„I don’t like spam“, oder wie man einen Mailserver testet

Dieser Artikel erschien erstmals in freiesMagazin 09/11: Es begann mit einem Irrtum. Im Werbebrief vom Google für den AdWords-Dienst befand sich ein Gutschein über 75 Euro, der auf einen völlig fremden Menschen ausgestellt war. Wenn man Sandra Fründt, Head of Business Marketing Google Deutschland, auf ihren Fehler aufmerksam machen will, immerhin hat sie diesen Brief unterschrieben, stößt man auf ein Problem: Im Schreiben ist überhaupt keine E-Mail-Adresse angegeben. Das Unternehmen, das mit Suchmaschine und E-Mail-Dienst im Internet groß geworden ist, zeigt sich in seiner Werbung ganz schön verschlossen.

Auf der Suche nach einer E-Mail-Adresse

Jetzt kann man sich eine mögliche und formal richtige E-Mail-Adresse für die Empfängerin ausdenken, eine E-Mail an diese Adresse schicken und darauf warten, ob der Mailserver die Nachricht auch erfolgreich zustellen kann. Wenn er nämlich scheitert, bekommt man eine Fehlermeldung als Antwort zurück. Entweder probiert man so lange herum, bis diese Antwort ausbleibt, oder man kann, um das Ganze abzukürzen, den Test auch in die Konsole verlagern. Das Werkzeug für diesen Test ist das Telnet [1], für das bei den meisten GNU/Linux-Distributionen, MacOS X und sogar bei Windows ein Tool vorinstalliert oder schnell nachträglich zu installieren ist.

In der Vergangenheit war Telnet eine unverschlüsselte und daher unsichere Methode für die Fernwartung von Rechnern. Der Vorteil von Telnet ist aber, dass man sich über den entsprechenden Port mit so ziemlich jedem Server verbinden kann, der ein textbasiertes Protokoll beherrscht, also auch mit Mailservern. Diesen Vorteil muss man allerdings mit Vorsicht genießen, da er auch von Spammern genutzt wird.

Woher kommt das Wort „Spam“?

Die Bezeichnung „Spam“ für Massenmails zu Werbezwecken im Internet wurde durch einen Sketch der englischen Komikertruppe Monty Python geprägt. Der Sketch [2] spielt in einem Imbiss, in dem es fast ausschließlich nur Spam (spiced ham), also „gewürzten Schinken“, auf der Speisekarte gibt. Auf die Frage, ob es auch etwas ohne Spam gäbe, antwortet die Kellnerin: „Well, there’s spam egg sausage and spam, that’s not got much spam in it.“ Woraufhin die Kundin sagt: „I don’t want ANY spam!“. Später, beim Versuch, etwas ohne Spam zu bestellen, kreischt sie sogar: „I don’t like spam!“ Spam wird in dem Sketch 132 mal genannt und steht synonym für eine unnötig häufige Verwendung und Wiederholung.

Wie funktioniert E-Mail eigentlich?

Bevor es losgeht, sollte man sich noch kurz klar darüber werden, was beim Versenden von E-Mails überhaupt passiert und ein paar Begriffe klären. In der Regel schreibt man eine E-Mail mit einem E-Mail-Programm, das auch E-Mail-Client oder, etwas technischer, „Mail User Agent“ (MUA) genannt wird. Traditionell werden die E-Mails vom „Mail Transfer Agent“ (MTA), das ist dann der Mailserver, entgegengenommen, falls nicht ein „Message Submission Agent“ (MSA) dazwischen geschaltet ist, der die E-Mails vom MUA an den MTA übergibt. Das Protokoll zum Versenden der Nachrichten zwischen diesen Servern heißt „Simple Mail Transfer Protocol“ (SMTP). Auf der Empfängerseite ist der „Mail Delivery Agent“ (MDA) verantwortlich für die Zustellung zum E-Mail-Client. Die Protokolle, die zum Abholen von Nachrichten verwendet werden heißen „Post Office Protocol“ (POP) oder „Internet Message Access Protocol“ (IMAP).

Der Weg einer E-Mail vom Sender zum Empfänger.
© Polluks (CC-BY-SA-3.0)

Nach der Theorie die Praxis

Normalerweise fragen Mailserver beim Versenden von E-Mails nach dem vollständigen Namen einer Domain. Da hier keine E-Mail verschickt werden soll, wird mit dem Befehl nslookup nach dem entsprechenden Domainnamen gesucht:

$ nslookup -q=mx google.com
Server:         192.168.178.1
Address:        192.168.178.1#53
 
Non-authoritative answer:
google.com      mail exchanger = 50 alt4.aspmx.l.google.com.
google.com      mail exchanger = 10 aspmx.l.google.com.
google.com      mail exchanger = 20 alt1.aspmx.l.google.com.
google.com      mail exchanger = 30 alt2.aspmx.l.google.com.
google.com      mail exchanger = 40 alt3.aspmx.l.google.com.

Gesucht wird nach dem „Mail Exchange Resource Record“ (MX-Eintrag) der Domain google.com im „Domain Name System“ (DNS), der sich ausschließlich mit dem E-Mail-Dienst (SMTP) beschäftigt. Wie man sieht hat Google gleich mehrere MX-Einträge mit unterschiedlichen Prioritäten, damit bei einem Ausfall der jeweils andere die E-Mails entgegen nehmen kann. Der Eintrag mit dem höchsten numerischen Wert hat meist die niedrigste Priorität. Das nutzen Spammer gerne aus, indem sie sich mit dem Mailserver mit der niedrigsten Priorität verbinden, um Spamfilter zu umgehen, die auf dem Server mit der höchsten Priorität laufen. Laut dem MX-Eintrag ist der Server mit der höchsten Priorität aspmx.l.google.com. Mit dem wird jetzt die Verbindung über Telnet und dem Port 25 für SMTP aufgebaut:

$ telnet aspmx.l.google.com 25
Trying 74.125.39.27...
Connected to aspmx.l.google.com.
Escape character is '^]'.
220 mx.google.com ESMTP 3si5028908fav.179

Was in diesem Fall bei Google klappt, kann bei anderen Mailservern schon schief gehen. Zur Abwehr von Spammern lassen einige Mailserver – zum Beispiel von GMX – eine Verbindung zum Server im MX-Eintrag gar nicht erst zu, wenn die Anfrage über die dynamische IP eines Client-PCs gestellt wird und nicht von einem anderen Mailserver kommt. Es kann aber auch sein, dass der Mailserver aufgrund einer Störung einfach nicht erreichbar ist.

Was einem der Statuscode so sagt

Die letzte Zeile der obigen Ausgabe beginnt mit einer Zahl, nämlich 220. Im SMTP-Protokoll werden Befehle der Reihe nach ausgeführt und jeder Befehl wird mit einem Statuscode beantwortet. Die Beschreibung, die auf den Statuscode folgt, ist für Menschen gedacht und für das Protokoll ohne Bedeutung. Beginnt der Statuscode so wie in diesem Fall mit einer 2, dann war die Bearbeitung erfolgreich, bei einer 3 fehlen noch Informationen und bei einer 5 ist ein Fehler aufgetreten.

Als erstes erwartet der Server eine Begrüßung in Form eines HELO, dabei ist es im Prinzip völlig egal, welches Argument man nach dem Befehl einträgt, auch wenn man eigentlich die eigene Domain angeben sollte:

helo hi
250 mx.google.com at your service

Der Statuscode mit der 2 am Anfang zeigt, dass der Befehl erfolgreich bearbeitet wurde und der Server zu Diensten steht. Anschließend gibt man die E-Mail-Adresse des Absenders mit dem Befehl MAIL FROM ein:

mail from: <test.user@googlemail.com> 250 2.1.0 OK 3si5028908fav.179

Die spitzen Klammern vor und nach der E-Mail-Adresse sind wichtig. Ansonsten erhält man einen Syntax Error. Als nächstes gibt man einen Empfänger ein, zum Beispiel eine Adresse von der man weiß, dass sie existiert:

rcpt to: <larry.page@google.com>
250 2.1.5 OK 3si5028908fav.179

Gibt es die E-Mail-Adresse wirklich?

Die 250 oben verrät, dass der Befehl erfolgreich war. Die E-Mail-Adresse scheint zu existieren. Doch auch hier gibt es die ein oder andere Falle, die Mailserver Spammern stellen.

Manche Mailserver haben ein Catch-All für E-Mails, dann laufen alle E-Mails mit einer formal richtigen E-Mail-Adresse der Domain in der gleichen Mailbox zusammen und der Mailserver antwortet in diesem Fall bei jeder formal gültigen Adresse mit einem „OK“.

Vielleicht wird auch eine Graue Liste zur Spambekämpfung eingesetzt. Dabei wird die erste E-Mail von einem unbekannten Absender abgewiesen und erst nach dem nächsten Zustellversuch angenommen.

Eine weitere Methode ist das „Sender Policy Framework“ (SPF). Hier schaut der empfangende Mailserver nach, ob die Domain im Befehl MAIL FROM mit dem Argument des Befehls HELO übereinstimmt. Wenn das nicht der Fall ist, kann es gut sein, dass der Rechner E-Mails für diese Domain gar nicht versenden darf. Dadurch soll das Fälschen von Absendern auf SMTP-Ebene erschwert werden.

Der nächste Versuch zeigt, dass der Mailserver von Google vermutlich kein Catch-All verwendet:

rcpt to: <sandra.fruendt@google.com>
550-5.1.1 The email account that you tried to reach does not exist. Please try
550-5.1.1 double-checking the recipients email address for typos or
550-5.1.1 unnecessary spaces. Learn more at                             
550 5.1.1 http://mail.google.com/support/bin/answer.py?answer=6596 3si5028908fav.179

Auch ohne den Statuscode sieht man, dass hier etwas falsch läuft. Die E-Mail-Adresse existiert laut dem Mailserver nicht. Das kann auch wiederum mehrere Ursachen haben: Entweder ist Frau Fründt eine Externe und gehört nicht zum Unternehmen oder es gibt dort mehr als eine Sandra Fründt oder die Administratoren bei Google halten ein einheitliches Namensschema für E-Mail-Adressen in einem Unternehmen für überbewertet. Ein paar Versuche später wird klar, dass der letzte Punkt zutrifft. Mit dem Befehl QUIT schließt man die Telnet-Sitzung wieder.

Zum Validieren reicht es nicht

Am Ende konnte die – vermutlich – korrekte E-Mail-Adresse von Frau Fründt zusammen mit den hier gesammelten Infos nur durch weiteres Googeln genauer abgeglichen werden. Zur Validierung von E-Mail-Adressen ist das Verfahren aus den oben genannten Gründen somit nur begrenzt geeignet und wäre mit einem Webdienst wie verify-email.org [3] wesentlich schneller gegangen. Im Prinzip lässt sich so eigentlich nur ermitteln, ob zum Zeitpunkt der Abfrage der Mailserver bereit oder in der Lage ist, den Mailversand zu einer bestimmten E-Mail-Adresse durchzuführen. Das kann für die Fehlerdiagnose bei Versandproblemen durch das Mailprogramm sehr hilfreich sein, indem man seinen eigenen oder den Mailserver des Providers testet und dessen Funktionsweise direkt in einer seiner Protokollsprachen SMTP, POP3 oder IMAP überprüft, aber auch zum Testen der eigenen Spamfilter.

Bonuslevel: Eine E-Mail über Telnet versenden

Eine E-Mail über Telnet zu versenden ist zwar etwas komplizierter, kann sich aber zum Testen durchaus lohnen [4]. Als Beispiel dient hier der Maildienst von Google, wobei andere E-Mail-Dienst-Anbieter ähnlich funktionieren sollten.

Das SMTP-Protokoll wurde aufgrund der zunehmenden Spamproblematik um Verfahren zur Authentifizierung und Verschlüsselung erweitert [5]. Um eine E-Mail zu verschicken, muss man häufig diese Erweiterungen des Mailservers nutzen. Welche aktiv sind, findet man mit dem Befehl EHLO heraus, der für „Enhanced HELO“ steht:

$ telnet smtp.googlemail.com 25 
Trying 74.125.39.16... 
Connected to googlemail-smtp.l.google.com. 
Escape character is '^]'. 
220 mx.google.com ESMTP d1sm327505fai.4 
helo hi 
250 mx.google.com at your service 
ehlo hi 
250-mx.google.com at your service, [89.182.218.152] 
250-SIZE 35882577 
250-8BITMIME 
250-STARTTLS 
250 ENHANCEDSTATUSCODES

Wie man an dem Beispiel gut sehen kann, schweigt sich der Befehl HELO darüber aus, welche Fähigkeiten der Server bei Verschlüsselung, Authentifizierung und so weiter besitzt. Die bekommt man nur als Antwort auf EHLO. Die Ausgabe von STARTTLS zeigt zum Beispiel, dass der Server Verschlüsselung unterstützt.

Codiertes Login

Aufgrund des vermehrten Spamaufkommens verlangen Mailserver heutzutage eine Authentifizierung. Zur Vorbereitung der Authentifizierung und weil man gleich sowieso eine verschlüsselte Verbindung über openssl aufbauen muss, verlässt man den Server jetzt mit dem Befehl QUIT.

Die Authentifizierung findet in einer Base64-Kodierung statt. Dazu gibt man im Terminal den Befehl base64 ein und drückt „Enter“. Anschließend folgt der Anmeldename, wieder gefolgt von „Enter“. Um die Eingabe zu beenden, drückt man die Tasten „Strg“ + „D“ und erhält in etwa folgendes Ergebnis:

$ base64 
test.user@gmail.com 
dGVzdC51c2VyQGdtYWlsLmNvbQo=

Das Passwort wird genauso mit Base64 kodiert. Wenn das erledigt ist, baut man die verschlüsselte Verbindung zum Mailserver mit openssl auf:

$ openssl s_client -starttls smtp -crlf -connect smtp.googlemail.com:25

Es folgt eine wirklich lange Ausgabe im Terminal, in der man unter anderem sehen kann, dass Zertifikate ausgetauscht werden. Wenn diese erste Hürde überwunden ist, begrüßt man den Server wieder mit EHLO:

ehlo hi 
250-mx.google.com at your service, [89.182.218.152] 
250-SIZE 35882577 
250-8BITMIME 
250-AUTH LOGIN PLAIN XOAUTH 
250 ENHANCEDSTATUSCODES

Nach der Begrüßung folgt das Login mit dem Befehl AUTH LOGIN und dem Base64-kodierten Benutzernamen gleich dahinter:

auth login dGVzdC51c2VyQGdtYWlsLmNvbQo=
334 UGFzc3dvcmQ6

Der Statuscode 3 zeigt an, dass der Server noch weitere Infos benötigt. Die Beschreibung, die einen darauf hinweisen soll, was genau noch fehlt, ist übrigens auch Base64-kodiert:

$ base64 -d 
UGFzc3dvcmQ6 
Password:

Das heißt, man soll das Passwort eingeben, natürlich Base64-kodiert:

RGFzaXN0R2VoZWltCg==
235 2.7.0 Accepted

Sender und Empfänger

Nach der Eingabe des Base64-kodierten Passworts wird die E-Mail geschrieben. Mit den Befehlen MAIL FROM und RCPT TO werden Sender und Empfänger der E-Mail festgehalten:

mail from: <test.user@gmail.com > 
250 2.1.0 OK l22sm324987fam.37 
rcpt to: <empfaenger@beispiel.net> 
250 2.1.5 OK l22sm324987fam.37

Wichtig ist, dass die E-Mail-Adressen in spitzen Klammern stehen. Man kann RCPT TO auch mehrmals benutzen, wenn man die E-Mail an weitere Empfänger versenden möchte.

Der Befehl DATA gibt an, dass jetzt die E-Mail folgt. Zu Beginn gibt man der E-Mail beliebige Kopfzeilen mit, wobei Absender, Empfänger und Betreffzeile hier am sinnvollsten sind. Welche Adressen man in den Kopfzeilen einträgt, ist egal, es können ganz andere sein, als die, die in den Befehlen MAIL FROM und RCPT TO weiter oben eingetragen wurden. So einfach kann man Absender fälschen.

data 
354  Go ahead l22sm324987fam.37 
From : Test <test.user@gmail.com>
To: Empfaenger <empfaenger@beispiel.net>
Subject: Hier kommt eine Testmail 
 
Hallo Empfaenger,
hier kommt eine Testmail. 
Viele Gruesse.

Wenn der Text fertig ist, beendet man den Befehl DATA mit einem einzelnen Punkt in einer separaten Zeile. Nach der Bestätigung der Eingabe durch den Mailserver ist die E-Mail verschickt und man verlässt Telnet wieder über den Befehl QUIT.

Links
[1] http://de.wikipedia.org/wiki/Telnet
[2] http://www.youtube.com/watch?v=anwy2MPT5RE
[3] http://wiki.ubuntuusers.de/Mailserver_testen
[4] http://www.linux-magazin.de/Heft-Abo/Ausgaben/2002/04/Transport-Sicherung