Correo electrónico - Introducción

Introducción

El servicio de correo electrónico tiene como fin hacer posible el intercambio de mensajes entre usuarios de dicho servicio.

Aunque existen servicios de correo electrónico en redes privadas o diseñadas para ser usadas por un determinado colectivo de usuarios, nos referiremos aquí a lo que se puede denominar como 'correo Internet', que se caracteriza por su alcance casi universal, y es el que casi todos nosotros estamos acostumbrados a utilizar.

Existen semejanzas con el correo postal tradicional:

  • Para cada mensaje, hay un remitente y uno o varios receptores. Normalmente se trata de personas, que hacen uso del servicio mediante algún programa específico (Outlook, Eudora, algún tipo de acceso Web, etc.), aunque tanto emisor como receptor pueden ser sistemas informáticos actuando de forma automatizada.
  • Tanto el emisor como el receptor (fundamentalmente este último, para que sea posible hacerle llegar los mensajes) deben disponer de una 'dirección'. El sistema de correo debe ser capaz de hacerle llegar los mensajes dirigidos a él.
  • Existen aquí conceptos análogos al de 'sobre' y 'contenido' (el mensaje propiamente dicho). Más adelante damos más detalles.
  • El usuario sólo interactúa con elementos cercanos, como el buzón y el cartero en el modelo postal, que aquí se corresponde con el ordenador servidor. Estos servidores están conectados a la Internet global y configurados de forma que hagan llegar los mensajes a su destino, y recibir y hacer accesibles al usuario los dirigidos a él.
  • Los mensajes que llegan a un usuario quedan almacenados en su 'buzón de entrada', donde podrán ser consultados y manipulados cuando éste lo desee. Es por tanto un sistema off-line, en comparación con sistemas on-line como el teléfono o actualmente los chats, por ejemplo, donde la interacción sólo se puede producir si los participantes en la misma se hallan implicados en un mismo momento.

El funcionamiento del sistema de correo electrónico a escala global en Internet está definido en una serie de documentos que definen cada uno de sus muchos aspectos. Los distintos elementos de software que intervienen en el sistema (programas de usuario, intercambiadores de correo entre instituciones, etc.) implementan los estándares que corresponden a su función. De los muchos documentos que definen el correo-e, hay dos principales:

  • RFC2822 (Internet Message Format): Describe el formato de los mensajes .
  • RFC2821 (SMTP: Simple Mail Transfer Protocol): Define el protocolo de intercambio de mensajes entre dos ordenadores.

Estos (o mejor dicho, sus predecesores rfc821 y rfc822) definieron el servicio de correo-e desde sus inicios, que posteriormente se ha visto muy ampliado en funcionalidades, como la posibilidad de incorporar ficheros adjuntos en mensajes, firmarlos electrónicamente, etc.

Los primeros usuarios de correo-e eran las (pocas) personas que tenían acceso a los primitivos sistemas informáticos, complejos y de difícil manejo. El mismo ordenador en el que trabajaban (típicamente de su Universidad, su empresa, etc.) almacenaba sus mensajes de correo, desde él los manipulaban y efectuaban sus envíos.

Desde hace ya años, los usuarios utilizan principalmente ordenadores personales, con potencia suficiente para realizar gran parte de su trabajo en ellos, pero conectados en red (conexión proporcionada por su institución o por algún proveedor de Internet). En este caso, el ordenador en el que el usuario manipula su correo no es el mismo que aquél donde se reciben sus mensajes, por varias razones, entre ellas:

  • Su ordenador personal no está siempre encendido, y un mensaje puede llegar para él en cualquier momento. Es mejor por tanto que se reciban en servidores que siempre están encendidos y conectados.
  • La dirección de correo del usuario especifica (en la parte que hay tras '@', llamada 'dominio') el servidor al que deben entregarse sus mensajes. El sistema de correo no sabe cómo hacernos llegar un mensaje al PC de nuestra mesa, pero sí al servidor encargado de recibir los mensajes de nuestro dominio (típicamente gestionado por nuestra institución o proveedor de Internet).

En los primeros tiempos los usuarios trabajaban en los mismos ordenadores que gestionaban y recibían el correo. Los mensajes llegaban allí, se guardaban en unos ficheros y los programas de correo sólo tenían que acceder a los mismos. Ahora el usuario usa un PC que debe conectarse al servidor para leer sus mensajes.

Toda comunicación entre ordenadores debe regirse por un protocolo, y existen dos protocolos para el acceso desde PCs al correo:

  • POP (Post Office Protocol)
  • IMAP (Internet Messsage Access Protocol)

Posteriormente hablaremos en más detalle de ambos. Por supuesto ambos están bien detallados en una serie de documentos RFC.

Estos protocolos nos permiten acceder a nuestros mensajes almacenados en un servidor. Cuando queremos enviar un mensaje, sin embargo, el protocolo que usa nuestro programa de correo es SMTP, mencionado anteriormente.

Es decir, los programas de correo actuales deben utilizar al menos dos protocolos:

  • POP o IMAP para el acceso y manipulación de los mensajes recibidos (normalmente se contemplan los dos como opción)
  • SMTP para el envío de correo.

Es así porque la función de envío de correo entre nuestro PC y nuestro servidor (que luego se encargará de hacerlo llegar a su destino) es semejante al envío de mensajes entre instituciones, y para eso ya estaba inventado el protocolo SMTP. La función que surgió nueva es el acceso al correo desde un ordenador diferente de aquél donde se almacena, y ahí llegaron POP e IMAP.

Queda por aclarar que al enviar un mensaje, nuestro programa de correo no intenta hacerlo llegar a su destino. En su lugar usa SMTP para entregarlo al servidor de nuestra institución (o proveedor). Éste se encargará de entregarlo. Es así por varias razones, entre ellas:

  •  La tarea es compleja, y es mejor dejarla en manos de sistemas especializados, bien administrados.
  •  El servidor destino puede estar en ese momento apagado. Es necesario entonces retener el mensaje y volver a intentar la entregar más tarde. Si en ese momento apagamos nuestro PC, el mensaje no saldrá. Es mejor que se encarguen máquinas que están continuamente encendidas.
  • Suele ser conveniente pasar un antivirus a los mensajes antes de entregarlos, y es mejor centralizar ese tipo de funciones en servidores corporativos.

Para aclarar mejor las responsabilidades, se usan los siguientes acrónimos:

  • MUA (Mail User Agent). El programa de correo que utiliza el usuario
  • MTA (Mail Transfer Agent). Los programas que se ejecutan en los servidores de las instituciones y que se encargan de hacer llegar los mensajes a su destino y de recibir y almacenar los que llegan para sus usuarios.

Para terminar, vamos a hacer alguna aclaración sobre el significado del concepto de protocolo en Informática. Se podría decir que los ordenadores, como todos los dispositivos, tiene una lógica implacable, pero ninguna imaginación. Cualquier comunicación que se quiera establecer entre dos dispositivos electrónicos debe regirse por unas normas perfectamente especificadas e implementadas en ellos, sea mediante circuitería (hardware) o mediante programación (software). Obviamente siempre tiene que existir un componente hardware en toda conexión entre máquinas, tiene que haber un cable, o unas antenas para emisión y recepción.

Tras este comentario, aclarar que SMTP, POP e IMAP son protocolos: definen una sintaxis de datos que se intercambian entre dos máquinas y una semántica que define el significado de los mismos en las distintas fases de la comunicación, así como las acciones a tomar en cada posible eventualidad. Sin embargo el formato de los mensajes no se considera en este sentido un protocolo puesto que no determina cómo deben comunicarse dos ordenadores, sino cómo se debe interpretar la información transferida. Es decir, define formalmente cómo deben estar 'construidos' los mensajes de correo-e para poder ser procesador por los distintos componentes de la infraestructura de correo, pero no una comunicación 'on-line' entre ordenadores.

Para terminar con esta palabrería, es también muy importante la especificación MIME (Multipurpose Internet Mail Extensions), definida a su vez en una seria de documentos RFC, que es la que permite la inclusión de archivos, documentos multimedia, etc. en mensajes de correo. En línea con lo que venimos diciendo, no se puede considerar un protocolo en sentido estricto, sino una extensión al formato clásico (definido en rfc822 y rfc2822) de los mensajes de correo-e.

Los documentos RFC (Request For Comments), mencionados varias veces, son publicaciones de libre acceso (disponibles por ejemplo en ftp://ftp.rediris.es/docs/rfc) que definen con la mayor precisión posible cada aspecto del funcionamiento (a nivel técnico) tanto de Internet como de las aplicaciones que funcionan sobre ella. El documento rfc-index.txt, actualizado constantemente, contiene la lista de los RFCs.

Conceptos de sobre y contenido

El ejemplo más aproximado a este concepto es una carta de correo tradicional dentro de la cual va un oficio al principio del cual figura remitente y destinatario (y habitualmente también el asunto y la fecha). De todos esos datos lo único obligatorio es la dirección destino que se pone en el sobre, porque si no, el cartero no podría hacerla llegar a su destino. En todos los demás el remitente puede poner lo que quiera, sea verdadero o falso (como ocurre en el caso del Spam o correo basura).

En el caso del correo electrónico existe además el problema de que el usuario sólo se le muestran los datos que vienen en el mensaje (el remitente y destinatario que figuran en el oficio), que como hemos visto, no son fiables.

Este hecho (que tiene sus motivaciones técnicas) no había tenido mayor importancia hasta la época actual, donde el correo basura es una plaga que amenaza seriamente a este servicio, tal como lo conocemos. Es frecuente que en este tipo de mensajes que nos prometen desde vacaciones gratis hasta enriquecimientos fáciles, pasando por propuestas inconfesables, confundan al usuario, que no sabe cómo le ha podido llegar eso ni quién lo ha enviado. O peor aún, que piense que se lo ha enviado alguien que realmente no lo ha hecho.

Cuando se especificó en detalle cómo debía funcionar el correo-e nadie se podía imaginar que llegaría al nivel actual de utilización, por número de usuarios e importancia del servicio. Esto puede provocar aquello tan conocido y lamentable de 'morir de éxito'.

No se diseñó pensando que se podría usar y manipular como lo está siendo hoy día por motivos fundamentalmente comerciales. Apenas posee mecanismos que impidan su uso fraudulento. Se pensaba que la entidad (persona o programa) que envía un mensaje declara en él de forma verdadera tanto remitente como destinatario. Estos datos, como vamos a ver, son por tanto fácilmente falseables.

Como ya sabemos, el protocolo que usa un ordenador para enviar un mensaje a otro es SMTP. Es un protocolo muy sencillo, según el cual el programa que desea enviar un mensaje le indica al servidor el remitente y el destinatario del mismo. Ambos tienen la forma de direcciones de correo.

Luego le entrega el mensaje, constituido por unas cabeceras y el contenido del mismo (que puede ser un simple texto o incluir HTML, ficheros adjuntos, etc.). Las cabeceras constan de un término (de entre una relación de términos definidos en rfc2822 y otros) seguido del carácter ':' y un valor. Entre las cabeceras del mensaje, hay dos muy importantes:

  • From:
  • To:

Estas indican el remitente y el destino, pero, y esto es muy importante, sólo para información del usuario final (y para respuestas, pero esto lo matizamos más adelante).

Las direcciones de remite y destino que se usan en el protocolo SMTP, las primeras que hemos mencionado, se llaman 'direcciones del sobre', y las que aparecen en estas dos cabeceras, 'direcciones del mensaje'. Como hemos dicho, las direcciones del sobre no se muestran al usuario.

Esta dualidad tiene su sentido, por ejemplo en listas de correo. Si estamos suscritos a una llamada ' Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo. ', esa dirección es la que aparecerá en el To:, y nos ayuda a saber que ese mensaje nos llega a través de la lista, que no es un correo personal. Por supuesto, la dirección destino del sobre será nuestra dirección personal.

El servidor decide entonces, en función de una serie de datos (como dirección IP del ordenador que se ha conectado, las direcciones del sobre de origen y/o destino, etc.) y según cómo esté configurado (aspecto éste de gran complejidad) si acepta o no el mensaje. Supondremos que lo acepta.

Una vez recibido, el servidor intenta hacer llegar a su destino el mensaje en función de la dirección de destino del sobre. Si hubiera algún error en la entrega (como que la dirección no existe, etc.) se genera un mensaje de error, que se envía a la dirección de remite del sobre. Si el mensaje se entrega correctamente al usuario, y éste decide responder (pulsando el botón que suelen tener los programas para esto), la respuesta irá a la dirección de remite del mensaje.

De nuevo, esto tiene su justificación. Por ejemplo, en listas de correo el remitente del mensaje es la persona que envió el mensaje a la lista, y está bien que veamos eso cuando se nos muestra el mensaje. Pero si nuestra cuenta tiene un problema que impide que el mensaje nos sea entregado, el error no debe ir a esa persona, sino al gestor de la lista de correo, para que esté informado de este tipo de problemas. Es por ello que en el mensaje que hemos recibido el remitente del sobre es dicho administrador (normalmente será algo como ' Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo. ').

Así vemos que en este ejemplo de lista de correo tenemos un mensaje con:

  • Remitente del sobre: Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.
  • Destinatario del sobre: Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.
  • Remitente en el mensaje: Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo. (quien envió el mensaje a la lista)
  • Destinatario en el mensaje: Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.

En cuanto a las direcciones del mensaje, para que sean un poco más descriptivas, se permiten diversos formatos (en rfc2822). Ejemplos:

  • To: Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.
  • To: Usuarios de GPS
  • To: Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo. (Usuarios de GPS)

De esa forma el programa de correo que usemos puede visualizar el texto en vez de la dirección, o ambas.

En estos tiempos de correos basura, de intentos de estafas con mensaje pretendiendo venir de nuestro banco, de virus, etc., la única cabecera de la que podemos estar seguros de que es auténtica el destinatario del sobre, que debe ser nuestra dirección (en caso contrario no nos hubiera llegado). Las otras tres las pone el remitente, y si es malintencionado, no podemos esperar que sean reales.

En los apartados dedicados a listas de correo y al correo basura mostraremos más ejemplos de algunas de las posibilidades de uso de estas direcciones, unas legítimas y otras no. De todas formas, el remitente del sobre lo podemos ver en la cabecera 'Return-Path' (usando la opción de nuestro programa favorito de correo para que nos muestre todas las cabeceras).

Se puede decir que las direcciones de remite y destino del sobre son para uso de los sistemas de transferencia de mensajes y gestión del correo. Usan el destinatario para hacerle llegar el mensaje, y el remitente para informarle de errores, etc. Las cabeceras del mensaje son para acciones del usuario. La dirección de destino del mensaje es sólo informativa para él, y la de remite se usa para respuestas, por ejemplo (cuando el usuario usa la opción 'Responder' de su programa de correo, la respuesta va a esa dirección, normalmente).