LinkedIn
Instagram
WhatsApp
Telegram
Google Agenda
Rejoindre la communauté SlackUne connexion à un serveur IMAP est en réalité
Une connexion serveur IMAP est une session TCP persistante entre un client de messagerie et un serveur de messagerie qui utilise le protocole IMAP (Internet Message Access Protocol) pour synchroniser, récupérer et gérer les messages électroniques stockés à distance - sans les télécharger ni les supprimer du serveur.
Contrairement à POP3, qui a été conçu pour télécharger des messages localement et éventuellement les supprimer du serveur, IMAP a été conçu pour la synchronisation. Chaque lecture, marquage, déplacement ou suppression que vous effectuez localement est reflété sur le serveur - et donc sur tous les appareils connectés à la même boîte aux lettres. C'est pourquoi IMAP est devenu le protocole de facto pour les clients de messagerie modernes.
Au niveau du réseau, une connexion à un serveur IMAP ouvre un socket TCP vers un serveur de messagerie (généralement le port 993 pour SSL/TLS ou le port 143 pour STARTTLS), effectue une négociation TLS, authentifie l'utilisateur (via mot de passe, mot de passe d'application ou OAuth 2.0 XOAUTH2), puis entre dans une machine à états : Non authentifié, Authentifié, Sélectionné (dans un dossier de boîte aux lettres), ou Se déconnecter. La plupart des commandes utiles - FETCH, SEARCH, STORE, COPY, EXPUNGE - ne fonctionnent que dans l'état Selected.
Pour les développeurs créant des intégrations d'e-mails, une connexion au serveur IMAP est le bloc de construction le plus élémentaire. Vous l'établissez, l'authentifiez, SÉLECTIONNEZ une boîte aux lettres, puis interrogez ou utilisez l'IDLE pour les nouveaux messages. Ce guide couvre chaque étape : l'hôte et le port corrects pour chaque fournisseur, la méthode d'authentification correcte en 2026 (OAuth est de plus en plus obligatoire), et une référence complète de dépannage pour les modes d'échec les plus courants.
Ports IMAP expliqués : 143, 993 et quand STARTTLS est acceptable
Il y a exactement deux ports IMAP en usage actif : 993 (TLS implicite, la norme moderne) et 143 (Mise à niveau STARTTLS ou texte brut, ce que la plupart des serveurs n'autorisent plus en texte brut). Connaître la différence est important car utiliser le mauvais port est l'une des causes les plus courantes d'échec de connexion lors de la création d'une intégration IMAP.
Le client se connecte et initie immédiatement une négociation TLS avant que toute donnée IMAP ne soit échangée. Tout le trafic est chiffré dès le premier octet. C'est le comportement par défaut correct pour toute nouvelle intégration.
Le client se connecte en texte clair, puis émet une STARTTLS commande pour passer à TLS. La plupart des serveurs modernes exigent cette mise à niveau et rejettent entièrement les sessions en texte brut.
Recommandation 2026 : toujours utiliser le port 993 avec SSL_CONTEXT (TLS implicite). Si vous vous connectez à un serveur IMAP d'entreprise qui n'expose que le port 143, activez STARTTLS et vérifiez le certificat du serveur. Ne vous connectez jamais à un serveur IMAP en texte clair en production : les identifiants voyagent en clair et la plupart des fournisseurs refusent désormais catégoriquement de telles connexions.
Une courte note sur RFC 9051 (IMAP4rev2), publié en août 2021 en tant que successeur du RFC 3501. IMAP4rev2 exige formellement TLS pour toute connexion transportant des identifiants, déprécie les mécanismes d'authentification basés sur MD5 et supprime le LISTE-ÉTENDUE incompatibilités qui ont causé des bugs subtils dans les clients plus anciens. La plupart des principaux fournisseurs de services cloud (Gmail, Outlook) sont compatibles avec IMAP4rev2 en pratique depuis des années, même avant la finalisation de la RFC. À toutes fins pratiques, ciblez le port 993 + TLS et vous serez conforme à la RFC 9051 par défaut.
Table des paramètres d'hôte et de port - Gmail, Outlook, Yahoo, iCloud, Zoho, Fastmail, AOL, ProtonMail Bridge
Le tableau ci-dessous répertorie les paramètres de connexion IMAP corrects pour les fournisseurs de messagerie les plus utilisés. Toutes les valeurs ont été vérifiées par rapport à la documentation officielle de chaque fournisseur en mai 2026. Utilisez ceci comme référence rapide lors de la configuration d'un client IMAP ou de la construction Intégration de l'API IMAP.
| Fournisseur | Hôte IMAP | Port | Cryptage | OAuth 2.0 (XOAUTH2) | Notes |
|---|---|---|---|---|---|
 Gmail |
imap.gmail.com | 993 | SSL/TLS | Oui (requis pour les nouvelles applications) |
Les mots de passe d'application fonctionnent, mais OAuth est fortement privilégié. Activez d'abord l'IMAP dans les paramètres de Gmail. |
 Outlook / Microsoft 365 |
outlook.office365.com | 993 | SSL/TLS | Oui (Authentification de base obsolète déc. 2026) |
Authentification basique fin de vie décembre 2026 pour tous les locataires. Migrez vers OAuth dès maintenant. |
Yahoo Mail |
imap.mail.yahoo.com | 993 | SSL/TLS | Oui, |
Mot de passe d'application requis si l'authentification à deux facteurs est activée. OAuth via le portail développeur de Yahoo. |
iCloud Mail |
imap.mail.me.com | 993 | SSL/TLS | Non (mot de passe spécifique à l'application uniquement) |
Apple requiert un mot de passe d'application sur appleid.apple.com. Pas de prise en charge OAuth XOAUTH2. |
Zoho Mail |
imap.zoho.com | 993 | SSL/TLS | Oui, |
OAuth via l'API de Zoho Accounts. IMAP doit être activé par boîte aux lettres dans les paramètres de Zoho Mail. |
Fastmail |
imap.fastmail.com | 993 | SSL/TLS | Oui (JMAP préféré) |
Fastmail prend en charge nativement JMAP (plus rapide que IMAP), mais IMAP est entièrement pris en charge. Mots de passe d'application disponibles. |
Courrier AOL |
imap.aol.com | 993 | SSL/TLS | Oui, |
Fait maintenant partie de Yahoo Inc. Mot de passe d'application requis si l'authentification à deux facteurs est activée. OAuth via le portail développeur de Yahoo. |
ProtonMail Bridge (bureau) |
127.0.0.1 | 1143 | STARTTLS | Non (authentification par jeton de pont) |
ProtonMail Bridge s'exécute localement et expose un serveur IMAP local. Ne convient pas aux intégrations côté serveur. |
IMAP générique |
votre-serveur-de-messagerie.com | 993 / 143 | SSL/TLS STARTTLS | Varie (vérifiez la configuration du serveur) |
Dovecot, Postfix, Zimbra, Courier. Vérifiez la réponse CAPABILITY de votre serveur pour les mécanismes d'authentification pris en charge. |
Gmail
Outlook / Microsoft 365
Remarque sur ProtonMail : l'architecture Bridge signifie que les connexions IMAP de ProtonMail ne sont viables que pour les configurations de bureau à utilisateur unique. Pour les intégrations multi-comptes ou côté serveur, ProtonMail n'est pas pris en charge via IMAP standard. Pour Gmail et Outlook à grande échelle, consultez nos guides dédiés sur OAuth pour les API d'e-mail et API Microsoft Graph Email.
Pas à pas : ouverture d'une connexion brute avec un serveur IMAP
Voici des exemples fonctionnels minimaux montrant comment ouvrir une connexion IMAP authentifiée à un serveur en utilisant le module intégré de Python imaplib et Node.js avec imapflow. Ces deux exemples se connectent à Gmail sur le port 993 en utilisant l'authentification par mot de passe d'application. Pour OAuth XOAUTH2, voir H2 #7 ci-dessous.
import imaplib
import ssl
Paramètres du serveur IMAP #
IMAP_HOTE = "imap.gmail.com"
IMAP_PORT = 993
NOM D'UTILISATEUR = "you@gmail.com"
MOT DE PASSE = "votre-mot-de-passe-application" Le mot de passe de l'application #, et non celui de votre compte
# Créer un contexte SSL (vérifier les certificats)
contexte = ssl.créer_contexte_par_défaut()
# : Ouvrir une connexion SSL sur le port 993
avec imaplib.IMAP4_SSL(IMAP_HOTE, IMAP_PORT, ssl_context=contexte En tant que imap :
# Authentification
imap.Se connecter(NOM D'UTILISATEUR, MOT DE PASSE)
# Sélectionner la boîte de réception (affiche le nombre de messages)
statut, données = imap.sélectionner("BOÎTE DE RÉCEPTION")
print(La boîte de réception contient {data[0].decode()} messages")
# À la recherche de messages cachés
statut, ids_messages = imap.recherche(Aucun, "INVISIBLES")
print(Non vu : {msg_ids[0].decode()}")
# Déconnexion (la connexion se ferme à la fin du bloc ' with ')// npm installer imapflow
import { ImapFlow } from 'imapflow';
const client = new ImapFlow({
hôte : 'imap.gmail.com',
port 993,
sécurisé true, // SSL/TLS sur le port 993
auth : {
utilisateur : 'you@gmail.com',
passe 'votre-mot-de-passe-application'
},
journal faux
});
await client.Connecter();
// Verrouiller la boîte aux lettres INBOX pour un accès exclusif
laissez verrouiller = await client.verrouillerBoîteAuxLettres('BOÎTE DE RÉCEPTION');
essayer {
// Récupérer les 5 derniers messages (en-têtes uniquement)
pour await (laissez message de client.fetch('1:5', enveloppe : true })) {
console.log(msg.enveloppe.sujet);
}
} enfin {
verrou.libération();
}
await client.déconnexion();L'exemple Python utilise IMAP4_SSL - l'encapsuleur SSL de plus haut niveau qui gère la négociation TLS automatiquement. Évitez d'utiliser IMAP4 manuel starttls() pour les fournisseurs de cloud car cela ajoute de la complexité sans avantage. Pour Node.js, imapflow le choix moderne basé sur les Promesses (l'ancien node-imap la bibliothèque est abandonnée depuis 2024 et ne prend pas en charge XOAUTH2).
Les deux exemples utilisent des mots de passe d'application, qui sont le type d'identifiants le plus simple pour des tests rapides. Pour les systèmes de production gérant plusieurs utilisateurs, vous aurez besoin de OAuth 2.0 - voir la section XOAUTH2 ci-dessous. Pour une solution complète prête pour la production sans gérer de connexions IMAP brutes, voir le Guide du développeur de l'API IMAP.
Omettre le code standard IMAP. Unipile vous permet de lire, d'envoyer et de synchroniser Gmail, Outlook et IMAP via une seule API REST, sans gestion de connexion requise.
Évitez le code IMAP répétitif - Construisez-le avec UnipileAuthentification : mot de passe, mot de passe d'application et OAuth 2.0 (XOAUTH2)
Une connexion au serveur IMAP nécessite de s'authentifier après la négociation TLS. Trois méthodes d'authentification sont utilisées aujourd'hui, chacune avec un profil de sécurité, un niveau de complexité et une compatibilité différents avec les fournisseurs de cloud en 2026.
Le mécanisme IMAP AUTH PLAIN / LOGIN d'origine. Vous envoyez directement l'adresse e-mail du compte et le mot de passe du compte au serveur IMAP. Simple à implémenter mais de plus en plus bloqué par les fournisseurs de cloud pour des raisons de sécurité.
Obsolète pour le cloudUn jeton de 16 caractères généré par le fournisseur (Gmail, Yahoo, iCloud) qui remplace le mot de passe réel du compte. Fonctionne avec la même commande IMAP LOGIN que l'authentification de base, mais est limité et peut être révoqué indépendamment. Requis lorsque la 2FA est activée.
Acceptable pour un usage personnelL'utilisateur autorise votre application via un écran de consentement. Votre application reçoit un jeton d'accès (de courte durée, généralement 1 heure) que vous encodez en base64 et transmettez à la commande IMAP AUTHENTICATE XOAUTH2. Les jetons sont actualisés avec un jeton de rafraîchissement de longue durée. La seule méthode viable pour les applications de production multi-utilisateurs.
Requis pour la productionQuand utiliser quoi : Utilisez des mots de passe d'application lors du développement local et pour les outils personnels. Utilisez OAuth 2.0 XOAUTH2 pour toute intégration multi-utilisateurs - c'est la seule méthode qui permet de passer à l'échelle, car vous ne stockez jamais les mots de passe des utilisateurs, et chaque jeton peut être révoqué sans modifier le mot de passe de l'utilisateur. Pour Gmail, Google restreint progressivement l'authentification de base pour les "applications moins sécurisées" depuis 2022. Pour Microsoft/Outlook, la suppression de l'authentification de base est prévue pour décembre 2026 dans tous les locataires (voir la section suivante).
Pour une analyse approfondie des flux OAuth – y compris l'échange de jetons, la logique de rafraîchissement et les portées – consultez notre guide sur OAuth pour les API d'e-mail. Pour la configuration OAuth spécifique à Microsoft, voir Microsoft Graph OAuth pour Outlook.
Le problème de 2026 : dépréciation de l'authentification de base de Microsoft (décembre 2026)
Si votre intégration IMAP se connecte à des comptes Microsoft 365 ou Outlook en utilisant directement un nom d'utilisateur et un mot de passe, vous êtes sur le point de compter à rebours. Microsoft a annoncé la date de fin de vie définitive pour l'authentification de base sur IMAP, POP3 et SMTP pour tous les locataires.
Selon Microsoft Apprendre et le Annonce du Hub communautaire Microsoft, Exchange Online désactivera complètement l'authentification de base pour IMAP, POP3 et SMTP en décembre 2026 sur tous les locataires – y compris ceux bénéficiant d'exemptions existantes. Tout client IMAP ou toute intégration côté serveur utilisant toujours l'authentification par nom d'utilisateur/mot de passe cessera de fonctionner. Aucune prolongation supplémentaire n'est disponible.
Étapes d'action à migrer avant la date limite
Recherchez dans votre base de code les connexions IMAP qui utilisent connexion(nomdutilisateur, motdepasse) ou AUTH PLAIN. Vérifiez les journaux de connexion Microsoft Entra ID (anciennement Azure AD) pour l’activité d’authentification de base IMAP.
Créer un enregistrement d'application sur portal.azure.com avec le IMAP.AccéderEnTantQuUtilisateur.Tout (délégué) ou IMAP.AccèsEnTantQuApplication permission. Voir Microsoft Graph OAuth pour Outlook pour un guide étape par étape.
Utilisez MSAL (Microsoft Authentication Library) pour acquérir des jetons d'accès. Implémentez une logique de rafraîchissement de jeton - les jetons Microsoft expirent après 1 heure et vous avez besoin d'un flux de jeton de rafraîchissement pour maintenir des sessions IMAP de longue durée sans ré-authentification de l'utilisateur.
Remplacer l'IMAP CONNEXION commande avec AUTHENTIFIER XOAUTH2 en utilisant une chaîne de jeton encodée en base64. Voir l'exemple de code complet dans la section XOAUTH2 ci-dessous.
Microsoft fournit un moyen de désactiver l'authentification de base tôt, au niveau du locataire - utilisez ceci pour tester votre flux OAuth avant la coupure forcée de décembre 2026, afin de ne pas avoir à déboguer des problèmes de production sous la pression des délais.
Si vous gérez des connexions IMAP pour plusieurs utilisateurs Microsoft 365 - un scénario courant pour les outils CRM, ATS ou d'automatisation des ventes - la complexité de la migration s'accroît rapidement. Vous devez gérer les flux de consentement OAuth pour chaque utilisateur, stocker et actualiser les jetons en toute sécurité, et traiter les stratégies d'accès conditionnel qui peuvent bloquer votre application dans certains locataires. C'est l'une des raisons principales pour lesquelles les développeurs choisissent une API IMAP gérée plutôt que de maintenir eux-mêmes des connexions brutes.
La date limite pour l'authentification de base Microsoft approche. Créez un flux OAuth pérenne dès aujourd'hui avec l'API unifiée de messagerie d'Unipile - nous nous occupons pour vous du rafraîchissement des jetons, de l'authentification multi-locataire et du XOAUTH2.
Concevoir un flux OAuth pérenneConnexion via OAuth XOAUTH2
XOAUTH2 est le mécanisme SASL qui permet d'authentifier une connexion à un serveur IMAP en utilisant un jeton d'accès OAuth 2.0 au lieu d'un mot de passe. Le jeton est obtenu via le flux d'autorisation standard OAuth avec code (ou les informations d'identification du client pour les comptes de service), encodé en base64 dans un format spécifique, et transmis au AUTHENTIFIER XOAUTH2 Commande IMAP.
Gmail (Google)Microsoft 365import imaplib, base64, json
from google.oauth2.credentials import Indentifications
from google.auth.transport.requests import Requête
# Charger les identifiants OAuth obtenus précédemment
# (provenant du flux google-auth-oauthlib)
identifiants = Identifiants(
jeton=JETON_ACCÈS,
token_rafraîchissement=TOKEN_REFRAICHISSEMENT,
uri_jeton="https://oauth2.googleapis.com/token",
client_id=CLIENT_ID,
secret_client=CLIENT_SECRET,
lunettes de visée=["https://mail.google.com/"]
)
# Jeton d'actualisation s'il a expiré
si crédits.expirés:
identifiants.Actualiser(Requête())
# Génération de la chaîne XOAUTH2 : " user={email}\x01auth=Bearer {token}\x01\x01 "
email_utilisateur = "user@gmail.com"
chaine_auth = f"utilisateur={user_email}\x01auth=Bearer {creds.token}\x01\x01"
auth_b64 = base64.b64encode(chaîne_authentification.encoder()).décoder()
# : Ouvrir une connexion IMAP et s'authentifier
avec imaplib.IMAP4_SSL("imap.gmail.com", 993) En tant que imap :
imap.authentifier("XOAUTH2", lambda _: auth_b64)
imap.sélectionner("BOÎTE DE RÉCEPTION")
print("Connecté via XOAUTH2")import imaplib, base64
from msal import ClientApplicationConfidentielle
# Obtenir un jeton via MSAL (flux d'informations d'identification du client pour les comptes de service)
# Pour l'accès délégué par l'utilisateur, utilisez plutôt le flux de code d'authentification
application = ClientApplicationConfidentielle(
client_id=CLIENT_ID,
autorité=https://login.microsoftonline.com/{TENANT_ID}",
identifiants client=CLIENT_SECRET
)
résultat = application.acquérir_jeton_pour_client(
lunettes de visée=["https://outlook.office365.com/.default"]
)
access_token = résultat["jeton_d'accès"]
# Créer une chaîne XOAUTH2
email_utilisateur = "user@company.com"
chaine_auth = f"utilisateur={user_email}\x01authentification=Bearer {access_token}\x01\x01"
auth_b64 = base64.b64encode(chaîne_authentification.encoder()).décoder()
# : Connexion à Outlook via IMAP
avec imaplib.IMAP4_SSL("outlook.office365.com", 993) En tant que imap :
imap.authentifier("XOAUTH2", lambda _: auth_b64)
imap.sélectionner("BOÎTE DE RÉCEPTION")
print("Connecté via XOAUTH2 à Outlook")Principales différences entre Gmail et Microsoft XOAUTH2 : Gmail nécessite l' https://mail.google.com/ portée (accès complet à Gmail). Microsoft exige IMAP.AccéderEnTantQuUtilisateur.Tout (délégué) ou IMAP.AccèsEnTantQuApplication (application). Le format de chaîne XOAUTH2 en base64 est identique pour les deux fournisseurs : email={email}\x01auth=Bearer {token}\x01\x01.
Un détail d'implémentation essentiel : les jetons expirent après 3600 secondes. Une session IMAP IDLE de longue durée (voir la section suivante) recevra une erreur d'authentification lorsque le jeton expirera en milieu de session. Vous devez intercepter l' AUTHENTIFICATIONÉCHOUE erreur, actualisez le jeton à l'aide de votre jeton d'actualisation, puis rétablissez la connexion IMAP. Cette boucle de nouvelle tentative n'est pas triviale et est une raison principale pour laquelle les équipes choisissent une API gérée comme Guide de l'API unifiée pour les e-mails au lieu de connexions IMAP brutes.
Pour un guide complet de configuration OAuth pour Microsoft, y compris les considérations relatives aux stratégies d'accès conditionnel, consultez notre Microsoft Graph OAuth pour Outlook guide.
OAuth XOAUTH2 est un mécanisme d'authentification. Il permet à une application d'accéder à des ressources utilisateur. L'utilisateur autorise l'application sans partager ses identifiants. XOAUTH2 est une extension de base de OAuth 2.0. Il utilise des jetons d'accès pour authentification. Le client envoie le jeton dans l'en-tête d'une requête. Le serveur valide le jeton pour accorder l'accès. C'est courant pour l'accès aux e-mails (Gmail, Outlook). Cela simplifie l'intégration et la sécurité pour les utilisateurs. Utilisation via des protocoles comme IMAP, POP3, SMTP via SASL. Unipile gère automatiquement l'acquisition, le rafraîchissement et la réauthentification IMAP des tokens. Concentrez-vous sur la lecture de vos e-mails, pas sur la gestion des connexions.
Créez OAuth XOAUTH2 en 10 lignes avec Unipile 1. Importez les modules nécessaires : `unipile`, `google.oauth2.credentials`, `googleapiclient.discovery`. 2. Initialisez un client Unipile : `unipile_client = unipile.Client()`. 3. Générez la configuration OAuth2 : `flow = google_auth_oauthlib.flow.InstalledAppFlow.from_client_secrets_file(...)`. 4. Créez les informations d'identification : `credentials = flow.run_local_server(port=0)`. 5. Créez un service Gmail : `service = googleapiclient.discovery.build('gmail', 'v1', credentials=credentials)`. 6. Construisez la requête XOAUTH2 : `xoauth2_string = unipile_client.generate_xoauth2_string(credentials.to_json())`. 7. Ajoutez l'en-tête d'autorisation : `headers = {{'Authorization': f'XOAUTH2 {xoauth2_string}'}}`. 8. Créez un message : `message = service.users().messages().create(userId='me', body={{'raw': base64.urlsafe_b64encode(message_body.encode()).decode()}}).execute()`. 9. Envoyez le message avec l'en-tête : `response = service.users().messages().send(userId='me', body={{'raw': base64.urlsafe_b64encode(sent_message.as_bytes()).decode()}}, headers=headers).execute()`. 10. Gérez la réponse.IDLE, interrogation et notifications push : maintenir la connexion IMAP active
Une fois que vous avez une connexion authentifiée au serveur IMAP, le défi suivant consiste à détecter les nouveaux messages efficacement sans surcharger le serveur avec des requêtes constantes. Il existe trois modèles actuellement utilisés, chacun avec une latence, une complexité et des exigences d'infrastructure différentes.
| Méthode | Comment cela fonctionne-t-il ? | Temps de latence | Infrastructure | Meilleur pour | Évaluation |
|---|---|---|---|---|---|
| IMAP IDLE (RFC 2177) | Le client rencontre des problèmes avec la commande IDLE ; le serveur envoie des notifications EXISTS/RECENT sur la connexion TCP ouverte lorsque de nouveaux e-mails arrivent. Le client doit envoyer DONE + réémettre IDLE toutes les 29 minutes (délai d'attente du serveur). | ~1 à 5 secondes | 1 connexion TCP persistante par boîte aux lettres. Nécessite un thread dédié ou une boucle asynchrone. | Outils mono-utilisateur, clients de bureau, surveillance à faible latence | Bien |
| Sondage (NOOP / CHECK) | Le client se reconnecte périodiquement, effectue un SELECT + SEARCH UNSEEN pour rechercher de nouveaux messages, puis se déconnecte. Simple et sans état. | Égale à l'intervalle de sondage (typiquement 1 à 15 minutes) | Sans état. Fonctionne derrière un NAT/des pare-feux. Aucune connexion persistante. | Traitement par lots, latence élevée acceptable, environnements où les connexions persistantes sont bloquées | Acceptable |
| Push du fournisseur (Gmail Pub/Sub, Webhooks MS Graph) | Le fournisseur envoie une notification HTTP à votre point de terminaison de webhook lorsqu'un nouvel e-mail arrive. Aucune connexion IMAP n'est nécessaire au repos. Gmail utilise Google Cloud Pub/Sub ; Microsoft utilise les notifications de modification de MS Graph. | Quasi en temps réel(typiquement <1 seconde) | Nécessite un point d'accès HTTPS public et un abonnement Pub/Sub. Pas de connexion IMAP persistante au repos. | Systèmes de production multi-comptes à grande échelle, architectures serverless | Le meilleur à grande échelle |
IDLE est le bon choix pour des intégrations simples où vous contrôlez un petit nombre de comptes. Les principaux écueils : vous devez vous reconnecter avant l'expiration du délai d'inactivité de 29 minutes (Gmail applique ceci strictement), et vous avez besoin de connexions IMAP séparées pour chaque boîte aux lettres - ce qui devient coûteux pour des centaines ou des milliers de comptes.
Notifications push du fournisseur sont l'architecture correcte pour les systèmes multi-comptes en production. L'intégration Pub/Sub de Gmail et les webhooks d'abonnement de Microsoft Graph fournissent tous deux des notifications quasi en temps réel sans nécessiter une connexion IMAP persistante pour chaque compte. Le compromis : vous devez toujours ouvrir une connexion IMAP pour récupérer le corps du message réel lorsque vous êtes notifié, ce qui signifie que votre code de connexion IMAP est toujours nécessaire - il n'est juste pas maintenu ouvert en permanence. Pour lire les messages électroniques via l'API, consultez notre guide sur lire les e-mails via l'API et envoi d'e-mails via l'API.
Matrice de dépannage : timeouts, échecs d'authentification (handshake), erreurs d'authentification (auth), limites de taux
Voici une référence structurée pour les erreurs de connexion aux serveurs IMAP les plus courantes. Associez le symptôme (message d'erreur ou comportement observable) à la cause probable et à la solution recommandée.
| Symptôme / Erreur | Type | Cause probable | Réparer |
|---|---|---|---|
| Connexion refusée sur le port 993 | Connexion | Hôte incorrect, IMAP désactivé dans les paramètres du fournisseur, ou pare-feu bloquant la sortie 993 | Vérifiez l'hôte du tableau ci-dessus. Activez l'IMAP dans les paramètres du fournisseur (Gmail : Paramètres > Transfert et POP/IMAP). Vérifiez le pare-feu/proxy pour le TCP sortant 993. |
| Délai d'attente de la négociation SSL / CERTIFICATE_VERIFY_FAILED | TLS | Certificat expiré ou auto-signé, bundle CA obsolète, mauvais port (143 au lieu de 993) | Utilisez ssl.create_default_context() (Python) - ne pas passer ssl._create_unverified_context() en production. Mettez à jour votre bundle de CA (pip installer certifiConfirmez que vous vous connectez au port 993. |
| AUTHENTICATIONFAILED / [AUTHENTICATIONFAILED] Identifiants invalides | Auth | Mot de passe incorrect, mot de passe d'application non généré, 2FA activé mais mot de passe d'application non utilisé, Authentification de base bloquée par le fournisseur | Générez un mot de passe d'application spécifique à partir des paramètres de sécurité du fournisseur. Si vous utilisez Gmail, assurez-vous que "l'accès aux applications moins sécurisées" n'est pas la méthode utilisée - utilisez un mot de passe d'application ou OAuth. Pour Microsoft, vérifiez si l'authentification de base est désactivée pour le locataire. |
| AUTHENTIFIER XOAUTH2 - jeton_invalide | OAuth | Jeton d'accès expiré (les jetons durent 3600s), chaîne XOAUTH2 malformée en base64, portée incorrecte | Actualisez le jeton d'accès avant de vous connecter. Vérifiez le format de la chaîne XOAUTH2: email={email}\x01auth=Bearer {token}\x01\x01. Vérifier la portée : Gmail a besoin https://mail.google.com/; Outlook a besoin IMAP.AccéderEnTantQuUtilisateur.Tout. |
| imaplib.error : commande AUTHENTICATE illégale dans l'état AUTH | État | Tentative d'authentification alors que l'état est déjà authentifié, ou après une tentative d'authentification échouée sans réinitialisation | Fermez et rouvrez la connexion IMAP avant de retenter l'authentification. Ne retentez jamais l'authentification sur la même connexion après un échec. |
| Les connexions IMAP tombent après 29 minutes d'inactivité | INACTIF | Timeout IDLE forcé par le serveur (par défaut : 30 minutes selon la RFC 2177). Gmail applique 29 minutes. | Problème FAIT de 25 à 27 minutes, puis réémettre immédiatement INACTIF. Utilisez un thread d'arrière-plan ou une tâche asynchrone avec une minuterie de battement de cœur de 25 minutes. |
| [DÉPASSEMENT DE QUOTA] ou Trop de connexions simultanées | Limite de débit | Limite de connexion imposée par le fournisseur dépassée. Gmail autorise 15 connexions IMAP simultanées par compte ; Outlook varie selon le forfait. | Utilisez la mise en commun des connexions. Pour Gmail : max 15 connexions simultanées par compte. Fermez explicitement les connexions inactives.SE DÉCONNECTER) plutôt que de laisser tomber TCP. Implémenter une augmentation exponentielle du délai d'attente en cas d'erreurs de connexion. |
| NON [ALERTE] Veuillez vous connecter via votre navigateur Web | Auth | Défi de sécurité Google déclenché (modèle d'accès inhabituel, nouvelle IP, captcha requis) | Connectez-vous via le navigateur depuis le même réseau pour résoudre le défi de sécurité. Envisagez de passer à OAuth - l’accès par mot de passe d’application depuis des adresses IP inconnues déclenche ces défis plus souvent que OAuth. |
| AU REVOIR Déconnexion automatique ; inactif trop longtemps | Connexion | Connexion IMAP dans l'état Authentifié (boîte aux lettres non sélectionnée) est restée inactive trop longtemps | Après authentification, sélectionnez immédiatement une boîte aux lettres ou émettez IDLE. Implémentez la logique de reconnexion lorsque vous recevez BYE. |
| FETCH retourne un corps vide / parties nulles | Protocole | Message supprimé entre SEARCH et FETCH, ou inégalité UID après ré-analyse du dossier | Toujours utiliser UID RECHERCHE (pas de numéros de séquence) pour les opérations en plusieurs étapes. Gérer Aucun restituer les valeurs de FETCH avec grâce. Relancer SEARCH après une reconnexion pour obtenir des UID à jour. |
ssl.create_default_context() (Python) - ne pas passer ssl._create_unverified_context() en production. Mettez à jour votre bundle de CA (pip installer certifiConfirmez que vous vous connectez au port 993.
email={email}\x01auth=Bearer {token}\x01\x01. Vérifier la portée : Gmail a besoin https://mail.google.com/; Outlook a besoin IMAP.AccéderEnTantQuUtilisateur.Tout.
FAIT de 25 à 27 minutes, puis réémettre immédiatement INACTIF. Utilisez un thread d'arrière-plan ou une tâche asynchrone avec une minuterie de battement de cœur de 25 minutes.
SE DÉCONNECTER) plutôt que de laisser tomber TCP. Implémenter une augmentation exponentielle du délai d'attente en cas d'erreurs de connexion.
UID RECHERCHE (pas de numéros de séquence) pour les opérations en plusieurs étapes. Gérer Aucun restituer les valeurs de FETCH avec grâce. Relancer SEARCH après une reconnexion pour obtenir des UID à jour.
Arrêtez de déboguer les erreurs IMAP. Unipile expose des objets d'e-mail propres via REST - pas de machine à états IMAP, pas de logique de rafraîchissement de jeton, pas de mise en conserve de connexion à gérer.
Arrêtez de déboguer IMAP - Commencez à construirePourquoi la production d'IMAP à grande échelle est plus difficile qu'il n'y paraît
L'ouverture d'une seule connexion au serveur IMAP à une boîte de réception Gmail représente 15 lignes de Python. La mise à l'échelle pour des centaines ou des milliers d'utilisateurs dans un produit SaaS de production est un problème d'ingénierie fondamentalement différent. Voici une analyse honnête de la manière dont les connexions IMAP brutes créent une complexité non évidente.
Les jetons d'accès expirent toutes les 3600 secondes. Pour 1 000 comptes liés, vous avez besoin d'un processus d'arrière-plan qui actualise proactivement les jetons avant leur expiration, gère la rotation des jetons d'actualisation (Google les fait pivoter dans certaines conditions) et gère le cas où un utilisateur révoque l'accès - ce que vous ne découvrez qu'à la prochaine utilisation du jeton.
Chaque session IMAP active conserve un état : la boîte aux lettres actuellement sélectionnée, le dernier UID vu, le timer IDLE. Si votre serveur redémarre, vous perdez tout cet état et devez resynchroniser à partir de zéro, récupérant potentiellement des milliers de messages que vous avez déjà traités. Vous avez besoin d'un magasin d'état persistant par compte.
Les échecs temporaires (micro-coupures réseau, erreurs 500 du serveur, réponses d'atteinte de limite) nécessitent une logique de nouvelle tentative avec exponentielle décroissante et jitter. Les boucles de nouvelle tentative naïves surchargent les fournisseurs et entraînent des bannissements temporaires d'IP. Il faut une file de tâches appropriée avec des délais de nouvelle tentative configurables et une gestion des messages non distribués pour les comptes en échec permanent.
Les jetons de rafraîchissement OAuth sont des identifiants de longue durée qui accordent un accès complet aux e-mails. Ils doivent être chiffrés au repos à l'aide d'une clé prise en charge par KMS, contrôlés en accès au niveau de l'infrastructure et échangés en cas de suspicion de violation. Il s'agit d'une surface d'attaque de sécurité significative qui nécessite une infrastructure de gestion des clés appropriée.
Gmail limite les connexions IMAP simultanées à 15 par compte. Si votre application ouvre plus de connexions que la limite autorisée, elle reçoit des erreurs OVERQUOTA. Dans le même temps, les fournisseurs imposent également des quotas de bande passante sur le volume total de données transférées. Vous avez besoin d'un pool de connexions, d'une limitation des requêtes et du suivi des débits par compte.
Étiquettes Gmail vs. dossiers IMAP, dénomination non standard des dossiers Envoyés/Supprimés par Outlook, serveurs IMAP qui retournent des réponses CAPABILITY qui ne correspondent pas à ce qu'ils supportent réellement, et serveurs qui coupent silencieusement les connexions pendant les opérations FETCH sur de grosses pièces jointes. Chaque fournisseur a un ensemble unique de particularités qui ne se manifestent qu'en production.
Ce n'est pas un argument contre la création d'une intégration IMAP personnalisée - pour un outil à fournisseur unique et utilisateur unique, l'IMAP brut est tout à fait raisonnable. Mais pour tout produit qui a besoin de Lire et synchroniser les courriels sur plusieurs fournisseurs et plusieurs comptes d'utilisateurs, le coût opérationnel de la maintenance d'une couche IMAP personnalisée dépasse généralement le coût de l'utilisation d'une API de messagerie dédiée. Le Guide de l'API unifiée pour les e-mails couvre les compromis architecturaux en détail.
Synchronisation des e-mails de production sans la surcharge IMAP. Unipile gère la mise en pool de connexions, le rafraîchissement des jetons, la nouvelle tentative d'erreurs et la normalisation multi-fournisseurs - vous n'avez qu'à appeler l'API.
Construire à grande échelle sans la surcharge IMAPCréer une intégration IMAP sans gérer la connexion : Unipile
Si vous avez lu jusqu'ici, vous avez une idée claire de ce qu'il faut pour maintenir des connexions IMAP brutes en production : boucles de rafraîchissement de jetons OAuth, gestion de l'état par compte, pooling de connexions, logique de nouvelle tentative et particularités spécifiques aux fournisseurs pour Gmail, Outlook et les serveurs IMAP. Unipile abstrait toute cette couche et vous donne une API REST unique pour lire, envoyer et synchroniser les e-mails sur les trois, avec un démarrage rapide en 5 minutes et moins de 10 lignes de code par opération.
Unipile gère le flux OAuth complet pour Gmail et Microsoft 365 : acquisition, actualisation et rotation des jetons. Vous ne touchez jamais directement un jeton d'actualisation.
Une API, un schéma de réponse. Lisez les e-mails d'une boîte de réception Gmail et d'un serveur d'entreprise IMAP avec le même appel GET /emails. Pas d'analyse spécifique au fournisseur.
Recevez des notifications HTTP lorsque de nouveaux e-mails arrivent. Aucune connexion IMAP persistante à gérer, aucun délai d'attente IDLE de 29 minutes à traiter, aucun thread dédié par compte.
Liez les comptes utilisateurs via le flux OAuth hébergé d'Unipile. Chaque compte lié obtient son propre `account_id`. Adaptez-vous de 1 à 10 000 comptes liés sans modifier votre code d'intégration.
Identifiants chiffrés au repos avec des clés prises en charge par KMS. Unipile est certifié SOC 2 Type II et évalué CASA Tier 2. Aucun mot de passe IMAP ni jeton OAuth stocké dans votre base de données.
import demandes
BASE_URL = "https://api7.unipile.com:13047/api/v1"
EN-TÊTES = {"X-API-KEY": "votre-clé-api-unipile"}
# Étape 1 : Dressez la liste de tous les comptes associés
comptes = requêtes.obtenir(
"{BASE_URL}/comptes", en-têtes=EN-TÊTES
).json()
account_id = comptes["articles"][0]["id"]
# Étape 2 : Lire les e-mails de la boîte de réception
courriels = requêtes.obtenir(
f"{URL_DE_BASE}/emails",
en-têtes=EN-TÊTES,
paramètres={"account_id": identifiant_compte, "limite": 10}
).json()
pour l'email en courriels"articles"]:
print(e-mail["sujet"], courriel["de_participant"])
# Pas de connexion IMAP, pas d'actualisation du jeton,
# : pas de contexte SSL, pas de machine à états.
Questions fréquemment posées
Questions courantes sur les connexions aux serveurs IMAP, les ports, l'authentification et la migration OAuth.
Une connexion à un serveur IMAP est une session TCP persistante entre un client de messagerie et un serveur de messagerie qui utilise le protocole d'accès aux messages Internet pour synchroniser, récupérer et gérer les messages électroniques stockés sur le serveur, sans les télécharger ni les supprimer localement. Contrairement au POP3, IMAP conserve les messages sur le serveur et synchronise les états (lus, marqués, déplacés) sur tous les appareils connectés. Pour les développeurs, il s'agit du protocole fondamental pour créer des intégrations de messagerie qui fonctionnent sur Gmail, Outlook et n'importe quel serveur standard. API IMAP.
Utilisez port 993 pour IMAP sur SSL/TLS (TLS implicite). C'est la norme moderne et elle est requise par tous les principaux fournisseurs de cloud, y compris Gmail et Outlook. Le port 143 est destiné aux mises à niveau STARTTLS et ne convient qu'aux serveurs de messagerie auto-hébergés. Ne jamais se connecter à un serveur de messagerie cloud sur le port 143 en production - la plupart refusent désormais entièrement de telles connexions. En cas de doute, utilisez toujours le port 993 avec ssl=Vrai.
Oui, sans exception. SSL/TLS est obligatoire pour toute connexion à un serveur IMAP qui transmet des identifiants. Les serveurs de messagerie modernes refusent totalement les connexions en texte brut. La RFC 9051 (IMAP4rev2) exige formellement le TLS pour toutes les sessions authentifiées. Utilisez toujours port 993 avec TLS implicite pour les fournisseurs de cloud. Si vous vous connectez à un serveur auto-hébergé sur le port 143, vous devez passer à TLS en utilisant la commande STARTTLS et vérifier le certificat du serveur - n'utilisez jamais ssl._create_unverified_context() en production.
L'adresse du serveur IMAP pour Gmail est imap.gmail.com on port 993 avec SSL/TLS. Avant de vous connecter, vous devez activer l'accès IMAP dans les paramètres de Gmail sous " Transfert et POP/IMAP ". L'authentification nécessite un mot de passe spécifique à l'application (si l'authentification à deux facteurs est activée) ou OAuth 2.0 XOAUTH2 avec la portée https://mail.google.com/. Google a restreint l'authentification de base pour les nouvelles applications et recommande fortement OAuth pour tout accès programmatique IMAP.
L'adresse du serveur IMAP pour les comptes Outlook.com personnels et les comptes professionnels Microsoft 365 est outlook.office365.com on port 993 avec SSL/TLS. Notez que Microsoft met fin à la prise en charge de l'authentification de base (nom d'utilisateur/mot de passe) pour IMAP dans Décembre 2026. Toutes les intégrations doivent migrer vers OAuth 2.0 XOAUTH2 avant cette date limite. Voir notre Microsoft Graph OAuth pour Outlook Guide des étapes de migration.
Vous avez besoin d'un mot de passe spécifique à l'application si votre compte dispose de l'authentification à deux facteurs et que vous utilisez l'authentification de base pour IMAP. Les mots de passe d'application sont des jetons de 16 caractères générés à partir des paramètres de sécurité de votre fournisseur (page de sécurité du compte Google pour Gmail, identifiant Apple pour iCloud) qui remplacent votre vrai mot de passe sans accorder un accès complet au compte. Pour les applications multi-utilisateurs en production, OAuth 2.0 est fortement préférable Les mots de passe d'application – ils sont plus sécurisés, ne nécessitent pas de stocker d'informations d'identification utilisateur dans votre application, et constituent la seule méthode qui restera valide après la dépréciation de Microsoft Basic Auth en décembre 2026.
Oui, pour les services Microsoft. Microsoft a confirmé la fin de vie définitive de l'authentification de base pour IMAP, POP3 et SMTP dans Exchange Online. Décembre 2026, affectant tous les locataires, y compris ceux qui bénéficient déjà d'exemptions. Toute intégration utilisant une authentification par nom d'utilisateur/mot de passe pour Outlook ou Microsoft 365 IMAP cessera de fonctionner après cette date. Google a déjà restreint l'accès à l'authentification de base pour Gmail et exige des mots de passe d'application ou OAuth pour tout accès programmatique depuis 2022. Si votre intégration IMAP se connecte à des comptes Microsoft, vous devez migrer vers OAuth 2.0 XOAUTH2 avant décembre 2026.
Pour vous connecter à un serveur IMAP avec OAuth 2.0, vous utilisez le mécanisme SASL XOAUTH2. Après avoir obtenu un jeton d'accès via le flux de code d'autorisation OAuth standard, encodez la chaîne email={email}\x01auth=Bearer {token}\x01\x01 en base64, puis le passer à la AUTHENTIFIER XOAUTH2 Commande IMAP. Pour Gmail, la portée requise est https://mail.google.com/. Pour Microsoft 365, utilisez MSAL pour acquérir un jeton avec le IMAP.AccéderEnTantQuUtilisateur.Tout Les jetons d'accès expirent après 3600 secondes et doivent être actualisés avant de se reconnecter. Implémentez une vérification de l'actualisation du jeton avant chaque nouvelle session IMAP. Voir les exemples de code complets dans la section XOAUTH2 ci-dessus.
FR 
EN 
ES 
DE 
IT 
BR 
NL 
PL 
TR