Résumé

  • La RFC 2369 de juillet 1998 permettait à une liste d’annoncer une adresse de désabonnement dans les en-têtes. Si l’ouverture de l’URL suffisait à radier un abonné, l’inspection automatique et la volonté du lecteur devenaient indiscernables.
  • La RFC 8058 de janvier 2017 a ajouté List-Unsubscribe-Post: List-Unsubscribe=One-Click. Une signature DKIM valide doit couvrir ce champ et List-Unsubscribe ; le destinataire doit consentir avant que son logiciel n’envoie un POST HTTPS.
  • Le POST ne contient que la paire clé-valeur prescrite, sans cookie ni autorisation HTTP. Le serveur ne doit pas répondre par une redirection HTTPS. Le nouveau champ figure au registre de l’IANA.

La visite qui comptait comme un vote

Le premier dispositif rendait service. Avec RFC 2369, une liste pouvait placer son chemin de sortie dans List-Unsubscribe. Le logiciel de messagerie pouvait le montrer au lecteur sans fouiller le pied d’un long courrier. Le champ pouvait contenir une URL HTTPS. Il rendait le départ facile à trouver, mais il ne disait pas qui, humain ou programme, venait de visiter l’adresse.

Le logiciel de sécurité a fini par suivre lui aussi ces indications. La RFC 8058 décrit des outils antispam qui récupèrent automatiquement les ressources mentionnées dans les en-têtes, sans intervention de l’utilisateur. Si le serveur supprime l’abonné dès que l’URL est visitée, l’analyse du lien devient un désabonnement. Du côté du serveur, aucune propriété mécanique de cette visite ne distingue sûrement l’inspection du choix d’une personne. Le filtre censé protéger le courrier peut alors retirer son propriétaire de la liste.

Les expéditeurs ont interposé des pages de confirmation. Le robot ouvre la page, mais ne clique pas sur le deuxième bouton ; la personne peut achever la démarche. Cette défense évite la radiation accidentelle au prix d’un abandon du « un clic ». Le véritable défaut était plus profond : une adresse offerte à la lecture servait aussi d’autorisation à changer un état.

Le nouvel en-tête précise le verbe

La RFC 8058 conserve l’ancien champ et lui adjoint une indication distincte pour l’opération en un clic. L’expéditeur met une URI HTTPS dans List-Unsubscribe et exactement List-Unsubscribe=One-Click dans List-Unsubscribe-Post. Après consentement, le logiciel récepteur envoie à cette URI un POST HTTPS dont le corps porte cette seule paire. Examiner une URL par une récupération ordinaire et modifier l’abonnement par POST deviennent deux actes séparés jusque dans la méthode HTTP.

L’expéditeur doit aussi appliquer une signature DKIM valide qui couvre les deux en-têtes, tous deux inscrits dans la liste h= de la signature. La signature relie l’adresse et la promesse d’une opération en un clic au message vérifiable. En son absence, la RFC indique que le logiciel récepteur ne devrait pas proposer cette opération. Une signature atteste l’offre de l’expéditeur ; elle ne remplace pas le choix du lecteur.

La décision revient ensuite à celui-ci. Le logiciel récepteur ne doit pas envoyer de POST sans son consentement. La RFC laisse à ce logiciel la façon de demander ce consentement. Les pouvoirs sont ainsi distribués : l’expéditeur publie et signe l’offre, le logiciel présente et exécute l’action, le lecteur décide. Le scanner qui inspecte l’adresse n’hérite d’aucun de ces pouvoirs.

Le serveur doit terminer à l’adresse annoncée

Le corps du POST contient uniquement la paire prescrite. Il ne transporte ni cookie, ni autorisation HTTP, ni contexte supplémentaire. L’URI doit donc identifier assez précisément le destinataire et la liste pour permettre la radiation. La RFC recommande un identifiant opaque difficile à deviner. Un serveur qui compte sur une session de navigateur pour retrouver le compte ne peut pas exécuter la requête prévue.

Il ne peut pas non plus rediriger ce POST vers une autre adresse HTTPS. La raison donnée par la RFC est pratique : les POST redirigés ont mal fonctionné historiquement et certains navigateurs les ont transformés en GET. La frontière entre lecture et action, soigneusement établie dans le message, se dissoudrait pendant le trajet. Le serveur doit accepter la demande consentie à l’adresse qu’il a lui-même publiée et y achever l’opération.

La RFC 8058 ne réécrit pas les autres usages des URL de désabonnement de la RFC 2369. Elle balise un parcours particulier. L’IANA a enregistré List-Unsubscribe-Post, mais le registre ne peut pas faire fonctionner un bouton : il faut encore la signature, l’accord du lecteur, le POST du récepteur et le traitement du serveur.

La sortie est une chaîne, pas un lien

L’exploitant de liste tient l’offre signée et le serveur. Le logiciel de messagerie tient l’interface et le moment de la requête. Le lecteur tient la décision. L’inspection automatique reste une inspection. C’est le partage instauré par cette petite modification des en-têtes. Faute d’un maillon, le chemin de sortie peut devenir une machine à départs involontaires ou un bouton décoratif.

Ces documents officiels établissent la règle et son enregistrement. Pour mesurer sa mise en œuvre dans un service précis, il faudrait des messages bruts datés, des manuels de réception et les journaux du serveur expéditeur. Le fait historique est déjà net : le Web permettait à un programme d’ouvrir facilement un lien ; le courrier électronique devait préciser quelle ouverture valait un ordre.