"Lusers2"

Hace un tiempito (algo más de 4 años, mas o menos) que tenemos como cliente a una conocida empresa de publicidad. Arrancamos instalándoles un servidor de correo y un firewall, y hoy tienen también un servidor de archivos instalado sobre Linux, el cual cumple las funciones del antiguo PDC (un "Windos" 2000 Server que me dió muchas satisfacciones... cuando fué apagado definitivamente, ¡por supuesto!).

El asunto es que dicha empresa tiene una fauna autóctona muy particular. Así como en la literatura y en el cine existe el "antihéroe" (una especie de antagonista genérico por definición, un ser execrable, malévolo, inmoral y sórdido), existe también en el mundo de la computación el "antiusuario", un usuario que en realidad niega su condición de tal y hace hasta lo imposible por evitar "ayudar a ayudarse" (en nuestro caso, lo que se llamaría un "luser²", o "luser al cuadrado"). A este género de seres "cuasihumanos" es que pertenece dicha fauna.

Una de las características de estos "lusers²", es que no suelen siquiera leer los mensajes de error (o de horror en algunos casos) que se les presentan de vez en cuando en sus computadoras. Claro, cuando mandan pedidos por correo electrónico al soporte técnico (nosotros), suelen dar descripciones como "che, no tengo internet" (siempre me pregunté como podían llegarnos sus mensajes de correo electrónico si no tenían internet...), o "che, XXXXXX no me anda" ("XXXXXX" es el nombre de una empresa, no "otra cosa" (como un firewall o un servidor), y creo que si no funcionara, ellos no se podrían dar cuenta salvo que fuera porque no los atenderíamos...), o "cuando quiero entrar al sitio de xxxxx me aparece un cartel" (y no te dicen qué sitio web es, cual es la URL exacta, cuál es el "cartel" que les aparece, o te mandan una captura de pantalla de 1280x1024, true color en formato BMP, de esas que pesan 2 o 3 Mb... donde se muestra el navegador a pantalla completa, exhibiendo un texto en fuente tamaño 22 en negrita que dice claramente "Servidor no encontrado").


Y obviamente, con el tiempo, las relaciones humanas - infrahumanos (o debería decir "Soporte - Lusers²") se desmoronan, se corrompen y se generan roces...

Nuestra implementación de Firewall, hace filtrado de contenidos, lo cual significa que cuando el usuario intenta acceder a algún contenido (como ser una página web específica, o un archivo descargable desde Internet, o una imágen, etc.) al que, por diversos motivos, no debería acceder (ya sea por política de la empresa, o porque el contenido es peligroso), el firewall le despliega en el navegador una pantalla descriptiva con todos los detalles de porqué no puede acceder, y además, le indica instrucciones precisas y simples para que pueda hacernos llegar la información sobre el problema, y de esa forma "ayudarnos a ayudarlo", ya sea solucionando el error (si es tal, cosa extremadamente rara) o advirtiéndole que no puede acceder a ese contenido por las razones que aparecen en el mensaje de texto (básicamente lo que hacemos es leerle lo mismo que aparece en la pantalla y que ellos se negaron a leer, y de repente, traducírselo al lenguaje que dichos seres utilizan: por ejemplo, si dice "Acceso denegado", les decimos "No podés entrar porque tu gerente no quiere que entres y punto").

El mensaje instructivo que explica cómo se debe hacer para poder enviar la información del error en el mensaje de reclamo a nuestro mail de soporte, dice exactamente esto:

"SI VA A RECLAMAR EL ACCESO A ESTE SITIO, COPIE Y PEGUE EL TEXTO QUE APARECE DENTRO DE LA PARTE DE COLOR NEGRO A CONTINUACIÓN EN EL MENSAJE DE RECLAMO. CUALQUIER OTRO TEXTO O CAPTURA DE PANTALLA SERÁ IGNORADO, YA QUE EL SISTEMA DE SOPORTE NO PUEDE INTERPRETAR INFORMACIÓN COMO IMÁGENES O ARCHIVOS ADJUNTOS."

Debajo de dicho mensaje, aparecen las razones por las cuales el acceso se denegó (o el mensaje de error que indica el problema que se haya suscitado), dentro de un recuadro con fondo color negro y letras blancas.

Y claro, como es de esperarse, NINGUNO DE ELLOS lee los mensajes explicativos del firewall, a pesar de que están en castellano (lengua materna de la mayoría de dicha fauna) y que están perfectamente accesibles en letras negritas y de colores bien definidos y contrastados con el fondo de dichas pantallas. Así que me tomé la libertad de cambiar el tamaño del texto de las instrucciones para que el mensaje quedara EXCESÍVAMENTE más grande (algo así como 22 puntos, mas o menos) que el resto de los textos (además de agregarle algo de "pimienta" y sarcasmo al mensaje), y ¿saben qué sucedió cuando un luser² se topó con el mensaje?: LO MISMO DE SIEMPRE... pero con la diferencia de que este usuario "pensó" (¿será que "piensan" o será que "imaginan" nomás?) que "XXXXXXX" (recuerden que estos usuarios asumen que "XXXXXXX" es sinónimo de "el firewall", cuando en realidad se trata del nombre de una empresa) había sido hackeado, y volvió a mandar una captura de pantalla del mensaje, igual que siempre, algo que el mensaje EXPLÍCITAMENTE PIDE QUE NO SE HAGA.

Indudablemente, el problema persiste a pesar de mis esfuerzos por evitarlo, lo cual es algo que ya no debería extrañarme.

Y si, trabajan en publicidad, no tienen porqué ser expertos en informática, ni tampoco tienen porqué saber leer, basta con que tengan "ideas" y sean capaces de comunicarlas (talvés mediante pinturas rupestres, mímica o mensajes de correo electrónico con imágenes adjuntas grotescamente voluminosas), así que ¿para qué me caliento?...

Al final, tienen razón, el nabo inadaptado, exigente e intransigente debo ser yo...

"Lusers" y "pringaos"

Si, es así... Me he convertido en un "pringao".

No me molesta tanto en realidad, lo cual atribuyo a mis ganas de explicar y enseñar, pero es cierto que a veces a uno se le complican las cosas y no tiene tiempo para lidiar con detalles como errores de configuración y problemas derivados de la simple y llana ignorancia informática, derivada a su vez del hecho universalmente comprobado de que la computadora se convirtió en un electrodoméstico más de la casa.

Claro, el lavarropa es programable, el video también, algunas cafeteras se pueden programar (¿no se inventó Java para eso originalmente?), entonces cabe pensar que si todos esos aparatos con núcleos "programables" existen en una casa, ¿porqué no puede agregarse a la lista una computadora?.

Una vez discutí con mi cuñado (un usuario standard de PC con ideas erróneas sobre su condición a nivel informático) acerca de las dificultades que presentaban las computadoras en cuanto al concepto erróneo sobre facilidad de uso de la interfaz y el ámplio abanico de funcionalidad que proveen, a lo cual él me expresaba que "tendría que ser más fácil de usar...", a lo que yo le traté de explicar que "no, no es fácil", básicamente porque "la computadora es una herramienta que nunca se diseñó originalmente para el usuario final" (independientemente de lo que diga el amigo Bill). Claro, uno vé Micro$oft Windows y piensa que es una tontería aprender a usarlo, configurarlo y hasta programarlo, pero como todas las cosas relacionadas con la informática, esa "capa de abstracción" que es la interfaz gráfica, aísla y de alguna forma engaña al usuario para que crea lo que ya acabo de explicar.



Así es que en todos lados aparecen "expertos" que después discuten sobre temas complejos (y gritan a vivas voces hartos disparates) como si supieran de qué se trata...

Si te gusta jugar en la computadora, mejor comprate una consola de juegos. Lo mismo si querés escuchar música (comprate un buen equipo de audio), o querés ver películas (comprate un DVD), o incluso, si querés navegar en Internet (comprate un Webpal, o andá a un cybercafé, donde un técnico calificado te pueda ayudar...), pero no te compres una "verdadera" computadora, creyendo que te va a solucionar la vida instantáneamente, y tampoco la compres si no estás dispuesto a malgastar parte de tu vida entendiéndola, y aprendiendo realmente cómo usarla.

No es que yo esté en contra de las computadoras (vivo de eso...), ni de los usuarios finales (a veces, también vivo de eso...), sino que en realidad estoy en contra de "unir" esos dos conceptos irreconciliables, porque de eso es que después nacen los problemas a los que nos enfrentamos muchos de nosotros a diario.

Si, se podría decir que la causa de que yo me haya convertido en un "pringao", es jústamente esa. Me convertí en pringao porque de alguna forma asumí que podía ayudar a la gente que me rodea a abandonar la condición de analfabeto informático con la que todos nacemos, y que iban a entender finalmente que esto no es como se lo vendieron en el lugar donde compraron la computadora.

Las computadoras NO son fáciles de usar, los niños NO las usan para aprender más, y NO, tampoco sirven para hacer "amigos" en internet. Si no fuera que vivo de esto (y que probablemente me quedara sin trabajo si todo el mundo me hiciera caso), les acosejaría que vendieran sus computadoras y simplemente volvieran al correo convencional, la televisión con DVD y las consolas de juegos.
Esas cosas son más fáciles de usar y no se agarran virus, no se "desconfiguran", ni generan horas de tiempo desperdiciado tratando de hacerlas funcionar. Si no funcionan, uno se las lleva al técnico, o las tira y se terminó. No llama al "pringao" para que la "revise" y la haga andar.

En definitiva, el mundo estaría mejor sin "computadoras personales", o mejor dicho, sin "usuarios finales" (nosotros los llamamos cálidamente "lusers"), o talvés sin cualquiera de los dos.

Es cierto, por algo hay que empezar... yo también supe ser un ignorante informático, pero resulta ser que me tomé el trabajo de aprender a usar esta "cosa llena de teclas" y pude cambiar mi condición en base al recurso del estudio y del "ensayo y error", porque me gustaba y porque es lo que decidí hacer con mi vida.

Supongo que es lo que pasa cuando uno tiene un tiempo en esto... Bueno, los dejo porque tengo que ir a revisarle la "compu" al vecino... no sea cosa que se me enoje por estar malgastando su tiempo en escribir en este blog apestoso...

¿Son tán brillantes los "americans" como algunos piensan?

Después del famoso "11 de septiembre", el pánico se adueñó de la gente "común" en USA. El "terrorismo" había dado un golpe que dolió mucho más en la moral y la autoestima, que en otras no menos importantes partes, pero que dejó huellas indelebles en las mentes de la gente.

El gobierno alimentó ese pánico hasta que todo el mundo dijo "¡Si, vayan a donde sea necesario y mátenlos a todos!" (a los terroristas, se entiende). Pero no acabó ahí, el gobierno estadounidense pensó: "Hmmm... esto se puede usar también para aplicar controles internos sobre nuestra población... ¡Creemos una ley para poder controlar, investigar y abusar de nuestra autoridad sin tener que rendirle cuentas a nadie!", y de ahí salió el USA Patriot Act (Uniting and Strengthening America by Providing Appropriate Tools Required to Intercept and Obstruct Terrorism Act of 2001, o sea, el acrónimo más rebuscado, largo y polisémico que se les podía ocurrir, como para que nadie sospechara nada (en esto, son realmente unos genios del Marketing)). Y bueno, como pasa siempre que un gobierno actúa en forma que parece concordante con el sentir de la gente, el Congreso lo votó practicamente sin leerlo.
43 días después del ataque del 11 de septiembre, ya entraba en funcionamiento esta ley, que bien pudo obtener el Record Guiness como la ley aprobada por una organización de más de dos personas en menos tiempo en todo el mundo (¿se dan cuenta de que la burocracia puede ser realmente eficiente cuando el gobierno así lo quiere?).

Y claro, después empezaron los reclamos... El Patriot Act les dá plena potestad a agentes del FBI para revisar registros de bibliotecas públicas, intervenir teléfonos, entrar sin órdenes de cateo a las casas de los ciudadanos y a tomar toda clase de acciones amparados por esa ley, sin necesidad de tener una prueba en contra de ninguna persona. Es más, acuñaron la frase "terrorismo doméstico", para poder darle la dimensión necesaria al asunto y que quede claro que es para proteger a los inocentes de los "terroristas" que actúen dentro del territorio "americanou", pero sin hacer una definición específica de cual es la diferencia entre unos y otros. Si vieron la película "The Siege" (una joya cinematográfica que se adelantó muy poco a su época), talvés se den cuenta de las implicaciones.

Y bueno, después de tanto trajinar, resulta que algunos jueces se dieron cuenta de que algunos de los artículos de dicha ley son inconstitucionales.

Wow, ¿les llevó 6 años darse cuenta?... ¿Será que recién terminan de leer la ley completa (que ocupa unos 450kb (unas 120 páginas)) y que ahora sí pueden determinar que la misma tiene partes tan oscuras y obvias como excremento de elefante en un quirófano?

¡Y hay gente que me discute que los "americans" son lo más grande que hay!

Yo creo que deberían por lo menos cambiar su himno nacional y sacarle la parte esa donde se canta "the land of the free"... :-)

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!.