Bonjour,
Depuis la semaine dernière, nous expérimentons des problèmes lors de l'envoi de nos mails en @certam-rouen.com et depuis hier depuis notre autre MX Plan en @certam.fr (identifiants identiques, l'un étant une redirection vers l'autre)
La semaine dernière, connecté sur le webmail d'OVH Roundcube avec une adresse mail en @certam-rouen.com:
* envoi d'un mail test sur une adresse perso et sur la même adresse en @certam-rouen.com: rien n'arrive nulle part, aucune notification reçue (même dans les spams ou autre dossiers)
* Toujours connecté sur le même compte mais en modifiant l'adresse expéditeur en @certam.fr (modification du champ X-Sender) : le mail arrive bien sur la boite perso et sur la boite @certam-rouen.com
=> vérification des champs SPF pour les deux domaines: RAS de détecté selon moi, ajout d'un serveur smtp de confiance et sécurisé dans nos zones DNS afin de retrouver une connectivité (champ ip4)
=> l'envoi de mail sous une identité @certam-rouen.com en utilisant ce smtp de confiance fonctionne mais l'utilisation de ssl0.ovh.net malgré une authentification de l'utilisateur OK ne permet pas de recevoir l'email (nous avons pris l'habitude de nous auto-mettre en Cc des emails)
Et jamais de notification de non-délivrance pour cause xx ou yy, les emails apparaissent bien dans le dossier Envoyés mais ont l'air de se perdre en route…
Depuis hier, même phénomène sous nos identités en @certam.fr alors que la semaine dernière nous pouvions utiliser les serveurs d'OVH pour envoyer des emails. Du coup, j'ai rajouté notre serveur smtp de secours également dans le champ SPF de @certam.fr
Une piste à creuser? le champ include:mx.ovh.com fait appel à un mécanisme de ptr qui n'est plus recommandé mais j'ai peine à croire qu'un timeout sur une résolution DNS inverse puisse faire bugger complètement le relayage des emails.
Le ticket incident ouvert chez OVH ne m'a pas été d'un grand secours pour le moment (sauf à me demander l'en-tête du mail non reçu)…
Merci
certam.fr
Bonjour,
Les mails sont-ils envoyés depuis OVH ou depuis coria ?
Commencez par mettre p=none dans votre DMARC tant que vous n'avez pas une installation stable qui fonctionne.
Sachez aussi que OVH élimine silencieusement les mails en sortie qui seraient identifiés comme spam. Le filtrage des spams n'est pas une science exacte et des faux positifs sont possibles.
Je milite pour que le client puisse être prévenu d'une manière ou d'une autre lorsque OVH lui subtilise ainsi des mails.
Je ne dis pas que c'est votre cas, mais puisque OVH ne prévient pas ses clients dans un tel cas, vous ne pouvez pas savoir si c'est pour cela ou non.
Bonjour et merci de votre réponse,
Actuellement, nos emails sont envoyés via coria depuis notre courrielleur (Thunderbird ou Outlook). Si nous utilisons le smtp d'OVH (ssl0.ovh.net en 465), malgré l'authentification utilisateur OK, les emails partent mais n'arrivent jamais.
Depuis le webmail OVH, mêmes symptômes que relatés dans mon premier post (X-sender modifié en certam.fr ça fonctionne, X-Sender non modifié ça part mais n'arrive nulle part)
J'ai modifié l'enregistrement DMARC en modifiant la politique de quarantine vers none, je me suis ajouté dans le rua pour recevoir des rapports mais même ça, je ne reçois rien.
Aucun retour du ticket incident OVH depuis samedi dernier…
Autre précision (si par hasard cela pourrait être d'importance):
Nous recevons bien les emails envoyés par nos clients, encore heureux, mais également des spams ou autre emails non sollicités qui arrivent,certes, correctement taggés.
La désactivation du filtrage OVH antispam/antivirus pourrait-elle être d'un quelconque effet? De ce que je comprends, ce mécanisme de filtrage doit s'effectuer sur le mx in d'ovh => se pourrait-il qu'un mail adressé à soi-même (ou à un autre mail du même domaine) se fasse détecter comme spam et renvoyé vers /dev/null?
Désolé je spamme le topic mais en parcourant l'interface OVH, je suis tombé sur cette erreur CDN dans la partir nom de domaine de @certam-rouen.com
c'est là où apparaissent en général nos informations d'abonnement, renouvellement automatique, etc etc…
Cela pourrait-il avoir un lien avec le problème?
1rouen.comrouen.com
Vous dirigez les visiteurs du site web vers une adresse de CDN
1rouen.com.rouen.com. 3600 IN A 46.105.204.21
www.1rouen.com.rouen.com. 3600 IN A 46.105.204.21
alors que vous n'avez pas d'abonnement sur CDN pour ce domaine, voire même aucun hébergement web OVH pour ce domaine.
En effet, sur la zone DNS 1rouen.comrouen.com il n'y a pas d'hébergement web, simplement un MX Plan
Historiquement, lorsque nous avons migré chez OVH, nous avions ouvert un hébergement avec zone DNS et MX Plan en certam.fr le temps d'effectuer la transition depuis notre nom historique en 1rouen.comrouen.com géré à l'époque par Altitude Telecom
Un nouveau site internet a été développé sous le nom www.certam.fr et la gestion de 1rouen.comrouen.com a été transférée chez OVH.
Ma direction souhaitant conserver le nom historique du site internet ainsi que le domaine des adresses emails, une redirection des requêtes sur www.1rouen.comrouen.com avait été mise en place pour pointer vers le nouveau site internet www.certam.fr, et les adresses mails des collaborateurs recréées sur @1rouen.com.rouen.com.
les mêmes adresses existent sur @certam.fr mais sont configurées en redirection vers les adresses @1rouen.comrouen.com
C'est un peu le mic-mac mais ça permettait de conserver le nom de domaine historique sans qu'il n'y ait eu de coupure de service lors de la transition (et au passage on paye 2 MX Plan pour n'en utiliser au final qu'un seul, bref…)
Enfin, tout ce petit monde fonctionnait bien jusqu'à la semaine dernière mais force est de constater que dorénavant dès que nous voulons envoyer un email depuis un X-sender en @1rouen.comrouen.com avec les serveurs smtp de OVH identifié par un vrai compte en @1rouen.com,rouen.com, les emails partent mais restent coincés quelque part…
J'essaie de contacter le 1007 histoire d'avoir un vraie personne mais le serveur vocal me renvoie systématiquement vers les demandes d'assistance en ligne en me raccrochant au nez après m'avoir souhaité une bonne journée …
Il y a un dysfonctionnement, donc c'est un incident.
Faites un ticket incident à partir de votre espace client.
Ca ne veut pas dire que vous aurez une réponse rapide.
Bonjour Fritz2cat,
Je suis d'accord avec vous, le ticket incident a été ouvert la semaine dernière. Au moins, votre œil extérieur m'a permis de confirmer qu'il n'y a pas de misconfiguration évidente de mon côté (des fois quand on a le nez dans le guidon, c'est bien d'avoir un avis tiers).
Bonne journée
il n'y a pas de misconfiguration évidente
Pour moi, X-Sender ne devrait normalement pas influencer.
Certains logiciels (Roundcube notamment je pense) l'ajoutent mais ça ne prouve rien à personne.
Feedback de la résolution du problème:
Notre nom de domaine était considéré comme spam par les serveurs d'envoi d'OVH et nos mails se faisaient shooter. Après contact téléphonique au 1007 avec une personne ayant rapidement pu déterminer la nature du problème, celle-ci a pu relayer aux administrateurs qui ont résolu le souci.
nos mails se faisaient shooter.
La morale de cette histoire:
Je milite pour que le client puisse être prévenu d'une manière ou d'une autre lorsque OVH lui subtilise ainsi des mails.