Was ist SMTP-Authentifizierung? Sichere E-Mails gegen Spam

Wenn man Drohbriefe oder unerwünschte Reklame per Post versenden will, ohne Konsequenzen befürchten zu müssen, braucht man lediglich eine falsche Absenderadresse auf den Umschlag zu schreiben. Dasselbe funktioniert im übertragenden Sinne auch mit E-Mails. So gut offenbar, dass laut einer Kaspersky-Lab-Studie 58,31 Prozent aller weltweit verschickten E-Mails Spam-Nachrichten sind – ein Wert, der zwischen den Jahren 2015 und 2016 um ca. 3 Prozentpunkte zugelegt hat. Der Großteil davon stammt von mit Malware infizierten Rechnern und Servern, die als zweckentfremdete Spam-Verteiler schnell auf den Blacklists großer Provider landen. SMTP-Authentifizierung bietet ein absolutes Minimum an Sicherheit, damit Ihnen nicht dasselbe passiert.

SMTP Authentication, oft mit SMTP-Auth oder ASMTP abgekürzt, ist eine Erweiterung des Extended SMTP (ESMTP), das wiederum eine Erweiterung des Netzwerkprotokolls SMTP darstellt. Mit ihr kann sich ein SMTP-Client (also ein E-Mail-Absender) über einen Authentifizierungsmechanismus bei einem SMTP-Server (also einem E-Mail-Provider) anmelden. Auf diese Weise können nur noch vertrauenswürdige Nutzer E-Mails über den Server ins Netzwerk einspeisen und weiterleiten. Darüber hinaus kann anhand der Log-Daten nachvollzogen werden, wer den Server als Mail-Relay verwendet hat.

Sinn hinter SMTP-Auth ist es, zu verhindern, dass ein SMTP-Server als „Offenes Mail-Relay“ missbraucht wird, um Spam im Netzwerk zu verteilen. Die Notwendigkeit dieses Verfahrens ist in den inhärenten Eigenschaften des ursprünglichen SMTP von 1982 begründet, das standardmäßig keine Authentifizierung von Nutzern vorsah. Aus diesem Grund waren Offene Mail-Relays bis etwa 1997 die Norm – also Mail-Server, die jede E-Mail weiterleiten, egal, von welcher Absenderadresse und an welche Empfängeradresse. Was aus heutiger Sicht absurd erscheint, hatte damals gute Gründe: Systemfehler und Serverausfälle traten häufiger auf, weshalb Offene Mail-Relays im Notfall den Traffic aufrechterhalten sollten.

Aus der weiten Verbreitung solch ungeschützter Relays erwuchs jedoch das Problem der Spam-Flut. Moralisch fragwürdige Werbetreibende wie auch böswillige Kriminelle (allen voran der berüchtigte „Spam-King“ Sanford „Spamford“ Wallace mit seiner Firma Cyberpromo) nutzten die offenen Server mittels gestohlener oder erfundener E-Mail-Adressen, um Spam zu verteilen (diese Praktik nennt sich „Mail-Spoofing“).

Da die Server seinerzeit nicht über zusätzliche Authentifizierungsmechanismen verfügten, nahmen sie die Spam-Mails anstandslos entgegen und speisten sie in das Netzwerk ein. Durch die Nutzung fremder Hardware sparten die Spammer zugleich eigene Ressourcen und konnten zudem nicht zurückverfolgt werden. Weiterhin ermöglichte es der ständige Wechsel der Fake-Adressen, Spamfilter zu umgehen. Verschiedene Gegenmaßnahmen wurden entwickelt, um das Problem der Offenen Mail-Relays zu lösen – zuerst SMTP-After-POP, 1995 dann ESMTP und ASMTP. Mit Erfolg: Die Anzahl Offener Mail-Relays schrumpfte bis 2005/06 von mehreren Hunderttausend auf einen verschwindend geringen Bruchteil zusammen.

Zwar ist die Situation heute längst nicht mehr so kritisch wie damals, trotzdem machen Spammer laut der internationalen Non-Profit-Organisation Spamhaus immer noch 10 bis 20 neue offene Server pro Tag im Netzwerk ausfindig. Manchmal sind sie das Ergebnis der Leichtsinnigkeit unerfahrener Administratoren, die ihren Server zu Testzwecken vorübergehend öffnen. Häufiger liegt das Problem laut Spamhaus aber bei schlecht konfigurierten oder gecrackten Firewalls und externen Sicherheitsapplikationen – also nicht unbedingt bei der Serverkonfiguration an sich, wie es oft bei kleinen regionalen Firmen der Fall ist. Lässt eine Applikation eine Spam-Mail durch, wird diese nämlich über eine lokale SMTP-Verbindung mit der IP-Adresse der jeweiligen Applikation an den Server weitergereicht, der sie dann als vertrauenswürdig behandelt. Zudem nutzen immer mehr Spammer Botnetze aus „zombifizierten“ Heimcomputern als Relays.

Nun ist es so, dass für Spam instrumentalisierte Offene Mail-Relays in der Regel schon nach wenigen Tagen oder sogar Stunden als solche identifiziert werden und anschließend auf sogenannten Blacklists landen. Das hat zur Folge, dass selbst legitime E-Mails im Spamfilter des Empfängers landen, sodass sich der Betreiber eines Mailservers erst um die Schließung der Sicherheitslücke kümmern und dann um die Löschung von der Liste bemühen muss, um wieder normal operieren zu können. Unternehmen entsteht durch Spammer also nicht nur hoher Traffic zulasten ihrer Hardware-Geschwindigkeit; ihre angeschlagene Reputation und der zusätzliche Zeitaufwand kosten auch bares Geld.

Genau aus diesem Grund verwenden nahezu alle Mailserver heutzutage ESMTP in Verbindung mit ASMTP. Sie verlangen also im Vorfeld der Nutzung ihrer E-Mail-Dienstleistung immer eine Authentifizierung. Als optimal konfiguriertes SMTP-Relay (auch „Smart Host“ genannt) gilt dabei ein Server, der nur dann E-Mails von Absendern an Dritte weiterleitet, wenn er für beide Parteien zuständig ist. Im Klartext: Ankommende Mails gehen nur an registrierte Benutzer, und ausgehende Mails stammen ausschließlich von registrierten Benutzern bzw. solchen, die zur Nutzung des Mailservers autorisiert sind.

Eine wesentliche Eigenschaft von ASMTP besteht darin, dass E-Mails anstatt über den traditionellen Port 25/TCP über Port 587/TCP (den SMTP-Auth-Port) angenommen werden, der für ESMTP die obligatorische Grundlage darstellt. Das Protokoll enthält im Grunde eine Auswahl an Authentifizierungsmechanismen mit verschiedenen Sicherheitsgraden, die ein SMTP-Server je nach seiner Konfiguration nutzen kann, um die Vertrauenswürdigkeit eines SMTP-Client zu überprüfen.

Dazu gehören u. a.:

• PLAIN: Eine Authentifizierung über den Benutzernamen und das Passwort des Clients. Beide werden unverschlüsselt übertragen und im Base64-Zeichensatz codiert.
• LOGIN: Funktioniert wie PLAIN, jedoch werden die Base64-Codes für Benutzernamen und Passwort in zwei Schritten statt nur in einem übertragen.
• CRAM-MD5: Eine Alternative zu PLAIN und LOGIN mit höherem Sicherheitsgrad nach dem Challenge-Response-Prinzip. Da Spammer die persönlichen Zugangsdaten eines Nutzers relativ schnell aus dem Base64-Code dekodieren können, wird das Passwort bei diesem Mechanismus weder im Klartext noch im Code auf den Server übertragen. Stattdessen stellt der Server dem Client eine Art Rechenaufgabe, die nur mithilfe des Passworts gelöst werden kann. Diese Aufgabe ändert sich bei jeder Anmeldung, sodass Spammer die Daten vorangegangener Serververbindungen nicht missbrauchen können.
• Weitere angebotene Mechanismen sind z. B. GSSAPI, DIGEST-MD5, MD5, OAUTH10A, OAUTHEBEARER, SCRAM-SHA-1 und NTLM.

Ein Beispiel für eine Authentifizierung via LOGIN:

Ergänzend folgt hier eine Anleitung für Outlook:

1. Klicken Sie im Dateimenü auf „Kontoeinstellungen“.
2. Wählen Sie Ihr Konto aus und klicken Sie auf „Ändern“.
3. Klicken Sie im sich öffnenden Fenster auf „Weitere Einstellungen“.
4. Gehen Sie in die Registerkarte „Postausgangsserver“ und aktivieren Sie die Option „Postausgangsserver (SMTP) erfordert Authentifizierung“.
5. Markieren Sie den Punkt „Gleiche Einstellungen wie für Posteingangsserver verwenden“.
6. Bestätigen Sie mit „OK“. Das Fenster schließt sich wieder.
7. Klicken Sie auf „Weiter“. Outlook überprüft nun die neuen Kontoeinstellungen. Nach abgeschlossenem Test klicken Sie auf „Schließen“.
8. Klicken Sie auf „Fertig stellen“ und dann auf „Schließen“.

Um zu überprüfen, ob ein Mailserver als Offenes Relay herhält bzw. SMTP-Auth einwandfrei funktioniert (etwa, wenn Sie einen eigenen Mailserver einrichten), können Sie den Telnet-Client verwenden. Diesen nutzen auch einige Spammer, um Offene Mail-Relays in Handarbeit ausfindig zu machen. SMTP und ESMTP sind nämlich rein textbasierte Protokolle, weshalb Sie eine Client-Server-Session auch manuell starten und durchführen können. Sie benötigen dazu lediglich Ihren Benutzernamen und Ihr Passwort im Base64-Code, den Sie auf Webseiten wie base64encode.net erhalten können.

Der SMTP-Auth-Test läuft wie folgt ab:

1. Versuchen Sie, mit dem Kommando „telnet smtp.beispiel.com 25“ eine Verbindung zum SMTP-Server über Port 25/TCP herzustellen (ersetzen Sie „smtp.beispiel.com“ mit der Domain Ihres Mailservers).
2. Der Server sollte mit dem Statuscode „220 smtp.beispiel.com ESMTP Postfix“ antworten und die Session beginnen.
3. Grüßen Sie den Server mit „EHLO smtp.beispiel.com“.
4. Der Server wird gemäß dem Beispiel weiter oben eine Auswahl an Authentifizierungsmechanismen anbieten. Wählen Sie z. B. LOGIN, indem Sie das Kommando „AUTH LOGIN“ eingeben.
5. Nun folgt der eigentliche Test: Geben Sie nach den Kommandos „MAIL FROM“ und „RCPT TO“ jeweils eine ausgedachte, also nicht existente Absender- und Empfängeradresse ein. Antwortet der Server mit einer Fehlermeldung, ist ASMTP korrekt konfiguriert und Ihr Server somit kein Offenes Mail-Relay. Bestätigt er stattdessen beide Kommandos mit „250 OK“, besteht Nachbesserungsbedarf.

Alternativ können Sie den SMTP-Auth-Test mithilfe externer Tools wie dem der Firma MxToolbox, Inc. durchführen. Selbige bietet auch eine Auswahl von Blacklists an, die Sie im Verdachtsfall überprüfen können.