Date de publication du RFC : Avril 2006
Auteur(s) du RFC : J. Lyon (Microsoft)
Intérêt historique uniquement
Première rédaction de cet article le 17 mai 2006
Un très court RFC qui décrit l'algorithme PRA (Purported Responsible Address) qui permet de désigner un expéditeur à partir des en-têtes d'un message électronique. (L'expérience a été abandonnée par la suite, et reclassifiée « intérêt historique seulement », en février 2020.)
Il existe en effet plusieurs identités possibles pour l'émetteur
d'un courrier : l'adresse indiquée par la commande MAIL
FROM
de SMTP (RFC 2821) ? Celle indiquée par le champ
From:
des en-têtes (RFC 2822) ? Aucune n'est idéale et le choix dépend de pas mal de
considérations. (Meng Weng Wong, concepteur de SPF), fait remarquer que les gens du
logiciel libre préfèrent l'identité SMTP et Microsoft préfère une
identité extraite des en-têtes ; selon lui, c'est parce que le
logiciel libre sur Unix domine dans le monde des
MTA et Microsoft domine dans celui des
MUA.)
Par exemple, un message envoyé sur la liste de diffusion des utilisateurs francophones de Debian contient :
MAIL FROM (SMTP) bounce-debian-user-french=stephane=sources.org@lists.debian.org From: Demba COULIBALY <demcoul@yahoo.com> To: debian-user-french@lists.debian.org Resent-From: debian-user-french@lists.debian.org Resent-Sender: debian-user-french-request@lists.debian.org
Quel est l'expéditeur ? Demba Coulibaly l'a écrit (et c'est typiquement l'expéditeur que va m'indiquer mon MUA) mais c'est une machine de Debian qui me l'a transmis, via le programme de gestion de listes de diffusion.
Or, tous les efforts d'authentification de l'émetteur d'un courrier dépendent de cette identité.
Notre RFC propose donc de ne pas
utiliser le From:
aveuglément mais de ne le
prendre que s'il est seul, et d'utiliser
Resent-From:
ou
Resent-Sender:
s'ils sont présents. Je ne
reprends pas l'algorithme ici, il figure dans le RFC mais il est de
toute façon trivial (vous pouvez en voir une mise en œuvre en
Python, par moi, PRA.py
et une
en Perl, par Mark Kramer, pra2.pl
).
Ce RFC est un des produits du groupe de travail IETF maudit, MARID, qui avait tenté de créer une norme ouverte d'authentification du courrier électronique mais avait été fermé d'autorité avant d'être arrivé à un résultat. Les documents survivants ont été publiés avec un gros avertissement de l'IESG, qui, dans le cas de notre RFC, met en garde contre le fait que l'algorithme PRA ne marche pas pour la plupart des listes de diffusion (la liste Debian, citée plus haut, n'a pas de problèmes).
Une des raisons de la crise du groupe de travail MARID était le fait que PRA est plombé par un brevet de Microsoft. Beaucoup refusaient de normaliser une technologie où il aurait fallu obtenir une licence, même gratuite, de la part d'une grosse société dominante.
Mais PRA illustre aussi à quel point le système des brevets est délirant et a échappé à tout contrôle : l'algorithme PRA est trivial, il tient en quelques lignes de Perl ou de Python et il n'aurait jamais dû être brevetable. Il est scandaleux que les organismes de dépôt de brevet soient payés au nombre de brevets enregistrés, les encourageant ainsi à accepter des brevets futiles, comme celui sur PRA.
Version PDF de cette page (mais vous pouvez aussi imprimer depuis votre navigateur, il y a une feuille de style prévue pour cela)
Source XML de cette page (cette page est distribuée sous les termes de la licence GFDL)