Etiqueta: e-mail

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 Protocol – Version 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 MTA – MUA 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