Re: [sympa-fr] Yahoo et politique de contrôle

[Luc Veillon <adresse@cachée>]

Bonjour,

Nous avons rencontré un pb semblable avec 9 domaines dépendant de SFR :

elais

smtp-in.neuf.fr mx.club-internet.fr smtp-in.sfr.fr

Domaine

9online.fr, akeonet.com, cegetel.net, magros.fr, neuf.fr 9business.fr club-internet.fr, sfr.fr
L'utilisation de SPF + DKIM par ces relais a un effet de bord néfaste pour le moteur de listes :
- le point d'entrée du domaine destinataire compare l'enregistrement SPF (dans notre cas de figure) publié par le domaine de l'émetteur avec l'IP/FQDN du relais qui le contacte.
- si la publication des relais que fait le DNS contredit celui qui est réellement utilisé, le courrier est rejeté.

ex. :

94F9450947: from=<adresse@cachée>, size=3774, nrcpt=1 (queue active)

94F9450947: to=<adresse@cachée>, relay=smtp-in.sfr.fr[93.17.128.25], \

delay=1, status=bounced (host smtp-in.sfr.fr[93.17.128.25] said: 554 5.7.1 \

<adresse@cachée>: Sender address rejected: Please%see%\

http://spf.pobox.com/why.html?sender=no-reply%40cndp.fr&ip=194.167.196.131&receiver=msfrf2319 : \

Reason: mechanism (in reply to MAIL FROM command))

Ici, un émetteur du CNDP poste un courrier dans une liste que nous hébergeons.
* Certains abonnés de cette liste n'appartiennent pas à notre domaine, mais à sfr.fr.
* SFR reçoit le courrier depuis notre relais 194.167.196.131.
* Ce relais n'est pas listé dans l'enregistrement du CNDP (à l'époque), qui affirme être exhaustif (option -all) :
$ dig +short TXT cndp.fr
"google-site-verification=vx721obWob7EwQoW_Whyd5_LhcrE5qsTKK80DUk8mG4"
"v=spf1 ip4:194.254.145.192/27 ip4:194.254.145.128/26 ip4:91.103.234.96/27 ip4:91.103.237.96/27 ip4:83.206.237.128/26 -all"
* SFR rejette le courrier.

Pour synthétiser, le pb est latent pour chaque moteur de listes, quand il servira d'intermédiaire entre un émetteur et un destinataire qui ne sont ni l'un ni l'autre dans son domaine de messagerie. Il s'exprimera lorsque deux conditions seront remplies :
- le domaine de l'émetteur aura positionné des flags restrictifs sur la description de ses relais SMTP
- le domaine du destinataire aura positionné des flags sévères sur la lecture de ces indicateurs

Les solutions :
1/ Le destinataire assouplit sa politique. SFR ne reviendra pas en arrière. Je n'ai pas contacté Yahoo, mais je pense qu'ils nous opposeront le même refus. On peut les comprendre, puisqu'il ne font qu'appliquer l'instruction donnée par l'émetteur ("ne fait confiance qu'à ce relais et à aucun autre")
2/ L'émetteur assouplit sa politique. C'est plus facilement négociable (dans notre cas, cela l'a été). Mais cela oblige les gestionnaires de moteurs de listes à examiner leurs logs et à contacter un par un tous les domaines affichant un enregistrement incompatible avec le passage par votre moteur de listes. En pratique, c'est ingérable.
3/ Le domaine du moteur de listes positionne SRS sur sa chaîne d'émission. Ce protocole permet de modifier le domaine d'émission pour le rendre cohérent avec votre relais SMTP tout en conservant la trace de l'émetteur initial. Nousn'y couperons pas avec le déploiement progressif des protocoles de sécurisation des relais émetteurs.

A lire le courrier de David et l'annonce de la sortie de sympa 6.22, j'imagine que c'est une sorte de SRS qui a été implémentée dans cette version ?
Dans ce cas, sympa s'autoprotègera, mais tout autre mécanisme de rediffusion autorisant la transmission entre deux correspondants hors de votre domaine (un helpdesk, une application métier... ) tombera également dans ce piège

Cordialement

Le 06/06/2014 11:09, Magali Bernard a écrit :

adresse@cachée">Est-ce parce que DKIM est mis en place sur vos serveurs ?
À la lecture des différents liens concernant DMARC, c'est une chose qui
ressort, par exemple:
https://sendgrid.zendesk.com/hc/en-us/articles/200182958-Everything-about-DMARC-
"Enter DMARC, "Domain-based Message Authentication, Reporting & Conformance". Which was created to tell a participating receiving server what to do with a message that fails both SPF and DKIM validation. In other words, what to do if a message claims to be from you, but isn't."

De fait, ceux qui mettent ainsi en place DMARC pénalisent en premier lieu... leurs propres utilisateurs.

Bon, on va quand même envisager DKIM, si cela suffit.

-- 
Luc VEILLON
Pôle IH2M Equipe "Hub - Hébergement - Messagerie"
DSI - Rectorat d'Orléans-Tours
10 Rue Molière
45 000 Orléans
Tél: 02 38 79 45 20/ 02 38 79 45 51
Fax: 02 38 79 45 29
Mel : adresse@cachée