info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Return-path
15 views
Skip to first unread message
les renardeaux
Apr 24, 2022, 10:13:34 AM4/24/22
to
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 <nor...@discord.com> (et je ne suis pas chez Discord)
[To] les.ren...@wanadoo.fr
[Return-path] les.ren...@wanadoo.fr
...
et, là c'est nettement plus curieux, de services censés être
technico-compatibles, exemple:
[From] GIE SESAM-Vitale <lettrein...@sesam-vitale.fr>
[To] a....@wanadoo.fr
[Return-path] a....@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
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 <nor...@discord.com> (et je ne suis pas chez Discord)
[To] les.ren...@wanadoo.fr
[Return-path] les.ren...@wanadoo.fr
...
et, là c'est nettement plus curieux, de services censés être
technico-compatibles, exemple:
[From] GIE SESAM-Vitale <lettrein...@sesam-vitale.fr>
[To] a....@wanadoo.fr
[Return-path] a....@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
Didier
Apr 24, 2022, 2:07:07 PM4/24/22
to
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
Apr 24, 2022, 2:25:36 PM4/24/22
to
In article (Dans l'article) <t443k8$ut8$1...@gioia.aioe.org>, Didier
<nos...@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.
--
Jean-Pierre Kuypers
<nos...@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.
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
Apr 24, 2022, 4:36:02 PM4/24/22
to
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
Apr 24, 2022, 6:25:58 PM4/24/22
to
Bonjour,
Le message du dimanche 24/04/2022 (cf. <t44cbh$l05$1...@gioia.aioe.org> ),
Didier dixit, stipule notammant :
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.
Le message du dimanche 24/04/2022 (cf. <t44cbh$l05$1...@gioia.aioe.org> ),
Didier dixit, stipule notammant :
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.
Didier
Apr 25, 2022, 2:41:24 AM4/25/22
to
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
>>> <nos...@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,
> 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
>>> <nos...@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êteDonc y a un but.
> 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
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
> question 'pourquoi'. Pour des organismes para/péri gouvernementaux,
> encore plus. Émanant d'un univers tech, tout-à-fait.
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.
> junk et destruction directe sans lecture ni chargement. Peut-être
> suis-je trop chatouilleux. Ou simplement trop respecteux.
>
Didier.
Jean-Pierre Kuypers
Apr 25, 2022, 3:35:00 AM4/25/22
to
In article (Dans l'article) <62655b0d$0$22068$426a...@news.free.fr>,
les renardeaux <les.ren...@wanadur.grr.invalid> 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 <nor...@discord.com> (et je ne suis pas chez Discord)
> [To] les.ren...@wanadoo.fr
> [Return-path] les.ren...@wanadoo.fr
> ...
>
> et, là c'est nettement plus curieux, de services censés être
> technico-compatibles, exemple:
> [From] GIE SESAM-Vitale <lettrein...@sesam-vitale.fr>
> [To] a....@wanadoo.fr
> [Return-path] a....@wanadoo.fr
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
les renardeaux <les.ren...@wanadur.grr.invalid> 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 <nor...@discord.com> (et je ne suis pas chez Discord)
> [To] les.ren...@wanadoo.fr
> [Return-path] les.ren...@wanadoo.fr
> ...
>
> et, là c'est nettement plus curieux, de services censés être
> technico-compatibles, exemple:
> [From] GIE SESAM-Vitale <lettrein...@sesam-vitale.fr>
> [To] a....@wanadoo.fr
> [Return-path] a....@wanadoo.fr
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
Apr 25, 2022, 4:11:27 AM4/25/22
to
Didier <nos...@invalid.invalid> 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
> 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.
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
Apr 28, 2022, 7:06:54 PM4/28/22
to
Bonjour,
Le message du lundi 25/04/2022 (cf.
<250420220934581784%Kuy...@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
<2022040707333...@petra.assurance-maladie.fr>]--
Return-Path: <a....@wanadoo.fr>
Delivered-To: a...@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....@wanadoo.fr>)
for <a...@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 <a...@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....@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-...@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-...@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-...@assurance-maladie.fr>)
for <a....@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....@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....@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=ECDHE-RSA-AES256-GCM-SHA384 bits=256
verify=NOT)
for <a....@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=ECDHE-RSA-AES256-GCM-SHA384 bits=256
verify=NOT)
for <a....@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....@wanadoo.fr
Subject: =?UTF-8?B?VUtSQUlORSA6IE1vZGFsaXTDqXMgZCdlbnZvaSBkZSB2b3M=?=
=?UTF-8?B?IGRlbWFuZGVzIGRlIHJlbWJvdXJzZW1lbnQgZGUgc29pbnM=?=
From: "GFS CPAM HAUTE-VIENNE via PETRA.assurance-maladie.fr"
<Urgence-Ukraine-...@assurance-maladie.fr>
Reply-To: Urgence-Ukraine-...@assurance-maladie.fr
MIME-Version: 1.0
Content-Transfert-Encoding: 8bit
Message-Id: <2022040707333...@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=2022-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....@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<2022040707333...@petra.assurance-maladie.fr>]>-
Le message du lundi 25/04/2022 (cf.
<250420220934581784%Kuy...@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 !
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
<2022040707333...@petra.assurance-maladie.fr>]--
Return-Path: <a....@wanadoo.fr>
Delivered-To: a...@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....@wanadoo.fr>)
for <a...@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 <a...@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....@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-...@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-...@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-...@assurance-maladie.fr>)
for <a....@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....@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....@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=ECDHE-RSA-AES256-GCM-SHA384 bits=256
verify=NOT)
for <a....@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=ECDHE-RSA-AES256-GCM-SHA384 bits=256
verify=NOT)
for <a....@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....@wanadoo.fr
Subject: =?UTF-8?B?VUtSQUlORSA6IE1vZGFsaXTDqXMgZCdlbnZvaSBkZSB2b3M=?=
=?UTF-8?B?IGRlbWFuZGVzIGRlIHJlbWJvdXJzZW1lbnQgZGUgc29pbnM=?=
From: "GFS CPAM HAUTE-VIENNE via PETRA.assurance-maladie.fr"
<Urgence-Ukraine-...@assurance-maladie.fr>
Reply-To: Urgence-Ukraine-...@assurance-maladie.fr
MIME-Version: 1.0
Content-Transfert-Encoding: 8bit
Message-Id: <2022040707333...@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=2022-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....@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<2022040707333...@petra.assurance-maladie.fr>]>-
les renardeaux
Apr 29, 2022, 2:00:12 PM4/29/22
to
Bonjour,
Le message du vendredi 29/04/2022 (cf. <t4gb7q$cj5$1...@dont-email.me> ),
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...
Le message du vendredi 29/04/2022 (cf. <t4gb7q$cj5$1...@dont-email.me> ),
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...
0 new messages