Clase sobre Correo electrónico.
c.1995.
Protocolos de correo electrónico e Internet
Introducción
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: Eudora, Pegasus, MS-Internet Mail, el comando mail de
Unix, elm, mailtool, 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).
– 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,
trabajá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 eran monotarea, es decir, que no pueden tener (al
menos no con facilidad) un MTA corriendo todo el tiempo adefondo (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 crearan 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 se indicó 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:
[email protected] 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:
[email protected] 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
