← RFC Reference

Anatomie des en-têtes de courrier électronique

Chaque champ d'en-tête important dans un message électronique expliqué — ce qu'il signifie, qui le définit et pourquoi il importe. Comprend un exemple réel complètement annoté.

Un exemple complet

Voici les en-têtes d'un vrai message électronique, de haut en bas, tels qu'ils apparaissent dans la boîte de réception d'un destinataire. Nous allons analyser chacun d'eux.

Maintenant, parcourons chaque en-tête.

En-têtes d'identité

From

L'auteur du message, défini par RFC 5322. C'est ce que le destinataire voit dans son client de messagerie. Il se compose d'un nom d'affichage optionnel (Alice) et d'une adresse de boîte aux lettres (alice@example.com). Les vérifications d'alignement DMARC sont effectuées par rapport au domaine dans cet en-tête.

From n'est pas identique à l'expéditeur d'enveloppe. L'expéditeur d'enveloppe (MAIL FROM en SMTP) peut être complètement différent. L'en-tête From: est défini par l'auteur du message ; l'expéditeur d'enveloppe est défini par le système d'envoi.

To, Cc, Bcc

To: et Cc: sont des en-têtes d'affichage — ils indiquent le public visé mais ne contrôlent pas la livraison. Les destinataires réels sont déterminés par les commandes SMTP RCPT TO, qui peuvent inclure des destinataires Bcc non répertoriés dans aucun en-tête. Un message peut avoir un en-tête To: répertoriant des adresses qui ne sont pas dans RCPT TO, et vice versa (c'est ainsi que fonctionne Bcc).

Reply-To

Non affiché dans notre exemple, mais courant. Spécifie où les réponses doivent être dirigées si différentes de From:. Souvent utilisé lorsqu'un message est envoyé à partir d'une adresse no-reply mais que les réponses doivent aller au support :

Sender

Utilisé lorsque l'entité responsable de l'envoi diffère de l'auteur. Si l'assistant d'Alice envoie un message en son nom, les en-têtes pourraient dire From: Alice et Sender: Assistant. La plupart des messages omettent cet en-tête.

Identification du message

Message-ID

Un identifiant unique au niveau mondial pour ce message, généré par l'expéditeur. Le format est <unique-part@domain>. C'est essentiel pour le regroupement, la déduplication et la corrélation des rebonds. Chaque message devrait en avoir un. Si votre système d'envoi ne le défini pas, le premier MTA en générera un — mais vous perdrez alors la capacité à corréler les rebonds avec les messages envoyés spécifiques.

In-Reply-To et References

Utilisés pour le regroupement. In-Reply-To contient le Message-ID du message auquel on répond. References contient la chaîne complète des valeurs Message-ID dans le thread. Les clients de messagerie les utilisent pour regrouper les conversations :

Date et sujet

Date

La date et l'heure de la composition du message, définies par l'expéditeur. Le format est spécifié dans RFC 5322. Ce n'est pas l'heure de livraison. Un message peut rester en attente pendant des heures ou des jours avant la livraison. Incluez toujours un décalage de fuseau horaire.

Subject

Texte libre résumant le message. Aucune limite de longueur dans la spécification, mais les clients de messagerie la tronquent à des longueurs variables. Conservez-la sous 60 caractères pour un affichage cohérent. Les caractères non-ASCII doivent être codés à l'aide du codage RFC 2047 (par exemple, =?UTF-8?Q?...?=), bien que la plupart des systèmes de messagerie modernes gèrent cela de manière transparente.

La chaîne reçue

Chaque serveur qui traite le message ajoute un en-tête Received:. Ils sont lus de bas en haut — le houblon le plus ancien est en bas, le plus récent en haut. Chaque en-tête enregistre :

• from — Le serveur qui a envoyé le message (nom d'hôte et IP)
• by — Le serveur qui l'a reçu
• with — Le protocole utilisé (ESMTP, ESMTPS pour TLS, LMTP pour la livraison locale)
• id — L'ID de file d'attente du serveur récepteur
• for — Le destinataire (peut être omis pour la confidentialité avec plusieurs destinataires)
• timestamp — Quand ce houblon a reçu le message

La chaîne Received est inestimable pour le débogage des retards de livraison. Comparez les horodatages entre les houblons pour trouver où le temps a été perdu. Remarque : les en-têtes Received: du côté de l'expéditeur peuvent être forgés. Ne faire confiance qu'aux en-têtes ajoutés par votre propre infrastructure.

Return-Path

Défini par le MTA final de livraison, cela enregistre l'expéditeur d'enveloppe SMTP (MAIL FROM). C'est où les rebonds sont envoyés. Dans cet exemple, le codage VERP est utilisé — le destinataire original (alice@example.com) est codé dans la partie locale de l'adresse de rebond.

Return-Path n'est pas défini par l'auteur du message ; il est extrait de la session SMTP et ajouté par le serveur de livraison. Il devrait y avoir exactement un en-tête Return-Path dans un message livré.

En-têtes d'authentification

DKIM-Signature

Ajouté par le serveur d'envoi. Le champ d= identifie le domaine signataire (utilisé pour l'alignement DMARC). Le champ s= est le sélecteur utilisé pour rechercher la clé publique dans le DNS. Le champ h= énumère les en-têtes qui sont signés. Voir Email Authentication Explained pour le processus de vérification complet.

Authentication-Results

Ajouté par le serveur récepteur (RFC 8601). Ceci est le verdict autorité des vérifications d'authentification pour ce message à ce houblon. L'authserv-id (mx1.example.net) identifie quel serveur a effectué la vérification. Il enregistre les résultats SPF, DKIM et DMARC, y compris les identifiants vérifiés.

Note de sécurité : Les en-têtes Authentication-Results forgés de sources externes doivent être supprimés par le MTA de bordure. Ne faire confiance à cet en-tête que lorsqu'il est ajouté par votre propre infrastructure.

En-têtes MIME

MIME-Version

Indique que le message utilise MIME (RFC 2045). C'est toujours 1.0 et devrait être présent sur chaque message. Sans cela, le message est interprété comme du texte US-ASCII simple.

Content-Type

Décrit le type de média du corps du message. Valeurs courantes :

• text/plain — Texte brut
• text/html — Contenu HTML
• multipart/alternative — Plusieurs versions du même contenu (généralement texte et HTML). Le client de messagerie choisit le meilleur.
• multipart/mixed — Message avec des pièces jointes
• multipart/related — HTML avec des images insérées

Le paramètre boundary définit le délimiteur entre les parties MIME. Voir RFC 2046 pour les détails.

Content-Transfer-Encoding

Comment le corps est codé pour un transit sûr. Valeurs courantes : 7bit, quoted-printable, base64. Les pièces jointes utilisent base64. Les corps de courrier HTML utilisent généralement quoted-printable pour gérer les caractères non-ASCII tout en restant largement lisibles.

En-têtes de gestion de liste

RFC 2369 définit List-Unsubscribe, qui fournit une URL et/ou une adresse de messagerie pour la désinscription. RFC 8058 ajoute List-Unsubscribe-Post, permettant la désinscription en un clic directement depuis l'interface utilisateur du client de messagerie sans ouvrir de navigateur. Gmail et d'autres fournisseurs majeurs exigent les deux en-têtes pour le courrier de masse et marketing.

En-têtes que vous ne devriez pas voir (mais parfois vous voyez)

X-Mailer / User-Agent

Identifie le client de messagerie ou le logiciel d'envoi. Parfois utilisé par les filtres de spam comme signal. Les systèmes d'envoi modernes omettent souvent ceci pour réduire la surface d'empreinte.

X-Priority / Importance

En-têtes non-standard qui tentent de définir la priorité du message. La plupart des clients de messagerie les ignorent. Certains filtres de spam traitent les marquages de haute priorité comme un signal négatif.

X-Spam-Status / X-Spam-Score

Ajouté par les systèmes de filtrage du spam (comme SpamAssassin). Non standardisé, mais largement utilisé en interne. Ces ne devraient pas être présents sur le courrier sortant — ils sont ajoutés par l'infrastructure réceptrice.

Ce qui peut mal tourner

Message-ID manquant

Si vous ne définissez pas un Message-ID, le premier MTA en ajoute un. Mais vous perdez la capacité à corréler les messages envoyés avec les rebonds et les notifications de livraison. Générez toujours votre propre Message-ID avant d'envoyer.

Confusion From et expéditeur d'enveloppe

Une source courante de problèmes de délivrabilité. L'en-tête From: affiche alice@example.com, mais l'expéditeur d'enveloppe est bounce@esp.com. SPF valide le domaine ESP, pas votre domaine. Si votre signature DKIM utilise aussi d=esp.com, l'alignement DMARC échoue pour les deux mécanismes. Le correctif : signez avec d=example.com pour que DKIM s'aligne.

En-têtes en double ou conflictuels

RFC 5322 spécifie que certains en-têtes (comme From:, Date:, Message-ID:) doivent apparaître exactement une fois. Les doublons peuvent causer un comportement imprévisible — différents clients de messagerie peuvent choisir des valeurs différentes. Certains filtres de spam traitent les en-têtes From: en double comme suspects.

En-tête Date manquant

Sans un en-tête Date:, le MTA récepteur ou le client de messagerie substituera son propre horodatage, qui peut différer considérablement. Certains filtres de spam pénalisent les messages sans en-tête Date.

Usurpation de la chaîne reçue

N'importe qui peut ajouter de faux en-têtes Received: à un message avant de l'envoyer. Le MTA récepteur ne peut faire confiance qu'aux en-têtes qu'il a lui-même ajoutés. Lors du débogage, commencez par le haut (le plus récent) et travaillez vers le bas, et arrêtez de faire confiance une fois que vous avez atteint la bordure entre votre infrastructure et le monde extérieur.

Points clés à retenir

• Les en-têtes sont des métadonnées sur le message. L'enveloppe (MAIL FROM / RCPT TO) contrôle la livraison ; les en-têtes sont pour l'affichage et le traitement.
• From: est ce que voit le destinataire. Return-Path: est où vont les rebonds. Ils sont souvent différents.
• Received: les en-têtes forment une chaîne de bas en haut montrant le chemin du message. Ne faire confiance qu'aux en-têtes de votre propre infrastructure.
• Authentication-Results: est le verdict du serveur récepteur sur SPF, DKIM et DMARC.
• Définissez toujours Message-ID, Date, From, MIME-Version et Content-Type.
• Pour le courrier de masse/marketing, incluez List-Unsubscribe et List-Unsubscribe-Post.

Lectures complémentaires

Related RFCs