Postfix từ chối_unknown_Vverse_client_hostname: thay thế default_client_Vject_code (450) mặc định thành 550. Tại sao / Khi nào tôi không nên?

Trong cuộc chiến hàng ngày chống lại SPAM, đã có nhiều lần tôi bị cám dỗ thực thi mạnh mẽ các yêu cầu DNS từ các máy khách kết nối từ Internet hoang dã.

Cụ thể, tôi sẽ có thêm các reject_unknown_reverse_client_hostname thiết lập trong phạm vi của tôi smtpd_client_restrictions phần, như trong:

smtpd_client_restrictions = 
            permit_sasl_authenticated
            check_client_access hash:/etc/postfix/access 
            check_policy_service inet:127.0.0.1:4466
            reject_unknown_reverse_client_hostname
            reject_unauth_pipelining 

Dù sao, tôi đã lưu ý rằng khi nhấn vào hạn chế đó, hành vi Postfix khá "mềm" vì giá trị mặc định cho unknown_client_reject_codelà 450. Do đó, khách hàng được mời tiếp tục thử lại.

Trong khi điều tra phản hồi 550, tôi đã gặp tuyên bố sau, trên tài liệu chính thức của Postfix :

Tôi hoàn toàn không phải là chuyên gia về toàn bộ RFC 5321 , nhưng là một người đủ tuổi để biết RFC 821 , tôi thực sự không hiểu tại sao, một phản hồi 550 thay vì 450, có thể ảnh hưởng đến cá thể Postfix của tôi ở mức SMTP tối đa ( phá vỡ sự tuân thủ RFC), đặc biệt xem xét rằng trong trường hợp có lỗi tạm thời, Postfix sẽ gắn với 450 bất kể cài đặt rõ ràng.

Vì vậy, ai đó có thể giúp tôi hiểu vấn đề với sự thay thế như vậy không?

PS: trong lúc này, tôi đã kết thúc với một hạn chế "thoải mái":

smtpd_client_restrictions = 
            permit_sasl_authenticated
            check_client_access hash:/etc/postfix/access 
            check_policy_service inet:127.0.0.1:4466
            warn_if_reject reject_unknown_reverse_client_hostname
            reject_non_fqdn_helo_hostname
            reject_unauth_pipelining 
            reject_invalid_helo_hostname 

Tôi sẽ bắt đầu với hai câu trả lời thiết thực

1. Câu trả lời đầu tiên và rõ ràng nhất là trong trường hợp có lỗi DNS tạm thời, việc thoát tạm thời sẽ cho phép máy chủ mail của người gửi thử lại cho đến khi lỗi DNS được khắc phục. Trong trường hợp này, thư bị trả lại vĩnh viễn sẽ chặn thư ham thực tế đến tay bạn.

2. Câu trả lời thứ hai là rất nhiều thư rác được gửi qua các hộp botnet không có bất kỳ hình thức chương trình chức năng thực tế nào để gửi thư. Họ sẽ chỉ phun rác một lần duy nhất và sẽ không cố gửi lại bất kỳ tin nhắn nào cho dù tin nhắn nói đó có lỗi tạm thời hay vĩnh viễn. Vì vậy, bằng cách sử dụng một lỗi tạm thời, bạn sẽ chặn được phần lớn thư rác, nhưng bạn vẫn cho phép ham thử lại. (Nhân tiện, đây là lý do tại sao greylning vẫn hoạt động và vẫn bắt được rất nhiều thư rác.)

Ngoài những câu hỏi này, còn có một câu trả lời mang nhiều lý thuyết và RFC

RFC nói trong phần 4.2.1. cái đó:

Một nguyên tắc nhỏ để xác định xem một câu trả lời phù hợp với loại 4yz hay 5yz (xem bên dưới) là các câu trả lời là 4yz nếu chúng có thể thành công nếu được lặp lại mà không có bất kỳ thay đổi nào trong dạng lệnh hoặc thuộc tính của người gửi hoặc người nhận (đó là , lệnh được lặp lại giống hệt nhau và người nhận không đưa ra một triển khai mới).

Trong trường hợp lỗi tra cứu ngược, thông báo có thể được chấp nhận mà không có bất kỳ thay đổi nào trong thông báo, chỉ với điều kiện là lỗi DNS đã được sửa. Do đó, đây phải là một lỗi tạm thời.

Trong trường hợp tin nhắn không phải là thư rác, người gửi mailserver sysadmin có thể nhận thấy thông báo lỗi và khắc phục sự cố DNS, để tin nhắn có thể được gửi mà không cần người dùng phải can thiệp và gửi lại tin nhắn. Và trừ khi người dùng gửi email cũng chịu trách nhiệm về máy chủ thư và / hoặc các mục DNS của nó, ngay cả khi họ bị trả lại vĩnh viễn, họ sẽ không thể làm bất cứ điều gì với nó - không giống như trường hợp sai chính tả Địa chỉ.

Tất nhiên, bạn vẫn luôn có quyền từ chối bất kỳ email nào vì bất kỳ lý do gì.