Página Oficial de la Campaña ASCII Ribbon

Bienvenido a la página oficial de la Campaña ASCII Ribbon. Esta campaña empezó como un esfuerzo local, que con el paso del tiempo ha cobrado fuerza conforme las personas se han concientizado de las reglas básicas del envío de correo electrónico, diferenciándolo del correo electrónico en HTML y del correo electrónico con archivos anexos en formatos propietarios. Debido que a sólo existían un puñado de páginas dispersas en diferentes servidores, sin una página oficial definida, decidimos que algo teníamos que hacer para solucionar este problema. ¡Así nació el sitio www.asciiribbon.org!

Todos estan invitados a pasar la voz sobre esta campaña, y de indicar a otros la dirección de este sitio para que se enteren y obtengan mas información.

¿De qué se trata esta campaña?

Dicho en pocas palabras: Se opone al uso de cualquier tipo de correo electrónico en HTML, y del correo electrónico con archivos anexos propietarios (es decir que solo pueden verse en sólo un tipo de programa evitando su libre lectura). ¿Por que? Existen muchas razones de peso:

• Algunos servicios y clientes de correo electrónico no soportan mensajes en HTML. Esto significa que los usuarios de estos servicios no podrán leer tus mensajes, verán los mensajes en HTML sin formato o incluso solo verán un mensaje de error.
• Otros clientes tienen una pobre o nula capacidad para leer formato HTML (como en los PDA y Smartphones), causando que los mensajes sean inlegíbles.
• Enviar correo electrónico en HTML causa muchos "cuellos de botella" y es muy ineficiente. El tamaño del correo electrónico en HTML es varias veces más grande que un mensaje en texto simple, incluso si no contiene imágenes. Un gran porcentaje de usuarios de Internet tienen acceso por tiempo y/o limite por uso de ancho de banda, si se pasan de estos límites se les cobra extra.
• Los mensajes de correo electrónico en HTML con una imagen de fondo, animaciones de Flash (por ejemplo los creados con el servicio IncrediMail), son un desperdicio de ancho banda, espacio de buzón y tiempo. Descargar unos 200kb o más por un mensaje de correo electrónico que contiene sólo unas líneas de texto es ridículo. El mismo mensaje puede ser enviado en una pequeña fracción de este espacio (como !0.1% del original!) cuando se usa texto simple, diciendo exactamente lo mismo y comunicando exactamente la misma información.
  Usando como ejemplo ilustrativo un mensaje de la vida real (usado con permiso del autor) que contiene muchísimo texto (3 kb), muchos mensajes no son así de largos a menos que alguien escriba su autobiografía a alguien más, la diferencia son 850Kb que no comunican nada:
  

  Message: "AMIGOS SIN ROSTROS~(c/sonido)".
     I     1 <no description>                    [multipa/alternativ, 7bit, 17K]
     I     2 	<no description>        [text/plain, quoted, iso-8859-1, 3.0K]
     I     3 	<no description>            [text/html, 7bit, iso-8859-1, 14K]
     I     4 DOT_Flowersg4a122212222332224221222.jpg  [image/jpeg, base64, 100K]
     I     5 !cid_03f701c31824$5b06d6d0$2edb98c8@cida   [image/gif, base64, 29K]
     I     6 monoset purple344434444554446443444.gif    [image/gif, base64, 10K]
     I     7 BLUEAN~125665557554555.GIF                 [image/gif, base64, 58K]
     I     8 Amigos sin Rostros6111511112211131171  [audio/wav, base64, 635K]
  853 KB total.
  

• Personas que por diversas razones solo pueden accesar a una terminal de texto, personas con discapacidades, ciegos y en general cualquier persona que no pueda usar un sistema con una interfaz gráfica, son incapaces de leer tus correos también.
• Incluso representan una seria amenaza en la seguridad de tu equipo si las "graficas incrustadas" son descargadas de un servidor remoto cuando tu revisas (preview) o abres un correo electrónico en HTML. Las imágenes pueden "llamar a casa" de forma astuta e invisible, por ejemplo, indicando a un servidor de spam una confirmación de lectura con tu dirección de correo electrónico, dirección IP, tipo de navegador, sistema operativo, zona horaria y mucha información extra sobre tu equipo. Todo esto de forma automática con solo ver el mensaje, lo cual hará que los spammers vendan tu dirección a otros spammers... !y seas el blanco sin fin de más SPAM!
  Un ejemplo de la vida real de este tipo de enlaces es el que recibí en mi propio correo electrónico el cual muestro a continuación (no sin antes exagerar un poco el nombre del dominio, no es mi intención atacar a ninguna compañía o individuo aquí):

  <img src="http://www.servidordespam.com/buyersvcs/mensajes_si_leidos.jsptracker?ccode=bs_war_wbe_1" />

  Esto indica que si -mi- programa de correo electrónico inentara desplegar esta imagen, esta contactaría a "servidordespam.com", diciéndoles que el mensaje fué abierto, y si mi navegador de Internet esta configurado por default, les dará mi dirección de correo electrónico dirección IP, tipo de navegador, sistema operativo, zona horaria, (mucha información es transmitida en una cabecera normal de una página web cuando se revisa una página de un servidor) y cualquier otra información que ellos puedan leer con su códigos (cookies, plugins, etc) se envía con en el enlace.... ¿Crees que ellos necesitan de un hacker para violar la seguridad de tu equipo y obtener tu información ilegalmente? !Tu mismo les das toda la que necesitan y gratis!
• Existen muchas razones que las antes mencionadas por supuesto. Muchas más, realmente.

Los mensajes de correo electrónico que contienen archivos anexos propietarios son aún mucho peor. Esta clase de mensaje obliga al destinatario a usar un tipo de sistema opertaivo, programa y/o versión (lo cual pasa seguido con los archivos de "office") para poder abrirlos y leerlos. Tomemos el caso popular de un correo electrónico escrito en un documento de word. La idea de este caso es la de preservar el tipo de texto, fuentes y estilo del mensaje independientemente de quien abra el mensaje. Sin embargo, la mayoría de los clientes de correo electrónico nunca pueden abrir este tipo de mensajes internamente, frecuentemente están limitados a ejecutar word para leer el mensaje, por supuesto si el programa esta instalado o si existe una versión para ese sistema operativo. En caso contrario el destinatario no podría leer el mensaje. El formateado de texto se puede hacer con texto simple, por lo que es un gasto de tiempo y ancho de banda enviar un mensaje en esta forma, sin mencionar que los documentos propietarios muchas veces contienen información personal y del equipo en se redacto el mensaje, muchas veces el remitente no sabe cuanta información privada extra se envía sin su consentimiento en un documento de este tipo.

Argumentos en contra

Algunas personas han argumentado a favor del uso del HTML en los correos electrónicos, porque el texto simple podría ser muy limitante. Sin embargo, esos argumentos estan basados en la falta de conocimiento en qué exactamente es posible hacer con el correo electrónico y que no se puede hacer con el correo en HTML (y propietario o cerrado):

• "Yo necesito tener mi correo formateado en una formato específico/Yo quiero que tenga el mismo diseño gráfico de la compañía": El formato y alineación simple de texto se puede hacer con el texto simple. Si el diseño y colores son de lo más importante, entonces HTML tampoco será suficiente porque siempre se verá en una forma distinta en la máquina del destinatario. Pueden no tener las fuentes necesarias, por ejemplo. En ese caso, por ejemplo para documentos oficiales, uno necesita usar un tipo de documento que sea independiente de la plataforma como un archivo adjunto (por ejemplo. RTF).
• "Yo necesito tener un logo corporativo desplegado en el mensaje": El correo electrónico, por naturaleza, es un medio en texto e intentar poner gráficos dentro del texto esta plagado de problemas. HTML es naturalmente considerado como "la solución" a esto, pero nada de esto es verdad: Desplegar un logo corporativo fallará en varios clientes de correo electrónico, porque no hay una forma estandarizada en HTML para hacer esto sin incluir el gráfico con el mensaje. Cualquier gráfico incluído en el mensaje, es por definición, un archivo adjunto, pero las formas de refrenciar este archivo cambian en cada cliente de correo electrñonico. Por ejemplo, el método de Outlook de específicar imagenes dentro del mensaje usando un marcador "cid" fallará en clientes que no sean Outlook, etc. La otra opción sería especificar un URL a un elemento HTML IMG en línea, pero una buena porción de los clientes de correo electrónico bloquearán los gráficos externos (probablemente por cuestiones de seguridad ya enlistadas antes), y por necesidad necesitaría de una computadora con un cliente de correo electrónico con acceso libre al Internet para obtener el logo, lo cual no es la norma en muchos ambientes coroporativos.
• "El texto simple no puede usar fuentes proporcionales": Usar texto simple no implica o fuerza el uso de una fuente específica en un cliente de correo electrónico. Muy seguido, una fuente de tamaño fijo es por defecto, pero no es un requerimiento. Esta fuente por defecto es elegida para reproducir fácilmente, el formato, de por ejemplo, tablas formateadas con espacios en blanco.
• "No puedo usar extensas líneas de text que no son justificadas/Yo debo usar 72 o 78 caracteres con saltos de línea": Al parecer el RFC2822 especifica que las líneas de caracteres no deben exceder 998 caracteres, con una sugerencia enfática en que se limiten a 78 caracteres, esto sólo aplica al mensaje que esta en el cuerpo del correo electrónico. En muchos casos, esto puede ser una forma en que el mensaje es enviado, pero no es una limitación: Usando MIME, lo cual es sugerido siempre porque te permite especificar diferentes juegos de caracteres/páginas de código para texto (para acentos, caracteres diferentes a los lenguages latinos, etc.), también puedes especificar una codificación de contenido que pueda permitir líneas lagras (que puedan ser justificadas dinamicamente en el cliente del destinatario), por ejemplo usando citas impresas u otros juegos de caracteres que de otro modo interfieren con el transporte del correo electrónico (tu puedes transportar esto usando Base64).
• "Yo estoy oficialmente obligado a incluir un pie de página corporativo en cualquier información de la compañía": Un pie de página corporativo es proporcionado por cualquier cliente de correo electrónico con texto simple que sea certificado en el estandar RFC usando el marcador "signature", también conocido como "tear-off line", y con muchos otros nombres: Un doble dash -- y un espacio en una línea separada. Cualquier cosa debajo de este marcador es una "firma de de pie de página", o "sig block"; muchos clientes, cuando se responde, automáticamente no comentan este pie, previniendo contenido innecesario en las respuesta - algo que no es una opción con los pies de página en HTML. Otra practica común es la poner esta información en una "vcard" adjunta al mensaje, la cual es soportada por casi la totalidad de los clientes de correi - de hecho, usando una vcard se puede añadir la información corporativa a la agenda de contactos personal con un sólo clic del ratón; de nuevo, esto es algo que no es posible con un pie de página formateado en HTML. Finalmente la "netiqueta" recomienda usar en los pies de página texto simple: No texto en formato RTF, HTML o imágenes son permitidos.

¿Qué puedo hacer para ayudar?

¡Qué bueno que lo preguntas!
En este momento puedes hacer algunas cosas para ayudar:

• Primero y lo más importante, configura tu cliente de correo electrónico para enviar sólo mensajes de texto. Un tutorial para Outlook y Netscape puede ser encontrado aquí Thunderbird: aquí.
• Segundo, muestra tu apoyo a la campaña ASCII Ribbon poniendo una firma en los correos electrónicos que envías. Algunos ejemplos son:
  

  ()  ascii ribbon campaign - against html e-mail 
  /\  www.asciiribbon.org   - against proprietary attachments

  
  

                         _
  ASCII ribbon campaign ( )
   against HTML e-mail   X
                        / \

  
  

  O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

  
  ¡Más firmas pueden ser encontradas en la sección de enlaces!
• Tercero, corre la voz sobre lo que el correo electrónico debe ser en realidad y seguir así: Un medio de comunicación en texto simple - que es lo para lo que fue diseñado y es bastante eficiente! Usar texto simple no te limita en ningún sentido; puedes seguir enviando archivos anexos e imagenes a tus amigos y conocidos, esto sólo significa que el contenido de los mensajes esta en un formato que puede ser desplegado correctamente en cualquier sistema.

Enlaces a otros sitios

Esta página no sería posible sin la ayuda de la gente que empezó este esfuerzo. A continuación enlisto algunas (pero seguramente no todas) de las páginas relacionadas con esta campaña que contienen mayor información, más firmas y más ayuda. Si falta alguna página que creas que es indispensable por favor indícamelo.

the semi-official, semi-serious ascii ribbon campaign against gratuitous graphics on the web! (English)
ascii ribbon campaign (English)
7 reasons why html e-mail is evil (English)
ascii ribbon campaign (German)
ascii ribbon campaign (English)
Please, no MS Office documents (multi-lingual)
Rant against HTML mail (English, defunct) [translated in German/auf Deutsch]
Put an end to Word attachments (multi-lingual)
GNU Philosophy: no word attachments (Spanish)

Contacto

Si tienes adiciones, comentarios, quejas, puedes escribirme usando esta forma de contacto.