Boîte de réception unifiée : tous vos comptes sans transfert

Une boîte de réception unifiée rassemble les messages de tous vos comptes dans une liste classée par date de réception. Chaque ligne indique le compte d’origine. Beaucoup découvrent cette solution après avoir essayé de regrouper leur courrier par transfert et rencontré ses limites.

Avec un transfert mal configuré, les informations de l’expéditeur peuvent changer, certains messages finir dans les indésirables et les réponses partir d’une adresse inconnue du destinataire. Le second compte retrouve alors son propre onglet, qu’il faut consulter plusieurs fois par jour.

Le problème ne se résout pas toujours en modifiant une règle. Le transfert change le parcours du message et peut affecter son authentification. SRS, une signature DKIM intacte et une chaîne ARC reconnue par le destinataire peuvent aider, mais ne font pas du transfert un véritable client pour plusieurs comptes.

L’autre approche consiste à lire directement toutes les boîtes avec un seul client. Les logiciels de bureau le font depuis longtemps. Une boîte unifiée côté serveur reprend ce principe, avec la même liste sur le téléphone et l’ordinateur.

Pourquoi le transfert ne remplace pas un client

Le transfert réexpédie le message depuis un serveur que l’expéditeur initial n’a généralement pas autorisé dans SPF. SPF peut donc échouer. DKIM reste souvent valide si les parties signées n’ont pas changé. DMARC exige un SPF ou DKIM valide et aligné ; si aucun ne convient, une politique p=reject recommande au serveur destinataire de rejeter le message. La décision finale lui appartient. Le transfert peut ainsi provoquer des échecs de livraison.

Sender Rewriting Scheme remplace l’expéditeur d’enveloppe par un domaine qui autorise le serveur de transfert. Dans le système décrit, SRS est appliqué automatiquement et aide à valider SPF pour cette nouvelle enveloppe. Il n’aligne pas ce domaine avec le From initial, ne répare pas une signature DKIM endommagée et ne permet pas de répondre depuis l’ancienne adresse.

Ce dernier point est souvent sous-estimé. Le transfert va dans un seul sens. Un message adressé à you@oldcompany.com arrive dans la nouvelle boîte ; vous répondez et le destinataire voit you@newcompany.com si l’envoi depuis l’ancienne adresse n’a pas été configuré séparément. Dans un échange client, cela peut créer une confusion. Une règle de transfert ne donne pas le droit d’envoyer depuis l’adresse précédente.

Le stockage compte aussi. La copie transférée consomme de l’espace à destination, et l’original peut en consommer à la source. Si vous le supprimez après transfert, cette copie locale ne peut plus servir de recours. Une règle incorrecte peut alors compliquer la récupération. Les sauvegardes doivent être évaluées indépendamment du transfert.

Le transfert est utile pour une adresse sans boîte propre, comme invoices@, qui dirige les factures vers la personne responsable. Il ne remplace pas la lecture et l’envoi depuis plusieurs comptes actifs. Voir alias, boîtes et transfert et SRS pour les messages transférés.

La collecte POP et le retrait de l’ancien système

Une autre méthode traditionnelle consiste à se connecter régulièrement à l’autre compte en POP3, télécharger les nouveaux messages et les stocker localement. Gmail Mail Fetcher fonctionnait ainsi. Les comptes connectés d’Outlook.com répondaient à un besoin similaire.

L’article original décrit le retrait de ces fonctions. Microsoft a supprimé les comptes connectés d’Outlook.com, et Google a annoncé le retrait de Gmail Mail Fetcher et Gmailify. Vérifiez les échéances et la disponibilité actuelles auprès de chaque fournisseur : cela concerne des fonctions précises, pas toutes les façons d’accéder à plusieurs comptes.

La collecte périodique a des limites techniques. Le message peut attendre la prochaine interrogation avant d’apparaître. Si l’original est conservé, le stockage est consommé dans les deux services. L’état des copies peut diverger : lu ici mais pas là, supprimé d’un côté mais conservé de l’autre. POP3 ne reproduit pas l’arborescence des dossiers.

Trois façons de réunir le courrier

Chaque approche a ses limites. Le transfert réexpédie et peut affecter l’authentification. La collecte dépend de l’intervalle d’interrogation et des conditions de stockage. Un proxy IMAP s’authentifie auprès de chaque compte et lit à la demande, sans créer une archive permanente de copies. Les identifiants invalides sont détectés à la connexion.

TrekMail utilise la troisième approche. Il ne crée pas de copies permanentes des messages. À l’ouverture de la vue unifiée, le serveur se connecte en IMAP aux comptes, récupère les en-têtes nécessaires, les regroupe par date interne et garde brièvement le résultat en cache. La lecture est marquée à la source si les droits et les réglages permettent de modifier cet indicateur.

Connecter un compte ne change pas son hébergement. Gmail reste chez Google, avec son stockage, ses filtres et son interface web. La connexion ne modifie ni les MX ni le routage entrant. Après déconnexion, aucune archive de copies n’est à nettoyer, mais les actions réalisées dans le client restent appliquées à la source.

Le fonctionnement en pratique

Deux vues sont disponibles. La première réunit les messages pour un tri global ; la seconde se concentre sur un compte. Vous pouvez passer de l’une à l’autre selon le contexte de travail.

Toutes les boîtes de réception regroupe les boîtes et les comptes connectés par date de réception. Chaque ligne indique l’origine par le logo du fournisseur ou une initiale colorée pour une boîte TrekMail. La réponse présélectionne l’identité correspondante ; son utilisation dépend des droits et des réglages d’envoi.

La vue par compte s’active dans la barre latérale. Sélectionnez un compte pour retrouver ses dossiers, ses brouillons et ses messages envoyés.

Les sources sont interrogées en parallèle : contacter huit serveurs IMAP successivement ralentirait sensiblement la page. Si une source est indisponible à cause d’un mot de passe révoqué ou d’un incident, elle est ignorée et le compte concerné est signalé. Les autres sources restent affichées.

Envoyer depuis la bonne adresse

Lorsque vous répondez à un message reçu sur le Gmail connecté, la réponse est soumise au serveur SMTP de Google, avec l’authentification de votre compte. Elle part par l’infrastructure Google si la connexion et les droits sont correctement configurés, pas par notre serveur sortant.

C’est important pour l’authentification. Le SPF de Gmail autorise les serveurs Google. Envoyer avec @gmail.com depuis une infrastructure tierce non autorisée ne permet pas de compter sur un SPF ou DKIM valide et aligné. Utiliser le serveur autorisé du compte maintient le bon schéma. DMARC exige un SPF ou DKIM valide et aligné avec From, pas nécessairement les deux, et ne garantit pas l’arrivée dans la boîte de réception.

La règle vaut pour les autres comptes : une adresse Fastmail envoie par Fastmail ; un serveur personnel par son propre SMTP. Le menu From se limite aux adresses disponibles : celle de la boîte, les alias autorisés à envoyer, les boîtes partagées avec droit de réponse et les comptes connectés. Une adresse absente peut indiquer des droits ou réglages insuffisants, pas un futur échec d’authentification démontré. Mieux vaut vérifier avant l’envoi qu’après un retour d’erreur deux minutes plus tard.

Mots de passe d’application et OAuth

Les grands fournisseurs restreignent de plus en plus les mots de passe ordinaires pour IMAP. La connexion utilise un mot de passe d’application, OAuth ou une autre méthode acceptée. Le parcours dépend du fournisseur ; vérifiez aussi les règles actuelles et les politiques de l’organisation.

Un mot de passe d’application est une chaîne aléatoire distincte, généralement révocable sans changer le mot de passe principal. Ses droits ne se limitent pas forcément à un protocole : cela dépend du fournisseur. Il évite de communiquer le mot de passe principal. L’assistant renvoie vers la page de génération du service reconnu.

La détection est automatique : le domaine est comparé aux fournisseurs connus et, pour un domaine personnalisé, les MX sont consultés. Cela permet de reconnaître Google Workspace et Microsoft 365 même sans terminaison @gmail.com. Si le service n’est pas reconnu, vous saisissez les paramètres à la main. Cette consultation ne change pas le DNS.

La connexion manuelle accepte IMAP sur 993 avec TLS implicite ou 143 avec STARTTLS, et SMTP sur 465, 587 ou 2525. La validation du certificat TLS est obligatoire : un certificat autosigné non reconnu ou portant un nom incorrect bloque la connexion. Vérifiez la chaîne de confiance, la validité et le nom du serveur, car la connexion donne accès au courrier.

Connecter un compte

1. Ouvrez le webmail puis Paramètres → Comptes connectés.
2. Cliquez sur Connecter un compte et saisissez l’adresse.
3. Si le fournisseur est reconnu, suivez l’instruction pour créer un mot de passe d’application ou vous connecter avec Microsoft pour Outlook.com. Sinon, saisissez les serveurs IMAP et SMTP, les ports et le chiffrement selon sa documentation.
4. Cliquez sur Tester la connexion. Lecture et envoi sont testés séparément pour identifier la partie qui échoue.
5. Enregistrez. Le compte apparaît dans la barre latérale et ses messages rejoignent Toutes les boîtes de réception.

Les dossiers sont associés à la première connexion. Les fournisseurs utilisent des noms différents : [Gmail]/Sent Mail, Sent Items, Sent. Les indicateurs d’usage spécial sont utilisés lorsqu’ils existent, sinon les noms. Les vues virtuelles Gmail comme Tous les messages sont masquées pour éviter d’afficher plusieurs fois le même courrier. Les libellés n’impliquent pas des copies physiques indépendantes de chaque message.

La documentation contient des guides pour Gmail, Outlook et Microsoft, iCloud, Yahoo et AOL et les autres serveurs IMAP.

Les pannes et leurs symptômes

Mot de passe d’application révoqué. Une cause courante. Changer le mot de passe principal Google peut révoquer ceux des applications. L’interface demande de reconnecter le compte au lieu de le masquer. Créez un nouveau mot de passe d’application et actualisez les réglages.

IMAP désactivé chez le fournisseur. Une politique Google Workspace ou Microsoft 365 peut limiter l’accès. Le client ne peut pas la contourner : un administrateur doit examiner l’autorisation.

Autorisation OAuth invalide. Les jetons Microsoft sont renouvelés tant que cela reste autorisé. Le retrait du consentement ou des changements de sécurité et de politique peuvent imposer une nouvelle autorisation. Reconnectez-vous lorsque l’interface le demande.

Serveur source lent. Chaque source a un délai maximal. Si elle répond trop tard, elle est ignorée pour ce chargement et signalée. Les tentatives ne se poursuivent pas indéfiniment au détriment des autres boîtes.

Consultez le dépannage des comptes connectés.

Les limites

La description originale prévoit les comptes connectés à partir de Starter :

La vue commune interroge jusqu’à 25 sources simultanément. Au-delà, les vues par compte sont plus pratiques. Aucune copie permanente du courrier connecté ne consomme le quota de l’offre : les messages restent à la source. Cela n’exclut pas un cache temporaire des données d’interface.

Questions fréquentes

La boîte unifiée déplace-t-elle mon courrier ?

Non. Elle ne copie ni ne déplace une archive permanente. Les messages sont lus en IMAP chez le fournisseur initial. Déconnecter le compte ne supprime pas la boîte source, mais n’annule pas les actions déjà effectuées, comme les marques de lecture.

Quelle différence avec une migration ?

Une migration copie les messages dans TrekMail pour quitter l’ancien fournisseur. La boîte unifiée conserve le stockage existant et offre un écran commun. Pour un transfert définitif, utilisez la migration en masse.

Les réponses partent-elles de la bonne adresse ?

Avec les bons droits et réglages, la réponse part de l’adresse connectée par son SMTP. Le destinataire retrouve l’adresse habituelle. La validation et l’alignement SPF ou DKIM dépendent des réglages du fournisseur ; connecter le compte ne garantit ni authentification ni livraison.

Pourquoi Gmail demande-t-il un mot de passe d’application plutôt qu’un bouton de connexion ?

Cette intégration utilise IMAP avec un mot de passe d’application. L’API Gmail peut nécessiter une vérification des autorisations restreintes et, selon le traitement des données, une évaluation de sécurité externe. Le mot de passe d’application offre une autre voie d’accès et peut être révoqué dans Google si la politique autorise sa création. IMAP et l’API ne donnent pas nécessairement les mêmes droits.

Puis-je ajouter une boîte sur mon propre serveur ?

Oui, saisissez manuellement les serveurs IMAP et SMTP, les ports et le chiffrement. Le certificat doit réussir les vérifications de confiance et de nom. Remplacez un certificat autosigné non reconnu ; celui d’une autorité publique convient si la chaîne, la validité et le nom sont corrects.

La boîte unifiée fonctionne-t-elle sur mobile ?

Oui. Les connexions sont configurées sur le serveur, pas dans un profil local. Après connexion depuis un appareil compatible, les mêmes comptes et la même liste sont disponibles sans refaire la configuration.

Que se passe-t-il si je passe à une offre sans comptes connectés ?

La lecture s’arrête et le compte apparaît comme indisponible. Le changement ne supprime pas les données à la source. Avec une offre compatible, l’accès reprend si les identifiants et les autorisations restent valides.