Sie haben den Weg hierher gefunden, weil Sie sowas wie ihr-mailserver-verstoesst-gegen-rfc-5321.abschnitt-2-3-5.de in Ihren Maillogs gefunden haben?

Dann sind Sie hier richtig.

Zur Erklärung:

RFC 5321 als designierter Nachfolger von RFC 2821 und RFC 821 spezifiziert deutlich, welchen Text ein SMTP-Client hinter seinem "HELO" verwenden soll:

2.3.5.  Domain Names
[...]
The domain name given in the EHLO command MUST be either a primary
host name (a domain name that resolves to an address RR) or, if
the host has no name, an address literal, as described in
Section 4.1.3 and discussed further in the EHLO discussion of
Section 4.1.4.

Die Formulierung "a primary host name" steht nun aber gar nicht in Beziehung zur gerade laufenden SMTP-Transaktion und schon gar nicht zum dafür verwendeten TCP.
Sonst stünde da nämlich "The domain name given [...] MUST be contained in the PTR RR associated with the ip address the client chose to use for this transaction.". Und das steht da deshalb nicht, weil der Client-Mailserver selbstverständlich unter mehreren Namen mit unterschiedlichen IP-Nummern erreichbar sein darf und in einer Umgebung laufen könnte, in der es der SMTP-Software gar nicht möglich ist, autonom festzustellen, welche IP-Adresse der andere Mailserver sieht.¹
Welcher der möglichen Namen im HELO verwendet wird, bleibt deshalb offensichtlich dem Betreiber überlassen.

RFC 5321 (wie auch RFC 2821) stellt jedenfalls keine Anforderungen, welcher von mehreren möglichen Namen als FQDN im HELO benutzt werden soll. (RFC 821 forderte sogar nur, daß das Clientsystem sich durch den Namen hinter "HELO" identifizieren solle - da war von einer Existenz des Namens im DNS gar keine die Rede.)

Um diese Sachlage, die auch schon im RFC 2821 vorlag, unmissverständlich zu machen, konkretisiert RFC 5321 denn auch endlich im Abschnitt 4.1.4, Absatz 6 genau dies:

4.1.4.  Order of Commands
[...]
An SMTP server MAY verify that the domain name argument in the EHLO
command actually corresponds to the IP address of the client.
However, if the verification fails, the server MUST NOT refuse to
accept a message on that basis. [...]

Jetzt kommen Sie wieder: Ihr System lehnt wegen falsch konfigurierter SMTP-Software E-Mails von unserem Mailserver ab. Unser Mailserver heißt "mail.onlinefix.de". Er hat auch noch andere Namen, aber das ist sein ältester und am besten eingeführter Name. Obzwar "EHLO mail.onlinefix.de" also völlig korrekt ist (s.o.), behindert Ihr Mailserver die Kommunikation - wahrscheinlich, um Spam zu bekämpfen. Das war also keine gute Idee. Nicht nur, weil Sie damit legitime E-Mails an sich selbst behindern, zusätzlich ist die Maßnahme gegen Spam auch noch schlicht unwirksam, da auch schlecht programmierte Spambots durchaus in der Lage sind, im HELO den gerade zur IP-Adresse passenden Reverse-Lookup zu verwenden oder noch einfacher, das address literal zur eigenen IP-Nummer. Diese Spambots laufen nämlich fast ausschließlich auf Arbeitsplatz-PCs mit nur einer einzigen, einfach bestimmbaren IP. Und die wenigen Spambots, die ein ungültiges HELO senden, fallen durch totales Unvermögen auch ohne DNS-Abfragen sofort auf: Das sind die, die selbst nach RFC-821-Maßstäben Unsinn senden: "pc", "oemcomputer", "localhost" oder "workstation" sind keinesfalls geeignet, den Client zu identifizieren.

Wir haben für Ihren Fall einen Workaround eingerichtet, damit Sie Ihre Post trotzdem erhalten. Andere machen das vielleicht nicht und verzichten einfach auf E-Mailkommunikation - denken Sie mal darüber nach.


¹) Beispiele für mögliche Gründe: Der Client-Mailserver steht hinter einem Loadbalancer oder einer Firewall mit mehreren externen Interfaces oder der Mailserver selbst hat mehrere Interfaces zum Internet, aber die Entscheidung, welches davon verwendet wird, läuft unabhängig vom SMTP-Dienst.

Letzte Änderung: 2010-05-06 16:14 +0200