Mais où vont mes mails ? Autopsie d’un e-mail

Chaque jour, des milliards d’e-mails traversent Internet. Certains contiennent des informations essentielles, d’autres une facture que personne ne voulait recevoir, quelques-uns promettent une fortune laissée par un prince remarquablement généreux, et une proportion non négligeable termine son existence dans le cimetière numérique appelé « Spam ».

Pour l’utilisateur, tout semble pourtant très simple : on rédige un message, on clique sur Envoyer, puis on considère que le problème appartient désormais à quelqu’un d’autre.

Techniquement, c’est presque vrai.

Car entre votre bouton « Envoyer » et la boîte de réception du destinataire se cache toute une chaîne de logiciels, de protocoles, de serveurs DNS, de files d’attente, de contrôles antispam et de signatures cryptographiques.

Un e-mail ne voyage pas directement de votre ordinateur vers celui du destinataire.
Il est soumis à un serveur, relayé éventuellement par plusieurs autres, contrôlé, stocké, puis consulté par le destinataire. Une petite administration postale mondiale, mais avec davantage de DNS et légèrement moins de syndicats.

Les acteurs : MUA, MSA, MTA, MDA et MRA

Commençons par distribuer les rôles. Les acronymes sont nombreux, parce qu’Internet a été largement conçu par des gens qui estimaient manifestement que trois lettres constituaient une phrase complète.

MUA : Mail User Agent

Le MUA est le logiciel avec lequel l’utilisateur compose, envoie, consulte et organise ses messages.

Il peut s’agir d’une application installée :

• Thunderbird ;
• Microsoft Outlook ;
• Apple Mail ;
• eM Client ;
• K-9 Mail / Thunderbird pour Android.

Un webmail comme Gmail, Outlook.com ou Roundcube joue également le rôle de MUA du point de vue de l’utilisateur.

Il existe cependant une différence technique : dans un client installé, le logiciel peut directement parler SMTP, IMAP ou POP avec les serveurs. Avec un webmail, le navigateur parle généralement en HTTPS au service web, et c’est l’infrastructure du fournisseur qui dialogue ensuite avec les systèmes de messagerie internes.

Votre navigateur n’est donc pas nécessairement en train de faire de l’IMAP en cachette sous votre bureau.

MSA : Mail Submission Agent

Le MSA est une étape souvent oubliée dans les explications simplifiées du courrier électronique.

Son rôle consiste à accepter les nouveaux messages soumis par les utilisateurs.

Lorsque Thunderbird ou Outlook envoie votre message au serveur SMTP de votre fournisseur sur le port 587 ou 465, il parle généralement à un service de soumission.

Le MSA peut notamment :

• authentifier l’utilisateur ;
• refuser un expéditeur non autorisé ;
• vérifier certaines règles de format ;
• appliquer des politiques de sécurité ;
• ajouter ou normaliser certains en-têtes ;
• puis confier le message à l’infrastructure de transport.

C’est le guichet de départ.

Il accepte votre colis, vérifie vaguement que vous avez le droit d’être là, puis le transmet aux employés qui ont réellement la charge de le perdre.

MTA : Mail Transfer Agent

Le MTA est chargé de transférer les messages entre systèmes de messagerie, principalement via SMTP.

C’est lui qui consulte le DNS afin de déterminer quels serveurs acceptent le courrier destiné à un domaine donné, puis tente de leur transmettre le message.

Exemples :

• Postfix ;
• Exim ;
• Sendmail ;
• qmail ;
• Microsoft Exchange Server.

Certains de ces logiciels remplissent évidemment plusieurs fonctions. Dans une vraie infrastructure de messagerie, les frontières entre MSA, MTA et MDA peuvent être beaucoup moins nettes que sur un joli schéma pédagogique.

La réalité informatique déteste les jolies boîtes.

MDA : Mail Delivery Agent

Une fois le message arrivé sur l’infrastructure du destinataire, le MDA — Mail Delivery Agent participe à sa livraison finale dans la boîte aux lettres appropriée.

Selon l’architecture, il peut aussi appliquer :

• des règles de classement ;
• des filtres ;
• des quotas ;
• des règles Sieve ;
• des traitements antispam ou antivirus ;
• ou une décision administrative concernant votre pièce jointe PowerPoint de 47 Mo.

On rencontre notamment :

• Dovecot, notamment avec ses mécanismes LDA ou LMTP ;
• Procmail ;
• Maildrop ;
• Courier et ses différents composants.

Dovecot est par ailleurs surtout connu comme serveur IMAP/POP. C’est un bon exemple du fait qu’un logiciel réel peut couvrir plusieurs rôles de notre petit organigramme.

MRA : Mail Retrieval Agent

Le terme MRA — Mail Retrieval Agent désigne un composant chargé de récupérer les messages auprès d’un serveur, typiquement avec POP3 ou IMAP.

On peut citer :

• fetchmail ;
• getmail ;
• OfflineIMAP ;
• isync.

Dans les usages modernes, ce rôle existe toujours fonctionnellement, mais il n’est pas forcément représenté par un programme indépendant.

Thunderbird, Outlook ou Apple Mail intègrent directement leur propre client IMAP ou POP. Il est donc souvent plus naturel de parler simplement du client de messagerie qui accède à la boîte.

Le MRA reste néanmoins utile pour comprendre les architectures historiques, les synchronisations automatisées et certains systèmes Unix où chaque fonction possède son programme, son fichier de configuration et, idéalement, une syntaxe différente.

Les protocoles et leurs ports

Trois grandes familles de protocoles apparaissent régulièrement dans une configuration de messagerie : SMTP, POP3 et IMAP.

Protocole	Port	Usage	Sécurité courante
SMTP	25	Transport entre serveurs de messagerie	TLS via STARTTLS lorsqu’il est disponible
Submission	587	Envoi du client vers son serveur	STARTTLS, généralement avec authentification
Submissions	465	Envoi du client vers son serveur	TLS implicite dès l’ouverture de la connexion
POP3	110	Récupération des messages	STARTTLS possible
POP3S	995	Récupération POP3 sécurisée	TLS implicite
IMAP	143	Accès et synchronisation des boîtes	STARTTLS possible
IMAPS	993	Accès IMAP sécurisé	TLS implicite

Le port 25 n’est normalement pas le port de votre Outlook

Une confusion fréquente consiste à considérer que « SMTP = port 25 ».

C’est historiquement compréhensible, mais aujourd’hui il faut distinguer deux usages.

• Port 25 : principalement le relais SMTP entre serveurs de messagerie.
• Port 587 : soumission d’un message par un utilisateur, généralement avec authentification et STARTTLS.
• Port 465 : soumission avec TLS implicite.

Autrement dit, lorsque votre serveur mail.example.com envoie directement un message au serveur de example.net, le port 25 reste central.

Lorsque votre ordinateur transmet un nouveau message à votre fournisseur de messagerie, il devrait normalement utiliser un service de soumission sur 587 ou 465.

Et non, « 465 = SSL » n’est plus vraiment une bonne façon de le présenter. SSL appartient désormais essentiellement au musée des protocoles que l’on cite encore parce que les interfaces continuent parfois d’utiliser le mot.

POP3 contre IMAP : deux philosophies

POP3 et IMAP permettent tous deux d’accéder au courrier reçu, mais leur philosophie est très différente.

Caractéristique	POP3	IMAP
Principe	Récupération des messages	Accès et synchronisation d’une boîte distante
Stockage principal	Souvent local dans l’usage historique	Principalement côté serveur
Suppression après téléchargement	Configurable par le client	Indépendante du téléchargement
Conservation sur le serveur	Possible	Oui, par conception
Plusieurs appareils	Possible, mais peu adapté à la synchronisation complète	Très bien adapté
Dossiers côté serveur	Non	Oui
État lu/non lu	Gestion essentiellement locale	Synchronisé
Usage moderne typique	Récupération locale, archivage, cas particuliers	Ordinateurs, téléphones, tablettes et autres clients multiples

POP3 ne signifie pas « télécharger puis supprimer »

POP3 a historiquement été beaucoup utilisé selon ce modèle : le client télécharge les nouveaux messages sur l’ordinateur, puis les supprime du serveur.

Mais ce comportement n’est pas imposé par POP3.

La plupart des clients de messagerie proposent une option du type :

« Laisser une copie des messages sur le serveur »

Selon le logiciel, il est également possible de demander au client de :

• conserver indéfiniment les messages sur le serveur ;
• les supprimer après un certain nombre de jours ;
• les supprimer du serveur lorsque leur copie locale est supprimée ;
• ou les supprimer immédiatement après leur récupération.

Techniquement, POP3 permet au client de récupérer les messages puis, s’il le souhaite, de demander leur suppression au serveur.

Le comportement dépend donc principalement de la configuration du client de messagerie.

On peut parfaitement configurer deux ordinateurs en POP3 pour laisser les messages sur le serveur et permettre à chacun de les récupérer.

Ce n’est simplement pas une véritable synchronisation.

Si vous lisez un message sur l’ordinateur A, l’ordinateur B ne saura pas nécessairement qu’il a été lu. Si vous classez localement un message dans le dossier « Factures », le serveur et les autres appareils ne participeront pas spontanément à cette merveilleuse décision administrative.

POP3 est donc très efficace pour récupérer du courrier. Il est beaucoup moins doué pour maintenir plusieurs appareils dans un état parfaitement synchronisé.

IMAP : la boîte reste au centre

Avec IMAP, la boîte aux lettres du serveur constitue la référence.

Votre ordinateur, votre téléphone et votre tablette voient essentiellement différentes représentations du même ensemble de messages.

IMAP sait notamment gérer :

• les dossiers ;
• les indicateurs lu/non lu ;
• les messages marqués ;
• les déplacements ;
• les suppressions ;
• les recherches ;
• les identifiants persistants des messages.

Vous pouvez ainsi lire un message sur votre téléphone et constater avec émerveillement qu’il apparaît également comme lu sur votre ordinateur.

Technologiquement, nous avons mis plusieurs décennies à obtenir ce miracle avant de l’utiliser principalement pour synchroniser des newsletters jamais ouvertes.

Ce qu’il y a réellement dans un e-mail

Un courrier électronique n’est pas simplement constitué de trois champs « De », « À » et « Objet » suivis d’un joli texte.

Il possède plusieurs niveaux d’information.

L’enveloppe SMTP

Pendant le transport SMTP, le serveur manipule notamment une enveloppe comprenant un expéditeur et un ou plusieurs destinataires.

Conceptuellement, une transaction peut ressembler à ceci :

MAIL FROM:<bounce@example.com>
RCPT TO:<alice@example.net>
DATA
...

Ces informations servent au transport du message.

Les en-têtes visibles du message

À l’intérieur du message lui-même, on trouve des en-têtes comme :

From: Jean <jean@example.com>
To: Alice <alice@example.net>
Subject: Réunion
Date: ...
Message-ID: ...

Et voici une nuance fondamentale :

L’adresse utilisée dans l’enveloppe SMTP et l’adresse affichée dans le champ From: peuvent être différentes.

Ce n’est pas nécessairement malveillant. Les listes de diffusion, services transactionnels, systèmes de gestion des retours et plateformes d’envoi ont de bonnes raisons d’utiliser plusieurs identités.

Mais cette distinction explique aussi pourquoi l’authentification des e-mails est plus compliquée qu’un simple « l’adresse de l’expéditeur a l’air correcte ».

Les en-têtes Received : le carnet de voyage

Chaque serveur SMTP traversé ajoute normalement un champ Received:.

Ces lignes permettent de reconstruire une partie du trajet suivi par un message :

• serveur précédent ;
• serveur suivant ;
• date et heure ;
• protocole utilisé ;
• parfois adresse IP et informations TLS.

Lorsqu’un administrateur vous demande « les en-têtes complets du message », ce n’est donc pas une manière particulièrement élaborée de gagner du temps.

Il cherche la scène de crime.

Le parcours complet d’un e-mail

Prenons un exemple :

alice@example.com veut envoyer un message à bob@example.net.

Étape 1 : rédaction dans le MUA

Alice écrit son message dans Thunderbird, Outlook, Apple Mail ou un webmail.

Le MUA construit le message avec ses en-têtes, son contenu et éventuellement ses pièces jointes.

Étape 2 : soumission au serveur

Le client transmet le message à son serveur de soumission, généralement sur le port 587 avec STARTTLS ou 465 avec TLS implicite.

Alice s’authentifie.

Le serveur vérifie qu’elle possède le droit d’envoyer du courrier et que son compte n’a pas décidé de transmettre 800 000 factures moldaves depuis quatre minutes.

Étape 3 : recherche DNS

Le MTA doit maintenant trouver où envoyer le courrier destiné à example.net.

Il interroge le DNS pour rechercher les enregistrements MX — Mail Exchanger du domaine.

Par exemple :

example.net.    MX 10 mail1.example.net.
example.net.    MX 20 mail2.example.net.

Les nombres indiquent les préférences : une valeur plus faible représente normalement un serveur prioritaire.

Si plusieurs serveurs existent, cela peut notamment offrir de la redondance.

Le DNS vient donc de répondre à la question :

« Très bien, vous voulez écrire à quelqu’un chez example.net. Voici les bâtiments qui acceptent leur courrier. Bonne chance. »

Étape 4 : connexion SMTP entre les serveurs

Le MTA expéditeur ouvre une connexion vers le serveur destinataire, normalement sur le port 25.

Une conversation SMTP simplifiée ressemble à ceci :

220 mail.example.net ESMTP
EHLO mail.example.com
250-mail.example.net
MAIL FROM:<alice@example.com>
250 OK
RCPT TO:<bob@example.net>
250 OK
DATA
354 End data with <CRLF>.<CRLF>
...
.
250 Message accepted

Dans la réalité, il peut également y avoir STARTTLS, diverses extensions ESMTP, des contrôles de réputation, SPF, DKIM, antispam et plusieurs autres façons polies de demander au message de justifier son existence.

Étape 5 : temporairement refusé ? On attend

SMTP fonctionne largement selon un modèle store and forward.

Si le serveur distant renvoie une erreur temporaire de classe 4xx, le MTA expéditeur conserve généralement le message dans sa file d’attente et réessaie plus tard.

Exemple :

451 Temporary local problem - please try later

Votre mail n’est donc pas nécessairement « parti » ou « perdu ». Il peut simplement être assis dans une file SMTP, à contempler le temps qui passe.

Étape 6 : refus définitif ? Retour à l’envoyeur

Une réponse de classe 5xx indique normalement un échec permanent :

550 5.1.1 User unknown

Le message peut alors générer un rapport de non-remise, souvent appelé bounce ou DSN — Delivery Status Notification.

C’est le courrier recommandé de l’échec :

« Votre message n’a pas été livré. Voici 46 lignes techniques destinées à vous permettre de comprendre pourquoi, à condition d’avoir déjà compris pourquoi. »

Étape 7 : livraison dans la boîte

Si le MTA destinataire accepte le message, celui-ci entre dans l’infrastructure locale.

Il peut encore être :

• analysé par un antivirus ;
• classé par un antispam ;
• soumis aux règles de l’entreprise ;
• placé en quarantaine ;
• redirigé ;
• classé dans un dossier ;
• ou livré dans la boîte de Bob.

Un serveur SMTP ayant répondu qu’il accepte le message ne garantit donc pas que Bob le verra majestueusement apparaître au sommet de sa boîte de réception.

Il signifie surtout que l’infrastructure destinataire a accepté de prendre le problème en charge.

Étape 8 : Bob consulte son courrier

Son client utilise généralement IMAP — ou éventuellement POP3 — pour accéder à la boîte.

Avec POP3, il peut télécharger les messages et, selon sa configuration, les laisser ou non sur le serveur.

Avec IMAP, il travaille essentiellement sur une vue synchronisée de la boîte distante.

Si Bob utilise un webmail, son navigateur communique avec l’application web en HTTPS, et l’infrastructure du fournisseur s’occupe des détails moins photogéniques.

Enfin, le message s’affiche.

Alice a passé trois secondes à l’écrire.

Une demi-douzaine de systèmes ont travaillé pour afficher « OK merci » à l’autre bout.

Les pièces jointes : MIME et l’art de grossir un fichier

SMTP a été conçu à une époque où envoyer quelques lignes de texte constituait déjà une activité respectable.

Pour transporter aujourd’hui des images, documents PDF, fichiers ZIP, calendriers, contenus HTML et autres horreurs bureautiques, le courrier utilise notamment MIME — Multipurpose Internet Mail Extensions.

MIME permet à un message de contenir plusieurs parties et d’indiquer leur type :

Content-Type: text/plain
Content-Type: text/html
Content-Type: image/jpeg
Content-Type: application/pdf

Les données binaires sont très souvent transformées en texte via Base64.

Conséquence : une pièce jointe encodée prend sensiblement plus de place que le fichier original.

Le Base64 augmente typiquement le volume brut des données d’environ un tiers, auquel viennent encore s’ajouter les en-têtes MIME et le reste du message.

Un document de 20 Mo ne produit donc pas nécessairement un e-mail de 20 Mo.

Voilà pourquoi envoyer une vidéo familiale de 48 Mo en pièce jointe peut déclencher une succession de refus indignés entre serveurs qui, pour une fois, sont probablement dans leur droit.

Pourquoi certains mails finissent en spam

Le filtre antispam moderne ne se contente pas de rechercher le mot « VIAGRA » écrit quatorze fois en rouge dans le sujet.

Les systèmes de réception peuvent prendre en compte de nombreux signaux :

• réputation de l’adresse IP d’envoi ;
• réputation du domaine ;
• cohérence du DNS ;
• reverse DNS ;
• résultats SPF ;
• signature DKIM ;
• politique DMARC ;
• volume et rythme d’envoi ;
• contenu du message ;
• présence de liens suspects ;
• historique des plaintes ;
• comportement observé sur les messages similaires ;
• et divers critères que les grands fournisseurs ne publient évidemment pas sous forme d’une recette pratique intitulée « Comment contourner notre antispam ».

La délivrabilité est donc une combinaison de conformité technique, de réputation et de comportement.

Avoir un SPF parfait ne donne pas automatiquement un passeport diplomatique pour la boîte de réception.

SPF : qui a le droit d’envoyer pour ce domaine ?

SPF — Sender Policy Framework permet à un domaine de publier dans le DNS une politique indiquant quels systèmes sont autorisés à utiliser ce domaine pour certaines identités SMTP, principalement MAIL FROM et HELO/EHLO.

Exemple simplifié :

example.com. TXT "v=spf1 ip4:192.0.2.10 -all"

Cela signifie essentiellement :

« Pour cette identité SPF, l’adresse 192.0.2.10 est autorisée. Les autres ne le sont pas. »

SPF ne valide pas directement le From visible

C’est un point essentiel.

Le domaine visible par l’utilisateur dans :

From: Banque Très Sérieuse <contact@example.com>

n’est pas forcément le domaine directement vérifié par SPF.

SPF travaille sur des identités utilisées pendant la transaction SMTP.

C’est précisément l’une des raisons pour lesquelles DMARC ajoute une notion d’alignement avec le domaine visible dans From:.

SPF seul ne constitue donc pas un détecteur universel de mensonge.

Ce serait beaucoup demander à une ligne TXT dans le DNS.

DKIM : signer le message

DKIM — DomainKeys Identified Mail ajoute au message une signature cryptographique.

Le système expéditeur possède une clé privée avec laquelle il signe certaines parties du message.

La clé publique correspondante est publiée dans le DNS sous un nom contenant notamment un sélecteur.

Le destinataire peut alors vérifier :

• que la signature correspond bien au domaine indiqué ;
• et que les parties signées du message n’ont pas été modifiées d’une façon incompatible avec cette signature pendant le transport.

Une signature ressemble conceptuellement à ceci :

DKIM-Signature:
    v=1;
    d=example.com;
    s=mail2026;
    ...

d= indique le domaine signataire et s= le sélecteur permettant de retrouver la clé publique dans le DNS.

DKIM signe. DKIM ne chiffre pas.

Un message correctement signé peut toujours être parfaitement lisible par les serveurs qui le transportent ou le stockent.

La signature garantit certains éléments d’intégrité et associe un domaine au message. Elle ne transforme pas votre invitation à déjeuner en document classifié.

DMARC : vérifier que tout le monde raconte à peu près la même histoire

DMARC — Domain-based Message Authentication, Reporting and Conformance s’appuie sur SPF et DKIM, mais ajoute un élément essentiel : l’alignement avec le domaine visible dans l’en-tête From:.

Pour qu’un message réussisse DMARC, il faut en substance qu’au moins une des deux méthodes fournisse un résultat valide et aligné :

• SPF avec un domaine authentifié aligné sur le domaine du From: ;
• ou DKIM avec un domaine de signature aligné sur le domaine du From:.

Le propriétaire du domaine peut ensuite annoncer une politique.

Politique	Signification générale
p=none	Observer et recevoir des rapports, sans demander de traitement particulier.
p=quarantine	Demander que les messages en échec soient traités avec suspicion, par exemple placés en spam.
p=reject	Demander le rejet des messages qui échouent à DMARC.

Exemple simplifié :

_dmarc.example.com. TXT
"v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

DMARC peut aussi fournir des rapports permettant au propriétaire d’un domaine d’observer qui envoie des messages en son nom.

Une sorte de vidéosurveillance administrative du courrier électronique, mais constituée essentiellement de XML.

L’humanité aurait pu choisir des images. Elle a choisi XML.

SPF, DKIM et DMARC en une minute

Mécanisme	Question principale
SPF	« Cette machine est-elle autorisée à utiliser cette identité de domaine pour envoyer ? »
DKIM	« Cette signature est-elle valide et quelles parties du message protège-t-elle ? »
DMARC	« SPF ou DKIM réussissent-ils en étant alignés avec le domaine visible par l’utilisateur, et que demande le propriétaire en cas d’échec ? »

Les trois mécanismes sont complémentaires.

Ils réduisent notamment certaines formes d’usurpation de domaine, mais ne prouvent pas que le contenu est honnête.

Un escroc peut parfaitement posséder son propre domaine, configurer SPF, DKIM et DMARC à la perfection et vous envoyer une fraude techniquement irréprochable.

La cryptographie peut authentifier un domaine. Elle n’a toujours pas appris à détecter un commercial mal intentionné.

TLS : le tunnel entre deux étapes

Les connexions SMTP, IMAP et POP peuvent être protégées par TLS.

Entre un utilisateur et son fournisseur, il est aujourd’hui normal d’utiliser une connexion protégée.

Entre serveurs SMTP sur Internet, TLS est également extrêmement répandu.

Mais il faut comprendre une nuance :

TLS protège une connexion entre deux systèmes. Ce n’est pas nécessairement du chiffrement de bout en bout du message.

Un message peut être chiffré pendant son trajet entre deux serveurs, puis exister en clair sur le serveur qui vient de le recevoir.

Les administrateurs du service, les logiciels de filtrage ou les systèmes ayant accès au stockage peuvent donc potentiellement traiter son contenu selon l’architecture mise en place.

Pour du véritable chiffrement du contenu de bout en bout, il faut utiliser des mécanismes spécifiques comme S/MIME ou OpenPGP.

Et découvrir alors que rendre un échange réellement secret est assez simple jusqu’au moment où l’on implique un utilisateur.

Pourquoi le transfert d’e-mails complique tout

Les mécanismes d’authentification rencontrent un problème intéressant : les messages peuvent être transférés.

Imaginez :

1. example.com envoie légitimement un message à alice@example.net ;
2. Alice a configuré une redirection automatique vers alice@example.org ;
3. le serveur d’example.net retransmet le message.

Le serveur final voit alors une adresse IP qui n’était probablement pas prévue dans le SPF d’example.com.

SPF peut donc échouer lors de certains transferts parfaitement légitimes.

DKIM résiste mieux à la redirection tant que le message n’est pas modifié d’une manière qui invalide sa signature.

Mais les listes de diffusion aiment parfois ajouter un sujet, un pied de page, modifier le contenu ou effectuer d’autres opérations parfaitement raisonnables qui transforment ensuite les signatures cryptographiques en souvenirs.

C’est l’une des raisons pour lesquelles la messagerie moderne dispose encore d’autres mécanismes et conventions pour essayer de préserver les résultats d’authentification à travers certains intermédiaires.

À chaque fois qu’on résout un problème du courrier électronique, le courrier électronique produit généralement deux RFC supplémentaires.

Où un mail peut-il disparaître ?

Lorsque quelqu’un affirme :

« J’ai envoyé le mail, mais il n’est jamais arrivé. »

il existe de nombreux endroits où enquêter.

1. Il n’est jamais réellement parti du client

Problème d’authentification SMTP, connexion impossible, mauvais serveur, mauvais port ou message encore coincé dans la boîte d’envoi.

2. Le serveur de soumission l’a refusé

Adresse expéditeur interdite, quota, message trop volumineux, compte bloqué ou politique locale.

3. Le MTA le conserve dans sa file d’attente

Le domaine distant est temporairement inaccessible ou répond avec un code 4xx.

Le message attend alors une nouvelle tentative.

4. Le domaine du destinataire est mal configuré

MX incorrect, DNS défaillant, serveur inaccessible ou configuration SMTP douteuse : les occasions de transformer une simple correspondance en chantier sont nombreuses.

5. Le serveur distant l’a rejeté

Réputation, politique antispam, destinataire inexistant, authentification du domaine insuffisante ou autre restriction.

6. Il a été accepté, mais classé ailleurs

Spam, quarantaine, dossier automatique, règle utilisateur ou système de sécurité.

7. Il est bien arrivé

Le destinataire ne l’a simplement pas vu.

Cette hypothèse doit toujours être conservée avec soin, même si elle est rarement celle que l’on peut mentionner en premier pendant une réunion.

Comment enquêter proprement

Quelques éléments permettent généralement de comprendre ce qui s’est passé :

• les journaux du MTA expéditeur ;
• l’identifiant de file d’attente du message ;
• les codes de réponse SMTP ;
• les enregistrements DNS et MX ;
• les résultats SPF, DKIM et DMARC ;
• les en-têtes complets du message reçu ;
• les lignes Received: ;
• les journaux du serveur destinataire lorsque vous y avez accès ;
• et l’éventuel rapport de non-remise.

Un bon diagnostic de messagerie repose donc beaucoup moins sur :

« Pourtant, chez moi ça marche. »

et beaucoup plus sur :

« Quel serveur a répondu quoi, à quelle étape et avec quel code ? »

C’est moins intuitif, mais remarquablement plus efficace.

Les logiciels célèbres selon leur rôle

Les catégories se chevauchent dans les produits modernes, mais voici quelques noms classiques :

Rôle	Exemples
MUA	Thunderbird, Outlook, Apple Mail, eM Client, K-9 Mail
MTA / MSA	Postfix, Sendmail, Exim, qmail, Microsoft Exchange Server
MDA / livraison	Dovecot LDA/LMTP, Procmail, Maildrop, Courier
Accès IMAP / POP	Dovecot, Courier
MRA / synchronisation	fetchmail, getmail, OfflineIMAP, isync
Webmail	Gmail, Outlook.com, Roundcube, RainLoop, Horde

Certains de ces logiciels sont aujourd’hui moins actifs, moins courants ou remplacés par des alternatives plus modernes. Ils restent néanmoins intéressants pour comprendre l’écosystème et se rencontrent encore dans des installations existantes.

Webmail ou client installé ?

Les deux approches donnent accès au même concept fondamental — votre courrier — mais proposent des modèles différents.

Critère	Webmail	Client installé
Accès	Depuis un navigateur	Depuis une application installée
Installation	Aucune côté utilisateur	Nécessaire
Hors ligne	Variable selon le service	Souvent très bon
Plusieurs comptes	Variable	Souvent excellent
Personnalisation	Contrôlée par le fournisseur	Généralement plus importante
Maintenance	Principalement côté fournisseur	Une partie reste à la charge de l’utilisateur

Le webmail

Il est pratique, accessible depuis presque n’importe quelle machine et ne nécessite pas de configurer un logiciel complet.

Pour la majorité des utilisateurs, c’est extrêmement confortable.

En contrepartie, son comportement, son interface et ses possibilités dépendent fortement du fournisseur.

Le client installé

Thunderbird, Outlook, Apple Mail ou eM Client permettent souvent de centraliser plusieurs comptes, de conserver des données localement, de travailler hors ligne et d’ajouter des fonctions avancées.

Ils offrent davantage de contrôle.

Ce qui signifie également davantage d’occasions de configurer manuellement un port incorrect à 17 h 57 un vendredi.

Le parcours en une seule vue

Si l’on résume toute cette mécanique :

1. Le MUA construit le message.
2. Le MUA le soumet au MSA, généralement via SMTP Submission sur 587 ou 465.
3. Le MSA/MTA expéditeur accepte le message et détermine sa destination.
4. Le DNS indique les serveurs MX du domaine destinataire.
5. Le MTA expéditeur contacte le MTA destinataire via SMTP, normalement sur le port 25.
6. L’infrastructure destinataire vérifie éventuellement réputation, SPF, DKIM, DMARC, antispam et autres politiques.
7. Le MDA ou système de livraison place le courrier dans la boîte adéquate.
8. Le serveur d’accès expose cette boîte via IMAP ou POP lorsque ces protocoles sont utilisés.
9. Le MUA du destinataire synchronise ou récupère le message.
10. L’utilisateur lit le mail, puis répond « Vu ».

Des dizaines de standards et plusieurs machines viennent de travailler ensemble pour produire trois caractères.

Conclusion : le mail, ce dinosaure remarquablement vivant

Le courrier électronique est l’un des plus anciens grands services d’Internet encore utilisés quotidiennement.

Son apparente simplicité masque une architecture distribuée remarquable : MUA, MSA, MTA, MDA, mécanismes d’accès, DNS, SMTP, IMAP, POP3, MIME, TLS, SPF, DKIM, DMARC, files d’attente, filtres et politiques diverses travaillent ensemble pour accomplir quelque chose qui ressemble, depuis l’écran, à l’envoi d’une lettre.

Et malgré son âge, tout cela fonctionne étonnamment bien.

La plupart du temps.

La prochaine fois qu’un message disparaît, rappelez-vous donc qu’il n’est probablement pas tombé dans un mystérieux trou noir numérique.

Il peut être :

• encore dans votre client ;
• refusé par votre serveur ;
• en attente dans une file SMTP ;
• bloqué par le serveur distant ;
• en quarantaine ;
• dans le dossier spam ;
• rangé par une règle oubliée depuis 2017 ;
• ou parfaitement livré sous les yeux d’un destinataire qui jure ne rien avoir reçu.

Ce n’est pas magique.

C’est une mécanique distribuée, ancienne, remarquablement robuste et suffisamment complexe pour que les administrateurs mail développent parfois ce regard très particulier des gens qui ont passé trois heures à découvrir qu’un enregistrement SPF contenait onze recherches DNS.

Alors, lorsque vous cliquez sur Envoyer, ayez une petite pensée pour tous les serveurs qui vont maintenant devoir décider quoi faire de votre message.

Ils ne vous jugent pas.

Les filtres antispam, en revanche, ont déjà commencé.