Wat een IMAP-serververbinding eigenlijk is
Een IMAP-serververbinding is een persistente TCP-sessie tussen een e-mailclient en een mailserver die gebruikmaakt van het Internet Message Access Protocol (IMAP) om e-mailberichten die op afstand zijn opgeslagen, te synchroniseren, op te halen en te beheren - zonder deze van de server te downloaden of te verwijderen.
In tegenstelling tot POP3, dat is ontworpen om berichten lokaal te downloaden en optioneel van de server te verwijderen, IMAP is gebouwd voor synchronisatie. Elke actie die je lokaal uitvoert, zoals lezen, markeren, verplaatsen of verwijderen, wordt doorgevoerd op de server – en dus op elk apparaat dat is verbonden met dezelfde mailbox. Dit is waarom IMAP het standaardprotocol werd voor moderne e-mailclients.
Op netwerkniveau opent een IMAP-serververbinding een TCP-socket naar een mailserver (doorgaans poort 993 voor SSL/TLS of poort 143 voor STARTTLS), voert een TLS-handshake uit, authenticeert de gebruiker (via wachtwoord, app-wachtwoord of OAuth 2.0 XOAUTH2) en gaat vervolgens een state machine binnen: Niet geauthenticeerd, Geauthenticeerd, Geselecteerd (in een mailboxmap), of Uitloggen. De meeste nuttige commando's - FETCH, SEARCH, STORE, COPY, EXPUNGE - werken alleen in de Selected staat.
Voor ontwikkelaars die e-mailintegraties bouwen, is een IMAP-serververbinding het laagste bouwblok. Je legt het aan, authenticeert het, SELECTEERT een mailbox, en vervolgens poll of IDLE voor nieuwe berichten. Deze handleiding behandelt elke stap: de juiste host en poort voor elke provider, de juiste authenticatiemethode in 2026 (OAuth wordt steeds vaker verplicht), en een complete referentie voor probleemoplossing van de meest voorkomende faalscenario's.
IMAP poorten uitgelegd: 143, 993, en wanneer STARTTLS acceptabel is
Er zijn exact twee IMAP-poorten actief in gebruik: 993 (Impliciete TLS, de moderne standaard) en 143 (STARTTLS-upgrade of platte tekst, wat de meeste servers plat niet meer toestaan). Het verschil weten is belangrijk omdat het gebruiken van de verkeerde poort een van de meest voorkomende oorzaken van verbindingsfouten is bij het bouwen van een IMAP-integratie.
De client maakt verbinding en initieert onmiddellijk een TLS-handshake voordat er IMAP-gegevens worden uitgewisseld. Al het verkeer is vanaf de eerste byte versleuteld. Dit is de correcte standaard voor elke nieuwe integratie.
De client maakt verbinding in platte tekst en geeft vervolgens een STARTTLS commando om te upgraden naar TLS. De meeste moderne servers vereisen deze upgrade en weigeren volledig platte tekstsessies.
2026 aanbeveling: gebruik altijd poort 993 met SSL_CONTEXT (impliciete TLS). Als u bouwt tegen een zakelijke IMAP-server die alleen poort 143 beschikbaar stelt, schakel STARTTLS in en verifieer het servercertificaat. Maak nooit verbinding met een IMAP-server via platte tekst in productie - inloggegevens reizen onversleuteld en de meeste providers weigeren dergelijke verbindingen nu ronduit.
Een korte opmerking over RFC 9051 (IMAP4rev2), gepubliceerd in augustus 2021 als opvolger van RFC 3501. IMAP4rev2 vereist formeel TLS voor elke verbinding die inloggegevens bevat, doet MD5-gebaseerde authenticatiemechanismen in de ban en verwijdert de LIJST-UITGEBREID incompatibiliteiten die tot subtiele bugs in oudere clients leidden. De meeste grote cloudproviders (Gmail, Outlook) zijn al jaren IMAP4rev2-compatibel in de praktijk, zelfs voordat de RFC werd voltooid. Richt je voor praktische doeleinden op poort 993 + TLS en je bent standaard RFC 9051-compatibel.
Host- en poortinstellingen tabel - Gmail, Outlook, Yahoo, iCloud, Zoho, Fastmail, AOL, ProtonMail Bridge
De onderstaande tabel geeft de correcte IMAP-serververbindingsinstellingen weer voor de meest gebruikte e-mailproviders. Alle waarden zijn geverifieerd tegen de officiële documentatie van elke provider per mei 2026. Gebruik dit als uw snelle referentie bij het configureren van een IMAP-client of het bouwen van een IMAP API-integratie.
| Provider | IMAP Host | Haven | Encryptie | OAuth 2.0 (XOAUTH2) | Notities |
|---|---|---|---|---|---|
| imap.gmail.com | 993 | SSL/TLS | Ja (verplicht voor nieuwe apps) |
App-wachtwoorden werken, maar OAuth heeft sterk de voorkeur. Schakel eerst IMAP in de Gmail-instellingen in. | |
| outlook.office365.com | 993 | SSL/TLS | Ja (Basisauthenticatie verlaten dec. 2026) |
Basic Auth end-of-life december 2026 voor alle tenants. Migreer nu naar OAuth. | |
Yahoo Mail |
imap.mail.yahoo.com | 993 | SSL/TLS | Ja |
App-wachtwoord vereist als 2FA is ingeschakeld. OAuth via Yahoo's ontwikkelaarsportaal. |
iCloud-e-mail |
imap.mail.me.com | 993 | SSL/TLS | Nee (alleen app-specifiek wachtwoord) |
Apple vereist een app-specifiek wachtwoord van appleid.apple.com. Geen OAuth XOAUTH2-ondersteuning. |
Zoho Mail |
imap.zoho.com | 993 | SSL/TLS | Ja |
OAuth via Zoho Accounts API. IMAP moet per postbus worden ingeschakeld in de Zoho Mail-instellingen. |
Fastmail |
imap.fastmail.com | 993 | SSL/TLS | Ja (JMAP voorkeur) |
Fastmail ondersteunt JMAP native (sneller dan IMAP), maar IMAP wordt volledig ondersteund. App-wachtwoorden beschikbaar. |
AOL Mail |
imap.aol.com | 993 | SSL/TLS | Ja |
Nu onderdeel van Yahoo Inc. App-wachtwoord vereist indien 2FA is ingeschakeld. OAuth via Yahoo's ontwikkelaarsportaal. |
ProtonMail Bridge |
127.0.0.1 | 1143 | STARTTLS | Nee (Bridge token auth) |
ProtonMail Bridge draait lokaal en stelt een lokale IMAP-server ter beschikking. Niet geschikt voor server-side integraties. |
Generieke IMAP |
uw-mailserver.nl | 993 / 143 | SSL/TLS STARTTLS | Varieert (serverconfiguratie controleren) |
Dovecot, Postfix, Zimbra, Courier. Controleer de CAPABILITY-respons van uw server voor ondersteunde authenticatiemechanismen. |
Opmerking over ProtonMail: de Bridge-architectuur betekent dat ProtonMail IMAP-verbindingen alleen levensvatbaar zijn voor desktopopstellingen voor één gebruiker. Voor integraties met meerdere accounts of server-side is ProtonMail effectief niet ondersteund via standaard IMAP. Zie voor Gmail en Outlook op schaal onze speciale handleidingen over OAuth voor e-mail-API's en Microsoft Graph API E-mail.
Stap-voor-stap: een ruwe IMAP-serververbinding openen
Hieronder staan minimale, werkende voorbeelden van hoe je een geauthenticeerde IMAP-serververbinding opent met behulp van de ingebouwde bibliotheek van Python imaplib en Node.js met imapflow. Beide voorbeelden maken via poort 993 verbinding met Gmail met behulp van authenticatie via een app-wachtwoord. Zie H2 #7 hieronder voor OAuth XOAUTH2.
importeer imaplib
importeer ssl
# IMAP-serverinstellingen
IMAP_HOST = "imap.gmail.com"
IMAP_POORT = 993
GEBRUIKERSNAAM = "you@gmail.com"
WACHTWOORD = "jouw-app-wachtwoord" Het wachtwoord van de #-app, niet het wachtwoord van je account
# SSL-context aanmaken (certificaten verifiëren)
context = ssl.maak_standaard_context()
# Open SSL-verbinding op poort 993
met imaplib.IMAP4_SSLIMAP_HOST, IMAP_POORT, ssl_context=context als imap:
# Verificeren
imap.Login(GEBRUIKERSNAAM, WACHTWOORD)
# Inbox selecteren (geeft het aantal berichten weer)
status, gegevens = imap.select("INBOX")
print(Inbox bevat {data[0].decode()} berichten")
# Zoek naar verborgen berichten
status, msg_ids = imap.zoek(Niets, "ONGEZIEN")
print(Ongezien: {msg_ids[0].decode()}")
# Afmelden (verbinding wordt verbroken aan het einde van het 'with'-blok)// npm installeer imapflow
importeer ImapFlow van 'imapflow';
const klant = nieuw ImapStroom({
gastheer: 'imap.gmail.com',
haven 993,
veilig true, // SSL/TLS op poort 993
auth: {
gebruiker: 'you@gmail.com',
voorbij 'je-app-wachtwoord'
},
logger: vals
});
wacht op klant.Verbinden();
// Vergrendel de INBOX-mailbox voor exclusieve toegang
laat slot = wacht op klant.postvakvergrendelingophalen('POSTVAK');
proberen {
// Haal de laatste 5 berichten op (alleen headers)
voor wacht op (laat bericht van klant.fetch('1:5', { envelop: true })) {
console.log(onderwerp.envelop);
}
} uiteindelijk {
slot.vrijlating();
}
wacht op klant.uitloggen();Het Python-voorbeeld gebruikt IMAP4_SSL - de hogere SSL-wrapper die de TLS-handshake automatisch afhandelt. Vermijd het gebruik van IMAP4 + handleiding starttls() voor cloudproviders aangezien het complexiteit toevoegt zonder voordeel. Voor Node.js, imapflow is de moderne, Promise-gebaseerde keuze (de oudere node-imap bibiliotheek is sinds 2024 niet meer onderhouden en ondersteunt geen XOAUTH2.
Beide voorbeelden gebruiken app-wachtwoorden, het simpelste type inloggegevens voor snel testen. Voor productie systemen die meerdere gebruikers afhandelen, hebt u OAuth 2.0 nodig - zie de sectie XOAUTH2 hieronder. Voor een complete productieklare oplossing zonder het beheren van ruwe IMAP verbindingen, ziet u IMAP API ontwikkelaarsgids.
Sla de IMAP-standaardtekst over. Unipile biedt je lezen, verzenden en synchronisatie over Gmail, Outlook en IMAP in één REST API - geen verbindingsbeheer vereist.
Sla IMAP boilerplate over - Bouw het met UnipileAuthenticatie: wachtwoord, app-wachtwoord en OAuth 2.0 (XOAUTH2)
Een IMAP-serververbinding vereist authentificatie na de TLS-handshake. Er zijn tegenwoordig drie authenticatiemethoden in gebruik - elk met een ander beveiligingsprofiel, complexiteitsniveau en compatibiliteit met cloudproviders in 2026.
Het oorspronkelijke IMAP AUTH PLAIN / LOGIN-mechanisme. U stuurt het e-mailadres van het account en het wachtwoord van het account rechtstreeks naar de IMAP-server. Eenvoudig te implementeren, maar steeds vaker geblokkeerd door cloudproviders om veiligheidsredenen.
Verouderd voor de cloudEen 16-tekens token gegenereerd door de provider (Gmail, Yahoo, iCloud) die het werkelijke accountwachtwoord vervangt. Werkt met hetzelfde IMAP LOGIN-commando als Basic Auth, maar is beperkt en kan onafhankelijk worden ingetrokken. Vereist wanneer 2FA is ingeschakeld.
Acceptabel voor persoonlijk gebruikDe gebruiker autoriseert uw app via een toestemmingsscherm. Uw app ontvangt een toegangstoken (kortstondig, doorgaans 1 uur) die u base64-codeert en doorgeeft aan het IMAP AUTHENTICATE XOAUTH2 commando. Tokens worden vernieuwd met een langdurige vernieuwingstoken. De enige haalbare methode voor productie-apps voor meerdere gebruikers.
Vereist voor productieWanneer welk te gebruiken: Gebruik app-wachtwoorden tijdens lokale ontwikkeling en voor persoonlijk gereedschap. Gebruik OAuth 2.0 XOAUTH2 voor elke integratie met meerdere gebruikers - het is de enige schaalbare methode, omdat je nooit gebruikerswachtwoorden opslaat, en elke token kan worden ingetrokken zonder het wachtwoord van de gebruiker te wijzigen. Voor Gmail heeft Google sinds 2022 geleidelijk Basic Auth voor "minder veilige apps" beperkt. Voor Microsoft/Outlook is de afschaffing van Basic Auth gepland voor december 2026 voor alle tenants (zie de volgende sectie).
Voor een diepgaande bespreking van OAuth-stromen - inclusief tokenuitwisseling, vernieuwingslogica en scopes - raadpleeg onze gids over OAuth voor e-mail-API's. Zie voor Microsoft-specifieke OAuth-instellingen Microsoft Graph OAuth voor Outlook.
Het 2026-probleem: uitfasering Microsoft Basic Auth (december 2026)
Als je IMAP-integratie rechtstreeks verbinding maakt met Microsoft 365- of Outlook-accounts met behulp van een gebruikersnaam en wachtwoord, bevind je je op een aftelklok. Microsoft heeft de definitieve einddatum aangekondigd voor Basic Authentication voor IMAP, POP3 en SMTP voor alle tenants.
Volgens Microsoft Learn en de Microsoft Community Hub aankondiging, Exchange Online zal Basic Authentication voor IMAP, POP3 en SMTP in december 2026 volledig uitschakelen voor alle tenants - inclusief degene met bestaande vrijstellingen. Elke IMAP-client of server-side integratie die nog steeds authenticatie via gebruikersnaam/wachtwoord gebruikt, zal stoppen met werken. Er is geen verdere verlenging beschikbaar.
Actiestappen om te migreren vóór de deadline
Zoek in uw codebase naar IMAP-verbindingen die gebruik maken van inloggen(gebruikersnaam, wachtwoord) of AUTH PLAIN. Controleer Microsoft Entra ID (voorheen Azure AD) aanmeldingslogboeken voor IMAP Basic Auth-activiteit.
Maak een app-registratie aan op portal.azure.com met de IMAP.ToegangAlsGebruiker.Alle (gedelegeerd) of IMAP.ToegangAlsApp (toepassing) toestemming. Zien Microsoft Graph OAuth voor Outlook voor een stapsgewijze handleiding.
Gebruik MSAL (Microsoft Authentication Library) om toegangstokens te verkrijgen. Implementeer token-vernieuwingslogica - Microsoft-tokens verlopen na 1 uur en je hebt een refresh-tokenflow nodig om langdurige IMAP-sessies te behouden zonder herauthenticatie van de gebruiker.
Vervang de IMAP INLOGGEN commando met AUTHENTICEER XOAUTH2 met behulp van een base64-gecodeerde tokenreeks. Zie het volledige codevoorbeeld in de sectie XOAUTH2 hieronder.
Microsoft biedt een manier om Basic Auth vroegtijdig uit te schakelen per tenant - gebruik dit om uw OAuth-stroom te testen vóór de geforceerde afsnijdatum van december 2026, zodat u geen productieproblemen hoeft op te lossen onder tijdsdruk.
Als u IMAP-verbindingen beheert voor meerdere Microsoft 365-gebruikers - een veelvoorkomend scenario voor CRM-, ATS- of verkoopautomatiserings tools - neemt de complexiteit van de migratie snel toe. U moet OAuth-toestemmingsstromen voor elke gebruiker afhandelen, tokens veilig opslaan en vernieuwen, en omgaan met beleidsregels voor voorwaardelijke toegang die uw app in sommige tenants kunnen blokkeren. Dit is een van de belangrijkste redenen waarom ontwikkelaars kiezen voor een beheerde IMAP API in plaats van zelf ruwe verbindingen te onderhouden.
Deadline voor Microsoft Basic Auth nadert. Bouw vandaag nog een toekomstbestendige OAuth-flow met Unipiles uniforme e-mail API - wij regelen voor u token-vernieuwing, multi-tenant-authenticatie en XOAUTH2.
Bouw een toekomstbestendige OAuth-stroomVerbinden via OAuth XOAUTH2
XOAUTH2 is het SASL-mechanisme dat u toestaat een IMAP-serververbinding te authenticeren met behulp van een OAuth 2.0-toegangstoken in plaats van een wachtwoord. Het token wordt verkregen via de standaard OAuth autorisatie-codestroom (of clientreferenties voor serviceaccounts), base64-gecodeerd in een specifiek formaat, en doorgestuurd naar de AUTHENTICEER XOAUTH2 IMAP commando.
importeer imaplib, base64, json
van google.oauth2.credentials importeer Geloofsbrieven
van google.auth.transport.requests importeer Verzoek
# Eerder verkregen OAuth-inloggegevens laden
# (uit de google-auth-oauthlib-stroom)
credit = Referenties(
token=TOEGANGSTOKEN,
vernieuwingstoken=VERVERSINGSTOKEN,
token_uri="https://oauth2.googleapis.com/token",
klant_id=CLIENT_ID,
cliënt_geheim=CLIENT_SECRET,
scopes=["https://mail.google.com/"]
)
# Vernieuw het token als het is verlopen
als creds.verlopen:
credits.verversen(Verzoek())
# XOAUTH2-string samenstellen: "user={email}\x01auth=Bearer {token}\x01\x01""
gebruikers_email = "user@gmail.com"
auth_string = f"gebruiker={user_email}\x01auth=Bearer {creds.token}\x01\x01"
auth_b64 = base64.b64encode(auth_string.coderen()).decode()
# IMAP-verbinding openen en authenticeren
met imaplib.IMAP4_SSL("imap.gmail.com", 993) als imap:
imap.authenticeren("XOAUTH2", lambda _: auth_b64)
imap.select("INBOX")
print("Verbonden via XOAUTH2")importeer imaplib, base64
van msal importeer ConfidentialClientApplicatie
# Token verkrijgen via MSAL (clientreferenties-stroom voor serviceaccounts)
# Gebruik in plaats daarvan de authenticatiecodeprocedure voor door de gebruiker gedelegeerde toegang
app = ConfidentialClientApplicatie(
klant_id=CLIENT_ID,
autoriteit=https://login.microsoftonline.com/{TENANT_ID}",
client_credential=CLIENT_SECRET
)
resultaat = app.verkrijg_token_voor_client(
scopes=["https://outlook.office365.com/.default"]
)
toegangstoken = resultaat["toegangstoken"]
# XOAUTH2-string samenstellen
gebruikers_email = "user@company.com"
auth_string = f"gebruiker={user_email}\x01auth=Bearer {access_token}\x01\x01"
auth_b64 = base64.b64encode(auth_string.coderen()).decode()
# Verbinding maken met Outlook via IMAP
met imaplib.IMAP4_SSL("outlook.office365.com", 993) als imap:
imap.authenticeren("XOAUTH2", lambda _: auth_b64)
imap.select("INBOX")
print("Verbonden via XOAUTH2 met Outlook")Belangrijkste verschillen tussen Gmail en Microsoft XOAUTH2: Gmail vereist de https://mail.google.com/ bereik (volledige Gmail-toegang). Microsoft vereist IMAP.ToegangAlsGebruiker.Alle (gedelegeerd) of IMAP.ToegangAlsApp (toepassing). Het base64 XOAUTH2-tekenreekspatroon is identiek voor beide providers: gebruiker={email}\x01auth=Bearer {token}\x01\x01.
Eén cruciaal implementatiedetail: tokens verlopen na 3600 seconden. Een langlopende IMAP IDLE-sessie (zie het volgende gedeelte) zal een authenticatiefout ontvangen wanneer de token verloopt midden in de sessie. U moet deze afvangen AUTHENTICATIEGEFAALD fout, vernieuw de token met uw vernieuwingstoken, maak vervolgens opnieuw verbinding met IMAP. Deze opnieuw-poging-lus is niet-triviaal en is een van de belangrijkste redenen waarom teams kiezen voor een beheerde API zoals Unified e-mail API gids in plaats van onbewerkte IMAP-verbindingen.
Voor een complete handleiding voor de OAuth-instellingen voor Microsoft, inclusief overwegingen voor voorwaardelijke toegangbeleid, zie onze Microsoft Graph OAuth voor Outlook gids.
OAuth XOAUTH2, een authenticatiestandaard, maakt gestroomlijnde toegang mogelijk. Het protocol maakt een veilige autorisatie mogelijk voor gebruikers. Applicaties vragen hierdoor toestemming om namens de gebruiker te handelen. Dit gebeurt zonder het delen van het wachtwoord van de gebruiker. XOAUTH2 gebruikt een authenticatiecode en tokens uit te wisselen. Deze tokens bieden tijdelijke toegang tot beschermde bronnen. De server valideert het token en autoriseert de toegang. Dit voorkomt dat gevoelige inloggegevens worden blootgesteld. Het verbetert de veiligheid en de gebruikerservaring aanzienlijk. XOAUTH2 is cruciaal voor moderne veilige webapplicaties. Unipile regelt de acquisitie, verversing en opnieuw authenticeren van tokens van IMAP automatisch. Jij focust je op het lezen van e-mails, niet op connectiebeheer.
Bouw OAuth XOAUTH2 in 10 regels met Unipile: 1. Importeer de Unipile client. 2. Initialiseer de client met je client_id en client_secret. 3. Definiëer de scope voor Gmail: "https://mail.google.com/". 4. Genereer de autorisatie-URL met redirect_uri. 5. Stuur de gebruiker naar de autorisatie-URL. 6. Na autorisatie ontvang je een code in de redirect_uri. 7. Wissel de code in voor een access_token en refresh_token. 8. Gebruik de access_token om Gmail-API's te benaderen. 9. Als de access_token verloopt, gebruik de refresh_token om een nieuwe te verkrijgen. 10. Bewaar tokens veilig voor toekomstig gebruik.IDLE, polling en pushmeldingen: de IMAP-verbinding in stand houden
Zodra u een geauthenticeerde IMAP-serververbinding hebt, is de volgende uitdaging het efficiënt detecteren van nieuwe berichten zonder de server constant te belasten met verzoeken. Er zijn momenteel drie patronen in gebruik, elk met verschillende latentie, complexiteit en infrastructuurvereisten.
| Methode | Hoe het werkt | Latency | Infrastructuur | Het beste voor | Beoordeling |
|---|---|---|---|---|---|
| IMAP IDLE (RFC 2177) | Clientproblemen met IDLE-commando; server stuurt EXISTS/RECENT meldingen via de open TCP-verbinding wanneer nieuwe e-mail arriveert. Client moet DONE sturen + IDLE opnieuw uitgeven elke 29 minuten (server timeout). | ~1-5 seconden | 1 persistente TCP-verbinding per mailbox. Vereist een aparte thread of asynchrone lus. | Single-user tools, desktopclients, monitoring met lage latentie | Goed |
| Poll (NOOP / CHECK) | Client maakt periodiek opnieuw verbinding, voert SELECT + SEARCH UNSEEN uit om te zoeken naar nieuwe berichten, en verbreekt dan de verbinding. Eenvoudig en stateless. | Gelijk aan pauze-interval (doorgaans 1-15 min) | Staatloos. Werkt achter NAT/firewalls. Geen persistente verbinding. | Batchverwerking, acceptabele hoge latentie, omgevingen waar persistente verbindingen geblokkeerd zijn | Acceptabel |
| Providerpush (Gmail Pub/Sub, MS Graph webhooks) | Provider stuurt HTTP-meldingen naar je webhook-eindpunt wanneer er nieuwe e-mail arriveert. Geen IMAP-verbinding nodig in rust. Gmail gebruikt Google Cloud Pub/Sub; Microsoft gebruikt MS Graph wijzigingsmeldingen. | Nagenoeg realtime ((typisch <1 seconde) | Vereist een openbaar HTTPS-eindpunt en een Pub/Sub-abonnement. Geen permanente IMAP-verbinding in rust. | Grootschalige multi-account productie systemen, serverloze architecturen | Beste op schaal |
IDLE is de juiste keuze voor eenvoudige integraties waar je een klein aantal accounts beheert. De belangrijkste valkuilen: je moet opnieuw verbinding maken vóór de IDLE-time-out van 29 minuten (Gmail handhaaft dit strikt), en je hebt aparte IMAP-verbindingen nodig voor elke mailbox - wat duur wordt bij honderden of duizenden accounts.
Provider pushmeldingen zijn de juiste architectuur voor productie multi-account systemen. Gmail's Pub/Sub-integratie en Microsoft Graph's abonnements-webhooks leveren beide bijna real-time meldingen zonder dat er voor elk account een persistente IMAP-verbinding nodig is. De afweging: je moet nog steeds een IMAP-verbinding openen om de daadwerkelijke berichttekst op te halen wanneer je een melding ontvangt, wat betekent dat je IMAP-verbindingscode nog steeds nodig is - alleen niet continu opengehouden hoeft te worden. Voor het lezen van e-mailberichten via API, zie onze gids over e-mails lezen via API en e-mails verzenden via API.
Probleemoplossingsmatrix: time-outs, handshakefouten, authenticatiefouten, snelheidslimieten
Hieronder vindt u een gestructureerd referentiemateriaal voor de meest voorkomende IMAP-serververbindingsfouten. Koppel het symptoom (foutmelding of observeerbaar gedrag) aan de waarschijnlijke oorzaak en de aanbevolen oplossing.
| Symptoom / Fout | Categorie | Waarschijnlijke oorzaak | Repareer |
|---|---|---|---|
| Verbinding geweigerd op poort 993 | Verbinding | Verkeerde host, IMAP uitgeschakeld in providerinstellingen, of firewall die uitgaande 993 blokkeert | Verifieer de host uit de bovenstaande tabel. Schakel IMAP in de instellingen van uw provider in (Gmail: Instellingen > Doorsturen en POP/IMAP). Controleer uw firewall/proxy voor uitgaande TCP 993. |
| SSL-handshake time-out / CERTIFICATE_VERIFY_FAILED | TLS | Vervallen of zelf-ondertekend certificaat, verouderde CA-bundel, verkeerde poort (143 in plaats van 993) | Gebruik ssl.create_default_context() (Python) - niet doorgeven ssl._create_unverified_context() in productie. Werk uw CA-bundel bij (pip install certifiVerifiëer dat u verbinding maakt met poort 993. |
| AUTHENTICATIONFAILED / [AUTHENTICATIONFAILED] Ongeldige gegevens | Auth | Verkeerd wachtwoord, app-wachtwoord niet gegenereerd, 2FA ingeschakeld maar app-wachtwoord niet gebruikt, Basic Auth geblokkeerd door provider | Genereer een app-specifiek wachtwoord uit de beveiligingsinstellingen van de provider. Als je Gmail gebruikt, zorg ervoor dat "Toegang voor minder veilige apps" niet de methode is - gebruik een app-wachtwoord of OAuth. Controleer voor Microsoft of Basic Auth is uitgeschakeld voor de tenant. |
| ONTICHT XOAUTH2 - ongeldige_token | OAuth | Toegangstoken verlopen (tokens geldig voor 3600s), ongeldige base64 XOAUTH2-streng, verkeerd bereik | Vernieuw het toegangstoken voordat u verbinding maakt. Controleer het XOAUTH2-tekenreeksprofiel: gebruiker={email}\x01auth=Bearer {token}\x01\x01. Controleer bereik: Gmail heeft https://mail.google.com/; Outlook heeft nodig IMAP.ToegangAlsGebruiker.Alle. |
| imaplib.error: opdracht AUTHENTICATE illegaal in staat AUTH | Staat | Poging om te authenticeren terwijl u al in de geauthenticeerde status bent, of na een mislukte authenticatiepoging zonder opnieuw in te stellen | Sluit de IMAP-verbinding en open deze opnieuw voordat je de authenticatie opnieuw probeert. Probeer de authenticatie nooit opnieuw op dezelfde verbinding na een storing. |
| IMAP-verbinding wordt na 29 minuten IDLE verbroken | WERKELOOS | Server-gedwongen IDLE time-out (standaard: 30 minuten per RFC 2177). Gmail handhaaft 29 minuten. | Probleem KLAAR op 25-27 minuten, herdruk dan onmiddellijk WERKELOOS. Gebruik een achtergrondthread of asynchrone taak met een timer van 25 minuten. |
| [OVERQUOTA] of Te veel gelijktijdige verbindingen | Limiet op aanvraagfrequentie | Provider-beperking voor verbindingen overschreden. Gmail staat 15 gelijktijdige IMAP-verbindingen per account toe; Outlook varieert per abonnement. | Gebruik connection pooling. Voor Gmail: maximaal 15 gelijktijdige verbindingen per account. Sluit inactieve verbindingen expliciet af.UITLOGGEN) in plaats van TCP te laten vallen. Implementeer exponentiële backoff op verbindingsfouten. |
| Nee [WAARSCHUWING] Log alstublieft in via uw webbrowser | Auth | Google beveiligingsuitdaging geactiveerd (ongewoon toegangspatroon, nieuw IP, captcha vereist) | Log in via browser vanaf hetzelfde netwerk om de beveiligingsuitdaging te wissen. Overweeg over te schakelen op OAuth - app-wachtwoordtoegang vanaf onbekende IP-adressen triggert deze uitdagingen vaker dan OAuth. |
| TOT ZIENS Automatische afmelding; te lang inactief | Verbinding | IMAP-verbinding in Geauthenticeerde staat (mailbox niet geselecteerd) was te lang inactief | Na authenticatie meteen een mailbox of IDselecteren. Implementeer opnieuw verbindingslogica wanneer je BYE ontvangt. |
| FETCH retourneert een lege body / nil delen | Protocol | Bericht is verwijderd tussen ZOEK en OPHALEN, of UID-ongelijkheid na het opnieuw scannen van de map | Altijd gebruiken UID OPHALEN (niet-opeenvolgende nummers) voor meerstapsoperaties. Behandel Niets geef waarden van FETCH gracieus terug. Herhaal SEARCH na een herverbinding om nieuwe UIDs te krijgen. |
ssl.create_default_context() (Python) - niet doorgeven ssl._create_unverified_context() in productie. Werk uw CA-bundel bij (pip install certifiVerifiëer dat u verbinding maakt met poort 993.
gebruiker={email}\x01auth=Bearer {token}\x01\x01. Controleer bereik: Gmail heeft https://mail.google.com/; Outlook heeft nodig IMAP.ToegangAlsGebruiker.Alle.
KLAAR op 25-27 minuten, herdruk dan onmiddellijk WERKELOOS. Gebruik een achtergrondthread of asynchrone taak met een timer van 25 minuten.
UITLOGGEN) in plaats van TCP te laten vallen. Implementeer exponentiële backoff op verbindingsfouten.
UID OPHALEN (niet-opeenvolgende nummers) voor meerstapsoperaties. Behandel Niets geef waarden van FETCH gracieus terug. Herhaal SEARCH na een herverbinding om nieuwe UIDs te krijgen.
Stop met het debuggen van IMAP-fouten. Unipile levert schone e-mailobjecten via REST - geen IMAP state machine, geen token verversingslogica, geen connection pooling om te beheren.
Stop met het debuggen van IMAP - Begin met bouwenWaarom production-grade IMAP op schaal moeilijker is dan het lijkt
Het openen van een enkele IMAP-serververbinding naar een Gmail-inbox is 15 regels Python. Opschalen naar honderden of duizenden gebruikers in een productie SaaS-product is een fundamenteel ander technisch probleem. Hier is een eerlijke uiteenzetting van waar ruwe IMAP-verbindingen niet-voor-de-hand-liggende complexiteit creëren.
Toegangstokens verlopen elke 3600 seconden. Voor 1.000 gekoppelde accounts heb je een achtergrondtaak nodig die tokens proactief vernieuwt vóór het verlopen, rotatie van vernieuwingstokens afhandelt (Google roteert deze onder bepaalde voorwaarden) en de situatie beheert waarin een gebruiker de toegang intrekt - wat je pas ontdekt bij het volgende tokengebruik.
Elke actieve IMAP-sessie houdt een status bij: momenteel geselecteerde mailbox, laatst geziene UID, IDLE-timer. Als uw server opnieuw opstart, verliest u al deze status en moet u opnieuw synchroniseren vanaf nul - potentieel duizenden berichten ophalen die u al hebt verwerkt. U hebt een persistente statusopslag per account nodig.
Tijdelijke storingen (netwerkonderbrekingen, server 500s, antwoorden op rate limiting) vereisen opnieuw proberen met exponentiële backoff en jitter. Naïeve retry loops belasten providers en resulteren in tijdelijke IP-verbanningen. Je hebt een goede job queue nodig met configureerbare vertragingen voor opnieuw proberen en dead-letter handling voor permanent mislukte accounts.
OAuth-vernieuwings-tokens zijn langdurige inloggegevens die volledige e-mailtoegang verlenen. Ze moeten versleuteld zijn in rust met een op KMS gebaseerde sleutel, toegangsgecontroleerd op infrastructuurniveau en geroteerd worden als er enige aanwijzing is van een inbreuk. Dit is een aanzienlijk beveiligingsoppervlak dat de juiste infrastructuur voor sleutelbeheer vereist.
Gmail beperkt gelijktijdige IMAP-verbindingen tot 15 per account. Als uw applicatie meer verbindingen opent dan toegestaan, ontvangt deze OVERQUOTA-fouten. Tegelijkertijd leggen providers ook bandbreedtequota op voor de totale overgedragen data. U hebt connection pooling, request throttling en per-account rate tracking nodig.
Gmail-labels versus IMAP-mappen, Outlook's niet-standaard mapnamen voor Verzonden/Verwijderd, IMAP-servers die CAPABILITY-antwoorden retourneren die niet overeenkomen met wat ze daadwerkelijk ondersteunen, en servers die verbindingen stilzwijgend verbreken tijdens FETCH-bewerkingen op grote bijlagen. Elke provider heeft een unieke set eigenaardigheden die alleen in de praktijk naar boven komen.
Dit is geen argument tegen het bouwen van een aangepaste IMAP-integratie - voor een tool voor één provider en één gebruiker is ruwe IMAP volkomen redelijk. Maar voor elk product dat moet e-mail lezen en synchroniseren tussen meerdere providers en meerdere gebruikersaccounts, de operationele overhead van het onderhouden van een aangepaste IMAP-laag overschrijdt doorgaans de kosten van het gebruik van een speciale e-mail-API. De Unified e-mail API gids behandelt de architecturale afwegingen in detail.
Productie-e-mail synchronisatie zonder de IMAP overhead. Unipile beheert connection pooling, tokenvernieuwing, foutherhaling en normalisatie van meerdere providers - u hoeft alleen de API aan te roepen.
Bouw op schaal zonder IMAP-overheadHet opbouwen van een IMAP-integratie zonder de verbinding te beheren: Unipile
Als je tot hier hebt gelezen, heb je een duidelijk beeld van wat er nodig is om ruwe IMAP-verbindingen in productie te onderhouden: OAuth-tokenherhalingslussen, statusbeheer per account, connectiepooling, retry-logica en provider-specifieke eigenaardigheden voor Gmail-, Outlook- en IMAP-servers. Unipile abstraheert deze hele laag en geeft je één REST API om e-mails te lezen, te verzenden en te synchroniseren via alle drie, met een snelle start van 5 minuten en minder dan 10 regels code per bewerking.
Unipile beheert de volledige OAuth-flow voor Gmail en Microsoft 365: tokenverwerving, vernieuwing en rotatie. U raakt nooit rechtstreeks een vernieuwingstoken aan.
Eén API, één response schema. Lees e-mails uit een Gmail-inbox en een IMAP-bedrijfsserver met dezelfde GET /emails-aanroep. Geen provider-specifieke parsing.
Ontvang HTTP-meldingen bij het ontvangen van nieuwe e-mails. Geen persistente IMAP-verbinding om te beheren, geen IDLE-time-out van 29 minuten om af te handelen, geen speciale thread per account.
Koppel gebruikersaccounts via Unipile's gehoste OAuth-flow. Elk gekoppeld account krijgt zijn eigen account_id. Schaal van 1 tot 10.000 gekoppelde accounts zonder uw integratiecode te wijzigen.
Referenties versleuteld opgeslagen met KMS-ondersteunde sleutels. Unipile is SOC 2 Type II gecertificeerd en CASA Tier 2 beoordeeld. Geen IMAP-wachtwoorden of OAuth-tokens opgeslagen in uw database.
importeer verzoekt
BASE_URL = "https://api7.unipile.com:13047/api/v1"
KOPTEKSTEN = {"X-API-SLEUTEL": "jouw-unipile-api-sleutel"}
# Stap 1: Maak een lijst van alle gekoppelde accounts
rekeningen = verzoeken.krijgen(
"{BASE_URL}/accounts", kopteksten=KOPTEKSTEN
).json()
account_id = accounts["items"][0]["id"]
# Stap 2: Lees de e-mails in je inbox
e-mails = verzoeken.krijgen(
f"{BASIS_URL}/emails",
kopteksten=KOPPEN,
parameters={"account_id"account_id, "limiet": 10}
).json()
voor e-mail in e-mails"items"]:
print(e-mail["onderwerp", e-mail["van_deelnemer"])
# Geen IMAP-verbinding, geen vernieuwing van het token,
#: geen SSL-context, geen toestandsmachine.Veelgestelde vragen
Veelgestelde vragen over IMAP-serververbindingen, poorten, authenticatie en OAuth-migratie.
Een IMAP-serververbinding is een persistente TCP-sessie tussen een e-mailclient en een mailserver die gebruikmaakt van het Internet Message Access Protocol om e-mailberichten die op de server zijn opgeslagen te synchroniseren, op te halen en te beheren - zonder ze lokaal te downloaden of te verwijderen. In tegenstelling tot POP3 bewaart IMAP berichten op de server en synchroniseert de status (gelezen, gemarkeerd, verplaatst) op alle verbonden apparaten. Voor ontwikkelaars is het het fundamentele protocol voor het bouwen van e-mailintegraties die werken met Gmail, Outlook en elke standaard IMAP API.
Gebruik poort 993 voor IMAP over SSL/TLS (impliciete TLS). Dit is de moderne standaard en wordt vereist door alle grote cloudproviders, waaronder Gmail en Outlook. Poort 143 is voor STARTTLS-upgrades en is alleen geschikt voor zelf gehoste mailservers. Maak in productie nooit verbinding met een cloudmailserver op poort 143 - de meeste weigeren dergelijke verbindingen nu volledig. Als u niet zeker bent, gebruik dan altijd standaard poort 993 met ssl=True.
Ja, zonder uitzondering. SSL/TLS is verplicht voor elke IMAP-serververbinding die inloggegevens verzendt. Moderne mailservers weigeren verbindingen in platte tekst volledig. RFC 9051 (IMAP4rev2) vereist formeel TLS voor alle geauthenticeerde sessies. Gebruik altijd poort 993 met impliciete TLS voor cloudproviders. Bij verbinding met een zelf gehoste server op poort 143 moet u upgraden naar TLS met het STARTTLS-commando en het servercertificaat verifiëren - gebruik nooit ssl._create_unverified_context() in productie.
Het IMAP-serveradres voor Gmail is imap.gmail.com on poort 993 met SSL/TLS. Voordat je verbinding maakt, moet je IMAP-toegang inschakelen in Gmail-instellingen onder "Doorsturen en POP/IMAP". Authenticatie vereist ofwel een app-specifiek wachtwoord (als 2FA is ingeschakeld) of OAuth 2.0 XOAUTH2 met de scope https://mail.google.com/. Google heeft Basic Auth beperkt voor nieuwe apps en raadt OAuth sterk aan voor programmatische IMAP-toegang.
Het IMAP-serveradres voor zowel persoonlijke Outlook.com-accounts als Microsoft 365-zakelijke accounts is outlook.office365.com on poort 993 met SSL/TLS. Houd er rekening mee dat Microsoft ondersteuning voor Basic Authentication (gebruikersnaam/wachtwoord) voor IMAP beëindigt per December 2026. Alle integraties moeten vóór die deadline migreren naar OAuth 2.0 XOAUTH2. Zie onze Microsoft Graph OAuth voor Outlook Gids voor migratiestappen.
Je hebt een app-specifiek wachtwoord nodig als je account is beveiligd met tweefactorauthenticatie en je Basic Auth gebruikt voor IMAP. App-wachtwoorden zijn 16-tekens lange tokens die je genereert via de beveiligingsinstellingen van je provider (de beveiligingspagina van je Google-account voor Gmail, Apple ID voor iCloud) en die je echte wachtwoord vervangen zonder volledige accounttoegang te verlenen. Voor productieapplicaties voor meerdere gebruikers, OAuth 2.0 heeft sterk de voorkeur over app-wachtwoorden - het is veiliger, vereist het niet opslaan van gebruikersgegevens in uw applicatie, en is de enige methode die geldig blijft na de afschaffing van Microsoft Basic Auth in december 2026.
Ja, voor Microsoft-services. Microsoft heeft het definitieve einde van de ondersteuning voor Basic Authentication via IMAP, POP3 en SMTP in Exchange Online bevestigd in December 2026, met gevolgen voor alle tenants, inclusief die met bestaande vrijstellingen. Elke integratie die gebruikmaakt van gebruikersnaam/wachtwoordverificatie tegen Outlook of Microsoft 365 IMAP zal na die datum stoppen met werken. Google heeft de toegang tot Basic Auth voor Gmail al beperkt en vereist app-wachtwoorden of OAuth voor alle programmatische toegang sinds 2022. Als uw IMAP-integratie verbinding maakt met Microsoft-accounts, moet u migreren naar OAuth 2.0 XOAUTH2 vóór december 2026.
Om verbinding te maken met een IMAP-server met OAuth 2.0, gebruikt u het XOAUTH2 SASL-mechanisme. Na het verkrijgen van een toegangstoken via de standaard OAuth-autorisatiecodestroom, codeert u de reeks gebruiker={email}\x01auth=Bearer {token}\x01\x01 als base64, en geef het vervolgens door aan het AUTHENTICEER XOAUTH2 IMAP-commando. Voor Gmail is de vereiste scope https://mail.google.com/. Voor Microsoft 365 gebruikt u MSAL om een token te verkrijgen met de IMAP.ToegangAlsGebruiker.Alle scope. Toegangstokens verlopen na 3600 seconden en moeten opnieuw worden vernieuwd voordat er opnieuw wordt verbonden - implementeer een tokenvernieuwingscontrole vóór elke nieuwe IMAP-sessie. Zie de volledige codenavolgingen in de sectie XOAUTH2 hierboven.