Return-path

Didier

24/04/2022 à 20:07

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 (et je ne suis pas chez Discord)
[To]
[Return-path]
...
et, lÍ c'est nettement plus curieux, de services censés être
technico-compatibles, exemple:
[From] GIE SESAM-Vitale
[To]
[Return-path]
...
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.

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.

Vous avez filtré cet utilisateur ! Consultez son message

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 (et je ne suis pas chez Discord)
[To]
[Return-path]
...
et, lÍ c'est nettement plus curieux, de services censés être
technico-compatibles, exemple:
[From] GIE SESAM-Vitale
[To]
[Return-path]
...
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.

Jean-Pierre Kuypers

24/04/2022 à 20:25

In article (Dans l'article) <t443k8$ut8$, Didier
wrote (écrivait)Â :

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.

Chacun restant libre de faire ce qu'il veut, bien entendu...
Reste qu'Í défaut de respecter les non-normes sur lesquelles les
partenaires s'alignent, on a peu de chance de voir son équipement de
communication fonctionner correctement.
--
Jean-Pierre Kuypers

Didier

24/04/2022 à 22:36

Le 24/04/2022 Í 20:25, Jean-Pierre Kuypers a écritÂ :

In article (Dans l'article) <t443k8$ut8$, Didier
wrote (écrivait)Â :
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.

Chacun restant libre de faire ce qu'il veut, bien entendu...
Reste qu'Í défaut de respecter les non-normes sur lesquelles les
partenaires s'alignent, on a peu de chance de voir son équipement de
communication fonctionner correctement.

Ou comme dans le cas cité ici, ou dans tous ces appels téléphoniques
qu'on reçoit avec notre propre numéro comme numéro appelant, par
exemple, ça fonctionne et ça fait n'importe quoi, ou plutÍ´t, comme tu le
dis, ce que chacun veut; mais ça fonctionne, c'est certain ... même sans
respecter.
Didier.

les renardeaux

25/04/2022 à 00:25

Bonjour,
Le message du dimanche 24/04/2022 (cf. <t44cbh$l05$ ),
Didier dixit, stipule notammant :

Le 24/04/2022 Í 20:25, Jean-Pierre Kuypers a écritÂ :
In article (Dans l'article) <t443k8$ut8$, Didier
wrote (écrivait)Â :
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.

Chacun restant libre de faire ce qu'il veut, bien entendu...
Reste qu'Í défaut de respecter les non-normes sur lesquelles les
partenaires s'alignent, on a peu de chance de voir son équipement de
communication fonctionner correctement.

Ou comme dans le cas cité ici, ou dans tous ces appels téléphoniques
qu'on reçoit avec notre propre numéro comme numéro appelant, par
exemple, ça fonctionne et ça fait n'importe quoi, ou plutÍ´t, comme tu
le dis, ce que chacun veut; mais ça fonctionne, c'est certain ...
même sans respecter.
Didier.

Je sais bien ce qu'est une RFC. Et l'esprit qui prévaut quand on
repecte son correspondant. Tout comme je connais les combines d'un
marchandising éperdu.
Mais, ici, je trouve qu'on est pas loin d'une usurpation d'identité. Je
suis sérieux.
Et, ici, je suis étoné de cette légéreté de pratique de la part du GIE
SESAM-Vitale. Car, quand-même, ce n'est pas un oubi, faut le coder,
aussi succint soit le repiquage de header de l'un Í l'autre, faut coder
la requête. Donc y a un but. Pour les camelots, déjÍ je me pose la
question 'pourquoi'. Pour des organismes para/péri gouvernementaux,
encore plus. Émanant d'un univers tech, tout-Í -fait.
Une fois actée la chose, faut quand même s'interroger sur ses
motivations. C'est tout du moins mon avis. Et sur les moyens de
combattre ce travers: pourquoi permettrais-je qu'un tiers me nomme
Return-path d'un message que je n'ai pas émis. Et qui m'assure que
cette adresse ne sera pas utiisée auprès d'autres correspondants Í
cette même fin ?
Pour le reste c'est simple, ces messages (comme ceux en noreply) sont
junk et destruction directe sans lecture ni chargement. Peut-être
suis-je trop chatouilleux. Ou simplement trop respecteux.
--
... Michel
les petits renardeaux dans la clairière du CTV

Bonjour,

Le message du dimanche 24/04/2022 (cf. <t44cbh$l05$1@gioia.aioe.org> ),
Didier dixit, stipule notammant :

Le 24/04/2022 Í 20:25, Jean-Pierre Kuypers a écritÂ :

In article (Dans l'article) <t443k8$ut8$1@gioia.aioe.org>, Didier
<nospam@invalid.invalid> wrote (écrivait)Â :

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.

Chacun restant libre de faire ce qu'il veut, bien entendu...

Reste qu'Í défaut de respecter les non-normes sur lesquelles les
partenaires s'alignent, on a peu de chance de voir son équipement de
communication fonctionner correctement.

Ou comme dans le cas cité ici, ou dans tous ces appels téléphoniques
qu'on reçoit avec notre propre numéro comme numéro appelant, par
exemple, ça fonctionne et ça fait n'importe quoi, ou plutÍ´t, comme tu
le dis, ce que chacun veut; mais ça fonctionne, c'est certain ...
même sans respecter.
Didier.

Je sais bien ce qu'est une RFC. Et l'esprit qui prévaut quand on
repecte son correspondant. Tout comme je connais les combines d'un
marchandising éperdu.
Mais, ici, je trouve qu'on est pas loin d'une usurpation d'identité. Je
suis sérieux.
Et, ici, je suis étoné de cette légéreté de pratique de la part du GIE
SESAM-Vitale. Car, quand-même, ce n'est pas un oubi, faut le coder,
aussi succint soit le repiquage de header de l'un Í l'autre, faut coder
la requête. Donc y a un but. Pour les camelots, déjÍ je me pose la
question 'pourquoi'. Pour des organismes para/péri gouvernementaux,
encore plus. Émanant d'un univers tech, tout-Í -fait.

Une fois actée la chose, faut quand même s'interroger sur ses
motivations. C'est tout du moins mon avis. Et sur les moyens de
combattre ce travers: pourquoi permettrais-je qu'un tiers me nomme
Return-path d'un message que je n'ai pas émis. Et qui m'assure que
cette adresse ne sera pas utiisée auprès d'autres correspondants Í
cette même fin ?

Pour le reste c'est simple, ces messages (comme ceux en noreply) sont
junk et destruction directe sans lecture ni chargement. Peut-être
suis-je trop chatouilleux. Ou simplement trop respecteux.

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

Vous avez filtré cet utilisateur ! Consultez son message

Bonjour,
Le message du dimanche 24/04/2022 (cf. <t44cbh$l05$ ),
Didier dixit, stipule notammant :

Le 24/04/2022 Í 20:25, Jean-Pierre Kuypers a écritÂ :
In article (Dans l'article) <t443k8$ut8$, Didier
wrote (écrivait)Â :
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.

Chacun restant libre de faire ce qu'il veut, bien entendu...
Reste qu'Í défaut de respecter les non-normes sur lesquelles les
partenaires s'alignent, on a peu de chance de voir son équipement de
communication fonctionner correctement.

Ou comme dans le cas cité ici, ou dans tous ces appels téléphoniques
qu'on reçoit avec notre propre numéro comme numéro appelant, par
exemple, ça fonctionne et ça fait n'importe quoi, ou plutÍ´t, comme tu
le dis, ce que chacun veut; mais ça fonctionne, c'est certain ...
même sans respecter.
Didier.

Je sais bien ce qu'est une RFC. Et l'esprit qui prévaut quand on
repecte son correspondant. Tout comme je connais les combines d'un
marchandising éperdu.
Mais, ici, je trouve qu'on est pas loin d'une usurpation d'identité. Je
suis sérieux.
Et, ici, je suis étoné de cette légéreté de pratique de la part du GIE
SESAM-Vitale. Car, quand-même, ce n'est pas un oubi, faut le coder,
aussi succint soit le repiquage de header de l'un Í l'autre, faut coder
la requête. Donc y a un but. Pour les camelots, déjÍ je me pose la
question 'pourquoi'. Pour des organismes para/péri gouvernementaux,
encore plus. Émanant d'un univers tech, tout-Í -fait.
Une fois actée la chose, faut quand même s'interroger sur ses
motivations. C'est tout du moins mon avis. Et sur les moyens de
combattre ce travers: pourquoi permettrais-je qu'un tiers me nomme
Return-path d'un message que je n'ai pas émis. Et qui m'assure que
cette adresse ne sera pas utiisée auprès d'autres correspondants Í
cette même fin ?
Pour le reste c'est simple, ces messages (comme ceux en noreply) sont
junk et destruction directe sans lecture ni chargement. Peut-être
suis-je trop chatouilleux. Ou simplement trop respecteux.
--
... Michel
les petits renardeaux dans la clairière du CTV

Didier

25/04/2022 à 08:41

Le 25/04/2022 Í 00:25, les renardeaux a écritÂ :

Bonjour,
Le message du dimanche 24/04/2022 (cf. <t44cbh$l05$ ),
Didier dixit, stipule notammant :
Le 24/04/2022 Í 20:25, Jean-Pierre Kuypers a écritÂ :
In article (Dans l'article) <t443k8$ut8$, Didier
wrote (écrivait)Â :
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.

Chacun restant libre de faire ce qu'il veut, bien entendu...
Reste qu'Í défaut de respecter les non-normes sur lesquelles les
partenaires s'alignent, on a peu de chance de voir son équipement de
communication fonctionner correctement.

Ou comme dans le cas cité ici, ou dans tous ces appels téléphoniques
qu'on reçoit avec notre propre numéro comme numéro appelant, par
exemple, ça fonctionne et ça fait n'importe quoi, ou plutÍ´t, comme tu
le dis, ce que chacun veut; mais ça fonctionne, c'est certain ...
même sans respecter.
Didier.

Bjr,

Je sais bien ce qu'est une RFC. Et l'esprit qui prévaut quand on
repecte son correspondant. Tout comme je connais les combines d'un
marchandising éperdu.
Mais, ici, je trouve qu'on est pas loin d'une usurpation d'identité. Je
suis sérieux.
Et, ici, je suis étoné de cette légéreté de pratique de la part du GIE
SESAM-Vitale. Car, quand-même, ce n'est pas un oubi, faut le coder,
aussi succint soit le repiquage de header de l'un Í l'autre, faut coder
la requêteDonc y a un but.

Le but vient peut-être du fait que ce message n'émane peut-être pas d'eux.
Pour les camelots, déjÍ je me pose la

question 'pourquoi'. Pour des organismes para/péri gouvernementaux,
encore plus. Émanant d'un univers tech, tout-Í -fait.

L'univers "tech" n'est peut-être pas plus "pur" que les autres > Pour le
reste c'est simple, ces messages (comme ceux en noreply) sont

junk et destruction directe sans lecture ni chargement. Peut-être
suis-je trop chatouilleux. Ou simplement trop respecteux.

LÍ je te rejoins complètement, j'ai la même réaction.
Didier.

Le 25/04/2022 Í 00:25, les renardeaux a écritÂ :

Bonjour,

Le message du dimanche 24/04/2022 (cf. <t44cbh$l05$1@gioia.aioe.org> ),
Didier dixit, stipule notammant :

Le 24/04/2022 Í 20:25, Jean-Pierre Kuypers a écritÂ :

In article (Dans l'article) <t443k8$ut8$1@gioia.aioe.org>, Didier
<nospam@invalid.invalid> wrote (écrivait)Â :

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.

Chacun restant libre de faire ce qu'il veut, bien entendu...

Reste qu'Í défaut de respecter les non-normes sur lesquelles les
partenaires s'alignent, on a peu de chance de voir son équipement de
communication fonctionner correctement.

Ou comme dans le cas cité ici, ou dans tous ces appels téléphoniques
qu'on reçoit avec notre propre numéro comme numéro appelant, par
exemple, ça fonctionne et ça fait n'importe quoi, ou plutÍ´t, comme tu
le dis, ce que chacun veut; mais ça fonctionne, c'est certain ...
même sans respecter.
Didier.

Bjr,

Je sais bien ce qu'est une RFC. Et l'esprit qui prévaut quand on
repecte son correspondant. Tout comme je connais les combines d'un
marchandising éperdu.
Mais, ici, je trouve qu'on est pas loin d'une usurpation d'identité. Je
suis sérieux.
Et, ici, je suis étoné de cette légéreté de pratique de la part du GIE
SESAM-Vitale. Car, quand-même, ce n'est pas un oubi, faut le coder,
aussi succint soit le repiquage de header de l'un Í l'autre, faut coder
la requêteDonc y a un but.

Le but vient peut-être du fait que ce message n'émane peut-être pas d'eux.
Pour les camelots, déjÍ je me pose la

question 'pourquoi'. Pour des organismes para/péri gouvernementaux,
encore plus. Émanant d'un univers tech, tout-Í -fait.

L'univers "tech" n'est peut-être pas plus "pur" que les autres > Pour le
reste c'est simple, ces messages (comme ceux en noreply) sont

junk et destruction directe sans lecture ni chargement. Peut-être
suis-je trop chatouilleux. Ou simplement trop respecteux.

LÍ je te rejoins complètement, j'ai la même réaction.
Didier.

Vous avez filtré cet utilisateur ! Consultez son message

Le 25/04/2022 Í 00:25, les renardeaux a écritÂ :

Bonjour,
Le message du dimanche 24/04/2022 (cf. <t44cbh$l05$ ),
Didier dixit, stipule notammant :
Le 24/04/2022 Í 20:25, Jean-Pierre Kuypers a écritÂ :
In article (Dans l'article) <t443k8$ut8$, Didier
wrote (écrivait)Â :
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.

Chacun restant libre de faire ce qu'il veut, bien entendu...
Reste qu'Í défaut de respecter les non-normes sur lesquelles les
partenaires s'alignent, on a peu de chance de voir son équipement de
communication fonctionner correctement.

Ou comme dans le cas cité ici, ou dans tous ces appels téléphoniques
qu'on reçoit avec notre propre numéro comme numéro appelant, par
exemple, ça fonctionne et ça fait n'importe quoi, ou plutÍ´t, comme tu
le dis, ce que chacun veut; mais ça fonctionne, c'est certain ...
même sans respecter.
Didier.

Bjr,

Je sais bien ce qu'est une RFC. Et l'esprit qui prévaut quand on
repecte son correspondant. Tout comme je connais les combines d'un
marchandising éperdu.
Mais, ici, je trouve qu'on est pas loin d'une usurpation d'identité. Je
suis sérieux.
Et, ici, je suis étoné de cette légéreté de pratique de la part du GIE
SESAM-Vitale. Car, quand-même, ce n'est pas un oubi, faut le coder,
aussi succint soit le repiquage de header de l'un Í l'autre, faut coder
la requêteDonc y a un but.

Le but vient peut-être du fait que ce message n'émane peut-être pas d'eux.
Pour les camelots, déjÍ je me pose la

question 'pourquoi'. Pour des organismes para/péri gouvernementaux,
encore plus. Émanant d'un univers tech, tout-Í -fait.

L'univers "tech" n'est peut-être pas plus "pur" que les autres > Pour le
reste c'est simple, ces messages (comme ceux en noreply) sont

junk et destruction directe sans lecture ni chargement. Peut-être
suis-je trop chatouilleux. Ou simplement trop respecteux.

LÍ je te rejoins complètement, j'ai la même réaction.
Didier.

Jean-Pierre Kuypers

25/04/2022 à 09:34

In article (Dans l'article) <62655b0d$0$22068$,
les renardeaux wrote (écrivait)Â :

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 (et je ne suis pas chez Discord)
[To]
[Return-path]
...
et, lÍ c'est nettement plus curieux, de services censés être
technico-compatibles, exemple:
[From] GIE SESAM-Vitale
[To]
[Return-path]

L'exposé de l'en-tête complet permettrait de mieux se rendre compte
d'oÍ¹ vient le message et par oÍ¹ il est passé.
Par ailleurs, les inondeurs ont en effet tout intérêt Í ce qu'on ne
vienne pas les embarrasser avec les flopées de messages non distribués
parce que l'adresse du destinataire est incorrecte. Non maisÂ !
--
Jean-Pierre Kuypers

Marc SCHAEFER

25/04/2022 à 10:11

Didier wrote:

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.

Il faut toutefois savoir que les RFC peuvent être sélectionnés pour
passer par un cycle normatif: draft standard, proposed standard,
Internet standard (les 2 derniers ont été de mémoire fusionnés).
Mais Í un temps t, il se peut que le standard date pas mal, et qu'il
faille, si l'on veut implémenter quelque chose de correct, tenir compte
de RFC ultérieurs et de draft standards p.ex.
C'est typiquement le cas pour le mail.

les renardeaux

29/04/2022 à 01:06

Bonjour,
Le message du lundi 25/04/2022 (cf.
<250420220934581784% ), Jean-Pierre Kuypers
dixit, stipule notammant :

L'exposé de l'en-tête complet permettrait de mieux se rendre compte
d'oÍ¹ vient le message et par oÍ¹ il est passé.
Par ailleurs, les inondeurs ont en effet tout intérêt Í ce qu'on ne
vienne pas les embarrasser avec les flopées de messages non
distribués parce que l'adresse du destinataire est incorrecte. Non
maisÂ !

Désolé pour le temps de réponse.
L'en-tête complet, donc.
Je pense que tu as eu trouvé la réponse.
Pour ce message est d'abord envoyé Í une anncienne adresse chez wanadoo
qui redirige directement chez infomaniak.
Et je crains que ce soit la direction qui implémente ce return path...
Merci merci. Et honte sur moi. Je suis trop Í cran en ce moment.
--[Message ID
]--
Return-Path:
Delivered-To:
Received: from smtp-3-9003.mail.infomaniak.ch ([10.4.36.133])
by mda-2-0047.mail.infomaniak.ch with LMTP
id iPQYFRyfTmLSiAUAwdDECw
(envelope-from )
for ; Thu, 07 Apr 2022 10:21:48 +0200
Authentication-Results: mx.infomaniak.com; dmarc=pass (p=none dis=none)
header.from=assurance-maladie.fr
Authentication-Results: mx.infomaniak.com; spf=none
smtp.mailfrom=wanadoo.fr
Received: from smtp.smtpout.orange.fr (smtp01.smtpout.orange.fr
[80.12.242.123])
by smtp-3-9003.mail.infomaniak.ch (Postfix) with ESMTPS id
4KYvVh01CyzlkNTS
for ; Thu, 7 Apr 2022 10:21:47 +0200 (CEST)
Authentication-Results: mx.infomaniak.com;
dkim=pass (2048-bit key; unprotected)
header.d=assurance-maladie.fr header.i=@assurance-maladie.fr
header.b="SssL5gLk";
dkim-atps=neutral
Received: from opme11d3b16aub.idf.fr.intraorange ([10.99.73.6])
by smtp.orange.fr with ESMTP
id cNOlnLZxAiqKccNOlntmqT; Thu, 07 Apr 2022 10:21:47 +0200
X-ME-Helo: opme11d3b16aub.idf.fr.intraorange
X-ME-Date: Thu, 07 Apr 2022 10:21:47 +0200
X-ME-IP: 10.99.73.6
X-Sieve: Pigeonhole Sieve 0.5.14 (1b5c82b2)
X-Sieve-Redirected-From:
Received: from opme11d3d04aub.idf.fr.intraorange ([10.79.3.107])
by opme11d3b16aub.idf.fr.intraorange with LMTP
id OCUIGBufTmKMNwAAHEYXmg
(envelope-from
); Thu, 07 Apr
2022 10:21:47 +0200
Received: from opme11ppr01aub.idf.fr.intraorange ([10.79.3.107])
by opme11d3d04aub.idf.fr.intraorange with LMTP
id wJPkFxufTmLSGgAAjMarew
(envelope-from
)
for <MELOFR-200-5aCT1a0RmZt446SalY6A169cRBD2LXMRnOh4x7BincM=>;
Thu, 07 Apr 2022 10:21:47 +0200
Received: from opmta1mti42nd1 ([10.79.3.107])
by opme11ppr01aub.idf.fr.intraorange with LMTP
id QPxgFxufTmIIGwAAmR1C9Q
(envelope-from
)
for ; Thu, 07 Apr 2022 10:21:47 +0200
Received: from smtpapp1.assurance-maladie.fr ([93.174.145.54])
by smtp.orange.fr with ESMTP
id cNOjn4Yf8VbMZcNOlnIWW2; Thu, 07 Apr 2022 10:21:47 +0200
X-bcc:
X-ME-engine: default
X-me-spamcause:
(0)(0000)gggruggvucftvghtrhhoucdtuddrgedvvddrudejkedgtdefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuoffgpdggtffipffknecuuegrihhlohhuthemucehtddtnecunecujfgurhepvffuhfhrggfkffgtgfesthektddttddtjeenucfhrhhomhepfdfihffuucevrfetofcujfetfgfvgfdqggfkgffppffguchvihgrucfrgffvtfetrdgrshhsuhhrrghntggvqdhmrghlrgguihgvrdhfrhdfuceofghrghgvnhgtvgdqfghkrhgrihhnvgdqvehprghmqdfjrghuthgvqdggihgvnhhnvgesrghsshhurhgrnhgtvgdqmhgrlhgrughivgdrfhhrqeenucggtffrrghtthgvrhhnpeffveeljeekheevgefftdekkeevvdefueduveethfffudejjefgfeeiueefkeelgeenucffohhmrghinheprghsshhurhgrnhgtvgdqmhgrlhgrughivgdrfhhrnecukfhppeelfedrudejgedrudeghedrheegnecuvehluhhsthgvrhfuihiivgepfeenucfrrghrrghmpehhvghlohepshhmthhprghpphdurdgrshhsuhhrrghntggvqdhmrghlrgguihgvrdhfrhdpihhnvghtpeelfedrudejgedrudeghedrheegpdhmrghilhhfrhhomhepuhhrghgvnhgtvgdquhhkrhgrihhnvgdqtghprghmqdhhrghuthgvqdhvihgvnhhnvgesrghsshhurhgrnhgtvgdqmhgrlhgrughivgdrfhhrpdhrtghpthhtoheprgdrihdrlhesfigrnhgrughoohdrfhhrpdhnsggprhgtphhtthhopedu
X-me-spamlevel: not-spam
Received: from assurance-maladie.fr (150001lb72paout3.cen.cnamts.fr
[127.0.0.1])
by 150001lb72paout3.cen.cnamts.fr (8.16.1.2/8.16.1.2) with SMTP
id 2377WNkW001371
for ; Thu, 7 Apr 2022 09:33:40 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=assurance-maladie.fr; h=to :
subject : from : reply-to : mime-version : message-id : date :
content-type : content-transfer-encoding; s=mail0;
bh=fMaD477BwRlD4gglao+2QRSk75xYxtoGEGmBkyHPRlg=;
b=SssL5gLkm43nuOxyO+jTBxY7zIt08RlKlDiAvPV0W3KDAZGj0n9B9O+uDTJZE2oFx73+
8pZnB4nsf7PSN8OIYyKWJVvul56NfuPgCTRFA5x0ZeM8dihjpkqZZxi3AbMQpheLsl7Z
Ah7tnfaPXdAJGQbMOc5WCiNlEMYELTCqZuseCAfGsy9CSdi7rVFsu/zjQWsUQioBtTKt
gwcjY4SxyBH8M9YVyCMD62oOPhBrDoB3E3ipO1vCRCTuYWwSGBORHQs3f9qkzkeByd3z
Exj3aV4jiU8Sjiiaob/+VN7Gsi/NvSDFwItWgvdEKdNOJ0OTn9g8dLLve2SjrJClaxCG
Og=Received: from 150001lb75paap1.osi.cnamts.fr ([10.244.64.150])
by 150001lb72paout3.cen.cnamts.fr with ESMTP id 3f8xfr083h-1
(version=TLSv1.2 cipherÍ¬DHE-RSA-AES256-GCM-SHA384 bits%6
verify=NOT)
for ; Thu, 07 Apr 2022 09:33:39 +0200
Received: from petra.assurance-maladie.fr ([10.225.112.90])
(authenticated bits=0)
by 150001lb75paap1.osi.cnamts.fr (8.16.1.2/8.16.1.2) with
ESMTPSA id 2377XcFB023314
(version=TLSv1.2 cipherÍ¬DHE-RSA-AES256-GCM-SHA384 bits%6
verify=NOT)
for ; Thu, 7 Apr 2022 09:33:38 +0200
Received: by petra.assurance-maladie.fr (Postfix, from userid 48)
id D576A601177; Thu, 7 Apr 2022 09:33:38 +0200 (CEST)
To:
Subject: =?UTF-8?B?VUtSQUlORSA6IE1vZGFsaXTDqXMgZCdlbnZvaSBkZSB2b3M=? =?UTF-8?B?IGRlbWFuZGVzIGRlIHJlbWJvdXJzZW1lbnQgZGUgc29pbnM=?From: "GFS CPAM HAUTE-VIENNE via PETRA.assurance-maladie.fr"
Reply-To:
MIME-Version: 1.0
Content-Transfert-Encoding: 8bit
Message-Id:
Date: Thu, 7 Apr 2022 09:33:38 +0200 (CEST)
X-Proofpoint-ORIG-GUID: MzxOm8Hg6CGg-w9yjqzUhgLR47WGymqb
X-Proofpoint-GUID: MzxOm8Hg6CGg-w9yjqzUhgLR47WGymqb
X-Proofpoint-Virus-Version: vendor=fsecure
engine=2.50.10434:6.0.425,18.0.850
definitions 22-04-06_13:2022-04-06,2022-04-06 signatures=0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Authentication-Results: mx.infomaniak.com; spf=none
smtp.mailfrom=
X-Infomaniak-Spam: ham
X-Infomaniak-Type: ham
X-Spam-Score: -10
X-Spam-Detail:
gggruggvucftvghtrhhoucdtuddrgedvvddrudejkedgtdefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecukffphffqofetpffktefmnecuuegrihhlohhuthemucfpsdetnecujfgrmhfjvggruggvrhfhihgvlhguucfjvggruggvrhcuufgtohhrihhnghculddquddtmdenucfjughrpefvuffhrhggkffftgfgsehtkedttddttdejnecuhfhrohhmpedfiffhufcuvefrtefoucfjtegfvffgqdggkffgpffpgfcuvhhirgcurffgvffttedrrghsshhurhgrnhgtvgdqmhgrlhgrughivgdrfhhrfdcuoegfrhhgvghntggvqdgfkhhrrghinhgvqdevphgrmhdqjfgruhhtvgdqgghivghnnhgvsegrshhsuhhrrghntggvqdhmrghlrgguihgvrdhfrheqnecuggftrfgrthhtvghrnhepffevleejkeehveegffdtkeekvedvfeeuudevtefhffdujeejgfefieeufeekleegnecuffhomhgrihhnpegrshhsuhhrrghntggvqdhmrghlrgguihgvrdhfrhenucfkphepkedtrdduvddrvdegvddruddvfedpuddtrdelledrjeefrdeipdelfedrudejgedrudeghedrheegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepkedtrdduvddrvdegvddruddvfedphhgvlhhopehsmhhtphdrshhmthhpohhuthdrohhrrghnghgvrdhfrhdpmhgrihhlfhhrohhmpegrrdhirdhlseifrghnrgguohhordhfrhdpnhgspghrtghpthhtohepuddprhgtphhtthhopegrihhlsegrihhlrdgtthhvrdi
iohhnvgdpshhpfhepnhhonhgvpdgukhhimhepphgrshhs
X-Infomaniak-Cause:
gAAAAABiTp8c8Is-sVTF-Sp_zr2MHWRiocZF7djlrajNI9zh27UaGQyk9oeZXgjTFzFRfxSzZ4SN5QabsPbrBpYGCIySDi1_X3FSw0gF0N-8yBdhDF2lMSEEY9BRh4KYm_75ImFT7bwitKYnGeoNrmo-z8HEpooZaWlpDJfUz7HX2rcji5kKZfVKcjJwjQHaWJXTgLDSK_0Eb-svh03m2Kc_jlLxruiV3WpJPuTZpKkXN8utjfY3SDz14_Xd_23ZBGTsmLGd6FovMRVENMK5VDcMlemYFQ4yQeIQniaMBYrXOQJEzsmV1AD9i067JkXdO4Uzu1uvrYd0QE-oH59ubqOR--GM3AZu4J1F_2O7_1fyDC-rtaiRZuM-<[/Message
ID]>-
--
... Michel
les petits renardeaux dans la clairière du CTV

Bonjour,

Le message du lundi 25/04/2022 (cf.
<250420220934581784%Kuypers@address.invalid> ), Jean-Pierre Kuypers
dixit, stipule notammant :

L'exposé de l'en-tête complet permettrait de mieux se rendre compte
d'oÍ¹ vient le message et par oÍ¹ il est passé.

Par ailleurs, les inondeurs ont en effet tout intérêt Í ce qu'on ne
vienne pas les embarrasser avec les flopées de messages non
distribués parce que l'adresse du destinataire est incorrecte. Non
maisÂ !

Désolé pour le temps de réponse.

L'en-tête complet, donc.

Je pense que tu as eu trouvé la réponse.

Pour ce message est d'abord envoyé Í une anncienne adresse chez wanadoo
qui redirige directement chez infomaniak.
Et je crains que ce soit la direction qui implémente ce return path...
Merci merci. Et honte sur moi. Je suis trop Í cran en ce moment.
--[Message ID
<20220407073338.D576A601177@petra.assurance-maladie.fr>]--
Return-Path: <a.i.l@wanadoo.fr>
Delivered-To: ail@ail.ctv.zone
Received: from smtp-3-9003.mail.infomaniak.ch ([10.4.36.133])
by mda-2-0047.mail.infomaniak.ch with LMTP
id iPQYFRyfTmLSiAUAwdDECw
(envelope-from <a.i.l@wanadoo.fr>)
for <ail@ail.ctv.zone>; Thu, 07 Apr 2022 10:21:48 +0200
Authentication-Results: mx.infomaniak.com; dmarc=pass (p=none dis=none)
header.from=assurance-maladie.fr
Authentication-Results: mx.infomaniak.com; spf=none
smtp.mailfrom=wanadoo.fr
Received: from smtp.smtpout.orange.fr (smtp01.smtpout.orange.fr
[80.12.242.123])
by smtp-3-9003.mail.infomaniak.ch (Postfix) with ESMTPS id
4KYvVh01CyzlkNTS
for <ail@ail.ctv.zone>; Thu, 7 Apr 2022 10:21:47 +0200 (CEST)
Authentication-Results: mx.infomaniak.com;
dkim=pass (2048-bit key; unprotected)
header.d=assurance-maladie.fr header.i=@assurance-maladie.fr
header.b="SssL5gLk";
dkim-atps=neutral
Received: from opme11d3b16aub.idf.fr.intraorange ([10.99.73.6])
by smtp.orange.fr with ESMTP
id cNOlnLZxAiqKccNOlntmqT; Thu, 07 Apr 2022 10:21:47 +0200
X-ME-Helo: opme11d3b16aub.idf.fr.intraorange
X-ME-Date: Thu, 07 Apr 2022 10:21:47 +0200
X-ME-IP: 10.99.73.6
X-Sieve: Pigeonhole Sieve 0.5.14 (1b5c82b2)
X-Sieve-Redirected-From: a.i.l@wanadoo.fr
Received: from opme11d3d04aub.idf.fr.intraorange ([10.79.3.107])
by opme11d3b16aub.idf.fr.intraorange with LMTP
id OCUIGBufTmKMNwAAHEYXmg
(envelope-from
<urgence-ukraine-cpam-haute-vienne@assurance-maladie.fr>); Thu, 07 Apr
2022 10:21:47 +0200
Received: from opme11ppr01aub.idf.fr.intraorange ([10.79.3.107])
by opme11d3d04aub.idf.fr.intraorange with LMTP
id wJPkFxufTmLSGgAAjMarew
(envelope-from
<urgence-ukraine-cpam-haute-vienne@assurance-maladie.fr>)
for <MELOFR-200-5aCT1a0RmZt446SalY6A169cRBD2LXMRnOh4x7BincM=>;
Thu, 07 Apr 2022 10:21:47 +0200
Received: from opmta1mti42nd1 ([10.79.3.107])
by opme11ppr01aub.idf.fr.intraorange with LMTP
id QPxgFxufTmIIGwAAmR1C9Q
(envelope-from
<urgence-ukraine-cpam-haute-vienne@assurance-maladie.fr>)
for <a.i.l@wanadoo.fr>; Thu, 07 Apr 2022 10:21:47 +0200
Received: from smtpapp1.assurance-maladie.fr ([93.174.145.54])
by smtp.orange.fr with ESMTP
id cNOjn4Yf8VbMZcNOlnIWW2; Thu, 07 Apr 2022 10:21:47 +0200
X-bcc: a.i.l@wanadoo.fr
X-ME-engine: default
X-me-spamcause:
(0)(0000)gggruggvucftvghtrhhoucdtuddrgedvvddrudejkedgtdefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuoffgpdggtffipffknecuuegrihhlohhuthemucehtddtnecunecujfgurhepvffuhfhrggfkffgtgfesthektddttddtjeenucfhrhhomhepfdfihffuucevrfetofcujfetfgfvgfdqggfkgffppffguchvihgrucfrgffvtfetrdgrshhsuhhrrghntggvqdhmrghlrgguihgvrdhfrhdfuceofghrghgvnhgtvgdqfghkrhgrihhnvgdqvehprghmqdfjrghuthgvqdggihgvnhhnvgesrghsshhurhgrnhgtvgdqmhgrlhgrughivgdrfhhrqeenucggtffrrghtthgvrhhnpeffveeljeekheevgefftdekkeevvdefueduveethfffudejjefgfeeiueefkeelgeenucffohhmrghinheprghsshhurhgrnhgtvgdqmhgrlhgrughivgdrfhhrnecukfhppeelfedrudejgedrudeghedrheegnecuvehluhhsthgvrhfuihiivgepfeenucfrrghrrghmpehhvghlohepshhmthhprghpphdurdgrshhsuhhrrghntggvqdhmrghlrgguihgvrdhfrhdpihhnvghtpeelfedrudejgedrudeghedrheegpdhmrghilhhfrhhomhepuhhrghgvnhgtvgdquhhkrhgrihhnvgdqtghprghmqdhhrghuthgvqdhvihgvnhhnvgesrghsshhurhgrnhgtvgdqmhgrlhgrughivgdrfhhrpdhrtghpthhtoheprgdrihdrlhesfigrnhgrughoohdrfhhrpdhnsggprhgtphhtthhopedu
X-me-spamlevel: not-spam
Received: from assurance-maladie.fr (150001lb72paout3.cen.cnamts.fr
[127.0.0.1])
by 150001lb72paout3.cen.cnamts.fr (8.16.1.2/8.16.1.2) with SMTP
id 2377WNkW001371
for <a.i.l@wanadoo.fr>; Thu, 7 Apr 2022 09:33:40 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=assurance-maladie.fr; h=to :
subject : from : reply-to : mime-version : message-id : date :
content-type : content-transfer-encoding; s=mail0;
bh=fMaD477BwRlD4gglao+2QRSk75xYxtoGEGmBkyHPRlg=;
b=SssL5gLkm43nuOxyO+jTBxY7zIt08RlKlDiAvPV0W3KDAZGj0n9B9O+uDTJZE2oFx73+
8pZnB4nsf7PSN8OIYyKWJVvul56NfuPgCTRFA5x0ZeM8dihjpkqZZxi3AbMQpheLsl7Z
Ah7tnfaPXdAJGQbMOc5WCiNlEMYELTCqZuseCAfGsy9CSdi7rVFsu/zjQWsUQioBtTKt
gwcjY4SxyBH8M9YVyCMD62oOPhBrDoB3E3ipO1vCRCTuYWwSGBORHQs3f9qkzkeByd3z
Exj3aV4jiU8Sjiiaob/+VN7Gsi/NvSDFwItWgvdEKdNOJ0OTn9g8dLLve2SjrJClaxCG
Og=Received: from 150001lb75paap1.osi.cnamts.fr ([10.244.64.150])
by 150001lb72paout3.cen.cnamts.fr with ESMTP id 3f8xfr083h-1
(version=TLSv1.2 cipherÍ¬DHE-RSA-AES256-GCM-SHA384 bits%6
verify=NOT)
for <a.i.l@wanadoo.fr>; Thu, 07 Apr 2022 09:33:39 +0200
Received: from petra.assurance-maladie.fr ([10.225.112.90])
(authenticated bits=0)
by 150001lb75paap1.osi.cnamts.fr (8.16.1.2/8.16.1.2) with
ESMTPSA id 2377XcFB023314
(version=TLSv1.2 cipherÍ¬DHE-RSA-AES256-GCM-SHA384 bits%6
verify=NOT)
for <a.i.l@wanadoo.fr>; Thu, 7 Apr 2022 09:33:38 +0200
Received: by petra.assurance-maladie.fr (Postfix, from userid 48)
id D576A601177; Thu, 7 Apr 2022 09:33:38 +0200 (CEST)
To: a.i.l@wanadoo.fr
Subject: =?UTF-8?B?VUtSQUlORSA6IE1vZGFsaXTDqXMgZCdlbnZvaSBkZSB2b3M=? =?UTF-8?B?IGRlbWFuZGVzIGRlIHJlbWJvdXJzZW1lbnQgZGUgc29pbnM=?From: "GFS CPAM HAUTE-VIENNE via PETRA.assurance-maladie.fr"
<Urgence-Ukraine-Cpam-Haute-Vienne@assurance-maladie.fr>
Reply-To: Urgence-Ukraine-Cpam-Haute-Vienne@assurance-maladie.fr
MIME-Version: 1.0
Content-Transfert-Encoding: 8bit
Message-Id: <20220407073338.D576A601177@petra.assurance-maladie.fr>
Date: Thu, 7 Apr 2022 09:33:38 +0200 (CEST)
X-Proofpoint-ORIG-GUID: MzxOm8Hg6CGg-w9yjqzUhgLR47WGymqb
X-Proofpoint-GUID: MzxOm8Hg6CGg-w9yjqzUhgLR47WGymqb
X-Proofpoint-Virus-Version: vendor=fsecure
engine=2.50.10434:6.0.425,18.0.850
definitions 22-04-06_13:2022-04-06,2022-04-06 signatures=0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Authentication-Results: mx.infomaniak.com; spf=none
smtp.mailfrom=a.i.l@wanadoo.fr
X-Infomaniak-Spam: ham
X-Infomaniak-Type: ham
X-Spam-Score: -10
X-Spam-Detail:
gggruggvucftvghtrhhoucdtuddrgedvvddrudejkedgtdefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecukffphffqofetpffktefmnecuuegrihhlohhuthemucfpsdetnecujfgrmhfjvggruggvrhfhihgvlhguucfjvggruggvrhcuufgtohhrihhnghculddquddtmdenucfjughrpefvuffhrhggkffftgfgsehtkedttddttdejnecuhfhrohhmpedfiffhufcuvefrtefoucfjtegfvffgqdggkffgpffpgfcuvhhirgcurffgvffttedrrghsshhurhgrnhgtvgdqmhgrlhgrughivgdrfhhrfdcuoegfrhhgvghntggvqdgfkhhrrghinhgvqdevphgrmhdqjfgruhhtvgdqgghivghnnhgvsegrshhsuhhrrghntggvqdhmrghlrgguihgvrdhfrheqnecuggftrfgrthhtvghrnhepffevleejkeehveegffdtkeekvedvfeeuudevtefhffdujeejgfefieeufeekleegnecuffhomhgrihhnpegrshhsuhhrrghntggvqdhmrghlrgguihgvrdhfrhenucfkphepkedtrdduvddrvdegvddruddvfedpuddtrdelledrjeefrdeipdelfedrudejgedrudeghedrheegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepkedtrdduvddrvdegvddruddvfedphhgvlhhopehsmhhtphdrshhmthhpohhuthdrohhrrghnghgvrdhfrhdpmhgrihhlfhhrohhmpegrrdhirdhlseifrghnrgguohhordhfrhdpnhgspghrtghpthhtohepuddprhgtphhtthhopegrihhlsegrihhlrdgtthhvrdi
iohhnvgdpshhpfhepnhhonhgvpdgukhhimhepphgrshhs
X-Infomaniak-Cause:
gAAAAABiTp8c8Is-sVTF-Sp_zr2MHWRiocZF7djlrajNI9zh27UaGQyk9oeZXgjTFzFRfxSzZ4SN5QabsPbrBpYGCIySDi1_X3FSw0gF0N-8yBdhDF2lMSEEY9BRh4KYm_75ImFT7bwitKYnGeoNrmo-z8HEpooZaWlpDJfUz7HX2rcji5kKZfVKcjJwjQHaWJXTgLDSK_0Eb-svh03m2Kc_jlLxruiV3WpJPuTZpKkXN8utjfY3SDz14_Xd_23ZBGTsmLGd6FovMRVENMK5VDcMlemYFQ4yQeIQniaMBYrXOQJEzsmV1AD9i067JkXdO4Uzu1uvrYd0QE-oH59ubqOR--GM3AZu4J1F_2O7_1fyDC-rtaiRZuM-<[/Message
ID<20220407073338.D576A601177@petra.assurance-maladie.fr>]>-

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

Vous avez filtré cet utilisateur ! Consultez son message

Bonjour,
Le message du lundi 25/04/2022 (cf.
<250420220934581784% ), Jean-Pierre Kuypers
dixit, stipule notammant :

L'exposé de l'en-tête complet permettrait de mieux se rendre compte
d'oÍ¹ vient le message et par oÍ¹ il est passé.
Par ailleurs, les inondeurs ont en effet tout intérêt Í ce qu'on ne
vienne pas les embarrasser avec les flopées de messages non
distribués parce que l'adresse du destinataire est incorrecte. Non
maisÂ !

Désolé pour le temps de réponse.
L'en-tête complet, donc.
Je pense que tu as eu trouvé la réponse.
Pour ce message est d'abord envoyé Í une anncienne adresse chez wanadoo
qui redirige directement chez infomaniak.
Et je crains que ce soit la direction qui implémente ce return path...
Merci merci. Et honte sur moi. Je suis trop Í cran en ce moment.
--[Message ID
]--
Return-Path:
Delivered-To:
Received: from smtp-3-9003.mail.infomaniak.ch ([10.4.36.133])
by mda-2-0047.mail.infomaniak.ch with LMTP
id iPQYFRyfTmLSiAUAwdDECw
(envelope-from )
for ; Thu, 07 Apr 2022 10:21:48 +0200
Authentication-Results: mx.infomaniak.com; dmarc=pass (p=none dis=none)
header.from=assurance-maladie.fr
Authentication-Results: mx.infomaniak.com; spf=none
smtp.mailfrom=wanadoo.fr
Received: from smtp.smtpout.orange.fr (smtp01.smtpout.orange.fr
[80.12.242.123])
by smtp-3-9003.mail.infomaniak.ch (Postfix) with ESMTPS id
4KYvVh01CyzlkNTS
for ; Thu, 7 Apr 2022 10:21:47 +0200 (CEST)
Authentication-Results: mx.infomaniak.com;
dkim=pass (2048-bit key; unprotected)
header.d=assurance-maladie.fr header.i=@assurance-maladie.fr
header.b="SssL5gLk";
dkim-atps=neutral
Received: from opme11d3b16aub.idf.fr.intraorange ([10.99.73.6])
by smtp.orange.fr with ESMTP
id cNOlnLZxAiqKccNOlntmqT; Thu, 07 Apr 2022 10:21:47 +0200
X-ME-Helo: opme11d3b16aub.idf.fr.intraorange
X-ME-Date: Thu, 07 Apr 2022 10:21:47 +0200
X-ME-IP: 10.99.73.6
X-Sieve: Pigeonhole Sieve 0.5.14 (1b5c82b2)
X-Sieve-Redirected-From:
Received: from opme11d3d04aub.idf.fr.intraorange ([10.79.3.107])
by opme11d3b16aub.idf.fr.intraorange with LMTP
id OCUIGBufTmKMNwAAHEYXmg
(envelope-from
); Thu, 07 Apr
2022 10:21:47 +0200
Received: from opme11ppr01aub.idf.fr.intraorange ([10.79.3.107])
by opme11d3d04aub.idf.fr.intraorange with LMTP
id wJPkFxufTmLSGgAAjMarew
(envelope-from
)
for <MELOFR-200-5aCT1a0RmZt446SalY6A169cRBD2LXMRnOh4x7BincM=>;
Thu, 07 Apr 2022 10:21:47 +0200
Received: from opmta1mti42nd1 ([10.79.3.107])
by opme11ppr01aub.idf.fr.intraorange with LMTP
id QPxgFxufTmIIGwAAmR1C9Q
(envelope-from
)
for ; Thu, 07 Apr 2022 10:21:47 +0200
Received: from smtpapp1.assurance-maladie.fr ([93.174.145.54])
by smtp.orange.fr with ESMTP
id cNOjn4Yf8VbMZcNOlnIWW2; Thu, 07 Apr 2022 10:21:47 +0200
X-bcc:
X-ME-engine: default
X-me-spamcause:
(0)(0000)gggruggvucftvghtrhhoucdtuddrgedvvddrudejkedgtdefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuoffgpdggtffipffknecuuegrihhlohhuthemucehtddtnecunecujfgurhepvffuhfhrggfkffgtgfesthektddttddtjeenucfhrhhomhepfdfihffuucevrfetofcujfetfgfvgfdqggfkgffppffguchvihgrucfrgffvtfetrdgrshhsuhhrrghntggvqdhmrghlrgguihgvrdhfrhdfuceofghrghgvnhgtvgdqfghkrhgrihhnvgdqvehprghmqdfjrghuthgvqdggihgvnhhnvgesrghsshhurhgrnhgtvgdqmhgrlhgrughivgdrfhhrqeenucggtffrrghtthgvrhhnpeffveeljeekheevgefftdekkeevvdefueduveethfffudejjefgfeeiueefkeelgeenucffohhmrghinheprghsshhurhgrnhgtvgdqmhgrlhgrughivgdrfhhrnecukfhppeelfedrudejgedrudeghedrheegnecuvehluhhsthgvrhfuihiivgepfeenucfrrghrrghmpehhvghlohepshhmthhprghpphdurdgrshhsuhhrrghntggvqdhmrghlrgguihgvrdhfrhdpihhnvghtpeelfedrudejgedrudeghedrheegpdhmrghilhhfrhhomhepuhhrghgvnhgtvgdquhhkrhgrihhnvgdqtghprghmqdhhrghuthgvqdhvihgvnhhnvgesrghsshhurhgrnhgtvgdqmhgrlhgrughivgdrfhhrpdhrtghpthhtoheprgdrihdrlhesfigrnhgrughoohdrfhhrpdhnsggprhgtphhtthhopedu
X-me-spamlevel: not-spam
Received: from assurance-maladie.fr (150001lb72paout3.cen.cnamts.fr
[127.0.0.1])
by 150001lb72paout3.cen.cnamts.fr (8.16.1.2/8.16.1.2) with SMTP
id 2377WNkW001371
for ; Thu, 7 Apr 2022 09:33:40 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=assurance-maladie.fr; h=to :
subject : from : reply-to : mime-version : message-id : date :
content-type : content-transfer-encoding; s=mail0;
bh=fMaD477BwRlD4gglao+2QRSk75xYxtoGEGmBkyHPRlg=;
b=SssL5gLkm43nuOxyO+jTBxY7zIt08RlKlDiAvPV0W3KDAZGj0n9B9O+uDTJZE2oFx73+
8pZnB4nsf7PSN8OIYyKWJVvul56NfuPgCTRFA5x0ZeM8dihjpkqZZxi3AbMQpheLsl7Z
Ah7tnfaPXdAJGQbMOc5WCiNlEMYELTCqZuseCAfGsy9CSdi7rVFsu/zjQWsUQioBtTKt
gwcjY4SxyBH8M9YVyCMD62oOPhBrDoB3E3ipO1vCRCTuYWwSGBORHQs3f9qkzkeByd3z
Exj3aV4jiU8Sjiiaob/+VN7Gsi/NvSDFwItWgvdEKdNOJ0OTn9g8dLLve2SjrJClaxCG
Og=Received: from 150001lb75paap1.osi.cnamts.fr ([10.244.64.150])
by 150001lb72paout3.cen.cnamts.fr with ESMTP id 3f8xfr083h-1
(version=TLSv1.2 cipherÍ¬DHE-RSA-AES256-GCM-SHA384 bits%6
verify=NOT)
for ; Thu, 07 Apr 2022 09:33:39 +0200
Received: from petra.assurance-maladie.fr ([10.225.112.90])
(authenticated bits=0)
by 150001lb75paap1.osi.cnamts.fr (8.16.1.2/8.16.1.2) with
ESMTPSA id 2377XcFB023314
(version=TLSv1.2 cipherÍ¬DHE-RSA-AES256-GCM-SHA384 bits%6
verify=NOT)
for ; Thu, 7 Apr 2022 09:33:38 +0200
Received: by petra.assurance-maladie.fr (Postfix, from userid 48)
id D576A601177; Thu, 7 Apr 2022 09:33:38 +0200 (CEST)
To:
Subject: =?UTF-8?B?VUtSQUlORSA6IE1vZGFsaXTDqXMgZCdlbnZvaSBkZSB2b3M=? =?UTF-8?B?IGRlbWFuZGVzIGRlIHJlbWJvdXJzZW1lbnQgZGUgc29pbnM=?From: "GFS CPAM HAUTE-VIENNE via PETRA.assurance-maladie.fr"
Reply-To:
MIME-Version: 1.0
Content-Transfert-Encoding: 8bit
Message-Id:
Date: Thu, 7 Apr 2022 09:33:38 +0200 (CEST)
X-Proofpoint-ORIG-GUID: MzxOm8Hg6CGg-w9yjqzUhgLR47WGymqb
X-Proofpoint-GUID: MzxOm8Hg6CGg-w9yjqzUhgLR47WGymqb
X-Proofpoint-Virus-Version: vendor=fsecure
engine=2.50.10434:6.0.425,18.0.850
definitions 22-04-06_13:2022-04-06,2022-04-06 signatures=0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Authentication-Results: mx.infomaniak.com; spf=none
smtp.mailfrom=
X-Infomaniak-Spam: ham
X-Infomaniak-Type: ham
X-Spam-Score: -10
X-Spam-Detail:
gggruggvucftvghtrhhoucdtuddrgedvvddrudejkedgtdefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecukffphffqofetpffktefmnecuuegrihhlohhuthemucfpsdetnecujfgrmhfjvggruggvrhfhihgvlhguucfjvggruggvrhcuufgtohhrihhnghculddquddtmdenucfjughrpefvuffhrhggkffftgfgsehtkedttddttdejnecuhfhrohhmpedfiffhufcuvefrtefoucfjtegfvffgqdggkffgpffpgfcuvhhirgcurffgvffttedrrghsshhurhgrnhgtvgdqmhgrlhgrughivgdrfhhrfdcuoegfrhhgvghntggvqdgfkhhrrghinhgvqdevphgrmhdqjfgruhhtvgdqgghivghnnhgvsegrshhsuhhrrghntggvqdhmrghlrgguihgvrdhfrheqnecuggftrfgrthhtvghrnhepffevleejkeehveegffdtkeekvedvfeeuudevtefhffdujeejgfefieeufeekleegnecuffhomhgrihhnpegrshhsuhhrrghntggvqdhmrghlrgguihgvrdhfrhenucfkphepkedtrdduvddrvdegvddruddvfedpuddtrdelledrjeefrdeipdelfedrudejgedrudeghedrheegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepkedtrdduvddrvdegvddruddvfedphhgvlhhopehsmhhtphdrshhmthhpohhuthdrohhrrghnghgvrdhfrhdpmhgrihhlfhhrohhmpegrrdhirdhlseifrghnrgguohhordhfrhdpnhgspghrtghpthhtohepuddprhgtphhtthhopegrihhlsegrihhlrdgtthhvrdi
iohhnvgdpshhpfhepnhhonhgvpdgukhhimhepphgrshhs
X-Infomaniak-Cause:
gAAAAABiTp8c8Is-sVTF-Sp_zr2MHWRiocZF7djlrajNI9zh27UaGQyk9oeZXgjTFzFRfxSzZ4SN5QabsPbrBpYGCIySDi1_X3FSw0gF0N-8yBdhDF2lMSEEY9BRh4KYm_75ImFT7bwitKYnGeoNrmo-z8HEpooZaWlpDJfUz7HX2rcji5kKZfVKcjJwjQHaWJXTgLDSK_0Eb-svh03m2Kc_jlLxruiV3WpJPuTZpKkXN8utjfY3SDz14_Xd_23ZBGTsmLGd6FovMRVENMK5VDcMlemYFQ4yQeIQniaMBYrXOQJEzsmV1AD9i067JkXdO4Uzu1uvrYd0QE-oH59ubqOR--GM3AZu4J1F_2O7_1fyDC-rtaiRZuM-<[/Message
ID]>-
--
... Michel
les petits renardeaux dans la clairière du CTV

Matt

29/04/2022 à 11:30

On lun. 25 avril 2022 (00:25),
les renardeaux wrote:

Une fois actée la chose, faut quand même s'interroger sur ses
motivations. C'est tout du moins mon avis. Et sur les moyens de
combattre ce travers: pourquoi permettrais-je qu'un tiers me nomme
Return-path d'un message que je n'ai pas émis. Et qui m'assure que
cette adresse ne sera pas utiisée auprès d'autres correspondants Í
cette même fin ?

C'est ici qu'intervient SPF. Malheureusement trop peu usité ou mal
paramétré (dans le cas de Wanadoo par exemple avec un « qualifier »
neutre) par les prestataires de messagerie électronique des FAI.
--
<lea06> je suis tellement naive, tu pourais me faire avaler n'importe quoi
<cch> c'est bon Í savoir ca... :p
<lea06> que veux tu dire ???
* bashfr.org

les renardeaux

29/04/2022 à 20:00

Bonjour,
Le message du vendredi 29/04/2022 (cf. <t4gb7q$cj5$ ),
Matt dixit, stipule notammant :

C'est ici qu'intervient SPF. Malheureusement trop peu usité ou mal
paramétré (dans le cas de Wanadoo par exemple avec un « qualifier »
neutre) par les prestataires de messagerie électronique des FAI.

Yes. Bon, wanadoo est un reliquat du bon vieux temps passé. J'ai
conservé quelques vieux anciens contrats 'illico' (cf. les joies du 56K
qui sont désormais gratuits puisqu'ils facturaient Í la conso sur le
cuivre RTC) comme secours et ils servent encore pour des news
commercialles chez des commerces d'avant-garde qui n'ont pas lu la
dernière liste iana et me refuse mon domaine en .zone (si si, y en a.
Et pas qu'un)
Sinon, hébergé chez infomaniak, j'ai SPF, dkim et DMARC qui vont bien.
Bon, j'ai mon serveur SMTP sur un serveur dans mes locaux mais bon,
c'est une autre histoire...
--
... Michel
les petits renardeaux dans la clairière du CTV

Return-path

10 réponses

Veuillez sélectionner un problème