En la lista de soporte de GUTL salió a relucir un tema sobre el buen comportamiento que deberían seguir los servidores de correo para interactuar con otros ajenos a su red. El tema fue expuesto por uno de la familia de GUTL (Hugo) y me tomé el atrevimiento (haciéndoselo saber primeramente a él en la lista) de traerlo a debate en nuestro portal porque es un tema bastante interesante, dicho esto vamos allá.
A raíz de ciertos ajustes que he realizado en un par de MTAs, he notado que hay servidores que no se comportan adecuadamente al intentar entregar mensajes a otros servidores (en buena medida a causa de un DNS configurado de una manera dudosa).
¿A que me refiero por un «comportamiento adecuado» en una sesión smtp entre servidores?
- El equipo que pretende entregar un correo debe identificarse correctamente con su FQDN, por ejemplo: ehlo nombredelequipo.subdominio.dominio.tld y no simplemente helo PC-SECRETARIA o helo [direccion_ip]
- El FQDN utilizado en el helo/ehlo debería existir en el DNS del remitente, y lo normal es que coincida con el FQDN del registro MX, o al menos con el FQDN de un equipo que realmente esté autorizado a entregar mensajes a nombre de ese dominio.
- El registro MX debería existir, incluso aunque se tenga un registro TXT con una entrada SPF autorizando el equipo (si no se desea que ese equipo reciba mensajes desde el exterior, basta con ponerle una prioridad inferior y ademas impedir en el cortafuegos las conexiones entrantes a dicho equipo).
- El registro MX debe contener un FQDN y no una dirección IP, y obviamente debe tener asociado un registro A (y no un CNAME) que resuelva ese FQDN a su IP correspondiente.
- Jamás debe hacerse un SPF que permita entregar mensajes desde todo un subdominio o dominio, ni desde todas las direcciones de una subred, a menos que realmente sea una subred exclusivamente de MXs o equipos autorizados a entregar mensajes en ese dominio.
- Debería existir un registro PTR para la ip del MX, y en el caso de equipos que están autorizados a enviar aunque no sean MXs (cosa en si un poco dudosa), es una medida de verificación practicamente obligatoria.
- Es altamente recomendable que cada registro PTR coincida con un único FQDN, (obviamente, el del equipo en cuestión al cual debe apuntar).
- El SOA del dominio debe contener una dirección de contacto real en caso de problemas. Si se pretende dejar el valor generalmente por defecto de hostmaster.eldominio.tld, al menos debería hacerse un alias de hostmaster a la dirección de quien sea que gestione el DNS
Como ven, son reglas fáciles de implementar. Puede que se pregunten por qué digo todo esto.
En el mundo de las comunicaciones, hay una regla no escrita: la red de destino no tiene obligación alguna de aceptar un mensaje si no cumple las normas que considera aceptables. Es su potestad, y le toca a los administradores de los sistemas que intentan entregar mensajes a esa red hacer los ajustes necesarios para que al menos los mensajes que se dirigen hacia esa red cumplan esas normas.
Lamentablemente, con la creciente avalancha de spams, intentos de suplantación de identidad y de ataques con métodos de ingeniería social, se hace necesario utilizar normas de verificación un poco más estrictas. A muchos aqui les consta que la OSRI comprueba regularmente la vulnerabilidad de los servicios de correo electrónico, y algunas de las reglas que menciono ayudan a prevenir parte de estas vulnerabilidades.
Obviamente que no deben usarse normas tan estrictas y complejas que se vuelva prácticamente imposible cumplirlas, pero este no es el caso de las que he mencionado arriba, de modo que animo a todos los administradores de sistemas a que revisen sus configuraciones a ver si conseguimos comunicaciones fluidas y relativamente seguras al mismo tiempo.
Y por cierto, si consideran que algo de lo que he dicho es falso o inapropiado, me gustaría ver la argumentación.
Saludos, Hugo
¿Te resultó interesante? Compártelo ...
muy buen comentario @Hyuuga_Neji, me consta porque recién la OSRI me revisó los mios e hizo sus comentarios.
Gracias por tu comentario pero no debería atribuirme el mérito que no me corresponde… quien sacó a relucir el tema en la lista de soporte fue Hugo yo lo único que hice fue traerlo al portal porque considero que un tema como este siempre es bien recibido entre los que tenemos bajo nuestra responsabilidad los servidores de correo y demas servicios.
Hmm, quizás su confusión se debe a que no hay una separación visible entre tu introducción y mi mensaje, o no queda del todo claro que el texto ha sido citado íntegramente sin modificaciones. En fin, realmente no me molesta, lo importante es que se tome conciencia del tema, no tanto que se sepa que fui yo quien lo dijo, jejeje.
Tienes razón… sugerencia aceptada y encerrado el texto dentro del «quote» que indica que es una cita.
Sipe, muchas veces en mi trabajo (Consultor en TI, enfocado en migraciones a FLOSS) al terminar de configurar los server para X empresa me topo que tal dominio no acepta los email, o que no me llegan desde tal dominio… muchas veces es por causas como estas.
Ante tal problema paso a notificar a los administradores por todas las vías posibles, desde la emails en el registro DNS a los lógicos postmaster|admin|administrador|inform@tico@dominio.tld y en muy pocas ocasiones he tenido respuestas y de estas en muy poquísimas ocasiones hay respuestas colaborativas para solucionar el problema…
Un detalle con respecto al HELO/EHLO, en la RFC se especifica que si el host no tiene dominio asociado es válido dejar una IP y listo, por lo que muchas veces un simple (parafraseando) «full_fqdn_helo_required = yes» es por gusto… puesto que muchos clientes (MUA) usan la IP «per se» para quitarse de arriba este problema…
Saludos.
El tema es que lamentablemente el uso de una ip para el helo/helo se pinta ideal para los spammers. En muchos casos ponen la ip del propio mta al cual se conectan y si el administrador de ese mta no ha previsto que esto puede ser una vulnerabilidad, a veces esto les facilita colar un spam. El servidor no llega a ser un open-relay, pero casi.