Return-path

Boujour à tous,

Ce n'est sans doute pas nouveau mais je viens de remarquer qu'un grand
nombre de mails parmi ceux que je reçois comporte cette curiosité: le
header [Return-path] est *identique* à l'header [To]
Bien sûr je ne m'écris pas en l'occurrence à moi-même.

Tantôt il s'agit de mails commerciaux, exemple:
[From] Discord <noreply@discord.com> (et je ne suis pas chez Discord)
[To] les.renardeaux@wanadoo.fr
[Return-path] les.renardeaux@wanadoo.fr
...

et, là c'est nettement plus curieux, de services censés être
technico-compatibles, exemple:
[From] GIE SESAM-Vitale <lettreinformation@sesam-vitale.fr>
[To] a.i.l@wanadoo.fr
[Return-path] a.i.l@wanadoo.fr
...

Ce repiquage du header [To] pour le header [Return-path] est-il
acceptable ? Conforme à une RFC -pourtant paraissant sans équivoque-
(La 822 donne:
 return      =  "Return-path" ":" route-addr ; return address
 La 5321 donne:
When the delivery SMTP server makes the "final delivery" of a
   message, it inserts a return-path line at the beginning of the mail
   data.  This use of return-path is required; mail systems MUST
support
   it.  The return-path line preserves the information in the <reverse-
   path> from the MAIL command.  Here, final delivery means the message
   has left the SMTP environment.  Normally, this would mean it had
been
   delivered to the destination user or an associated mail drop, but in
   some cases it may be further processed and transmitted by another
   mail system.
               ..................
A message-originating SMTP system SHOULD NOT send a message that
   already contains a Return-path header field.  SMTP servers
performing
   a relay function MUST NOT inspect the message data, and especially
   not to the extent needed to determine if Return-path header fields
   are present.  SMTP servers making final delivery MAY remove Return-
   path header fields before adding their own.

   The primary purpose of the Return-path is to designate the address
to
   which messages indicating non-delivery or other mail system failures
   are to be sent.  For this to be unambiguous, exactly one return path
   SHOULD be present when the message is delivered.  Systems using RFC
   822 syntax with non-SMTP transports SHOULD designate an unambiguous
   address, associated with the transport envelope, to which error
   reports (e.g., non-delivery messages) should be sent.)
Un décret franco-français ?

Quelle action pour que remettre l'église au milieu du village ?
Où gueuler pour épingler les branques ? Un mail à l'expéditeur est
souvent malaisé, ces derniers s'abritant derrière du noreply...

--
  ... Michel
     les petits renardeaux dans la clairière du CTV