Adinet y S.P.F. (¡segunda!)

Hace algunos días, publiqué una noticia que hablaba de la implementación de S.P.F. en el dominio adinet.com.uy.

Bueno, la cosa no anda muy bien para estos muchachos, ya que por lo que se puede ver hoy, si uno manda un mail a cualquier dominio utilizando el servicio de correo de adinet.com.uy, se recibirá una cabecera generada por los mismos servidores internos de Adinet, lo cual es casi un grito desgarrador de "¡Error, horror!"...

Una de las reglas que he escrito para mi implementación de Spam Assassin hace referencia a la cabecera Received-SPF, la cual suele tener el resultado de la aplicación del chequeo S.P.F. sobre el mensaje recibido. Esto lo utilizo como un extra para asegurarme de que ningún mensaje que rompa una regla S.P.F. llegue a la casilla del usuario, sino que se vea desviado al repositorio de SPAM específicamente designado para dicho menester. El asunto es que hoy nos avisaron que uno de nuestros clientes no estaba pudiendo recibir mensajes de adinet.com.uy, a lo cual, luego de investigar al respecto, llegamos a la conclusión de que el problema lo causaba dicha regla de Spam Assassin, dado que entre las cabeceras de los mensajes enviados desde Adinet, aparece una entrada que indica un error SoftFail sobre el chequeo de S.P.F.

Dichos headers son elocuentes:

Si se intenta enviar un mail directamente utilizando el servicio SMTP del servidor, sucede esto:

Received-SPF: softfail (smtp-s03.adinet.com.uy: domain adinet.com.uy does not designate 190.64.50.103 as permitted sender)
identity=mailfrom; receiver=smtp-s03.adinet.com.uy; client_ip=190.64.50.103; envelope-from=xxxxxxx@adinet.com.uy; helo=ereshkigal;


Y si se intenta enviar un mail directamente utilizando el servicio webmail (que internamente utiliza el SMTP también), sucede esto:

Received-SPF: softfail (smtp-s02.adinet.com.uy: domain adinet.com.uy does not designate 192.168.2.202 as permitted sender)
identity=mailfrom; receiver=smtp-s02.adinet.com.uy; client_ip=192.168.2.202; envelope-from=xxxxxxx@adinet.com.uy; helo=fe-ps02;

Esto básicamente significa tres cosas:

• Los servidores de adinet.com.uy están aplicando chequeos S.P.F. sobre conexiones de usuarios autenticados (lo cual está mal)


• Los servidores de adinet.com.uy están aplicando chequeos S.P.F. sobre conexiones de servidores internos propios (lo cual también está mal).


• Los servidores de adinet.com.uy no eliminan el resultado interno del chequeo de S.P.F. cuando el mensaje abandona sus servidores para ir hacia otros (lo cual no es tan grave, siempre y cuando los resultados sean positivos, algo que en este caso no se dá).

La implementación correcta de S.P.F. debería ser así:

• Si un usuario se autentica contra el servidor SMTP, su conexión debe pasar totalmente desapercibida por el framework S.P.F. (¿Qué sentido puede tener chequear S.P.F. sobre direcciones IP de usuarios que tienen derecho de utilizar el servidor?)


• Si se trata de la conexión de un servidor interno (con esto quiero decir que ese servidor ES propiedad de Adinet y que se comunica con el verdadero servidor SMTP mediante una IP privada), su conexión deberá pasar totalmente desapercibida por el framework S.P.F. (¿no se supone que esas IP privadas son parte de su "red de confianza" y por lo tanto no deberían ser chequeadas?)


• Si el mensaje está destinado a un servicio externo a Adinet, la cabecera Received-SPF debe o bien removerse, o bien tener un status interno "pass", ya que en realidad el servidor destino que recibe el mensaje deberá hacer su propia evaluación del resultado de la aplicación del framework S.P.F. en forma interna nuevamente, independientemente al resultado que el servidor del remitente haya obtenido. (¿Qué utilidad y confiabilidad puede tener un chequeo S.P.F. realizado en el servidor del remitente, el cual en realidad debería figurar como "permitido" por el registro S.P.F. del dominio para uno poder saber si es legítimo o no?)

(Y mejor ni hablemos de S.R.S. todavía...)

Con esas tres modificaciones al esquema, adinet.com.uy podrá empezar a ser confiable en su uso con respecto a esta tecnología. Seguramente, como la alegría vá por barrios, primero publicaron el registro y después empezaron a implementar la tecnología en los servidores (lo cual es la misma exacta forma en que yo lo hago), pero talvés no tomaron en cuenta las implicaciones del uso irrestricto de este chequeo en casos de uso especiales como lo son estos dos que aquí les menciono.

Claro, estamos hablando de unos cuantos servidores que tienen que manejar unas 400.000 cuentas aproximadamente, lo cual no es un asunto menor, sobre todo si pensamos que esto está sucediendo en Uruguay.

De todas maneras, se aprecia el esfuerzo que estos sysadmin están realizando y esperamos ver pronto resueltos estos detalles menores, propios de una implementación de mayor calibre que el que estamos acostumbrados a ver en este humilde rincón de Internet.

Hay que también agregar que empezaron a hacer chequeos antivirus y antispam directamente en sus servidores, lo cual es un hito importantísimo en la historia de este servicio, ya que comenzará a hacerlo realmente usable para las empresas que aún insisten en utilizarlo para sus comunicaciones comerciales.

¡Sigan adelante, que ya casi, casi lo tienen!