Ist es empfehlenswert oder zu drakonisch, Mails von Mailservern ohne RDNS abzulehnen?

Ich habe SpamAssassin kürzlich gelöscht und begründe die Spam-Ablehnung nun mit DNSRBLs, Gray-Listing und anderen grundlegenden Tests. Ich frage mich, ob ich auch Hosts blockieren soll, die kein gültiges RDNS haben, das mit dem EHLO übereinstimmt.

Wenn ich das tue, mache ich dann Ärger mit viel seriöser Post und ärgere meine Kunden? Ich habe gehört, wie sich Leute darum gekümmert haben, dass AOL das tut, was mich denken lässt, dass es vielleicht zu ungewöhnlich für mich ist.

Ich frage mich auch, ob ich Kompromisse eingehen kann, indem ich überprüfe, ob RDNS mindestens auf etwas eingestellt ist, aber nicht versuche, es mit dem EHLO abzugleichen. Ist das mit Postfix möglich (und ist es nützlich)?

Ich habe mehrere Ansätze mit der HELO / EHLO-Prüfung bei einem relativ großen Kundenstamm von 100.000 bis 200.000 Benutzern ausprobiert und am Ende eine Lösung gefunden, die die folgenden Aufgaben erfüllt:

• Überprüfen Sie, ob das HELO / EHLO einen Domainnamen enthält. - Das läuft meist darauf hinaus, dass der Name einen Punkt enthält. Das Überprüfen des DNS auf den Namen führte zu VIELEN ausgefallenen Servern, da es nicht ungewöhnlich ist, dass der Server einen internen Namen hat oder etwas, das Sie nicht richtig auflösen können.
• Überprüfen Sie, ob die IP einen umgekehrten DNS-Eintrag hat. - Auch dies ist eine lockere Einstellung, da wir sie nicht mit dem HELO / EHLO vergleichen. Beim Vergleich mit dem HELO / EHLO wurden so viele Tickets erstellt, dass diese Einstellung nicht einmal einen Tag dauerte.
• Überprüfen Sie, ob der Domainname des Absenders gültig ist. - Dies ist eine grundlegende Überprüfung, um sicherzustellen, dass es zumindest eine Möglichkeit gibt, einen Server dafür zu finden, wenn wir die Nachricht bouncen müssen.

Hier ist der Postfix-Block, den wir für diese Prüfungen verwenden:

smtpd_recipient_restrictions =
    reject_non_fqdn_sender,
    reject_unauth_destination,
    reject_unknown_reverse_client_hostname,
    reject_invalid_helo_hostname,
    reject_non_fqdn_helo_hostname,
    reject_unknown_sender_domain,
    reject_non_fqdn_recipient

Es ist äußerst verbreitet, SMTP-Server zu blockieren, die nicht über die folgenden Grundlagen verfügen:

1. Der Hostname in der HELO-Weiterleitung wird in eine IP-Verbindung aufgelöst, die von stammt.
2. Die Ursprungs-IP der Verbindung wird auf den in HELO angegebenen Hostnamen zurückgesetzt.
3. Überprüfen Sie, ob SPF-, DKIM- oder DMARC-Richtlinien vorhanden sind.

Jeder, der sich wegen einer solchen Blockade überlegt, sollte geteert und mit Federn versehen werden.
Menschen, die aus anderen Gründen blockiert werden, insbesondere aus Situationen, in denen die RFC-Konformität in "abnormalen" Situationen erforderlich ist, habe ich Verständnis dafür. Spam ist ein solches Problem, dass es einfach keine Entschuldigung gibt, die Grundlagen zu verpassen.

Ich würde erwarten, dass das Senden von MTA gültige RDNS hat, aber darauf zu bestehen, dass EHLO übereinstimmt, würde davon abhängen, wer "die Kunden" sind. In RFC5321 finden Sie einige interessante Richtlinien :

2.3.5.

(...) Der im EHLO-Befehl angegebene Domänenname MUSS entweder ein primärer Hostname (ein Domänenname, der in eine Adresse RR aufgelöst wird) oder, falls der Host keinen Namen hat, ein Adressliteral sein (...)

4.1.4.

(...) Ein SMTP-Server KANN überprüfen, ob das Domänennamenargument im EHLO-Befehl tatsächlich der IP-Adresse des Clients entspricht. Wenn die Überprüfung fehlschlägt, DARF der Server die Annahme einer Nachricht auf dieser Basis NICHT ablehnen.

aber dann in 7.9.

Es ist allgemein anerkannt, dass ein SMTP-Server die Annahme von E-Mails aus betrieblichen oder technischen Gründen ablehnen kann, die für den Standort, der den Server bereitstellt, sinnvoll sind. (...)

Reverse Lookup zeigt nicht unbedingt auf den in HELO angegebenen Hostnamen. Manchmal werden mehrere Domänen auf demselben Host gehostet und alle haben dieselbe IP-Adresse. Wenn Sie jedoch versuchen, die Rückwärtssuche durchzuführen, erhalten Sie den Namen, der in den PTR-Datensatz eingefügt wurde. Es ist offensichtlich, dass beide FQDNs unterschiedlich sind - und das ist völlig akzeptabel.

Der einzige Umstand, der das Löschen einer Nachricht zulässt, ist die fehlgeschlagene Reverse-Suche. Jede erfolgreiche Suche bedeutet, dass der Host gültig ist. Namen sollten nicht übereinstimmen.

Ich frage mich, ob ich auch Hosts blockieren soll, die kein gültiges RDNS haben, das mit dem EHLO übereinstimmt.

Nein, das solltest du nicht. Blockiert eine ganze E-Mail nur nach einem Kriterium. Es ist eine schlechte Praxis.

Wenn ich das tue, mache ich dann Ärger mit viel seriöser Post und ärgere meine Kunden?

Wahrscheinlicher ist, dass Sie legitime E-Mails verlieren

Ich frage mich auch, ob ich Kompromisse eingehen kann, indem ich überprüfe, ob RDNS mindestens auf etwas eingestellt ist, aber nicht versuche, es mit dem EHLO abzugleichen. Ist das mit Postfix möglich (und ist es nützlich)?

ja es ist möglich Sie können reject_unknown_reverse_client_hostname anstelle von reject_unknown_client_hostname verwenden

Leider hat postfix keine flexiblen Optionen für "komplexe Entscheidungen". In exim können Sie einige Punkte für solche Mails hinzufügen, z

Score = 0 
1. The HELO or EHLO hostname is not in fully-qualified domain or address literal form. Score +=10
2. The HELO or EHLO hostname has no DNS A or MX record. Score +=20
3. The HELO or EHLO hostname is listed with the A record "d.d.d.d" under rbl_domain. Score +=20
4. The sender domain has no DNS A or MX record. Score +=10
5. SPF checks return softfail. Score +=10, fail, Score +=20
...

Und so weiter. Nachdem alle Überprüfungen abgeschlossen sind und Sie einen Score> 100 hatten, können Sie E-Mails ablehnen. Eigentlich können Sie ein solches Verhalten feststellen, aber Sie müssten einen eigenen Richtliniendienst schreiben