Mon blog

Qui est l'auteur d'un message reçu par courrier électronique ? La réponse semblait autrefois simple, c'est forcément la personne ou l'organisation indiquée dans le champ From:. Sauf que des changements récents (et pas forcément bien inspirés) dans le traitement des messages ont amené à ce que le From: soit parfois modifié, par exemple par certaines listes de diffusion. Il ne reflète donc plus le vrai auteur. D'où ce RFC qui crée un nouvel en-tête, Author:, qui identifie le vrai émetteur.

La norme pertinente est le RFC 5322, qui définit des en-têtes comme From: (auteur d'un message) ou Sender: (personne ou entité qui n'a pas écrit le message mais réalise l'envoi, par exemple parce que l'auteur n'avait pas le temps, ou bien parce que le message a été relayé par un intermédiaire). Les amateurs d'archéologie noteront que le courrier électronique est très ancien, plus ancien que l'Internet, cette ancienneté étant la preuve de son efficacité et de sa robustesse. Le premier RFC avec la notion formelle d'auteur d'un message était le RFC 733.

Une particularité du courrier électronique est que le message ne va pas toujours directement de la machine de l'auteure à celle du lecteur (cf. le RFC 5598, sur l'architecture du courrier). Il y a souvent des intermédiaires (mediators) comme les gestionnaires de listes de diffusion, qui prennent un message et le redistribuent aux abonnées. En raison du problème du spam, plusieurs mécanismes de protection ont été développés, qui peuvent poser des problèmes pour ces intermédiaires. SPF (RFC 7208), contrairement à une légende tenace, n'affecte pas les listes de diffusion. (C'est en raison de la distinction entre enveloppe et en-tête d'un message. Si vous entendez quelqu'un pontifier sur SPF et la messagerie, et qu'il ne connait pas la différence entre l'émetteur indiqué dans l'enveloppe et celui marqué dans l'en-tête, vous pouvez être sûre que cette personne est ignorante.) En revanche, DKIM (RFC 6376), surtout combiné avec DMARC (RFC 7489), peut poser des problèmes dans certains cas (le RFC 6377 les détaille). Pour gérer ces problèmes, certaines listes de diffusion choisissent de carrément changer le From: du message et d'y mettre, par exemple (ici tiré de l'utile liste outages, informant des pannes Internet) :

From: Erik Sundberg via Outages <outages@outages.org>

  

Alors que le message avait en fait été écrit par « Erik Sundberg <ESundberg@nitelusa.com> ». C'est une mauvaise idée, mais elle est commune. Dans ce cas, la liste s'est « approprié » le message et on a perdu le vrai auteur, privant ainsi la lectrice d'une information utile (dans le cas de la liste Outages, il a toutefois été préservé dans le champ Reply-To:). [Personnellement, il me semble que l'idéal serait de ne pas modifier le message, préservant ainsi les signatures DKIM, et donc les vérifications DMARC. Dans les cas où le message est modifié, DMARC s'obstine à vérifier le From: et pas le Sender:, ce qui serait pourtant bien plus logique.]

Maintenant, la solution (section 3 du RFC) : un nouvel en-tête, Author:, dont la syntaxe est la même que celle de From:. Par exemple :

Author: Dave Crocker <dcrocker@bbiw.net>

  

Cet en-tête peut être mis au départ, par le MUA, ou bien ajouté par un intermédiaire qui massacre le champ From: mais veut garder une trace de sa valeur originale en la recopiant dans le champ Author:. Cela n'est possible que s'il n'y a pas déjà un champ Author:. S'il existe, il est strictement interdit de le modifier ou de le supprimer.

À la lecture, par le MUA de réception, le RFC conseille d'utiliser le champ Author:, s'il est présent, plutôt que le From:, pour afficher ou trier sur le nom de l'expéditrice.

Comme dans le cas du champ From:, un malhonnête peut évidemment mettre n'importe quoi dans le champ Author: et il faut donc faire attention à ne pas lui accorder une confiance aveugle.

Author: a été ajouté au registre des en-têtes.

On notera qu'une tentative précédente de préservation de l'en-tête From: original avait été faite dans le RFC 5703, qui créait un Original-From: mais uniquement pour les intermédiaires, pas pour les MUA.