2 votos

El banner SMTP no coincide con múltiples registros MX

Mi sensación dice "este no es un problema y, lógicamente, no puede ser corregido". Yo soy de la configuración de una copia de seguridad de conexión al ISP para su uso con nuestro servicio de correo de exchange server.

Esto es lo que he puesto arriba:

198.51.100.30 -> primary ISP
203.0.113.40 -> backup ISP

El siguiente añadido a nuestra example.com de dominio DNS:

mail.example.com. A 198.51.100.30
mail2.example.com. A 203.0.113.40
example.com. MX 10 mail.example.com.
example.com. MX 20 mail2.example.com.

PTR añadido por la importancia de los Isp:

198.51.100.30 mail.example.com
203.0.113.40 mail2.example.com

Ahora, nuestro servidor de correo, que siempre ha trabajado con sólo mail.example.com como la flag, todo está bien, MXToolBox es feliz. Sin embargo, ¿qué hago con el banner con respecto a nuestra conmutación por error MX? Obviamente, la conmutación por error PTR es mail2.example.com y va a producir un "Reverse DNS no coincide con SMTP Banner" en MXToolBox.

Que hago no sólo se preocupan de esto o no me he puesto algo correctamente?

EDIT: SSL SAN cert instalado en el servidor de correo tiene tanto mail.example.com y mail2.example.com.

6voto

ivanivan Puntos 357

Usted sólo tiene que preocuparse de lo que el nombre del titular es cuando mail2 se utiliza para enviar un correo de salida. Y en ese caso, debe coincidir con el DNS inversa de la IP que está utilizando. Acerca de la única cosa a la izquierda para comprobar que el nombre propio se usa en cualquier certificados SSL (todos 3 los nombres deben coincidir para cada servidor - banner/helo nombre, nombre en SSL cert, y de búsqueda inversa) y que el servidor de copia de seguridad aparece en cualquiera de los registros SPF, etc. En la medida en que se va, mis registros SPF simplemente una lista de "todos los MXs para este dominio".

Así que, sí, como lo que puedo decir con lo que ha publicado usted debe ser bueno para ir.

2voto

Esa Jokinen Puntos 1735

Sobre las mejores prácticas: tener dos servidores MX

La mejor opción es tener dos servidores es decir, configurar Exchange de otro (o, alternativamente, una opensource basado en servidor SMTP, por ejemplo, Postfix) como una copia de seguridad de secundaria servidor MX. En la mayoría de los casos, el servidor en sí puede causar más el tiempo de inactividad de la conexión a Internet. Como la flag de desajuste es sólo un problema en el correo saliente, este servidor podría perfectamente ser la mail2.example.com en su configuración actual.

Un único servidor con dos conexiones de Internet

Configuración de correo saliente

El segundo enfoque sería tener ambas conexiones configuradas con el mismo nombre de host, como de hecho es el mismo host con IP diferentes direcciones y rutas. Que se podría lograr con un round-robin DNS de la configuración de + la coincidencia de registros PTR & SMTP banner por ejemplo,

mail.example.com. A 198.51.100.30
mail.example.com. A 203.0.113.40
40.113.0.203.in-addr.arpa. PTR mail.example.com.
30.100.51.198.in-addr.arpa. PTR mail.example.com.

No te olvides de agregar un registro SPF permitiendo que tanto la dirección IP para enviar correo, por ejemplo

example.com. IN TXT "v=spf1 +ip4:198.51.100.30/32 +ip4:203.0.113.40/32 -all"

Configuración de correo entrante

Si desea prefiero la primera ISP sobre la secundaria en el correo de entrada (por ejemplo, si tiene un mejor ancho de banda), usted podría separar MX configuración de este por ejemplo, mediante la adición de

mx1.example.com. A 198.51.100.30
mx2.example.com. A 203.0.113.40
example.com. MX 10 mx1.example.com.
example.com. MX 20 mx2.example.com.

La flag de desajuste no es un problema para el correo entrante, por lo que sería perfectamente bien.

Certificado

Para mantener el certificado de validez para ambas configuraciones se debe tener ahora SANs para todos mail.example.com, mx1.example.com y mx2.example.com. Generalmente esto no importa tanto, como certificados del servidor de correo sólo raramente en realidad valitated, y la mayoría de los sistemas de correo todavía permitiría volver a caer en las conexiones sin cifrar.

En lugar de CA basada en la validación de certificados, DNS basado en la Autenticación de Entidades con Nombre (DANE, RFC 6698) es una de las alternativas propuestas, permitiendo la verificación de los certificados auto-firmados, demasiado. Para la compatibilidad hacia atrás no es posible configurar un servidor SMTP para permitir sólo las conexiones cifradas, lo que deja un agujero para los ataques MitM para las conexiones que podría ser establecido a través de TLS. Con el DANE es posible declarar que TLS debe ser utilizado para la conexión y sólo los certificados publicados en la zona DNS debe ser permitido.

1voto

HBruijn Puntos 16577

Tienes razón con su corazonada de que esto no es un problema real debido a dos cosas:

  1. Los registros MX de gobernar en la que desea recibir el correo electrónico de entrada de mensajes de correo electrónico.
    La copia de seguridad del registro MX no está destinado a ser utilizado para enviar correo electrónico, sólo para recibir el correo entrante.

    La recepción de correo electrónico es fácil: a Pesar de que algunos remitentes de tener un poco más estrictos controles sobre, por ejemplo, el contenido de un certificado de compatibilidad hacia atrás casi todos los remitentes simplemente entregar el correo a tus registros MX mientras algo se está escuchando en el puerto TCP 25, responde correctamente a SMTP protocolo de mensajes y está volviendo un "250 Solicitado de correo de acción se ha realizado correctamente la respuesta después de aceptar correo para la entrega a usted.

(Es sólo envío de correo electrónico de forma fiable que requiere, sin duda, mucho más cuidadoso de la configuración y el protocolo de adhesión.)

  1. El SMTP entrante servidor no es necesario que se identifique a todos. Sólo tiene que aceptar los mensajes que desea recibir y rechazar los que no. (Sólo el remitente está obligado a identificarse a sí mismo.)

    Que yo sepa sólo de la propia respuesta SMTP código de retorno número en casi todos los mensajes del servidor es relevante para el propio protocolo. El texto que sigue a la respuesta del servidor SMTP código no sólo en la cabecera, sino también en el error y la mayoría de los otros mensajes sólo es interesante para los propósitos de depuración / interacción humana y que no es relevante en absoluto de un protocolo SMTP perspectiva (y en su mayoría ignorados). Por favor, tenga en cuenta que es sólo para los mensajes del servidor, para luchar contra el spam de los servidores SMTP en sí son mucho más estrictas en lo que se requieren cuando se reciben los mensajes de los clientes/otros servidores de correo.

De RFC 5321 :

Servidor SMTP implementaciones PUEDEN incluir la identificación de sus el software y la información de versión en la conexión saludo respuesta después de la 220 código, una práctica que permite más eficiente aislamiento y reparación de cualquier problema. Implementaciones PUEDEN hacer provisión para Los servidores SMTP para deshabilitar el software y la versión del anuncio donde esto causa problemas de seguridad

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: