Résumé

  • Dans sa lettre du 2 septembre 2004, Apache annonce que SpamAssassin et JAMES ne mettront pas en œuvre Sender ID sous les conditions alors proposées par Microsoft. La gratuité des redevances ne résolvait pas, selon la fondation, les droits des redistributeurs.
  • L'IETF publie Sender ID et SPF en 2006 avec le statut expérimental et un avertissement sur les courriels valides susceptibles d'être perdus. Son bilan de 2012 constate l'essor de SPF et la faible adoption de Sender ID ; les textes de ce dernier passent au statut Historic en 2020.

L'adresse que l'on montre, celle que l'on vérifie

L'en-tête affiché au lecteur et l'adresse utilisée dans la conversation SMTP ne remplissent pas la même fonction. Un transfert de message peut encore éloigner ces deux repères. Lorsqu'un domaine publie dans le DNS les serveurs autorisés à envoyer son courrier, le serveur destinataire doit donc savoir à quelle identité appliquer cette autorisation.

La charte du groupe MARID énumérait précisément les candidats : les champs From ou Sender du message, Mail-From dans SMTP et le nom annoncé par EHLO. Choisir l'identité devait être sa première tâche. Ce choix n'était pas une préférence de présentation. Il déterminait quel domaine serait interrogé et quel message serait accepté ou refusé.

Sender ID utilisait notamment l'algorithme PRA pour chercher une adresse responsable dans les en-têtes. SPF examinait les identités de la transaction SMTP. Les deux approches plaçaient des politiques dans le DNS. Ce voisinage technique rendait leur désaccord dangereux : un serveur pouvait prendre une déclaration écrite pour une méthode et lui appliquer l'autre.

« Sans redevance » ne voulait pas dire « transmissible »

Le 2 septembre 2004, la fondation Apache écrit à la liste MARID que les conditions de la licence de brevet Sender ID de Microsoft empêchent ses projets SpamAssassin et JAMES de l'intégrer ou de le déployer. Elle juge ces conditions incompatibles avec la licence Apache 2.0. Le prix annoncé était nul ; la circulation des droits, elle, posait problème.

Apache désignait deux obstacles concrets. Selon sa lecture de l'offre, les droits de brevet ne pouvaient pas être concédés de manière fluide aux destinataires successifs du logiciel. Un acteur souhaitant redistribuer ou rebaptiser une implémentation devait aussi contacter Microsoft. Dans un projet où le code passe normalement des auteurs aux mainteneurs, puis aux distributeurs et aux utilisateurs, cette obligation donnait au détenteur du brevet un regard sur la chaîne de diffusion.

La fondation décidait pour ses propres logiciels. Sa lettre ne rendait pas Sender ID inexécutable ailleurs. Elle montrait toutefois une faille dans l'idée qu'une spécification publique suffit à produire une implémentation ouverte : le texte du protocole et les permissions nécessaires pour livrer du code peuvent emprunter deux voies différentes.

L'IETF publie le désaccord

En avril 2006, Sender ID et SPF paraissent côte à côte comme RFC expérimentales. La note de l'IESG est directe : pas de consensus technique général, échec des tentatives de rapprochement. Elle avertit qu'un récepteur Sender ID pourrait interpréter une entrée DNS publiée pour SPF selon ses propres règles, puis écarter un courrier légitime. Elle relève aussi un problème lié aux transferts automatiques et aux champs Resent-*.

L'IETF avait ainsi conservé les deux propositions sans transformer leur coexistence en compatibilité. Le risque n'était pas seulement une querelle entre auteurs de RFC : il se matérialisait au moment où un serveur appliquait une politique et décidait de remettre ou non un message.

Le rapport expérimental de 2012 distingue les mécanismes disponibles des mécanismes réellement utilisés. SPF avait une large diffusion ; les éléments PRA et SUBMITTER de Sender ID n'avaient pas rassemblé une forte communauté d'utilisateurs. Le rapport précise que le manque de logiciels n'a pas été le facteur qui a départagé les solutions. En 2014, SPF entre dans la voie des normes. En 2020, les trois RFC de Sender ID deviennent Historic.

Le refus d'Apache et le verdict de l'IETF racontent donc deux décisions situées à des endroits différents. Apache a fermé sa propre chaîne de distribution à ces conditions de brevet. Les opérateurs de courrier ont, au fil du temps, donné une diffusion très inégale aux deux expériences. Entre les deux, l'avertissement de 2006 rappelle la dette la plus tangible : un même enregistrement DNS ne peut guider correctement la remise du courrier si les récepteurs ne s'accordent pas sur l'identité à vérifier.