400 4.4.7 mensaje retrasado


8

La semana pasada, Exchange 2010 se activó y noto en el visor de colas (en la consola de Exchange) que aparece un par de correos electrónicos con errores 400 4.4.7 message delayed.

La respuesta de soborno que reciben nuestros miembros es:

Delivery is delayed to these recipients or groups:

XXX@aol.com (XXX@aol.com)

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.

Este es solo un ejemplo específico y existen múltiples dominios múltiples para los que funcionan otras direcciones de correo electrónico (para el mismo dominio).

Estamos a punto de filtrar nuestro correo a través de su filtro y luego ingresar al servidor, pero en este momento el registro MX apunta directamente a nuestro servidor de intercambio.

¿Alguien tiene alguna idea sobre cómo resolver esto? ¿O si pasar al filtro (cambiando la dirección a la que va nuestro registro MX) resolverá esto?

Respuestas:


7

Hay muchas posibilidades involucradas con este error. Tomado de esta respuesta mía en otra pregunta (pero ligeramente modificada):

Primero, intente establecer una sesión SMTP con los servidores de correo remotos usando telnet para ver si puede obtener más información.

También es posible que se haya establecido algún tipo de regla de firewall extraño que descarte, altere o modifique los paquetes hacia o desde un dominio o IP asociado con el servidor remoto. Improbable, pero he visto cosas más extrañas. Verifique el firewall de su puerta de enlace, así como el firewall del software del servidor de Exchange, para ver si hay alguna regla que pueda tener algo que ver con el servidor SMTP remoto. Compruebe dominios, direcciones IP y cualquier rango de direcciones que puedan estar asociadas con el dominio remoto.

Otra pequeña posibilidad es que el dominio remoto tenga problemas de zona DNS. Quizás sus registros MX están rancios. Tal vez realizaron una migración de zona pero nunca migraron todo al nuevo servidor DNS. Nuevamente, han sucedido cosas más locas.

Otra posibilidad es que el servidor receptor esté realizando una búsqueda DNS inversa en su IP de envío y no coincida con sus registros MX. Si el registro MX apunta a 192.0.2.1, pero está detrás del firewall que es 192.0.2.2 y se configura una IP virtual en el firewall para aceptar 192.0.2.1, entonces el tráfico saliente se verá como 192.0.2.1, pero RDNS sí lo hará. muestre 192.0.2.2 como el servidor de correo. Esa discrepancia puede hacer que algunos servidores de recepción rechacen el mensaje de varias maneras (aunque espero que el administrador del correo electrónico del destinatario no suprima los mensajes informativos de devolución, sino que opte por mensajes genéricos de falla).

(Como nota al margen, las comprobaciones de RDNS como las anteriores son una tontería, ya que muchas personas tienen relés autenticados para el correo electrónico saliente y eso, por necesidad, no coincidirá con el servidor entrante. ¡Administradores de correo electrónico, no sean perezosos!)

Por último, pero ciertamente no menos importante, ¡USE REGISTROS SPF! DKIM también. Es posible que muchos de sus problemas de correo electrónico transitorios simplemente desaparezcan después de configurar correctamente esas dos cosas.

Por supuesto, escuche a Shane Madden y revise su cola de correo .

Al final, contacta a los administradores del dominio remoto y resuélvelo con ellos . Puede que tenga que trabajar con ellos para resolver el problema.


Gracias por las respuestas! He realizado las pruebas en testexchangeconnectivity.com y recuerdo que la búsqueda inversa de DNS regresó correctamente.
Lbaker101

Hasta que obtengamos nuestro filtro de correo electrónico (dentro del día siguiente), el registro MX apunta directamente a nuestro servidor de intercambio a través de una IP externa designada. el ASA5505 realiza el reenvío NAT para señalar esto en la dirección interna correcta y se han abierto los puertos de firewall correctos para permitir el tráfico de correo electrónico. Lo investigaré más. ¡Gracias por el consejo!
Lbaker101

3

Verifique su cola de correo en la sección "Caja de herramientas" de la consola de administración de Exchange.

Podrá profundizar en los errores específicos que se generan cada vez que se intenta entregar el mensaje, lo que debería arrojar algo de luz sobre la causa raíz. Encuentre un mensaje de problema específico en una cola de dominio, luego haga clic derecho en el mensaje y abra las propiedades; la Last Errorsección " " es lo que interesa.

Las causas probables son la conectividad del puerto 25 / tcp y los problemas de resolución de DNS, pero edite los errores que encuentre en la pregunta si todavía tiene problemas y podemos ayudarlo a determinar la causa raíz.


Identidad: XXX-XXX \ 4269 \ 19930 Asunto: XXXX ID de mensaje de Internet: <8485BDE284F83A4EB411BC822A8F564EA3F8EC@EFC-XXX.XXX.local> Dirección del remitente: XX@XXX.com Estado: Tamaño listo (KB): 11 Nombre de la fuente del mensaje: de la fuente local IP: 255.255.255.255 SCL: -1 Fecha de recepción: 18/08/2011 6:53:04 AM Hora de vencimiento: 20/08/2011 6:53:04 AM Último error: 400 4.4.7 Mensaje retrasado ID de cola: XXX -XXX \ 4269 Destinatarios: XXXw@XXX.com
Lbaker101

0

Sin más información, esto no parece extraño. Algunos servidores del destinatario implementan controles de límite de velocidad que evitan la inundación de sus servidores. Algunos mensajes pasan de inmediato, otros tienen que esperar (y lo intentan más tarde).

Si este problema es cierto para más del (digamos) 10% de sus correos, entonces tiene problemas con la resolución de DNS, su firewall interno u otras configuraciones de red extrañas que impiden el flujo de correo en su sitio.

Pero esto no tiene absolutamente nada que ver con su configuración MX.



-2

El DNS que estaba configurado en mi servidor de Exchange había sido retirado. Traté de hacer ping a un par de dominios de correos retrasados ​​y no recibí ninguna resolución.

Entré en la configuración de mis redes en el servidor y actualicé el DNS primario y secundario.

Todo comienza a fluir bien de nuevo.

Espero que esto ayude

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.