Bonjour,
Plusieurs e-mails envoyés vers les serveurs d'OVH et acceptés par un de ces serveurs ne sont pas dans la boîte du destinataire.
C'est aléatoire, car certains mails plus récents sont bien là.
mx0.ovh.net Ok: queued as 4gPp3P2HSmzDqJZ (11h53)
Ok: queued as 4gPpd85zd2z326tR (12h19)
On reste dans des temps acceptables pour les e-mails, sauf quand il s'agit de recevoir des codes ou des challenges valables 10 ou 15 minutes. On est à 48 minutes pour au moins l'un d'entre eux.
Oui j'ai reçu des appels de clients et j'ai moi aussi constaté des retard variables.
Voilà un cas ou un corp OVH dédié au sujet serai très utile @FabL 
Hello à tous les deux,
Pour des cas e-mails, je veux bien les numéros de tickets associés dans lesquels vous aurez pu mettre toutes les infos avec les e-mails concernés et les entêtes avec le contexte (e-mail classique ou code à recevoir comme tu le mentionnais @fritz2cat)
Si un membre de l' @EmailTeam passe par ici, il aura tous les éléments directement pour vérifier de quoi il s'agit.
Merci pour l'alerte !
^FabL
Je n'ai pas fait de ticket. Mais chose rare, j'avais les numéros de transaction de mails qui n'étaient pas encore livrés, grâce à un serveur relais où je peux gérer l'agressivité vis-à-vis des black lists notamment.
Désolé pas de ticket, pour ce genre de cas je dis au client d'attendre jusqu'à demain
Le support mail c'est le pire des travail.
Bonjour,
Comme une question similaire arrive aujourd'hui: E-mails OVH reçus avec 15 min à 2 h de retard (différé): d'autres utilisateurs concernés ?
peux-tu réveiller l'e-mail team, stp ?
Merci !!
Bonjour,
J'ai ouvert un ticket d'incident pour ce problème. La réponse du support a été qu'il s'agissait d'une limitation mise en place au niveau de l'infrastructure OVHcloud afin de protéger leurs serveurs contre le spam.
La solution proposée est assez surprenante : demander à nos fournisseurs et à nos clients de ne pas envoyer plusieurs e-mails en même temps. Je leur ai expliqué que ce n'était pas envisageable. Quand on attend des CMR ou d'autres documents importants, on ne peut pas demander aux expéditeurs d'envoyer leurs mails à une heure précise ou espacés d'une heure.
Je leur ai également indiqué qu'il n'était pas possible de travailler dans ces conditions et je leur ai demandé s'ils pouvaient faire remonter le problème à leurs supérieurs. La réponse a été : « Je vous invite à changer de fournisseur mail si cette utilisation ne vous convient plus. »
J'avoue que j'ai trouvé ça assez lunaire...
En tout cas, maintenant je me sens moins seul. J'espère qu'une personne de l'équipe mail passera sur le sujet pour apporter des explications ou des pistes d'amélioration.
PS : J'ai remarqué la même chose que ce qui a déjà été signalé ici : c'est assez aléatoire. Certains e-mails arrivent immédiatement, d'autres avec 10 à 15 minutes de retard. Les délais les plus importants semblent surtout concerner les e-mails redirigés ou lorsqu'on reçoit plusieurs CMR ou BL envoyés vers une même adresse. Dans ces cas-là, le retard peut facilement atteindre une à deux heures.
Pour moi il y a un truc que je m'explique pas dans ce que OVH prétend avoir mis en place.
Je rappelle ce que j'avais donné comme renseignements le 26 mai:
Si OVH prétend faire du throttling, un peu comme Wanadoo faisait il y a 15 ou 20 ans (Wanadoo acceptait maximum une seule connexion entrante par IP source - ce qui était une galère à gérer pour les gros expéditeurs), dans ce cas les messages mis en attente doivent rester à l'extérieur de l'infrastructure.
Un autre mécanisme, tout aussi discutable, s'appelle le greylisting, et quasiment plus personne ne le pratique. Là aussi, les messages mis en attente restent en-dehors du périmètre des serveurs en réception, en utilisant les codes d'erreur temporaire SMTP 4xx.
Dans le cas que j'avais identifié ci-dessus en mai, OVH accepte les messages, les met dans une queue, et puis fait je ne sais quoi pour les empiler dans un coin dans un ordre aléatoire et les extraire dans un ordre tout aussi aléatoire.
J'ai juste l'impression que ça ne protège nullement contre le spam (puisque les mails sont acceptés) et ne peut faire qu'alourdir les processus internes.
Quand on voit le nombre de headers "Received:" dans les mails qui passent chez OVH, il faut se dire que le traitement est probablement complexe.
Je ne pense pas que l'équipe d'OVH fasse quoi que ce soit, car la personne que j'ai eue au téléphone m'a expliqué qu'il s'agissait de leur nouvelle politique de sécurité.
Au départ, je me suis dit qu'en écrivant sur le forum, ils finiraient peut-être par réagir, mais je vois que ce n'est pas le cas. Cela fait déjà 13 jours qu'un sujet similaire est lancé et il n'y a toujours aucune réaction. Pour eux, tout semble aller bien, comme indiqué dans la réponse à mon ticket d'incident :
« Comme nous vous l'avons expliqué, il s'agit d'une limitation mise en place au niveau de l'infrastructure OVHcloud. Nous ne pourrons pas la désactiver.
La volonté de la mise en place de cette dernière est de proposer une stabilité et une sécurité optimale des services de nos clients tout en offrant une expérience utilisateur de qualité sur nos offres mutualisées.
Les e-mails ne sont pas perdus, ils seront cependant délivrés après un délai variable d'attente qui permet de répartir la charge de réception des e-mails sur l'infrastructure et ainsi empêcher d'éventuelles anomalies et/ou ralentissements sur celle-ci.
Je vous remercie pour votre compréhension et vous souhaite une agréable journée. »
Je pense qu'il n'y a rien à attendre de leur part.
Personnellement, je vais suivre le conseil qui m'a été donné au téléphone et dans mon ticket, et me tourner vers d'autres fournisseurs.
Oui OVH fait du rate limit en réception, j'ai commencé à le constater depuis 4 semaines environs :
May 31 00:15:21 smtp2 postfix/smtp[1068158]: 8490B200DA: host mx0.mail.ovh.net[178.33.252.245] said: 450 4.7.1 Rate limit due to high number of emails sent, retry later (in reply to end of DATA command)
May 31 00:15:27 smtp2 postfix/smtp[1068158]: 8490B200DA: to=xxx.domain.com, relay=mx1.ovh.net[188.165.47.122]:25, delay=6.1, delays=0.06/0/5.9/0.18, dsn=4.7.1, status=deferred (host mx1.ovh.net[188.165.47.122] said: 450 4.7.1 Rate limit due to high number of emails sent, retry later (in reply to end of DATA command))
Gmail en fait aussi pas mal.
Merci. C'est intéressant, ça. Ca confirme que OVH fait effectivement du rate limiting ou throttling.
Ton Postfix t'informe que OVH a pris connaissance de la totalité du message avant de le rejeter. Il est donc possible que ce rejet soit basé sur des éléments qui se trouvent dans le contenu de l'e-mail, mais pas sur l'enveloppe SMTP.
Ceci explique que les e-mails sont livrés dans le désordre, puisque ce sont les serveurs expéditeurs qui doivent ré-essayer périodiquement.
Ceci a comme conséquence que l'analyse des en-têtes SMTP pourrait faire croire erronément que c'est le serveur de l'envoyeur qui a traîné pour livrer le message à OVH. Les tentatives échouées n'apairaissent pas dans ces headers.
OVH, comme bcp d'autres prestas, fait du mail low cost, ça ne leur rapporte pas grandchose, ça génère bcp de support, et ils essaient de se protéger comme ils peuvent d'une solution technique qui a bien 40 ans désormais, et qui n'est plus adaptée à la réalité du net d'ajd.
Si vous avez des impératifs pros forts, passez sur des solutions + avancées (google en mode payant, peutêtre Exchange chez OVH), montez votre propre serveur mail (avec tous les problèmes d'envois que ça pose, mais au moins vous contrôlez totalement la réception).
Malheureusement sur les offres premiers prix on en a pour son argent.
J'ai mes mails chez un concurrent Suisse, il y a aussi ce genre de problème parfois, faut juste faire avec et accepter vu le prix des offres. Ou, si vraiment au niveau pro ça ne passe pas, bah y mettre le prix en sortant des offres low cost.
Bonjour à toutes et à tous,
Il s'agit bien d'un mécanisme de grey-listing. Notre système fonctionne sur une base statistique : il surveille les variations de volume d'envoi selon l'adresse IP, le domaine expéditeur et le couple expéditeur/destinataire.
En règle générale, un domaine qui respecte les bonnes pratiques d'emailing lisse son trafic et s'appuie sur une IP « chauffée ». Il s'agit d'un standard chez les fournisseurs de messagerie, très efficace pour contrer les vagues de spam issues de serveurs compromis. Cela laisse également le temps à notre antispam d'isoler un pattern pour mieux filtrer les messages suivants.
Au cours des dernières semaines, nous avons calibré le système pour gérer des scénarios très spécifiques. C'est le cas, par exemple, des emails d'authentification à double facteur (2FA) qui génèrent un fort pic d'envoi le lundi à 9h, suivi d'un trafic très faible le reste de la semaine.
Afin de ne pas pénaliser nos utilisateurs, nous cherchons actuellement à identifier d'autres cas d'usage légitimes de ce type pour pouvoir les analyser.
N'hésitez pas à nous les remonter en réponse à ce sujet.
^FabL
Bonjour FabL,
Merci pour ces précisions.
J’ai aussi quelques interrogations en plus : est-ce qu’à terme les domaines ou adresses IP qui envoient régulièrement des emails sont censés être reconnus comme légitimes, même quand il y a ponctuellement un envoi groupé de 5 à 10 messages de la part du client ou fournisseur? Est-ce qu’un système de whitelist est prévu pour certains expéditeurs ou cas d’usage identifiés, et est-ce que vous prévoyez de faire évoluer le fonctionnement actuel ou ça va rester tel quel ?
Je pose la question car, comme indiqué précédemment, ce comportement impacte notre travail de façon assez régulière, quel que soit le client ou le fournisseur.
Pour contexte, on est une PME de 7 personnes, on reçoit entre 100 et 500 emails par semaine au total, et on utilise déjà une solution de filtrage pour nos emails (Mailinblack).
Jusqu’à présent, on n’avait pas rencontré de souci particulier avec la délivrabilité de nos messages. On aurait simplement apprécié être informés en amont d’un changement de ce type, afin de pouvoir en anticiper l’impact.
Merci d’avance pour votre retour.
Bonjour à tous,
J’ai remarqué une nette amélioration depuis le début de cette semaine. Il semblerait que le filtre laisse désormais passer les adresses récurrentes 
. Avez-vous observé la même chose de votre côté ?