Mailserver testen
Dieser Artikel wurde für die folgenden Ubuntu-Versionen getestet:
Dieser Artikel ist größtenteils für alle Ubuntu-Versionen gültig.
Artikel für fortgeschrittene Anwender
Dieser Artikel erfordert mehr Erfahrung im Umgang mit Linux und ist daher nur für fortgeschrittene Benutzer gedacht.
Zum Verständnis dieses Artikels sind folgende Seiten hilfreich:
Dieser Artikel handelt davon, wie man mit Hilfe des telnet-Clients verschiedene Eigenschaften von Mailservern auf der Kommandozeile testen kann[2]. Dies kann nützlich sein, wenn man einen eigenen Server aufsetzt und dessen Funktionsweise überprüfen will, aber auch um bspw. die Fähigkeiten vom Mailserver des Providers zu ermitteln oder zur Fehlerdiagnose. Hierbei wird mit dem Server direkt in seiner Protokollsprache kommuniziert, wobei die drei gängigen Mail-Protokolle verwendet werden: SMTP, POP3 und IMAP. Welches Protokoll für welchen Zweck geeignet ist, ist nicht Gegenstand dieses Artikels. Dies wird als Vorwissen vorausgesetzt (und kann z.B. in der Wikipedia unter den o.a. Links nachgelesen werden).
Grundlagen¶
Das Programm telnet ist bei Ubuntu standardmäßig installiert. Sollte das aus irgendwelchen Gründen nicht der Fall sein, muss folgendes Paket installiert werden[1]:
telnet
Jeder andere Telnet-Client funktioniert natürlich auch.
Möchte man die erwähnte Methode mit openssl ausprobieren, um auch verschlüsselt mit den Servern kommunizieren zu können, so muss auch noch folgendes Paket installiert werden[1]:
openssl
Eigentlich ist Telnet in der Vergangenheit eine unverschlüsselte und deswegen völlig unsichere Möglichkeit gewesen, Rechner aus der Ferne zu administrieren. Das Protokoll wurde aber inzwischen nahezu vollständig vom in jeder Hinsicht überlegenen SSH verdrängt. Man kann mit dem Telnet-Client aber nicht nur mit Telnet-Servern kommunizieren, sondern auch mit nahezu jedem anderen Server, der ein textbasiertes Protokoll spricht, indem man sich einfach mit dem entsprechenden Port verbindet. Diese Eigenschaft wird hier genutzt.
Das funktioniert einfach so (Beispiel):
$ telnet mail.gmx.de 25
Trying 213.165.64.20...
Connected to mail.gmx.net.
Escape character is '^]'.
220 mail.gmx.net GMX Mailservices ESMTP {mp020} In diesem Beispiel wurde mit dem SMTP-Port 25 des Servers mail.gmx.de verbunden, der dann auch sofort mit einer Statusmeldung antwortet und auf weitere Befehle wartet. Diese Befehle unterscheiden sich natürlich je nach Protokoll.
SMTP (Port 25)¶
Das Simple Mail Transfer Protocol (SMTP) besteht aus nacheinander ausgeführten Befehlen, die vom Server jeweils mit einem Statuscode beantwortet werden. Nach dem Statuscode folgt immer auch eine menschenlesbare Beschreibung, die aber für das Protokoll irrelevant ist. Statuscodes, die mit einer 2 beginnen, signalisieren einen Erfolg der Aktion, eine 3 bedeutet, dass noch Informationen fehlen, eine 5 bezeichnet einen Fehler. Werden Statuscode und Beschreibung durch ein Minuszeichen verbunden, so bedeutet das, dass die Ausgabe des Servers noch nicht zu Ende ist. Folgt auf den Code dagegen ein Leerzeichen, so wartet der Server auf den nächsten Befehl.
Begrüßung¶
Als erstes erwartet der Server, dass man ihn mit einem anständigen HELO begrüßt. Als Argument sollte man eigentlich den eigenen Rechnernamen angeben. In den allermeisten Fällen ist es aber völlig egal, was für eine Zeichenkette man verwendet. Evtl. erzeugt ein ungültiger HELO-Name einen leicht erhöhten Wert im Spamfilter des Empfängers.
helo test
250 mail.gmx.net GMX Mailservices {mp053} EHLO¶
Das SMTP-Protokoll wurde mit der Zeit erweitert, da es in seiner ursprünglichen Form (zu einer Zeit, als es noch keinen Spam gab) u.a. weder Authentifizierung noch Verschlüsselung besaß. Möchte man diese Erweiterungen nutzen, so muss man sich statt mit HELO mit dem Befehl EHLO (Abk. für Enhanced HELO) anmelden.
Sitzung beenden¶
Eine SMTP-Sitzung beendet man mit dem einfachen Befehl QUIT.
quit
221 2.0.0 GMX Mailservices {mp006}
Connection closed by foreign host. Server-Fähigkeiten¶
Die Fähigkeiten des Servers, was Verschlüsselung, Authentifizierung etc. angeht, werden als Antwort auf den EHLO-Befehl gesendet. Der HELO-Befehl gibt sich dagegen schweigsam.
Verschlüsselung¶
Wenn in der EHLO-Ausgabe das Schlüsselwort STARTTLS auftaucht, unterstützt der Server die Verschlüsselung. Testen kann man das allerdings über Telnet nicht, da der Server nach Eingabe dieses Befehls nur noch verschlüsselte Daten akzeptiert und jegliche Klartextbefehle mit einer Unterbrechung der Verbindung quittiert.
Zum Testen der verschlüsselten Kommunikation kann man stattdessen openssl benutzen. Ein c't Artikel, der die Vorgehensweise beschreibt, ist unten verlinkt.
Authentifizierung¶
Das normale SMTP-Protokoll ohne ESMTP-Erweiterung unterstützt überhaupt keine Authentifizierung. Heutzutage ist das auf Grund der Spamproblematik leider meistens nicht mehr tragbar. Eine Ausnahme gestattet in der Regel nur der eigene Internet-Zugangsprovider, der einen ja bei Missbrauch jederzeit über die IP-Adresse identifizieren kann.
Zwei SASL-Mechanismen eignen sich zum testen, LOGIN und PLAIN. Wie man die notwendigen Base64-Codierungen vornimmt, steht weiter unten im Abschnitt SASL.
LOGIN¶
Für die LOGIN-Authentifizierung sendet man den Befehl auth login mit dem base64-codierten Benutzernamen an den Server. Dieser antwortet mit einer kryptischen Zeichenkette, die die Base64-Entsprechung des Wortes "Password:" ist. Man muss mit dem base64-codierten Passwort antworten:
auth login YmVudXR6ZXJuYW1l # "benutzername" base64-codiert
334 UGFzc3dvcmQ6
cGFzc3dvcnQ= # "passwort" base64-codiert
235 2.7.0 Go ahead {mp030} Der 2xx-Statuscode zeigt den Erfolg an.
PLAIN¶
Bei der PLAIN-Authentifizierung muss nur eine Zeichenkette übertragen werden. Zur Zusammensetzung derselben s.u.:
auth plain YmVudXR6ZXJuYW1lAGJlbnV0emVybmFtZQBwYXNzd29ydA==
235 2.7.0 Go ahead {mp031} Mails verschicken¶
Hat man sich erstmal authentifiziert (oder braucht man das nicht, weil man einen Mailserver im eigenen Heimnetz oder den des Zugangsproviders verwendet), so kann man anfangen, Emails zu versenden. Dafür benötigt man der Reihe nach die drei Befehle MAIL FROM:, RCPT TO: und DATA. Die ersten beiden erwarten jeweils eine Email-Adresse, die in spitze Klammern eingeschlossen werden muss. Es sind mehrere RCPT TO:-Befehle möglich, um die Mail an mehrere Empfänger zu versenden. Ein Beispiel:
mail from: <abc@example.com> 250 2.1.0 Ok rcpt to: <mail@example.net> 250 2.1.5 Ok rcpt to: <irgendwer@example.org> 250 2.1.5 Ok data 354 End data with <CR><LF>.<CR><LF> From: Test <abc@example.com> To: xyz <xyz@example.com> Subject: Test test . 250 2.0.0 Ok: queued as 8EA2D30AC20
Der DATA-Block endet mit einem einzelnen Punkt in einer eigenen Zeile. Am Anfang des DATA-Blocks kann man der Mail noch beliebige Kopfzeilen mit auf den Weg geben. From, To und Subject sind z.B. sinnvoll.
Hinweis:
Die Mail-Adressen, die man in diese Kopfzeilen einträgt, sind völlig unabhängig von den eigentlichen Absendern und Empfängern, die man per MAIL FROM: und RCPT TO: eingetragen hat! So einfach ist Adressfälschen. 😉
Wenn alles funktioniert, kann man sich auf diese Art eine Testmail schicken.
POP3 (Port 110)¶
Auch beim Post Office Protocol Version 3 (POP3) werden die Befehle einfach in das Terminal getippt. Im Gegensatz zu SMTP kennt POP3 keine "Begrüßungsformel", sondern man kann gleich mit seinem Anliegen loslegen.
$ telnet pop.gmx.de 110 Trying 213.165.64.22... Connected to pop.gmx.net. Escape character is '^]'. +OK GMX POP3 StreamProxy ready <25552.1196273073@mp045>
Ein POP3-Server beantwortet jeden Befehl mit einem der beiden Codes +OK und -ERR, an denen man erkennen kann, ob der Befehl erfolgreich war. Der Rest der Zeile ist wiederum nur ein für Menschen interessanter Kommentar ohne protokollbezogene Relevanz.
Möchte der Server weitere Daten ausgeben, z.B. eine Liste vorhandener Mails oder eine bestimmte Mail selber, so schreibt er diese einfach anschließend hinaus. Das Ende der Serverausgabe wird dabei durch einen einzelnen Punkt auf einer eigenen Zeile gekennzeichnet.
Sitzung beenden¶
Auch bei POP3 lautet der Befehl zum Beenden der Sitzung QUIT.
quit +OK GMX POP3 server signing off Connection closed by foreign host.
Fähigkeiten¶
Eine Liste der Fähigkeiten des Servers erhält man mit dem Befehl CAPA (für capabilities):
capa +OK STLS TOP USER SASL LOGIN CRAM-MD5 UIDL RESP-CODES .
Die Fähigkeit zu APOP (s.u.) erkennt man bereits am APOP-Zeitstempel in der Begrüßung. (Steht in spitzen Klammern und sieht z.B. so aus: <622.1205709759@mp050>)
Verschlüsselung¶
Der Befehl zur Verschlüsselung der Sitzung heißt STLS, kann aber aus den im Abschnitt SMTP angegebenen Gründen nur schwerlich via Telnet getestet werden (abgesehen davon, dass man überprüfen kann, ob der Server danach wirklich keine unverschlüsselten Befehle mehr akzeptiert).
Auch hier hilft openssl. Ein c't Artikel, der die Vorgehensweise beschreibt, ist unten verlinkt.
Authentifizierung¶
Es gibt mehrere Authentifizierungsvarianten bei POP3. Die einfachste ist die normale über Benutzername und Passwort. Wenn die Verbindung als ganzes aber nicht verschlüsselt ist, können Lauscher das Passwort abfangen. Deswegen wurde das sichere APOP-Verfahren erfunden. Viele POP3-Server und -Clients unterstützen inzwischen auch SASL.
USER¶
Bei der USER-Methode werden einfach nacheinander ein USER- und ein PASS-Befehl eingesetzt, z.B. so:
$ telnet pop.gmx.de 110 Trying 213.165.64.22... Connected to pop.gmx.net. Escape character is '^]'. +OK GMX POP3 StreamProxy ready <19622.1205709759@mp050> user beispiel@gmx.de +OK May I have your password, please? pass gEhEiM! +OK Mailbox locked and ready
APOP¶
Beim APOP-Verfahren wird der Zeitstempel mit dem Passwort verknüpft und ein MD5-Hash daraus gebildet. Dieser wird an Stelle des Passworts übertragen. Um den Hash zu errechnen, öffnet man am besten ein zweites Terminal, benutzt den folgenden Befehl und nutzt dann die Zwischenablage, um den Hash in die POP3-Sitzung einzufügen:
$ echo -n '<19622.1205709759@mp050>gEhEiM!' | md5sum - 20376e3ca8d030b31e1fda962a4dfcfb -
Das Passwort wird direkt ohne Leerzeichen an den Zeitstempel (inkl. spitzen Klammern) angehängt. Außerdem ist das -n wichtig, damit der echo-Befehl keinen verfälschenden Zeilenendecode einfügt und die Zeichenkette in einfache Anführungszeichen gesetzt wird.
Der eigentliche APOP-Befehl verlangt zwei Argumente, nämlich den Benutzernamen und den Hash:
apop loginname 20376e3ca8d030b31e1fda962a4dfcfb +OK Mailbox locked and ready
SASL¶
Eine SASL-Authentifizierungsmethode (#sasl s.u.) wird durch den AUTH-Befehl eingeleitet. Hier eine Beispielauthentifizierung mit der LOGIN-Methode:
auth login # LOGIN-Methode einleiten + VXNlcm5hbWU6 # "Username:" in Base64 YmVudXR6ZXJuYW1l # Base64-kodierter Benutzername + UGFzc3dvcmQ6 # "Password:" in Base64 cGFzc3dvcnQ= # Base64-kodiertes Passwort +OK Mailbox locked and ready
Mails abrufen¶
Email direkt über POP3 lesen ist nicht besonders komfortabel und deswegen wenig sinnvoll. Deswegen hier nur eine kurze tabellarische Aufstellung der wichtigsten Befehle:
| Befehl | Serverantwort |
| Anzahl der Mails und Auslastung der Mailbox in Bytes |
| Liste der vorhandenen Mails, jeweils Nummer und Größe der Nachricht |
| Vollständige Mail mit der betreffenden Nummer |
| Nur Beginn der Mail nr. Vollständiger Header plus zahl Zeilen des eigentlichen Inhalts |
| Markiert die betreffende Mail auf dem Server als gelöscht |
IMAP (Port 143)¶
Das Internet Message Access Protocol (IMAP) unterscheidet sich etwas von den anderen beiden, weil man vor jeden Befehl noch eine Zeilennummer setzen muss. Ohne Zeilennummer quittiert der Server jeden Befehl mit einer Fehlermeldung (tatsächlich kann man als Zeilennummer eine beliebige Zeichenfolge eintragen, und diese muss auch nicht eindeutig sein). Die Antwort des Servers beginnt dann stets mit derselben Nummer, gefolgt von einem einzelnen Schlüsselwort über den Erfolg des Befehls (OK, BAD, NO, etc.) und dem obligatorischen Kommentar. Bei inhaltlichen Antworten, z.B. Listen, beginnt jede Zeile mit einem * und dem Namen des Befehls. Anders als bei POP3 wird die Statusmeldung erst am Ende gesendet und zeigt dieses Ende gleichzeitig an.
$ telnet imap.gmx.de 143 Trying 213.165.64.23... Connected to imap.gmx.net. Escape character is '^]'. * OK GMX IMAP4 StreamProxy ready.
Sitzung beenden¶
Der Befehl zum Beenden einer IMAP-Sitzung heißt LOGOUT.
logout logout BAD unable to parse command # Zeilennummer vergessen ;) 02 logout * BYE GMX IMAP4 StreamProxy terminating connection 02 OK LOGOUT completed
Fähigkeiten¶
Eine Auflistung verschiedener Fähigkeiten des Servers liefert der Befehl CAPABILITY. U.a. kann man so in Erfahrung bringen, ob der Server TLS-Verschlüsselung unterstützt (STARTTLS) oder SASL-Authentifizierung (AUTH=Methode):
aa capability # "a" ist die Zeilennummer * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ MAILBOX-REFERRALS NAMESPACE UIDPLUS ID NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND SORT THREAD=ORDEREDSUBJECT THREAD=REFERENCES IDLE STARTTLS AUTH=NTLM AUTH=DIGEST-MD5 AUTH=CRAM-MD5 ANNOTATEMORE aa OK Completed
Verschlüsselung¶
Die Verschlüsselung lässt sich über den STARTTLS-Befehl aktivieren, aber nicht per Telnet ausprobieren:
bb starttls bb OK Begin TLS negotiation now tls-test test bb NO Starttls negotiation failed * BAD Invalid tag
Zum Testen der verschlüsselten Kommunikation kann man stattdessen openssl benutzen. Ein c't Artikel, der die Vorgehensweise beschreibt, ist unten verlinkt.
Authentifizierung¶
Unverschlüsselt¶
Die einfachste, aber unsichere Methode sich zu authentifizieren, ist die LOGIN-Methode. Dem LOGIN-Befehl werden einfach Benutzername und Passwort als Argumente übergeben:
cc login name gEhEiM! cc OK User logged in
SASL¶
Sicherer ist die Authentifizierung über kryptografische SASL-Methoden wie Digest-MD5 oder Cram-MD5. Es gibt aber auch unverschlüsselte SASL-Verfahren wie PLAIN oder LOGIN, die zum Testen verwendet werden können. Aktiviert wird eine derartige Methode über den AUTHENTICATE-Befehl, der den Namen der Methode als Argument verlangt. Zur Zusammensetzung der SASL-Zeichenkette s.u.
bb authenticate login # SASL-Methode LOGIN + VXNlcm5hbWU6 # "Username:" base64-kodiert YmVudXR6ZXJuYW1l # benutzername -"- + UGFzc3dvcmQ6 # "Password:" -"- Z0VoRWlNIQ== # gEhEiM! -"- bb OK User logged in
Weitere Befehle¶
Das IMAP-Protokoll ist weitaus komplexer als bspw. POP3, weil es u.a. mit verschachtelten Ordnerstrukturen, verschiedenen Markierungen für Emails usw. umgehen muss. Wer sich dafür interessiert, wie man das auf Protokollebene handhabt, sollte sich den betreffenden RFC 🇬🇧 durchlesen.
SASL-Authentifizierung¶
Alle hier vorgestellten Emailprotokolle unterstützen (zumindest optional) das sogenannte Simple Authentication and Security Layer Protokoll zur Authentifizierung (was aber nicht unbedingt heißt, dass auch jeder Server es einsetzt). SASL ist ein erweiterbares Protokoll, was seinerseits verschiedene Authentifizierungsarten ermöglicht. Welche davon ein Server unterstützt, kann man durch Abfrage seiner Fähigkeiten (s.o.) herausfinden.
LOGIN¶
Beim LOGIN-Verfahren werden Benutzername und Passwort getrennt und unverschlüsselt übertragen. Um keine Probleme mit Sonderzeichen zu haben, werden die beiden Zeichenketten jedoch mit dem Base64-Verfahren codiert. Das kann man auf der Kommandozeile mit Hilfe des Perl-Interpreters simulieren:
$ perl -e 'use MIME::Base64; print encode_base64(q"benutzername");' YmVudXR6ZXJuYW1l $ perl -e 'use MIME::Base64; print encode_base64(q"passwort");' cGFzc3dvcnQ=
Diese beiden Befehle sind mit den eigenen Benutzerdaten auszuführen und die resultierenden Zeichenketten dann am besten per Zwischenablage zum geeigneten Zeitpunkt in die Mail-Sitzung einzufügen.
Achtung!
Obwohl die Base64-Zeichenketten kryptisch aussehen, stellen sie keine Verschlüsselung dar und können von jedem Lauscher z.B. mit dem decode_base64-Befehl von Perl wieder in Klartext zurückverwandelt werden.
PLAIN¶
Auch beim PLAIN-Verfahren werden die Daten nicht verschlüsselt. Statt zwei Zeichenketten hintereinander zu übertragen, werden Benutzername und Passwort aber in einer einzigen Base64-Zeichenkette kombiniert. Diese besteht aus dem doppelten Benutzernamen (wenn man mit einem master Benutzer einsteigt, ist der erste Benutzername als der man sich ausgeben möchte) und dem Passwort, jeweils getrennt durch ein Nullbyte, in Perl geschrieben so:
$ perl -e 'use MIME::Base64; print encode_base64(join "\0", qw"benutzername benutzername passwort");' YmVudXR6ZXJuYW1lAGJlbnV0emVybmFtZQBwYXNzd29ydA==
Der Login würde dann wie folgt erfolgen:
bb authenticate plain YmVudXR6ZXJuYW1lAGJlbnV0emVybmFtZQBwYXNzd29ydA== bb OK User logged in
CRAM-MD5 und andere Verfahren¶
CRAM-MD5 und DIGEST-MD5 sind dagegen Beispiele für sichere SASL-Authentifizierungsverfahren, da sie auf einem kryptografischen Challenge-Response-Verfahren beruhen. Leider sind sie deswegen auch wesentlich komplizierter "von Hand" zu erledigen, was hier deswegen nicht beschrieben wird.
Achtung!
Wer die in diesem Artikel beschriebenen Tests unbedingt über ein unsicheres Medium ausführen muss (und sich nicht z.B. per SSH einloggen und localhost testen kann) oder die Methode mit openssl anwendet, erzeugt sich am besten einen Extra-Account nur für diese Tests, der hinterher wieder deaktiviert werden kann.
Links¶
c't Artikel: E-Mail Verschlüsselung austesten 🇩🇪 - Artikel 09/2009
RFC 3501 - Internet Message Access Protocol - Version 4rev1 🇬🇧
RFC 4422 - Simple Authentication and Security Layer (SASL) 🇬🇧