Y al tercer día…

…mandaron el spam

Dos días de publicar la nota acerca del problema del spam, La Nación se despacha (por segunda vez) con un spam supongo que a todos sus lectores registrados.

Si bien el spam alega lo siguiente:

Le enviamos este e-mail porque en su registración aceptó recibir propuestas de parte de los anunciantes de lanacion.com

la realidad es que nunca acepté recibir propuestas de parte de los anunciantes de lanacion.com (de hecho, sé que no podría haberlo hecho sin pensarlo ya que es un tema que siempre tengo presente cuando me registro en un sitio).

Estoy registrado hace años como lector del diario ya que, al menos en una época, para poder hacer búsquedas o ver el archivo era necesario o al menos conveniente estar registrado.

De hecho, cuando recibí el primer spam que me envió La Nación entré a http://www.lanacion.com.ar/registracion/LN/misSuscripciones.asp como ellos sugerían y verifiqué que tenía todos los checkboxes de envío de mail apagados.

Enfurecido, me fijé en abuse.net cuál era la dirección de contacto para abuso y envié un mail a la misma sólo para recibir un rebote a los pocos días porque no sólo no existe la dirección, si no que ni siquiera existe el dominio attla.net.ar (sospecho que desde que Telmex compró AT&T, de todos modos, la responsabilidad de mantener actualizada la entrada en abuse.net es de La Nación.

No importa, entré a la página del diario y ya no me acuerdo donde encontré un formulario donde hice mi queja… recibí el acuse de recibo… y eso fue todo (hace más de dos meses).

Con lo cual, La Nación, para mí, es un nuevo emisor de spam…

Entrevista completa acerca del spam para el diario La Nación

A continuación reproduzco el texto completo de la entrevista que me realizara Sol Amaya para el diario La Nación

Parte de la misma fue reproducida en la nota Los spams ya representan el 96,5% de los e-mails y no hay leyes que los castiguen publicada el 22 de septiembre de 2008 en la sección Información General .

La entrevista fue un cuestionario que me remitió la periodista el 2 de agosto de 2008 que yo contesté al día siguiente.

Mariano

Como te comentaba por teléfono, estoy haciendo una nota sobre el tema del spam en la Argentina y la falta de legislación al respecto. El contexto en el que se basa esta nota es la reciente modificación a la ley de delitos informáticos, y el último fallo en USA contra un spammer (link a la nota)

Lo que me interesa es saber cuáles son las últimas estadísticas sobre el envío de spam en la Argentina, cómo se puede regular, cómo se perjudica a los usuarios, si hay tecnología suficiente en el país para rastrear el origen del correo basura, etc. Te paso algunas preguntas:

La Nación: Además de algunos fallos, ¿hay alguna legislación que regule específicamente el tema del spam? ¿Cuáles son las penas, en caso de que las haya?

Mariano Absatz: Hasta ahora no hay una regulación específica acerca del spam en Argentina. Hasta donde yo sé, las acciones legales que se han realizado en contra de spammers se han basado en la Ley de Protección de Datos Personales (tambien llamada Ley de Hábeas Data), por la cual vos podés exigir que se borre tu dirección de una base de datos, pero en general no es mucho lo que puede hacer esta ley para combatir el spam (por otra parte, su objetivo no era ese).

En realidad, legislar el tema del spam en forma específica probablemente sea un error, creo que en ese sentido es mejor la Ley 26.388 recientemente sancionada acerca del “Delito Informático“ donde, en lugar de tratar de armar una legislación específica para la tecnología (que será obsoleta en poquísimo tiempo), se han adaptado las normativas generales (el Código Penal) a las nuevas modalidades delictivas.

Si bien no sé si ya hay casos que estén actuando en el marco de esta Ley, creo que el Artículo 9° cubre la falsificación de remitente de un mail (que es una técnica utilizada en la gran mayoría de los spam). También podría interpretarse el envío de spam como entorpeciendo las comunicaciones, lo que está cubierto en el Artículo 12°.

LN: ¿Cómo se hacen estas denuncias? ¿A quién hay que dirigirse?

MA: Respecto de la Ley de Hábeas Data las denuncias hay que hacerlas en la Dirección Nacional de Protección de Datos Personales. Respecto de la nueva Ley de Delito Informático, supongo que hay que hacer la denuncia en la justicia o en una comisaría como con cualquier delito penal… habría que preguntarle a un abogado (si te sirve, conozco algunos que se dedican a estos temas y sin duda saben muchísimo más que yo al respecto).

LN: ¿Cómo obtienen las bases de datos?

MA: Las bases de datos salen de muchos lugares… en principio, parte del negocio de los spammers es vender bases de datos para enviar spam… puedo buscar en mi archivo de spam y encontrar ofertas de este tipo de a decenas por semana, de hecho, el famoso primer juicio a un spammer en Argentina fue por un caso de este tipo.

Estas direcciones pueden salir de distintos lugares:

  • búsquedas en Internet (robots que navegan por las páginas, del mismo modo que hacen los de Google o Yahoo! para indexar sus motores de búsqueda, pero que buscan direcciones de mail y las guardan)
  • campañas de márketing poco claras, muchas empresas, en línea o no te piden que dejes tu dirección de mail sin aclararte que pueden enviarte publicidad y sin contarte que la base de datos con las direcciones de mail la podrían vender (algunas avisan, pero la mayoría de la gente no presta atención y pone su dirección alegremente)
  • venta ilegal de bases de datos con direcciones de mail de bancos, tarjetas de crédito, organismos estatales y privados, etc. En general no es la empresa u organismo en sí que hace la venta, si no un empleado deshonesto. En general, y pese a la Ley de Habeas Data (que justamente protege esto), la mayoría de las empresas y organismos no tiene un control fuerte sobre qué pueden hacer sus empleados con acceso a esta información.

LN: ¿Qué se pone en riesgo a través del spam?

MA: Amén del derecho a la privacidad, hay varias cosas que están en riesgo. Como el costo del envio de spam es infinitamente inferior (para el remitente) que el envío de otro tipo de publicidad, muchas de las operaciones envían mensajes a millones de direcciones donde la mayoría de ellas ni siquiera existe.

El costo de envío, rechazo, almacenamiento, etc queda a cargo del receptor (esto es por el modo de funcionamiento intrínseco del mail en internet), es por esto que los proveedores de internet, empresas y organismos que manejan su propio correo, deben gastar grandes fortunas en equipamiento, comunicaciones, software para filtrado, horas hombre de administración, etc.

Es por esto que usualmente decimos que lo deshonesto del spam pasa por ser publicidad con costo al receptor… ¿qué pasaría si La Nación decide dejar de cobrarle a los anunciantes y pasar la mayor parte del costo del diario al precio de tapa? ¿Cuánta gente pagaría 20, 30, 50 pesos o más por un ejemplar? Eso es lo que pasa con el spam.

Los proveedores de internet (que me dan a mí conectividad y una casilla de correo y, usualmente, algún nivel de filtrado de spam) gastan miles de dólares en equipamiento, software y, sobre todo, operaciones para que a pesar del spam, yo reciba mi correo. Ese costo, el proveedor claramente lo tiene incorporado en el abono que me cobra a mí y a los demás usuarios todos los meses.

LN: ¿Cuál es la finalidad del spam?

MA: Esto ha cambiado un poco a lo largo del tiempo.

Originalmente (hace unos 15 años), la finalidad era meramente publicitaria. Se utilizaba para vender productos o servicios, o, a veces, para difusión de ideas políticas.

Hoy en día se ha transformado también, en muchos casos, en un medio indirecto de ataque o estafa. Se envían mensajes haciéndose pasar por un banco intentando convencerte de que sigas un link y carges tu usuario y clave (esto funciona muy bien y es fácil de hacer); se envían mensajes por cualquier tema (inclusive mensajes que parecen estar relacionados con el bien público o la solidaridad) y se invita a reenviar a todos los contactos incluyendo alguna dirección especial (que es la que recaba las direcciones) o a hacer click en un sitio que probablemente infecte la computadora de quien lo hace; etc.

LN: ¿Quiénes son los principales perjudicados?

MA: El público usuario de internet en general… me atrevería a decir que todos excepto los directamente beneficiados por el spam.

LN: ¿Hay algún antecedente como el caso del neoyorquino que debe ir a prisión por 30 meses por envío masivo de spam?

MA: Sí… en USA hubo varios casos a partir de la sanción de una Ley específica (la CANSPAM)… googleando rápidamente:

Seguro que si hablás con alguno de los abogados que se dedican al tema tienen información más específica.

LN: ¿La argentina es uno de los peores países en lo que es envío de spam?

MA: En ese sentido hemos mejorado relativamente en los últimos años, pero en realidad, creo que lo que pasó es que otros países han empeorado más rápido que nosotros (ya que, en valores absolutos, estamos siempre peor que antes).

Spamhaus tiene un ranking confiable en el que hace 4 ó 5 años teníamos el 5° lugar y ahora no aparecemos en el top ten: http://www.spamhaus.org/statistics/countries.lasso

LN: ¿Cómo se hace para detectar de dónde proviene? ¿Hay tecnología lo suficientemente avanzada?

MA: En general es muy difícil detectar el origen inicial de un spam. Mirando las cabeceras de un mensaje se puede saber por dónde pasó justo antes de llegar a nuestro proveedor, toda información de los puntos anteriores es fácilmente falsificable.

LN: ¿Hay penas para quienes venden las bases de datos?

MA: Creo que sí, están en la Ley de Delito Informático (ver Artículo 8°).

LN: ¿Qué significa que muchos spam se manden desde “Equipos secuestrados“?

MA: Significa utilizar equipos conectados a Internet donde el spammer ha logrado infiltrarse y ejecutar un programa que, de modo similar a un virus, corre sin la autorización o conocimiento del dueño de la computadora.

Dada la cantidad de equipos hogareños conectados 24 horas por día a internet, esto es una gran cantidad de computadoras que están a la merced de spammers y todo tipo de crackers que con mucha facilidad toman control del equipo y lo utilizan tanto para enviar spam como para atacar otros equipos en forma remota.

LN: Desde ya muchas gracias por la colaboración.

MA: Espero que te sirva, Saludos.

La Nación: Nuevos delitos en la Red – Los spams ya representan el 96,5% de los e-mails y no hay leyes que los castiguen

Hoy salió en La Nación la siguiente nota:

Nuevos delitos en la Red

Los spams ya representan el 96,5% de los e-mails y no hay leyes que los castiguen

allí hay algunos datos sacados de una entrevista que la periodista me hizo a través del correo electrónico a principios de agosto y que transcribí aquí con autorización de la periodista.

En primer lugar quiero aclarar que YO NO SOY ABOGADO (IANAL) y nada de lo que digo aquí debe considerarse más allá de la interpretación y visión de un lego interesado en la materia.

Creo que lo primero que hay que entender es que el spam no es sólo un problema tecnológico o legal, si no también un problema social. Hace unos cuatro años esbozamos una propuesta en iCauce.Ar (hoy desactualizada, en parte por falta de tiempo nuestro, en parte por el poco interés real que sucitó en la comunidad de ISPs). Allí dejábamos claro que no puede atacarse uno solo de los ejes. No alcanza con una legislación perfecta ni con un filtro perfecto si no que ambos debían ir acompañados por un compromiso social que debía involucrar a los interesados en el tema (esto incluye tanto a los ISPs como a los usuarios).

Es técnicamente imposible hacer un filtro de spam que no capture mensajes legítimos.

Es más si se lee bien la definición de spam que utilizamos en iCauce.Ar es claro que el mismo mensaje puede ser considerado spam por un usuario y legítimo por otro.

En perspectiva, estoy bastante conforme (como comento en la entrevista) con que no se haya hecho una legislación ad-hoc condenada a la obsolescencia casi inmediata como cada vez que se trata de legislar sobre una tecnología que es volátil. Una ley antispam hace cuatro años probablemente no habría contemplado el phishing o el spam a través de sms.

Desde el punto de vista de la tecnología la limitación más fuerte que hay es que los protocolos que se utilizan en internet para el envío de correo electrónico (SMTP) fueron pensados en un contexto de colaboración entre investigadores, docentes y estudiantes, donde no se pensaba que pudiera haber intención de dañar a los usuarios y las redes.

Internet es víctima de su propio éxito y pensar en una migración a un protocolo totalmente incompatible con los viejos servidores smtp es algo que simplemente no va a suceder (del mismo modo que todavía no es masivo el uso de la versión 6 del protocolo IP).

Hay muchos esquemas y técnicas que pueden mitigar el efecto del spam desde el punto de vista tecnológico, pero en general los spammers siempre están medio paso adelante.

Desde el punto de vista social, mientras no haya nada mejor, lo que podemos hacer es no adquirir bienes y servicios ofrecidos a través del spam.

Pequeña clase teórica sobre protocolos de correo electrónico e Internet

Descargo: Este documento fue escrito originalmente como un mensaje a una lista de correo electrónico cuyo tema es el uso de los acentos, eñes y otros caracteres en los mensajes de correo electonico. Como tal, el documento está bastante desorganizado y escrito a los apurones, su lenguaje es coloquial, está en parte en segunda persona del singular e incluye expresiones en lunfardo. Voy a tratar de pulirlo en una próxima versión.

Por otra parte, en este artículo se nombran productos que pueden ser comerciales, shareware, freeware o de dominio público, en cada caso, se deberá consultar la documentación del mismo para averiguarlo, así como las condiciones y costos de licenciamiento antes de su instalación y/o utilización.

La parte técnica: A lo largo de este documento hay referencias a documentos técnicos, llamados RFC (Request for Comments – Pedido de Comentarios). Todo protocolo estándar de internet debe tener su especificación publicada como un RFC, de todos modos, los RFC‘s se utilizan también como documentos informativos, o inclusive para hacer bromas con respecto a la Internet y su entorno. La lista oficial de estos documentos así como los documentos mismos, se encuentran en el ISI, sin embargo, desde la Argentina, se mantiene bastante actualizada, tanto la lista como los documentos en la UBA

Estos son documentos técnicos, sin embargo, cualquier persona con algún conocimiento de programación debería poder entenderlos, ya que los mismos son bastante accesibles.

Introducción

Voy a tratar de NO hacer una clase teórica como para la facultad, sino como para que se entienda entre usuarios de correo electrónico, si no se entiende, acepto consultas por línea privada, si me parece que la consulta lo amerita, o varias personas hacen la misma consulta, respondo en la lista, si no, por línea privada.

El correo electrónico se divide en dos partes, la composición y lectura, por un lado; y la transmisión, por el otro (en realidad hay una especie de tercer componente del que vamos a hablar más tarde).

Quiénes intervienen en el proceso de envío de mensajes

Para la composición y lectura de mensajes se usa un programa que se llama agente de usuario de correo (mail user agent – MUA). Este programa suele tener un editor de textos, un visor de textos y herramientas que permiten manejar los mensajes, guardarlos en distintas carpetas (folders), manejar un listado de direcciones, etc.

Ejemplos de MUA son Eudora, Pegasus, MS-Internet Mail, el comando mail de Unix, elm, mailtool, etc., etc., etc.

El correo electrónico se maneja por un sistema de almacenado y reenvío (store & forward) por el cual la máquina que origina el mensaje, no necesariamente debe enviarla a la máquina destinataria del mensaje, si no que puede hacerlo a través de una o más computadoras intermedias.

Cada una de estas transmisiones no necesariamente se hace en forma inmediata, sino que puede almacenarse durante algún tiempo en cada una de ellas.

Para transmitir un mensaje de una computadora a otra de estas que estamos hablando (incluyendo la originaria y la destinataria), hace falta un programa corriendo en cada par de computadoras, que se comuniquen utilizando un determinado protocolo. Por otra parte, todas las máquinas de esta serie, excepto la destinataria, deben decidir a qué máquina le enviarán el mensaje (es decir, a dónde se hace el próximo salto); esta tarea se llama enrutamiento (o ruteo, entre amigos) – Ojo, para los que saben algo de redes, no confundir con el ruteo de paquetes de red que hacen los routers.

El programa que realiza estas dos tareas, transmisión de computadora a computadora y ruteo, se llama agente de transferencia de mensajes (*message transfer agent – MTA *); ejemplos de MTA son sendmail, smail, zmailer, etc., obviamente, estos les son menos conocidos, porque son los programas que corren en los servidores.

Antes del advenimiento de la PC al mundo Internet en forma masiva, todos laburábamos en equipos Unix que solían estar prendidos todo el día y podían recibir mail en cualquier momento.

Estos equipos tenían tanto el MTA como el MUA, cuando un usuario terminaba de escribir un mail y le decía al MUA que lo envíe, el MUA simplemente llamaba al MTA (así como desde muchos programas se puede llamar a otro) que estaba en la misma máquina, y el MTA se ocupaba del envío.

Cuando el camino era al revés, cuando el MTA recibía un mensaje y se daba cuenta que era para un usuario en la misma máquina, simplemente lo dejaba en un archivo llamado casilla de correos del usuario (mailbox), que es el archivo que lee el MUA para encontrar los mensajes nuevos.

Ejemplos de MUA que hacen esto son el elm, el mail estándar de Unix, el mailtool de Sun, etc.

El advenimiento de las PCs trajo un par de inconvenientes aparejados, el primero es que las PCs son (o eran) monotarea, es decir, que no pueden tener (al menos no con facilidad) un MTA corriendo todo el tiempo al fondo (in background) y, peor aún, que en general, la gente cuando termina de usarla la apaga; esto hace que si un MTA está tratando de ubicar a esta máquina para mandarle un mail, no la encuentra.

Esto hizo que se creen protocolos de comunicación entre MUA y MTA donde ambos no necesariamente estén en la misma máquina.

El protocolo más usado para esto es POP3 (Post Office ProtocolVersion 3) que es un protocolo bastante simple que se usa para bajar mensajes de un servidor a un cliente.

La mayoría de los MUA de PC usan POP3 para recibir mensajes y para enviar mensajes usan el mismo protocolo que usan los MTA para comunicarse entre sí, solo que no rutean, simplemente envían todos los mensajes al mismo MTA y que ese MTA se ocupe del ruteo. Ejemplos de MUA que hacen esto son Pegasus, Eudora, etc.

El protocolo de Internet que se usa hoy en día entre MTA es el SMTP (Simple Mail Transfer Protocol – Protocolo Simple de Transferencia de Correo), definido en el   RFC-821  .

El formato de los mensajes en sí (encabezados, etc.) está definido en el   RFC-822  .

Un poco de historia antigua…

El sistema operativo Unix tuvo una gran difusión en las universidades norteamericanas durante la década del 70, porque se podía utilizar para fines de investigación sin pagar mucho y los fuentes estaban disponibles para ser corregidos, modificados o para ampliar su funcionalidad.

Para actualizar versiones de los fuentes entre máquinas dispersas por todo el país (del norte) :) se usaban comunicaciones telefónicas con modems de alta velocidad (1200 bps) ;-) .

Para esto se utilizó un comando llamado UUCP (Unix to Unix CoPy) que en realidad es todo un conjunto de comandos y archivos de configuración que colectivamente se llamaron más tarde UUCP (pero con la acepción: Unix to Unix Communication Protocol).

Este mecanismo de copia remota de archivos resultó tan práctico que a alguien se le ocurrió montar un sistema de correo electrónico sobre eso. Así, antes de que los términos MTA y MUA existan, se adoptó el protocolo UUCP como protocolo de transmisión entre MTA ; la comunicación MTAMUA era como comenté más arriba en el ejemplo de Unix.

Cuando la Internet se convirtió en una realidad, se adoptó el protocolo SMTP , sin embargo el UUCP se siguió utilizando sobre enlaces telefónicos.

NOTA: La definición de Internet que voy a utilizar es "el conjunto de computadoras que se comunican entre sí globalmente utilizando el conjunto de protocolos TCP/IP" Para que una computadora esté "conectada a internet" es necesario que esa computadora tenga asignada (aunque sea temporariamente) una dirección IP (eso es un conjunto de cuatro numeritos de un byte cada no que se denotan XX.YY.ZZ.WW) y tiene corriendo un mínimo de protocolos de TCP/IP (de hecho, al menos IP, TCP y UDP). Cuando ustedes conectan la PC de sus casas a través del modem a un  Proveedor de Servicio Internet (ISP – Internet Service Provider), el ISP les asigna una dirección IP temporaria (que probablemente no sepan, ni les interesa, ni es siempre la misma). Ustedes se conectan utilizando un protocolo que se llama SLIP (Serial Line IP) o PPP (Point to Point Protocol); ambos son parte del conjunto de protocolos TCP/IP y son los que se usan para conectar computadoras a través de líneas punto a punto (con o sin modem). El "conjunto de protocolos TCP/IP" que está corriendo la PC en ese momento puede ser el Trumpet, o el PC-TCP, o el que ya viene incluido en Windows 95 o en Windows NT 4.0.

Lo importante de esto es que sepan que cuando están conectados a un ISP, ya sea con Trumpet o con Windows 95 u otro conjunto TCP/IP, la computadora de ustedes está formando parte (temporalmente) de Internet, y yo podría, desde una máquina en la otra punta del mundo conectada a la Internet, tener alguna interacción en tiempo real con ustedes (por ejemplo, chatear).

El hecho de que una computadora esté conectada a Internet, permite que se mantengan varias comunicaciones simultáneas entre esa computadora y otras utilizando distintos protocolos. La computadora podría estar bajando mail de un servidor utilizando POP3, simultánamente, bajando la última versión de un antivirus utilizando FTP, estar conectado como terminal al equipo unix de la facultad en el que se tiene cuenta utilizando TELNET y mirando la última edición de "El País" de madrid en el WWW utilizando el protocolo HTTP; todo al mismo tiempo (el hecho de que todo ande más lento o más rápido no tiene nada que ver, hay varias conexiones TCP/IP al mismo tiempo.

El protocolo UUCP es perfectamente utilizable en una PC con DOS y un modem (o una mac o windows). El protocolo UUCP permite
definir quién hace llamados, quién los atiende y cuándo.

El esquema que se empezó a usar en los comienzos de lo que en ese entonces se llamaba la Red Académica Nacional, consistía en un equipo Unix en el Departamento de Computación de la Facultad de Ciencias Exactas y Naturales de la UBA, con un modem que se comunicaba con los equipos de la red uucp mundial, a los investigadores y docentes que lo solicitaban, se les daba un "nodo" de la red. Es decir, se les asignaba un "nombre de computadora" no un "nombre de usuario" como hacen los ISP.

También se les daba un protocolo UUCP para DOS llamado UUPC/Extended y cuando se creaba la entrada de ese nodo en el equipo de la facultad, se lo configuraba diciendo que siempre iba a llamar la PC al servidor Unix y que el servidor Unix nunca debía llamar a la PC.

El   UUPC/Extended   era (es) una buena adaptación del paquete de unix a DOS e incluía el comando "mail" similar al mail estándar de Unix.

El dueño de la PC podía crear cuentas para usuarios en la misma PC que, si bien no tenían password ni privacidad, permitían que varios usuarios compartan un nodo (por ejemplo varios investigadores de un instituto) sin que tengan que repartirse los mensajes entre ellos a mano.

Como el mail de Unix definitivamente no es un programa fácil de usar, decidimos crear algo para reemplazarlo, de ahí salió el Chasqui, que está basado en los fuentes del mail que venían con el UUPC/Extended pero al que le quisimos agregar la funcionalidad de un elm y la facilidad de uso de los primero programitas con menúes y ventanas (siempre bajo DOS).

Más adelante, gente más capacitada creó un instalador bastante automatizado, y un protocolo de comunicación semi-propietario pero más eficiente que reemplazaba el UUCP (sólo entre el server Unix y la PC) por algo más eficiente sin tocar nada de lo demás.

Ese es el paquete que generalmente se llama Chasqui y que el CCC distribuía a sus usuarios.

Hay que tener en cuenta que la cantidad de nodos era grande, que muchos de esos nodos tenían varios usuarios, que la cantidad de líneas telefónicas era muy chica y que… todavía no existía Internet en la Argentina (salvo el enlace de 9600 bps de Cancillería, anterior a la privatización de ENTel y que la Cancillería no podía brindar a terceros – amén de la lentitud del mismo).

Ahora bien, el problema a resolver a los Chasqui eros, para poder utilizar acentos en sus mensajes de correo electrónico, es reemplazar su MUA sin cambiar el MTA, o cambiar el MTA por uno funcionalmente equivalente.

>En resumen un conjunto Pegasus+“UUCP”:#UUCP-def ya sea para Windows como para DOS, probablemente sería la panacea para los usuarios Chasqui Esta combinación, debería manejar múltiples usuarios (sé que Pegasus los maneja, pero no sé si lo podría hacer a nivel UUCP).

Sé que estas combinaciones existen, pero no las conozco, no sé cuán actualizadas están ni cuán difíciles de configurar son. Habría que probarlo y, si no está bien documentado (cosa harto probable), documentarlo o, mejor aún, hacer un instalador.

Mi tiempo es escaso (de hecho, en la oficina me miran de reojo porque hace media hora que estoy escribiendo un mail), pero puedo prestar apoyo moral.

Bueno, si llegaron hasta aquí los felicito, yo no tengo tiempo para leer todo lo que escribí de nuevo. Creo que todo lo que dije está bien, está un poco desorganizado pero espero que se entienda, les reitero que si me hacen consultas NO LAS MANDEN A LA LISTA y déjenme evaluar a mí las ventajas de hacerlo (e.g. hacer un compendio de preguntas y mandar las respuestas a la lista o algo así, cosa aún más técnicas que ésta, contestarlas por afuera, etc.)

¿Y qué hacemos con los acentos?

El asunto es que SMTP sólo transmite 7 bits (aunque existe el estándar para hacerlo: RFC-1869 , RFC-1652 y RFC-1830, el mismo no está muy divulgado por lo que se recomienda no confiar en ello), y la definición del formato de los mensajes en RFC-822 tampoco nombra el tema.

Como solución a esto, en junio de 1992 aparece MIME (Multipurpose Internet Mail Extensions – Extensiones Multipropósito para Correo de Internet), definidas originalmente en los RFC-1341 y RFC-1342, que ya han sufrido dos revisiones.

MIME permite, entre otras cosas, utilizar algunos conjuntos de caracteres de 8 bits en mensajes de correo electrónico, sin descalabrar la base instalada de servidores SMTP y sin salirse del estándar del formato de los mensajes definido en RFC-822. Esto es muy importante, ya que define una evolución en lugar de una revolución, por lo que el costo del cambio es mucho menor.

MIME también estandariza el formato y codificación de archivos binarios, los mensajes de múltiples partes (que permiten anexar archivos de diverso tipo en el mismo mensaje), partes con imágenes, sonido, etc.

LA solución para el envío y recepción de mensajes de correo electrónico en Internet, es MIME. La Lista Acentos llegó bastante rápido a esta definición y hoy en día se está dedicando a dar soporte a usuarios que no saben del tema, o a problemas puntuales de configuración de los MUA, amén de algunos problemas con servidores de listas.

Junto con otras personas de la “Lista Acentos”#lista_acentos, estamos tratando de armar un pequeño FAQ (Frequently Asked Questions – Respuestas a Preguntas Frecuentes) sobre el tema de cómo usar acentos y otros caracteres en mensajes de correo electrónico. Mientras tanto, hay un muy buen artículo sobre "Internet y el correo electrónico en español" en el sitio de   iWorld, la Revista de Internet   publicada por   IDG Communications, España  .

Para los que les interese leer los protocolos en sí, la versión actual de MIME está dividida en varias partes:

  • La primera parte, en RFC-2045 ,
    define el formato del cuerpo de los mensajes MIME esto es,
    el contenido de los mensajes en sí y los encabezados que lo controlan.
  • La segunda parte, RFC-2046 ,
    define los tipos de medios (media types) que pueden contener dichos cuerpos.
  • La tercera parte, RFC-2047 ,
    define una forma de incluir texto no-ASCII en los encabezados de los mensajes (e.g. una
    eñe en el encabezado Subject: de un mensaje).
  • La cuarta parte, RFC-2048 ,
    explica cómo registrar nuevos tipos de medios y otras extensiones que permite MIME. MIME es un estándar abierto y
    extensible, este documento permite coordinar las extensiones que pudieren surgir.
  • La quinta y última parte, RFC-2049 ,
    da un criterio de "_conformidad mínima MIME y
    algunos ejemplos.

Pequeña reseña de la Lista Acentos

Esta es una lista abierta, creada el 14 de mayo de 1997 con el propósito de que en el plazo de seis meses podamos usar los acentos y las eñes en el e-mail, al menos en el correo electronico y listas de Argentina y del habla hispana.

Los objetivos especificos o tareas de la lista son: (lo que sigue son borradores, es una propuesta a debatir)

  • Reivindicar la posibilidad de usar correctamente nuestra lengua.
  • Localizar los servidores y proveedores que no tienen bien configurados los sistemas.
  • Conversar con los responsables de los mismos para que esten de acuerdo con trabajar para resolver este problema.
  • Contribuir a resolver los aspectos tecnicos para la implementacion de e-mail con acentos y eñes.
  • Que los administradores de red, etc.  puedan exponer en la lista por qué no pueden resolver el problema y los aspectos que consideran insuperables, de manera tal de entre todos buscar una solución.
  • Localizar los servidores y proveedores que tienen resuelto el problema y divulgar su lista, al mismo tiempo invitarlos a participar para resolver el problema de los otros.
  • Saludar públicamente cada servidor/proveedor que resuelve el problema.
  • Ir definiendo, entre los participantes de la lista, los pasos a seguir para el logro del objetivo señalado.

Para subscribirse a la lista, mandar un e-mail a: majordomo@intercol.satlink.net y en el cuerpo del mensaje:

subscribe acentos

(si su browser/mailer entiende la versión extendida de los links mailto: el mensaje se generará automáticamente al hacer click acá )

Para desuscribirse no mandar un mail a la lista, sino a: majordomo@intercol.satlink.net y en el cuerpo del mensaje:

unsubscribe acentos

(si su browser/mailer entiende la versión extendida de los links mailto: el mensaje se generará automáticamente al hacer click acá )

Para cualquier duda o consulta con respecto a la lista dirigirse a Fernando Juan Pisani