Cantemos: "Imagine a world... without Spam!"

Advierto que este artículo tiene contenido que talvés no sea accesible a todo el público en general. No quiero decir que esté "bloqueado", sino que el lenguaje utilizado talvés es demasiado técnico y no todo el mundo lo va a entender. Si hace falta aclaración o más información, les invito a exponer sus dudas o comunicarse conmigo a través de mi correo electrónico.
Ah... ¿no tienen mi correo electrónico?... Bueno, será que no me conocen, y de última, ¡ustedes se lo pierden! :-)

Ya queda poco que no se haya dicho con respecto al spam. A casi nadie le hace gracia recibir mensajes de desconocidos que le ofrecen drogas de diversa índole y para varios tipos de dolencias, citas con mujeres necesitadas, provenientes de la nueva Rusia postmodernista, efectivo fácil derivado de una simple transacción bancaria de dinero proveniente de la fortuna familiar de algún líder nigeriano millonario asesinado en alguna revuelta local, y hasta promesas de cambios anatómicos (¡como si uno los necesitara! :-) ). Al respecto de esto último, siempre me quedó la duda: ¿cómo se enteran de que a uno le hacen falta dichos cambios...? :-)

Hace algún tiempo escribí algo sobre el tema, y bastante agua ha pasado bajo el puente desde ese momento. Como implementador de servicios y servidores de correo electrónico para empresas, me he visto involucrado en forma directa (y de hecho, en algunos lugares mayormente he sido el ÚNICO involucrado...) en el diseño de soluciones antispam, y puedo hoy decir que he logrado disminuir la cantidad de spam que llega a las casillas de mis usuarios en forma drástica (en el órden del 98%), a través de la creación de políticas y metodologías de uso de los servicios, así como también a través del diseño, programación e implementación de software específico para estos casos. A pesar de que no es específicamente responsabilidad mía la gestión del spam que reciben mis usuarios (me baso en que el spam que reciben los usuarios es casi siempre una consecuencia del uso que hacen de sus casillas y la forma en que se manejan en Internet), he recibido las quejas de los mismos como si hubiera sido el causante, y eso solo alimentó la idea de que algo debía hacerse, así que por eso estoy aquí (y ustedes leyendo este post).

Desde siempre he estado en contra del spam y he buscado la forma de erradicarlo, más aún en la época en que estuve trabajando en un ISP (Internet Service Provider o Proveedor de servicios de Internet, para los neófitos), cuando el spam todavía no era tan incipiente y virósico como lo es ahora. He investigado el tema durante mucho tiempo, y si bien mis conclusiones no han sido precisamente sorprendentes, lo que sí sorprende es que las soluciones no se hayan implementado aún.

No voy a publicar los valores exactos, pero basado en el análisis de los registros de los servidores que gestiono y de los miles de mensajes de spam que he revisado y catalogado, puedo afirmar sin temor a equivocarme, que aproximadamente el 83% del spam que llega a servidores legítimos (por lo menos en Uruguay) proviene de direcciones IP dinámicas. Del restante 17%, un 9% proviene de proxys o servidores mal configurados (con IP fija, pero con configuraciones erróneas o demasiado permisivas, por razones que varían, desde ineptitud de los administradores, hasta mala práctica deliberada, destinada a permitir el uso de dichos proxys para tales fines), un 3% proviene de servidores web con aplicaciones (formularios automáticos, etc.) mal programadas o configuradas, y el resto proviene de servidores legítimos, algunos de ellos de uso gratuíto.

Estos valores corresponden al 92% del correo electrónico que ingresa a los servidores de correo legítimos en Uruguay. Esto representa un consumo ridículo de ancho de banda en la transmisión de datos que dudo que alguien quisiera recibir, sin contar con el espacio de almacenamiento, poder de procesamiento (CPU) y memoria desperdiciadas en contenido execrable.

Solamente el 8% restante es correo electrónico legítimo, lo cual lleva a preguntarnos hoy día si dicho medio de comunicaciones es razonablemente útil y confiable como para ser usado como hasta ahora en las empresas.

Yo insisto en que sí lo es (o por lo menos, puede volver a serlo), contrariamente a lo que algunos analistas expertos en el tema digan al respecto (supongo que estos expertos tendrán la solución y la querrán vender a un módico precio...). Y también digo que el spam (al igual que el tema virus, algo que trataré en un futuro y no muy lejano post) es relativamente fácil de erradicar, si todos ponemos algo de voluntad en el asunto.

Claro, poner voluntad puede significar que varios sysadmins que hoy día no hacen los deberes se pongan a estudiar un poco y lleven a cabo su trabajo de manera más ordenada y standarizada, que varios ISP que no tienen políticas al respecto del spam o que, si bien las tienen, no las hacen cumplir ni las controlan, empiecen a aplicarlas, y que esos mismos ISP simplemente se ajusten a un standard general que permita establecer sin lugar a dudas el origen de mensajes legítimos y el origen de mensajes spam de forma inequívoca. Nótese que no he puesto en consideración el origen real del problema, que son los spammers en sí mismos (gente que hace spam en forma deliberada) y los usuarios cuyas máquinas se infectan con alguna variante de algún virus diseñado para convertir dicho equipo en un "spam zombie", o sea, una máquina que se encarga de enviar spam, muchas veces sin que el dueño de la misma se dé cuenta (este es un problema que también trataré en el prometido próximo post sobre los virus).

Entonces, si consideramos que la mayoría del spam a nivel mundial se genera en direcciones IP dinámicas, resultaría relativamente fácil bloquear directamente las conexiones desde estas direcciones si estas estuvieran debidamente identificadas. La mayoría de las blacklists que existen, intentan tener catalogadas dichas direcciones, de forma tal de que si un servidor consulta el estado de una dirección IP que se conecta a él en a las mismas, sabrá a ciencia cierta si puede bloquearle la conexión o no. El problema es que como la mayoría de los ISP que administran esas direcciones dinámicas no las identifican de manera apropiada, resulta imposible determinar si dichas direcciones son o no son dinámicas, y eso se traduce en la inexactitud de las blacklists, y a su vez en el bloqueo de servidores legítimos que están listados como si utilizaran direcciones dinámicas, casos denominados "falsos positivos", situación en las que (créanme) no quieren estar.

Se supone que ningún servidor de correo electrónico en el mundo debe tener una dirección IP dinámica, independientemente de que sea posible implementar tal servicio sobre dicho tipo de direcciones. Y aquí voy a hacer un alto para expandir este concepto más a fondo. Si bien no existe una ley al respecto (de hecho existen definiciones que se desprenden de algunos RFC (Request For Comments) y documentos BCP (Best Current Practices), tanto apoyando (incluso intentando dar herramientas que contribuyan al éxito de dichas implementaciones. Cito como ejemplo el RFC 2645) como rechazando dichas prácticas), se debe imponer, por una cuestión de lógica, que una empresa séria que desée utilizar servicios de correo electrónico como medio de comunicaciones institucional, debería atenerse a una política razonable, y dicha política excluye la utilización de una dirección IP dinámica como soporte de su servicio de correo. Si la empresa desea tener un servidor de correo local (léase "dentro del edificio de su empresa"), deberá como mínimo obtener una dirección IP fija donde funcione dicho servidor, o de lo contrario, que dicho servidor local utilice alguna técnica que permita configurar el mismo como esclavo o hijo de un servidor legítimo, geográficamente remoto, pero que permita el relay de las cuentas configuradas en él, y obviamente, evite enviar los mensajes en forma directa por sí mismo.

Si dicha empresa tiene IP dinámica, puedo considerar que el servicio de correo electrónico que utilizan (y que emite los mensajes directamente desde su propio servidor de correo que se ejecuta en esa IP dinámica) no es legítimo y bloquear directamente el acceso al puerto 25 de mis servidores desde la dirección de origen de esta empresa. Si no tienen un servicio con IP fija, no los considero serios, y por lo tanto, como administrador de mi servidor (y en nombre de mis clientes y usuarios), puedo decidir no aceptar conexiones desde allí, con lo cual, esa gente queda excluída de poder comunicarse con mis clientes y usuarios. Simple y efectivo.

¿No le gusta la forma en la que manejo mis servidores? Bueno, está en todo su derecho al pensar diferente, pero le aseguro que mis clientes están mucho más contentos con mi forma de pensar que con la suya... (si quiere un servicio de correo electrónico serio, siempre puede contratarme a mí :-) ).

Muchos se preguntarán: "Pero... si bloqueamos las conexiones desde direcciones dinámicas al puerto 25 de los servidores SMTP, ¿como harán los usuarios que tienen casillas en ese servidor para poder enviar correo a través de él?". Eso significaría que son MIS clientes, y para ellos ya tengo la solución. Es muy simple: implementemos la transmisión de correo electrónico para dichos clientes a través de un puerto extra que provea además seguridad, confiabilidad y seriedad a la instalación. Hoy día resulta ridículo que existan servidores de correo electrónico que no tengan implementado algún sistema de encriptación como SSL (encripta el transporte de datos) o STARTTLS (encripta solo la transmisión dentro del transporte, ver RFC 3207) sobre SUBMISSION (ver RFC 2476), disponibles en los puertos standard para dichos servicios, el TCP 465 (smtps) y el TCP 587 (submission). Naturalmente que dichos servicios exigirán la correcta identificación del usuario que envía el mensaje para permitir el envío, impidiendo el relay a clientes no autenticados y evitando así que los spammers puedan hacer uso de dichos servicios impúnemente (no tendría razón de ser de otra manera, y no sería consistente con los RFC...). Y además, esto implica que los usuarios deben estár enterados de que el servidor que utilizan posee dicha capacidad y deben ser capacitados para el uso y configuración de sus programas clientes de correo (cosa que en la práctica casi nunca pasa).

¿Que ganamos con esto? Permitimos enviar correo electrónico a clientes que utilizan IP dinámicas (mejor dicho, sin restricciones basadas en el tipo o estado de su dirección IP de origen) de forma segura a través de los puertos 465 y/o 587, y bloqueamos conexiones desde direcciones dinámicas al puerto 25, evitando el 83% del spam que hoy circula en Internet.

Para poder identificar las direcciones IP dinámicas de forma exacta e inequívoca, los mismos ISP que asignan dichas direcciones a sus clientes tendrían que definir un standard de nomenclatura en los reversos DNS asignados a dichas direcciones, con lo cual podríamos simplemente decidir si bloqueamos o no las conexiones desde las mismas con una simple consulta previa al servidor DNS para averiguar su clasificación. Con el simple agregado de un prefijo "dip", "dyn" o "dynamic" en los reversos DNS asociados a estas IP dinámicas, el trabajo puede ser fácilmente realizado.

Ahí es donde falla todo este asunto (y donde puede estar la solución también), dado que normalmente los ISP no suelen tener definida una clasificación standard para las direcciones dinámicas, con lo cual resulta practicamente imposible clasificarlas de forma sistemática, y por lo tanto, decidir si las conexiones generadas desde las mismas pueden bloquearse con seguridad o no.

La solución entonces es simple: que se defina un esquema de nomenclatura standard para especificar si una dirección IP es dinámica o no, que los ISP la implementen y que los administradores de servidores de correo decidan si las bloquean o no dependiendo de dicha clasificación. (Escribiría un RFC con eso si no fuera que en U.S.A. este tipo de bloqueos puede considerarse como un ataque deliberado a la libertad de expresión, algo que no está muy bien visto por la legislatura actual de dicho país...).

Con "solamente" eso, ya eliminamos el 83% del spam que circula en Internet.

Por supuesto que esto es solo una de las cosas que los ISP deberían hacer. Sin importar cuantos bloques de direcciones dinámicas manejen, modificar todos los archivos de zona de reversos DNS de esas direcciones puede tardar como mucho unos 2 minutos, aplicando un simple comando "sed" con los argumentos adecuados (asumiendo que el ISP es serio y utiliza alguna implementación decente de servidor DNS como djbdns, BIND o algo similar. Si utiliza el servidor DNS de Micro$soft, bueno... ni hablemos del trabajo y el tiempo que le pueda llevar a ese "administrador" modificar todas sus zonas..., ¡y menos hablar de la seriedad del mismo!).

Además de esto, sería ideal que todos los sysadmins también publicaran registros S.P.F. (Sender Policy Framework, un sistema antispoofing que puede ser utilizado como antispam también, Ver RFC 4408, experimental por ahora, pero 100% funcional) y/o DomainKeys en todos sus dominios, y que todos los servidores de correo electrónico del mundo utilizaran esta información para permitir o denegar el acceso de mensajes hacia las casillas de los usuarios. Por supuesto que esto implicaría modificar muchas de las implementaciones de servidores SMTP que existen, o por lo menos, que esos sysadmins implementen los chequeos S.P.F. y/o DomainKeys antes del servidor (o sea, a nivel de la conexión), a través de algún proxy o similar. No voy a entrar en mayores detalles, porque no quiero que este artículo se convierta en un "HOWTO ANTISPAM" (Internet está llena de esos artículos), y además, un verdadero sysadmin que se precie de tal, ya debería haberse dado cuenta de lo que hablo y/o debería tener solucionado el tema.

Al implementar S.P.F. (y S.R.S., de ser necesario, para resolver un pequeño efecto secundario del uso del S.P.F. cuando uno intenta hacer el forwarding de mensajes (lean el enlace si quieren saber lo que significa esto)) y DomainKeys, se evita el spoofing de dominios, o sea, básicamente nadie podría enviar un mensaje desde un servidor "trucho" que se hace pasar por otro legítimo, ya que estas dos tecnologías aseguran que el servidor que envía el mensaje es legítimo (asignándole el "permiso" de enviar mensajes a nombre del dominio) y evitan que otros usurpen la identidad del verdadero servidor.

Si un sysadmin malintencionado envía un mensaje utilizando un servidor "trucho" que envía mensajes a nombre de un dominio que publica registros S.P.F. y DomainKeys, resulta extremadamente fácil bloquearlo en forma automática. Cualquier mensaje de un servidor no listado en los registros S.P.F., o que no tenga la firma DomainKeys del dominio en la cabecera, puede ser simplemente considerado "forged" (trucho), y por lo tanto, podemos descartarlo sin más.

Esto, eliminaría practicamente casi todo el spam que existe en el mundo (sobre todo el spam que se genera en "PCs zombies", o enviado al barrer desde direcciones dinámicas). Los únicos que seguirían haciendo spam serían los sysadmins que manejan verdaderos servidores de correo electrónico legítimos o los usuarios de esos dominios, y eso sería suficiente para que dichos servidores puedan ser bloqueados al detectarse que han hecho spam (asumiendo que los sysadmins o usuarios de esos servidores lo hacen en forma deliberada), y la verdad es que creo que nadie que tenga un servidor de correo legítimo desea ser bloqueado en estas épocas... Es el equivalente a que construyan un muro directamente en la puerta y ventanas de sus casas, evitándoles salir al mundo.

En definitiva, la solución al tema del spam es simple y es posible. El único problema que hay es que siguen habiendo sysadmins perezosos, ineptos o ignorantes, así como también ISPs que no hacen lo debido (talvés porque contratan a los citados sysadmins...), o que no tienen interés en hacer las cosas bien, o porque tienen acuerdos con spammers, o porque tienen acuerdos con empresas que venden sistemas antispam, o quien sabe... se me ocurren mil razones por las cuales estas cosas sigan pasando. Hay casos lamentables de ISP que dando servicios con IP fija, no permiten o no contemplan la necesidad de modificar los reversos DNS de esas IP según las especificaciones del cliente. Me vienen a la mente varios casos, sobre todo en U.S.A. (el primer productor mundial de spam en TODO el mundo), de ISP que no permiten cambiar los reversos de sus IP fijas.

Lo que no termino de entender es porqué siendo tán fácil hacer estas cosas bien y liberarnos de este flagelo, seguimos quejándonos del spam sin hacer nada (bueno, yo no me quejo... ¡hago! :-) ).

Citaría mil ejemplos malos de administración de sistemas (tenemos uno ENOOORME en nuestra empresa de telecomunicaciones nacional, Antel y su rama de datos, AntelData, y solo voy a nombrar el dominio adinet.com.uy (un claro ejemplo de qué servicio de correo electrónico NO se debe utilizar, ya que se corre riesgo de terminar inundado de spam y virus (UPDATE 19/10/2007: Adinet está publicando registros S.P.F. a partir de hoy, lo cual cambia un poco este panorama. Ver el artículo sobre este asunto.)) y el pésimo manejo que hacen de los reversos de IP de las redes ADSL (todavía hoy agregan bloques que pasan meses sin reversos), aunque mejoraron mucho después de las miles de cartas que varios sysadmins les enviamos al respecto de los listados en blacklists, y ainda mais), y ni que hablar de la legislatura de nuestro país al respecto del tema del spam (y otros llamados "delitos informáticos"), la cual es patéticamente inexistente. Según datos oficiales, el último proyecto de ley que hubo en Uruguay al respecto de los delitos informáticos, fué presentado en el año 1997 por Jorge Pacheco Klein (hijo de Jorge Pacheco Areco), el cual fué archivado sin ser tratado al final de la legislatura (posiblemente siga disponible en algún archivo perdido en las oficinas parlamentarias. Si alguien tiene acceso a dicho archivo, el número de carpeta del proyecto es 2221/1997, repartido 915 de Octubre/1997, datos que pude obtener en el Parlamento). Claro, mejor no tener nada que tener algo como lo que hicieron en Perú, una ley que practicamente legaliza el spam y deja vacíos legales que incluso permitirían que una presunta víctima lucre mediante denuncias falsas contra proveedores de servicios de internet... (Y acá vale la pena aclarar que pasa lo mismo que en todos lados, dado que no se le puede pedir a un legislador que sepa qué es una "dirección IP", tanto en Perú como en Uruguay...).

En fin, quisiera terminar este EXTENSO artículo (por favor, disculpen semejante derroche de su tiempo) con un aporte más: Es necesario que quienes hoy estudian en la Facultad de Ingeniería de nuestro país y que mañana talvés sean administradores de sistemas, se preparen apropiadamente para lo que es el verdadero campo de batalla. Exijan aprender más de redes y servicios de datos. Infórmense y aprendan a ser buenos administradores de sistemas. Cuando tengan acceso a gestionar redes con IP públicas, por favor gestionen los reversos DNS de sus servidores correctamente, sean consistentes en la información que publican en sus servidores DNS. Léan los R.F.C. sobre los servicios que utilicen e implementen, recueden que Internet existe gracias a la documentación escrita en esos archivos. Si gestionan servidores de correo, tengan la amabilidad de publicar y utilizar registros S.P.F. y DomainKeys. Es por su bien y por el bien del resto de Internet. No me obliguen a mandarlos a leer el RFC 1912 (como ya he tenido que hacer con varios amantes del tipo CNAME referidos en los NS(!)...).

Se los aconseja alguien que está algo cansado de lidiar contra la ignorancia, contra la falta de disposición de sysadmins, empresas e ISPs, y sobre todo, SOBRE ABSOLUTAMENTE TODO, ¡contra el maldito SPAM!.