Bonjour,
nous sommes sur une offre EXCHANGE 2019 PRIVATE.
Aujourd'hui nous nous apercevons que certains de nos clients ne reçoivent plus nos emails. Notamment des personnes chez Yahoo.
Le 15 Mai une mise a jour Exchange a été appliquée sur notre serveur.
Le 16 Mai une personne de notre entreprise découvre qu'elle a 3000 mails qui déboulent dans son Outlook…Exchange lui retourne des mails comme quoi des mails qu'elle aurait envoyé n'ont pas pu être livrés. Donc on a immédiatement changé son mot de passe de messagerie, ce qui a réglé le souci.
Une analyse antivirus du PC n'a rien donné, mais le problème est maintenant résolu vu qu'elle ne reçoit plus ces mails. Elle a du se faire hackée son mot de passe j'imagine.
Donc 2 événements proches, et l'un des deux n'a peut etre aucun rapport avec la situation actuelle qui fait que certains de nos clients ne reçoivent plus nos mails. Mais lequel des deux ??
J'ai passé notre domaine sur https://mxtoolbox.com/blacklists.aspx
1 seul serveur sur les 50 nous remonte comme blacklisté. UCEPROTECTL3. Après quelques recherches sur leur site je vois que ce n'est pas nous qui sommes blacklisté mais OVH, et comme nous sommes chez eux donc on hérite du blacklist.
Bon visiblement on est pas trop mal de ce côté la.
En faisant quelques test d'envoi vers des boites mail yahoo, ca ne passe pas. après quelques minutes on reçoit un code erreur :
> '400 4.4.7 Message delayed'
puis ensuite un autre plus complet :
> 5/17/2023 11:26:40 AM - Server at mx-eu.mail.am0.yahoodns.net (188.125.72.73) returned '451 4.4.395 Target host responded with error. -> 421 4.4.1 Connection timed out'
J'ai essayé de contacter yahoo depuis leur formulaire en ligne ici : https://senders.yahooinc.com/contact/
j'ai fait le Problem delivering emails et aussi Complaint feedback loop
j'ai recu un mail me demandant d'expliquer la situation, le souci c'est que pour y répondre je dois envoyer le mail depuis ma boite pro qui ne peut pas adresser de mail @yahoo…
Le mail que j'ai recu vient de postmastersupport@cc.yahoo.com le domaine n'est pas tout a fait le meme donc peut etre un peu d'espoir…
En parallele j'ai fait quelques recherches sur ces codes d'erreur, et j'ai trouvé ceci qui correspond :
http://nawazblogger.blogspot.com/2020/10/resolved-led451-44395-target-host.html
et il donne même une solution, une commande powershell à exécuter sur le serveur Exchange…donc de notre côté ?? donc peut etre que le patch sur notre serveur serait eventuellement à l'origine du problème ?
Dans le doute j'ai ouvert un ticket OVH.
Vous avez des idées ?
Ce matin plus de problème…
Le support yahoo m'a repondu ceci :
> Thanks for getting back to us.
> I'm sorry for the repeated requests for information but the connection error you're reporting is usually not on our end, but might be network related, so we've been trying to get an error we could help with.
> I passed the information in your case on to our Engineering team to see what we can do to help with delivery anyway.
> When they have an update for us or if they need any further information from you we'll reach out again as soon as possible.
> While we can't give you an estimated time for when our Engineering team will be finished, we encourage you to periodically check to see if the issue has been resolved.
> If you have any other questions or think of any more details that you think might be important, please let us know.
> Regards,
> Bella
> Yahoo Customer Care
Donc ce "blocage" ne semble pas venir d'eux, en tout cas il n'ont pas encore eu le temps d'investiguer que le problème est résolu.
Côté OVH je doute fort qu'une personne se soit déjà penché sur le problème, d'habitude il faut attendre 1 semaine pour avoir le premier message.
Est-ce qu'il n'y aurait pas eu un problème réseau côté OVH ?
12 jours plus tard, quelqu'un s'occupe enfin de mon ticket.
Entre temps j'ai installé DKIM et DMARC sur mon exchange, et suivi les recommendations de configuration. Notamment ce que https://easydmarc.com/ EasyDmarc m'a indiqué de mettre. Pour l'analyse des rapports j'ai créé un compte chez eux.
Aujourd'hui OVH me dit ceci (alors que le problème est résolu) :
> Le conflit d'envoi vient d'une mauvaise configuration du champ SPF de votre domaine. Je vous invite à le corriger et vous joins notre guide :
> https://help.ovhcloud.com/csm/fr-dns-spf-record?id=kb_article_view&sysparm_article=KB0051712
Donc mon SPF est soit disant mal configuré, sans me dire ce qui ne va pas bien entendu…alors que je suis sur et certain qu'il est correct. je l'ai meme testé sur Mxtoolbox :
https://mxtoolbox.com/SuperTool.aspx?action=spf%3ajallatte.fr%3a141.95.128.105&run=toolpage
Le seul truc que je vois mais qui est volontaire de ma part c'est le "**-all" au lieu de "~**all". Mais c'est volontaire car aucune autre source que celles mentionnées dans le SPF n'est sensée envoyer d'email. Donc un REJECT au lieu d'un SOFT FAIL me va bien.
Selon vous qu'est-ce qui pourrait clocher ???
Merci pour votre aide
@janus57 si tu es là 
Bonjour,
comme ça de but en blanc sans connaitre les spécificités des offres exchange de OVH, pour moi le SPF est bon à l'heure actuelle au 29/0/2023 à 21h13 (du moins syntaxiquement valide).
SPF actuel : "v=spf1 a mx a:mail.jallatte.fr ip4:141.95.128.105 ip6:2001:41d0:11b:2f00::8D5F:8069 include:spf.mailjet.com -all"
LA seule chose en trop serait le champ MX, car sauf à avoir pris l'option d'envoi chez MIB c'est inutile car les MX ne font que de la réception (et même avec l'option je dirais que c'est d'autres serveurs qui envois les mails).
Cordialement, janus57
Salut @janus57 merci pour ton retour. j'ai edité mon post au dessus pendant que tu répondais.
Le seul truc que je vois mais qui est volontaire de ma part c'est le "-all" au lieu de "~all". Mais c'est volontaire car aucune autre source que celles mentionnées dans le SPF n'est sensée envoyer d'email. Donc un REJECT au lieu d'un SOFT FAIL me va bien.
Bien vu pour le MX ! je vais le retirer.
Bonjour,
Salut @janus57 merci pour ton retour. j'ai edité mon post au dessus pendant que tu répondais.
sur tout mes SPF je met du -all, car mettre du ~all signifie laisser au serveur réceptionnaire décider s'il fait un rejet ou pas.
Hors le but du SPF est quand même d'être capable de lister la source d’envoi de ces mails et faire un rejet sur tout ce qui est extérieur à nos sources, du coup je vois pas l'intérêt du ~all
Cordialement, janus57
Hors le but du SPF est quand même d'être capable de lister la source d’envoi de ces mails et faire un rejet sur tout ce qui est extérieur à nos sources, du coup je vois pas l'intérêt du ~all
OK, on est bien d'accord.
D'ailleurs je ne comprends pas pourquoi tous les "generateurs de SPF" et les recommendations vont toutes vers un "~all"...
a mx a:mail.jallatte.fr ip4:141.95.128.105 ip6:2001:41d0:11b:2f00::8D5F:8069
OK, on est bien d'accord.
Bonjour,
Strictement il y a encore des trucs superflus/
"a" -> on questionne l'enregistrement A du domaine -> 188.165.223.91
Si ce serveur web envoie des mails sans passer par un relais, alors le "a" a toute sa raison d'être.
> a:mail.jallatte.fr ip4:141.95.128.105 ip6:2001:41d0:11b:2f00::8D5F:8069
L'ip4 et l'ip6 sont redondants avec a:mail.jallatte.fr
Mais ça vaut peut-être mieux de les laisser, au cas où le serveur Exchange Housed est relocalisé à une autre IP, et éviter que ça casse.
tous les "generateurs de SPF" et les recommendations vous toutes vers un "~all"...
Peut-être pour éviter d'endosser la responsabilité de mails perdus ?
Salut @Fritz2cat
"a" -> on questionne l'enregistrement A du domaine -> 188.165.223.91
Si ce serveur web envoie des mails sans passer par un relais, alors le "a" a toute sa raison d'être.
oui je l'ai mis car sur notre serveur web le compte root est susceptible de nous envoyer des mails d'alerte, en direct.
L'ip4 et l'ip6 sont redondants avec a:mail.jallatte.fr
Mais ça vaut peut-être mieux de les laisser, au cas où le serveur Exchange Housed est relocalisé à une autre IP, et éviter que ça casse.
exactement, on a eu droit a une migration il y a quelques mois, avec un changement d'IP de notre serveur Exchange et j'avais ajouté les ip pour éviter des problèmes. Je les ai laissé depuis, ca ne mange pas de pain, même si c'est redondant l'important c'est que ce soit juste. Mais si ca pose un problème effectivement on peut les retirer.
Peut-être pour éviter d'endosser la responsabilité de mails perdus ?
Dans la pratique, il s'agira d'un mail qui ne provient pas de chez nous, donc ca m'arrange que le destinataire ne soit pas polué par ce mail. Dans quel cas il y aurait un avantage à ce qu'il soit délivré ?
WPeut-être pour éviter d'endosser la responsabilité de mails perdus ?
Dans la pratique, il s'agira d'un mail qui ne provient pas de chez nous
Oui ma la différence entre vous et les autres, c'est que vous comprenez ce que vous faites, tandis que d'autres retapent intégralement sans même essayer de piger à quoi ça sert.
Une erreur dans votre SPF et vous allez perdre des mails sortants.
Bon je viens de recevoir un rapport DMARC de Google, que j'ai pasé sur EasyDmarc:
https://easydmarc.com/tools/dmarc-aggregated-reports?domain=jallatte.fr&report_id=15b725f9-a4f8-49fb-b724-ab86f9633c37&rep_id=4764546784380189168
je vois que sur 24 mails provenant de notre serveur mail : 141.95.128.105, il y en a 5 de rejetés…et 3 "forwarded"
Du coup je me demande s'il ne vaut pas mieux passer en "~all" dans le SPF pendant quelques temps pour comprendre ce qu'il se passe.
nouveau message d'ovh, je leur avais demandé "selon vous, qu'est-ce qui ne va pas dans notre SPF ?".
voici la réponse :
> Il vous manque la valeur d'OVHcloud à renseigner dans votre entrée. Je vous joins de nouveau le guide qui contient les indications et la valeur :
> https://help.ovhcloud.com/csm/fr-dns-spf-record?id=kb_article_view&sysparm_article=KB0051712
Hors il se trouve que nous somme avec un Private Exchange.
voici la réponse
mouais, c'est passer sous silence qu'ils ont de l'IPv6, et donc le SPF proposé est incomplet s'il y a des connexions sortantes en IPv6.
Votre serveur Exchange est bien joignable à l'adresse 2001:41d0:11b:2f00::8d5f:8069
~# telnet 2001:41d0:11b:2f00::8d5f:8069 25
Trying 2001:41d0:11b:2f00::8d5f:8069...
Connected to 2001:41d0:11b:2f00::8d5f:8069.
Escape character is '^]'.
220 S1043232.EX3169.lan Microsoft ESMTP MAIL Service ready at Tue, 30 May 2023 18:59:41 +0200
quit
221 2.0.0 Service closing transmission channel
Connection closed by foreign host.
Bon, j'ai plein de soucis encore…visiblement avec les serveurs outlook.com notre SPF ne leur convient pas ?!
https://mxtoolbox.com/Public/Tools/EmailHeaders.aspx?huid=9fa89cf3-97ec-4226-875c-0506c3ea4c94
S1043232.EX3169.lan fe80::f845:f86e:f48:6474 = IS ON BLACKLIST
SPF Alignment : Domain not found in SPF
DKIM Signature Body Hash Verified : Body Hash Did Not Verify
Cymru Bogons Ipv6 = Reason for listing - 8000::/1
Bon, j'ai plein de soucis encore
Bonjour,
Je vois ceci dans le rapport mxtoolbox:
authentication-results spf=pass (sender IP is 141.95.128.105) smtp.mailfrom=jallatte.fr; dkim=pass (signature was verified) header.d=jallatte.fr;dmarc=pass action=none header.from=jallatte.fr;compauth=pass reason=100
1) Votre serveur envoie en ip4 (et non en ip6)
2) le SPF est ok
3) le DKIM est OK.
Vous dites:
fe80::f845:f86e:f48:6474 = IS ON BLACKLIST
pas de souci. fe80:: c'est comme 127.0.0.1 ou localhost, ça fait partie du traitement interne avant que le mail ne sorte sur internet. C'est selon moi un diagnostic parano de mxtoolbox.
Avez-vous reçu un retour en erreur de outlook.com ???
Avez-vous reçu un retour en erreur de outlook.com ???
on me dit que non...juste les emails non livrés.
par contre je vois :
Cymru Bogons Ipv6 = Reason for listing - 8000::/1
Et si j'enlevais l'ipv6 de mon SPF ??
Et si j'enlevais l'ipv6 de mon SPF ??
Je passe en privé, je vais vous demander de m'envoyer un e-mail, et mon serveur accepte de les recevoir en ipv6.
OK merci !!! je viens d'envoyer un mail.
OK merci !!! je viens d'envoyer un mail.
J'ai répondu, voyez votre mailinblack, ce n'est pas à moi à devoir me battre avec ce genre de nuisance(*).
(*) ceci exprime un certain mépris.
pas de souci, je viens de débloquer le mail.
Merci pour ton aide. Au final je ne sais plus ce que je dois faire… s'il faut tout autoriser (Dmarc = none) et dkim sur none ou quarantine…tout cela ne sert plus a rien.