400 4.4.7 message retardé

8

La semaine dernière, Exchange 2010 a été mis en ligne et je constate dans la visionneuse de file d'attente (dans la console d'échange) qu'il contient 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 (modifiant ainsi l'adresse de notre enregistrement MX va) résoudra cela?

Lbaker101
la source

Réponses:

7

Il existe de nombreuses possibilités liées à cette erreur. Tiré de ma réponse à une autre question (mais légèrement modifiée):

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 excentrique 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 destinataire ne supprimera pas les messages de rebond informatifs, optant plutôt pour des messages d'échec génériques).

(En guise de remarque, les vérifications RDNS comme 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. Admins de messagerie, ne soyez pas paresseux!)

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 travaillez avec eux . Vous devrez peut-être travailler avec eux pour résoudre le problème.

Wesley
la source
Merci pour les réponses! J'ai fait les tests sur testexchangeconnectivity.com et je me souviens que la recherche DNS inversée était correcte.
Lbaker101
Jusqu'à ce que nous obtenions notre filtre de courrier électronique (le jour suivant), l'enregistrement MX pointe directement vers notre serveur d'échange via une adresse IP externe désignée. l'ASA5505 fait le transfert NAT pour pointer ceci dans l'adresse interne correcte et les ports de pare-feu corrects ont été ouverts pour permettre le trafic de courrier électronique. Je vais approfondir cela. Merci pour le conseil!
Lbaker101
3

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 éclairer 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; la Last Errorsection " " 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.

Shane Madden
la source
Identité: XXX-XXX \ 4269 \ 19930 Objet: XXXX ID de message Internet: <[email protected]> De l'adresse: [email protected] Statut: Prêt Taille (KB): 11 Nom de la source du message: FromLocal Source IP: 255.255.255.255 SCL: -1 Date de réception: 18/08/2011 06:53:04 AM Heure d'expiration: 20/08/2011 06:53:04 AM Dernière erreur: 400 4.4.7 Message retardé ID de la file d'attente: XXX -XXX \ 4269 Destinataires: [email protected]
Lbaker101
0

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.

mailq
la source
0

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

Brûlé par la neige
la source
-2

Le DNS qui a été configuré sur mon serveur Exchange a été retiré. J'ai essayé d'envoyer une requête ping à quelques domaines de messagerie retardée et je n'ai reçu aucune résolution.

Je suis entré dans mes paramètres réseaux sur le serveur et j'ai mis à jour le DNS primaire et secondaire.

Tout recommence à couler bien.

J'espère que cela t'aides

Patrick
la source