tag - ¿Debe un cliente SMTP proporcionar al MTA un nombre de host globalmente resoluble en el HELO?
resources para mta roleplay (5)
En resumen: estoy tratando de averiguar si debo decirle a un administrador de correo del empleador de un amigo si la configuración de su correo debe ser reparada, o si debo revisar mi propia política para ser más liberal en lo que acepto, o en ninguno de los dos.
Un amigo se quejaba de no poder alcanzar nada en mi servidor de correo. Indagué en ello y parece que el nombre de host proporcionado por su servidor de correo cuando se conectó al mío estaba en algún lugar del *. Espacio local, lo que significa que no se podía resolver de forma global.
Fueron rechazados con "comando de Helo rechazado: host no encontrado"; por mi postfix mailserver. Tal vez soy estricto en mis controles de UCE en postfix, así que incluí en la lista blanca su servidor (en mi opinión, mal configurado) pero ahora estoy tratando de averiguar hasta qué punto están mal configurados, en comparación con si estoy siendo demasiado duro en lo que acepto
Entonces revisé las RFC - RFC 821 dice "El receptor HELO PUEDE verificar que el parámetro HELO realmente corresponde a la dirección IP del emisor. Sin embargo, el receptor NO DEBE rechazar la aceptación de un mensaje, incluso si el comando HELO del remitente falla la verificación " lo que me sugiere que en realidad soy yo quien viola el RFC.
¿Esta parte de RFC 821 alguna vez fue reemplazada por un futuro RFC, que puedo señalar? ¿O deben los servidores de correo aceptar correo con HELO falsos? ¿Hay autoridades muy respetadas que pueda señalar a ese estado que el nombre de host HELO debería ser válido, como referencia para contactar a su administrador de correo?
Como usted cita, el estándar RFC 822 deja el comportamiento hasta el MTA. En estos días, rechazar conexiones en la etapa HELO si el nombre no puede resolverse (y compararlo con una lista negra como spamhaus) es la única manera en que los MTA pueden mantenerse al día con la avalancha de spam generada por las botnets.
Entonces, no hay un estándar que diga que DEBE, pero si no lo hace, su correo electrónico no llegará muy lejos.
Eh, no estoy de acuerdo. Puede proporcionar la basura total dentro de EHLO / HELO si así lo desea. Mientras diga algo, y mientras pueda resolver la dirección IP de la que proviene, estoy contento.
Dentro de EHLO a menudo es un nombre de host corto, no un FQDN.
Estrictamente, ambos violan el RFC.
Las secciones de nota son:
El remitente-SMTP DEBE garantizar que el parámetro en un comando HELO sea un nombre de dominio de host principal válido para el host del cliente.
y
El receptor HELO PUEDE verificar que el parámetro HELO realmente corresponde a la dirección IP del remitente. Sin embargo, el receptor NO DEBE negarse a aceptar un mensaje, incluso si el comando HELO del remitente falla la verificación.
Debido a la prevalencia de correo no deseado, los servidores de correo actualmente son considerablemente más estrictos de lo que los RFC dicen que deberían ser, y es común encontrar todo tipo de controles de propiedad y motivos de rechazo.
Sin embargo, no se están haciendo ningún favor al tener un nombre de host incorrecto en su cadena HELO. Mientras que su servidor de correo probablemente funcionará perfectamente, es probable que el suyo tenga problemas para enviar y recibir correos electrónicos de muchos sistemas.
Yo les haría saber. Si solo por su mala configuración, probablemente no reciban todo el correo electrónico que deberían.
Los SMTP RFC no lo requieren, pero muchos sistemas populares rechazarán el correo con HELO falsos. Tenga en cuenta que tanto RFC 1033 como RFC 1912 requieren que todos los hosts accesibles en Internet tengan un nombre válido; simplemente enumerar ese nombre en el HELO solucionará muchos problemas. Desafortunadamente, algunos filtros de spam también rechazan el correo de nombres de host que contienen cadenas que implican que están en grupos de direcciones dinámicas (por ejemplo, "dinámico", "dsl" o una dirección IP separada por guiones, como es común con muchos ISP).
Una opción si su amigo no tiene control sobre su DNS inverso es usar una máquina adecuada como smarthost para el correo saliente; por ejemplo, el servidor de correo de su ISP.
Sí, deberían. Muchos otros sistemas, incluido Yahoo, rechazarán el correo de los nombres de los hosts que no pueden revertir a la IP de conexión, o que no pueden resolver.