// CLUBIC — MOBILE & WEB
Outlook.com : si vous ne recevez plus d'email c'est normal, c'est un bug
Depuis au moins le 5 novembre, des e-mails envoyés à des adresses Outlook.com et Hotmail sont renvoyés à l’expéditeur avec une erreur d’authentification. Des utilisateurs ayant pourtant configuré leur domaine normalement sont aussi touchés, et Microsoft n’a pas confirmé l’origine du problème.
Vous écrivez à quelqu’un qui a une adresse Hotmail, et votre message revient avec un code 550 ? Selon Windows Latest, qui rapporte l’information, des centaines de plaintes ont été publiées ces derniers jours sur les forums de Microsoft et sur Reddit.
Les messages renvoyés portent le code 550 5.7.23, lequel signale un problème de Sender Policy Framework (SPF), ou le code 550 5.7.1 avec la mention « Message lacks SPF/DKIM/DMARC Auth Records ». Pour mémoire, le SPF sert à vérifier qu’un serveur a le droit d’envoyer des e-mails pour un domaine, d’après une liste publiée dans le DNS de ce domaine. Le DKIM ajoute une signature aux messages, et le DMARC dit au destinataire quoi faire quand ces contrôles échouent.
Microsoft refuse ces messages pour un échec d’authentification, même si les contrôles semblent réussis. Un utilisateur affecté peut ainsi lire spf=pass, dkim=pass et dmarc=pass dans les en-têtes des messages. Il semblerait que des enregistrements valides soient rejetés, pour une petite partie des e-mails seulement, peut-être selon le serveur Microsoft vers lequel le message est routé. Par ailleurs, un même message initialement refusé peut ensuite être accepté quelques minutes plus tard. Et le fournisseur de messagerie de l’expéditeur ne semble rien changer au problème. D’ailleurs un message envoyé depuis Outlook peut également être refusé par un destinataire utilisant aussi la messagerie de Microsoft.
Pour mieux lutter contre le spam, l’année dernière, Microsoft avait imposé la configuration des enregistrements SPF, DKIM et DMARC aux domaines qui envoient plus de 5 000 e-mails par jour vers Outlook.com, Hotmail.com et Live.com. Par la suite l’éditeur allait mettre en place une politique de blocage.
Dans le cas présent, il semblerait qu’un bug ait rendu un serveur un peu trop zélé au risque de bloquer systématiquement tous les messages, quelle que soit la quantité envoyée par jour. Soulignons que des utilisateurs ayant procédé à l’enregistrement DMARC p=none ont, semble-t-il, réussi à corriger le problème.