Постфикс reject_unknown_reverse_client_hostname: заменить код по умолчанию unknown_client_reject_code (450) на 550. Почему / Когда я не должен?

В ежедневной борьбе со спамом несколько раз я испытывал соблазн принудительно применять требования DNS от клиентов, подключающихся из дикого Интернета.

Подробно, я бы добавил параметр reject_unknown_reverse_client_hostname в моем разделе smtpd_client_restrictions , например:

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 

Во всяком случае, я заметил, что при достижении такого ограничения поведение Postfix довольно «мягкое», так как значение по умолчанию для unknown_client_reject_code450. Следовательно, клиенту предлагается продолжать повторную попытку.

При поиске ответа 550 я встретил следующее утверждение в официальной документации Postfix :

Я абсолютно не эксперт по всему RFC 5321 , но как человек достаточно взрослый , чтобы знать RFC 821 , я действительно не понимаю, почему ответ 550 вместо 450 мог повлиять на мой экземпляр Postfix на максимальном уровне SMTP ( нарушение соответствия RFC), особенно учитывая, что в случае временных ошибок Postfix будет придерживаться 450 независимо от явных настроек.

Итак, кто-то может помочь мне понять, в чем проблема с такой заменой?

PS: тем временем я закончил с "смягченным" ограничением:

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 

Я начну с двух практических ответов

1. Первый и наиболее очевидный ответ заключается в том, что в случае временной ошибки DNS временный отказ позволит почтовому серверу отправителя повторить попытку, пока ошибка DNS не будет исправлена. В этом случае постоянный отскок заблокирует фактическую почту от хэма.

2. Второй ответ заключается в том, что большое количество спама отправляется через ящики ботнетов, которые не имеют какой-либо формы реальных функциональных программ для отправки почты. Они будут опрыскивать свой мусор только один раз и не будут пытаться повторно отправлять какие-либо сообщения, независимо от того, является ли указанное сообщение временной или постоянной ошибкой. Таким образом, используя временную ошибку, вы навсегда блокируете большой процент спама, но вы все еще позволяете Хаму повторить попытку. (Именно поэтому, кстати, грейлистинг все еще работает и все еще ловит много спама.)

В дополнение к этим, есть также ответ, который имеет большее отношение к теории и RFC

RFC говорится в разделе 4.2.1. который:

Эмпирическое правило, определяющее, подходит ли ответ к категории 4yz или 5yz (см. Ниже), заключается в том, что ответы имеют размер 4yz, если они могут быть успешными, если они повторяются без каких-либо изменений в форме команды или в свойствах отправителя или получателя (то есть , команда повторяется одинаково, и получатель не устанавливает новую реализацию).

В случае сбоя обратного просмотра, было бы возможно, чтобы сообщение было приемлемым без каких-либо изменений в самом сообщении, при условии, что только исправлена ​​ошибка DNS. Следовательно, это должно быть временной ошибкой.

В случае, когда сообщение не является спамом, системный администратор отправляющего почтового сервера может заметить сообщение об ошибке и исправить проблему DNS, чтобы сообщение могло быть доставлено без вмешательства пользователя и повторной отправки сообщения. И если пользователь, отправляющий электронное письмо, также не отвечает за почтовый сервер и / или его DNS-записи, даже если он действительно получает постоянный отскок напрямую, он не сможет ничего с этим сделать - в отличие, например, от случая с ошибкой адрес.

Конечно, вы по-прежнему имеете право отклонить любое электронное письмо по любой причине.