Mon blog

Le RFC 7001 avait créé l'en-tête de courrier Authentication-Results: qui permettait de signaler à un logiciel de courrier les résultats de tests d'authenticité faits par un serveur. Cet en-tête pouvait inclure un type de propriété (property type ou ptype) qui indiquait d'où venait la propriété testée : la session SMTP, l'en-tête du message, son corps, ou bien une politique locale. Le jeu de valeurs pour les types possibles était fixe et, depuis, certains ont trouvé ce jeu trop restreint. Ce nouveau et très court RFC remplace donc la liste fixe du RFC 7001 par un registre en ligne à l'IANA. (Depuis, le RFC 7601, a remplacé ces deux RFC.)

Le principe de base du RFC 7001 est de séparer l'exécution des tests d'authenticité de l'utilisation de leurs résultats. Par exemple, les tests sont effectués sur un serveur de messagerie de l'organisation, et leur utilisation est décidée sur le poste de travail de l'utilisateur. Voici un exemple de résultat transmis au logiciel, utilisant les types de propriétés :

Authentication-Results: example.com;
                  spf=pass smtp.mailfrom=example.net
                           ^^^^^^^^^^^^^
                           Type et propriété

Ici, le test SPF a été fait lors de la session SMTP (le type est smtp et il est suivi d'un point et de la commande SMTP - la propriété - testée). Autre exemple :

Authentication-Results: example.com;
              dkim=fail reason="bad signature"
                header.i=@newyork.example.com
                ^^^^^^^^
                Type et propriété

Ici, le test était du DKIM, le type était l'en-tête du message (header) et la propriété le champ i de la signature DKIM (notez que le RFC 7001 dit que la propriété après header doit être un en-tête du message, ce qui n'est pas le cas ici, mais c'est un exemple officiel, je n'y peux rien, voir la bogue du RFC 7001).

Dans ces deux exemples, on a vu les types de propriétés smtp et header. Deux autres sont définis par le RFC 7001, section 2.2, body et policy. Cette liste était fixe et c'est ce point que change notre nouveau RFC.

Désormais, le type de propriété peut être n'importe quel mot-clé enregistré à l'IANA. Ce registre démarre avec les quatre types du RFC 7001. L'enregistrement d'une nouvelle valeur se fait selon la procédure « Examen par un expert » du RFC 5226.

Il est recommandé d'ignorer les types de propriété inconnus (ceux qui viennent d'être enregistrés et ne sont pas encore connus du logiciel). Autrement, déployer un nouveau type serait quasi-impossible.

Comme indiqué plus haut, ce RFC a été fusionné avec le RFC 7001 pour donner le texte qu'il faut consulter aujourd'hui, le RFC 7601.