400 4.4.7 message retardé
La semaine dernière, Exchange 2010 a été mis en ligne et je remarque dans la visionneuse de file d'attente (dans la console d'échange) qu'il arrive avec quelques e-mails contenant des erreurs 400 4.4.7 message delayed.
La réponse en retour que nos membres reçoivent est la suivante:
Delivery is delayed to these recipients or groups:
[email protected] ([email protected])
Subject: test
This message hasn't been delivered yet. Delivery will continue to be attempted.
The server will keep trying to deliver this message for the next 1 days, 19 hours and 54 minutes. You'll be notified if the message can't be delivered by that time.
Ceci n'est qu'un exemple spécifique et il existe plusieurs pour plusieurs domaines sur lesquels d'autres adresses e-mail fonctionnent (pour le même domaine).
Nous sommes sur le point de faire filtrer notre courrier à travers leur filtre, puis d'entrer dans le serveur, mais en ce moment, l'enregistrement MX pointe directement sur notre serveur d'échange.
Quelqu'un at-il une idée de la façon de résoudre ce problème? Ou si le déplacement vers le filtre (changeant ainsi l'adresse de notre enregistrement MX) va résoudre ce problème?
Il existe de nombreuses possibilités liées à cette erreur. Tiré de ma réponse à une autre question (mais légèrement modifié):
Tout d'abord, essayez d'établir une session SMTP avec les serveurs de messagerie distants à l'aide de telnet pour voir si vous pouvez obtenir plus d'informations.
Il est également possible qu'une sorte de règle de pare-feu étrange ait été mise en place qui supprime, modifie ou modifie autrement les paquets vers ou à partir d'un domaine ou d'une IP associé au serveur distant. Peu probable, mais j'ai vu des choses plus étranges. Vérifiez votre pare-feu de passerelle ainsi que le pare-feu logiciel du serveur Exchange pour toute règle qui pourrait avoir quelque chose à voir avec le serveur SMTP distant. Recherchez les domaines, les adresses IP et toute plage d'adresses pouvant être associées au domaine distant.
Une autre possibilité mince est que le domaine distant a des problèmes de zone DNS. Peut-être que leurs enregistrements MX sont périmés. Peut-être qu'ils ont effectué une migration de zone mais n'ont jamais tout migré vers le nouveau serveur DNS. Encore une fois, des choses plus folles se sont produites.
Encore une autre possibilité est que le serveur de réception effectue une recherche DNS inversée sur votre IP d'envoi et qu'il ne correspond pas à vos enregistrements MX. Si votre enregistrement MX pointe vers 192.0.2.1, mais que c'est derrière le pare-feu qui est 192.0.2.2 et qu'une IP virtuelle est configurée sur le pare-feu pour accepter 192.0.2.1, le trafic sortant sera considéré comme 192.0.2.1, mais RDNS affichez 192.0.2.2 comme serveur de messagerie. Cette différence peut amener certains serveurs de réception à rejeter le message de diverses manières (bien que j'espère que l'administrateur de messagerie du destinataire ne supprime pas les messages de rebond informatifs, optant plutôt pour des messages d'échec génériques).
(En remarque, les vérifications RDNS comme celles ci-dessus sont stupides car de nombreuses personnes ont authentifié des relais pour les e-mails sortants et cela, par nécessité, ne correspondra pas au serveur entrant.
Enfin, mais certainement pas des moindres, UTILISEZ DES ENREGISTREMENTS SPF! DKIM aussi. Vous pouvez constater que bon nombre de vos problèmes de messagerie transitoires disparaissent juste après avoir correctement configuré ces deux choses.
Bien sûr, écoutez Shane Madden et vérifiez votre file d'attente de messagerie .
À la fin, contactez les administrateurs du domaine distant et élaborez avec eux . Vous devrez peut-être travailler avec eux pour résoudre le problème.
Vérifiez votre file d'attente de messagerie dans la section "Boîte à outils" de la console de gestion Exchange.
Vous serez en mesure de creuser dans les erreurs spécifiques qui sont générées chaque fois que le message est tenté d'être remis, ce qui devrait faire la lumière sur la cause première. Recherchez un message de problème spécifique dans une file d'attente de domaine, puis cliquez avec le bouton droit sur le message et ouvrez les propriétés; le "Last Error "est ce qui vous intéresse.
Les causes probables sont la connectivité du port 25/TCP et les problèmes de résolution DNS, mais modifiez les erreurs que vous trouvez dans la question si vous rencontrez toujours des problèmes et nous pouvons vous aider à déterminer la cause première.
Une autre remarque, en particulier pour les domaines aol.com, si votre entreprise leur enverra beaucoup de courrier (je ne sais pas quel est le seuil pour qu'ils commencent à vous mettre sur liste noire), vous devez enregistrer votre nom de domaine avec un contact de postmaster sur ce site Web: http://postmaster.aol.com/Postmaster.Whitelist.php
Sans plus d'informations, cela ne semble pas étrange. Certains serveurs de destinataires mettent en œuvre des contrôles de limite de débit qui empêchent d'inonder leurs serveurs. Certains messages passent tout de suite, d'autres doivent attendre (et réessayer plus tard).
Si ce problème est vrai pour plus de (disons) 10% de vos e-mails, vous avez des problèmes avec la résolution DNS, votre pare-feu interne ou d'autres paramètres réseau étranges qui empêchent le flux de messagerie sur votre site.
Mais cela n'a absolument rien à voir avec vos paramètres MX.