Marialuisa92
Visiteur
Mes expéditeurs utilise office 365
SGDA
Client Top Contributeur

Dans le cas d'utilisateurs d'ofice 365, ceci peut apporter une aide à la configuration

https://docs.microsoft.com/fr-fr/microsoft-365/security/office-365-security/set-up-spf-in-office-365...

 

Il est encore délicat de savoir à qui revient la faute

SFR trop rigide ou config expediteur trop légère

 

Il serait évidemment utile que SFR communique ses nouvelles exigences (SPF voire DKIM et/ou DMARC)  @pantuoro 

 

 

utilisateur_supprimé
Non applicable

Bonjour,

 

Un de mes clients m'a donné la solution pour nous, nous avions de ligne "spf.protection.outlook.com" dans notre DNS car nous travaillons aussi avec un logiciel de CEGID include:cegid-all.

 

J'espère en avoir aider.


SGDA
Client Top Contributeur

Il existe des outils permettant de tester la validité de la configuration SPF d'un nom de domaine

 

par exemple

 

https://mxtoolbox.com/spf.aspx

 

Ils permettent de connaître celle de sfr.fr

 

v=spf1 ip4:93.17.128.0/24 ip4:198.2.187.67 ip4:52.36.127.248 ip4:86.64.210.3 ip4:86.64.210.5 ip4:86.64.210.19 ip4:86.64.210.79 ip4:86.64.210.153 ip4:86.64.210.154 ip4:195.62.75.16/29 include:mailgun.org include:spf.mailjet.com include:spf1.sfr.fr ?all
SGDA
Client Top Contributeur

On notera que le SPF de SFR  se termine par ?all  et non -all (ou ~all)

 

Ce qui revient à dire que si cela ne correspond pas considérer qu'il n'y a pas de règle

 

utilisateur_supprimé
Non applicable

Nous sommes dans le même cas.

Nos adresses mails sont gérées via Google Admin avec le nom de domaine de notre entreprise. 

Et depuis 4 semaines, nous ne pouvons plus adresser de mails aux boites SFR de nos clients.

 

Quelqu'un aurait-il la réponse sur la configuration à effectuer dans Google Admin pour que les boîtes SFR, Neuf... acceptent les mails de certains noms de domaine.

 

SGDA
Client Top Contributeur

Essayez de suivre les conseils de google

https://support.google.com/a/answer/33786?hl=fr

 

et commencer par tester votre nom de domaine avec

https://toolbox.googleapps.com/apps/checkmx/

jlch1
Visiteur

Bonjour,

Visiblement, la vérification SPF est devenue moins permissive. C'est dommage qu'il n'y ait pas eu de communication de la part de SFR, parce que ça a mis beaucoup de monde "dans le noir".

Simplement, lorsque des "include" sont renseignés dans SPF, ils doivent être encore valides. Parfois on laisse des valeurs historiques de peur d'une régression (ex: prestataire pour mailing). Désormais, SFR teste chaque valeur, et si elle ne contient pas d'élément, refus.

Pour info, même une stratégie DKIM ne prévaut pas.

Jean-Luc Ch.
Lan Explore

SGDA
Client Top Contributeur

Bonjour,

 

Merci de ton post. Ta conclusion rejoint la mienne à savoir que l'application stricte du protocole SPF a révélé les lacunes des configurations des expéditeurs....mais aussi qu'une communication de la part de SFR aurait été très utilie.

 

Il existe actuellement des problèmes entre SFR et yahoo.fr (ou .com) . On peut suspecter là aussi un relèvement de standard de filtrage (arroseur arrosé ?)

 

et en ajoutant DMARC ?  (mais cela necessite que SPF soit accepté)

 

idem pour DKIM qui prouve que les entêtes non pas été modifiées ...mais elles seront ensuite traitées suivant SPF

jlch1
Visiteur

@SGDAoui en effet nous sommes bien d'accord.

Comme tu l'indiques SPF n'est pas non plus un truc hyper sécurisant, bien qu'il protège du gros des attaques non ciblées.

De ce point de vue, ne pas gérer un include qui n'existe plus en sortant une erreur "550 5.7.1 SPF permanent error: " me semble une punition sèvère.

Cela signifie que le jour où un presta de mailing change le FQDN de son include, cela provoque un effet domino. Si le chef marketing vous demande d'ajouter l'include pour tester que sa plate-forme de mailing fonctionne, pas de faute de frappe... avant ça n'avait de conséquences que vis à vis de la plate-forme de maling - ça devient une autre paire de manches. Cela signifie également qu'on devient dépendant de chacun des hébergeur de ces fameux include. Est-ce bien conforme? Je ne sais pas, mais ça m'étonnerait.

 

Le cas qui m'a concerné était une migration vers une messagerie Cloud. La société maintenait son propre include, l'avait gardé "au cas où", bien que vide. Depuis maintenant pas mal d'années, quand on reprend des SPFs, on voit une ribambelle d'include, pas forcément évidents à "nettoyer".

Pour DMARC, j'avoue ne pas avoir testé, et je n'ai rien sous la main pour le faire rapidement (remettre un include bidon, vérifier que ça dysfonctionne, et mettre en place DMARC). En effet ça ne coûte pas grand chose de le mettre en place, surtout lorsque nos deux comparses (SPF & DKIM) ont déjà été activés.

Conclusion: si vous avez des mails chez SFR, vous avez du recevoir nettement moins de pubs, newsletters & co depuis quelques semaines

 

Je viens de jeter un oeil au cas SFR/Yahoo... et ça me semble bien compliqué! pour le coup on n'a pas trop de maîtrise de ce qu'il se passe entre les serveurs SMTP SFR & Yahoo. Je tenterais de sortir en TLS à tout hasard.

Ils ne seraient pas un peu saturés de boulot SFR?!

Comment gagner des badges

Badges En savoir plus