Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

Mon livre « Cyberstructure »

Ève

RFC 4407: Purported Responsible Address in E-Mail Messages

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.


Téléchargez le RFC 4407

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)