Postfix Reject_unknown_reverse_client_hostname: Ersetzen Sie den Standardcode unknown_client_reject_code (450) durch 550. Warum / wann sollte ich nicht?

Im täglichen Kampf gegen SPAM war ich mehrmals versucht, die DNS-Anforderungen von Clients, die über das wilde Internet eine Verbindung herstellen, stark durchzusetzen.

Im Detail hätte ich die Einstellung Reject_unknown_reverse_client_hostname in meinem Abschnitt smtpd_client_restrictions hinzugefügt , wie in:

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 

Wie auch immer, ich habe festgestellt, dass das Postfix-Verhalten bei Erreichen einer solchen Einschränkung ziemlich "weich" ist, da der Standardwert für das unknown_client_reject_code450 ist. Daher wird der Client aufgefordert, es erneut zu versuchen.

Während der Suche nach einer 550-Antwort traf ich folgende Aussage in der offiziellen Postfix-Dokumentation :

Ich bin absolut kein Experte für den gesamten RFC 5321 , aber als jemand, der alt genug ist, um RFC 821 zu kennen , verstehe ich wirklich nicht, warum eine 550-Antwort anstelle einer 450-Antwort meine Postfix-Instanz auf der maximalen SMTP-Ebene beeinflussen könnte ( Verstoß gegen die RFC-Konformität), insbesondere in Anbetracht der Tatsache, dass Postfix bei vorübergehenden Fehlern unabhängig von der expliziten Einstellung bei einem 450 bleibt.

Kann mir jemand helfen, zu verstehen, wo das Problem mit einem solchen Ersatz liegt?

PS: In der Zwischenzeit endete ich mit einer "entspannten" Einschränkung:

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 

Ich werde mit zwei praktischen Antworten beginnen

1. Die erste und naheliegendste Antwort ist, dass in einem Fall, in dem ein temporärer DNS-Fehler vorliegt, der Mailserver des Absenders durch einen temporären Bounce erneut versuchen kann, bis der DNS-Fehler behoben ist. In diesem Fall verhindert ein permanenter Absprung, dass die tatsächliche Ham-Mail Sie erreicht.

2. Die zweite Antwort ist, dass viel Spam über Botnet-Boxen gesendet wird, die keine tatsächlichen Funktionsprogramme zum Senden der E-Mails haben. Sie sprühen ihren Müll nur einmal und versuchen nicht, Nachrichten erneut zu senden, unabhängig davon, ob diese Nachricht einen vorübergehenden oder dauerhaften Fehler enthält. Wenn Sie also einen vorübergehenden Fehler verwenden, blockieren Sie einen großen Prozentsatz des Spam endgültig, aber Sie erlauben Ham dennoch, es erneut zu versuchen. (Dies ist übrigens der Grund, warum Greylisting immer noch funktioniert und immer noch viel Spam abfängt.)

Zusätzlich zu diesen gibt es auch eine Antwort, die mehr zur Theorie und zum RFC beiträgt

Der RFC sagt in Abschnitt 4.2.1. Das:

Eine Faustregel, um festzustellen, ob eine Antwort in die Kategorie 4yz oder 5yz passt (siehe unten), lautet, dass Antworten 4yz sind, wenn sie erfolgreich sein können, wenn sie ohne Änderung der Befehlsform oder der Eigenschaften des Absenders oder Empfängers (dh) wiederholt werden wird der Befehl identisch wiederholt und der Empfänger stellt keine neue Implementierung auf).

Im Falle eines Reverse-Lookup-Fehlers kann die Nachricht ohne Änderung der Nachricht selbst akzeptiert werden, sofern nur der DNS-Fehler behoben ist. Daher sollte dies ein vorübergehender Fehler sein.

In einem Fall, in dem es sich bei der Nachricht nicht um Spam handelt, kann der sendende Mailserver sysadmin die Fehlermeldung bemerken und das DNS-Problem beheben, sodass die Nachricht zugestellt werden kann, ohne dass der Benutzer eingreifen und die Nachricht erneut senden muss. Und wenn der Benutzer, der die E-Mail sendet, nicht auch für den Mailserver und / oder seine DNS-Einträge verantwortlich ist, kann er - selbst wenn er direkt einen permanenten Bounce erhält - nichts damit anfangen - anders als beispielsweise bei einem falsch geschriebenen Adresse.

Natürlich haben Sie immer das Recht, E-Mails aus irgendeinem Grund abzulehnen.