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 vollständigen Spezifikationen für alle SMTP-Befehle (EHLO, HELO, MAIL FROM, RCPT TO, DATA, RSET, VRFY, EXPN, HELP, NOOP, QUIT) mit Syntax, Semantik und Beispielen sind in RFC 5321 Abschnitt 4.1.1 detailliert beschrieben.

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)

Vollständige Liste aller SMTP-Antwortcodes von 211 bis 555 in RFC 5321 Abschnitt 4.2.3.

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.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.