[OSM-talk-fr] Désabonnement régulier

[Philippe Verdy]

Il semblerait que les envois par le gestionnaire de cette liste soient
maintenant effectués uniquement en IPv6. Bien que ce serveur le liste soit
correctement déclaré pour SPF (avec son adresse IPv6 délcarée pour le nom
de domaine de la liste), Orange ou Free ne comprennent toujours pas le
protocole SPF en IPv6, mais ne le reconnaissent qu'en IPv4.

Je reçois les messages sur mon compte Google via les connexions du serveur
de liste en IPv6 et ça passe. Je ne sais pas ce qu'il en est des envois par
le serveur de cette liste à d'autres serveurs destinataires SMTP en IPv4:
cette liste semble utiliser une IPv4 mal déclarée en SPF ou DMARC.

Chez Gmail ça passe car DMARC n'est pas utilisé en IPv6. Mais en Ipv4
visiblement les infos DMARC relayées par cette liste sont incorrectes
puisqu'elles concernent l'utilisateur expéditeur initial, et non le serveur
de la liste qui oublie de valider son propre relais en ajoutant ses propres
infos DMARC. De fait quand ça arrive à un autre fournisseur de messagerie,
la connexion est identifiée comme venant de la liste mais avec une
signature DMARC invalide (pas le bon domaine alors que la liste des champs
vérifiés du DMARC initial a été modifiée par la liste sans la recalculer
avec sa propre signature).

C'est bien un bogue de cette liste qui "trafique" les messages qu'elle
relaie sans remettre sa propre signature. De fait cette liste se voit
blacklistée (ou ses messages placés dans les "indésirables" du
destinataire, ce qui est motivée justement par le volume global des
messages émis par cette liste vers les serveurs d'Orange ou de Free, qui ne
peuvent pas s'appuyer sur DMARC, ni SPF, et ne peuvent pas authentifier le
routage suivi: ils appliquent un traitement statistique: cette liste ici
n'est toujours pas conforme et est vue exactement de la même façon qu'un
spammeur falsifiant les entête MIME pour changer l'identité des expédieurts
réels, sans leur permission vérifiable, ni Orange ni Free n'ayant accès aux
données détenues par l'exploitant de cette liste ici).

Gérer des listes de diffusion n'est pas chose aisée. Il semblerait que la
solution soit que cette liste devrait s'appuyer sur les services d'un gros
fournisseur de messagerie reconnu (et s'y connecte alors de manière
authentifiée et sécurisée) pour relayer ses messages ailleurs (vers des
listes de destinataires soit en BCC, soit hébergée sur un carnet d'adresses
stocké chez cet autre gros fournisseur), ou alors mette à jour son logiciel
pour corriger son bogue dans le traitement de DMARC (d'ailleurs Orange ne
reconnait toujours pas SPF même en IPv4, il reconnait juste DMARC mais
chaque relais DOIT correctement en faire le suivi et ajouter un entête
DMARC qu'il doit signer lui-même si un entête DMARC original suit dessous
avec des entêtes modifiés ou un corps de message modifié).

On peut noter que cette liste modifie les corps de messages originaux (qui
sont donc invalidés pour DMARC), simplement pour ajouter le pied du
message, au lieu d'attacher un composant MIME séparé: il n'y a aucun moyen
automatique de savoir que c'est un ajout et où commence cet ajout.

La transformation faire par cette liste n'invalide pas SPF, mais elle
invalide DMARC, comme on le voit ici dans le message de Marc Marc, avec
"dmarc=fail", puis "dkim=neutral (body hash did not verify)", alors que
pour SPF ça passe:

------8><----
Received-SPF: pass (google.com: domain of talk-fr-bounces at openstreetmap.org
designates 2001:41c9:1:400::32 as permitted sender)
client-ip=2001:41c9:1:400::32;
Authentication-Results: mx.google.com;
       dkim=neutral (body hash did not verify) header.i=@mailo.com
header.s=mailo header.b=HwkuQIgm;
       spf=pass (google.com: domain of talk-fr-bounces at openstreetmap.org
designates 2001:41c9:1:400::32 as permitted sender) smtp.mailfrom=
talk-fr-bounces at openstreetmap.org;
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mailo.com
------8><----

SPF parvient à authentifier l'expéditeur ici (il ne vérifie pas le contenu
et ça suffit pour Google parce que SPF authentifie l'expéditeur déjà et que
la liste est par ailleurs correctement inscrite dans son DNS associé et que
Google a autorisé cette liste).

Alors que DMARC essaye d'authentifier le contenu (body)... qui a été
modifié par cette liste. C'est donc interprêté comme une falsification
(DMARC n'est pas capable d'authentifier l'expéditeur séparément du contenu,
il y a une empreinte numérique unique).

Tu peux aussi te plaindre à Orange ou à Free pour n'avoir pas pris en
charge correctement SPF (d'ailleurs les serveurs SMTP d'envoi d'Orange ne
sont toujours pas tous déclarés pour SPF, il en manque plein selon les IP
variables utilisées, c'est un vieux problème connu d'Orange qui traine
depuis plusieurs décennies, car Orange ne sait pas gérer correctement ses
pools d'adresses IP et correctement mettre à jour ses inscriptions DNS et
les sécuriser et authentifier correctement)...

Philippe.


Le lun. 15 mars 2021 à 22:23, Sébastien Dinot <sebastien.dinot at free.fr> a
écrit :

> Jean-Claude Repetto a écrit :
> > Même problème pour moi, j'en ai d'ailleurs déjà parlé ici il
> > y a quelques jours, mais tu n'as évidemment pas reçu mon message !
>
> Exactement. :)
>
> Sébastien
>
> --
> Sébastien Dinot, sebastien.dinot at free.fr
> http://www.palabritudes.net/
> Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>