Exchange OVH - des clients ne reçoivent plus nos mails
... / Exchange OVH - des client...
BMPCreated with Sketch.BMPZIPCreated with Sketch.ZIPXLSCreated with Sketch.XLSTXTCreated with Sketch.TXTPPTCreated with Sketch.PPTPNGCreated with Sketch.PNGPDFCreated with Sketch.PDFJPGCreated with Sketch.JPGGIFCreated with Sketch.GIFDOCCreated with Sketch.DOC Error Created with Sketch.
question

Exchange OVH - des clients ne reçoivent plus nos mails

Par
Jallatte_SASJ
Créé le 2023-05-17 19:11:11 (edited on 2024-09-04 12:54:14) dans Emails-old

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 ?


44 réponses ( Latest reply on 2023-06-02 06:49:49 Par
CK
)

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.

en fait si on analyse le mail qui passe en spam, avec cet entete :
https://mxtoolbox.com/Public/Tools/EmailHeaders.aspx?huid=8097d42a-95f7-46bf-a76e-6c1965ce2652

On voit :
X-Microsoft-Antispam-Mailbox-Delivery : ucf:0;jmr:0;auth:0;dest:J;OFR:SpamFilterAuthJ;ENG:(910001)(944506478)(944626604)(920097)(930097)(3100021);RF:JunkEmail;

et X-Microsoft-Antispam-Message-Info =
`=?utf-8?B?U0xPK3VWUTd2c09helhyT2ZRd0hlZitReFc5VGl1ei9GYWFWenczbGpnZEF6?= =?utf-8?B?RU1VS0p5RDFiNWtwSnZaYXdrRklDS0t1c25pdVdzbEV0My9hQWZoWThGVnNY?= =?utf-8?B?V1FYN3dYSG4rSE55Q3p3ckpKWEp2UW5RdmVScXE2UzlNZ2hwR0hDdHphSk5L?= =?utf-8?B?NTk4TmpZYUFMRW1NcnVhcUNaY2tUMzdhOStJUlZUaE9KTCtRVFFyS0tzRHFi?= =?utf-8?B?RW9pSVQ4aTZ3dnFOdi92TU5mQnRtUVNvVkorMWwwcGFsMGpPdHhmWFpzUXdH?= =?utf-8?B?disrNlc1S202QUgwQXRCTFN4cEZxbTZ1UkRZaFYrb29saWtVdW9MK3orQU03?= =?utf-8?B?TjJZNUlYTGlCN1B3aG1JSXVrNHJQV0I2NUNTTXZ6dUI0eUREUGxNUnVmeWhH?= =?utf-8?B?UjVJT2NaYWI0UkE1SnFKeHZEenVTQjFqVWpVMmc2RHAwOXlUWXI0YjdmU3dp?= =?utf-8?B?ZDZiL3AyYWQvR3J3cnprYmdJVUlkRll4SXcrMEZ1aU42eWlwWXU4djArT3R1?= =?utf-8?B?Zk8wWDgrWjd2N09FS2N2eTVVNys0NGZWQUg5OUNKclU5SFpWNTNkVDFUZHlO?= =?utf-8?B?NnhHeEtFbXNpdndMOS9JMGM0OThseXd3UkYyRXNDb2FndnRxK1FWdit4ek1t?= =?utf-8?B?THd6ZUFWQ3ZFTlErc3lMWmFGdEJGb2t3TXpTOWkzSC9FTCtENkNpRktTYjVj?= =?utf-8?B?a1BuRXplNFp2NytaTHBwTk5YSzNrRkQydVI4M3MwU2EyWloyc1ZRaTFEQnBq?= =?utf-8?B?Sk80ZEQzWGcrRDdEZlRXZDRoSzRyV0l2ZzV2NURsUWVSSmJPQ1JEck5UYUFL?= =?utf-8?B?T1E1NUEzTEJlQmsreVFCY29CZ0ZETzI2aDdYYytWbEN1WmlITmdTQytPNG1m?= =?utf-8?B?T2N1TmtsQ1MzbUxhdjBHQm5jeURYSUZyYXFKUXhDZElEa1Y1aDJKZER1bk5p?= =?utf-8?B?NlpjWE1OSFMrVGdmU1V1K05DYWs0a1E4aTRQYjcwcTJkQ2NUWWlLdzNxcEVL?= =?utf-8?B?RlZzVjRLVDEwdk5nQkUyNGwvZ0thOUg4NDFIMkJIR2hEMmFFWW13b2NhYlhL?= =?utf-8?B?UldtcXMxdFo0QWgyc09lcUxHNGFqNnFVSkxIYXZlVEI3c2laU0x3VDF4OFZl?= =?utf-8?B?OVhmbzZjbk5naFBMMUZCMnhYRkpTUDdKYm5SRUVHVUpaMEt3b0ZDTEJwcFVy?= =?utf-8?B?MW83UVJXWTZiNlZDbnZOVEdsN29SY1l4RFRYMWNjK3NQdnRSZjJuN3UxaDhI?= =?utf-8?B?WGZTeGJLaXNRcDNROFRMbHZ6YitZQVdpQUVLaHdISWZVYitiWWM4QzB4NzA5?= =?utf-8?B?WjFmVTRLV3hGanJFNXdzYzRpV2YxV0duSnpybXBNeHJmUTgyQVYxOFdXVzZS?= =?utf-8?B?bUxSNzFQRFNKQzJjNzNXRFBUa2NRekNlZUlWckdoU0hHZkVrU3kvOGpuZmlr?= =?utf-8?B?a0Evb3ZSTzdOcm9KS1pwcGFueCtQRDVCM3RqVXlBRGR3dTNja3ZQZzN5Vy8v?= =?utf-8?B?WHBOaVJEKzUwS1ZnTkcyOHlicUVUODVWTTJSNnlZYVp2TGVzSm1KT0NVZ2Ix?= =?utf-8?B?SEhaL1Fwd2pPd1NZaVlwSTdNUm13QlZRSDRidDB4eG1CMDhZVktFM0JEaVZI?= =?utf-8?B?RnhPV2NEQ1lCL1lFYU8yaktEVEwrV2dyUGI0LzdqcGxJMi90YVphQzA3Nktw?= =?utf-8?B?ZHZPK1o5aW8xTk1SeVFSWkxzajlOS29ybW4rMXBJaVFFSFIzeVp3d1o4R1FI?= =?utf-8?B?ZGc5VVVBMXlSOFZRT2xIdXI2VmpsT1A4dUpUbCtZQ0pDYTN4UXNYZzB4Szkw?= =?utf-8?B?SWtZVFdMd29HZE1tU1FLSDdmY1hHek41QVRTOS92OHBnekVUUkhUcEtqdEgy?= =?utf-8?B?dnZ1VEoxKzRFSHA3dmdEcWhtMnd5VW5rMVUrd08zUmtaVEN4RHNXSlJpTFN4?= =?utf-8?B?Z0dlSzNSbXhlRWtOVnloRWZkWE1WdG5ITzZaY0NNakd6WWVVUGVlNzRrd1NZ?= =?utf-8?B?Q2VRNzRIWkZhRVpSZGZnTHgrWXIxbnNreDc0bWdXWENkcWI0YVhrV2Y5akxY?= =?utf-8?B?U2R0SDBJckRnVHdjRHhWYWxzd2JCNVhlQVZVeVNySDlCVTl4UUVaeFlzZnhR?= =?utf-8?B?cjY3MXlrZktJd3lEc0xHcDNhNTZncU03UktVdWVMek9VODRxSGQ5V1BxeG4v?= =?utf-8?B?bWZDK2VkRlJrRFgrclAxaDdNbEo0NXBWRUQ1SHp6dGIxL2pkTkNMR1hwV1dR?= =?utf-8?B?RTVoYmpKT0JMSWRXWlQweVJUR0YxejJVZUFlOHhSekFFUnhFQ1dsdjZOSW1I?= =?utf-8?B?WXRxZkZNR3ArMDh3SnNmMTJHMHB5cEFBbEIzY1pMSnVCcEdtMlgvQTd5eDc1?= =?utf-8?B?WFppOU9qV2dyclJNRlN0WitISld4SFhpUmNhVGdEN1UwVVl0WmNkbDY4N08r?= =?utf-8?B?S09pUDZseU8yc1BJYlhXdjU3TVFVSlJMb2QzV0l2TzMvdzlDZEV3NXFJR2pP?= =?utf-8?B?b2ZmR2RjZ2ZubVUycU1UaWQrTFNHMjh1cEVWQWFqNTBUcnA4RDExSjBZN01K?= =?utf-8?B?bnN6dFBrWnN6ZFRqbG5pUDVVUDdvTDF6SG55OUVLN1NtNTlMQzA2ak9sWEI1?= =?utf-8?B?NnZ3ZldsZDNFbG1GZm1HSGwvWUljU0cyMmJQK0U3QTZsUitUaU9tWEdTNTNP?= =?utf-8?B?b2MwbXN6L2o1VkFjNHVLeGtRUUxLbDNJdmExMDVYLzlVZ1MvUkxxamJ1TEpa?= =?utf-8?B?QzlaUUVJZHR0YkZOM2xQakZTVlhtblFzS3Y1YUxONFEzZzJGaUR0cGhjeE1w?= =?utf-8?B?bDRDSzhMRFJHa3U4WW1scnpPL1BvL1FJbmQyd1Q3djNUb2FLeFpyWXBhZkxS?= =?utf-8?B?MGtWSHplazVJU1RLSjhyTkJOZz09?=`

le problème c'est de pouvoir décoder ça...


en fait si on analyse le mail qui passe en spam, avec cet entete :


C'est Microsoft Outlook.com qui a décidé ainsi.
Votre correspondant pourrait tenter de savoir, mais vous savez on est bien peu de chose face aux GAFAM...

Bon j'ai trouvé ce lien : https://olcsupport.office.com/
on va voir ce que ca donne...

Je viens de recevoir le message suivant du support microsoft. je ne comprends pas trop ce qu'ils veulent dire par "**Not qualified for mitigation**".



et leur lien renvoi vers un PDF de 26 pages qui t'explique c'est quoi un dkim, un spf, un dmarc...etc et ce qu'on est sensé faire. Je tourne en rond.
http://download.microsoft.com/download/e/3/3/e3397e7c-17a6-497d-9693-78f80be272fb/enhance_deliver.pdf


un PDF de 26 pages


Haha ! belle pièce pour le musée !


Néanmoins avec Microsoft il faut suivre la procédure décrite sous le chapitre SNDS . C'est toujours d'actualité. Par contre le lien dans le PDF n'est plus d'actualité.

j'ai déjà essayé SNDS, voir plus haut, je me suis inscrit et j'attends depuis plusieurs jours leur email sensé etre envoyé "rapidement". il n'est pas dans mon mailblack...j'ai fait plusieurs demandes de renvoi mais toujours rien.



Bonjour,


je me suis inscrit et j'attends depuis plusieurs jours leur email sensé etre envoyé "rapidement"

De mémoire c'est le propriétaire des IPs qui reçoit le mail, donc le NOC de OVH.

Cordialement, janus57


De mémoire c'est le propriétaire des IPs qui reçoit le mail, donc le NOC de OVH.

OMG !!! et avec OVH on avance au rythme de 1 message par jour (jusqu'a maintenant a coté de la plaque)...

et je viens de recevoir un retour d'ovh qui me renvoie inlassablement vers son guide. Et cerise sur le gateau ils ont clos le ticket.


De mémoire c'est le propriétaire des IPs qui reçoit le mail, donc le NOC de OVH.


Comme le reverse est mis correctement, je me demande si jallatte.fr n'est pas dans le circuit de validation ? Je ne me rappelle plus...

~# host 141.95.128.105
105.128.95.141.in-addr.arpa domain name pointer mail.jallatte.fr.


Comme le reverse est mis correctement, je me demande si jallatte.fr n'est pas dans le circuit de validation ? Je ne me rappelle plus...


c'est a dire ?

Sinon je me demande qu'est-ce que je risque a faire ce que le support OVH semble me demander de faire (si j'ai bien compris) c'est a dire ajouter au SPF : **include:mx.ovh.com**

Bonjour,

Pouvoir mettre un PTR n'est pas synonymes de la possession de l'IP.

De mes souvenirs les mails sont bien envoyés au propriétaire/contact déclaré dans le RIPE.

Cordialement, janus57


include:mx.ovh.com


Pour vous (Exchange Private) ça ne sert à rien: vos serveurs mail de sortie n'ont pas un nom DNS qui se termine par 1out.ovh.net...out.ovh.net...

En plus OVH utilise une méthode désapprouvée et en cours d'abandon, basée sur le PTR du hostname d'envoi.

je suis en train de lire le PDF de microsoft, et tous les liens et emails vers qui ils indiquent de se tourner.
Dans la partie : **Contact and Escalation Procedures** La moitié des url ne marchent pas, les emails non plus...

DM3NAM06FT015.mail.protection.outlook.com a rejeté votre message vers les adresses de courrier suivantes :
senderid@microsoft.com (senderid@microsoft.com)
Nous avons rencontré un problème de communication lors de la remise de ce message. Essayez de renvoyer ce dernier plus tard. Si le problème persiste, contactez l’administrateur de votre courrier.
DM3NAM06FT015.mail.protection.outlook.com a généré cette erreur :
Recipient address rejected: Access denied. AS(201806281) [DM3NAM06FT015.1nam06.prod.protection.outlook.comnam06.prod.protection.outlook.com 2023-05-31T13:32:14.138Z 08DB6120C9E22E9D]





Informations de diagnostic pour les administrateurs :
Serveur de génération : S1043232.EX3169.lan
senderid@microsoft.com
DM3NAM06FT015.mail.protection.outlook.com
Remote Server returned '550 5.4.1 Recipient address rejected: Access denied. AS(201806281) [DM3NAM06FT015.1nam06.prod.protection.outlook.comnam06.prod.protection.outlook.com 2023-05-31T13:32:14.138Z 08DB6120C9E22E9D]'
En-têtes de message d'origine :
Received: from S1043232.EX3169.lan (2001:41d0:11b:2f00::8d5f:8069) by
S1043232.EX3169.lan (2001:41d0:11b:2f00::8d5f:8069) with Microsoft SMTP
Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.2.1118.26; Wed, 31 May 2023 15:32:12 +0200
Received: from S1043232.EX3169.lan ([fe80::f845:f86e:f48:6474]) by
S1043232.EX3169.lan ([fe80::f845:f86e:f48:6474%5]) with mapi id
15.02.1118.026; Wed, 31 May 2023 15:32:12 +0200
From: xxxxxxxxxxxxxx
To: "senderid@microsoft.com" microsoft.com>
Subject: Problem sending emails to outlook.com servers
Thread-Topic: Problem sending emails to outlook.com servers
Thread-Index: AdmTwwCTQQZCxN6nQTuVCnUAwjt/LA==
Date: Wed, 31 May 2023 13:32:11 +0000
Message-ID: <520d6f42a2aa4e5db76bd117c8efe3c4@jallatte.fr>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [90.121.xx.xx]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
micalg=SHA1; boundary="----=_NextPart_000_0067_01D993D4.EAED4B70"
MIME-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; d=jallatte.fr; s=ovhex4599-selector1;
c=relaxed/relaxed; t=1685539932; h=from:to:subject:date;
bh=HAr1gtTyBjT2tKDjWzj96N5Lju98cYxeljwSJxXvGIY=;
b=Fsa9iElZjO3deSjqkPzsu+Y2CV251njoK/wdBbC3ffSsDEyBWZhnTJt64IuUzBfDa4u4yX01km3oCkJAjx9v1it/sRrQ
Dernière page du document, tous les liens sont en HTTP aucun HTTPS c'est pour dire si le document est obsolète/outdated

Je suis en train de péter un cable, je ne sais plus quoi faire...

Bon si je repars depuis ZERO. Le guide OVH DIT :



auquel j'ajoute le spf de mailjet :
> include:spf.mailjet.com

ce qui me donnerait ca :
> "v=spf1 ip4:11.22.333.444 include:spf.mailjet.com ~all"

donc je ne peux pas réduire plus ce que ça...tout en concervant un soft fail "~all"

Selon vous je vais m'exposer a de nouveaux problèmes si je fais ça ?
Tant pis pour les emails envoyés depuis mon serveur web, tant pis pour l'ipv6.


donc je ne peux pas réduire plus ce que ça...tout en concervant un soft fail "~all"


Pour moi ça ne va rien changer.

Dites, au fait, le contenu de votre e-mail, il n'y a aucune raison pour qu'il puisse être considéré comme spam ou "presque spam" ?
Des liens vers des raccourcisseurs de liens, trop d'images distantes, trop d'images par rapport au texte, ... ?

Sinon je suis à court d'arguments.

j'arrive a obtenir un 10/10 sur mail-tester.com, avec un mail en HTML avec ma signature qui comporte des images etc...
il manque les balises ALT dans les images actuellement, si je les ajoute j'ai 10/10, et sans les balises 9.5/10

La signature est gérée par notre service marketing avec un plugin outlook appelé "weadvocacy", je leur ai dit ce matin d'ajouter les balises. En théorie demain on sera tous en mesure d'obtenir un 10/10 si on fait un test.



Le petit Check Orange c'est normal, j'ai pas de lien "unsubscribe" dans mon mail.


Dites, au fait, le contenu de votre e-mail, il n'y a aucune raison pour qu'il puisse être considéré comme spam ou "presque spam" ?
Des liens vers des raccourcisseurs de liens, trop d'images distantes, trop d'images par rapport au texte, ... ?


Après je ne peux pas analyser tous les emails que nos collaborateurs envoient...
Par contre j'ai remarqué un truc dans un des nombreux liens microsoft, c'est qu'un email avec en objet du texte tout en majuscule peut etre considéré come du SPAM. Et j'en ai remarqué souvent chez les personnes qui m'annoncent des mails non recus.
Par exemple on a un client qui nous envoie un mail avec en objet : **DEMANDE DE DEVIS**
tout en majuscule. Donc nous on répond au mail, et il ne le reçoit pas.
Si je dois dire a nos assistantes commerciales de mettre les objets des mails en minuscule, on n'a pas fini...


Par exemple on a un client qui nous envoie un mail avec en objet : DEMANDE DE DEVIS


hé oui c'est un indicateur (parmi d'autres) de probable spam

si c'est ça alors c'est un peu rageant d'installer SPF/DMARC/DKIM pour se retrouver dans le dossier des spams a cause d'un objet en majuscule, rédigé par nos clients en plus.

tien je viens de tomber **https://answers.microsoft.com/en-us/msoffice/forum/all/office-365-email-delist-portal-is-throwing-an/45be774a-91a1-44a3-89d1-219d64449102">sur un forum ou ils sortent un nouveau lien** pour se delister chez office365:
https://sender.office.com/

Aller on va tenter...

j'arrive jusqu'a l'etape 2, c'est déjà ca...


une fois le bouton "delist ip address" cliqué, j'obtiens ca :



c'est infernal, ya jamais rien qui fonctionne...et bien entendu le lien derrière **here** renvoie vers une page inexistante (erreur 404) : https://msdn.microsoft.com/en-US/library/dn774177.aspx

et que se passe-t-il quand j'écris à delist@messaging.microsoft.com ???



**Comment vous ne voulez pas peter un cable ??**

Bon, je pense qu'en fait je suis finalement parfaitement bien configuré. Le problème qui réside, c'est qu'on est blacklisté chez **microsoft** suite à la boite mail qui s'est fait hackée dans notre entreprise (voir 1er post)
Les mails sont bien livrés, mais ils tombent dans les courriers indésirables dès que le mail passe par un serveur : xxxxx.protection.outlook.com

j'ai trouvé ici quelques infos interessantes : https://postmaster.live.com/pm/policies.aspx


Les points 2, 3, et 4 ont du nous achever en fait. il n'y a plus qu'a attendre et espérer qu'un mécanisme "automatique" nous deliste, puisqu'aucun des formulaires ne fonctionne ou accepte ma demande, et aucun des emails indiqués dans mes recherchent n'acceptent mes messages.

Merci du feedback.

J'en fais quoi des spams qui proviennent de Gmail ? Je blackliste Gmail ?
exemple de mails avec les sujets:
Your balance has been replenished +27.665$
When you get your money +14,155$
etc

chaque fois authentiquement depuis les serveurs Gmail et avec une pièce jointe PDF.
Je les dénonce à Spamcop mais Gmail ne prend pas les plaintes Spamcop...

Bonjour,


J'en fais quoi des spams qui proviennent de Gmail ? Je blackliste Gmail ?

déjà essayé, on m'a demandé de le mettre sur liste blanche après…
Et oui fût un moment gmail était dans la RBL SpamHaus


Le problème qui réside, c'est qu'on est blacklisté chez microsoft suite à la boite mail qui s'est fait hackée dans notre entreprise (voir 1er post)
Les mails sont bien livrés, mais ils tombent dans les courriers indésirables dès que le mail passe par un serveur : xxxxx.protection.outlook.com

c'est pas du blacklisatage alors (sinon vos mails serait refusé en entrée), mais une mauvaise réputation du domaine et ça à part dire aux utilisateurs/Admin de catégoriser vos mails comme faux-positif il n'y a pas d'autre méthode (idem chez Gmail).

Cordialement, janus57


mauvaise réputation du domaine


oui voilà, c'est le terme exact.

Bon finalement j'ai reçu un mail de Microsoft qui m'indique qu'ils n'ont aucun souci avec l'ip de notre serveur...



en faisant un test sur ce site : http://mail-server-test.online-domain-tools.com/
je remarque un truc :


Le MX de notre Mailinblack (qui ne figure plus dans notre SPF maintenant que je l'ai retiré) semble poser un problème...Mais en orange ils disent que c'est valable que s'il s'agit d'un serveur de mail sortants, ce qui n'est pas le cas.