exito ok

whois para nuevos TLDs

Los nuevos TLDs como guru, americanfamily, showtime y muchos otros son un desafío para el comando whois con cierta antigüedad, ya que no los pueden resolver y muestra el error:

No whois server is known for this kind of object.

La solución es configurar un archivo /etc/whois.conf con las referencias a los nuevos TLDs y los servidores whois que los resuelven.

Este gist es un archivo /etc/whois.conf pronto para pegar y tener resuelto el problema para la siguiente consulta whois que se haga con los nuevos TLDs.

El reverso de tu IP no está configurado … ¿el qué?

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:

  1. 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.
  2. 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.

Terra Postmaster Reverso

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.

Empresas uruguayas de primera linea con presencia en internet de cuarta

No se en otras zonas hispanoparlantes, pero por mis tierras cuando decimos que algo es «de cuarta» nos referimos a que es de pésima calidad (ni «de primera», ni «de segunda», ni «de tercera»).

Hace unas semanas que hemos decidido ajustar todos nuestros servidores de correo para cumplir 100% la especificación RFC 1123 para recibir correos electrónicos. Por ello, solo recibimos correo de dominios y servidores correctamente configurados (fully-qualified), realizando los chequeos correspondientes y, de esta forma, contribuír a disminuir el spam y otros correos indebidos (falsificaciones, etc.).

Pero, para nuestra sorpresa, hemos emprezado a rechazar correo de empresas de primera línea (o al menos esa percepción tenemos), que tienen sus servidores de correo configurados en forma lastimosa o directamente ni siguiera configurados.

Al principio, fueron una o dos, pero con el correr del tiempo nuestros clientes nos van informando de más y más dominios que cuando investigamos saltan barrabazadas de no-configuración, muchas veces con servicios tercerizados.

El ejemplo más típico:

correo de @malejemplo.com.uy viene del servidor 66.55.44.33 que resuelve como host.badmail.com pero luego preguntada la IP de host.badmail.com nos dice que ese nombre no resuelve a ninguna IP [not found: 3(NXDOMAIN)]

Todavía tengo algún resquemor de dar nombres y datos. Soy de las personas que confían en el poder de «auto-critica» de los demás y creo que luego de los avisos que estoy cursando, se tomarán las medidas correctivas.

Aunque me lleno de preguntas:
¿es tan difícil preocpuarse de la resolución directa y reversa de su servidor de correo saliente?
¿a quienes contratan para que administren sus servidores?
¿cuánto se ahorran en capacitación? (o en leer el RFC)