← RFC Reference

RFC 8601 — Champ d'en-tête Authentication-Results

Pourquoi cet RFC existe

L'authentification des emails implique plusieurs mécanismes indépendants : SPF, DKIM, DMARC, ARC, et d'autres. Chacun produit son propre résultat. Sans un moyen standard d'enregistrer ces résultats, chaque composant du pipeline de livraison des emails — filtres de contenu, classificateurs de spam, clients destinataires — devrait indépendamment réévaluer chaque mécanisme d'authentification.

Le RFC 8601 définit le champ d'en-tête Authentication-Results, un moyen structuré pour l'MTA frontalier (le premier serveur de votre infrastructure qui reçoit le message d'Internet) d'enregistrer le résultat de toutes les vérifications d'authentification dans un seul en-tête. Ce résultat peut ensuite être consommé par tous les composants en aval.

Le RFC 8601 a obsolété le RFC 7601, qui lui-même avait obsolété le RFC 5451. Les mises à jour ont affiné la syntaxe, enregistré des mots-clés de méthode supplémentaires, et clarifié la gestion des limites de confiance.

Comment cela fonctionne

Structure de l'en-tête

L'en-tête Authentication-Results a une grammaire définie :

Exemple du monde réel

Comment il est généré

1. L'MTA frontalier reçoit un message d'Internet via SMTP.
2. Il exécute les vérifications SPF par rapport à l'expéditeur de l'enveloppe et à l'IP de connexion.
3. Il valide les signatures DKIM en interrogeant le DNS pour les clés publiques.
4. Il évalue la politique DMARC et l'alignement.
5. Il valide toute chaîne ARC présente sur le message.
6. Il prépend un en-tête Authentication-Results résumant tous les résultats, identifié par son propre nom d'hôte (l'authserv-id).
7. Les filtres de contenu en aval, les moteurs de spam, et la logique de livraison lisent cet en-tête au lieu de réexécuter les vérifications.

Détails techniques clés

L'authserv-id

Le premier jeton après Authentication-Results: est l'authserv-id, généralement le nom d'hôte du serveur qui a effectué les vérifications. C'est crucial pour la confiance : un système récepteur ne doit faire confiance qu'aux en-têtes Authentication-Results dont l'authserv-id correspond à un serveur au sein de son propre domaine administratif. Les en-têtes de serveurs externes doivent être supprimés ou ignorés.

Mots-clés de méthode

L'IANA gère un registre des mots-clés de méthode d'authentification. Les plus couramment utilisés sont :

Valeurs de résultat

Chaque méthode produit l'une de ces valeurs de résultat :

Types de propriétés

Chaque résultat peut inclure des paires propriété/valeur fournissant des détails :

Résultats multiples

Un seul en-tête Authentication-Results peut contenir les résultats de plusieurs méthodes, séparés par des points-virgules. Alternativement, plusieurs en-têtes Authentication-Results peuvent être présents (par ex., un par méthode). Les deux approches sont valides.

Limites de confiance

La considération de sécurité la plus critique : ne jamais faire confiance aux en-têtes Authentication-Results de sources externes. Un attaquant peut inclure un en-tête Authentication-Results falsifié prétendant dkim=pass et dmarc=pass. L'MTA frontalier doit soit supprimer tous les en-têtes Authentication-Results existants qui correspondent à son propre authserv-id, soit ne faire confiance qu'aux en-têtes qu'il peut vérifier avoir été ajoutés au sein de son propre domaine administratif.

Erreurs courantes

• Faire confiance aux en-têtes A-R externes : L'erreur la plus dangereuse. Si votre système de messagerie ne supprime ou n'ignore pas les en-têtes Authentication-Results de l'extérieur de votre limite de confiance, un attaquant peut injecter de faux résultats. Supprimez toujours les en-têtes A-R entrants qui utilisent votre authserv-id.
• Ne pas enregistrer les résultats à la frontière : Si les vérifications d'authentification se produisent à l'MTA frontalier mais que les résultats ne sont pas enregistrés dans un en-tête, les systèmes de filtrage internes n'ont aucune donnée d'authentification pour travailler et doivent réexécuter toutes les vérifications (ce qui peut produire des résultats différents en raison de la position réseau modifiée).
• Authserv-id ambigu : L'utilisation d'un nom d'hôte générique (comme « localhost ») comme authserv-id rend impossible la distinction entre les en-têtes A-R de votre système et ceux d'autres systèmes. Utilisez le nom d'hôte complet de votre MX.
• Mauvaise lecture des résultats DKIM : Un résultat dkim=pass seul ne signifie pas que le message est sûr. Vérifiez la valeur header.d pour voir quel domaine l'a signé. Un pass pour d=attacker.com est sans valeur pour les messages prétendant être de example.com. C'est pourquoi l'alignement DMARC est important.
• Ignorer les résultats none : Un résultat none signifie qu'aucun enregistrement n'a été trouvé. Pour SPF ou DMARC, cela signifie que le domaine n'a pas publié de politique d'authentification. Cette absence doit être traitée différemment d'un fail explicite.

Impact sur la délivrabilité

• Mine d'or diagnostique : Lors du dépannage des problèmes de délivrabilité, l'en-tête Authentication-Results est le premier endroit à regarder. Il vous dit exactement ce que le serveur récepteur a vu : quelles vérifications ont réussi, lesquelles ont échoué, et pourquoi.
• Conduit les décisions de filtrage : Les principaux fournisseurs de messagerie (Gmail, Microsoft, Yahoo) utilisent les résultats d'authentification comme entrées principales de leur filtrage de spam. Un message avec spf=pass, dkim=pass, et dmarc=pass a une chance considérablement meilleure d'atteindre la boîte de réception.
• Intégration ARC : L'en-tête ARC-Authentication-Results dans ARC suit le même format que l'en-tête standard Authentication-Results, assurant un rapport cohérent sur les sauts de transfert.
• Transparence : En exposant les résultats d'authentification dans les en-têtes de message, le RFC 8601 rend l'authentification des emails observable et débogable. Les expéditeurs peuvent demander aux destinataires de transférer les en-têtes bruts pour diagnostiquer les échecs d'authentification.
• Lisible par machine : Le format structuré rend simple pour les systèmes automatisés d'analyser et d'agir sur les résultats d'authentification, permettant une surveillance de délivrabilité programmée.

Related RFCs