← RFC Reference

RFC 5617 : ADSP — Pratiques de signature du domaine de l'auteur

Pourquoi cela existe

DKIM (RFC 6376) permet à un domaine de signer ses messages sortants, mais il ne dit pas aux destinataires quoi faire quand un message manque d'une signature valide. Sans couche de politique, un destinataire n'a aucun moyen de savoir si un message non signé de bank.example.com est légitime (peut-être que leur chemin sortant ne signe pas toujours) ou frauduleux (un phisher usurpant l'identité de la banque).

ADSP était la première tentative pour combler cette lacune. Elle permettait aux propriétaires de domaines de publier un enregistrement DNS déclarant leur pratique de signature :

• « unknown » — le domaine peut signer ou non tous les messages (par défaut s'il n'existe pas d'enregistrement ADSP).
• « all » — le domaine signe tous les messages avec une signature d'auteur (le d= DKIM correspond au domaine From:).
• « discardable » — le domaine signe tous les messages, et les messages non signés doivent être supprimés.

Publié en août 2009, ADSP a connu une adoption limitée et a été déclassé au statut « Historique » en novembre 2013 par RFC 5863. Son successeur, DMARC, a résolu les lacunes d'ADSP et est devenu le mécanisme de politique d'authentification de courrier électronique standard.

Comment cela fonctionne

La recherche DNS

Les enregistrements ADSP sont publiés en tant qu'enregistrements TXT DNS à _adsp._domainkey.<domain>. Quand un destinataire reçoit un message avec un en-tête From: de alice@example.com, il cherche :

Valeurs de politique

Signature d'auteur versus signature tierce

Un concept clé dans ADSP est la signature d'auteur — une signature DKIM où la balise d= dans l'en-tête DKIM-Signature correspond exactement au domaine dans l'en-tête From:. Ceci est plus strict que DKIM général, qui permet à n'importe quel domaine de signer :

Cela signifiait que si vous utilisiez un fournisseur de services de messagerie (ESP) qui signait le courrier en tant que d=esp.com plutôt que d=votredomaine.com, ADSP traiterait ces messages comme non signés — même s'ils avaient une signature DKIM parfaitement valide.

Le flux de vérification

1. Recevez le message et extrayez le domaine de l'en-tête From:.
2. Recherchez les en-têtes DKIM-Signature où d= correspond au domaine From (signatures d'auteur).
3. Si une signature d'auteur est présente et valide, acceptez le message normalement.
4. Si aucune signature d'auteur valide n'existe, interrogez DNS pour _adsp._domainkey.<domain>.
5. Appliquez la politique : unknown signifie n'entreprendre aucune action, all signifie traiter avec suspicion, discardable signifie rejeter ou supprimer silencieusement.

Détails techniques clés

Pourquoi ADSP a échoué

La conception d'ADSP avait des limitations fondamentales qui ont empêché une adoption significative :

• Les listes de diffusion cassent les signatures d'auteur. Quand une liste de diffusion modifie le message (ajoute un pied de page, change l'objet), la signature DKIM casse. Sous dkim=discardable, le destinataire aurait supprimé le message. Les domaines qui utilisent des listes de diffusion ne pouvaient jamais déployer en toute sécurité une politique stricte.
• Pas de couverture de sous-domaine. ADSP ne s'appliquait qu'au domaine exact interrogé. Il n'y avait aucun moyen de définir une politique pour *.example.com sans publier d'enregistrements pour chaque sous-domaine individuellement.
• Pas de mécanisme de rapport. ADSP n'avait aucun moyen pour les destinataires d'envoyer des retours aux propriétaires de domaines sur les résultats d'authentification. Sans données, les propriétaires de domaines ne pouvaient pas évaluer l'impact d'une politique plus stricte avant de la déployer.
• Pas de déploiement progressif. Les seules options étaient « unknown » (pas de protection), « all » (ambigu), ou « discardable » (nucléaire). Il n'y avait pas d'équivalent à la balise pourcentage (pct=) de DMARC pour l'application progressive.
• SPF n'a pas été considéré. ADSP évaluait uniquement DKIM. Un message qui passait SPF mais manquait DKIM était traité de la même manière qu'une contrefaçon complètement non authentifiée.

ADSP versus DMARC : différences clés

L'enregistrement DNS en détail

Erreurs courantes

• Déployer ADSP en 2024+. ADSP est historique. Aucun destinataire majeur ne vérifie les enregistrements ADSP. Si vous en avez toujours un publié, cela ne fait rien. Déployez DMARC à la place.
• Confondre ADSP et DMARC. Les deux sont des mécanismes de politique pour DKIM, mais DMARC est la norme actuelle. Si vous rencontrez une documentation faisant référence à des enregistrements _adsp._domainkey, elle est obsolète.
• Laisser des enregistrements ADSP périmés dans DNS. Les anciens enregistrements ADSP consomment du temps de requête DNS et ajoutent de la confusion lors du dépannage. Si vous trouvez des enregistrements TXT _adsp._domainkey dans votre zone, nettoyez-les.
• Penser que « discardable » était la politique la plus stricte possible. Même à son apogée, le « discardable » d'ADSP était respecté par très peu de destinataires. L'adoption était trop faible pour fournir une protection significative contre l'usurpation d'identité.
• Ne pas tirer la leçon. ADSP a échoué parce qu'il était tout ou rien sans visibilité. DMARC a réussi parce qu'il a ajouté des rapports (rua=) et le déploiement progressif (pct=). Commencez toujours par la surveillance avant l'application.

Impact sur la livrabilité

• Aucun impact actuel. Les enregistrements ADSP ne sont pas vérifiés par les destinataires modernes. En publier un n'a aucun effet sur la livraison, les résultats d'authentification ou le filtrage du spam.
• Leçon historique pour le déploiement de DMARC. L'échec d'ADSP a directement inspiré la conception de DMARC. Les rapports et les fonctionnalités de déploiement progressif qui rendent DMARC déployable existent parce qu'ADSP a prouvé qu'une politique binaire sans retour d'information est impraticable.
• Les anciens enregistrements comme signal. Un ancien enregistrement ADSP dans DNS est un léger signal qu'une infrastructure de courrier électronique de domaine n'est pas activement maintenue. Bien qu'aucun destinataire ne pénalise cela, cela peut causer de la confusion lors du dépannage d'authentification.
• Migrer vers DMARC. Si votre domaine a un enregistrement ADSP mais pas d'enregistrement DMARC, déployez DMARC immédiatement. Commencez par p=none et une adresse de rapport rua= pour gagner en visibilité, puis resserrez la politique en fonction des données.

Related RFCs