El spam ha llevado a quienes administramos servidores de correo a tomar precauciones para que no abusen de nuestros servidores y molesten lo menos posible a los usuarios que tienen cuenta allí. Esas precauciones van bastante más allá de instalar un sistema anti-spam, estos suelen ser la última barrera (y la más costosa).
Una de las precauciones a tener en cuenta es la configuración del servidor que desea entregarnos correo, llamado el «cliente». Las computadoras que envían SPAM suelen estar en la cuerda floja pues si son demasiado prolijos en su configuración pierden capacidad de adaptación cuando son descubiertos y bloqueados, mientras que los servidores que no envían spam tienen todo el tiempo para ajustar su configuración.
En fin, uno de los chequeos básicos es consultar un servidor de nombres (DNS) para saber si la dirección IP del cliente tiene configurado reverso, es decir resuelve un nombre y si ese nombre corresponde a su IP. En postfix esto se realiza mediante las directivas:
reject_unknown_reverse_client_hostname
Rechaza el correo cuando:
- la dirección IP no resuelve un nombre (no tiene reverso)
- el nombre no resuelve contra la IP (no tiene configurado el directo A)
- el nombre (A) resuelve contra una IP que no es la IP del cliente que se conecta
reject_unknown_client_hostname
Rechaza el correo cuando:
- la dirección del cliente no resuelve reverso con un nombre.
Lamentablemente, las buenas prácticas de configuración, que deberían ser estándar, para un servidor de correo no lo son. Generalmente porque los técnicos a cargo del servidor de correo desconocen o no invierten tiempo en estos detalles; así es que muy seguido me veo en la necesidad de explicar esto.
Detectando un servidor mal configurado
Si el cliente no resuelve un nombre aparece en el DNS:
Nov 6 06:27:55 postfix/smtpd[4944]: connect from unknown[117.6.131.49] Nov 6 06:36:47 postfix/smtpd[9419]: NOQUEUE: reject: RCPT from unknown[201.151.212.105]: 450 4.7.1 Client host rejected: cannot find your hostname,
y es facil de verificar el reverso de una IP con los comandos host o dig:
# host 117.6.131.49 117.6.131.49 does not exist, try again
En el anterior ejemplo no hay ningún nombre configurado para el reverso de esa IP.
# dig -x 201.151.212.105 ;; ANSWER SECTION: 105.212.151.201.in-addr.arpa. 2605 IN PTR static-201-151-212-105.alestra.net.mx. # dig static-201-151-212-105.alestra.net.mx ;; QUESTION SECTION: ;static-201-151-212-105.alestra.net.mx. IN A
En el anterior ejemplo, hay un nombre configurado para la IP, pero luego ese nombre no está configurado para ninguna IP.
Revisando nuestro servidor
Si queremos ver si nuestro servidor está bien configurado, debemos tener en cuenta lo siguiente:
- Verificar la IP del servidor que realmente entrega los correos salientes. Me he topado con Admins que revisan una y otra vez la IP de su MX, y ese es el servidor que recibe los correos.
- Verificar la IP pública con la que el servidor sale a entregar correo. Algunas veces los Admins no saben claramente cuál es la IP pública que toman sus servidores, pues de esto se encargan «los de redes».
Y si bien los comandos host y dig son útiles, muchas veces no tenemos la posibilidad inmediata de revisar nuestra IP desde el universo público («desde afuera»), así que este servicio de Terra para Postmasters nos permite hacerlo.
Así que si Ud. es administrador de servidores de correo (postmaster) y puede colaborar mejorando su configuración, espero este artículo sea de utilidad.
