Groupe de travail Réseau	E. Allman, Sendmail, Inc.	
Request for Comments: 5617	J. Fenton, Cisco Systems, Inc.	
Catégorie : Sur la voie de la normalisation	M. Delany, Yahoo! Inc.	
	J. Levine, Taughannock Networks	
Traduction Claude Brière de L'Isle	août 2009	

Pratiques de signature de domaine d'auteur (ADSP) pour la messagerie identifiée par DomainKeys (DKIM)

Résumé
La messagerie identifiée par des clés de domaine (DKIM, DomainKeys Identified Mail) définit un cadre d'authentification au niveau du domaine pour la messagerie pour permettre la vérification de la source et du contenu des messages. Le présent document spécifie l'ajout d'un mécanisme pour aider à certifier des messages qui ne contiennent pas de signature DKIM pour le domaine utilisé dans l'adresse de l'auteur. Il définit un enregistrement qui peut annoncer si un domaine signe ses messages sortants ainsi que comment les autres hôtes peuvent accéder à cet enregistrement.

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet sur la voie de la normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de droits de reproduction
Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document. 
Table des matières
1. Introduction	2
2. Langage et terminologie	2
2.1 Termes importés de la spécification des signatures DKIM	2
2.2 Signature valide	3
2.3 Adresse d'auteur 	3
2.4 Domaine d'auteur 	3
2.5 Auteur prétendu	3
2.6 Pratiques de signature de domaine d'auteur	3
2.7 Signature de domaine d'auteur	3
3. Vue d'ensemble du fonctionnement	3
3.1 Applicabilité d'ADSP	3
3.2 Usage d'ADSP	4
3.3 Résultats d'ADSP	4
4. Description détaillée 	4
4.1 Représentation du DNS	4
4.2 Publication des enregistrements ADSP	4
4.3 Procédure de recherche d'ADSP	5
5. Considérations relatives à l'IANA	6
5.1 Registre des étiquettes de spécification d'ADSP	6
5.2 Registre des pratiques de signature sortante d'ADSP	6
5.3 Mise à jour du registre des méthodes de résultat d'authentification	7
5.4 Mise à jour du registre des résultats d'authentification	7
6. Considérations sur la sécurité	8
6.1 Modèle des menaces sur ADSP	8
6.2 Considérations sur le DNS	8
6.3 Caractères génériques dans le DNS	9
6.4 Application inappropriée de signatures de domaine d'auteur	9
7. Références	9
7.1 Références normatives	9
7.2 Références pour information	9
Appendice A. Exemples de recherches	10
A.1 Il existe un domaine et un ADSP	10
A mail message contains this From: header line:	10
A.2 Le domaine existe, l'ADSP n'existe pas	10
A.3 Le domaine n'existe pas	10
Appendice B. Exemples d'usage	10
B.1 Domaines d'une seule localisation	11
B.2 Domaines de messagerie en gros	11
B.3 Domaines de messagerie en gros avec messages éliminables	11
B.4 Envoyeurs tiers	11
B.5 Domaines avec des utilisateurs indépendants et des politiques d'utilisation libérales	11
B.6 Domaines non de messagerie	12
Appendice C. Remerciements	12
Adresse des auteurs	12

 	1.	Introduction

La messagerie identifiée par clés de domaine (DKIM, DomainKeys Identified Mail) définit un mécanisme par lequel les messages électroniques peuvent être signés cryptographiquement, permettant à un domaine signataire de revendiquer la responsabilité de l'introduction d'un message dans le flux de messages. Les receveurs de messages peuvent vérifier la signature en interrogeant directement le domaine du signataire pour restituer la clé publique appropriée, et par là confirmer que le message est attesté par une partie qui dispose de la clé privée pour le domaine signataire.

Cependant, la tradition de l'Internet est telle que tous les messages ne sont pas signés, et l'absence d'une signature sur un message n'est pas une indication a priori de falsification. En fait, durant les premières phases de déploiement, il est très probable que la plupart des messages vont rester non signés. Cependant, certains domaines pourraient décider de signer tous leurs messages sortants, par exemple, pour protéger leurs marques commerciales. Il pourrait être souhaitable pour ces domaines d'être capable d'annoncer ce fait aux autres hôtes. C'est le sujet des pratiques de signature de domaine d'auteur  (ADSP, Author Domain Signing Practices).

Les hôtes qui mettent en œuvre la présente spécification peuvent s'enquérir de quelles pratiques de signature de domaine d'auteur annonce un domaine. Cette interrogation est appelée une vérification de pratiques de signature de domaine d'auteur.

Les exigences de base pour ADSP sont données dans la [RFC5016]. Le présent document se réfère extensivement à la [RFC4871] et suppose que le lecteur est familiarisé avec elle.

Notation des exigences :
Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

 	2.	Langage et terminologie
 	2.1	Termes importés de la spécification des signatures DKIM
Des termes utilisés ici sont dérivés directement de la [RFC4871]. Dans plusieurs cas , les références dans ce document à "envoyeur" ont été changées ici en "auteur", pour souligner la relation de la ou des adresses d'auteur dans le champ d'en-tête From: décrite dans la [RFC5322]. En bref,
o	Un "signataire" est l'agent qui signe un message, comme défini au paragraphe 2.1 de la [RFC4871].
o	Une "partie locale" est la partie d'une adresse précédant le caractère @, comme défini dans la [RFC5322] et utilisé dans la [RFC4871].

 	2.2	Signature valide
Une "signature valide" est toute signature sur un message qui se vérifie correctement en utilisant la procédure décrite au paragraphe 6.1 de la [RFC4871].

 	2.3	Adresse d'auteur 
Une "adresse d'auteur" est une adresse de messagerie dans le champ d'en-tête From: d'un message [RFC5322]. Si le champ d'en-tête From: contient plusieurs adresses, le message a plusieurs adresses d'auteur.

 	2.4	Domaine d'auteur 
Un "domaine d'auteur" est tout ce qui est à droite du "@" dans une adresse d'auteur (à l'exclusion du "@" lui-même).

 	2.5	Auteur prétendu
Un "auteur prétendu" est une adresse d'auteur d'un message ; elle est "prétendue" parce que elle n'a pas encore été vérifiée.

 	2.6	Pratiques de signature de domaine d'auteur
Les "pratiques de signature de domaine d'auteur" (ou juste les "pratiques") consistent en un enregistrement lisible par la machine publié par le domaine d'un auteur prétendu qui inclut des déclarations sur les pratiques du domaine à l'égard de la messagerie qu'il envoie avec son domaine dans la ligne From:.

 	2.7	Signature de domaine d'auteur
Une "signature de domaine d'auteur" est une signature valide dans laquelle le nom de domaine de l'entité signataire DKIM, c'est-à-dire, l'étiquette d= dans le champ d'en-tête DKIM-Signature, est la même que le nom de domaine dans l'adresse d'auteur. Conformément à la [RFC5321], les comparaisons de nom de domaine sont insensibles à la casse.

Par exemple, si l'adresse de la ligne From: est bob@domaine.exemple, et si le message a une signature valide avec le champ d'en-tête DKIM-Signature qui contient "d=domaine.exemple", alors le message a une signature de domaine d'auteur.

 	3.	Vue d'ensemble du fonctionnement

Les propriétaires de domaine publient les informations d'ADSP via un mécanisme d'interrogation comme celui du système des noms de domaine ; les détails spécifiques sont donnés au paragraphe 4.1. Les hôtes peuvent chercher les informations d'ADSP du ou des domaines spécifiés par la ou les adresses d'auteur comme décrit au paragraphe 4.3. Si un message a plusieurs adresses d'auteur, les recherches d'ADSP DEVRAIENT être effectuées indépendamment sur chaque adresse. Le présent document ne traite pas du processus qu'un hôte pourrait utiliser pour combiner les résultats de recherche.

 	3.1	Applicabilité d'ADSP
ADSP tel que défini dans le présent document est lié au DNS. Pour cette raison, ADSP est applicable seulement aux domaines d'auteur avec des enregistrements DNS appropriés (c'est-à-dire, A, AAAA, et/ou MX) indiquant l'utilisation possible du domaine pour la messagerie. Le traitement des autres domaines d'auteur sort du domaine d'application du présent document. Cependant, des attaquants peuvent utiliser de tels noms de domaine pour tenter délibérément de contourner les déclarations de politique d'ADSP d'une organisation. Il appartient à la mise en œuvre de vérificateur d'ADSP de retourner un résultat d'erreur approprié pour les domaines d'auteur en dehors de la portée de ADSP.

ADSP s'applique à des domaines spécifiques, pas à des sous arborescences de domaines. Si, par exemple, une adresse d'auteur était usager@domaine.exemple, le domaine d'auteur serait domaine.exemple, et l'enregistrement ADSP applicable serait à _adsp._domainkey.domaine.exemple. Une adresse d'auteur dans un sous domaine tel que usager@sous.domaine.exemple aurait un enregistrement ADSP différent à _adsp._domainkey.sous.domaine.exemple. ADSP ne fait pas de connexion entre un domaine et ses domaines parents ou enfants.

Note : Si une organisation veut publier des pratiques de signature de domaine d'auteur pour tous les sous domaines qu'elle utilise, comme les noms d'hôte des serveurs dans le domaine, elle le fait en créant des enregistrements ADSP pour chaque _adsp._domainkey.<sub>.domaine.exemple. Des caractères génériques ne peuvent pas être utilisés (voir le paragraphe 6.3) ; cependant, des outils de gestion convenables du DNS pourraient automatiser la création de l'enregistrement ADSP.

Note : Les résultats des interrogations du DNS qui sont destinées à validerun nom de domaine approximent inévitablement l'ensemble des domaines d'auteur qui peuvent apparaître dans la messagerie légitime. Par exemple, un enregistrement A du DNS pourrait appartenir à un appareil qui n'a même pas de mise en œuvre de messagerie. Il appartient au vérificateur de décider quel degré d'approximation est acceptable.

 	3.2	Usage d'ADSP
Selon le ou les domaines d'auteur et les signatures dans un message, un receveur obtient des quantités variables d'informations utiles de chaque recherche d'ADSP.

o	Si un message n'a pas de signature valide, le résultat d'ADSP est directement pertinent pour le message.

o	Si un message a une signature de domaine d'auteur, ADSP ne fournit pas d'avantage par rapport à ce domaine car le message est déjà connu pour être conforme à toute ADSP possible pour ce domaine.

o	Si un message a une signature valide autre qu'une signature de domaine d'auteur, le receveur peut utiliser la signature et le résultat d'ADSP dans son évaluation du message.

 	3.3	Résultats d'ADSP
Une recherche d'ADSP pour une adresse d'auteur produit un des quatre résultats possibles suivants :

o	Les messages provenant de ce domaine pourraient ou non avoir une signature de domaine d'auteur. C'est le résultat par défaut si le domaine existe dans le DNS mais qu'aucun enregistrement ADSP n'est trouvé.

o	Tous les messages provenant de ce domaine sont signés avec une signature de domaine d'auteur.

o	Tous les messages provenant de ce domaine sont signés avec une signature de domaine d'auteur et sont éliminables, c'est-à-dire, si un message arrive sans une signature de domaine d'auteur valide, le domaine encourage le ou les receveurs à les éliminer.

o	Ce domaine est hors de portée, c'est-à-dire, le domaine n'existe pas dans le DNS.

Une recherche ADSP pourrait se terminer sans produire de résultat si une recherche dans le DNS résulte en une défaillance temporaire.

 	4.	Description détaillée 
 	4.1	Représentation du DNS
Les enregistrements ADSP sont publiés en utilisant le type d'enregistrement de ressource TXT du DNS.

Les RDATA pour les enregistrements de ressource ADSP sont de format textuel, avec une syntaxe et sémantique spécifiques relatives à leur rôle dans la description d'ADSP. La syntaxe de "Tag=Liste de valeurs" décrite au paragraphe 3.2 de la [RFC4871] est utilisée, modifiée pour utiliser des espaces blanches (WSP) plutôt que des espaces de repli (FWS). Les enregistrements non conformes à cette syntaxe ou à la syntaxe des étiquettes individuelles décrite au paragraphe 4.3 DOIVENT être ignorées (considérées équivalentes à un résultat NODATA) pour les besoins d'ADSP, bien que cela PUISSE causer l'enregistrement de messages d'avertissement via un mécanisme approprié d'enregistrement du système. Si les RDATA contiennent plusieurs chaînes de caractères, les chaînes sont enchaînées logiquement sans délimiteur entre les chaînes.

Note : ADSP change la syntaxe de "Tag=liste de valeurs" de la [RFC4871] pour utiliser des WSP plutôt que des FWS dans ses enregistrements du DNS.

Les domaines NE DOIVENT PAS publier les enregistrements ADSP avec des noms comportant des caractères génériques.  Les caractères génériques dans un domaine qui publie des enregistrements ADSP posent un problème particulier, comme discuté plus en détails au paragraphe 6.3.

 	4.2	Publication des enregistrements ADSP
ADSP est destiné à s'appliquer à tous les messages envoyés en utilisant la chaîne de nom de domaine d'un auteur prétendu.

 	4.2.1	Syntaxe d'enregistrement
Les enregistrements ADSP utilisent la syntaxe de "étiquette=valeur" décrite au paragraphe 3.2 de la [RFC4871], modifiée pour utiliser des WSP plutôt que des FWS. Chaque enregistrement ADSP DOIT commencer par une étiquette de pratiques de signature sortante, de sorte que les quatre premiers caractères de l'enregistrement sont "dkim" en minuscules, suivi par une espace facultative et "=".

Les étiquettes utilisées dans les enregistrements ADSP sont décrites ci-dessous. Les étiquettes non reconnues DOIVENT être ignorées. Dans l'ABNF ci-dessous, le jeton WSP est importé de la [RFC5234].

dkim = pratiques de signature sortantes pour le domaine (plain-text ; EXIGÉ). Les valeurs possibles sont comme suit :

unknown (inconnu) : le domaine pourrait signer certains messages ou tous.

all (tous) : tous les messages provenant du domaine sont signés avec une signature de domaine d'auteur.

discardable (éliminable) : tous les messages provenant du domaine sont signés avec une signature de domaine d'auteur. De plus, si un message arrive sans une signature de domaine d'auteur valide du fait d'une modification en transit, la soumission via un chemin sans accès à une clé de signature, ou toute autre raison, le domaine encourage le ou les receveurs à l'éliminer.

Toutes les autres valeurs sont traitées comme "inconnu".

ABNF :

Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du code. Tous droits réservés.

La redistribution et l'utilisation en forme source et binaire, avec ou sans modification, sont permises pourvu que les conditions suivantes soient satisfaites :
o	Les redistributions de code source doivent conserver la notice de droits de reproduction ci-dessus, cette liste de conditions et le déclinatoire de responsabilité qui suit.
o	Les redistributions en forme binaire doivent reproduire la notice de droits de reproduction ci-dessus, cette liste de conditions et le déclinatoire de responsabilité qui suit dans la documentation et/ou autres matériaux fournis avec la distribution.
o	Ni le nom de la Internet Society, de l'IETF ou de l'IETF Trust, ni les noms des contributeurs spécifiques, ne peuvent être utilisés pour avaliser ou promouvoir des produits dérivés de ce logiciel sans permission écrite spécifique préalable.

Ce logiciel est fourni par les détenteurs du droit de reproduction et les contributeurs "TEL QUEL" et toutes garanties expresses ou implicites, incluant, sans s'y limiter, les garanties implicites de commercialisabilité et de convenance à un objet particulier sont déclinées. En aucun cas les détenteurs du droit de reproduction et les contributeurs ne seront responsables de dommages directs, indirects, incidents, spéciaux, exemplaires, ou consécutifs (incluant, sans s'y limiter, la fourniture de biens ou services de substitution, perte d'usage, données, ou profits, ou interruption d'affaires) cependant causés, et aucune théorie de responsabilité, contractuelle, stricte, ou pour tort (incluant la négligence ou autrement) survenant d'une façon quelconque de l'utilisation de ce logiciel, même si on est avisé de la possibilité de tels dommages.

        adsp-dkim-tag = %x64.6b.69.6d *WSP "=" *WSP
                        ("unknown" / "all" / "discardable" / x-adsp-dkim-tag)
        x-adsp-dkim-tag = hyphenated-word   ; pour une future extension
        ; hyphenated-word est défini dans la RFC 4871

 	4.3	Procédure de recherche d'ADSP
Les hôtes qui font une recherche d'ADSP DOIVENT produire un résultat sémantiquement équivalent à appliquer les étapes suivantes dans l'ordre indiqué. En pratique, ces étapes peuvent être effectuées en parallèle afin d'améliorer les performances. Cependant, les mises en œuvre DEVRAIENT éviter de faire des recherches non nécessaires dans le DNS.

Pour les besoins de ce paragraphe, un "enregistrement ADSP valide" est celui qui est correct syntaxiquement et sémantiquement ; en particulier, il correspond à l'ABNF pour une "tag-list" et commence par une étiquette "dkim" valide.

Vérification de la portée de domaine : une mise en œuvre de vérificateur ADSP DOIT déterminer si un domaine d'auteur donné est dans la portée pour l'ADSP. Étant données les déclarations du paragraphe 3.1, le vérificateur DOIT décider quel degré d'approximation est acceptable. Le vérificateur DOIT retourner un résultat d'erreur approprié pour les domaines d'auteur qui sont en dehors de la portée de l'ADSP.

L'hôte DOIT effectuer une interrogation de DNS pour un enregistrement correspondant au domaine d'auteur (sans préfixe). Le type de l'interrogation peut être quelconque, car cette étape est seulement pour déterminer si le domaine lui-même existe dans le DNS. Cette interrogation PEUT être faite en parallèle avec l'interrogation pour aller chercher l'enregistrement ADSP désigné. Si le résultat de cette interrogation est que le domaine d'auteur n'existe pas dans le DNS (souvent appelé une erreur NXDOMAIN, rcode=3 dans la [RFC1035]) l'algorithme DOIT se terminer avec une erreur indiquant que le domaine est hors de portée. Noter qu'un résultat avec le rcode=0 mais pas d'enregistrement (souvent appelé NODATA) n'est pas la même chose que NXDOMAIN.

DISCUSSION NON NORMATIVE : tout type d'enregistrement de ressource pourrait être utilisé pour cette interrogation car l'existence d'un enregistrement de ressource de n'importe quel type va empêcher une erreur NXDOMAIN. MX est un choix raisonnable à cette fin parce que ce type d'enregistrement est estimé être le plus courant pour les domaines utilisés dans la messagerie électronique et va donc produire un résultat qui peut être plus directement mis en antémémoire qu'un résultat négatif.

Si le domaine existe bien, le vérificateur PEUT faire des vérifications plus poussées pour s'assurer de l'existence du domaine, comme celles décrites à la Section 5 de la [RFC5321]. Si ces vérifications indiquent que le domaine d'auteur n'existe pas pour la messagerie, par exemple, le domaine n'a pas d'enregistrement MX, A, ou AAAA, le vérificateur DEVRAIT terminer avec une erreur indiquant que le domaine est hors de portée.

Aller chercher l'enregistrement ADSP désigné : l'hôte DOIT faire une interrogation du DNS pour un enregistrement TXT correspondant au domaine d'auteur préfixé par "_adsp._domainkey." (noter le point en fin).

Si le résultat de cette interrogation est une réponse NOERROR (rcode=0 dans la [RFC1035]) avec une réponse d'un seul enregistrement qui est un enregistrement ADSP valide, utiliser cet enregistrement, et l'algorithme se termine.

Si le résultat de l'interrogation est NXDOMAIN ou NOERROR avec zéro enregistrement, il n'y a pas d'enregistrement ADSP. Si le résultat de l'interrogation contient plus d'un enregistrement, ou un enregistrement qui n'est pas un enregistrement ADSP valide, le résultat d'ADSP est indéfini.

Si une interrogation résulte en une réponse d'erreur "SERVFAIL" (rcode=2 dans la [RFC1035]) l'algorithme se termine sans retourner de résultat ; les actions possibles incluent de mettre en file d'attente le message ou de retourner une erreur SMTP indiquant une défaillance temporaire.

Voir à l'Appendice A des exemples de recherche ADSP.

 	5.	Considérations relatives à l'IANA

ADSP ajoute les espaces de noms suivants au registre de l'IANA. Dans tous les cas, les nouvelles valeurs sont allouées seulement pour les valeurs qui ont été documentées dans une RFC publiée après revue de l'IETF, comme spécifié dans la [RFC5226].

 	5.1	Registre des étiquettes de spécification d'ADSP
Un enregistrement ADSP fournit une liste d'étiquettes de spécification. L'IANA a établi le registre des étiquettes de spécification ADSP pour les étiquettes de spécification qui peuvent être utilisées dans les champs d'ADSP.

L'entrée initiale dans le registre est :

Type	Référence
dkim	(RFC 5617)

 	5.2	Registre des pratiques de signature sortante d'ADSP
La spécification d'étiquette "dkim=", définie au paragraphe 4.2.1, fournit une valeur qui spécifie les pratiques de signature sortante. L'IANA a établi le registre des pratiques de signature sortante ADSP pour les pratiques de signature sortante.

Les entrées initiales dans le registre comprennent :

Type	Référence
unknown	(RFC 5617)
all	(RFC 5617)
discardable	(RFC 5617)

 	5.3	Mise à jour du registre des méthodes de résultat d'authentification
L'IANA a ajouté ce qui suit au registre des noms de méthode d'authentification de messagerie électronique :

Méthode : dkim-adsp
Définie dans : RFC 5617
ptype : header
propriété : from
valeur : contenu du champ d'en-tête From: de la [RFC5322], sans les commentaires.

 	5.4	Mise à jour du registre des résultats d'authentification
L'IANA a ajouté ce qui suit au registre des noms de résultat d'authentification de messagerie électronique :

Code : none (aucun)
Code existant/nouveau : existant
Défini dans : [RFC5451]
Méthode d'authentification : dkim-adsp (ajouté)
Signification : aucun enregistrement de pratiques de signature de domaine d'auteur (ADSP) DKIM n'a été publié.

Code : pass (réussi)
Code existant/nouveau : existant
Défini dans : [RFC5451]
Méthode d'authentification : dkim-adsp (ajouté)
Signification : ce message a une signature de domaine d'auteur validée. (Une vérification d'ADSP n'est pas strictement exigée pour ce résultat car une signature de domaine d'auteur valide satisfait toutes les politiques d'ADSP possibles.)

Code : unknown (inconnu)
Code existant/nouveau : nouveau
Défini dans : RFC 5617
Méthode d'authentification : dkim-adsp
Signification : aucune signature de domaine d'auteur valide n'a été trouvée dans le message et l'ADSP publié était "inconnu".

Code : fail (échec)
Code existant/nouveau : existant
Défini dans : [RFC5451]
Méthode d'authentification : dkim-adsp (ajouté)
Signification : aucune signature de domaine d'auteur valide n'a été trouvée dans le message et l'ADSP publié était "all".

Code : discard (éliminer)
Code existant/nouveau :  nouveau
Défini dans : RFC 5617
Méthode d'authentification : dkim-adsp
Signification : aucune signature de domaine d'auteur valide n'a été trouvée dans le message et l'ADSP publié était "discardable".

Code : nxdomain
Code existant/nouveau : nouveau
Défini dans : RFC 5617
Méthode d'authentification : dkim-adsp
Signification : l'évaluation de l'ADSP pour le domaine DNS de l'auteur indique que le domaine DNS de l'auteur n'existe pas.

Code : temperror (erreur temporaire)
Code existant/nouveau : existant
Défini dans : [RFC5451]
Méthode d'authentification : dkim-adsp (ajouté)
Signification : un enregistrement ADSP n'a pas pu être restitué à cause d'une erreur probablement de nature transitoire, comme une erreur temporaire du DNS. Une tentative ultérieure peut produire un résultat final.

Code : permerror (erreur permanente)
Code existant/nouveau : existant
Défini dans : [RFC5451]
Méthode d'authentification : dkim-adsp (ajouté)
Signification : un enregistrement ADSP n'a pas pu être restitué à cause d'une erreur probablement pas de nature transitoire, comme une erreur permanente du DNS. Une tentative ultérieure a peu de chances de produire un résultat final.

 	6.	Considérations sur la sécurité

Les considérations sur la sécurité dans ADSP sont principalement relatives à des tentatives de la part d'envoyeurs malveillants de se représenter comme des auteurs pour lesquels ils ne sont pas autorisés à envoyer de message, souvent pour tenter de tromper le receveur ou un auteur prétendu.

Des considérations de sécurité supplémentaires concernant les pratiques de signature de domaine d'auteur se trouvent dans l'analyse des menaces de DKIM [RFC4686].

 	6.1	Modèle des menaces sur ADSP
Les receveurs de messagerie ont souvent un ensemble d'auteurs de contenus auxquels ils font déjà confiance. Des exemples courants incluent des institutions financières avec lesquelles ils ont une relations existante et les sites de transaction de la Toile de l'Internet avec lesquels ils font des affaires.

Les abus de la messagerie électronique cherchent souvent à exploiter la reconnaissance du nom d'un auteur de messages légitimes parmi les receveurs en utilisant le nom de domaine de l'auteur dans le champ d'en-tête From:. En particulier comme de nombreux agents d'utilisateur de messagerie (MUA, Mail User Agent) populaires n'affichent pas l'adresse de messagerie de l'auteur, il n'y a pas d'évidence empirique de la mesure dans laquelle cette utilisation particulière non autorisée d'un nom de domaine contribue au mécontentement du receveur ou que l'éliminer va avoir un effet significatif.

Cependant, fermer cette exploitation potentielle pourrait faciliter certains types de traitement optimisé par les moteurs de filtrage de message côté receveur, car cela pourrait leur permettre de maintenir des assertions de plus grande confiance sur les utilisations du champ d'en-tête From: d'un domaine quand l'occurrence est autorisée.

Les utilisations non autorisées des noms de domaine se produisent ailleurs dans les messages, comme le font les utilisations non autorisées de noms d'organisations. Ces attaques sortent du domaine d'application de cette spécification.

ADSP ne donne aucun avantage -- ni, bien sûr, n'a du tout d'effet -- sauf si un système externe agit sur le verdict, soit en traitant le message différemment durant le processus de livraison, soit en montrant un indicateur au receveur d'extrémité. Un tel système sort du domaine d'application de cette spécification.

Les vérificateurs ADSP peuvent effectuer plusieurs recherches dans le DNS par domaine d'auteur prétendu. Comme ces recherches sont conduites par nom de domaine dans les en-têtes de message de messages éventuellement frauduleux, les vérificateurs légitimes d'ADSP peuvent devenir des participants à des attaques en multiplication de trafic sur des domaines qui apparaissent dans des messages frauduleux.

 	6.2	Considérations sur le DNS
Un attaquant pourrait attaquer l'infrastructure du DNS pour tenter de falsifier des enregistrements ADSP et influencer la décision d'un receveur sur la façon de traiter ses messages. Cependant, un tel attaquant va plus probablement attaquer à un niveau supérieur, par exemple, en redirigeant les recherches d'enregistrement A ou MX afin de capturer le trafic qui était légitimement destiné au domaine cible. Ces questions de sécurité du DNS sont traitées par DNSSEC [RFC4033].

Parce que ADSP opère dans le cadre du système de messagerie traditionnel, le résultat par défaut en l'absence d'un enregistrement ADSP est que le domaine ne signe pas tous ses messages. Il est donc important que les clients de ADSP distinguent une défaillance du DNS comme un "SERVFAIL" des autres erreurs du DNS afin que les actions appropriées puissent être effectuées.

 	6.3	Caractères génériques dans le DNS
Des caractères génériques du DNS (décrits dans la [RFC4592]) qui existent dans la hiérarchie du DNS au domaine vérifié ou au dessus, interfèrent avec la capacité de vérifier la portée de la vérification d'ADSP décrite au paragraphe 4.3. Par exemple, un caractére générique d'enregistrement pour *.domaine.exemple fait que tous les sous domaines comme foo.domaine.exemple existent dans le DNS. Les domaines qui ont l'intention de faire un usage actif de ADSP en publiant une pratique autre que "'inconnu" seront avisés d'éviter d'utiliser des caractères génériques dans leur hiérarchie.

Si un domaine contient des caractères génériques, alors tout nom qui correspond au caractère générique peut apparaître comme étant un domaine de messagerie valide éligible pour ADSP. Mais le préfixe "_adsp._domainkey." sur les enregistrements ADSP ne permet pas la publication d'enregistrements avec des caractères génériques qui couvrent les enregistrements ADSP sans aussi couvrir des enregistrements non ADSP, ni ne permet la publication d'enregistrements avec des caractères génériques qui couvrent des enregistrements non ADSP sans aussi couvrir des enregistrements ADSP. Un domaine qui utilise des pratiques d'ADSP autres que "inconnu" NE DEVRAIT PAS publier des enregistrements avec des caractères génériques.

 	6.4	Application inappropriée de signatures de domaine d'auteur
Dans un modèle d'usage de DKIM, un domaine signe des messages qui sont en transit à travers son système. Comme toute signature dont le domaine correspond au domaine d'auteur est, par définition, une signature de domaine d'auteur, il serait malavisé de signer des messages dont le domaine d'auteur est le domaine du signataire si le message n'est pas connu pour satisfaire les normes du domaine pour une signature de domaine d'auteur.

Un tel cas d'utilisation est lorsque un domaine pourrait applique une telle signature à la suite de l'application d'un champ d'en-tête Authentication-Results comme décrit au paragraphe 7.1 de la [RFC5451]. Ce problème peut être facilement évité soit en n'appliquant pas une signature qui pourrait être confondue avec une signature de domaine d'auteur, soit en appliquant une signature provenant d'autres domaines, comme d'un sous domaine du domaine d'auteur.

 	7.	Références
 	7.1	Références normatives

[RFC1035]	P. Mockapetris, "Noms de domaines – Mise en œuvre et spécification", DOI 10.17487/RFC1035, STD 13, novembre 1987. (MàJ par RFC1101, 1183, 1348, 1876, 1982, 1995, 1996, 2065, 2136, 2181, 2137, 2308, 2535, 2673, 2845, 3425, 3658, 4033, 4034, 4035, 4343, 5936, 5966, 6604, 7766, 8482, 8767)

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. DOI 10.17487/RFC2119, (MàJ par RFC8174)

[RFC4033]	R. Arends, et autres, "Introduction et exigences pour la sécurité du DNS", mars 2005, DOI 10.17487/RFC4033

[RFC4592]	E. Lewis, "Le rôle des caractères génériques dans le système des noms de domaines", juillet 2006. (P.S.)

[RFC4871]	E. Allman et autres, "Signatures de messagerie identifiées par DomainKeys (DKIM)", mai 2007. (Remplace RFC4870 Màj par RFC5672 ; Remplacée par RFC6376) (P.S.)

[RFC5226]	T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, mai 2008. (Remplace RFC2434 ; remplacée par RFC8126) 

[RFC5234]	D. Crocker, P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", janvier 2008. (STD0068)

[RFC5322]	P. Resnick, éd., "Format du message Internet", octobre 2008. (Remplace RFC2822) (MàJ RFC4021) (D.S.)

[RFC5451]	M. Kucherawy, "Champ d'en-tête de message pour indiquer l'état d'authentification du message", avril 2009 (MàJ par la RFC6577  ; P. S.) (Remplacée par RFC7001)

 	7.2	Références pour information

[RFC4686]	J. Fenton, "Analyse des menaces qui motivent la messagerie identifiée par DomainKeys (DKIM)", septembre 2006. (Info.)

[RFC5016]	M. Thomas, "Exigences pour un protocole des pratiques de signature de messagerie identifiée par DomainKeys (DKIM)", octobre 2007. (Information)

[RFC5321]	J. Klensin, "Protocole simple de transfert de messagerie(SMTP)", octobre 2008. (Remplace RFC2821) (MàJ RFC1123) (D.S.)
 	
 	Appendice A.	Exemples de recherches

Supposons que le domaine exemple publie ces enregistrements DNS (dans ces exemples, les numéros entre parenthèses sont des commentaires pour aider à identifier les enregistrements, et ne font pas partie des enregistrements eux-mêmes) :

aaa.exemple                     A     192.0.2.1	(1)
_adsp._domainkey.aaa.exemple TXT   "dkim=all"	(2)

bbb.exemple                  MX 10 mail.bbb.exemple	(3)
mail.bbb.exemple             A     192.0.2.2	(4)

 	A.1	Il existe un domaine et un ADSP
Un message contient cette ligne d'en-tête From: :

   From: bob@aaa.exemple (Bob l'auteur)

La recherche ADSP identifie d'abord l'adresse d'auteur bob@aaa.exemple et le domaine d'auteur aaa.exemple. Elle fait une interrogation MX du DNS pour aaa.exemple et reçoit un résultat NOERROR sans enregistrement DNS. (Il n'y a pas d'enregistrement MX, mais comme l'enregistrement (1) existe, le nom existe dans le DNS.) Comme cette interrogation n'a pas retourné une erreur, la recherche se poursuit avec une interrogation TXT DNS pour _adsp._domainkey.aaa.exemple, qui retourne l'enregistrement (2). Comme c'est un enregistrement ADSP valide, le résultat est que tous les messages provenant de ce domaine sont signés.

 	A.2	Le domaine existe, l'ADSP n'existe pas
Un message contient cette ligne d'en-tête From: :

   From: alice@bbb.exemple (Alice démodée)

La recherche ADSP identifie d'abord l'adresse d'auteur alice@bbb.exemple et le domaine d'auteur bbb.exemple. Elle fait une interrogation MX du DNS pour bbb.exemple et obtient l'enregistrement (3). Comme cette interrogation n'a pas retourné d'erreur, elle procède alors à une interrogation TXT DNS pour _adsp._domainkey.bbb.exemple, qui retourne NXDOMAIN.  Comme le domaine existe mais qu'il n'y a pas d'enregistrement ADSP, ADSP retourne le résultat par défaut de "unknown" : les messages peuvent ou pas avoir une signature de domaine d'auteur.

 	A.3	Le domaine n'existe pas
Un message contient cette ligne d'en-tête From: :

   From: frank@ccc.exemple (Frank le pas fiable)

La recherche ADSP identifie d'abord l'adresse d'auteur frank@ccc.exemple et le domaine d'auteur ccc.exemple. Elle fait une interrogation MX du DNS pour ccc.exemple et obtient en retour un résultat NXDOMAIN car il n'y a pas d'enregistrement du tout pour ccc.exemple. La recherche se termine avec le résultat que le domaine n'existe pas dans le DNS et donc est hors de portée.

 	Appendice B.	Exemples d'usage

Ces exemples sont destinés à illustrer les utilisations normales de ADSP. Ils ne sont pas destinés à être exhaustifs ou à s'appliquer à toute situation individuelle de chaque domaine ou système de messagerie.

Les gestionnaires de domaines sont invités à examiner les moyens dont le traitement de messagerie peut modifier les messages de façons qui invalident une signature DKIM existante, comme des listes de diffusion, des copies de courtoisie, et autres chemins qui pourraient ajouter ou modifier les en-têtes, ou modifier le corps de message. Si les modifications invalident la signature DKIM, les hôtes receveurs vont considérer que le message n'a pas de signature de domaine d'auteur, même si la signature était présente quand le message a été envoyé à l'origine.

 	B.1	Domaines d'une seule localisation
Une configuration courante de système de messagerie traite tous les messages entrants et sortants des utilisateurs d'un domaine à travers un seul agent de transport de messagerie (MTA, Mail Transport Agent) ou groupe de MTA. Avec cette configuration, le ou les MTA peuvent être configurés à signer les messages sortants avec une signature de domaine d'auteur.

Dans cette situation, il pourrait être approprié de publier un enregistrement ADSP pour le domaine contenant "all", selon que les utilisateurs envoient aussi des messages par d'autres chemins qui n'appliquent pas de signature de domaine d'auteur. De tels chemins pourraient inclure des MTA à des hôtels ou des points chauds de réseau utilisés par des utilisateurs en voyage, des sites de la Toile qui fournissent des caractéristiques de "messagerie à la pièce", les messages envoyés par des listes de diffusion, ou des clients de messagerie tiers qui prennent en charge plusieurs identités d'utilisateur.

 	B.2	Domaines de messagerie en gros
Une autre configuration courante utilise un domaine seulement pour les messages en vrac ou en diffusion, sans utilisateur humain individuel -- là encore, envoyant normalement tous les messages à travers un seul MTA ou groupe de MTA qui peuvent appliquer une signature de domaine d'auteur. Dans ce cas, la gestion du domaine peut avoir confiance que tous ses messages sortants vont être envoyés à travers le ou les MTA signants. En l'absence d'utilisateurs individuels, le domaine a peu de chances de participer à des listes de diffusion, mais pourrait quand même envoyer des messages par d'autres chemins qui pourraient invalider les signatures.

Les propriétaires de domaine utilisent souvent des fournisseurs de messagerie spécialisés pour envoyer leurs flux de messages. Dans ce cas, le fournisseur de messagerie a besoin d'avoir accès à une clé de signature convenable afin d'appliquer une signature de domaine d'auteur. Un chemin possible serait que le propriétaire du domaine génère la clé et la donne au fournisseur de messagerie. Un autre serait que le domaine délègue un sous domaine au fournisseur de messagerie, par exemple, bigbank.exemple pourrait déléguer email.bigbank.exemple à un tel fournisseur ; dans ce cas, le fournisseur peut générer lui-même les clés et les enregistrement DKIM du DNS et utiliser le sous domaine dans l'adresse d'auteur dans le message.

Sans considération de la stratégie de gestion du DNS et des clés choisie, celui, quel qu'il soit qui maintient les enregistrements DKIM pour le domaine, pourrait aussi installer un enregistrement ADSP contenant "all".

 	B.3	Domaines de messagerie en gros avec messages éliminables
Dans certains cas, un domaine peut signer tous ses messages sortants avec une signature de domaine d'auteur et préférer que les systèmes receveurs éliminent les messages sans signature de domaine d'auteur valide afin d'éviter d'avoir ses messages confondus avec les messages envoyés de sources qui n'appliquent pas de signature de domaine d'auteur. (Dans le cas de domaines avec un contrôle strict des messages sortants, cette dernière sorte de messages est parfois appelée du terme vague de "faux".) Dans ce cas, il pourrait être approprié de publier un enregistrement ADSP contenant "discardable". Noter qu'un domaine NE DEVRAIT PAS publier un enregistrement "discardable" si il souhaite maximiser la probabilité que les messages provenant de ce domaine soit livrés, car cela pourrait causer l'élimination d'une certaine fraction des messages envoyés du domaine.

 	B.4	Envoyeurs tiers
Un autre cas d'utilisation courant est celui d'un tiers qui entre dans un accord par lequel ce tiers va envoyer les messages en vrac ou autres au nom d'un auteur ou domaine d'auteur désigné, en utilisant ce domaine dans les en-tête From: ou autres de la [RFC5322]. Du fait des complexités nombreuses et variées de ces accords, la signature de tiers n'est pas traitée par la présente spécification.

 	B.5	Domaines avec des utilisateurs indépendants et des politiques d'utilisation libérales
Quand un domaine a des utilisateurs indépendants et que sa politique d'usage ne les contraint pas explicitement à envoyer des messages seulement à partir des serveurs de messagerie désignés (par exemple, de nombreux domaines de fournisseurs d'accès Internet et même certains domaines d'entreprises) il est alors seulement approprié de publier un enregistrement ADSP contenant "unknown". Publier "all" ou "discardable" résulterait probablement en une casse significative parce que les utilisateurs indépendants vont probablement envoyer des messages à partir des chemins externes énumérés à l'Appendice B.1.

 	B.6	Domaines non de messagerie
Si un domaine n'envoie pas de message du tout, il peut en toute sécurité publier un enregistrement ADSP "discardable", parce que tout message avec une adresse d'auteur dans le domaine est un faux.

 	Appendice C.	Remerciements

Le présent document a largement bénéficié des commentaires de Steve Atkins, Jon Callas, Dave Crocker, Pasi Eronen, JD Falk, Arvel Hathcock, Ellen Siegel, Michael Thomas, et Wietse Venema.

 	Adresse des auteurs

Eric Allman	Jim Fenton	
Sendmail, Inc.	Cisco Systems, Inc.	
6475 Christie Ave, Suite 350	170 W. Tasman Drive	
Emeryville, CA  94608	San Jose, CA  95134-1706	
téléphone : +1 510 594 5501	téléphone : +1 408 526 5914	
mél : eric+dkim@sendmail.org	mél : fenton@cisco.com	

Mark Delany	John Levine	
Yahoo! Inc.	Taughannock Networks	
701 First Avenue	PO Box 727	
Sunnyvale, CA  94089	Trumansburg, NY  14886	
téléphone : +1 408 349 6831	téléphone : +1 831 480 2300	
mél : markd+dkim@yahoo-inc.com	mél : standards@taugh.com