Làm cách nào để kiểm tra xem e-mail của tôi có vào thư mục thư rác của người nhận không? [đóng cửa]


8

Tôi đang sử dụng Exim như một MTA để gửi email. Có thể nhận được thông báo nếu một email đi vào thư mục thư rác của người nhận không?


3
Vì các câu trả lời là không, nên có lẽ cách tốt nhất của bạn là đo lường số lượng người tham gia với email của bạn bằng cách theo dõi các liên kết được nhấp. Trong trường hợp có số lần nhấp ít hơn đáng kể so với thông thường, có thể là do thư đã kết thúc trong thư mục thư rác.
joeytwiddle

14
Nếu bạn có thể làm điều đó, điều đó sẽ đánh bại điểm có thư mục thư rác, bởi vì bạn cứ tiếp tục gửi các email hơi khác nhau cho đến khi không gửi được vào thư mục thư rác.
dùng253751

Gửi email theo dõi và hỏi xem người đầu tiên có vào thư mục thư rác không :-)
MonkeyZeus

4
Tôi đang bỏ phiếu để đóng câu hỏi này ngoài chủ đề vì nó nói chung về email và không phải là Unix / Linux. Nó có thể là chủ đề tại Super User (hoặc có thể là Lỗi máy chủ ), nhưng có lẽ nó sẽ không nhận được bất kỳ câu trả lời nào khác với câu trả lời mà nó đã nhận được.
G-Man nói 'Phục hồi Monica'

Câu trả lời:


14

Không, bạn sẽ nhận được thông báo "đã gửi" hoặc thông báo "lỗi". Khi thư được chấp nhận bởi đầu cuối từ xa, bạn không thể biết nó sẽ đi đến đâu sau đó. Ít nhất là không ở phía MTA của mọi thứ.

Một trong những lỗi có thể là "từ chối nguyên nhân của thư rác" hoặc "bị từ chối vì SPF" hoặc tương tự, nhưng nếu email của bạn được chấp nhận, ngay cả với thư mục thư rác, bạn sẽ không nhận được thông báo. Nếu email bị máy chủ của họ từ chối thì người nhận của bạn sẽ không nhận được email, ngay cả trong thư mục thư rác của họ.

Bạn có thể gặp lỗi "Trì hoãn" - đó có thể là do bạn bị nghi gửi spam. Điều này (trạng thái hoãn lại) sẽ cho Exim thử lại sau. Bạn có thể có được nhiều thông tin hơn từ tin nhắn đó. Tuy nhiên, hoãn lại là phổ biến, và bình thường, và không thực sự là một vấn đề. Sử dụng nó để cảnh báo thư rác rất cụ thể cho phần cuối nhận và có thể sẽ không cho Exim làm bất cứ điều gì ngoài việc thử lại sau.

Một số dịch vụ có "thủ thuật" để xem liệu thư có bị đánh dấu là thư rác hay không. Sự kết hợp của các liên kết, hình ảnh và thậm chí có thể là javascript có thể cho biết, trong một số trường hợp, nếu kết thúc của bạn trong thư mục thư rác. Nhưng những thứ này không hoạt động 100% thời gian và nhiều hơn về phía khách hàng (gmail, triển vọng, v.v.) sau đó là phía MTA.


1
Nói chung, SMTP được thiết kế sao cho các tin nhắn không bị biến mất vào quên lãng (tức là bạn phải nhận được một tin nhắn từ chối hoặc trả lại rõ ràng). Nhưng SMTP cũng được thiết kế theo giả định hoàn toàn sai lầm rằng thư rác không tồn tại, vì vậy điều này hầu như không đúng trong thực tế. Tuy nhiên, nếu bạn có DKIM và đảo ngược DNS được định cấu hình đúng và địa chỉ IP của bạn không thuộc về một khối được biết là spam, không chắc là email của bạn sẽ biến mất hoàn toàn (nó có thể rơi vào một thư mục spam, nhưng nó sẽ không âm thầm bỏ).
Kevin

3
@Kevin không may, một số máy chủ thư thực hiện một cách âm thầm email được xác định là thư rác - được chấp nhận ở giai đoạn SMTP nhưng không được gửi.
Stephen Kitt

10

Không, những gì xảy ra ở đích chỉ hiển thị ở đó (trừ khi nó trả lại email của bạn cho bạn).


5

Không, những gì xảy ra sau khi email của bạn rời khỏi hệ thống của bạn không thể được theo dõi trừ khi bạn có quyền truy cập vào máy tính nhận hoặc nếu có một số chương trình lọc thư rác cung cấp phản hồi.

Các chương trình phản hồi như vậy sẽ gửi lại email yêu cầu xác nhận, do đó, thư rác tự động có thể được phân biệt với tin nhắn thực sự được gửi bởi con người, nhưng một khi các bot đủ thông minh để trả lời thư này chỉ tạo ra thêm thư và tôi đã không được yêu cầu xác nhận như vậy qua email trong hơn 15 năm.

Thư bị trả lại không được khuyến khích, nếu hoàn toàn không nên chấp nhận email để gửi (nếu địa chỉ không tồn tại), nhưng điều đó không liên quan gì đến việc liệu tin nhắn của bạn có rơi vào hộp thư rác hay không. Thư rác không bao giờ bị trả lại vì người gửi trong tiêu đề thư không chắc là người gửi thực sự.


nếu bạn đang nói về các hệ thống phản hồi thử thách (còn gọi là spam tán xạ ngược tự động ở cấp độ người dùng), tôi đã viết các quy tắc procmail để đối phó với chúng, chúng sẽ luôn xác nhận bất kỳ thông báo phản hồi thách thức nào gửi cho tôi. Đó không phải là thư rác của tôi để xử lý, đó là thư của họ và thật vô cùng khó chịu và phản cảm khi người dùng CR mong tôi xử lý thư rác CỦA HỌ - nếu họ sẽ giảm tải công việc cho họ, tôi sẽ tự động chấp nhận thay mặt họ. Một bài học quý giá về những rủi ro của việc thuê ngoài.
cas

Tôi trả lời bạn, tôi nghĩ rằng bạn nói ở đây về các vòng phản hồi, giúp kích hoạt "khiếu nại" của người nhận, vì vậy khi người nhận đánh dấu thư là thư rác, FBL cho phép người gửi nhận lại tin nhắn từ các thành viên đã khiếu nại
Abdessamad Elouarti

@ABDESSAMADELOUARTI Có, bạn có thể xem đây là các vòng phản hồi. Có một số vấn đề với điều này và việc tạo thêm một thư cho mỗi thư được gửi là một trong số đó. Ngoài ra, nếu cả A và B đều thiết lập một hệ thống như vậy với các cơ chế khác nhau và tôi đã gửi email từ A đến B, thì B có thể gửi cho A một tin nhắn xác nhận, do đó A không nhận ra như vậy, do đó tự động gửi một email đến B để xác nhận, trong đó ...... ad infinitum
Anthon

3

Không có chức năng nào sẽ cho bạn biết thư mục của bạn được gửi đến. Ngay cả các thủ thuật cho bạn biết nếu tin nhắn đã được đọc, đừng cho bạn biết nó được đọc từ đâu.

Tuy nhiên, bạn có thể có được một ý tưởng tốt từ các nhà cung cấp chính, gmail, yahoo và microsoft, nếu bạn định cấu hình DMARC. Điều này dựa trên cấu hình DKIM và SPF của bạn và có thể báo cáo lại số lượng tin nhắn nhận được từ tên miền của bạn, cũng như khả năng xử lý. Nó cũng sẽ báo cáo các địa chỉ IP giả mạo tên miền của bạn.


Đồng thời tạo một tài khoản kiểm tra với mỗi nhà cung cấp chính, để bạn có thể kiểm tra xem email kiểm tra đơn của bạn có vào thư mục thư rác hay không và email trông như thế nào trước khi gửi thư hàng loạt.
Ian Ringrose

yeah, thnks, đây là giải pháp cuối cùng của tôi
Abdessamad Elouarti
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.