Welche SMTP-Authentifizierung ist wann sinnvoll – PLAIN, LOGIN, CRAM-MD5 und OAuth2 im direkten Vergleich

Grundlagen: SMTP AUTH im Submission-Kontext, Capability-Aushandlung und Grenzen der Mechanismen

SMTP AUTH dient im Submission-Kontext primär dazu, das Einliefern von Nachrichten an einen Mail Submission Agent (MSA) kontrolliert zu erlauben. Typischerweise erfolgt Submission über Port 587 (häufig mit STARTTLS) oder über Port 465 (Implicit TLS). Das unterscheidet sich funktional von klassischem Relay/Transport zwischen MTAs, bei dem Authentifizierung meist nicht vorgesehen ist und stattdessen IP-basierte Vertrauensmodelle, mTLS oder andere Transportvereinbarungen dominieren. Für Submission gilt: Ohne klare Capability-Aushandlung und ohne abgesicherte Transportebene führt SMTP AUTH schnell zu Fehlkonfigurationen, Credential-Leaks oder unerwarteten Fallbacks.

Die Authentifizierung im SMTP-Protokoll ist als Erweiterung modelliert: Erst die vom Server beworbenen Fähigkeiten (ESMTP Capabilities) bestimmen, welche AUTH-Mechanismen überhaupt verhandelbar sind und unter welchen Bedingungen sie akzeptiert werden. Daraus folgt eine harte Grenze: Clients dürfen keine Mechanismen „erraten“, sondern müssen sich an die Serveransage halten. Umgekehrt müssen Server Betreiberziele (Kompatibilität, Richtlinien, Compliance) in Capabilities und Fehlerbehandlung so ausdrücken, dass Clients nicht auf unsichere oder unerwünschte Pfade ausweichen.

Submission-Flow: EHLO, STARTTLS, Re-EHLO und AUTH-Reihenfolge

In einer korrekten Submission-Sitzung beginnt der Client mit EHLO, um die ESMTP-Erweiterungen abzufragen. Unterstützt der Server STARTTLS, erscheint STARTTLS in der Capability-Liste. Wird TLS ausgehandelt, fordert die Spezifikation anschließend ein erneutes EHLO, da sich die Capabilities (insbesondere AUTH-Angebote) nach dem Wechsel in einen geschützten Kanal ändern können. Viele produktive Setups bewerben AUTH bewusst erst nach erfolgreichem TLS, um Klartext-Credentials und Downgrade-Effekte zu verhindern.

Die Reihenfolge ist nicht kosmetisch, sondern Sicherheitslogik: Wird AUTH vor TLS angeboten und vom Client genutzt, sind Mechanismen wie PLAIN oder LOGIN selbst bei Base64-„Verschleierung“ faktisch Klartext. Auch bei OAuth2-basierten SASL-Mechanismen reduziert TLS das Risiko von Token-Exfiltration und Session-Hijacking, da die Token als Bearer-Token gelten und bei Abfluss unmittelbar missbraucht werden können.

• Capability-Abfrage: Client sendet EHLO client.example, Server antwortet mit 250--Zeilen (z. B. 250-STARTTLS, 250-AUTH PLAIN LOGIN).
• TLS-Eskalation: Wenn STARTTLS angeboten wird, folgt STARTTLS; nach erfolgreichem Handshake muss erneut EHLO client.example folgen, bevor AUTH startet.
• Policy-Erzwingung: Server können AUTH vor TLS unterdrücken oder bei AUTH ohne TLS mit 530 5.7.0 Must issue a STARTTLS command first ablehnen.
• Abhängigkeiten: Der Wechsel in TLS kann zusätzliche Mechanismen freischalten (z. B. AUTH OAUTHBEARER nur nach TLS) oder schwache Mechanismen bewusst ausblenden.

Capability-Aushandlung: Was „AUTH“ wirklich aussagt

Die Capability AUTH ist eine Serveraussage über unterstützte SASL-Mechanismen, nicht über deren Zulässigkeit in jedem Kontext. Ein Server kann AUTH PLAIN bewerben, aber PLAIN nur innerhalb von TLS akzeptieren; oder er kann bestimmte Identitäten (z. B. Mandanten) nur mit bestimmten Mechanismen zulassen. Für Clients ergibt sich daraus: Die Mechanismen sind eine Präferenzliste, keine Garantie. Für Betreiber ergibt sich: Die Fehlermeldung und der Statuscode entscheiden, ob Clients korrekt reagieren oder in riskante Fallback-Pfade geraten.

Problematisch wird es, wenn Clients bei Fehlschlag eines Mechanismus automatisch auf einen anderen wechseln, ohne die Ursache zu prüfen. Ein Beispiel ist ein Token-basierter Mechanismus, der serverseitig abgelehnt wird (Policy), worauf der Client auf AUTH LOGIN zurückfällt und damit Passwortauthentifizierung erzwingt. Eine sichere Server-Policy kommuniziert daher möglichst eindeutig, ob ein Mechanismus „nicht unterstützt“ (504 5.5.4 Unrecognized authentication type), „derzeit nicht erlaubt“ (534/535 je nach Implementierung) oder „nur nach TLS“ (530) ist.

Grenzen der Mechanismen: PLAIN/LOGIN, CRAM-MD5 und OAuth2 in der Praxis

SASL-Mechanismen unterscheiden sich darin, ob sie das Passwort direkt übertragen, ob sie Challenge-Response nutzen oder ob sie Tokens statt Passwörtern verwenden. Für Submission ist entscheidend, wie der Mechanismus mit Transportverschlüsselung zusammenspielt und welche Angriffsklassen er offenlässt. PLAIN und LOGIN übertragen letztlich ein Shared Secret (Passwort) und sind daher ohne TLS inakzeptabel. CRAM-MD5 vermeidet zwar die Klartextübertragung des Passworts, schützt aber nicht gegen Offline-Angriffe auf schwache Passwörter und ist kryptografisch überholt; moderne Richtlinien setzen typischerweise auf TLS plus moderne Passwort-Policy oder auf OAuth2-Tokenflüsse mit klaren Scopes.

OAuth2 ist im SMTP-Kontext kein „AUTH-Mechanismus“ im OAuth-Sinne, sondern wird über SASL-Mechanismen wie XOAUTH2 (de-facto in bestimmten Ökosystemen) oder OAUTHBEARER (standardisiert) transportiert. Diese Mechanismen verlagern das Geheimnismanagement: Statt ein statisches Passwort zu speichern, verwendet der Client ein kurzlebiges Access Token. Grenzen entstehen durch Token-Lebensdauer, Clock-Skew, Scope-Fehlkonfigurationen und die Notwendigkeit eines zuverlässigen Refresh-Prozesses. Ohne TLS bleibt auch hier das Risiko bestehen, dass ein abgegriffenes Token unmittelbar wiederverwendet werden kann.

• PLAIN/LOGIN (Passwort-basiert): Übertragung von Anmeldedaten in Base64; ohne TLS praktisch Klartext. Serverseitig üblich: Bewerbung nur nach STARTTLS oder Ablehnung mit 530 5.7.0.
• CRAM-MD5 (Challenge-Response): Passwort wird nicht direkt übertragen, aber die Sicherheit hängt stark von Passwortentropie ab; MD5 ist kryptografisch veraltet. In vielen modernen Umgebungen nicht mehr aktiviert, insbesondere wenn Compliance-Vorgaben schwache Mechanismen untersagen.
• OAuth2-Token (Bearer): Mechanismen wie OAUTHBEARER oder XOAUTH2 transportieren ein Access Token; TLS bleibt erforderlich, weil ein Token bei Abfluss sofort gültig sein kann. Typische Fehlerbilder: 535 bei abgelaufenem Token oder fehlenden Scopes, implementierungsabhängige Subcodes.
• Mechanismus-Fallback als Risiko: Ein fehlgeschlagener AUTH OAUTHBEARER-Versuch darf nicht automatisch zu AUTH LOGIN führen, wenn die Organisation Passwortauthentifizierung abschalten will; Server-Policies sollten dies mit klaren Statuscodes und Capabilities steuern.

Interaktion von TLS-Handshake und AUTH-Phase: Sequenzlogik und Downgrade-Grenzen

TLS verändert im Submission-Protokoll nicht nur die Vertraulichkeit, sondern auch die Semantik der Sitzung: Nach STARTTLS gilt die vorherige Capability-Aushandlung als potenziell kompromittiert und muss erneuert werden. Diese Re-Aushandlung ist eine Downgrade-Barriere. Wenn ein aktiver Angreifer STARTTLS aus der Serverantwort herausfiltert (STARTTLS-Stripping), würde ein sauber konfigurierter Server AUTH vor TLS nicht anbieten oder aktiv zurückweisen. Damit wird verhindert, dass ein Client in eine unverschlüsselte Passwortauthentifizierung gedrängt wird.

Aus der Sequenzlogik ergibt sich eine praktische Grenze: SMTP AUTH kann Transportdefizite nicht „kompensieren“. Kein SASL-Mechanismus ersetzt verifizierte Serveridentität, robuste TLS-Parameter und eine saubere Policy, die unverschlüsselte AUTH-Versuche zuverlässig blockiert. Umgekehrt kann TLS allein nicht verhindern, dass schwache Mechanismen oder unklare Fehlercodes Clients zu unsicheren Fallbacks verleiten. Erst das Zusammenspiel aus Capability-Design, TLS-Erzwingung und deterministischer Fehlersemantik stabilisiert Submission in heterogenen Clientlandschaften.

Mechanismen im Detailvergleich: PLAIN, LOGIN, CRAM-MD5, OAuth2 (Voraussetzungen, Sicherheitsbewertung, Client-Kompatibilität, typische Fehler und Fallback-Verhalten)

SMTP-Authentifizierung unterscheidet sich weniger durch „ob“ Zugangsdaten übertragen werden, sondern durch wie sie in der AUTH-Phase kodiert, geschützt und serverseitig geprüft werden. PLAIN und LOGIN delegieren die Sicherheit vollständig an eine vorgeschaltete Transportverschlüsselung. CRAM-MD5 vermeidet die Übertragung des Passworts im Klartext, bleibt jedoch kryptografisch und operativ eingeschränkt. OAuth2 ersetzt statische Passwörter durch zeitlich begrenzte Tokens und bindet Autorisierung in ein separates Protokoll ein.

Vergleichstabelle: Voraussetzungen, Sicherheit, Serveranforderungen, Kompatibilität

Protokollabläufe in Sequenzform (SMTP-Dialog)

Die folgenden Sequenzen zeigen typische, stark vereinfachte Abläufe. Entscheidend ist, ob der Server AUTH bereits vor TLS anbietet oder per Policy ausschließlich nach erfolgreichem STARTTLS. Letzteres reduziert das Risiko von Downgrade-Angriffen und Fehlkonfigurationen auf Client-Seite.

• PLAIN nach STARTTLS: S: 220 mail.example ESMTP
C: EHLO client
S: 250-STARTTLS
C: STARTTLS
S: 220 Ready to start TLS
(TLS-Handshake)
C: EHLO client
S: 250-AUTH PLAIN LOGIN
C: AUTH PLAIN <base64>
S: 235 2.7.0 Authentication successful
• LOGIN (zweistufig): C: AUTH LOGIN
S: 334 VXNlcm5hbWU6
C: <base64(username)>
S: 334 UGFzc3dvcmQ6
C: <base64(password)>
S: 235 2.7.0 Authentication successful
• CRAM-MD5 (Challenge/Response): C: AUTH CRAM-MD5
S: 334 <base64(challenge)>
C: <base64(username SP hmac-md5(challenge, secret))>
S: 235 2.7.0 Authentication successful
• OAuth2 (XOAUTH2) mit Initial-Response: C: AUTH XOAUTH2 <base64("user=" + user + "\x01auth=Bearer " + access_token + "\x01\x01")>
S: 235 2.7.0 Authentication successful

Typische Fehlermeldungen, Ursachen und Fallback-Verhalten

Fehlerbilder entstehen häufig an Übergängen: EHLO/Capability-Cache im Client, STARTTLS-Policy auf dem Server, SASL-Mechanismusauswahl und Token-Validierung. „Fallback“ bedeutet dabei entweder Mechanismus-Wechsel (z. B. von OAuth2 auf PLAIN) oder Transport-Wechsel (z. B. Versuch ohne TLS). Beide Fallback-Arten sollten serverseitig gezielt unterbunden oder zumindest sichtbar geloggt werden.

• 530 5.7.0 Must issue a STARTTLS command first: Server erzwingt TLS vor AUTH; Client versucht AUTH im Klartext oder hat STARTTLS deaktiviert.
• 538 5.7.11 Encryption required for requested authentication mechanism: Mechanismus (typisch PLAIN/LOGIN) wird ohne aktive TLS-Sitzung abgelehnt; häufig nach Capability-Cache, wenn der Client AUTH aus einer früheren Sitzung „merkt“.
• 534 5.7.9 Authentication mechanism is too weak: Server-Policy blockiert „Basic Auth“; tritt auf, wenn ein Client auf LOGIN/PLAIN zurückfällt oder OAuth2 nicht beherrscht.
• 535 5.7.8 Authentication credentials invalid: Falsches Passwort, falscher Benutzername, gesperrtes Konto; bei OAuth2 auch Token für falschen Nutzer, falsche Audience oder abgelaufener Token.
• 454 4.7.0 Temporary authentication failure: Temporäre Abhängigkeit gestört (z. B. Backend-Verzeichnisdienst, Token-Introspection, Rate-Limit); Clients interpretieren dies oft als retry-fähig.
• Mechanismus-Fallback (Client-Seite): Manche Clients probieren in Reihenfolge XOAUTH2 → PLAIN → LOGIN. Server sollten per Capability nur erlaubte Mechanismen annoncieren und „AUTH erst nach TLS“ erzwingen, um einen stillen Downgrade zu verhindern.

Diagramm-Tabellen: Interaktion zwischen TLS-Handshake und AUTH-Phase

Die Kopplung von TLS und AUTH entscheidet über das reale Sicherheitsniveau. Ohne erneutes EHLO nach STARTTLS fehlen dem Client oft korrekte Capabilities; umgekehrt kann ein Client, der vor TLS bereits AUTH sieht, fälschlich einen Klartextversuch starten. Die folgende Darstellung nutzt eine zeitliche Achse von oben nach unten.

Für die Praxis folgt daraus eine klare Priorität: PLAIN/LOGIN ausschließlich nach TLS, CRAM-MD5 nur bei begründeter Legacy-Notwendigkeit und unter Berücksichtigung der Passwortspeicher-Anforderungen, OAuth2 bevorzugt dort, wo Clients und Betriebsprozesse (Token-Lifecycle, Scopes, Conditional Access) es zuverlässig tragen.

Abläufe und Wechselwirkungen: Sequenzen von TLS-Handshake und AUTH-Phase, STARTTLS vs. SMTPS, Policy- und Logging-Implikationen

In SMTP-Transaktionen entscheidet die zeitliche Kopplung zwischen Transportverschlüsselung (TLS) und Authentifizierung (AUTH) über Vertraulichkeit, Protokollierbarkeit und Fehlersignale. Entscheidend ist weniger, ob ein Mechanismus formal „unterstützt“ wird, sondern unter welchen Zuständen er angeboten wird, wie ein Client darauf reagiert (inklusive Fallback) und welche Policy an welcher Protokollstelle greift. Besonders sichtbar wird dies bei STARTTLS, weil TLS dort als Zustandswechsel innerhalb derselben TCP-Verbindung erfolgt und sich die Server-Capabilities nach dem TLS-Upgrade typischerweise ändern.

Sequenz: STARTTLS mit erneuter Capability-Aushandlung und nachgelagerter AUTH-Phase

Bei STARTTLS beginnt der Dialog im Klartext, allerdings ohne zwingend sensitive Inhalte zu übertragen. Der Server kann bereits in dieser Phase AUTH bewerben, sollte dies aus Sicherheitsgründen jedoch oft unterdrücken oder per Policy so steuern, dass Authentifizierung erst nach erfolgreichem TLS-Upgrade zulässig ist. Nach dem Upgrade verlangt RFC-konformes Verhalten, dass der Client erneut EHLO sendet; der Server antwortet dann mit einem zweiten, kontextabhängigen Capability-Set (häufig erst jetzt mit AUTH, SMTPUTF8 oder strengeren Größen-/Policy-Hinweisen).

Die Wechselwirkung zeigt sich daran, dass die AUTH-Phase inhaltlich zwar SMTP ist, aber sicherheitstechnisch von TLS abhängt: Ohne TLS sind Mechanismen wie PLAIN und LOGIN lediglich Base64-kodiert und damit bei Transport-Mitlesen trivial rekonstruierbar. Auch bei TLS bleibt relevant, ob der Client die Serveridentität zuverlässig prüft (Zertifikatskette, Hostname), weil andernfalls ein aktiver MITM trotz Verschlüsselung Auth-Daten abgreifen kann.

STARTTLS vs. SMTPS (Implicit TLS): Zustandsmodell, Fehlerszenarien und Interoperabilität

Bei SMTPS (implicit TLS, typischerweise Port 465) startet die Verbindung unmittelbar mit dem TLS-Handshake; SMTP-Banner und EHLO erscheinen erst innerhalb des verschlüsselten Kanals. Das reduziert Protokollkomplexität (kein Upgrade-Punkt), verschiebt aber Fehlerbilder: Ein TLS-Problem äußert sich als Verbindungs- oder Handshake-Fehler, nicht als SMTP-Statuscode. STARTTLS (häufig Port 587) erlaubt dagegen einen opportunistischen oder erzwungenen Upgrade-Pfad; hier entstehen spezifische Downgrade-Risiken, wenn Policies „TLS optional“ zulassen und Clients bei fehlendem 250-STARTTLS im Klartext fortfahren.

• Downgrade-Fenster bei STARTTLS: Wenn ein Angreifer das 250-STARTTLS-Capability aus der EHLO-Antwort entfernt, kann ein fehlkonfigurierter Client ohne TLS fortfahren; wirksame Gegenmaßnahmen sind Server-Policy „TLS required“ für Submission und Client-Policy mit „require STARTTLS“ statt opportunistischem Modus.
• Fehlersignale bei SMTPS: TLS scheitert vor SMTP; typische Indikatoren liegen in TLS-Alerts und Socket-Fehlern, nicht in SMTP-Codes wie 530 5.7.0 Must issue a STARTTLS command first.
• Capability-Semantik: STARTTLS erfordert nach erfolgreichem Upgrade ein erneutes EHLO; ein Server kann dadurch vor und nach TLS unterschiedliche AUTH-Mechanismen ausweisen (z. B. vor TLS kein AUTH, nach TLS AUTH PLAIN und AUTH XOAUTH2).
• Port-/Rollen-Trennung: Submission über 587 (STARTTLS) und 465 (implicit TLS) unterstützt klare Policies: Authentifizierung und Enforcements sind erwartbar; Port 25 bleibt primär für MTA-zu-MTA und sollte AUTH dort nur sehr kontrolliert anbieten.

Diagramm als Tabelle: TLS-Handshake, AUTH-Angebot und Policy-Entscheidungspunkte

Policy-Engines und Konfigurationen greifen an unterschiedlichen Stellen ein: beim Bauen der Capability-Liste, beim Akzeptieren von AUTH, beim Erzwingen von TLS sowie beim Schreiben von Logs. Die folgende Interaktionsdarstellung dient als „Schaltplan“ für typische Decision Points; sie trennt Transportzustand, SMTP-Phase und beobachtbare Artefakte (Codes, Logevent, Telemetrie).

Fallback- und Logging-Implikationen: Was Protokolle über Sicherheit verraten

Client-Fallback kann Sicherheit stillschweigend degradieren, wenn ein Mechanismus- oder TLS-Fehler als Signal zur Absenkung genutzt wird. Typisch ist die Sequenz: AUTH XOAUTH2 scheitert (Token abgelaufen, Uhrzeitdrift, Audience falsch), danach versucht der Client AUTH LOGIN oder AUTH PLAIN. Serverseitig sollte eine Policy festlegen, ob solche Downgrades überhaupt akzeptiert werden, insbesondere wenn OAuth2 als zwingender Kontrollpunkt vorgesehen ist.

• Transport-Guardrails: Bei Klartextzustand AUTH mit 530 5.7.0 Must issue a STARTTLS command first ablehnen; in Logs den Zustand „pre-TLS“ explizit markieren, um Fehlkonfigurationen und Downgrade-Versuche sichtbar zu machen.
• Mechanismus-Downgrade erkennen: Wiederholte Sequenzen AUTH XOAUTH2 → 535 5.7.8 → AUTH LOGIN sollten als Policy-Verstoß oder Anomalie auswertbar sein; andernfalls entsteht ein unbeabsichtigter „Password-Fallback“ trotz Token-Strategie.
• Logging-Minimierung vs. Forensik: AUTH-Payloads niemals loggen; zulässig und nützlich sind Mechanismusname, Ergebniscode, Session-/Connection-ID, TLS-Parameter (Version, Cipher), Peer-IP, und gegebenenfalls Token-Fehlerklassen ohne Geheimnisse (z. B. „invalid_signature“ statt Tokeninhalt).
• Rate-Limit auf mehreren Ebenen: Separate Limits für AUTH-Fehlschläge und für TLS-Handshakes verhindern, dass Auth-Bruteforce und Handshake-Flooding sich gegenseitig verdecken; in Telemetrie sollten beide Achsen korrelierbar bleiben.

Für belastbare Auswertungen muss ein Logereignis sowohl SMTP- als auch TLS-Kontext tragen: Bei STARTTLS sind zwei EHLO-Phasen und damit zwei Capability-Zustände relevant; ohne diese Differenzierung wirkt ein „AUTH not advertised“-Fehler wie ein Mechanismusproblem, obwohl tatsächlich ein fehlendes TLS-Upgrade oder eine Policy „AUTH erst nach TLS“ greift. Eine saubere Korrelation über eine durchgehende Session-ID über den TLS-Upgrade hinweg verhindert, dass die AUTH-Entscheidung isoliert betrachtet wird.