Path: ...!3.us.feeder.erje.net!3.eu.feeder.erje.net!feeder.erje.net!usenet.goja.nl.eu.org!aioe.org!zabDkiJnTMb8/8dY5+WhLA.user.46.165.242.91.POSTED!not-for-mail
From: Didier <nospam@invalid.invalid>
Newsgroups: fr.comp.mail
Subject: Re: Return-path
Date: Sun, 24 Apr 2022 20:07:05 +0200
Organization: Aioe.org NNTP Server
Message-ID: <t443k8$ut8$1@gioia.aioe.org>
References: <62655b0d$0$22068$426a74cc@news.free.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="31656"; posting-host="zabDkiJnTMb8/8dY5+WhLA.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.8.1
Content-Language: fr
X-Notice: Filtered by postfilter v. 0.9.2
Bytes: 4208
Lines: 68

Le 24/04/2022 à 16:13, les renardeaux a écrit :
> 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...
> 
Bjr,
RFC, ça signifie seulement "Request For Comment", ce n'est pas une 
norme, juste une suggestion pour commentaires, qui doit avoir sans doute 
valeur de recommandation.
C'est une des joyeusetés que l'Internet a apporté par rapport au monde 
des Télécoms qui lui fonctionnait sur des normes (ce qui est 
obligatoire, ce qui est possible, ce qui est interdit), et n'aurait pas 
laissé passer ça.
Didier.