Tôi có nên để email bị trả lại hoặc gửi nó vào một lỗ đen?

Tôi có rất nhiều tài khoản chưa sử dụng (cũ, đã chết) trên máy của mình. Nhiều người trong số họ nhận được hàng ngàn email mỗi ngày, tất cả đều là thư rác.

Nếu tài khoản được sử dụng bởi một người, tôi để email bị trả lại để bất kỳ ai cố gắng liên hệ với họ đều biết có gì đó không ổn. Tuy nhiên, tôi không biết phải làm gì với hàng trăm tài khoản được sử dụng cho các mục đích khác, chẳng hạn như các tài khoản bị vứt bỏ mà tôi đã sử dụng cho các trang web hỏi địa chỉ email của tôi hoặc địa chỉ mà tôi đã sử dụng để liệt kê trên các trang web .

Tùy chọn 1:
Chuyển tiếp tất cả thư đến các tài khoản này /dev/null. Người gửi không nhận được một phản hồi.

Tùy chọn 2:
Hãy để email bị trả lại.

Lợi ích của việc gửi email đến /dev/nulllà một người gửi thư rác không thể sử dụng tôi để tạo thư bị trả lại (Thư rác tán xạ ngược) . tức là: giả mạo dòng "từ" để trở thành người mà họ không thích, sau đó sử dụng tôi để gửi hàng tấn tin nhắn trả lại cho người đó.

Lợi ích của việc nảy chúng là nó ít bảo trì hơn đối với tôi. Tôi chỉ có thể xóa mục khỏi tệp bí danh của mình và email sẽ bị trả lại. Ngoài ra, tôi tiếp tục phát hiện ra các bẫy thư rác mới và thêm chúng vào danh sách "lỗ đen thư rác" của mình, điều này thật lãng phí thời gian.

Những ưu và nhược điểm của từng phương pháp là gì?

Miễn là bạn trả lại thư bằng cách từ chối nhận nó ngay từ đầu, thì một người gửi thư rác không thể sử dụng bạn để làm phiền ai đó vô tội với rất nhiều thư bị trả lại.

Bạn có thể trả về lỗi trên RCPT TOlệnh, đây là điều thường xảy ra trong trường hợp địa chỉ không tồn tại hoặc bạn có thể trả về thành công cho RCPT TOlệnh nhưng trả lại lỗi ở cuối DATA.

Trong cả hai trường hợp, kết quả cuối cùng sẽ giống nhau. Máy chủ thư của bạn không chịu trách nhiệm về thư và máy chủ gửi thư hiện chịu trách nhiệm gửi thư. Trong trường hợp thư rác, điều đó có nghĩa là người gửi thư rác sẽ phải tạo ra các lần thoát. (Và nếu đó là những gì họ muốn làm, họ có thể đã làm như vậy mà không cần cố gắng gửi thư cho bạn ngay từ đầu.)

Tôi thấy không có vấn đề trong cách tiếp cận này.

Tuy nhiên tôi thấy có một vấn đề trong việc chấp nhận thư. Tức là nếu máy chủ thư của bạn phản hồi thành công trong suốt quá trình giao dịch, kể cả vào cuối DATA, thì việc máy chủ thư của bạn trở thành trách nhiệm gửi thư. Đây là một vấn đề, bởi vì bạn không có lối thoát thích hợp.

• Âm thầm thả thư là một vấn đề, bởi vì nếu bất kỳ thư hợp pháp nào được gửi, người gửi không bao giờ có thể biết rằng nó đã được gửi.
• Gửi thư bị trả lại từ máy chủ thư của bạn là một vấn đề, bởi vì trong trường hợp đó, thư rác bị trả về hộp thư của một người vô tội thay vì quay lại thư rác.

Có thể có trường hợp phân phối địa chỉ email ở nơi đầu tiên bị hạn chế đến mức bạn biết rằng không thể có bất kỳ thư hợp pháp nào gửi đến địa chỉ. Trong những trường hợp đó, sẽ có rất ít sự khác biệt nếu bạn từ chối RCPT TOlệnh hoặc nếu bạn chấp nhận thư và âm thầm thả nó. Nhưng tôi không thể đưa ra một tình huống trong đó âm thầm bỏ thư tốt hơn là từ chối nó trong giao dịch SMTP.

Tôi sẽ đưa ra câu trả lời này khá chung chung vì các thuật ngữ và chi tiết cấu hình sẽ thay đổi tùy thuộc vào phần mềm máy chủ thư / bộ lọc thư rác cụ thể của bạn.

Thực tế, có 3 cách tiếp cận cho một người nhận không hợp lệ:

1. Sau khi người nhận được xác định là không hợp lệ, hãy gửi một tin nhắn không thể gửi lại cho người gửi.

2. Đóng kết nối SMTP trong khi tin nhắn vẫn "đang trong chuyến bay". Máy chủ SMTP của người gửi sẽ chịu trách nhiệm tạo thư không thể gửi được.

3. Chấp nhận tin nhắn và âm thầm xóa nó. Người gửi sẽ không biết liệu tin nhắn có được nhận hay không.

Có rất ít lý do để sử dụng phương pháp số 1 nữa. Trong trường hợp tấn công Backscatter, máy chủ của bạn sẽ trông giống như kẻ gửi thư rác (mặc dù đó là nạn nhân vô tội) và bạn sẽ là người bị đưa vào danh sách đen. Nó cũng đặt thêm tải trên máy chủ của bạn và tải lên băng thông, vì nó phải gửi thông báo thoát.

Cách tiếp cận # 2 là khá tốt hơn nhiều so với cách tiếp cận # 1. Nó làm giảm khả năng máy chủ của bạn bị đưa vào danh sách đen hoặc DoSed. Nó không loại trừ khả năng tán xạ ngược đối với địa chỉ bên thứ ba vô tội, nhưng ít nhất máy chủ của bạn không phải là nơi gửi tin nhắn bị trả lại.

Cách tiếp cận # 3 loại bỏ khả năng Backscatter. Nó cũng giúp bảo vệ chống lại Attack Attack Attack . Tuy nhiên, điều đó cũng có nghĩa là nếu một người gửi bên ngoài nhập sai địa chỉ của bạn, họ sẽ không bao giờ biết. Nó cũng có thể là một vấn đề nếu ai đó rời khỏi công ty của bạn và một khách hàng cố gắng liên lạc với nhân viên cũ.

Tôi đã thừa hưởng một hệ thống e-mail sử dụng Cách tiếp cận số 3 do lo ngại về DHA. Nó gây ra nhiều rắc rối hơn giá trị của nó. Bây giờ chúng tôi sử dụng phương pháp # 2. (Lưu ý có nhiều cách khác để giảm thiểu DHA.)

Nếu máy chủ email của bạn được cấu hình đúng, bạn nên từ chối email cho người dùng không xác định trong giao dịch SMTP.

Từ chối email trong quá trình giao dịch SMTP

Máy chủ của bạn nên được cấu hình để từ chối email đến những người dùng không xác định trong giai đoạn giao dịch SMTP. Làm như vậy sẽ trả về mã lỗi 550 SMTP cho máy chủ gửi. Vì điều này xảy ra trong giao dịch SMTP, máy chủ của bạn không bao giờ gửi Báo cáo không phân phối (còn gọi là bị trả lại).

Được cấu hình đúng, điều này ngăn chặn tán xạ ngược do từ chối được gửi trực tiếp đến máy chủ gửi và các tiêu đề email khác bị bỏ qua.

Những lợi ích

Lợi ích của phương pháp này là bạn sẽ từ chối email rất sớm trong quy trình giao dịch SMTP. Điều này có nghĩa là:

• Sử dụng tài nguyên thấp hơn trên máy chủ của bạn, đặc biệt nếu tất cả email được gửi để xử lý sau khi được chấp nhận (lọc virus / av).
• Người gửi thường sẽ xóa các địa chỉ email này khỏi danh sách của họ để tránh bị đưa vào danh sách đen.

Hãy xem xét rằng nếu bạn định tuyến email, máy chủ gửi tin nhắn sẽ được gửi thành công. Không có lý do gì để họ ngừng gửi email những địa chỉ không còn tồn tại này. Do đó, khi các địa chỉ cũ này chồng chất, bạn cần ngày càng nhiều tài nguyên máy chủ để xử lý email.

Để thực hiện điều này, bạn chỉ cần xóa người dùng khỏi hệ thống email. Nếu bạn cần sao lưu email hiện tại, điều đó tốt, bạn chỉ muốn máy chủ của mình gửi 550 user unknownphản hồi.