SMTP / POP3 / IMAP #

1. Überblick #

E-Mail besteht technisch nicht aus „einem“ Protokoll, sondern aus mehreren, die unterschiedliche Aufgaben übernehmen. SMTP ist für das Senden und Weiterleiten von E-Mails zuständig, POP3 für das Abrufen von Nachrichten aus einem Postfach, und IMAP für den synchronisierten Zugriff auf Nachrichten, Ordner und Statusinformationen auf dem Mailserver. Genau deshalb tauchen in Mailprogrammen meist getrennte Einstellungen für „Postausgangsserver“ und „Posteingangsserver“ auf. SMTP ist in RFC 5321 beschrieben, POP3 in RFC 1939 und IMAP in aktueller Form in RFC 9051.

Vereinfacht gesagt:

• SMTP = E-Mails verschicken und zwischen Mailservern transportieren
• POP3 = E-Mails abholen, oft eher „download-orientiert“
• IMAP = E-Mails serverbasiert verwalten und zwischen Geräten synchron halten

Ein typischer moderner Mailfluss sieht so aus: Ein Benutzer schreibt in seinem Mailclient eine Nachricht. Der Client übergibt diese per SMTP an den ausgehenden Mailserver. Danach wird die Nachricht über SMTP zum Zielsystem transportiert. Der Empfänger liest sie später entweder per POP3 oder IMAP aus seinem Postfach. SMTP und POP3/IMAP ergänzen sich also, statt dass sie miteinander konkurrieren.

2. Definition und Zweck #

2.1 SMTP #

SMTP steht für Simple Mail Transfer Protocol. Sein Hauptzweck ist der Transport von E-Mails zwischen Systemen. Das betrifft sowohl die Übergabe vom Mailclient an den eigenen Mailserver als auch die Weiterleitung zwischen Mailservern im Internet. SMTP ist also primär ein Sende- und Transferprotokoll, nicht das Protokoll, mit dem ein Benutzer komfortabel sein Postfach durchsucht. RFC 5321 bezeichnet SMTP explizit als Basisspezifikation für den Transport von Internet-E-Mail.

2.2 POP3 #

POP3 steht für Post Office Protocol Version 3. Es wurde dafür entworfen, dass ein Client Nachrichten aus einem Postfach auf einem Server abholt. Das Modell ist eher schlicht: Client verbindet sich, authentifiziert sich, listet Mails auf, lädt sie herunter und löscht sie optional vom Server. RFC 1939 beschreibt POP3 genau mit diesem Ziel eines dynamischen Zugriffs auf ein Maildrop auf einem Serverhost.

2.3 IMAP #

IMAP steht für Internet Message Access Protocol. IMAP ist deutlich umfangreicher als POP3. Es wurde dafür entwickelt, dass E-Mails auf dem Server verbleiben und von mehreren Clients parallel verwaltet werden können. Es unterstützt Ordner, Flags wie gelesen/ungelesen, serverseitige Suche und selektives Laden. Das aktuelle IMAP ist in RFC 9051 spezifiziert, das IMAP4rev2 beschreibt und weitgehend kompatibel zu IMAP4rev1 ist.

3. Grundprinzip – einfach erklärt #

Man kann sich ein E-Mail-System wie einen Postdienst mit Sortierzentrum vorstellen.

Absender-Mailclient
   |
   | SMTP
   v
Absender-Mailserver
   |
   | SMTP
   v
Empfänger-Mailserver
   | \
   |  \__ POP3
   |      oder
   \_____ IMAP
          v
     Empfänger-Mailclient

SMTP ist in diesem Bild der Teil, der Briefe annimmt und zwischen Postzentren transportiert. POP3 ist wie „Postfach leeren und Briefe mitnehmen“. IMAP ist wie „im Postamt arbeiten, ohne die Briefe dauerhaft mitzunehmen“: Du siehst denselben Bestand von mehreren Orten aus, kannst Briefe markieren, sortieren und in Ordner verschieben. Diese Trennung passt genau zum Design der drei Protokolle.

Der wichtigste gedankliche Unterschied ist daher nicht nur „verschicken vs. empfangen“, sondern auch welches Nutzungsmodell dahintersteht:

• SMTP: Transport
• POP3: Abruf
• IMAP: Synchronisierte Verwaltung auf dem Server

4. Technische Funktionsweise im Detail #

4.1 SMTP Schritt für Schritt #

Wenn ein Client eine E-Mail versendet, läuft technisch meist Folgendes ab:

1. Der Client baut eine TCP-Verbindung zum SMTP-Server auf.
2. Der Server meldet sich mit einem Banner.
3. Der Client identifiziert sich mit EHLO oder HELO.
4. Optional werden Fähigkeiten des Servers erkannt, etwa Erweiterungen oder Authentifizierungsoptionen.
5. Der Client authentifiziert sich gegebenenfalls.
6. Der Client übermittelt Absender und Empfänger mit MAIL FROM und RCPT TO.
7. Mit DATA beginnt die Übertragung des Nachrichteninhalts.
8. Der Server bestätigt die Annahme der Nachricht.
9. Der Client beendet die Sitzung mit QUIT. Dieses dialogorientierte Modell ist typisch für SMTP nach RFC 5321.

Ein vereinfachtes SMTP-Beispiel sieht so aus:

S: 220 mail.example.org ESMTP ready
C: EHLO client.example.org
S: 250-mail.example.org
S: 250-AUTH PLAIN LOGIN
S: 250 STARTTLS
C: STARTTLS
... TLS-Aufbau ...
C: EHLO client.example.org
C: AUTH LOGIN
C: MAIL FROM:<alice@example.org>
C: RCPT TO:<bob@example.net>
C: DATA
C: Subject: Test
C: From: alice@example.org
C: To: bob@example.net
C:
C: Hallo Bob
C: .
S: 250 Message accepted
C: QUIT

Dieses Muster zeigt sehr gut, dass SMTP textbasiert und zustandsorientiert arbeitet. Erweiterungen werden über das EHLO-Verfahren angekündigt, was RFC 5321 ebenfalls ausdrücklich behandelt.

SMTP zwischen Servern #

Zwischen Mailservern läuft SMTP ebenfalls, aber mit einem anderen Schwerpunkt. Hier geht es nicht mehr um einen Benutzer, sondern um die Zustellung an das richtige Zielsystem. Der sendende Mailserver ermittelt typischerweise anhand von DNS-MX-Einträgen, welcher Server für die Empfängerdomain zuständig ist, und versucht dann dort per SMTP zuzustellen. SMTP ist also das Transport-Rückgrat des E-Mail-Systems. RFC 5321 behandelt sowohl Mail Submission als auch Relay- und Delivery-Aspekte.

Submission vs. Relay #

In der Praxis unterscheidet man häufig zwischen:

• Mail Submission vom Client zum eigenen Provider
• Server-to-Server SMTP für die Weiterleitung

Daher gibt es oft unterschiedliche Ports und Sicherheitsvorgaben. Submission ist meist authentifiziert und für Endnutzer gedacht, während klassisches SMTP-Relay zwischen Mailservern andere Anforderungen hat. Diese Trennung ist in der heutigen Mailpraxis Standard, auch wenn die Grundmechanik weiterhin SMTP ist.

4.2 POP3 Schritt für Schritt #

POP3 ist deutlich einfacher aufgebaut. RFC 1939 beschreibt im Kern drei Zustände:

• Authorization
• Transaction
• Update

Ein typischer POP3-Ablauf:

1. Client verbindet sich mit dem POP3-Server.
2. Server sendet Begrüßung.
3. Client authentifiziert sich mit USER und PASS oder einer Erweiterung.
4. Client kann per STAT die Anzahl und Größe der Nachrichten abfragen.
5. Mit LIST werden Nachrichten aufgelistet.
6. Mit RETR werden einzelne Nachrichten abgerufen.
7. Mit DELE werden Nachrichten zum Löschen markiert.
8. Beim QUIT werden markierte Nachrichten im Update-Zustand tatsächlich gelöscht. Diese Logik ist zentral für POP3.

Beispiel:

S: +OK POP3 server ready
C: USER max
S: +OK
C: PASS geheim
S: +OK mailbox locked and ready
C: STAT
S: +OK 2 3456
C: LIST
S: +OK
S: 1 1200
S: 2 2256
S: .
C: RETR 1
S: +OK 1200 octets
S: [Nachrichteninhalt]
S: .
C: DELE 1
S: +OK message 1 deleted
C: QUIT
S: +OK

Dieses Beispiel zeigt auch die Philosophie von POP3: eher linear, eher simpel, eher auf „abholen“ ausgerichtet. RFC 1939 betont genau diesen eher einfachen Zugriff auf ein serverseitiges Maildrop.

Warum POP3 historisch sinnvoll war #

POP3 stammt aus einer Zeit, in der viele Benutzer nicht dauerhaft online waren. Man holte die Mails ab, las sie lokal und trennte dann die Verbindung. Genau für dieses Modell ist POP3 effizient: geringe Komplexität, wenig Serverlogik, klare Abläufe. Auch heute kann POP3 noch sinnvoll sein, wenn ein einzelnes Gerät Mails lokal archivieren soll und keine echte Synchronisation zwischen mehreren Clients gebraucht wird. Das Grunddesign des Protokolls spiegelt genau diese Herkunft.

4.3 IMAP Schritt für Schritt #

IMAP ist deutlich umfangreicher, weil es nicht nur Nachrichten liefert, sondern das Postfach selbst als persistenten Datenbestand auf dem Server verwaltet. RFC 9051 beschreibt ein umfangreiches Kommando-/Antwortmodell mit Mailboxen, Statusinformationen, Suchfunktionen, Flags und Erweiterbarkeit.

Ein vereinfachter IMAP-Ablauf:

1. Client baut Verbindung auf.
2. Server sendet Begrüßung.
3. Client authentifiziert sich.
4. Client wählt eine Mailbox, z. B. INBOX.
5. Client listet Nachrichten, ruft Header oder Teile einer Nachricht ab.
6. Client setzt Flags wie \Seen.
7. Client verschiebt Nachrichten zwischen Mailboxen oder sucht serverseitig.
8. Sitzung wird beendet. Diese Arbeitsweise ist typisch für IMAP und deutlich mächtiger als POP3.

Beispiel:

S: * OK IMAP server ready
C: A001 LOGIN max geheim
S: A001 OK LOGIN completed
C: A002 SELECT INBOX
S: * 42 EXISTS
S: * 3 RECENT
S: A002 OK [READ-WRITE] SELECT completed
C: A003 FETCH 1 BODY[HEADER]
S: * 1 FETCH (BODY[HEADER] {342}
   [Headerdaten]
)
S: A003 OK FETCH completed
C: A004 STORE 1 +FLAGS (\Seen)
S: A004 OK STORE completed
C: A005 LOGOUT
S: * BYE IMAP server logging out
S: A005 OK LOGOUT completed

Warum IMAP komplexer ist #

IMAP muss viel mehr leisten als POP3:

• Ordner verwalten
• Status synchron halten
• mehrere Geräte gleichzeitig bedienen
• Teildownloads ermöglichen
• serverseitige Suche unterstützen
• UIDs und Nachrichtennummern verwalten

Das erklärt, warum IMAP in der Praxis leistungsfähiger, aber auch komplexer in Implementierung und Fehlersuche ist. RFC 9051 beschreibt IMAP ausdrücklich als aufwärtskompatible Weiterentwicklung mit reichhaltigen Funktionen.

5. Wichtige Bestandteile / Mechanismen / Konzepte #

5.1 Ports #

Die klassischen Ports sind:

SMTP selbst ist standardisiert; in der Praxis werden für Mail Submission häufig Port 587 und historisch oder praxisnah auch 465 für implizites TLS genutzt. POP3 nutzt klassisch 110 und POP3S 995, IMAP 143 und IMAPS 993. Diese Portnutzung ist gängige Implementierungspraxis rund um die jeweiligen Protokolle; SMTP als Transportprotokoll selbst ist in RFC 5321 definiert, POP3 in RFC 1939 und IMAP in RFC 9051.

5.2 Authentifizierung #

Sowohl SMTP-Submission als auch POP3 und IMAP benötigen in realen Umgebungen fast immer Authentifizierung. Historisch gab es einfache Login-Mechanismen, heute werden bevorzugt abgesicherte Varianten und TLS eingesetzt. POP3-Erweiterungen für Fähigkeiten und optionale Auth-Mechanismen sind etwa in RFC 2449 und SASL-bezogene Authentifizierung für POP3 in RFC 5034 beschrieben; IMAP und SMTP kennen ebenfalls Erweiterungsmodelle.

5.3 TLS / STARTTLS #

Ein sehr wichtiges Thema ist Verschlüsselung. Es gibt grob zwei Modelle:

• Explizites TLS per STARTTLS: Verbindung startet unverschlüsselt, wird dann per Kommando auf TLS umgestellt
• Implizites TLS: Verbindung ist von Anfang an verschlüsselt

SMTP zeigt per EHLO, ob STARTTLS unterstützt wird. Auch bei POP3 und IMAP gibt es entsprechende Sicherheitsmodelle in der Praxis. Für moderne E-Mail-Kommunikation ist TLS faktisch Standard, weil sonst Zugangsdaten und Inhalte auf dem Transportweg leichter angreifbar wären. RFC 5321 deckt SMTP-Erweiterungsmechanismen ab; POP3- und IMAP-Ökosysteme nutzen ebenfalls standardisierte und verbreitete Sicherheits-Extensions.

5.4 Mailboxen, Flags und UIDs bei IMAP #

IMAP unterscheidet sich von POP3 besonders durch serverseitige Zustandsverwaltung. Nachrichten haben Flags wie „gelesen“, „beantwortet“ oder „markiert“, und Clients arbeiten mit stabilen Identifikatoren, damit mehrere Geräte den gleichen Bestand konsistent sehen können. Diese Konzepte sind Kernelemente des IMAP-Designs in RFC 9051.

5.5 Einfachheit vs. Synchronisation #

POP3 ist einfacher, weil es nur auf Abruf ausgerichtet ist. IMAP ist mächtiger, weil es Synchronisation ermöglicht. SMTP wiederum ist der Transportbaustein und hat einen ganz anderen Zweck. Viele Missverständnisse entstehen gerade daraus, dass diese drei Rollen verwechselt werden.

6. Einsatzgebiete in der Praxis #

SMTP wird überall dort eingesetzt, wo E-Mails verschickt oder zwischen Servern weitergeleitet werden. Das betrifft Mailclients, Newsletter-Systeme, Webanwendungen mit Kontaktformularen, Monitoring-Systeme, Scan-to-Mail-Geräte, Business-Software und praktisch jeden Mailserver im Internet. Ohne SMTP gäbe es keine standardisierte Übertragung von E-Mail zwischen Systemen.

POP3 wird heute noch genutzt, wenn ein Benutzer oder eine Organisation bewusst ein einfaches Modell möchte: Nachrichten werden auf ein einzelnes Gerät geladen, eventuell lokal archiviert und auf dem Server entfernt. In Umgebungen mit nur einem Hauptgerät oder sehr einfachen Clients kann das weiterhin sinnvoll sein. RFC 1939 passt genau zu diesem Abrufmodell.

IMAP ist heute meist die bessere Wahl für Smartphones, Laptops, Webmailer und Desktop-Clients gleichzeitig. Es erlaubt, dass Ordnerstruktur, Gelesen-Status und Teilmengen von Nachrichten auf allen Geräten konsistent bleiben. Genau diese serverzentrierte Verwaltung ist die Stärke von IMAP nach RFC 9051.

7. Mehrere ausführliche Praxisbeispiele #

7.1 Beispiel: Eine E-Mail von Outlook/Thunderbird an Gmail senden #

Ausgangssituation: Ein Benutzer schreibt lokal in einem Mailclient eine Nachricht an einen Empfänger mit Gmail-Adresse. Der Benutzer klickt auf „Senden“. Für den Benutzer sieht das trivial aus, technisch passiert aber eine Kette mehrerer Schritte.

Ablauf:

1. Der Client verbindet sich mit dem SMTP-Submission-Server des Providers.
2. Der Server fordert Identifikation und meist Authentifizierung.
3. Die Nachricht wird mit SMTP-Kommandos und anschließendem DATA übertragen.
4. Der sendende Server prüft, wohin die Nachricht zugestellt werden muss.
5. Er ermittelt den zuständigen Ziel-Mailserver der Empfängerdomain.
6. Die Nachricht wird per SMTP dorthin weitertransportiert.
7. Der empfangende Server legt die Mail im Postfach des Empfängers ab.
8. Der Empfänger ruft sie später per IMAP oder POP3 ab. Genau dieser mehrstufige Ablauf folgt direkt dem Design von SMTP als Transportprotokoll.

Bedeutung: Dieses Beispiel zeigt, dass SMTP nicht nur „aus dem Client raus“ arbeitet, sondern auch „zwischen Servern“. Es erklärt außerdem, warum Versand- und Empfangseinstellungen getrennt sind. POP3 oder IMAP sind am Versand selbst gar nicht beteiligt; sie kommen erst später ins Spiel, wenn das Zielpostfach gelesen wird.

7.2 Beispiel: POP3 auf einem einzigen Büro-PC #

Ausgangssituation: In einem kleinen Unternehmen existiert ein zentrales Info-Postfach, das nur an einem Desktop-Rechner benutzt wird. Die Mitarbeiter wollen alle eingehenden Nachrichten lokal archivieren und möglichst wenig Serverplatz verbrauchen.

Ablauf:

1. Das Mailprogramm verbindet sich per POP3 mit dem Mailserver.
2. Es authentifiziert sich.
3. Es listet neue Mails auf.
4. Es lädt die Nachrichten vollständig herunter.
5. Optional werden die Nachrichten auf dem Server gelöscht.
6. Das Archiv liegt danach lokal auf dem Büro-PC.

Warum das sinnvoll sein kann: POP3 ist für genau dieses Modell gedacht. Es ist leichtgewichtig, leicht verständlich und passt gut zu „ein Postfach, ein primäres Gerät“. Der Nachteil wird sofort sichtbar, sobald mehrere Geräte ins Spiel kommen: Dann sind Status und Bestände nicht mehr sauber synchron. Diese Grenze folgt direkt aus dem POP3-Design.

7.3 Beispiel: IMAP auf Laptop, Smartphone und Tablet gleichzeitig #

Ausgangssituation: Ein Benutzer liest berufliche E-Mails unterwegs auf dem Smartphone, beantwortet sie später am Laptop und möchte, dass alles auf allen Geräten denselben Stand hat.

Ablauf:

1. Alle Geräte verbinden sich per IMAP mit demselben Serverpostfach.
2. Die Ordnerstruktur liegt zentral auf dem Server.
3. Der Benutzer öffnet auf dem Smartphone eine Mail; der Server speichert den Gelesen-Status.
4. Am Laptop erscheint dieselbe Mail danach ebenfalls als gelesen.
5. Verschiebt der Benutzer die Mail in einen Projektordner, sehen das die anderen Geräte ebenfalls.
6. Anhänge oder Nachrichtenteile können selektiv geladen werden, statt immer alles vollständig herunterzuladen.

Warum das wichtig ist: Genau hier zeigt IMAP seinen größten Mehrwert. Das Postfach ist nicht bloß eine Downloadquelle, sondern der zentrale Wahrheitsbestand. Das ist der Grund, warum IMAP im Alltag fast immer die bessere Wahl für Mehrgeräte-Szenarien ist. RFC 9051 beschreibt dafür die nötigen Mailbox- und Zustandsmechanismen.

7.4 Beispiel: Kontaktformular einer Webseite #

Ausgangssituation: Eine Firmenwebseite hat ein Kontaktformular. Wenn ein Besucher etwas absendet, soll intern eine E-Mail an das Support-Team versendet werden.

Ablauf:

1. Die Webanwendung erzeugt serverseitig eine Nachricht.
2. Sie übergibt diese an einen SMTP-Server.
3. Der SMTP-Server nimmt die Nachricht an und stellt sie weiter zu.
4. Das Support-Team liest sie später per IMAP oder POP3.

Bedeutung: Dieses Beispiel zeigt, dass SMTP nicht nur von klassischen Mailprogrammen verwendet wird. Viele Systeme versenden automatisiert: Ticketsysteme, Monitoring, Multifunktionsdrucker, Shopsysteme, CRM-Tools. SMTP ist damit ein grundlegender Infrastrukturbaustein.

8. Typische Probleme, Fehler und Missverständnisse #

Ein sehr häufiger Fehler ist die Verwechslung von SMTP und IMAP/POP3. Viele Benutzer denken, „E-Mail funktioniert nicht“, obwohl nur der Postausgangsserver falsch konfiguriert ist. Technisch muss man immer unterscheiden: Geht es um das Senden oder um das Abrufen/Synchronisieren? SMTP-Probleme betreffen den Versand, POP3-/IMAP-Probleme den Empfang oder die Postfachdarstellung.

Ein weiteres typisches Problem sind falsche Ports oder falsche Sicherheitsmodi. Wird etwa ein TLS-Port mit einer unverschlüsselten Einstellung kombiniert oder umgekehrt, schlägt die Verbindung fehl. In Mailclients sind deshalb Einstellungen wie „SSL/TLS“, „STARTTLS“ oder „keine“ oft die eigentliche Fehlerquelle und nicht Benutzername oder Passwort. Dass SMTP, POP3 und IMAP in unterschiedlichen Varianten und Erweiterungen arbeiten, macht diese Fehler in der Praxis sehr häufig.

Bei POP3 ist das größte Missverständnis oft die Annahme, es synchronisiere wie IMAP. Das tut es nicht. POP3 ist in seinem Kern auf Abruf ausgelegt. Zwar können Clients Mails auf dem Server belassen, aber das macht POP3 nicht zu einem echten Synchronisationsprotokoll mit Ordnern, Flags und konsistenter Mehrgeräteverwaltung. Diese Unterschiede ergeben sich direkt aus RFC 1939 versus RFC 9051.

Bei IMAP wiederum erwarten manche Benutzer, dass jede Aktion sofort überall sichtbar ist. In der Praxis hängt das auch vom Client, von Caching-Strategien und von der Serverimplementierung ab. IMAP ist mächtig, aber komplexer als POP3; dadurch entstehen auch komplexere Fehlerbilder. Die Größe des Protokolls und die vielen Erweiterungen tragen dazu bei.

9. Sicherheit / Risiken #

Historisch wurden viele Mailprotokolle ohne ausreichende Transportverschlüsselung betrieben. Das bedeutete, dass Zugangsdaten und Inhalte auf dem Transportweg potenziell mitgelesen werden konnten. Heute ist TLS deshalb praktisch unverzichtbar. SMTP unterstützt Erweiterungsmechanismen wie STARTTLS, und auch POP3 und IMAP werden üblicherweise in abgesicherten Varianten betrieben.

Ein reales Risiko liegt in falsch konfigurierten SMTP-Servern. Wenn ein Server unkontrolliert Relay erlaubt, kann er zum Spam-Versand missbraucht werden. Moderne SMTP-Umgebungen verhindern das durch Authentifizierung, Relay-Regeln und weitere Schutzmechanismen. SMTP ist als Transportprotokoll bewusst offen genug für Mailrouting, muss aber in der Praxis sauber abgesichert werden.

Bei POP3 und IMAP liegt das Sicherheitsrisiko besonders in schwachen Passwörtern, fehlender Verschlüsselung oder unsicheren Alt-Clients. Zusätzlich ist IMAP wegen seiner serverzentrierten Natur attraktiv für Angreifer: Wer Zugriff auf ein IMAP-Konto erhält, bekommt meist den kompletten Bestand des Postfachs inklusive Ordnerhistorie. Gerade deshalb sind starke Authentifizierung, TLS und gute Zugriffskontrolle wichtig. RFC 9051 und die zugehörigen Erweiterungen zeigen, wie umfangreich und damit sicherheitsrelevant moderne Mailzugriffe geworden sind.

10. Vergleich mit ähnlichen Technologien #

10.1 POP3 vs. IMAP #

Dieser Vergleich ergibt sich direkt aus der unterschiedlichen Zielsetzung beider Protokolle: POP3 ist bewusst einfach, IMAP bewusst funktionsreich. RFC 1939 und RFC 9051 spiegeln diese grundverschiedenen Philosophien klar wider.

10.2 SMTP vs. POP3/IMAP #

SMTP ist mit POP3 oder IMAP eigentlich nicht direkt vergleichbar, weil es einen anderen Zweck erfüllt. SMTP transportiert und übergibt Nachrichten. POP3 und IMAP erlauben dem Benutzer, auf das empfangene Postfach zuzugreifen. Wer diese Rollen sauber trennt, versteht Mailarchitekturen deutlich besser.

10.3 Senden ist nicht gleich Speichern im „Gesendet“-Ordner #

Ein praktischer Sonderfall: Das Versenden per SMTP bedeutet nicht automatisch, dass die Nachricht im gesendeten Ordner eines Kontos sauber auf allen Geräten auftaucht. Diese serverseitige Sicht auf Ordner und Zustände ist typischerweise eine Stärke von IMAP. In modernen Umgebungen arbeiten Client und Server daher oft so zusammen, dass Versand über SMTP erfolgt, die Verwaltung des Sent-Ordners aber per IMAP sichtbar bleibt. Das ist ein gutes Beispiel dafür, wie die Protokolle zusammenspielen statt sich zu ersetzen.

11. Praxis-Teil #

11.1 SMTP mit Telnet oder OpenSSL testen #

Unverschlüsselter Test auf einem SMTP-Port:

telnet mail.example.org 25

Dann kann man eine Sitzung manuell nachstellen:

EHLO test.local
MAIL FROM:<alice@example.org>
RCPT TO:<bob@example.net>
DATA
Subject: TestmailHallo Welt
.
QUIT

Das eignet sich hervorragend zum Verständnis, weil man das textbasierte Protokoll direkt sieht. SMTP nach RFC 5321 ist dafür besonders anschaulich, da die Kommandos und Antwortcodes klar lesbar sind.

TLS-Variante mit OpenSSL:

openssl s_client -connect mail.example.org:465

oder mit STARTTLS:

openssl s_client -starttls smtp -connect mail.example.org:587

Damit lässt sich prüfen, ob der Server TLS korrekt anbietet und welches Zertifikat präsentiert wird. Solche Tests sind in der Praxis sehr nützlich, wenn ein Mailclient nur „Verbindung fehlgeschlagen“ meldet. Die SMTP-Erweiterungslogik aus RFC 5321 ist dafür die Grundlage.

11.2 POP3 testen #

Mit OpenSSL auf einem TLS-Port:

openssl s_client -connect mail.example.org:995

Danach kann man, falls der Server es zulässt, manuell typische Befehle testen:

USER max
PASS geheim
STAT
LIST
RETR 1
QUIT

Das hilft, Authentifizierungsprobleme, Erreichbarkeit oder Rechteprobleme einzugrenzen. Die Befehlsstruktur stammt direkt aus RFC 1939.

11.3 IMAP testen #

Mit OpenSSL:

openssl s_client -connect mail.example.org:993

Danach kann man grundlegende IMAP-Kommandos ausführen:

A001 LOGIN max geheim
A002 SELECT INBOX
A003 FETCH 1 BODY[HEADER]
A004 LOGOUT

IMAP ist dadurch etwas schwerer manuell zu testen als POP3, aber genau solche Tests zeigen sehr gut, dass IMAP nicht nur „Nachrichten runterlädt“, sondern serverseitig mit Mailboxen arbeitet. RFC 9051 liefert dafür das Protokollmodell.

11.4 Typische reale Fehleranalyse #

Wenn Versand nicht funktioniert, geht man sinnvollerweise so vor:

1. Stimmt Servername?
2. Stimmt Port?
3. Stimmt Sicherheitsmodus?
4. Funktioniert TLS?
5. Ist Authentifizierung korrekt?
6. Akzeptiert der Server die Absenderadresse?
7. Gibt es eine genaue SMTP-Fehlermeldung oder einen Reply-Code?

Bei Empfangsproblemen mit POP3/IMAP prüft man:

1. Sind Zugangsdaten korrekt?
2. Stimmt der richtige Eingangsserver?
3. Ist TLS/SSL korrekt gesetzt?
4. Ist das Konto gesperrt oder Passwort abgelaufen?
5. Sind Ordner oder Status nur lokal gecacht?
6. Wird POP3 statt IMAP verwendet und deshalb kein sauberer Sync erreicht?

Diese Vorgehensweise passt sehr gut zur unterschiedlichen Architektur der Protokolle.

12. Fazit #

SMTP, POP3 und IMAP gehören zusammen, erfüllen aber klar unterschiedliche Rollen. SMTP ist das Protokoll für den Versand und Transport von E-Mails. POP3 ist ein schlichtes Abrufprotokoll, das gut zu einfachen „ein Gerät lädt Mails herunter“-Szenarien passt. IMAP ist das deutlich modernere und flexiblere Protokoll für serverseitige Postfachverwaltung und Mehrgeräte-Synchronisation. Diese Einteilung ist nicht nur Praxiswissen, sondern direkt in den offiziellen Protokollspezifikationen angelegt.

Für ein modernes Setup gilt meist:

• SMTP für den Versand
• IMAP für den Empfang und die Verwaltung
• POP3 nur noch dann, wenn das einfache Download-Modell bewusst gewünscht ist

Wer diese Rollen sauber versteht, versteht auch den Kern moderner E-Mail-Infrastruktur.