3. SMTP-Verfahren: Überblick (The SMTP Procedures: An Overview)
Dieser Abschnitt bietet einen Überblick über SMTP-Operationen, einschließlich Sitzungsinitiierung, Mail-Transaktionen, Adressverifizierung, Relaying, Gatewaying und Sitzungsbeendigung.
3.1. Sitzungsinitiierung (Session Initiation)
Eine SMTP-Sitzung (SMTP session) wird initiiert, wenn der sendende SMTP (Client) einen bidirektionalen Übertragungskanal zum empfangenden SMTP (Server) etabliert. Der Kanal ist vollständig asynchron und es gibt keine Einschränkungen beim Datenfluss. Nach Abschluss der TCP-Verbindung sendet der Server normalerweise eine "220 Service ready"-Antwort (Dienst bereit). Der Client beginnt normalerweise mit den Operationen, nachdem er diese Begrüßung empfangen hat.
3.2. Client-Initiierung (Client Initiation)
Nachdem der Transportdienst den Initiierungskanal bereitgestellt und der Server die 220-Dienstbereit-Begrüßung gesendet hat, sendet der Client normalerweise den EHLO-Befehl (EHLO command), um sich zu identifizieren und den Server aufzufordern, ihn über verfügbare Service-Erweiterungen zu informieren. Wenn der Server keine Erweiterungen unterstützt, antwortet er auf EHLO mit einem 500-Fehler, und der Client SOLLTE (SHOULD) auf den HELO-Befehl (HELO command) zurückfallen.
EHLO-Befehlsbeispiel:
S: 220 smtp.example.com ESMTP Postfix
C: EHLO client.example.com
S: 250-smtp.example.com
S: 250-SIZE 52428800
S: 250-8BITMIME
S: 250-STARTTLS
S: 250 HELP
3.3. Mail-Transaktionen (Mail Transactions)
Eine Mail-Transaktion (mail transaction) besteht aus einer Reihe von Befehlen vom Client zum Server, um eine Nachricht zu übertragen. Eine Mail-Transaktion umfasst:
- MAIL-Befehl - Identifiziert den Nachrichtenabsender
- Ein oder mehrere RCPT-Befehle - Identifiziert den/die Nachrichtenempfänger
- DATA-Befehl - Sendet den Nachrichteninhalt
Vollständiges Transaktionsbeispiel:
C: MAIL FROM:<[email protected]>
S: 250 Ok
C: RCPT TO:<[email protected]>
S: 250 Ok
C: RCPT TO:<[email protected]>
S: 250 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: [email protected]
C: To: [email protected]
C: Subject: Test message
C:
C: This is a test message.
C: .
S: 250 Ok: queued as 12345
Der MAIL-Befehl initiiert die Mail-Transaktion. Der erfolgreiche Abschluss dieses Befehls bewirkt, dass der Empfänger alle Puffer und Statustabellen löscht und sich darauf vorbereitet, RCPT-Befehle zu empfangen.
Der RCPT-Befehl identifiziert einen einzelnen Empfänger dieser Mail. Mehrere RCPT-Befehle können für eine bestimmte Nachricht ausgegeben werden. Jeder erfolgreiche RCPT-Befehl fügt einen Empfänger zum Puffer hinzu.
Der DATA-Befehl bewirkt, dass nachfolgende Zeilen als Nachrichtentext statt als Befehle behandelt werden. Die Nachricht wird durch eine Zeile beendet, die nur einen Punkt (.) enthält.
3.4. Weiterleitung zur Adresskorrektur oder -aktualisierung (Forwarding for Address Correction or Updating)
Einige Server möchten Mail möglicherweise an eine korrigierte oder aktualisierte Adresse weiterleiten, anstatt an die ursprüngliche Empfängeradresse. SMTP stellt die Antwortcodes 251 und 551 (response codes) für diesen Zweck bereit. Diese Codes ermöglichen es dem Server, den Client darüber zu informieren, dass sich die Benutzeradresse geändert hat, der Server aber versuchen wird, die Nachricht weiterzuleiten (251), oder nicht weiterleiten kann (551).
3.5. Befehle zum Debuggen von Adressen (Commands for Debugging Addresses)
3.5.1. Überblick (Overview)
SMTP stellt zwei Befehle zur Verifizierung von Benutzernamen und Mailinglisten bereit:
- VRFY - Verifiziert einen Benutzernamen oder eine Mailbox
- EXPN - Erweitert eine Mailingliste
Diese Befehle sind hauptsächlich für Debugging-Zwecke gedacht, und viele Server deaktivieren oder beschränken sie aus Sicherheits- und Datenschutzgründen.
3.5.2. Normale VRFY-Antwort (VRFY Normal Response)
Eine erfolgreiche Antwort auf den VRFY-Befehl ist normalerweise Code 250, gefolgt von Text, der den vollständigen Namen des Benutzers und die Mailbox-Adresse enthält.
Beispiel:
C: VRFY Jones
S: 250 Fred Jones <[email protected]>
3.5.3. Bedeutung der erfolgreichen VRFY- oder EXPN-Antwort (Meaning of VRFY or EXPN Success Response)
Eine erfolgreiche Antwort auf die VRFY- und EXPN-Befehle garantiert nicht, dass die Adresse Mail empfangen kann oder dass Mail zugestellt wird. Sie zeigt lediglich an, dass die Adresse dem Server bekannt ist und syntaktisch gültig ist.
3.5.4. Semantik und Anwendungen von EXPN (Semantics and Applications of EXPN)
Der EXPN-Befehl wird verwendet, um eine Mailingliste oder einen Alias zu erweitern. Er gibt alle Adressen in der Liste zurück.
Beispiel:
C: EXPN staff
S: 250-Alice <[email protected]>
S: 250-Bob <[email protected]>
S: 250 Charlie <[email protected]>
3.6. Relaying und Mail-Routing (Relaying and Mail Routing)
3.6.1. Quellrouten und Relaying (Source Routes and Relaying)
Source Routing (Quellrouting) (explizite Angabe eines Pfads über Zwischen-Hosts) ist im modernen SMTP veraltet. Mail-Routing SOLLTE (SHOULD) sich auf DNS-MX-Records stützen.
3.6.2. Mail-Exchange-Records und Relaying (Mail eXchange Records and Relaying)
Das DNS-MX (Mail eXchanger)-Record-System wird verwendet, um die Mail-Server zu identifizieren, die für die Annahme von Mail für eine Domain verantwortlich sind. Bei der Zustellung von Mail:
- MX-Records für die Zieldomain nachschlagen
- Nach Priorität sortieren (niedrigere Zahl = höhere Priorität)
- Zustellung an Server in Prioritätsreihenfolge versuchen
- Wenn alle MX-Records fehlschlagen, direkte Zustellung an A/AAAA-Records versuchen
Beispiel für DNS-MX-Records:
example.com. IN MX 10 mail1.example.com.
example.com. IN MX 20 mail2.example.com.
example.com. IN MX 30 mail3.example.com.
3.6.3. Message-Submission-Server als Relays (Message Submission Servers as Relays)
Message Submission Agents (MSAs, Nachrichteneinreichungsagenten) fungieren als spezielle Relays, die:
- Mail von Mail User Agents (MUAs, Mail-Benutzeragenten) akzeptieren
- Submission-Richtlinien anwenden
- Erforderliche Header hinzufügen
- Absender authentifizieren
- An entsprechende MTAs weiterleiten
3.7. Mail-Gatewaying (Mail Gatewaying)
Ein Mail-Gateway (mail gateway) verbindet die SMTP-Infrastruktur mit anderen Mail-Systemen (z. B. X.400, UUCP). Gateways übersetzen zwischen Protokollen und Formaten.
3.7.1. Header-Felder beim Gatewaying (Header Fields in Gatewaying)
Gateways MÜSSEN (MUST) obligatorische Header-Felder bewahren und KÖNNEN (MAY) Gateway-spezifische Felder hinzufügen. Die Übersetzung MUSS (MUST) semantische Äquivalenz aufrechterhalten, wenn möglich.
3.7.2. Received-Zeilen beim Gatewaying (Received Lines in Gatewaying)
Gateways MÜSSEN (MUST) Received-Header-Felder hinzufügen, um den Nachrichtenpfad zu verfolgen:
- Gateway-Identifikation
- Zeitstempel
- Protokollinformationen
3.7.3. Adressen beim Gatewaying (Addresses in Gatewaying)
Adressübersetzung ist komplex und Gateway-spezifisch. Gateways SOLLTEN (SHOULD):
- Ursprüngliche Adressinformationen bewahren
- Bidirektionales Adressmapping bereitstellen
- Übersetzungsregeln dokumentieren
3.7.4. Andere Header-Felder beim Gatewaying (Other Header Fields in Gatewaying)
Gateways MÜSSEN (MUST) verschiedene Header-Felder korrekt handhaben:
- From, To, Cc, Bcc (Adressfelder)
- Subject, Keywords (Textfelder)
- Date (Zeitstempel-Konvertierung)
- Message-ID (Einzigartige Kennungserhaltung)
3.7.5. Umschläge beim Gatewaying (Envelopes in Gatewaying)
SMTP-Umschläge (MAIL FROM und RCPT TO) können sich von Header-Adressen unterscheiden. Gateways MÜSSEN (MUST) beide korrekt handhaben.
3.8. Beenden von Sitzungen und Verbindungen (Terminating Sessions and Connections)
Eine SMTP-Sitzung wird mit dem QUIT-Befehl beendet:
C: QUIT
S: 221 smtp.example.com closing connection
Nach dem Senden der 221-Antwort schließt der Server die TCP-Verbindung. Der Client SOLLTE (SHOULD) auf die 221-Antwort warten, bevor er schließt, MUSS (MUST) aber darauf vorbereitet sein, dass der Server zuerst schließt.
Abnormale Beendigung: Bei schwerwiegenden Fehlern kann jede Partei die Verbindung sofort schließen. Der Server KANN (MAY) den Antwortcode 421 verwenden, um anzuzeigen, dass der Dienst nicht verfügbar ist, bevor er schließt.
3.9. Mailinglisten und Aliase (Mailing Lists and Aliases)
3.9.1. Alias (Alias)
Ein Alias (alias) ist ein Mailbox-Name, der sich bei Auflösung auf einen oder mehrere andere Mailbox-Namen bezieht. Die Alias-Erweiterung ist für den Absender transparent.
Beispiel: [email protected] könnte ein Alias für [email protected] sein
3.9.2. Listen (Lists)
Eine Mailingliste (mailing list) ähnelt einem Alias, hat aber in der Regel:
- Verwaltung durch Listen-Software
- Erlaubt Abonnieren/Abbestellen
- Kann Nachrichten ändern (Header, Footer hinzufügen)
- Unterhält eine Abonnenten-Datenbank
Wenn Mail an eine Liste gesendet wird, wird sie erweitert und an alle Abonnenten zugestellt. Listen-Software in der Regel:
- Fügt listenspezifische Header hinzu (List-ID, List-Unsubscribe)
- Kann Moderation erfordern
- Handhabt Bounces
- Pflegt Archive