SMTP: Unterschied zwischen den Versionen

Aktuelle Version vom 6. November 2024, 12:39 Uhr

SMTP (Simple Mail Transfer Protocol) ist ein Protokoll zum Austausch von E-Mails

Beschreibung

SMTP (Simple Mail Transfer Protocol)
Familie	Internetprotokolle
Einsatzgebiet	Einspeisung von E-Mail (Mail Submission), Abholung von E-Mails eventuell über mehrere Stationen (Mail Transfer)
Ports	25/TCP (Standard-MTA) 465/TCP (nur mit SSL/TLS) 587/TCP (nur als MSA/für Mail-Clients, häufig mit STARTTLS)

Standard	RFC 5321

Das Simple Mail Transfer Protocol (SMTP, auf Deutsch etwa Einfaches E-Mail-Transportprotokoll) ist ein Protokoll der Internetprotokolle, das zum Austausch von E-Mails in Computernetzen dient.

Es wird dabei vorrangig zum Einspeisen und zum Weiterleiten von E-Mails verwendet.
Zum Abholen von Nachrichten kommen andere, spezialisierte Protokolle wie POP3 oder IMAP zum Einsatz.
SMTP-Server nehmen traditionell Verbindungen auf Port 25 („smtp“) entgegen.

Neuere Server benutzen auch Port 587, um ausschließlich von authentifizierten Benutzern/Servern Mails entgegenzunehmen („Mail Submission Agent“), wobei gewöhnlich mittels STARTTLS die bestehende Klartext-Verbindung zu einer verschlüsselten Verbindung umgeschaltet wird, um die Authentifizierungsdaten zu schützen.

Durch eine klare Trennung eigener und fremder Benutzer sollen Konfigurationsprobleme und damit Spam vermieden werden (→ SMTP-Relay-Server).
Außerdem kann aufgrund der unterschiedlichen Ports eine einfache Firewall-Regel verwendet werden, um unkontrolliert abgehende Spamnachrichten aus dem eigenen Netzwerk zu blockieren, ohne dass Verbindungen zu externen SMTP-Servern vollständig ausgeschlossen werden.

SMTP ist ein Kommunikationsprotokoll für die Übertragung von E-Mails.

Die Kommunikation erfolgt zwischen einem E-Mail-Client und einem SMTP-Server (Postausgangsserver) oder zwischen zwei SMTP-Server.

Für den Austausch der E-Mails sind die Mail Transfer Agents (MTAs) zuständig.

Untereinander verständigen sich die MTAs mit dem SMTP-Protokoll.

Neben SMTP gibt mit POP und IMAP noch zwei weitere Protokolle für den E-Mail-Austausch.

Diese beiden Protokoll dienen jedoch nur dazu, um E-Mail abzuholen oder online zu verwalten.
SMTP dagegen ist ein Kommunikationsprotokoll, das E-Mails entgegennehmen und weiterleiten kann.

Nachteile von SMTP

Keine zuverlässige Versandbestätigung
- Geht eine E-Mail verloren, werden weder Sender noch Empfänger darüber informiert.

Kann eine E-Mail nicht zugestellt werden, sieht die SMTP-Spezifikation die Benachrichtigung des Senders vor.

Es gibt zwar eine SMTP-Erweiterung für standardisierte Fehlermeldungen, allerdings unterstützen nicht alle SMTP-Server diese Erweiterung.
Die meisten unzustellbaren E-Mails enthalten nur eine mehr oder weniger verständliche Fehlermeldung in englischer Sprache und den Header der gesendeten E-Mail.

Ein weiteres Problem von SMTP ist die nicht vorhandene Authentisierung des Benutzers beim Verbindungsaufbau zwischen SMTP-Client und SMTP-Server.

Das führt dazu, dass eine beliebige Absenderadresse beim Versand einer E-Mail angegeben werden kann.
In der Praxis sieht das dann so aus, dass über offene SMTP-Server massenhaft Werbe-E-Mails, der sogenannte Spam, versendet wird.
Aufgrund der gefälschten Absender-Adressen kann der eigentliche Urheber nur mit viel Mühe ermittelt werden.

Mit der Zeit wurden Maßnahmen und Verfahren entwickelt, um den Missbrauch von SMTP-Servern entgegenzuwirken.

Leider sind diese Verfahren optional.
Das heißt, es ist den Administratoren überlassen die Verfahren in ihren Mail-Servern zu aktivieren und zu konfigurieren.

Geschichte

Vorgänger von SMTP waren im Arpanet das Mail Box Protocol (RFC 278) vom Juli 1971 und FTP Mail (RFC 458) vom Februar 1973.

Mit der Entstehung des Internets aus dem ARPANET um 1980 schlug Jon Postel vor, die Abhängigkeit des E-Mail-Verkehrs vom FTP-Dienst abzukoppeln (RFC 772), und veröffentlichte 1982 SMTP unter RFC 821.
In den frühen 1980er Jahren wurde es eine Ergänzung zu UUCP, das vor allem für den E-Mail-Verkehr periodisch verbundener Rechner genutzt wurde.
SMTP wurde der Standard für Rechner, die ständig am Netz waren.

Einer der ersten Mail Transfer Agents, der SMTP implementierte und weitere Verbreitung erlangte, war sendmail.

Inzwischen gibt es unzählige Programme, die SMTP als Client oder Server unterstützen, darunter weit verbreitete SMTP-Server wie Postfix, qmail, exim usw.
Da viele Programmierframeworks wie .NET oder Java bereits SMTP-Klassen eingebaut haben, ist die Entwicklung auch nur noch mit geringem Aufwand verbunden.

SMTP begann als reines ASCII-Protokoll, so dass damit keine Binärdateien übertragen werden konnten.

Erst Standards wie MIME (Multipurpose Internet Mail Extensions) schufen diese Möglichkeit durch ein Kodieren der Binärdateien in ASCII.

Verfahren

Die Abwicklung des SMTP-Verfahrens wird meist für den Anwender unsichtbar durch sein Mailprogramm vorgenommen, den sogenannten Mail User Agent (MUA).

Dieses Programm verbindet sich mit einem SMTP-Server, dem Mail Submission Agent (MSA), der die Mail über ggf. weitere SMTP-Server, sogenannte Mail Transfer Agents (MTA), zum Ziel transportiert.
Da SMTP als Protokoll zum Transport von lokal erstellten Mails zwischen Servern konzipiert wurde, übernahm dabei ursprünglich ein einzelner Server auf Port 25 („smtp“) die Rolle von MSA und MTA.
Der dedizierte Port 587 („submission“) wurde erst 1998 eingeführt, um den unterschiedlichen Anforderungen beider Aufgaben gerecht zu werden: Ein MSA akzeptiert ausdrücklich nur Nachrichten berechtigter Nutzer/Server und bereitet sie vor der Einspeisung in das Mailsystem gegebenenfalls standardkonform auf.
Wegen der nahen Verwandtschaft beider Dienste wird die Funktionalität von MSA und MTA üblicherweise immer noch von nur einem Programm, das dann auf beiden Ports Verbindungen annimmt, bereitgestellt.

E-Mail-Routing über SMTP und DNS

Nachdem der SMTP-Server eine E-Mail von einem E-Mail-Client (SMTP-Client) entgegengenommen hat, ist er für das Weiterleiten an den Ziel-SMTP-Server verantwortlich.

Das DNS spielt wie bei den Protokollen HTTP und FTP eine zentrale Rolle.
Im DNS sind spezielle Einträge für die elektronische Post vorhanden.
Das sind die Mail Exchange Records (MX-Records). Über diese Einträge identifiziert der SMTP-Server den Ziel-SMTP-Server der Domain, die in der E-Mail-Adresse des Empfängers angegeben ist.

Der Ablauf des E-Mail-Routings sieht in etwa so aus: Der SMTP-Server fragt einen DNS-Server ab und erhält eine Aufstellung von Mail-Servern, die E-Mails für den Ziel-SMTP-Server entgegennehmen.

Jeder dieser Mail-Server (Mail Exchange) ist mit einer Priorität versehen.
Der SMTP-Server versucht die Mail-Server in der vorgegebenen Reihenfolge zu kontaktieren, um die E-Mail zu übermitteln.

Theoretisch ist es möglich, das eine E-Mail über mehrere dieser Mail Exchanger läuft.

Die MX-Records sollen das Entstehen dieser Mail-Schleifen verhindern.
Trotzdem kann es zu Mail-Schleifen kommen, wenn die MX-Records unvollständig sind oder die Domain zu einem anderen Hoster oder Provider umgezogen ist.

Protokoll

Wie bei allen textbasierten Protokollen, die TCP verwenden, kann mit Hilfe eines Telnet-Client eine E-Mail per SMTP auch „von Hand“ verschickt werden.

Dabei sind, wie auch bei anderen Verfahren, Absender- und Empfängeradresse frei wählbar.
Aus diesem Grund ist die Verlässlichkeit der Absenderangabe einer E-Mail nicht gegeben.
Grundsätzlich können sich die Adressen im MAIL FROM- und RCPT TO-Kommando (sog. Envelope-From bzw. Envelope-To) von den Adressen im From:- und To:-Mailheader unterscheiden.

Der Server antwortet auf Kontaktaufnahmen mit dreistelligen Statusnummern und kurzen Texten, die variieren oder auch entfallen können.

Der Client muss mit festgelegten Zeichenfolgen auf die Statusmeldungen reagieren.
Eine einfache SMTP-Sitzung zum Versenden einer E-Mail kann beispielsweise folgendermaßen aussehen:

Client	Server	Erläuterung
telnet mail.example.com 25		Client ruft Server
	220 service ready	Server meldet sich bereit
HELO foobar.example.net		Client nennt seinen Namen
	250 OK	Server bestätigt
MAIL FROM:<sender@example.org>		Client nennt Absenderadresse
	250 OK	Server bestätigt
RCPT TO:<receiver@example.com>		Client nennt Empfängeradresse
	250 OK	Server bestätigt
DATA		Client kündigt Inhalt der E-Mail an
	354 start mail input	Server bereit für diesen längeren Vorgang
From: <sender@example.org> To: <receiver@example.com> Subject: Testmail Date: Thu, 26 Oct 2006 13:10:50 +0200 Lorem ipsum dolor sit amet, consectetur adipisici elit, sed eiusmod tempor incidunt ut labore et dolore magna aliqua. .		Client sendet Inhalt der E-Mail und markiert das Ende durch eine Zeile, die nur einen Punkt enthält. (Zwischen Header und Textkörper muss eine Leerzeile vorhanden sein, sonst wird beim Empfänger kein Textkörper angezeigt.)
	250 OK	Server bestätigt und übernimmt die Verantwortung für die Nachricht
QUIT		Client fordert Verbindungstrennung an
	221 closing channel	Server kündigt Trennung an

Status-Codes

Das SMTP-Protokoll sieht zum Status der Kommunikation zwischen Mailserver und Mailclient folgende Statuscodes vor:

Status‑Code	Beschreibung
1XX	Mailserver hat die Anforderung akzeptiert, ist aber selbst noch nicht tätig geworden. Eine Bestätigungsmeldung ist erforderlich.
2XX	Mailserver hat die Anforderung erfolgreich ohne Fehler ausgeführt.
3XX	Mailserver hat die Anforderung verstanden, benötigt aber zur Verarbeitung weitere Informationen.
4XX	Mailserver hat einen temporären Fehler festgestellt. Wenn die Anforderung ohne jegliche Änderung wiederholt wird, kann die Verarbeitung möglicherweise abgeschlossen werden.
5XX	Mailserver hat einen fatalen Fehler festgestellt. Die Anforderung kann nicht verarbeitet werden.

Verbotene Zeichenfolge „E-Mail-Ende-Indikator“

Die Zeichenfolge „<CRLF>.<CRLF>“ wird vom empfangenden Server als E-Mail-Ende-Indikator interpretiert, sie kann daher vom User nicht versendet werden.

Die Überprüfungsregel einer empfangenen Mail-Textzeile lautet nach RFC 821 Abschnitt 4.5.2.
im Detail: Wenn die Zeile aus einem einzelnen Punkt besteht, wird sie als E-Mail-Ende-Indikator behandelt.
Wenn das erste Zeichen ein Punkt ist und es andere Zeichen in der Zeile gibt, wird das erste Zeichen gelöscht.

Extended SMTP

Als SMTP 1982 in RFC 821 definiert wurde, gab es eine überschaubare Anzahl von Hosts im Internet.

Da die Verbindungen langsam und instabil waren, wurde auf Zuverlässigkeit großer Wert gelegt. Authentifizierung war nicht vorgesehen, somit war jeder Mailserver ein offenes Mail-Relay, über den Mails an jeden anderen Knoten weitergeleitet werden konnten.
Mit der wachsenden Popularität des Internets entstand so das Problem des Spam.

1995 wurde mit Extended SMTP (ESMTP) in RFC 1869 das Protokoll erweitert (zuvor 1993 in RFC 1425 und 1994 in RFC 1651).

Diese Erweiterung erlaubt, dass über ein modulares Konzept weitere Befehle (SMTP-Verben) definiert werden.
Wenn der Client sich beim Server nicht – wie oben gezeigt – mit HELO, sondern mit EHLO (Extended HELO) meldet, teilt der Server ihm im Gegenzug mit, welche Erweiterungen des Protokolls er unterstützt.
Gängige Beispiele hierfür sind STARTTLS (Secure SMTP over TLS), 8BITMIME (8bit-MIMEtransport), DSN (Delivery Status Notifications) und AUTH (SMTP-Auth).

Zur Kryptografie über SSL/TLS wird SMTPS empfohlen, welches einen eigenen TCP-Port benötigt.

Hierfür wurde TCP-Port 465 standardisiert.
Alternativ kann das STARTTLS-Kommando verwendet werden.
Es läuft auf dem gleichen TCP-Port wie unverschlüsseltes SMTP.

Aufbau einer E-Mail

Eine E-Mail besteht aus drei Teilen.

Der Envelope beinhaltet Sender-Adresse und Empfänger-Adresse, die der MTA benötigt.
Es folgt der Header mit Informationen über den E-Mail-Client und die Message-ID.
- Diese besteht aus einer Zahlen-/Buchstaben-Kombination, gefolgt von der Host-Adresse (Domain) des Senders.
Der Body enthält den Nachrichten-Text der E-Mail.

Beispiel einer E-Mail

Die hier dargestellte E-Mail wurde von sender@beispiel.org an empfaenger@beispiel.org versendet.

Return-path: <sender@beispiel.org>
Envelope-to: <empfaenger@beispiel.org>
Delivery-date: Mon, 08 Mar 2004 21:30:15 +0100
Received: from [212.227.126.205] (helo=mail.beispiel.org)
by mail.beispiel.org with esmtp (Exim 3.35 #1)
id 1B0ROB-0002PO-00
for empfaenger@beispiel.org; Mon, 08 Mar 2004 21:30:15 +0100
Received: from [80.138.34.215] (helo=INTERN)
by mail.beispiel.org with asmtp (Exim 3.35 #1)
id 1B0ROB-0005zH-00
for empfaenger@beispiel.org; Mon, 08 Mar 2004 21:30:15 +0100
Message-ID: <000501c4054c$2b1f4720$0ca8a8c0@INTERN>
From: "Name" <sender@beispiel.org>
To: <empfaenger@beispiel.org>
Subject: Text in der Betreffzeile
Date: Mon, 8 Mar 2004 21:30:06 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-15"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Provags-ID: beispiel.org <abuse@beispiel.org>
auth:0a897c3f2fd8d0ba166f9ea6c6001711

Hallo,

das ist eine kurze Nachricht.


Mit freundlichen Grüßen

Protokoll einer abgebrochenen E-Mail-Übertragung

In diesem Kommunikationsprotokoll wird die Verbindung abgebrochen, weil der Benutzername beim Empfangsserver nicht existiert.

Wed 2008-01-09 11:15:07: Parsing message <xxxxxxxxxxxxxxxxxxxxxxxx\pd50013101218.msg>
Wed 2008-01-09 11:15:07: * From: sender@beispiel.de
Wed 2008-01-09 11:15:07: * To: empfaenger@beispiel.de
Wed 2008-01-09 11:15:07: * Subject: Nachricht
Wed 2008-01-09 11:15:07: * Message-ID: <E1JCXxQ-0001@mail.beispiel.net>
Wed 2008-01-09 11:15:07: * Route slip host: 10.0.0.1
Wed 2008-01-09 11:15:07: * Route slip port: 25
Wed 2008-01-09 11:15:07: Attempting SMTP connection to [10.0.0.1]
Wed 2008-01-09 11:15:07: Attempting SMTP connection to [10.0.0.1:25]
Wed 2008-01-09 11:15:07: Waiting for socket connection...
Wed 2008-01-09 11:15:07: * Connection established (10.0.0.1:3019 -> 10.0.0.2:25)
Wed 2008-01-09 11:15:07: Waiting for protocol to start...
Wed 2008-01-09 11:15:07: <-- 220 Beispiel SMTP Service. Ready for action at Wed, 9 Jan 2008 11:15:08 +0100
Wed 2008-01-09 11:15:07: --> EHLO mail.beispiel.de
Wed 2008-01-09 11:15:07: <-- 250-mail.beispiel.de Hello mail.beispiel.de ([10.0.0.1]), pleased to meet you
Wed 2008-01-09 11:15:07: <-- 250-SIZE 32768000
Wed 2008-01-09 11:15:07: <-- 250-8BITMIME
Wed 2008-01-09 11:15:07: <-- 250 PIPELINING
Wed 2008-01-09 11:15:07: --> MAIL From:<sender@beispiel.de> SIZE=12001
Wed 2008-01-09 11:15:07: <-- 250 sender@beispiel.de... Sender OK
Wed 2008-01-09 11:15:07: --> RCPT To:<empfaenger@beispiel.de>
Wed 2008-01-09 11:15:07: <-- 550 empfaenger@beispiel.de... No such user
Wed 2008-01-09 11:15:07: --> QUIT

SMTP-Befehle

Die Kommunikation zwischen SMTP-Client und SMTP-Server basiert auf ASCII-Kommandos.

Laut SMTP-Spezifikation muss eine SMTP-Implementierung mindestens die folgenden acht Kommandos unterstützen.

SMTP-Kommando	Beschreibung
HELO/EHLO (Hello/Extended Hello)	HELO bzw. EHLO startet die SMTP-Sitzung und identifiziert den Client am Server.
MAIL	MAIL leitet die Mailübertragung ein und liefert gleich die Absender-Adresse mit.
RCPT (Recipient)	RCPT gibt die Adresse eines oder mehrere Empfänger an. Dieses Kommando kann mehrmals ausgeführt werden.
DATA	Mit DATA wird die Übermittlung der E-Mail-Nachricht eingeleitet. Das Ende der E-Mail-Nachricht wird mit "CRLF.CRLF" gekennzeichnet.
RSET (Reset)	Mit RSET wird die bereits eingeleitete Mailübertragung abgebrochen. Die Verbindung zwischen Client und Server bleibt bestehen.
VRTY (Verify)	Mit VRFY kann die Empfänger-Adresse überprüft werden.
EXPN (Expand)	Die meisten MTAs behandeln EXPN wie VRFY.
NOOP	NOOP bewirkt eine Antwort vom Server. Damit wird die Verbindungstrennung durch einen Timeout verhindert.
QUIT	QUIT beendet die Verbindung zum SMTP-Server. Der Server liefert eine letzte Antwort zurück.

SMTP-Status-Code

Auf jedes Kommando vom SMTP-Client an den SMTP-Server schickt der Server einen 3-stelligen Status-Code mit Klartext-Meldung zurück.

Status‑Code	Beschreibung Englisch	Beschreibung Deutsch
211	System status, or system help reply.	System-Status oder System-Hilfe.
214	Help message.	Hilfe - Informationen zum Ausführen eines Kommandos.
220	Domain service ready. Ready to start TLS.	Server bereit.
221	Domain service closing transmission channel.	Server beendet Verbindung.
250	OK, queuing for node node started. Requested mail action okay, completed.	Kommando ausgeführt.
251	OK, no messages waiting for node node. User not local, will forward to forwardpath.	Keine lokale Mailbox; Weiterleitung an "forward-path".
252	OK, pending messages for node node started. Cannot VRFY user (e.g., info is not local), but will take message for this user and attempt delivery.	Überprüfung der Empfängeradresse nicht möglich; Die Nachricht wird dennoch versendet.
253	OK, messages pending messages for node node started.
354	Start mail input; end with <CRLF>.<CRLF>.	Starte Empfang der Mail; Beenden mit "CRLF". "CRLF".
355	Octet-offset is the transaction offset.
421	Domain service not available, closing transmission channel.	Service nicht verfügbar; Verbindung wird beendet.
432	A password transition is needed.
450	Requested mail action not taken: mailbox unavailable. ATRN request refused.	Aktion nicht ausgeführt - Mailbox nicht verfügbar.
451	Requested action aborted: local error in processing. Unable to process ATRN request now	Aktion abgebrochen - Fehler beim Ausführen.
452	Requested action not taken: insufficient system storage.	Aktion abgebrochen - Nicht genügend System-Speicher.
453	You have no mail.
454	TLS not available due to temporary reason. Encryption required for requested authentication mechanism.
458	Unable to queue messages for node node.
459	Node node not allowed: reason.
500	Command not recognized: command. Syntax error.	Syntax-Fehler - Kommando unbekannt.
501	Syntax error, no parameters allowed.	Syntax-Fehler - Parameter oder Argument falsch.
502	Command not implemented.	Kommando unbekannt / nicht implementiert.
503	Bad sequence of commands.	Falsche Reihenfolge der Kommandos.
504	Command parameter not implemented.	Parameter unbekannt / nicht implementiert.
521	Machine does not accept mail.
530	Must issue a STARTTLS command first. Encryption required for requested authentication mechanism.
534	Authentication mechanism is too weak.
538	Encryption required for requested authentication mechanism.
550	Requested action not taken: mailbox unavailable.	Syntax-Fehler - Kommando unbekannt.
551	User not local; please try forwardpath.	Mailbox nicht lokal; "forward-path" versuchen.
552	Requested mail action aborted: exceeded storage allocation.	Aktion abgebrochen - Fehler bei der Speicherzuweisung.
553	Requested action not taken: mailbox name not allowed.	Aktion nicht ausgeführt - Mailbox-Name nicht erlaubt (Syntax inkorrekt).
554	Transaction failed.	Transaktion fehlgeschlagen (beim Verbindungsaufbau: Kein SMTP-Service verfügbar).

Ablauf beim Versand einer E-Mail

1: > 220 mail.example.com SMTP Foo Mailserver
2: < HELO mail.example.org
3: > 250 Ok
4: < MAIL FROM: hans.muster@example.org
5: > 250 Ok
6: < RCPT TO: foo@example.com
7: > 250 Ok
8: < DATA
9: > 354 End data with .
10: < From: hans.muster@example.org
11: < To: foo@example.com
12: < Subject: Testmail
13: <
14: < Testmail
15: < .
16: > 250 Ok
17: < QUIT
18: > 221 Bye

Analyse des E-Mail-Versands

Direkt nach dem Verbindungsaufbau über TCP meldet sich der SMTP-Server.
Der SMTP-Client meldet sich mit seinem Computernamen an.
Der Server bestätigt den Erhalt und erwartet die Fortführung der Verbindung.
Der Client meldet die Absender-Adresse für den MTA.
Der Server bestätigt den Erhalt und erwartet die Fortführung der Verbindung.
Der Client meldet die Empfänger-Adresse für den MTA.
Der Server bestätigt den Erhalt und erwartet die Fortführung der Verbindung.
Mit DATA leitet der Client das Senden der E-Mail ein.
Der Server teilt dem Client mit, dass er die E-Mail mit einem Punkt (.) abgeschlossen haben will.
1. E-Mail-Zeile
2. E-Mail-Zeile
3. E-Mail-Zeile Der Client signalisiert mit zweimal Zeilenumbruch den eigentlichen Nachrichtentext der E-Mail in der
4. E-Mail-Zeile.
5. E-Mail-Zeile
Die E-Mail wird mit dem Punkt (.) abgeschlossen.
Der Server quittiert den erfolgreichen Empfang der E-Mail.
Der Client beendet die Verbindung zum Server.
Der Server sagt "Auf Wiedersehen".

ESMTP - Extended SMTP

ESMTP ist die Erweiterung von SMTP.

Nutzt ein E-Mail-Client die Erweiterungen von ESMTP, meldet er sich beim SMTP-Server mit dem Kommando EHLO an.
Antwortet der Server mit einer Fehlermeldung kennt er ESMTP nicht und der Client muss sich mit HELO anmelden.
Beherrscht der SMTP-Server die ESMTP-Erweiterungen meldet er mehrere Antwortzeilen mit dem Status-Code 250.
Der Status-Code und die Meldung sind durch einen Bindestrich voneinander getrennt.
In jeder Zeile steht eine spezifizierte Erweiterung, die der SMTP-Server unterstützt.

ESMTP-Befehle

Im folgenden sind einige ESMTP-Befehle beschrieben, die sehr häufig benutzt werden.

Die Tabelle ist also nicht vollständig.

ESMTP‑Kommando	Beschreibung
8BITMIME	Mit 8BITMIME gibt der Server an, dass er die Verwendung des 8-Bit-ASCII-Zeichensatzes im E-Mail-Nachrichtentext erlaubt.
SIZE	Mit SIZE gibt der SMTP-Server die maximale E-Mail-Größe in Byte an, die er akzeptiert.
EHLO	Mit EHLO meldet sich der ESMTP-Client an den SMTP-Server an und teilt ihm auf diese Weise mit, dass er die ESMTP-Erweiterungen beherrscht.
STARTTLS	Mit STARTTLS teilt der Server dem Client mit, dass er die Kryptografie nach TLS beherrscht. Mit dem Kommando STARTTLS leitet der Client dann die Kryptografie ein.

Sicherheitskonzepte

Merkmal	Definition	Konzepte
Zugangskontrolle	Nur zugelassene Benutzer dürfen den Mailserver benutzen	SMTP-After-POP, SMTP-Auth, SMTPS
Echtheitsprüfung	Eindeutige Zuordnung von Absender und Nachricht	PGP, S/MIME (siehe Elektronische Signatur), SPF, DomainKeys
Integrität	Erkennung von Veränderungen beim Versand.	PGP, S/MIME
Vertraulichkeit	Kryptografie der Nachricht	PGP, S/MIME, SSL/TLS

Software

Häufig verwendete SMTP-Server

Siehe auch

Mail Transfer Agent
Mailserver
Bounce Message (Fehlermeldung vom Mailserver)
SMTP-Authentifizierung
On-Demand Mail Relay (ODMR)

Dokumentation

RFC

RFC 821 (SIMPLE MAIL TRANSFER PROTOCOL)
RFC 2821 (SIMPLE MAIL TRANSFER PROTOCOL)
RFC 1845 (SMTP Service Extension for Checkpoint/Restart)
RFC 1870 (SMTP Service Extension for Message Size Declaration)
RFC 1869 (SMTP Service Extensions)
RFC 1894 (An Extensible Message Format for Delivery Status Notifications)
RFC 1985 (SMTP Service Extension for Remote Message Queue Starting – ETRN)
RFC 2034 (SMTP Service Extension for Returning Enhanced Error Codes)
RFC 2047 (Message Header Extensions for Non-ASCII Text)
RFC 2487 (SMTP Service Extension for Secure SMTP over TLS)
RFC 2505 (Anti-Spam Recommendations for SMTP MTAs)
RFC 2554 (SMTP Service Extension for Authentication)
RFC 2606 (Reserved Top Level DNS Names)
RFC 2852 (Deliver By SMTP Service Extension)
RFC 2920 (SMTP Service Extension for Command Pipelining)
RFC 3030 (SMTP Service Extensions for Transmission of Large and Binary MIME Messages)
RFC 3207 (SMTP Service Extension for Secure SMTP over Transport Layer Security)
RFC 3461 (SMTP Service Extension for Delivery Status Notifications (DSNs))
RFC 3463 (Enhanced Status Codes for SMTP)
RFC 3464 (An Extensible Message Format for Delivery Status Notifications)
RFC 3700 (Internet Official Protocol Standards)
RFC 3974 (SMTP Operational Experience in Mixed IPv4/v6 Environments)
RFC 4409 (Message Submission for Mail, führt Port 587 für Message Submission ein)
RFC 5321 (Simple Mail Transfer Protocol)
RFC 5322 (Internet Message Format)
RFC 5336 (SMTP Extension for Internationalized Email Addresses)
RFC 6409 (Message Submission for Mail, Internet Standard, löst RFC 4409 ab)
RFC 6152 (SMTP Service Extension for 8bit-MIMEtransport)
RFC 7505 (A "Null MX" No Service Resource Record for Domains That Accept No Mail)
RFC 8314 (Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access)

Man-Page

Info-Pages

Siehe auch

E-Mail
POP3 - Post Office Protocol
IMAP - Internet Message Access Protocol
HTTP - Hypertext Transfer Protocol
NNTP - Network News Transfer Protocol
FTP - File Transfer Protocol
MIME-Typen - Multipurpose Internet Mail Extensions

Links

Projekt-Homepage

Weblinks