VPN connecté mais IMAP ne se synchronise pas ? Vérifiez ces trois couches

Connectez-vous au VPN du bureau, ouvrez le client de messagerie et regardez la boîte de réception refuser de s’actualiser alors que le webmail se charge normalement. Le diagnostic habituel est que le VPN laisse passer le trafic mais bloque le courrier, ou que le mot de passe du compte a changé. Les deux hypothèses sautent la structure de ce que fait un client IMAP. Atteindre l’hôte, terminer TLS, s’authentifier et sélectionner une boîte aux lettres sont quatre événements différents, et le VPN ne possède que le premier.

Le mythe : une connexion signifie une ouverture de session

La croyance est que, une fois le tunnel monté et le serveur de messagerie répondant, la boîte aux lettres est effectivement ouverte. Elle ne l’est pas. Le VPN fournit un chemin vers le service ; il ne vous connecte pas et ne sélectionne pas de dossier. Un client peut rester à la quatrième de ces étapes avec un tunnel parfaitement fonctionnel et un mot de passe valide.

C’est dans cet écart que vivent réellement la plupart des rapports « IMAP cassé via VPN ».

Trois états IMAP, et où les clients bloquent

IMAP définit un état non authentifié, un état authentifié et un état sélectionné, et les commandes ne sont valides que dans l’état qui les autorise. Une connexion peut aussi démarrer déjà authentifiée lorsque le serveur propose une pré-authentification, donc l’absence d’invite de mot de passe ne prouve rien. Sélectionner une boîte aux lettres fait passer la session d’authentifiée à sélectionnée, et ce n’est qu’alors que les commandes agissant sur les messages ont une cible.

Un client qui s’authentifie correctement puis n’arrive pas à sélectionner le dossier configuré ressemblera à un échec de synchronisation alors que le serveur se comporte correctement. Dossiers renommés, fournisseur qui mappe « boîte de réception » différemment ou droits d’accès manquants finissent tous ici. La réponse NO étiquetée du serveur est la preuve, et ce n’est pas la même réponse qu’un mot de passe rejeté.

TLS précède la conversation IMAP

Avec TLS implicite sur le port 993, la poignée de main TLS se termine avant qu’une seule commande IMAP soit envoyée, ce qui explique qu’un problème de certificat produise une erreur qui parle de confiance et non de courrier. Le nom d’hôte du courrier doit être validé par rapport au certificat de la même manière qu’un nom d’hôte web ; un tunnel qui préserve le trafic ne rend pas valide un certificat invalide.

Le texte de l’erreur sépare les cas. Un délai de connexion signifie que le SYN ne s’est jamais terminé. Une erreur TLS signifie que la connexion TCP a fonctionné et que la poignée de main non. Une réponse IMAP NO ou BAD signifie que les deux ont réussi et que la couche protocole a rejeté quelque chose. Notez laquelle vous avez vue avant de modifier un réglage.

Le courrier en cache ne prouve rien

Un client de messagerie affiche les messages déjà téléchargés qu’il puisse ou non atteindre le serveur aujourd’hui, donc une boîte de réception qui s’affiche vous dit seulement que le stockage local fonctionne. Tout test réel doit forcer une opération côté serveur : actualisez un dossier, récupérez un message qui n’a jamais été téléchargé, ou envoyez une commande que le client n’émettrait qu’après avoir sélectionné la boîte aux lettres.

Utilisez une vérification non destructive. Actualiser un dossier et lire le journal d’erreurs du compte vaut mieux que supprimer et rajouter le compte, ce qui prouve surtout que l’écran de configuration fonctionne encore.

Envoi et webmail sont des protocoles différents

Envoyer du courrier est une soumission, pas IMAP. Cela utilise un service séparé et généralement un port séparé avec son propre mode TLS et sa propre authentification, donc une boîte d’envoi qui fonctionne ne prouve pas que la boîte IMAP a été sélectionnée, et une boîte d’envoi cassée n’incrimine pas IMAP.

Le webmail est encore différent. Il peut réussir sur le même VPN parce qu’il s’agit d’une session HTTPS contre un front-end web, ce qui ne dit rien sur l’hôte IMAP, le port ou le mode TLS du client de bureau.

Pour un transfert, notez quatre résultats séparément : le chemin VPN, le résultat du point de terminaison de messagerie et de TLS, le résultat de l’authentification du compte et le résultat de la sélection de la boîte aux lettres. Gardez les identifiants et le contenu des messages hors de la note. Cette trace indique à la personne suivante si le correctif relève du réseau, du certificat, du compte ou de la configuration des dossiers, sans affaiblir l’une ou l’autre couche de protection.