Hola colegas,
A raiz 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?
1- 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]
2- 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.
3- 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).
4- 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.
5- 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.
6- 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.
7- Es altamente recomendable que cada registro PTR coincida con un
único FQDN, (obviamente, el del equipo en cuestión al cual debe
apuntar).
8- 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
PD. ¿Que les parece si colocamos esto en el portal para darle un poco
mas de exposición?
--
Este mensaje ha sido analizado por MailScanner
en busca de virus y otros contenidos peligrosos,
y se considera que est� limpio.
______________________________________________________________________
Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba.
Gutl-l@jovenclub.cu
https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
