Skip Navigation

E-Mail Protokolle

Für die technisch Interessierten möchten wir hier gerne eine Reihe von technischen Details der verschiedenen E-Mail Protokolle zeigen. Diese Informationen sind keineswegs vollständig, bieten aber sicher dem einen oder anderen Anhaltspunkte für eine weitere Vertiefung.

Sollten Sie Fragen oder Ergänzungen haben, die auf diesen Seiten nicht erläutert werden, so bedienen Sie sich bitte unseres Formulars.

Bitte beachten Sie, dass diese Seite zu Ihrer freien Verfügung steht und gemäß der GNU Free Documentation License verwendet werden kann. (Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License Version 1.1.).

POP3

Das POP3-Protokoll (Post Office Protocol Version 3) ist neben IMAP (Internet Message Access Protocol, vgl. RFC 2060) das Standard-Protokoll zum Empfang von E-Mails (vgl. RFC 1939).

POP3 ist ein Client-Server-Protokoll. Üblicherweise beginnt die Übertragung von E-Mail Nachrichten damit, dass ein Client (ein E-Mail Programm wie Outlook, Eudora, Mozilla Thunderbird, aber auch ein Web-Interface wie zeitform Services Webmail) sich mit dem POP3-Server auf Port 110 verbindet. Der Server bestätigt die Anfrage durch eine Meldung in der Art 

Server: +OK <1017.997873531@mail.zeitform-services.de>

und wartet dann auf die Übermittlung der Benutzerdaten (Benutzerkennung und Passwort) durch den Client. 

Client: USER benutzer@zeitform-services.de
Server: +OK
Client: PASS geheimes_passwort
Server: +OK

Stimmen die übermittelten Benutzerdaten wie im Beispiel mit den gespeicherten Daten überein, kann der Client die Nachrichten abfragen. Mit dem Befehl STAT kann der Client die Anzahl und Größe der gespeicherten E-Mails erfragen, 

Client: STAT
Server: +OK 24 3260090

mit dem Befehl LIST erhält er diese Informationen für jede vorhandenen Nachricht. 

Client: LIST
Server: +OK
        1 57739
        2 199077
        3 341012
        4 196786
        5 2680
        6 349421
        [... usw.]

Zum Übertragen der Nachrichten auf den lokalen Rechner verwendet der Client für jede vorhandene E-Mail Nachricht den Befehl RETR nummer, woraufhin der Server den vollständigen Text der E-Mail überträgt. 

Client: RETR 1
Server: +OK
        [E-Mail Nachricht 1 wird Übertragen]
Client: DELE 1
Server: +OK
Client: RETR 2
Server: +OK
        [E-Mail Nachricht 2 wird Übertragen]
Client: DELE 2
Server: +OK
        [... usw.]

Mit dem Befehl DELE nummer wird die Nachricht nach dem Empfang auf dem Server gelöscht. Dies ist nicht zwingend vorgeschrieben, aber in der Regel üblich, da die E-Mails bei der nächsten Verbindung sonst erneut übertragen werden würden. Mit QUIT wird die Verbindung schließlich beendet. 

Client: QUIT
Server: +OK
Verbindung beendet.

Die Beschreibung weiterer (auch optionaler) Befehle entnehmen Sie bitte der POP3-Spezifikation unter RFC 1939.

APOP

Das POP3-Protokoll verwendet zur Authentisierung des Benutzers dessen Benutzerkennung sowie sein E-Mail Passwort. Dieses Passwort wird dabei im Klartext übertragen und kann unter Umständen von Dritten abgehört und zum unberechtigten Lesen oder Löschen von E-Mails verwendet werden. 

Server: +OK <1017.997873531@mail.zeitform-services.de>
Client: USER benutzer@zeitform-services.de
Server: +OK
Client: PASS geheimes_passwort
Server: +OK

Die Verwendung von APOP beseitigt diese Sicherheitslücke dadurch, dass der Client statt der Befehlsfolge USER/PASS den Befehl APOP benutzerkennung prüfsumme verwendet. 

Server: +OK <1017.997873531@mail.zeitform-services.de>
Client: APOP benutzer@zeitform-services.de 69cd75fb958e7958da34922f05cc3057
Server: +OK

Die übertragene Prüfsumme wird vom Client über eine nicht umkehrbare kryptographische Funktion (MD5-digest) aus dem E-Mail Passwort und dem Datumsstempel (im Beispiel <1017.997873531@mail.zeitform-services.de>) der Server-Begrüßung (die sich stetig ändert) berechnet. Aus diesem »digest« kann nicht auf das Passwort geschlossen werden. Der Server, der das Passwort kennt, kann den »digest« auf die selbe Weise nachberechnen und auf Richtigkeit prüfen. Damit ist der Benutzer authentisiert.

Das folgende Perl-Skript berechnet die Prüfsumme für eine APOP-Authentisierung: 

#!/usr/bin/perl -w
use Digest::MD5  qw(md5_hex);

my $stamp = '<1017.997873531@mail.zeitform-services.de>';
my $secret = 'geheimes_passwort';

print md5_hex($stamp . $secret);  # 69cd75fb958e7958da34922f05cc3057

SMTP

Während das POP3-Protokoll für das Abholen von E-Mails vom Mailserver zurständig ist, übernimmt das SMTP-Protokoll (Simple Mail Transfer Protocol) die Auslieferung der E-Mails vom lokalen Rechner an den Mailserver, aber auch die Weiterleitung der E-Mails von dort an den Mailserver des Empfängers (vgl. RFC 2821).

Zu diesem Zweck verbindet sich der sendende Rechner (Client) an Port 25 des empfangenden Mailservers (Server). Der Server antwortet mit einer Begrüßungsmeldung, 

Server: 220 mail.zeitform-services.de SMTP

die der Client seinerseits mit einer Begrüßung beantwortet, bei der er seinen Hostnamen sendet. 

Client: HELO my.host.com
Server: 250 mail.zeitform-services.de

Die vom SMTP-Server gesendeten Zahlen repräsentieren Fehler- bzw. Erfolgsmeldungen, die der Client kennen und verstehen muss.

Einige typische Meldungen (vgl.RFC 2821)

  • 220 – Service bereit
  • 221 – Schließe Übertragungskanal
  • 250 – Angeforderte Mail-Aktion verfügbar
  • 354 – Beginne Mail-Übertragung; beende mit CRLF.CRLF

Nach der Begrüßungsphase sendet der Client seine Absender-Adresse sowie eine oder mehrere Empfänger-Adressen: 

Client: MAIL FROM: benutzer@zeitform-services.de
Server: 250 ok
Client: RCPT TO: empfaenger@host.de
Server: 250 ok
Client: RCPT TO: anderer_empfaenger@somewhere.com
Server: 250 ok

Der Befehl DATA initialisiert die Übermittlung des E-Mail Textes, die mit einem Punkt (.) auf einer sonst leeren Zeile abgeschlossen werden muss. 

Client: DATA
Server: 354 go ahead
Client: [hier folgt der Text der E-Mail mit allen Headern]
Client: .
Server: 250 ok 997887680 qp 2592

Nach dem Senden weiterer E-Mails beendet der Client die Verbindung mit dem Befehl QUIT. 

Client: QUIT
Server: 221 mail.zeitform-services.de
Verbindung beendet.

Die Beschreibung weiterer (auch optionaler) Befehle entnehmen Sie bitte der SMTP-Spezifikation unter RFC 2821.

POP3 AUTH bzw. SMTP AUTH

Sowohl das SMTP- (resp. das ESMTP-) Protokoll als auch das POP3-Protokoll wurden durch entsprechende RFCs (RFC 2554 bzw. RFC 1734) um einen Authentisierungs-Mechanismus erweitert, der die Verwendung des Schlüsselwortes AUTH und die Einbindung von SASL-Methoden (Simple Authentication and Security Layer, RFC 2222) in regulären ESMTP- bzw. POP3-Sitzungen ermöglicht.

Bislang wurden in dieser kurzen Übersicht lediglich die POP3-Authentisierung mittels eines Benutzernamens und eines Passwortes bzw. die APOP-Authentisierung über den »digest« aus Zeitstempel und Passwort erläutert. POP3 AUTH bietet weitergehende Mechanismen an.

Das SMTP-Protokoll sieht in seinem ursprünglichen Entwurf keine Authentisierung vor, was in der Hauptsache darauf zurückzuführen ist, dass es in den frühen Tagen des Internets unangenehme Erscheinungen wie »Spam« nicht gab. Für den Versand von E-Mails ist eine Authentisierung nicht notwendig (»open relay«). Mittlerweile sind viele Betreiber von SMTP-Servern dazu übergegangen, die Nutzung ihrer Server aus Sicherheitsgründen einzuschränken, z.B.:

  • E-Mails können nur an lokale User verschickt werden.
  • E-Mails können nur verschickt werden, nachdem der Benutzer über POP3 E-Mails empfangen hat (SMTP-after-POP3).
  • E-Mails können nur verschickt werden, nachdem der Benutzer sich über SMTP AUTH authentisiert hat.

Verfügt ein SMTP-Server über entsprechende Möglichkeiten zur Benutzerauthentisierung über SMTP AUTH, so wird er dies in aller Regel dem Client mitteilen: 

Server: 220 mail.zeitform-services.de ESMTP
Client: EHLO my.host.com
Server: 250-mail.zeitform-services.de
        250-AUTH LOGIN CRAM-MD5 PLAIN
        250-AUTH=LOGIN CRAM-MD5 PLAIN
        250-PIPELINING
        250 8BITMIME

In seiner Begrüßungsmeldung teilt der Server dem Client mit, dass er über »ESMTP Service Extensions« verfügt, eine Erweiterung des SMTP-Standards, die u.a. für SMTP AUTH benötigt wird. Mit dem Schlüsselwort EHLO (einem Anagramm von HELO) werden diese Erweiterungen vom Client aktiviert.

Daraufhin sendet der Server eine Liste der unterstützten Erweiterungen: im Beispiel die Erweiterungen »AUTH« mit den Optionen (SASL-Methoden) »LOGIN«, »CRAM-MD5« und »PLAIN«, sowie »PIPELINING« und »8BITMIME«, die hier nicht näher erläutert werden sollen (siehe RFC 1854 für »PIPELINING« und RFC 1652 für »8BITMIME«). An der gesendeten Liste kann der Client ersehen, welche Erweiterungen und speziell welche Authentisierungsmethoden der Server unterstützt. Es steht dem Client frei, eine oder mehrere dieser Optionen zu verwenden.

Der Client initialisiert die Authentisierung mit dem Schlüsselwort AUTH und dem Namen der gewünschten SASL-Methode. Wird die Methode vom Server nicht unterstützt, so antwortet er mit einer entsprechenden Fehlermeldung, bei SMTP z.B. mit: 

Client: AUTH FOOBAR
Server: 504 auth type unimplemented (#5.5.1)
        535 authorization failed (#5.7.0)

oder bei POP3 z.B. mit 

Client: AUTH FOOBAR
Server: -ERR unsupported method

Wird die Authentisierungsmethode unterstützt, sendet der Server die jeweilige Meldung an den Client, die den Authentisierungsprozess einleitet. Die entsprechenden Verfahren werden in den nächsten Abschnitten exemplarisch erläutert.

Nach der erfolgreichen Authentisierung kann der Client mit dem Übertragen bzw. Empfangen der E-Mails beginnen.

Authentisierung über AUTH LOGIN

AUTH LOGIN verwendet für die Authentisierung des Benutzers den base64-codierten Benutzernamen und das ebenfalls codierte Passwort des Benutzers. Die Codierung mit base64 dient dabei lediglich dem Schutz übertragener Sonderzeichen, so dass Username und Passwort faktisch im Klartext übertragen werden.

Nach der Anforderung von AUTH LOGIN durch den Client, sendet der Server den String »VXNlcm5hbWU6« (»Username:« in base64-Codierung) und erwartet seinerseits den Usernamen als Antwort. Im Anschluß sendet der Server den String »UGFzc3dvcmQ6« (»Password:« in base64-Codierung) und erwartet das Senden des Passwortes durch den Client. Stimmen die Angaben mit den serverseitig gespeicherten Werten überein, ist der Benutzer authentisiert und kann mit der Übertragung der Daten beginnen. 

Server: 220 mail.zeitform-services.de ESMTP
Client: EHLO my.host.com
Server: 250-mail.zeitform-services.de
        250-AUTH LOGIN CRAM-MD5 PLAIN
        250-AUTH=LOGIN CRAM-MD5 PLAIN
        250-PIPELINING
        250 8BITMIME
Client: AUTH LOGIN
Server: 334 VXNlcm5hbWU6              ['Username:']
Client: YmVudXR6ZXJAemVpdGZvcm0uZGU=  ['benutzer@zeitform-services.de']
Server: 334 UGFzc3dvcmQ6              ['Passwort:']
Client: Z2VoZWltZXNfcGFzc3dvcnQ=      ['geheimes_passwort']
Server: 235 ok, go ahead (#2.0.0)

Die folgenden beiden kleinen Perl-Skripte führen eine manuelle base64-Codierung durch: 

#/usr/bin/perl -w
use MIME::Base64;

my $string = 'benutzer@zeitform-services.de';
print encode_base64($string);    # YmVudXR6ZXJAemVpdGZvcm0uZGU=

bzw. 

#/usr/bin/perl -w
use MIME::Base64;

my $string = 'YmVudXR6ZXJAemVpdGZvcm0uZGU=';
print decode_base64($string);    # benutzer@zeitform-services.de

Nach Möglichkeit sollten Sie die Verwendung von AUTH LOGIN ebenso vermeiden, wie die ausschließliche Verwendung von POP3, da in beiden Fällen Ihr Passwort im Klartext übertragen wird.

Authentisierung über AUTH CRAM-MD5

AUTH CRAM-MD5 verwendet zur Authentisierung einen Frage-Antwort-Mechanismus (CRAM, Challenge-Response Authentication Mechanism) basierend auf dem Zeitstempel des Servers und dem Benutzer-Passwort unter Zuhilfenahme der kryptographischen Prüfsummen-Funktion MD5 (message digest 5). Die Einzelheiten werden in RFC 2195 beschrieben und sollen hier nur skizzenhaft dargestellt werden.

Nach der Initialiserung der Authentisierung über das Schlüsselwort AUTH CRAM-MD5 sendet der Server einen base64-codierten Zeitstempel (analog APOP). Der Client berechnet aus diesem Zeitstempel und seinem Passwort mit der folgenden Funktion eine Prüfsumme und gibt diese zusammen mit seinem Benutzernamen (erneut base64-codiert) an den Server zurück. 

MD5 (( passwort XOR opad ), MD5 (( passwort XOR ipad ), zeitstempel ))

Die Bedeutung der Werte »opad« und »ipad« können dem RFC 2104 entnommen werden.

Das folgende Beispiel gibt eine Authentisierung über CRAM-MD5 wieder: 

Server: 220 mail.zeitform-services.de ESMTP
Client: EHLO my.host.com
Server: 250-mail.zeitform-services.de
        250-AUTH LOGIN CRAM-MD5 PLAIN
        250-AUTH=LOGIN CRAM-MD5 PLAIN
        250-PIPELINING
        250 8BITMIME
Client: AUTH CRAM-MD5
Server: 334 PDQwMzYuMTA3NjMyNDM4MUBndWlsZGVuc3Rlcm4uemVpdGZvcm0uZGU+
Client: YmVudXR6ZXJAemVpdGZvcm0uZGUgMmQ5MzczZGZkOTFlMmU2NjMxYzhlMWFkNjk4MzRmYWQ=
Server: 235 ok, go ahead (#2.0.0)

Mit dem folgenden Perl-Skript kann die CRAM-MD5-Prüfsumme berechnet werden: 

#!/usr/bin/perl -w
use Digest::HMAC_MD5 qw(hmac_md5_hex);
use MIME::Base64;

my $user = 'benutzer@zeitform-services.de';
my $secret = 'geheimes_passwort';
my $stamp = 'PDQwMzYuMTA3NjMyNDM4MUBndWlsZGVuc3Rlcm4uemVpdGZvcm0uZGU+';

my $decoded_stamp = decode_base64($stamp);
   # <4036.1076324381@guildenstern.zeitform-services.de>
my $hmac = hmac_md5_hex($decoded_stamp, $secret);
   # 2d9373dfd91e2e6631c8e1ad69834fad
my $answer = encode_base64($user . ' ' . $hmac);
   # YmVudXR6ZXJAemVpdGZvcm0uZGUgMmQ5MzczZGZkOTFlMmU2NjMxYzhlMWFkNjk4MzRmYWQ=
print $answer;

Bei der Authentisierung mit CRAM-MD5 wird das Benutzerpasswort nicht im Klartext übertragen und eine Berechnung aus dem gesendeten »digest« ist nicht möglich. Damit ist CRAM-MD5 ein für diese Zwecke sicheres Verfahren.

Authentisierung über AUTH PLAIN

Auch bei einer Authentisierung über AUTH PLAIN werden wie bei AUTH LOGIN Benutzerkennung und Passwort im Klartext übertragen. Das zugrunde liegende RFC 2595 rät daher von einer Verwendung ohne weitere Sicherheitsstufen (z.B. SSL) ab.

Anders als bei AUTH LOGIN sendet der Client nach der Authentisierungsanforderung einen einzigen (base64-codierten) String bestehend aus:
Benutzerkennung <NUL> Authentisierungskennung <NUL> passwort.
Da Benutzerkennung und Authentisierungskennung in unserem Fall identisch sein werden, vereinfacht sich die Zeichensequenz zu:
<NUL> Benutzerkennung <NUL> passwort.
<NUL> stellt dabei das nicht sichtbare ASCII-Zeichen 0 (0x00) dar. Ein Beispiel verdeutlicht den Vorgang: 

Server: 220 mail.zeitform-services.de ESMTP
Client: EHLO my.host.com
Server: 250-mail.zeitform-services.de
        250-AUTH LOGIN CRAM-MD5 PLAIN
        250-AUTH=LOGIN CRAM-MD5 PLAIN
        250-PIPELINING
        250 8BITMIME
Client: AUTH PLAIN
Server: 334 ok, go on
Client: AGJlbnV0emVyQHplaXRmb3JtLmRlAGdlaGVpbWVzX3Bhc3N3b3J0
          ['<NUL>benutzer@zeitform-services.de<NUL>geheimes_passwort']
Server: 235 ok, go ahead (#2.0.0)

Das folgende Perl-Skript generiert den Authentisierungsstring: 

#/usr/bin/perl -w
use MIME::Base64;

my $username = 'benutzer@zeitform-services.de';
my $password = 'geheimes_passwort';
print encode_base64("\000" . $username . "\000" . $password);
   # AGJlbnV0emVyQHplaXRmb3JtLmRlAGdlaGVpbWVzX3Bhc3N3b3J0

Empfohlene Literatur

Bitte beachten Sie auch die Literaturhinweise innerhalb der genannten RFCs.

Sie können die oben aufgeführten Bücher durch Anklicken des Links »bei Amazon.de bestellen« direkt bestellen. Bitte beachten Sie dabei, dass Sie uns damit eine Werbeprovision von 7,5% des Verkaufspreises zukommen lassen. Für Sie entstehen keine zusätzlichen Kosten. Vielen Dank.

Amazon.de

| Mailserver | Webserver | Weitere Infos | Kontakt |
| Startseite | Mailserver | Webserver | Weitere Infos | Kontakt |