Zum Hauptinhalt springen

4. SMTP-Spezifikationen (The SMTP Specifications)

Dieser Abschnitt enthält detaillierte Spezifikationen für SMTP-Befehle, Antworten, Sequenzen, Trace-Informationen und Implementierungsfragen.

4.1. SMTP-Befehle (SMTP Commands)​

SMTP-Befehle sind Groß-/Kleinschreibung-insensitive ASCII-Wörter mit vier Zeichen (einige auf acht Zeichen erweitert), optional gefolgt von Parametern.

4.1.1. Befehlssemantik und -syntax (Command Semantics and Syntax)​

Die Befehle EHLO und HELO eröffnen eine SMTP-Sitzung; EHLO fordert zusätzlich Dienst-Erweiterungen an, während HELO als Fallback für Server ohne Erweiterungsunterstützung dient. MAIL FROM startet eine Mail-Transaktion und gibt den Reverse-Path an. RCPT TO identifiziert jeweils einen Empfänger; mehrere RCPT-Befehle können für dieselbe Nachricht verwendet werden. DATA leitet den Nachrichtentext ein und endet mit der Sequenz <CRLF>.<CRLF>. RSET bricht die aktuelle Mail-Transaktion ab und setzt die Puffer zurück. VRFY prüft, ob eine Mailbox existiert, und EXPN erweitert eine Mailingliste; viele Server beschränken diese Befehle aus Sicherheitsgründen. HELP liefert Hilfetext, NOOP hält die Verbindung aktiv, und QUIT beendet die Sitzung.

4.1.2. Befehlsargument-Syntax (Command Argument Syntax)​

Befehle folgen strengen Syntaxregeln, die in ABNF (RFC 5234) definiert sind. Mailbox-Format: local-part@domain (local-part max. 64 Zeichen, domain max. 255 Zeichen).

4.1.3. Adressliterale (Address Literals)​

  • IPv4: [192.0.2.1]
  • IPv6: [IPv6:2001:db8::1]

4.1.4. Befehlsreihenfolge (Order of Commands)​

Gültige Befehlssequenz: Verbindung → EHLO/HELO → MAIL → RCPT (ein oder mehr) → DATA → QUIT

4.1.5. Private-Use-Befehle (Private-Use Commands)​

Befehle, die mit X beginnen, sind für private Verwendung und Experimente reserviert.

4.2. SMTP-Antworten (SMTP Replies)​

4.2.1. Antwortschweregrade und Theorie (Reply Code Severities and Theory)​

Antwortcodes sind dreistellige Zahlen:

  • 2yz: Positiver Abschluss
  • 3yz: Positive Zwischenantwort
  • 4yz: Vorübergehender negativer Abschluss (wiederholbar)
  • 5yz: Permanenter negativer Abschluss (nicht wiederholen)

4.2.2. Antwortcodes nach Funktionsgruppen (Reply Codes by Function Groups)​

Wichtige Codes: 220 (Dienst bereit), 250 (Ok), 354 (Daten starten), 421 (Dienst nicht verfügbar), 450/550 (Mailbox nicht verfügbar), 500 (Syntaxfehler), 554 (Transaktion fehlgeschlagen).

4.2.3. Antwortcodes in numerischer Reihenfolge (Reply Codes in Numeric Order)​

  • 211: Systemstatus.
  • 214: Hilfemeldung.
  • 220: Dienst bereit.
  • 221: Verbindung wird geschlossen.
  • 250: OK.
  • 251: Benutzer nicht lokal; Weiterleitung erfolgt.
  • 252: Benutzer kann nicht mit VRFY geprüft werden, wird aber akzeptiert.
  • 354: Beginn der Mail-Eingabe.
  • 421: Dienst nicht verfügbar.
  • 450: Mailbox nicht verfügbar.
  • 451: lokaler Fehler.
  • 452: unzureichender Speicher.
  • 455: Server kann Parameter nicht verarbeiten.
  • 500: Syntaxfehler.
  • 501: Syntaxfehler in Parametern.
  • 502: Befehl nicht implementiert.
  • 503: falsche Befehlssequenz.
  • 504: Befehlsparameter nicht implementiert.
  • 550: Mailbox nicht verfügbar.
  • 551: Benutzer nicht lokal.
  • 552: Speicherzuweisung überschritten.
  • 553: Mailboxname nicht erlaubt.
  • 554: Transaktion fehlgeschlagen.
  • 555: Parameter nicht erkannt.

4.2.4. Antwortcode 502 (Reply Code 502)​

502 zeigt an, dass der Befehl nicht implementiert ist. Clients sollten nicht versuchen, nicht implementierte Befehle erneut auszuführen.

4.2.5. Antwortcodes nach DATA und dem anschließenden <CRLF>.<CRLF>​

Nach Abschluss von DATA:

  • 250: Nachricht angenommen.
  • 450/550: Mailbox nicht verfügbar.
  • 451/551: Verarbeitungsfehler.
  • 452/552: unzureichender Speicher.
  • 554: Transaktion fehlgeschlagen.

4.3. Sequenzierung von Befehlen und Antworten (Sequencing of Commands and Replies)​

SMTP ist Lock-Step: Client sendet Befehl, wartet auf Antwort, sendet dann nächsten Befehl. Ausnahme: PIPELINING-Erweiterung erlaubt Batch-Verarbeitung.

4.3.2. Befehls-Antwort-Sequenzen (Command-Reply Sequences)​

Minimale Implementierung:

S: 220
C: EHLO
S: 250
C: MAIL FROM
S: 250
C: RCPT TO
S: 250
C: DATA
S: 354
C: (message data)
C: .
S: 250
C: QUIT
S: 221

4.4. Trace-Informationen (Trace Information)​

Jeder SMTP-Server fügt bei Annahme einer Nachricht ein Received-Header-Feld hinzu:

Received: from sender.example.com (host.example.com [192.0.2.1])
  by receiver.example.com (Postfix) with ESMTP id 12345
  for `<[email protected]>`; Mon, 24 Dec 2024 10:00:00 +0000 (UTC)

4.5. Zusätzliche Implementierungsfragen (Additional Implementation Issues)​

4.5.1. Minimale Implementierung (Minimum Implementation)​

Ein voll funktionsfähiges SMTP MUSS (MUST) unterstützen: EHLO, MAIL, RCPT, DATA, RSET, NOOP, QUIT-Befehle, alle Standard-Antwortcodes, Warteschlangen- und Wiederholungslogik, ordnungsgemäße Fehlerbehandlung.

4.5.2. Transparenz (Transparency)​

Server MÜSSEN (MUST) Dot-Stuffing handhaben: Zeilen, die mit . beginnen, müssen während DATA-Übertragung als .. escaped werden.

4.5.3. Größen und Timeouts (Sizes and Timeouts)​

Mindestanforderungen: Local-part 64 Oktette, Domain 255 Oktette, Path 256 Oktette, Befehlszeile 512 Oktette, Antwortzeile 512 Oktette, Textzeile 1000 Oktette, Empfängerpuffer 100 Empfänger.

Timeouts: Initiale 220-Nachricht 5 Minuten, MAIL-Befehl 5 Minuten, RCPT-Befehl 5 Minuten, DATA-Initiation 2 Minuten, DATA-Block 3 Minuten, DATA-Beendigung 10 Minuten.

4.5.4. Wiederholungsstrategien (Retry Strategies)​

Bei vorübergehenden Fehlern (4yz-Codes): Mindestens alle 30 Minuten wiederholen, mindestens 4-5 Tage lang versuchen, Absender in Intervallen warnen, nach endgültigem Fehler Bounce generieren.

4.5.5. Nachrichten mit Null-Rückwärtspfad (Messages with a Null Reverse-Path)​

Bounce-Nachrichten verwenden MAIL FROM:<> (Null-Rückwärtspfad), um Mail-Schleifen zu vermeiden. Server MÜSSEN (MUST) Null-Rückwärtspfad akzeptieren, DÜRFEN ABER NICHT (MUST NOT) Bounces dafür generieren.

Letztes Update am