IIS / SMTP: los correos electrónicos están bloqueados en mailroot / Queue

Estoy tratando de enviar correos electrónicos a través de SMTP dentro del directorio de recolección de IIS. Lamentablemente, los correos electrónicos simplemente van a la carpeta mailroot / queue y permanecen allí. En realidad nunca son enviados.

¿Alguien sabe por qué sucedería esto y una posible solución para el problema?

Tuve un problema similar con los archivos atascados en la cola. En el administrador IIS, Servidor virtual SMTP> Propiedades> Entrega> Conexiones salientes. La opción para Limit number of connections tofue verificada y el valor fue 0. Por lo tanto, se configuró para nunca hacer conexiones salientes, lo que hace que los correos electrónicos nunca salgan del servidor. Desmarqué la opción y reinicié el servidor SMTP y todo estaba bien.

Tuve este problema hoy.

Después de reiniciar el servicio 'Protocolo simple de transferencia de correo (SMTP)', comenzó a funcionar nuevamente.

Solo para el registro: tuvimos un caso en el que el servidor ya no podía resolver nombres debido a una configuración de DNS errónea. El comportamiento resultante fue exactamente el que usted describió.

IISRESET me arregló esto. Creo que es similar a la solución de restablecer el servicio SMTP ya que este servicio depende de IIS. ¡Después de que reinició el correo dentro de C: \ inetpub \ mailroot \ Queue comenzó a desaparecer!

Me encontré con este problema recientemente. En mi caso, resultó ser un problema con la definición del servidor DNS en un adaptador de red (esto tiene dos por alguna razón desconocida para mí). El servidor DNS designado se configuró en "127.0.0.1" en lugar del "8.8.8.8" normal que normalmente se usa en esta red. Cambié esto al valor correcto, reinicié mi servidor SMTP y los correos electrónicos en cola se distribuyeron inmediatamente.

Cómo descubrí eso para analizar el problema de la definición de DNS:

• Usé nslookup para encontrar un servidor mx para probar (probé 5 o 6 diferentes)
• Intenté telnet al servidor (cada vez que me encontré con un mensaje de "no se pudo conectar" que me hizo pensar inicialmente en problemas de firewall)
• Intenté hacer ping al valor para el servidor mx probado (cada vez que se encontró con un mensaje de "no se pudo conectar al host")

Espero que esto ayude a alguien más, no era algo que hubiera pensado mirar inicialmente.

En mi experiencia, esto generalmente se debe a que IIS SMTP intenta enviar y encuentra un error temporal (código de respuesta 4xx). ¿Ha activado el registro para el servicio SMTP de IIS y ha revisado el registro? Lo siento si eso es obvio, pero es difícil saber la causa o la solución sin saber lo que muestra el registro.

Creo que el problema podría ser que existe una confusión entre IPv4 e IPv6 en el sistema, por lo que cuando especifica localhost, se elige el protocolo predeterminado de IPv6. Tuve el mismo problema hoy y se solucionó después de que se eliminó la referencia localhost a la dirección IPv6 en los hosts, aunque eso podría haber sido una coincidencia (también estoy configurando SVN). Así que aquí está mi configuración por si acaso:

1. En IIS7 tengo la opción "Entregar al servidor SMTP" habilitada con localhost como mi servidor elegido.
2. En IIS6, tengo acceso configurado a solo 127.0.0.1, sin autenticación para entrantes o salientes.

Jugué con la configuración todo el día, así que, para ser sincero, no estoy seguro de qué más podría haber influido en el hecho de que está funcionando ahora. Sin embargo, espero que esto ayude al menos un poco.

El primer lugar para buscar son los archivos de registro del servidor. Esto le dirá si su servidor tiene problemas para enviar a hosts específicos. La mayoría de las veces esto sucede (en mi experiencia) es generalmente el DNS (ya sea de su parte o de forma remota) que es el culpable.

El servidor SMTP está buscando un host / puerta de enlace SMTP para enviar el correo.

Si está intentando enviar a localhost, entonces la IP localhost sería la puerta de enlace. Si está intentando enviar a una dirección de correo electrónico externa como gmail o hotmail, deberá agregar la puerta de enlace de correo de su ISP como host inteligente.

Para configurar un host inteligente:

1. En el Administrador IIS, haga clic con el botón derecho en el servidor virtual SMTP y luego haga clic en Propiedades.
2. Haga clic en la pestaña Entrega y haga clic en Avanzado.
3. En el cuadro Host inteligente, escriba el nombre del servidor host inteligente. Puede escribir una cadena para representar un nombre o ingresar una dirección IP.
4. Si desea que el servicio SMTP intente entregar mensajes remotos directamente antes de reenviarlos al servidor host inteligente, seleccione la casilla de verificación Intentar entrega directa antes de enviar al host inteligente. El valor predeterminado es enviar todos los mensajes remotos al host inteligente, no intentar la entrega directa.

Tuve el mismo problema después de cambiar el servicio de correo electrónico de un host a otro (uno nuevo es Office 365). Después de muchas pruebas y errores, finalmente comenzó a funcionar haciendo esto:

1. Agregar mi dominio de correo electrónico a IIS 6 como un dominio "remoto". (Este es el dominio alojado en O365 y todas las cuentas de usuario usan).
2. En IIS 6, haga doble clic en ese dominio; en "Enrutar dominio", seleccione "Reenviar todo el correo al host inteligente" e ingrese su servidor (en mi caso, "smtp.office365.com"). También marque la casilla "Permitir que el correo entrante se retransmita a este dominio".
3. En IIS 6, haga clic con el botón derecho en el servidor virtual SMTP> Propiedades.
   • Pestaña General: haga clic en Avanzado y agregue la IP y el puerto 587 de su servidor local
   • Pestaña de acceso: asegúrese de que la casilla "Requerir cifrado TLS" esté marcada. Tuve que crear un certificado de dominio en IIS 7 con el nombre de mi dominio de correo electrónico.
   • Pestaña de acceso: agregue la dirección IP de su servidor local a las listas "Conexión" y "Relé".
   • Pestaña Entrega: Seguridad saliente: seleccione autenticación básica, ingrese las credenciales de un usuario con licencia válida; marque la casilla "Cifrado TLS"
   • Pestaña Entrega: Conexiones salientes: Ingrese 587 para el puerto TCP
   • Pestaña Entrega: Avanzado: ingrese su dominio de correo electrónico como el "Nombre de dominio completo" y su servidor de correo electrónico como el "Host inteligente" (nuevamente en mi caso smtp.office365.com).

Cortafuegos: he leído que necesita abrir el puerto 587 para la salida. (No lo hice porque este es un servidor VOIP que necesita su firewall desactivado).

Office 365: agregue un "conector" en Admin> Exchange para permitir su IP estática local. Microsoft proporciona esas instrucciones en línea.

Me encontré con este problema recientemente. Alguien había instalado MalwareBytes en el servidor smtp y las carpetas de raíz de correo smtp no estaban en la lista blanca. El software trató todo lo que estaba en la cola como una posible campaña de correo no deseado y permitió que se agotara el tiempo suficiente para pasar al correo no deseado. Todos los dominios fueron afectados. Me había intrigado (operación impecable durante años ...) hasta que miré los procesos en ejecución y noté el exe de mbam.

Tuve el mismo problema. Como otros dijeron, estaba relacionado con el DNS. Tengo una zona de búsqueda directa en nuestros servidores DNS internos para nuestro nombre de dominio público (que es diferente a nuestro nombre de dominio interno). Tuve que agregar los registros MX en esta zona interna de búsqueda directa para que coincida con los registros MX en nuestros registros DNS de dominio público. Esto resolvió el problema.