¿En qué circunstancias (si corresponde) debería un registro MX apuntar a localhost?

Estoy pensando que no hay absolutamente ninguna razón o justificación para esto, pero antes de abrir la boca y obtener algo de kimchi profundo, pensé que debería preguntar.

¿Hay alguna circunstancia en la que un registro MX debe apuntar a una dirección de bucle invertido? Para mí, esto dice que cualquier servidor de correo que intente enviar a este dominio se enviará a sí mismo y fallará, pero no soy un gurú del correo, así que tal vez me estoy perdiendo algo.

Me encontré con lo siguiente cuando solucioné un problema de ¿por qué no estamos recibiendo correo electrónico? problema para un cliente, y estoy teniendo problemas para entenderlo. Sin embargo, tal vez estoy pensando demasiado.

Respuesta corta: no debería.

Respuesta larga: si el dominio en cuestión (DIQ) no debe recibir correo electrónico, al ingresar una dirección de bucle de retorno para el registro MX, el servidor emisor intentará conectarse a sí mismo. Esto ahorra al DIQ unos pocos bytes de medición y posiblemente limpia los registros del firewall (si alguien está mirando) cuando otros servidores de correo intentan conectarse. Sin embargo, en mi opinión, el ahorro de ancho de banda no es suficiente para justificar la violación de RFC 3330.

Definitivamente un NO, no con una IP 127.0.0.0. Todo el rango 127.0.0.0 en IPv4 funciona como direcciones de bucle invertido, por lo tanto, cuando cualquier máquina se conecta a IP en ese rango, intentará conectarse a sí misma.

Su dirección IP de registro MX debe ser accesible desde el mundo exterior y lo que ese resultado le dice a cualquier servidor que realice una consulta MX, para intentar conectarse a sí mismo.

Si mi servidor intentaba enviarle un correo electrónico, buscaría el registro MX y luego conectaría su propia dirección IP, enviaría el correo electrónico y fallaría.

Las RFC relevantes dicen:

• El registro de recursos MX DEBE apuntar a un nombre de dominio completo (no una dirección IP) de un servidor en Internet público que acepte correo para el dominio. Tenga en cuenta que este servidor no necesariamente tiene que estar en el mismo dominio que el registro MX. RFC 1035 sección 3.3.9

• Las direcciones en el rango 127.0.0.0/8 NO DEBEN aparecer en la Internet pública. RFC 5735 sección 3

Tenga en cuenta que algunos servidores de correo rechazarán el correo electrónico de los remitentes que no cumplan con los RFC relevantes .

Cuando un host debe poder enviarse correo a sí mismo a través de diferentes dominios alojados pero no acepta correo externo, "MX 0 localhost". es aceptable. Para indicar que un host no tiene ningún servidor de correo, utilice "MX 0".

El "MX 0". se detalla en RFC7505 .

Bueno, tengo una situación en la que parece ser necesario configurar el MX de un dominio en localhost.

En marzo de 2012 registré un lindo dominio que me sorprendió encontrar disponible. Fue para un sitio de colaboración artística que mi hija quería crear. Configuré el MX en uno de mis otros servidores smtp. Esto funcionó bien, pero luego comencé a recibir muchos rebotes de correo de "usuarios desconocidos" a [email protected] (no el nombre de dominio real). Entonces utilicé MailScanner para bloquear todos los mensajes entrantes a ese dominio, excepto una dirección legítima. Parece que el dominio era un servicio de correo electrónico gratuito a partir de 2001, pero aparentemente se había oscurecido y renunció a su lindo nombre de dominio.

Esto funcionó bien hasta hace un par de días (20/11/12) cuando el servidor smtp comenzó a rechazar los mensajes entrantes debido a conexiones abiertas excesivas. Estos fueron procesos smtp esperando respuestas de "recibo a", creo. Miré el tráfico y me bombardearon miles de mensajes entrantes para [email protected] de la misma cantidad de retransmisiones smtp en todo el mundo. (17,000 mensajes en un período de 24 horas)

Así que cambié el MX para apuntar a otro servidor que no ejecuta smtp con el puerto 25 bloqueado. Efectivamente, miles de sesiones caídas comenzaron a aparecer. Dado que este comportamiento se parece a una especie de torrente de spam, tal vez desde una botnet, pensé que podría requerirse configurar el MX en localhost.

Lo dejaré así por un tiempo. No necesitamos ningún correo electrónico para cute.domain.com, por lo que no se pierde nada excepto los ciclos de la botnet.

¿Por qué no usar un objetivo MX que no resuelve nada? P.ej:

ejemplo.com. EN MX 10 algo inválido.

Los spammers verán el error de resolución y no se molestarán con el próximo registro MX, pensando que el objetivo está mal configurado. Los servidores reales intentarán el próximo registro. Esto no molestará al puerto TCP 25 cerrado de nadie, es decir, sin tráfico smtp, solo DNS.