HELO-Filter
So funktioniert es
Das erste, was ein empfangender Mailserver nach dem CONNECT von dem Absender zu sehen bekommt ist ein HELO. Und hier können schon die ersten Tests einsetzen, um Verbindungen frühzeitig abzulehnen. Ein Auszug aus der RFC ist der Startpunkt:
Quelle: RFC-821 Section 3.5 (Achtung: RFC ist nicht mehr
aktuell !)
5.2.5 HELO Command:
The sender-SMTP MUST ensure that the <domain> parameter in a HELO command is
a valid principal host domain name für the client host. As a result, the
receiver-SMTP will not have to perform MX resolution on this name in order
to validate the HELO parameter. The HELO receiver MAY verify that the HELO
parameter really corresponds to the IP address of the sender. However, the
receiver MUST NOT refuse to accept a message, even if the sender's HELO
command fails verification.
Auf Deutsch:
- Der im HELO verwendete Hostname muss ein voll qualifizierter Hostname sein
- Damit erspart man dem Empfängerserver die Auflösung um zur IP-Adresse einen Namen zu finden
Aber hier steht auch klar:
- Der Empfänger darf die Mail nicht ablehnen, wenn HELO nicht dieser Vorgabe folgt.
Auch wenn damit eigentlich klar ist, dass ein Empfänger aufgrund eines falschen HELO-Strings die Mail nicht ablehnen darf, so ist es mittlerweile doch gängige Praxis einiger Firmen, eben eine solche strenge Richtlinie an den Tag zu legen.
Die RFC 821 wurde mittlerweile durch die RFC 2821 (http://tools.ietf.org/html/rfc2821#page-29) abgelöst, welche den Passus nicht mehr enthält. Es ist also nicht mehr "Pflicht" aber damit nicht wirksamer oder unwirksamer.
Ich selbst bin sehr skeptisch ob solche ein Filter wirklich brauchbar ist, da ein qualifizierter Spammer sicher alles daran setzen wird, an solchen Hürden vorbei zu kommen. Im Gegenzug gibt es aber sehr viele Firmen, die keinen ordentlichen Reverse-DNS-Record pflegen oder mit dynamischen IP-Adressen arbeiten. Sicher sind Verfahren wie SPF/CallerID besser geeignet, um gefälschte Absender zu einem frühen Zeitpunkt zu verhindern, aber solche Optionen sind leider noch nicht weit verbreitet.
Strenge HELO Prüfung
Wenn Sie ihre Mail nun nicht versenden können, weil die Gegenseite ihnen die Mail nicht abnimmt, dann soll ihnen das folgende Diagramm verdeutlichen, welche Tests die Gegenseite beim Verbindungsaufbau durchführen kann und wie Sie ihr System entsprechend "kompatibel" trimmen.
Wenn ihr Mailserver eine Verbindung zur Gegenstelle aufbaut, dann sieht der empfangende Mailboxserver erst einmal zwei Parameter:
- IP-Adresse, von der ihr System aus versendet.
- Der Namen im "HELO"- Kommando
Der Empfänger "kann" nun basierend darauf einige Tests durchführen und abhängig von den Werten unterschiedlich reagieren
Befehl | Beschreibung und Beispielmeldung |
---|---|
CONNECT |
Einige Mailserver prüfen schon direkt bei der
Verbindungsaufnahme die IP-Adresse gegen Sperrlisten oder
DNS-Anfragen. So kann es sein, dass Sie schon vor dem HELO gleich
eine Ablehnung erhalten, z.B. |
HELO Localhost |
"localhost" als HELO-String ist laut RFC nicht erlaubt und kann
vom anderen Mailserver abgewiesen werden. Fehlermeldung ist oft |
HELO ip-adress |
Eine IP-Adresse als HELO-String ist laut RFC nicht erlaubt und
kann vom anderen Mailserver abgewiesen werden. Fehlermeldung ist oft |
HELO server.firma.intern |
Die Verwendung eines "privaten" volldeklarierten Namens ist syntaktisch
erst einmal in Ordnung aber der Empfänger kann natürlich mit dem
Namen eine DNS-Auflösung durchführen. Macht der Empfänger die
Abfrage und findet den Host nicht, dann kann er auch die Verbindung
ablehnen. |
HELO server.fima.tld |
Die Verwendung des offiziellen Namens ist der saubere Weg.
Denkbar wäre hier auch ein Alias, z.B. mail.firma.tld. Der Empfänger
kann nun ebenfalls eine DNS-Abfrage machen und wird die Domain
sicher finden. Ob der Host selbst zu finden ist, können Sie als
DNS-Administrator der Zone konfigurieren. Ist der Host nicht
auflösbar, kann der Empfänger die Mail natürlich ablehnen. |
Man kann nun zu den Tests und Prüfungen sehr unterschiedliche Positionen einnehmen. Die einen Administratoren aktivieren sehr viele Tests um die Absender zu einer "strengen Richtlinie" zu zwingen. Als Firma, die jedoch Mails von Kunden und Bestellungen annehmen möchte, können Sie diese Regel aber eher nicht durchsetzen.
Die RFC selbst fordert eigentlich nur, dass es sich um einen "Voll Qualifizierten Hostnamen" handeln muss. Alle weitergehenden Prüfungen sind nicht vorgeschrieben und die damit verbundenen Bedingungen müssen nicht erfüllt sein. Sicher zeigt es von einem "guten" Setup, wenn der Name des Server im HELO-String auch per DNS auflösbar ist.
Ob man dies aber als Spamschutz erzwingen will, muss jede Firma mit sich selbst ausmachen, denn es wird sicher genug Absender geben, die diese Informationen nicht gepflegt haben oder nicht pflegen können. Als Spammer sollte es mir aber einfach sein mit falschen Angaben einen Server zu mieten, welcher alle Anforderungen erfüllt.
Die über eine Validierung des Hostnamens auf RFC-Konformität hinausgehenden Tests bedeuten nach meiner persönlichen Ansicht nur eine höhere Last auf den DNS-Servern und ein erhöhtes Risiko für "False Positives".
Weitere Links
- Exchange 2007 Sender Reputation
http://technet.microsoft.com/en-us/library/bb124512.aspx - RFC 2821
http://tools.ietf.org/html/rfc2821#page-29