
Abbildung 1: Swaks schlüpft in die Rolle eines SMTP-Clients und checkt den Server auf valides Verhalten.
Fehler im Dunstkreis eines SMTP-Servers per Telnet und Testmails suchen – das kann zu einem nervenzehrenden Hindernislauf ausarten. Das Tool Swaks bringt die Ziellinie wieder in Sichtweite.
Dass SMTP ein Klartextprotokoll ist, erweist sich für die Fehlersuche an Mailservern als vorteilhaft. Ich kann mich einfach per Telnet auf Port 25 verbinden und wie ein Mailclient benehmen. An den Antworten des Servers sehe ich schnell, wo es hakt. So weit die Theorie. Die Praxis, man ahnt es, läuft meist weniger geradlinig. Denn SMTP hat mit den Jahren Fett angesetzt, auch wegen dringend benötigter Sicherheitsfunktionen. Während ich die Basiskommandos wie »HELO FQDN« oder »RCPT« noch flott tippe, hört spätestens beim Authentisieren per CRAM-SHA-1 für mich der “Klartext” und damit der Spaß auf.
Seit Swaks [1] geht mir die Mailserver-Diagnose wieder leicht von der Hand. Richtig parametrisiert führt das Werkzeug die zur Diagnose notwendigen SMTP-Dialoge selbstständig aus. Eine einfache Testmail versende ich mit dem Kommando:
swaks --from=charly@kuehnast.com --to=charly@example.com --server=mail.example.com
Ist der Test erfolgreich, erhält »charly@example.com« eine Mail. Ich kann jeden Schritt des SMTP-Dialogs in der Konsole mitlesen und bekomme Fehlermeldungen auf dem Silbertablett präsentiert.
Ein etwas umfangreicheres Beispiel zeigt Abbildung 1. Hier findet Swaks unter anderem heraus, dass der Mailserver TLS unterstützt. Dazu habe ich »-tls« angegeben (Achtung: mit nur einem Bindestrich, nicht mit zweien). Wäre der Server nicht TLS-fähig gewesen, hätte ich die Meldung »*** Host did not advertise STARTTLS« erhalten und Swaks hätte den SMTP-Dialog beendet.
Zudem demonstriert das Beispiel die SMTP-Plain-Authentisierung. In der Praxis nimmt man natürlich ein sicheres Verfahren, denn Plain verschlüsselt den Usernamen und das Passwort nicht – den vermeintlich kryptischen Buchstabensalat richtet die Base64-Kodierung der Daten an. Swake teile ich mit »–auth« mit, dass ich ein Authensierungsverfahren nutzen möchte, und übergebe mit
--auth-user=testuser --auth-password=testpass
meine Login-Daten. Swaks und der Mailserver handeln dann das Verfahren mit dem höchsten Sicherheitsniveau miteinander aus, das beide beherrschen.

Abbildung 1: Swaks schlüpft in die Rolle eines SMTP-Clients und checkt den Server auf valides Verhalten.
Was gegen Verstopfung
Wenn ich bei der Fehlersuche ein Dutzend oder mehr Testmails versende, finde ich es ziemlich lästig, dass diese Mails oder ihre Bounces meinen Posteingang verstopfen. Swaks bietet daher eine Möglichkeit, den SMTP-Dialog an einer beliebigen Stelle abzubrechen. In Beispiel habe ich »-q RCPT« angegeben, weshalb Swaks den Dialog beendet, nachdem es dem Server die Empfängeradressen übergeben und die Antwort empfangen hat:
RCPT TO:<charly@kuehnast.com> 250 2.1.5 Ok QUIT
»HELO« -String, TLS und die Authentisierung sind überstanden, die Absender- und Empfängeradresse hat der Server mit »Ok« auch quittiert. Das Studium der Manpage lohnt, denn Swaks leistet mehr, als meine Kurzvorstellung würdigen kann. Beispielsweise kommt das Tool seit Frühjahr 2012 mit IPv6 klar. (jk)
Infos





