¿Cómo se puede probar un servidor MX de respaldo / secundario?

Quiero configurar un servidor MX secundario usando Postfix, pero me pregunto cuál es la mejor manera de probar esto antes de ponerlo en producción (agregando su entrada MX).

Una forma posible es probarlo con un nombre de dominio completamente diferente, es decir, comprar un dominio como "fake-test-domain.com" y configurar su zona DNS SOLO con este servidor MX de respaldo.

¿De alguna manera más fácil puedo forzar a un servidor de correo a enviar un mensaje a este servidor antes de que aparezca en DNS?

No creo que pueda usar el archivo hosts en el sistema de envío porque eso no emularía un registro MX, ¿verdad?

— thomasrutter
fuente

Simplemente puede habilitar el MX secundario. Siempre que tenga un prio más bajo en los registros MX, no se realizará ninguna entrega, y puede probar como se menciona en @EEAA. Por cierto: tenga en cuenta que los servidores de correo alternativos son trampas de spam. Y si no configura la verificación del destinatario, recibirá muchos mensajes de rebote a lo que utilicen los remitentes de correo no deseado. Es posible que desee configurar un sistema manual o automático que controle las reglas de iptables para el acceso al puerto 25. La mayoría de los servidores de envío tienen un tiempo de aplazamiento de tres días, por lo que es fácil abrir manualmente el puerto 25 de reserva MX solo cuando sea necesario.

— Halfgaar

Me preguntaría por qué crees que necesitas un MX secundario.

— joeqwerty

@Halfgaar si el servidor MX secundario está mal configurado, podría provocar la pérdida de correo en el improbable caso de que un remitente no pueda conectarse al servidor MX primario por cualquier motivo (incluido un problema de conectividad en su extremo). Al menos, si aún no se ha agregado al DNS, entonces un problema transitorio con el primario no causará la pérdida de correo: un remitente solo pondrá en cola el correo e intentará nuevamente más tarde.

— thomasrutter

@joeqwerty Realmente estoy pensando en migrar un servidor de correo a otra máquina, lo que implicará configurar el servidor antiguo para retransmitir al nuevo servidor durante la propagación de DNS (incluso con valores TTL bajos, algunos resolvers se almacenarán en caché durante 30 minutos o más) . Dado que de todos modos tendré que esforzarme para que esta retransmisión funcione correctamente, pensé que también podría crear una configuración de servidor MX de respaldo. Y será una experiencia de aprendizaje. Esto fue solo para dar un poco de antecedentes sobre por qué.

— thomasrutter

Respuestas:

Simplemente use una sesión telnet para probar la entrega de correo electrónico. Como ejemplo,

# telnet host.domain 25
Trying host.domain...
Connected to host.domain.
Escape character is '^]'.
220  ESMTP
HELO example.com
250
MAIL FROM:<user@example.com>
250 ok
RCPT TO:<user2@example.com>
250 ok
DATA

To: user2@example.com
From: user@example.com
Subject: a test message

Test message body.
.
250 ok

— EEAA
fuente

+1: cualquier persona que administre un servidor SMTP pero no pueda ejecutar el protocolo "a mano" en TELNET no tiene derecho a administrar un servidor SMTP.

— Evan Anderson

@EvanAnderson Este es un buen principio general hasta que se trata de probar STARTTLS o cualquier AUTH que no sea PLAIN. Pero sí, en este caso tienes toda la razón.

— thomasrutter

@thomasrutter Yo rutinariamente pruebo a STARTTLSmano, usando openssl s_client -starttls smtp -connect .... Pero estoy de acuerdo en que los métodos de autenticación que no sean PLAIN son problemáticos.

— MadHatter

Cuando telnet no es suficiente o demasiado tedioso, uso SWAKS

p.ej:

 cat email-content.txt | 
 swaks --body - --helo localhost.localhomain --server mail.example.com:25 \
  --auth-user fred --auth-password flintst1 -tls \
  --h-Subject Pebbles  --to wilma@example.org
  --from 'fred@example.biz'

— usuario313114
fuente

sudo apt install swakstrabajó en ubuntu

— Donn Lee