1. Einführung (Introduction)
Das Ziel des Simple Mail Transfer Protocol (SMTP, Einfaches Mail-Übertragungsprotokoll) ist es, Mail zuverlässig und effizient zu übertragen.
SMTP ist unabhängig vom jeweiligen Transportsubsystem und erfordert nur einen geordneten, zuverlässigen Datenstromkanal. Obwohl sich dieses Dokument speziell auf die Verwendung von SMTP über TCP konzentriert, sind andere Transporte möglich. Die Anhänge dieses Dokuments liefern wichtige Informationen über TCP und andere Implementierungsdetails.
1.1. Transport elektronischer Post (Transport of Electronic Mail)
Elektronische Post wird von einem Server zum nächsten übertragen, bis sie das Zielsystem erreicht. Genauer gesagt wird Mail von einem Message-Transfer-Agent (MTA, Nachrichtenübertragungsagent) zu einem anderen unter Verwendung von SMTP übertragen. Der Ziel-MTA ist für die Zustellung der Mail an die Mailbox des Benutzers oder deren Weiterleitung an ein anderes System verantwortlich.
Benutzer interagieren nicht direkt mit SMTP. Stattdessen:
- User Agents (UAs, Benutzeragenten) oder Mail Submission Agents (MSAs, Mail-Einreichungsagenten) übermitteln Mail an MTAs
- Mail Access Agents (MAAs, Mail-Zugriffsagenten) ermöglichen Benutzern den Abruf von Mail aus Mailboxen unter Verwendung von Protokollen wie POP3 oder IMAP
1.2. Geschichte und Kontext dieses Dokuments (History and Context for This Document)
SMTP wurde erstmals im August 1982 in RFC 821 spezifiziert. Seitdem wurde es Gegenstand zahlreicher Aktualisierungen und Klarstellungen:
- RFC 821 (1982): Ursprüngliche SMTP-Spezifikation
- RFC 1123 (1989): Anforderungen für Internet-Hosts - klärte und aktualisierte SMTP
- RFC 1869 (1995): Führte den SMTP-Service-Extension-Mechanismus (ESMTP) ein
- RFC 2821 (2001): Konsolidierte und klärte vorherige Spezifikationen
- RFC 5321 (2008): Dieses Dokument - aktuelle Spezifikation
Dieses Dokument macht RFC 2821 obsolet und aktualisiert RFC 1123. Es integriert die Erfahrungen und Best Practices der letzten zwei Jahrzehnte des SMTP-Einsatzes im Internet.
Wichtige Änderungen gegenüber RFC 2821
- Klarstellungen: Präzisere Sprache zum Befehlsverhalten
- Best Practices: Aktualisierte Empfehlungen basierend auf Betriebserfahrung
- Sicherheitsüberlegungen: Erweiterte Sicherheitsleitlinien
- Interoperabilität: Verbesserte Leitlinien für den Umgang mit Legacy-Systemen
1.3. Dokumentkonventionen (Document Conventions)
Die Schlüsselwörter "MUST" (MUSS), "MUST NOT" (DARF NICHT), "REQUIRED" (ERFORDERLICH), "SHALL" (SOLL), "SHALL NOT" (SOLL NICHT), "SHOULD" (SOLLTE), "SHOULD NOT" (SOLLTE NICHT), "RECOMMENDED" (EMPFOHLEN), "MAY" (KANN) und "OPTIONAL" (OPTIONAL) in diesem Dokument sind wie in RFC 2119 beschrieben zu interpretieren.
Bedeutung der RFC 2119-Schlüsselwörter
- MUST / REQUIRED / SHALL: Absolute Anforderung der Spezifikation
- MUST NOT / SHALL NOT: Absolutes Verbot
- SHOULD / RECOMMENDED: Es können gültige Gründe zum Ignorieren existieren, aber die Implikationen müssen verstanden werden
- SHOULD NOT / NOT RECOMMENDED: Es können gültige Gründe existieren, wenn das Verhalten akzeptabel ist, aber die Implikationen müssen verstanden werden
- MAY / OPTIONAL: Das Element ist wirklich optional
Notationen
In diesem Dokument:
- Protokollbeispiele verwenden "C:" für Client-Zeilen und "S:" für Server-Zeilen
- Syntax wird unter Verwendung von Augmented Backus-Naur Form (ABNF, Erweiterte Backus-Naur-Form) wie in RFC 5234 definiert spezifiziert
- Begriffe, die in diesem Dokument definiert werden, werden bei ihrer ersten Verwendung hervorgehoben
Beispiel einer SMTP-Sitzung
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
C: MAIL FROM:<[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
C:
C: This is a test message.
C: .
S: 250 Ok: queued as 12345
C: QUIT
S: 221 Bye