Mon blog

On le sait, le courrier électronique, tel qu'il est spécifié dans les RFC 2821 et RFC 2822, ne fournit aucune authentification, même faible, de l'émetteur. Un expéditeur de courrier peut toujours prétendre être Nicolas Sarkozy <iznogoud@jeveuxetrealelysee.fr> et il n'y a aucun moyen de l'en empêcher. Sender ID vise à diminuer cette facilité de frauder en permettant à un titulaire de nom de domaine de déclarer quelle(s) adresse(s) IP sont autorisées à envoyer du courrier pour ce domaine. (L'expérience a été abandonnée par la suite, et reclassifiée « intérêt historique seulement », en février 2020.)

Sender ID est un concurrent de SPF. SPF avait été spécifié à l'origine (pas dans un RFC mais dans un processus informel) puis, dans le cadre du défunt groupe de travail MARID de l'IETF, une tentative de fusion entre SPF et le protocole de Microsoft, Caller ID, avait été tentée et avait donné naissance à Sender ID.

Sender ID partage donc beaucoup des caractéristiques de SPF (spécifié dans le RFC 4408). Les principales différences sont :

• Sender ID marque ses enregistrements avec "spf/2.0" et pas avec "v=spf1" mais, si ceux-ci ne sont pas présents, Sender ID utilise les enregistrements SPF, mais en leur donnant un sens différent (ce qui n'aurait jamais dû être accepté par l'IESG et a fait l'objet d'un appel, malheureusement repoussé),
• Sender ID authentifie surtout une adresse tirée des en-têtes (via l'algorithme PRA, spécifié dans le RFC 4407).

Il est amusant de noter qu'AOL est un des rares domaines à publier à la fois du SPF et du Sender ID :

% dig +short TXT aol.com 
"spf2.0/pra ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ptr:mx.aol.com ?all"
"v=spf1 ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ptr:mx.aol.com ?all"

alors que Microsoft, auteur et principal promoteur de Sender ID ne publie que du SPF.

En même temps que notre RFC a été publié le RFC 4408 sur SPF. SPF, comme Sender ID, avait été discuté dans le groupe de travail MARID, groupe qui avait été autoritairement dissous avant d'avoir atteint un consensus. Malgré le déploiement bien plus important de SPF, l'IESG a choisi de traiter les deux propositions de manière égale et de publier les deux RFC comme expérimentaux. C'est seulement en 2012, avec la publication du RFC 6686, que l'IETF a reconnu que Sender ID n'avait connu aucun déploiement significatif et que SPF restait seul en lice.