LinkedIn
Instagram
WhatsApp
Telegramm
Google Kalender
Slack-Gemeinschaft beitretenWas ist eigentlich eine IMAP-Serververbindung
Eine IMAP-Serververbindung ist eine persistente TCP-Sitzung zwischen einem E-Mail-Client und einem Mailserver, die das Internet Message Access Protocol (IMAP) verwendet, um E-Mail-Nachrichten, die remote gespeichert sind, zu synchronisieren, abzurufen und zu verwalten – ohne sie vom Server herunterzuladen oder zu löschen.
Anders als POP3, das entwickelt wurde, um Nachrichten lokal herunterzuladen und optional vom Server zu löschen, IMAP wurde für die Synchronisation entwickelt. Jeder Lese-, Flag-, Verschiebe- oder Löschvorgang, den Sie lokal durchführen, wird auf dem Server reflektiert – und somit auf jedem Gerät, das mit demselben Postfach verbunden ist. Deshalb hat sich IMAP zum De-facto-Protokoll für moderne E-Mail-Clients entwickelt.
Auf Netzwerkebene öffnet eine IMAP-Serververbindung einen TCP-Socket zu einem Mailserver (typischerweise Port 993 für SSL/TLS oder Port 143 für STARTTLS), führt einen TLS-Handshake durch, authentifiziert den Benutzer (über Passwort, App-Passwort oder OAuth 2.0 XOAUTH2) und tritt dann in eine Zustandsmaschine ein: Nicht authentifiziert, Authentifiziert, Ausgewählt (in einem E-Mail-Ordner), oder Abmelden. Die meisten nützlichen Befehle – FETCH, SEARCH, STORE, COPY, EXPUNGE – funktionieren nur im Selected-Zustand.
Für Entwickler, die E-Mail-Integrationen erstellen, ist eine IMAP-Serververbindung der grundlegendste Baustein. Sie stellen diese her, authentifizieren sie, wählen eine Mailbox aus und fragen dann neue Nachrichten ab oder warten auf sie (Polling oder IDLE). Dieser Leitfaden behandelt jeden Schritt: den richtigen Host und Port für jeden Anbieter, die korrekte Authentifizierungsmethode im Jahr 2026 (OAuth wird zunehmend obligatorisch) und eine vollständige Referenz zur Fehlerbehebung für die häufigsten Fehlerquellen.
IMAP-Ports erklärt: 143, 993 und wann STARTTLS in Ordnung ist
Es gibt genau zwei IMAP-Ports in aktiver Nutzung: 993 (Implizites TLS, der moderne Standard) und 143 (STARTTLS-Upgrade oder Klartext, was die meisten Server nicht mehr zulassen). Den Unterschied zu kennen ist wichtig, da die Verwendung des falschen Ports eine der häufigsten Ursachen für Verbindungsfehler bei der Erstellung einer IMAP-Integration ist.
Der Client verbindet sich und leitet sofort einen TLS-Handshake ein, bevor IMAP-Daten ausgetauscht werden. Der gesamte Datenverkehr ist vom ersten Byte an verschlüsselt. Dies ist die richtige Standardeinstellung für jede neue Integration.
Der Client verbindet sich im Klartext und sendet dann eine STARTTLS Befehl zum Upgrade auf TLS. Die meisten modernen Server erfordern dieses Upgrade und lehnen reine Textverbindungen vollständig ab.
Empfehlung 2026: immer Port verwenden 993 mit SSL_CONTEXT (implizites TLS). Wenn Sie gegen einen unternehmensinternen IMAP-Server entwickeln, der nur Port 143 bereitstellt, aktivieren Sie STARTTLS und überprüfen Sie das Serverzertifikat. Verbinden Sie sich niemals über Klartext mit einem IMAP-Server in einer Produktionsumgebung – Anmeldedaten werden unverschlüsselt übertragen und die meisten Anbieter lehnen solche Verbindungen inzwischen grundsätzlich ab.
Eine kurze Notiz zu RFC 9051 (IMAP4rev2), veröffentlicht im August 2021 als Nachfolger von RFC 3501. IMAP4rev2 schreibt TLS für jede Verbindung, die Anmeldeinformationen überträgt, formal vor, veraltet auf MD5 basierende Authentifizierungsmechanismen und entfernt die LISTE-ERWEITERT Inkompatibilitäten, die in älteren Clients zu subtilen Fehlern führten. Die meisten großen Cloud-Anbieter (Gmail, Outlook) waren schon Jahre vor der Finalisierung des RFC in der Praxis IMAP4rev2-kompatibel. Für praktische Zwecke zielen Sie auf Port 993 + TLS ab und Sie werden standardmäßig RFC 9051-konform sein.
Host- und Porteinstellungen-Tabelle - Gmail, Outlook, Yahoo, iCloud, Zoho, Fastmail, AOL, ProtonMail Bridge
Die nachstehende Tabelle listet die korrekten IMAP-Server-Verbindungseinstellungen für die am weitesten verbreiteten E-Mail-Anbieter auf. Alle Werte wurden Stand Mai 2026 mit der offiziellen Dokumentation des jeweiligen Anbieters abgeglichen. Verwenden Sie diese als schnelles Nachschlagewerk bei der Konfiguration eines IMAP-Clients oder beim Erstellen eines IMAP API-Integration.
| Anbieter | IMAP-Host | Hafen | Verschlüsselung | OAuth 2.0 (XOAUTH2) | Notizen |
|---|---|---|---|---|---|
 Google Mail |
imap.gmail.com | 993 | SSL/TLS | Ja (erforderlich für neue Apps) |
App-Passwörter funktionieren, aber OAuth wird dringend bevorzugt. Aktivieren Sie zuerst IMAP in den Gmail-Einstellungen. |
 Outlook / Microsoft 365 |
outlook.office365.com | 993 | SSL/TLS | Ja (Basic Auth wird im Dezember 2026 veraltet sein) |
Basic Auth Ende-des-Lebenszyklus Dezember 2026 für alle Mandanten. Migrieren Sie jetzt zu OAuth. |
Yahoo Mail |
imap.mail.yahoo.com | 993 | SSL/TLS | Ja |
App-Passwort erforderlich, wenn 2FA aktiviert ist. OAuth über das Entwicklerportal von Yahoo. |
iCloud Mail |
imap.mail.me.com | 993 | SSL/TLS | Nein (nur app-spezifisches Passwort) |
Apple benötigt ein App-spezifisches Passwort von appleid.apple.com. Keine OAuth XOAUTH2-Unterstützung. |
Zoho Mail |
imap.zoho.com | 993 | SSL/TLS | Ja |
OAuth über Zoho Accounts API. IMAP muss pro Postfach in den Zoho Mail-Einstellungen aktiviert sein. |
Fastmail |
imap.fastmail.com | 993 | SSL/TLS | Ja (JMAP bevorzugt) |
Fastmail unterstützt JMAP nativ (schneller als IMAP), aber IMAP wird vollständig unterstützt. App-Passwörter verfügbar. |
AOL Mail |
imap.aol.com | 993 | SSL/TLS | Ja |
Jetzt Teil von Yahoo Inc. App-Passwort erforderlich, wenn 2FA aktiviert. OAuth über das Entwicklerportal von Yahoo. |
ProtonMail Bridge |
127.0.0.1 | 1143 | STARTTLS | Nein (Bridge Token-Authentifizierung) |
ProtonMail Bridge läuft lokal und stellt einen lokalen IMAP-Server bereit. Nicht für serverseitige Integrationen geeignet. |
Generisches IMAP |
your-mail-server.com | 993 / 143 | SSL/TLS STARTTLS | Variiert (Serverkonfiguration prüfen) |
Dovecot, Postfix, Zimbra, Courier. Überprüfen Sie die CAPABILITY-Antwort Ihres Servers auf unterstützte Authentifizierungsmechanismen. |
Google Mail
Outlook / Microsoft 365
Hinweis zu ProtonMail: Die Bridge-Architektur bedeutet, dass ProtonMail IMAP-Verbindungen nur für Desktop-Einrichtungen mit einzelnen Benutzern rentabel sind. Für Multi-Account- oder serverseitige Integrationen wird ProtonMail über Standard-IMAP effektiv nicht unterstützt. Für Gmail und Outlook in größerem Maßstab siehe unsere speziellen Anleitungen zu OAuth für E-Mail-APIs und Microsoft Graph API-E-Mail.
Schritt für Schritt: Öffnen einer rohen IMAP-Serververbindung
Unten sind minimale, funktionierende Beispiele, wie man eine authentifizierte IMAP-Serververbindung mit Pythons integriertem imaplib und Node.js mit imapflow. Beide Beispiele stellen über Port 993 eine Verbindung zu Gmail her und verwenden dabei die Authentifizierung per App-Passwort. Informationen zu OAuth XOAUTH2 finden Sie weiter unten unter H2 #7.
import imaplib
import SSL
# IMAP-Server-Einstellungen
IMAP_HOST = "imap.gmail.com"
IMAP_PORT = 993
BENUTZERNAME = "you@gmail.com"
PASSWORT = "dein-app-passwort" Das Passwort für die #-App, nicht das Passwort für dein Konto
# SSL-Kontext erstellen (Zertifikate überprüfen)
Kontext = ssl.Standardkontext erstellen()
# SSL-Verbindung auf Port 993 öffnen
mit imaplib.IMAP4_SSL(IMAP_HOST, IMAP_PORT, ssl_context=Kontext als imap:
# Authentifizieren
imap.Anmelden(BENUTZERNAME, PASSWORT)
# Posteingang auswählen (gibt die Anzahl der Nachrichten zurück)
Status, Daten = imap.Auswählen("Posteingang")
print(Posteingang hat {data[0].decode()} Nachrichten")
# Suche nach verborgenen Botschaften
Status, Nachrichten-IDs = imap.Suche(Nichts, "UNSEEN")
print(Unbekannt: {msg_ids[0].decode()}")
# Abmelden (Verbindung wird am Ende des 'with'-Blocks geschlossen)// npm install imapflow
import { ImapFlow } from 'imapflow';
const client = new ImapFlow({
Gastgeber: 'imap.gmail.com',
Port 993,
sicher true, // SSL/TLS auf Port 993
auth: {
Benutzer: 'you@gmail.com',
Pass 'dein-app-passwort'
},
Protokollierer falsch
});
await Klient.verbinden();
// Sperre die INBOX-Mailbox für exklusiven Zugriff
lassen Schloss = await Klient.getMailboxLock('POSTeingang');
versuchen {
// Lädt die letzten 5 Nachrichten (nur Kopfzeilen)
für await (lassen Nachricht von Klient.fetch('1:5', { Umschlag: true })) {
Konsole.log(Betreff der Nachricht);
}
} endlich {
Schloss.Veröffentlichung();
}
await Klient.abmelden();Das Python-Beispiel verwendet IMAP4_SSL - die höhere SSL-Wrapper-Schicht, die den TLS-Handshake automatisch verwaltet. Vermeiden Sie die Verwendung von IMAP4 + Handbuch starttls() für Cloud-Anbieter, da es Komplexität ohne Nutzen hinzufügt. Für Node.js, imapflow ist die moderne, Promise-basierte Wahl (die ältere node-imap Bibliothek wird seit 2024 nicht mehr gepflegt und unterstützt XOAUTH2 nicht.
Beide Beispiele verwenden App-Passwörter, den einfachsten Anmeldetyp für schnelle Tests. Für Produktionssysteme, die mehrere Benutzer verarbeiten, benötigen Sie OAuth 2.0 – siehe den Abschnitt XOAUTH2 unten. Für eine vollständige, produktionsreife Lösung, ohne rohe IMAP-Verbindungen zu verwalten, siehe IMAP API Entwicklerhandbuch.
Umgehe die IMAP-Standardformulierungen. Unipile bietet Ihnen Lesen, Senden und Synchronisieren über Gmail, Outlook und IMAP in einer einzigen REST-API – keine Verbindungsverwaltung erforderlich.
IMAP-Boilerplate überspringen – Bauen Sie es mit UnipileAuthentifizierung: Passwort, App-Passwort und OAuth 2.0 (XOAUTH2)
Eine IMAP-Serververbindung erfordert nach dem TLS-Handshake eine Authentifizierung. Heute werden drei Authentifizierungsmethoden verwendet – jede mit einem anderen Sicherheitsprofil, Komplexitätsgrad und Kompatibilität mit Cloud-Anbietern im Jahr 2026.
Der ursprüngliche IMAP AUTH PLAIN / LOGIN-Mechanismus. Sie senden die E-Mail-Adresse und das Passwort des Kontos direkt an den IMAP-Server. Einfach zu implementieren, aber aus Sicherheitsgründen zunehmend von Cloud-Anbietern blockiert.
Veraltet für CloudEin 16-stelliger Token, der vom Anbieter (Gmail, Yahoo, iCloud) generiert wird und das eigentliche Kontopasswort ersetzt. Funktioniert mit demselben IMAP LOGIN-Befehl wie Basic Auth, ist aber begrenzt und kann unabhängig widerrufen werden. Erforderlich, wenn 2FA aktiviert ist.
Akzeptabel für den persönlichen GebrauchDer Nutzer autorisiert Ihre App über einen Zustimmungsbildschirm. Ihre App erhält ein Zugriffstoken (kurzlebig, typischerweise 1 Stunde), das Sie Base64-kodieren und an den IMAP AUTHENTICATE XOAUTH2-Befehl übergeben. Tokens werden mit einem langlebigen Refresh-Token aktualisiert. Die einzig praktikable Methode für Produktions-Apps mit mehreren Nutzern.
Benötigt für die ProduktionWann welches verwenden: Verwenden Sie App-Passwörter während der lokalen Entwicklung und für persönliche Tools. Verwenden Sie OAuth 2.0 XOAUTH2 für jede Multi-User-Integration – dies ist die einzige skalierbare Methode, da Sie niemals Benutzerpasswörter speichern und jedes Token widerrufen werden kann, ohne das Passwort des Benutzers zu ändern. Für Gmail schränkt Google seit 2022 schrittweise die Basisauthentifizierung für "weniger sichere Apps" ein. Für Microsoft/Outlook ist die Abschaffung der Basisauthentifizierung für alle Mandanten für Dezember 2026 geplant (siehe nächster Abschnitt).
Für eine detaillierte Betrachtung der OAuth-Flows – einschließlich Token-Austausch, Refresh-Logik und Scopes – siehe unser Leitfaden zu OAuth für E-Mail-APIs. Für die Microsoft-spezifische OAuth-Einrichtung siehe Microsoft Graph OAuth für Outlook.
Das 2026-Problem: Abschaffung der Microsoft Basic Auth (Dezember 2026)
Wenn Ihre IMAP-Integration eine direkte Verbindung zu Microsoft 365- oder Outlook-Konten über Benutzername und Passwort herstellt, befinden Sie sich auf einer Zeitbombe. Microsoft hat das endgültige End-of-Life-Datum für die Basisauthentifizierung für IMAP, POP3 und SMTP für alle Tenants angekündigt.
Laut Microsoft Learn und die Microsoft Community Hub Ankündigung, Exchange Online wird die Basisauthentifizierung für IMAP, POP3 und SMTP im Dezember 2026 vollständig deaktivieren über alle Mandanten hinweg – einschließlich derjenigen mit bestehenden Ausnahmen. Jeder IMAP-Client oder jede serverseitige Integration, die weiterhin die Benutzername/Passwort-Authentifizierung verwendet, wird nicht mehr funktionieren. Es ist keine weitere Verlängerung verfügbar.
Aktionsschritte zur Migration vor der Frist
Durchsuche deinen Code nach IMAP-Verbindungen, die verwenden Anmelden(Benutzername, Passwort) oder AUTH PLAIN. Überprüfen Sie die Anmeldeprotokolle von Microsoft Entra ID (früher Azure AD) auf IMAP-Basic-Auth-Aktivitäten.
Erstellen Sie eine App-Registrierung unter portal.azure.com mit dem IMAP.ZugriffAlsBenutzer.Alle (delegiert) oder IMAP.ZugriffAlsApp (Anwendung) Berechtigung. Siehe Microsoft Graph OAuth für Outlook für eine Schritt-für-Schritt-Anleitung.
Verwenden Sie MSAL (Microsoft Authentication Library), um Zugriffstoken zu erwerben. Implementieren Sie die Token-Aktualisierungslogik – Microsoft-Token laufen nach 1 Stunde ab, und Sie benötigen einen Aktualisierungstoken-Flow, um langlebige IMAP-Sitzungen ohne erneute Benutzerauthentifizierung aufrechtzuerhalten.
Ersetzen Sie IMAP ANMELDUNG Befehl mit AUTHENTIFIZIEREN XOAUTH2 mit einem Base64-kodierten Token-String. Siehe die vollständige Codebeispiel im Abschnitt XOAUTH2 unten.
Microsoft bietet eine Möglichkeit, die Basissignatur-Authentifizierung frühzeitig mandantenweise zu deaktivieren – nutzen Sie dies, um Ihren OAuth-Flow vor dem erzwungenen Stichtag im Dezember 2026 zu testen, damit Sie keine Produktionsprobleme unter Zeitdruck beheben müssen.
Wenn Sie IMAP-Verbindungen für mehrere Microsoft 365-Benutzer verwalten – ein gängiges Szenario für CRM-, ATS- oder Vertriebsautomatisierungstools – wird die Migrationskomplexität schnell größer. Sie müssen OAuth-Zustimmungsabläufe für jeden Benutzer handhaben, Token sicher speichern und aktualisieren und mit bedingten Zugriffsbeschränkungen umgehen, die Ihre App in einigen Mandanten möglicherweise blockieren. Dies ist einer der Hauptgründe, warum Entwickler eine verwaltete IMAP-API wählen, anstatt Rohverbindungen selbst zu warten.
Microsoft Basic Auth-Frist rückt näher. Bauen Sie noch heute einen zukunftssicheren OAuth-Flow mit der einheitlichen E-Mail-API von Unipile – wir kümmern uns um Token-Aktualisierung, Mandantenfähigkeit und XOAUTH2 für Sie.
Zukunftssicheren OAuth-Flow erstellenVerbindung über OAuth XOAUTH2
XOAUTH2 ist der SASL-Mechanismus, mit dem Sie eine IMAP-Serververbindung mithilfe eines OAuth 2.0-Zugriffstokens anstelle eines Passworts authentifizieren können. Das Token wird über den Standard-OAuth-Autorisierungscode-Flow (oder Client-Anmeldeinformationen für Dienstkonten) abgerufen, Base64-kodiert in einem bestimmten Format und an den übergeben. AUTHENTIFIZIEREN XOAUTH2 IMAP-Befehl.
Gmail (Google)Microsoft 365import imaplib, base64, json
from google.oauth2.anmeldeinformationen import Berechtigungsnachweise
from google.auth.transport.requests import Anfrage
#: Zuvor ermittelte OAuth-Anmeldedaten laden
# (aus dem Google-Auth-Oauthlib-Ablauf)
Referenzen = Anmeldeinformationen(
Token=ACCESS_TOKEN,
Aktualisierungsschlüssel=REFRESH_TOKEN,
Token-URI="https://oauth2.googleapis.com/token",
client_id=CLIENT_ID,
kunden_geheimnis=CLIENT_SECRET,
Geltungsbereiche=["https://mail.google.com/"]
)
# Aktualisierung des Tokens bei Ablauf
wenn creds.expired:
Guthaben.auffrischen(Anfrage())
# XOAUTH2-Zeichenkette erstellen: "user={email}\x01auth=Bearer {token}\x01\x01""
Benutzer-E-Mail = "user@gmail.com"
auth_string = f"user={user_email}\x01auth=Bearer {creds.token}\x01\x01"
auth_b64 = Base64.b64encode(auth_string.kodieren()).decode()
# IMAP-Verbindung herstellen und authentifizieren
mit imaplib.IMAP4_SSL("imap.gmail.com", 993) als imap:
imap.authentifizieren("XOAUTH2", Lambda _: auth_b64)
imap.Auswählen("Posteingang")
print("Verbunden über XOAUTH2")import imaplib, base64
from msal import VertraulicheClientAnwendung
# Token über MSAL abrufen (Client-Anmeldeinformationen-Ablauf für Dienstkonten)
# Verwenden Sie für den vom Benutzer delegierten Zugriff stattdessen den Auth-Code-Ablauf
app = VertraulicheClientAnwendung(
client_id=CLIENT_ID,
Autorität=https://login.microsoftonline.com/{TENANT_ID}",
client_credential=CLIENT_SECRET
)
Ergebnis = App.Token für Client erwerben(
Geltungsbereiche=["https://outlook.office365.com/.default"]
)
Zugriffstoken = Ergebnis["Zugriffstoken"]
# XOAUTH2-Zeichenkette erstellen
Benutzer-E-Mail = "user@company.com"
auth_string = f"Benutzer={user_email}\x01auth=Bearer {access_token}\x01\x01"
auth_b64 = Base64.b64encode(auth_string.kodieren()).decode()
# Mit Outlook über IMAP verbinden
mit imaplib.IMAP4_SSL("outlook.office365.com", 993) als imap:
imap.authentifizieren("XOAUTH2", Lambda _: auth_b64)
imap.Auswählen("Posteingang")
print("Via XOAUTH2 mit Outlook verbunden")Wichtige Unterschiede zwischen Gmail und Microsoft XOAUTH2: Gmail erfordert das https://mail.google.com/ scope (voller Gmail-Zugriff). Microsoft benötigt IMAP.ZugriffAlsBenutzer.Alle (delegiert) oder IMAP.ZugriffAlsApp (Anwendung). Das XOAUTH2-Format in Base64 ist für beide Anbieter identisch: Benutzer={email}\x01auth=Bearer {token}\x01\x01.
Ein wichtiger Implementierungsdetail: Token verfallen nach 3600 Sekunden. Eine langlaufende IMAP IDLE-Sitzung (siehe den nächsten Abschnitt) empfängt einen Authentifizierungsfehler, wenn das Token mitten in der Sitzung abläuft. Sie müssen diesen Fehler abfangen. AUTHENTIFIZIERUNGFEHLGESCHLAGEN Fehler, aktualisieren Sie das Token mit Ihrem Refresh-Token und stellen Sie dann die IMAP-Verbindung wieder her. Diese Wiederholungsschleife ist nicht trivial und ist ein Hauptgrund, warum Teams eine verwaltete API wie Leitfaden zur Unified Email API anstelle von rohen IMAP-Verbindungen.
Für eine vollständige Anleitung zum Einrichten von OAuth bei Microsoft, einschließlich Überlegungen zu bedingten Zugriffrichtlinien, siehe unsere Microsoft Graph OAuth für Outlook Leitfaden.
OAuth XOAUTH2 in 10 Zeilen. 1. OAuth 2.0 ist ein Autorisierungsframework. 2. XOAUTH2 ist eine Erweiterung für Gmail und Google Workspace. 3. Sie ermöglicht einem Client, auf Ressourcen im Namen eines Nutzers zuzugreifen. 4. Ohne dass der Nutzer seine Anmeldedaten preisgeben muss. 5. Der Client erhält ein Zugriffstoken von Google. 6. Dieses Token wird dann bei der Authentifizierung mit dem Mailserver verwendet. 7. Der eigentliche Übertrag erfolgt über SASL (Simple Authentication and Security Layer). 8. XOAUTH2 ist ein Mechanismus innerhalb von SASL. 9. Es vermeidet die Notwendigkeit, das Google-Passwort direkt im Mail-Client einzugeben. 10. Dies erhöht die Sicherheit und den Datenschutz. Unipile übernimmt die automatische Token-Akquise, -Aktualisierung und IMAP-Re-Authentifizierung. Sie konzentrieren sich auf das Lesen von E-Mails, nicht auf die Verbindungsverwaltung.
Erstelle OAuth XOAUTH2 in 10 Zeilen mit Unipile: 1. Importiere die notwendigen Unipile-Module. 2. Erstelle ein Unipile-Client-Objekt. 3. Generiere einen OAuth2-Authentifizierungs-URL. 4. Leite den Benutzer zur Autorisierungs-URL weiter. 5. Erhalte den Autorisierungscode vom Benutzer. 6. Tausche den Autorisierungscode gegen ein Zugriffstoken. 7. Speichere die Tokens sicher. 8. Nutze das Zugriffstoken für weitere Anfragen. 9. Implementiere die Token-Aktualisierungslogik. 10. Handle Fehler und Berechtigungsablauf.IDLE, Polling und Push-Benachrichtigungen: die IMAP-Verbindung aktiv halten
Sobald Sie eine authentifizierte IMAP-Serververbindung haben, besteht die nächste Herausforderung darin, neue Nachrichten effizient zu erkennen, ohne den Server mit ständigen Anfragen zu überlasten. Drei Muster sind heute im Einsatz – jedes mit unterschiedlicher Latenz, Komplexität und Infrastrukturanforderungen.
| Methode | Wie es funktioniert | Latenzzeit | Infrastruktur | Am besten für | Bewertung |
|---|---|---|---|---|---|
| IMAP IDLE (RFC 2177) | Client hat Probleme mit dem IDLE-Befehl; Server sendet EXISTS/RECENT Benachrichtigungen über die offene TCP-Verbindung, wenn neue E-Mails eintreffen. Client muss DONE senden + alle 29 Minuten IDLE erneut ausgeben (Server-Timeout). | ~1-5 Sekunden | 1 persistente TCP-Verbindung pro Mailbox. Erfordert einen dedizierten Thread oder eine asynchrone Schleife. | Einzelplatzwerkzeuge, Desktop-Clients, Latenzüberwachung | Gut |
| Polling (NOOP / CHECK) | Client verbindet sich periodisch neu, sendet SELECT + SEARCH UNSEEN, um nach neuen Nachrichten zu suchen, und trennt dann die Verbindung. Einfach und zustandslos. | Gleich dem Abfrageintervall (typischerweise 1-15 Min.) | Zustandslos. Funktioniert hinter NAT/Firewalls. Keine persistente Verbindung. | Stapelverarbeitung, hohe Latenz tolerierbar, Umgebungen, in denen persistente Verbindungen blockiert sind | Akzeptabel |
| Provider-Push (Gmail Pub/Sub, MS Graph-Webhooks) | Provider sendet eine HTTP-Benachrichtigung an Ihren Webhook-Endpunkt, wenn eine neue E-Mail eintrifft. Keine IMAP-Verbindung im Ruhezustand erforderlich. Gmail verwendet Google Cloud Pub/Sub; Microsoft verwendet MS Graph-Änderungsbenachrichtigungen. | Nahezu Echtzeit(typisch < 1 Sekunde) | Benötigt einen öffentlichen HTTPS-Endpunkt und ein Pub/Sub-Abonnement. Keine persistente IMAP-Verbindung im Ruhezustand. | Hochgradig skalierbare Multi-Account-Produktionssysteme, Serverless-Architekturen | Am besten in großem Maßstab |
IDLE ist die richtige Wahl für einfache Integrationen wo Sie eine kleine Anzahl von Konten verwalten. Die Hauptprobleme: Sie müssen sich vor dem 29-minütigen IDLE-Timeout wieder verbinden (Gmail erzwingt dies streng) und Sie benötigen separate IMAP-Verbindungen für jede Mailbox – was bei Hunderten oder Tausenden von Konten teuer wird.
Provider-Push-Benachrichtigungen sind die richtige Architektur für produktionsreife Multi-Account-Systeme. Die Pub/Sub-Integration von Gmail und die Abonnement-Webhooks von Microsoft Graph liefern beide Benachrichtigungen nahezu in Echtzeit, ohne dass für jedes Konto eine persistente IMAP-Verbindung erforderlich ist. Der Kompromiss: Sie müssen immer noch eine IMAP-Verbindung öffnen, um den eigentlichen Nachrichtentext abzurufen, wenn Sie benachrichtigt werden. Das bedeutet, dass Ihr IMAP-Verbindungscode immer noch benötigt wird – er muss nur nicht kontinuierlich offen gehalten werden. Zum Lesen von E-Mail-Nachrichten über die API lesen Sie unsere Anleitung zu E-Mails über API lesen und E-Mails per API senden.
Fehlerbehebungsmatrix: Timeouts, Handshake-Fehler, Authentifizierungsfehler, Ratenbegrenzungen
Nachstehend finden Sie eine strukturierte Referenz für die häufigsten IMAP-Serververbindungsfehler. Ordnen Sie das Symptom (Fehlermeldung oder beobachtbares Verhalten) der wahrscheinlichen Ursache und der empfohlenen Fehlerbehebung zu.
| Symptom / Fehler | Kategorie | Wahrscheinliche Ursache | Korrigieren |
|---|---|---|---|
| Verbindung verweigert an Port 993 | Verbindung | Falscher Host, IMAP in den Anbietereinstellungen deaktiviert oder Firewall blockiert ausgehenden Port 993 | Host aus der obigen Tabelle überprüfen. IMAP in den Anbietereinstellungen aktivieren (Gmail: Einstellungen > Weiterleitung und POP/IMAP). Firewall/Proxy auf ausgehende TCP-Verbindung 993 prüfen. |
| SSL-Handshake-Timeout / CERTIFICATE_VERIFY_FAILED | TLS | Abgelaufenes oder selbstsigniertes Zertifikat, veraltetes CA-Bundle, falscher Port (143 statt 993) | Verwenden Sie ssl.create_default_context() (Python) - nicht bestehen ssl._create_unverified_context() in Produktion. Aktualisieren Sie Ihr CA-Bundle (pip install certifi). Bestätigen Sie, dass Sie eine Verbindung zu Port 993 herstellen. |
| AUTHENTICATIONFAILED / [AUTHENTICATIONFAILED] Ungültige Zugangsdaten | Autor | Falsches Passwort, App-Passwort nicht generiert, 2FA aktiviert, aber App-Passwort nicht verwendet, Basic Auth vom Anbieter blockiert | Erzeugen Sie ein App-spezifisches Passwort aus den Sicherheitseinstellungen des Anbieters. Wenn Sie Gmail verwenden, stellen Sie sicher, dass "Zugriff auf weniger sichere Apps" nicht die verwendete Methode ist – verwenden Sie ein App-Passwort oder OAuth. Überprüfen Sie bei Microsoft, ob die Basisauthentifizierung für den Mandanten deaktiviert ist. |
| AUTHENTIFIZIEREN XOAUTH2 - ungültiger_Token | OAuth | Zugriffstoken abgelaufen (Tokens sind 3600s gültig), fehlerhafter Base64 XOAUTH2-String, falscher Bereich | Aktualisieren Sie das Zugriffstoken vor der Verbindung. Überprüfen Sie das XOAUTH2-Format: Benutzer={email}\x01auth=Bearer {token}\x01\x01. Umfang prüfen: Gmail benötigt https://mail.google.com/; Outlook benötigt IMAP.ZugriffAlsBenutzer.Alle. |
| imaplib.error: Befehl AUTHENTICATE ungültig im Status AUTH | Bundesland | Versuch der Authentifizierung im bereits authentifizierten Zustand oder nach einem fehlgeschlagenen Authentifizierungsversuch ohne Zurücksetzung. | Schließen und öffnen Sie die IMAP-Verbindung, bevor Sie die Authentifizierung erneut versuchen. Versuchen Sie nie, die Authentifizierung bei derselben Verbindung nach einem Fehler erneut zu versuchen. |
| IMAP-Verbindung bricht nach 29 Minuten im IDLE-Status ab | IDLE | Vom Server erzwungener Leerlauf-Timeout (Standard: 30 Minuten gemäß RFC 2177). Gmail erzwingt 29 Minuten. | Ausgabe ERLEDIGT zwischen 25 und 27 Minuten, dann sofort wieder ausgeben IDLE. Verwenden Sie einen Hintergrund-Thread oder eine asynchrone Aufgabe mit einem 25-Minuten-Heartbeat-Timer. |
| [Überkontingent] oder zu viele gleichzeitige Verbindungen | Ratenbegrenzung | Anbieterbedingtes Verbindungslimit überschritten. Gmail erlaubt 15 gleichzeitige IMAP-Verbindungen pro Konto; Outlook variiert je nach Plan. | Nutze Connection Pooling. Für Gmail: maximal 15 gleichzeitige Verbindungen pro Konto. Schließe inaktive Verbindungen explizit.ABMELDEN) anstatt TCP zu verwerfen. Implementiere exponentielles Backoff bei Verbindungsfehlern. |
| NO [ALARM] Bitte melden Sie sich über Ihren Webbrowser an | Autor | Google-Sicherheitsüberprüfung ausgelöst (ungewöhnliches Zugriffsmuster, neue IP, Captcha erforderlich) | Melden Sie sich über den Browser aus demselben Netzwerk an, um die Sicherheitsherausforderung zu beenden. Erwägen Sie den Umstieg auf OAuth – App-Passwortzugriffe von unbekannten IPs lösen diese Herausforderungen häufiger aus als OAuth. |
| Abgemeldet wegen Inaktivität; zu lange untätig | Verbindung | IMAP-Verbindung im Zustand "authentifiziert" (Postfach nicht ausgewählt) war zu lange untätig | Nach der Authentifizierung sofort eine Mailbox auswählen oder IDLE ausgeben. Implementiere Wiederverbindungslogik, wenn BYE empfangen wird. |
| FETCH gibt leeren Body / nil Teile zurück | Protokoll | Nachricht zwischen SEARCH und FETCH expunged, oder UID-Mismatch nach Ordner-Neuabfrage | Immer verwenden UID HOLEN (keine Sequenznummern) für mehrschrittige Operationen. Verarbeiten Nichts Rückgabewerte von FETCH werden ordnungsgemäß behandelt. Stellen Sie SEARCH nach einer Wiederverbindung erneut aus, um frische UIDs zu erhalten. |
ssl.create_default_context() (Python) - nicht bestehen ssl._create_unverified_context() in Produktion. Aktualisieren Sie Ihr CA-Bundle (pip install certifi). Bestätigen Sie, dass Sie eine Verbindung zu Port 993 herstellen.
Benutzer={email}\x01auth=Bearer {token}\x01\x01. Umfang prüfen: Gmail benötigt https://mail.google.com/; Outlook benötigt IMAP.ZugriffAlsBenutzer.Alle.
ERLEDIGT zwischen 25 und 27 Minuten, dann sofort wieder ausgeben IDLE. Verwenden Sie einen Hintergrund-Thread oder eine asynchrone Aufgabe mit einem 25-Minuten-Heartbeat-Timer.
ABMELDEN) anstatt TCP zu verwerfen. Implementiere exponentielles Backoff bei Verbindungsfehlern.
UID HOLEN (keine Sequenznummern) für mehrschrittige Operationen. Verarbeiten Nichts Rückgabewerte von FETCH werden ordnungsgemäß behandelt. Stellen Sie SEARCH nach einer Wiederverbindung erneut aus, um frische UIDs zu erhalten.
Beenden Sie die Fehlersuche bei IMAP-Fehlern. Unipile liefert saubere E-Mail-Objekte über REST – keine IMAP-Zustandsautomaten, keine Token-Aktualisierungslogik, kein Connection-Pooling zum Verwalten.
Beenden Sie das Debuggen von IMAP – Beginnen Sie mit dem ErstellenWarum produktionsreife IMAP-Implementierungen im großen Maßstab schwieriger sind, als es scheint
Die Öffnung einer einzigen IMAP-Serververbindung zu einem Gmail-Posteingang erfordert 15 Zeilen Python. Die Skalierung auf Hunderte oder Tausende von Benutzern in einem Produktions-SaaS-Produkt ist ein grundlegend anderes technisches Problem. Hier ist eine ehrliche Aufschlüsselung, wo rohe IMAP-Verbindungen nicht offensichtliche Komplexität verursachen.
Zugriffstoken verfallen alle 3600 Sekunden. Für 1.000 verknüpfte Konten benötigen Sie einen Hintergrundprozess, der Tokens proaktiv vor Ablauf erneuert, die Rotation von Refresh-Token handhabt (Google rotiert sie unter bestimmten Bedingungen) und den Fall verwaltet, dass ein Benutzer den Zugriff widerruft – was Sie erst bei der nächsten Token-Nutzung erfahren.
Jede aktive IMAP-Sitzung hält Zustandsinformationen: die aktuell ausgewählte Mailbox, die zuletzt gesehene UID, den IDLE-Timer. Wenn Ihr Server neu gestartet wird, gehen all diese Zustandsinformationen verloren und Sie müssen von neuem synchronisieren – möglicherweise mit dem Abrufen Tausender von Nachrichten, die Sie bereits verarbeitet haben. Sie benötigen einen persistenten Zustandsspeicher pro Konto.
Transiente Fehler (Netzwerkspitzen, Server 500er, Rate-Limit-Antworten) erfordern Wiederholungslogik mit exponentiellem Backoff und Jitter. Naive Wiederholungsschleifen belasten Anbieter und führen zu temporären IP-Sperren. Sie benötigen eine ordnungsgemäße Job-Warteschlange mit konfigurierbaren Wiederholungsverzögerungen und Dead-Letter-Handling für permanent fehlgeschlagene Konten.
OAuth-Refresh-Token sind langlebige Anmeldeinformationen, die vollen E-Mail-Zugriff gewähren. Sie müssen at rest mit einem mit KMS gesicherten Schlüssel verschlüsselt, auf Infrastrukturebene zugriffsgesteuert und bei Anzeichen einer Kompromittierung rotiert werden. Dies ist eine bedeutende Angriffsfläche, die eine ordnungsgemäße Schlüsselverwaltungsinfrastruktur erfordert.
Gmail begrenzt gleichzeitige IMAP-Verbindungen auf 15 pro Konto. Wenn Ihre Anwendung mehr Verbindungen öffnet als zulässig, erhalten Sie OVERQUOTA-Fehler. Gleichzeitig legen Anbieter auch Bandbreitenquoten für die insgesamt übertragene Datenmenge fest. Sie benötigen Connection-Pooling, Request-Throttling und eine kontenspezifische Ratenverfolgung.
Gmail-Labels im Vergleich zu IMAP-Ordnern, Oulooks nicht standardmäßige Ordnerbenennung für Gesendete/Gelöschte Objekte, IMAP-Server, die CAPABILITY-Antworten zurückgeben, die nicht mit dem übereinstimmen, was sie tatsächlich unterstützen, und Server, die Verbindungen während FETCH-Operationen mit großen Anhängen stillschweigend trennen. Jeder Anbieter hat seine eigenen Eigenheiten, die nur in der Produktion auftreten.
Dies ist kein Argument gegen die Erstellung einer benutzerdefinierten IMAP-Integration – für ein Tool für einen einzelnen Anbieter und einen einzelnen Benutzer ist reines IMAP durchaus angemessen. Aber für jedes Produkt, das benötigt E-Mails mehrerer Anbieter und mehrere Benutzerkonten lesen und synchronisieren, die Betriebskosten für die Wartung einer benutzerdefinierten IMAP-Schicht übersteigen in der Regel die Kosten für die Nutzung einer dedizierten E-Mail-API. Die Leitfaden zur Unified Email API deckt die architektonischen Kompromisse im Detail ab.
Produktions-E-Mail-Synchronisierung ohne den IMAP-Overhead. Unipile übernimmt Connection Pooling, Token-Aktualisierung, Fehlerwiederholungen und die Normalisierung mehrerer Anbieter – Sie müssen nur die API aufrufen.
Skaliert aufbauen ohne IMAP-OverheadAufbau einer IMAP-Integration ohne Verbindungsverwaltung: Unipile
Wenn Sie bis hierher gelesen haben, haben Sie eine klare Vorstellung davon, was zur Wartung von rohen IMAP-Verbindungen in der Produktion erforderlich ist: OAuth-Token-Aktualisierungsschleifen, zustandsverwaltung pro Konto, Verbindungspooling, Wiederholungslogik und anbieterspezifische Besonderheiten für Gmail-, Outlook- und IMAP-Server. Unipile abstrahiert diese gesamte Ebene und bietet Ihnen eine einzige REST-API zum Lesen, Senden und Synchronisieren von E-Mails über alle drei hinweg, mit einem 5-minütigen Quickstart und weniger als 10 Zeilen Code pro Vorgang.
Unipile verwaltet den vollständigen OAuth-Flow für Gmail und Microsoft 365: Token-Erwerb, -Aktualisierung und -Rotation. Sie berühren niemals direkt ein Refresh-Token.
Eine API, ein Antwortschema. Lesen Sie E-Mails aus einem Gmail-Posteingang und einem IMAP-Unternehmensserver mit demselben GET /emails-Aufruf. Keine anbieterspezifische Analyse.
Empfangen Sie HTTP-Benachrichtigungen, wenn neue E-Mails eintreffen. Keine verwaltete persistente IMAP-Verbindung, kein zu handhabendes IDLE-Timeout von 29 Minuten, kein dedizierter Thread pro Konto.
Verknüpfen Sie Benutzerkonten über den gehosteten OAuth-Flow von Unipile. Jedes verknüpfte Konto erhält seine eigene account_id. Skalieren Sie von 1 bis zu 10.000 verknüpften Konten, ohne Ihren Integrationscode zu ändern.
Zugangsdaten im Ruhezustand mit KMS-verschlüsselten Schlüsseln verschlüsselt. Unipile ist SOC 2 Typ II zertifiziert und CASA Tier 2 bewertet. Keine IMAP-Passwörter oder OAuth-Token in Ihrer Datenbank gespeichert.
import Anfragen
BASIS_URL = "https://api7.unipile.com:13047/api/v1"
ÜBERSCHRIFTEN = {"X-API-KEY": "dein-unipile-api-schlüssel"}
# Schritt 1: Alle verknüpften Konten auflisten
Konten = Anfragen.bekommen.(
f"{BASIS_URL}/konten", Kopfzeilen=ÜBERSCHRIFTEN
).json()
account_id = Konten["Gegenstände"][0]["id"]
# Schritt 2: E-Mails im Posteingang lesen
Emails = Anfragen.bekommen.(
f"{BASIS_URL}/emails",
Kopfzeilen=ÜBERSCHRIFTEN,
Parameter={"Konto_ID"Konto-ID, "Grenze": 10}
).json()
für E-Mail in E-Mails"Gegenstände"]:
print(E-Mail["Betreff", E-Mail["von_teilnehmer"])
# Keine IMAP-Verbindung, keine Aktualisierung des Tokens,
#: kein SSL-Kontext, keine Zustandsmaschine.
Häufig gestellte Fragen
Häufig gestellte Fragen zu IMAP-Serververbindungen, Ports, Authentifizierung und OAuth-Migration.
Eine IMAP-Serververbindung ist eine persistente TCP-Sitzung zwischen einem E-Mail-Client und einem Mailserver, die das Internet Message Access Protocol verwendet, um E-Mail-Nachrichten, die auf dem Server gespeichert sind, zu synchronisieren, abzurufen und zu verwalten – ohne sie lokal herunterzuladen oder zu löschen. Im Gegensatz zu POP3 behält IMAP Nachrichten auf dem Server und synchronisiert den Status (gelesen, markiert, verschoben) geräteübergreifend. Für Entwickler ist es das grundlegende Protokoll für die Erstellung von E-Mail-Integrationen, die auf Gmail, Outlook und jedem Standard funktionieren IMAP-API.
Verwenden Sie Port 993 für IMAP über SSL/TLS (implizites TLS). Dies ist der moderne Standard und wird von allen großen Cloud-Anbietern, einschließlich Gmail und Outlook, verlangt. Port 143 ist für STARTTLS-Upgrades und eignet sich nur für selbst gehostete Mailserver. Verbinden Sie sich im Produktivbetrieb niemals über Port 143 mit einem Cloud-Mailserver – die meisten lehnen solche Verbindungen mittlerweile ganz ab. Wenn Sie unsicher sind, verwenden Sie immer standardmäßig Port 993 mit ssl=True.
Ja, ohne Ausnahme. SSL/TLS ist für jede IMAP-Serververbindung, die Anmeldedaten überträgt, zwingend erforderlich. Moderne Mailserver lehnen Klartextverbindungen vollständig ab. RFC 9051 (IMAP4rev2) schreibt TLS für alle authentifizierten Sitzungen formal vor. Verwenden Sie immer Port 993 mit implizitem TLS für Cloud-Anbieter. Wenn Sie eine Verbindung zu einem selbst gehosteten Server über Port 143 herstellen, müssen Sie TLS mit dem STARTTLS-Befehl upgraden und das Serverzertifikat überprüfen – verwenden Sie niemals ssl._create_unverified_context() in Produktion.
Die IMAP-Serveradresse für Gmail ist imap.gmail.com on Port 993 mit SSL/TLS. Vor dem Verbinden müssen Sie den IMAP-Zugriff in den Gmail-Einstellungen unter "Weiterleitung und POP/IMAP" aktivieren. Die Authentifizierung erfordert entweder ein App-spezifisches Passwort (wenn 2FA aktiviert ist) oder OAuth 2.0 XOAUTH2 mit dem Geltungsbereich https://mail.google.com/. Google hat die Basisauthentifizierung für neue Apps eingeschränkt und empfiehlt dringend OAuth für jeden programmatischen IMAP-Zugriff.
Die IMAP-Serveradresse für persönliche Outlook.com-Konten und Microsoft 365-Geschäftskonten ist outlook.office365.com on Port 993 mit SSL/TLS. Beachten Sie, dass Microsoft die Unterstützung für die Basisauthentifizierung (Benutzername/Passwort) für IMAP einstellt in Dezember 2026. Alle Integrationen müssen bis zu dieser Frist auf OAuth 2.0 XOAUTH2 migriert werden. Siehe unsere Microsoft Graph OAuth für Outlook Anleitung für Migrationsschritte.
Sie benötigen ein app-spezifisches Passwort, wenn Ihr Konto über eine Zwei-Faktor-Authentifizierung verfügt und Sie die Basisauthentifizierung für IMAP verwenden. App-Passwörter sind 16-stellige Token, die aus den Sicherheitseinstellungen Ihres Anbieters generiert werden (Google-Konto-Sicherheitsseite für Gmail, Apple-ID für iCloud) und Ihr echtes Passwort ersetzen, ohne vollen Kontozugriff zu gewähren. Für produktionsreife Multi-User-Anwendungen gilt:, OAuth 2.0 wird dringend bevorzugt über App-Passwörter - es ist sicherer, erfordert keine Speicherung von Benutzeranmeldeinformationen in Ihrer Anwendung und ist die einzige Methode, die nach der Abschaffung der Microsoft Basic Auth im Dezember 2026 gültig bleibt.
Ja, für Microsoft-Dienste. Microsoft hat das endgültige Ende der Unterstützung für die Basisauthentifizierung in IMAP, POP3 und SMTP in Exchange Online bestätigt. Dezember 2026, die alle Mandanten betrifft, auch diejenigen mit bestehenden Ausnahmen. Jede Integration, die die Benutzername/Passwort-Authentifizierung gegen Outlook oder Microsoft 365 IMAP verwendet, wird nach diesem Datum nicht mehr funktionieren. Google hat den Basic Auth-Zugriff für Gmail bereits eingeschränkt und verlangt seit 2022 Anwendungs-Passwörter oder OAuth für jeden programmatischen Zugriff. Wenn Ihre IMAP-Integration eine Verbindung zu Microsoft-Konten herstellt, müssen Sie migrieren auf OAuth 2.0 XOAUTH2 vor Dezember 2026.
Um eine Verbindung zu einem IMAP-Server mit OAuth 2.0 herzustellen, verwenden Sie den XOAUTH2 SASL-Mechanismus. Nach Erhalt eines Zugriffstokens über den Standard-OAuth-Autorisierungscode-Flow, codieren Sie die Zeichenkette Benutzer={email}\x01auth=Bearer {token}\x01\x01 als Base64, dann übergeben Sie es an den AUTHENTIFIZIEREN XOAUTH2 IMAP-Befehl. Für Gmail ist der erforderliche Geltungsbereich https://mail.google.com/. Für Microsoft 365 verwenden Sie MSAL, um ein Token mit dem IMAP.ZugriffAlsBenutzer.Alle scope. Zugriffstoken laufen nach 3600 Sekunden ab und müssen vor dem Wiederverbinden aktualisiert werden – implementieren Sie eine Token-Aktualisierungsprüfung vor jeder neuen IMAP-Sitzung. Die vollständigen Codebeispiele finden Sie im Abschnitt XOAUTH2 oben.
DE 
EN 
FR 
ES 
IT 
BR 
NL 
PL 
TR