Servicio de Informática

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).

Anatomía de un mensaje de correo-e

Como hemos comentado en la introducción, el formato de los mensajes de correo está especificado en el rfc822 y su sucesor, el rfc2822.

Un mensaje está compuesto de dos partes: las cabeceras y el cuerpo. Recordemos que, además del propio mensaje, existe el concepto de 'sobre', compuesto por una dirección de origen (o remite) y otra de destino. Estas últimas son utilizadas por los MTAs, los sistemas encargados de hacer llegar un mensaje a su destino o, en caso de no ser posible, informar de ello a quien origina el mensaje.

Las direcciones de origen y destino 'del sobre' no están habitualmente disponibles para los programas de correo que utilizan los usuarios, que en su lugar disponen de las cabeceras del mensaje. Parte de la confusión de muchos usuarios, en estos tiempos de correo basura, viene de este hecho, pero de eso hablaremos más adelante.

Para entender mejor lo que sigue, aconsejamos que el lector localice en su programa de correo la opción, que casi todos proporcionan, de ver las cabeceras de los mensajes, para así disponer de ejemplos reales.

Un mensaje comienza con las cabeceras, y la primera línea vacía tras ellas marca el comienzo del cuerpo.

Las cabeceras

Cada cabecera consta de un nombre, o identificador, y a continuación, separado de éste por el carácter 'dos puntos' (:), su valor. Si una línea de la parte de cabeceras (esto es, antes de la primera línea vacía, que indica el fin de las mismas) comienza por espacios, se considera que es continuación de la línea anterior.

Los nombres de las cabeceras están determinados en los RFCs, aunque se permite que se puedan añadir otras nuevas, siempre que sus nombres comiencen por 'X-'. Esto se usa por ejemplo en los sistemas antivirus que cada vez más se usan en los servidores de correo, que pueden añadir cabeceras como:

X-Virus-Scanned: by amavisd-new at uco.es

que informan de que el mensaje ha sido analizado por un antivirus y por tanto, si ha llegado a su destino es porque no está infectado (el uso que se pueda hacer de estas cabeceras o la confianza que puedan dar al usuario es otro asunto).

Las principales cabeceras que todo mensaje debe llevar son:

From: Remitente del mensaje

To: Destinatario

Subject: Asunto (breve descripción, típicamente de una línea o menos)

Date: Fecha en que se envió

Hay otras que aparecen a veces:

Cc: Otro/s destinatario/s, además de quien figura en el 'To:'

Reply-To: A qué dirección debe ir la respuesta del mensaje (si la hay). Sólo aparece en caso de que el remitente no desee que se use para eso la dirección que figura en 'From:'

Return-Path: El remitente 'del sobre' del mensaje

Es importante tener en cuenta que la mayoría de las cabeceras (entre las que están todas las importantes), las pone el programa que envía el mensaje, a instancias de la persona que lo utiliza. Pero cuando se trata de mensajes de correo comercial, abusivos o incluso que intentan estafas, no podemos fiarnos de ninguna de esas cabeceras.

Aparte de este tipo de mensajes poco fiables, las cabeceras suelen ser claras de entender, aunque en el caso de los mensajes que nos llegan a través de listas de correo o nos informan de errores producidos, la cosa puede ser un poco más confusa.

Hay otras cabeceras que no han sido puestas por el emisor del mensaje, sino por los MTAs por los que ha pasado hasta llegar a nosotros. Un ejemplo son las que se llaman 'Received:'. Cada MTA (o proceso auxiliar, como antivirus, etc.) por el que pasa un mensaje debe añadir una línea de este tipo. Eso nos sirve para conocer el camino que ha seguido un mensaje, a qué hora pasó por cada sitio, etc...

Desgraciadamente tampoco esas cabeceras son fiables en los casos de mensajes basura, porque pueden haber sido falseadas igualmente. En mensajes legítimos, sin embargo, constituyen una valiosa fuente de información, sobre todo en caso de producirse algún tipo de problema. Cada entidad por la que pasa el mensaje debe añadirle una línea de este tipo ANTES de las que ya hay, de forma que el rastro de un mensaje se sigue comenzando por la última cabecera 'Received:' y de ahí hacia el inicio del mensaje. En mensajes basura, sólo podemos fiarnos de las que han sido puestas por ordenadores de nuestra institución.

El cuerpo

Como hemos dicho, la primera línea en blanco del mensaje indica el fin de las cabeceras y el inicio del cuerpo del mensaje. En los primeros tiempos del correo-e, el contenido consistía en un texto, más o menos breve. No se permitía nada que no fuera texto, de forma que cuando se necesitaba enviar un programa, un fichero PDF o algún otro tipo de fichero binario, era necesario utilizar algún programa que lo 'codificara' en caracteres textuales (imprimibles). El destinatario debía usar el mismo programa para ‘decodificarlo' y extraer así el fichero original. El programa más utilizado en esta primera época (aún hay quien lo usa) fué uuencode/uudecode.

La restricción de no utilizar caracteres no imprimibles aún permanece en las especificaciones del correo-e. Ahora al menos se pueden usar caracteres no anglosajones como vocales acentuadas, ñ, etc. Pero sigue sin poderse enviar tal cual un programa ejecutable o cosas así. Sin embargo se le dio una solución que es la que permite actualmente enviar cualquier tipo de información por correo-e: el conjunto de especificaciones MIME(Multipurpose Internet Mail Extensions).

En resumen, estas especificaciones adaptan el arcaico formato de mensaje a los usos modernos, pero sin alterar en lo fundamental dicho formato original, de forma que un programa de correo antiguo no se vuelva ‘loco’ al recibir un mensaje formado según las reglas modernas, aunque no pueda tratar adecuadamente lo que contiene (en los protocolos de Internet es muy habitual que las mejoras se hagan siempre de forma que no contradigan a las versiones antiguas, al contrario de lo que hacen muchas empresas en sus productos).

Lo que aporta MIME, entre otras cosas que veremos, es algo parecido a lo que hacía uuencode/uudecode, pero sin que el usuario se preocupe de esos detalles. Mediante unas etiquetas especiales que se incluyen en el mensaje, cuyo formato está claramente especificado en el estandar, se indica el tipo de fichero, su nombre, cómo está codificado, etc. También aporta unos mecanismos para adjuntar más de un fichero en un mensaje, etc.

MIME también proporciona un mecanismo que permite que las cabeceras de un mensaje incluyan caracteres con acentos, ñ, etc., algo que inicialmente no se permitía.

El proceso comienza habitualmente cuando un usuario, usando su programa de correo electrónico favorito, escribe un mensaje y lo envía a un destinatario, indicando la dirección de correo de éste.

En primer lugar, el programa compone un mensaje válido conforme a las indicaciones del rfc2822 (Ver "Introducción al Correo Electrónico" y "Anatomía de un mensaje de correo-e"). Para ello antepone unas cabeceras al texto escrito, y posiblemente codifica éste de alguna forma. Si el mensaje incluye ficheros adjuntos, compone el mensaje según la especificación MIME.

Lo siguiente en entregar este mensaje a un ordenador de nuestra institución, o de nuestro proveedor de acceso a Internet, que es quien se encargará de hacerlo llegar a su destino. Ya hemos mencionado en la Introducción las razones por las que el programa de usuario no se hace cargo de esa tarea. Para esta entrega, establece una comunicación según el protocolo SMTP con el ordenador que tengamos configurado en el programa en el apartado 'Servidor de correo saliente', 'SMTP server' o algo parecido, según el programa que usemos.

- Mediante dicho protocolo, nuestro programa proporciona al servidor tres cosas:

- La dirección de correo-e de quien envía el mensaje (dirección remite del sobre).

- La dirección destino. Pueden ser una o varias (dirección/es destino del sobre).

- El mensaje en sí, incluyendo las cabeceras.

El servidor normalmente aceptará el mensaje (más adelante veremos las causas por las que un servidor SMTP puede no aceptarlo) y lo pondrá en su cola de trabajos (mensajes a enviar) que puede estar más o menos cargada según el tráfico que soporte, aunque habitualmente ningún mensaje se retrasa más de unos segundos.

Que el mensaje sea aceptado no significa que vaya a ser entregado finalmente, pues tanto este servidor como otros por los que puede pasar el mensaje en el futuro en el camino a su destino, pueden estar configurados para someter los mensajes que procesan a filtros como por ejemplo:

- Detectar si tienen virus

- Intentar detectar si es correo basura o ilícito

- Si su tamaño es superior a un umbral permitido

- En el caso del MTA final, puede ocurrir que la dirección no exista (por ejemplo, hemos enviado a ' Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.', sin darnos cuenta del error en la dirección, que hasta que no llega el mensaje al MTA de 'univer.es' no se detecta el problema) o que haya algún problema técnico que impida su entrega.

En el caso de no pasar alguno de estos filtros de un MTA, éste normalmente genera automáticamente un mensaje de correo-o de error que envía al remitente del sobre. Decimos 'normalmente' porque en los casos de virus o correo ilícito el servidor puede estar configurado para no enviar estos mensajes, ya que en esos casos la dirección de remite suele ser falsa y no merece la pena su envío, pues puede que no llegue a ningún sitio o, peor aún, que los autores del mensaje fraudulento (o el virus que lo genera y envía) hayan puesto como dirección de remite la de alguien inocente, con lo que enviarle a éste un mensaje de error no haría más que confundirle.

Supondremos en lo que sigue que el mensaje es válido, dejamos para otro documento los casos de fraudes y correo basura.

El servidor que ha recibido el mensaje antepone una cabecera 'Received:' (Ver "Anatomía de un mensaje de correo-e") a las que ya existan, indicando de qué ordenador ha recibido el mensaje y la fecha y hora.

A continuación tiene que decidir qué hacer con él, y lo hace en función de la dirección destino del sobre. Si hay varias, típicamente actuará como si fueran varios mensajes, uno destinado a cada dirección final. Supondremos el caso de un sólo destinatario.

La decisión de lo que hacer, más concretamente, se basa en la parte 'dominio' de la dirección, es decir, lo que va a continuación del carácter '@'. Entre los parámetros de configuración de un servidor SMTP (un MTA), suelen figurar:

- El dominio o los dominios para los cuales es el responsable final.

Ejemplos:

- El MTA de la UCO sabe que los mensajes dirigidos a direcciones del tipo ' Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.' debe entregarlos al usuario 'xxx'

- Una empresa usa direcciones del tipo ' Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.', y su correo es gestionado por un proveedor de servicios de Internet (un ISP), llamado por ejemplo Poptel. El MTA de Poptel sabe que debe entregar los mensajes dirigidos a ' Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.' a un buzón local (cuyo usuario y clave posee el cliente, esa empresa), lo mismo que a todos los demás dominios que gestione (aparte de los mensajes a ' Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.', para su personal o sus direcciones de contacto).

Más adelante explicamos cómo saben otros MTAs que los mensajes dirigidos a ' Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.' deben ser entregados al MTA de Poptel (adelantamos que para eso se usan los registros MX de DNS).

- Otros dominios para los cuales es intermediario.

Ejemplo:

En las Universidades y otras instituciones cada vez es más frecuente que sólo se permita la entrada de correo a través de un único MTA, aunque haya Departamentos, servicios, etc. que gestionen su propio servidor de correo para sus usuarios, con direcciones tipo ' Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.'. Esos mensajes deben llegar al único MTA de entrada (el mismo encargado del dominio Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.') y éste lo hará llegar luego al MTA gestionado por el Servicio. Como en el ejemplo anterior, los registros MX son los que hacen que esos mensajes entren por el MTA 'oficial'.

Si el dominio del mensaje no está en ninguno de esos casos, debe entonces averiguar a qué MTA debe pasárselo. Se dan dos casos principales:

- Delegue su entrega a otro MTA local de nivel superior. Esto es poco frecuente. Se da en instituciones con cierta complejidad, con jerarquías de MTAs. Por ejemplo, una empresa con varias sedes, cada una con un MTA para recibir el correo enviado por sus usuarios locales, puede desear que todo el correo que salga de su organización hacia fuera pase por un MTA especialmente configurado. En ese caso los MTAs regionales no realizan entregas finales (salvo a sus usuarios locales).

- El MTA debe hacer llegar el mensaje a su destino.

En el segundo caso, se realiza una consulta a DNS (Domain Name System).

Ésta es una base de datos global conocida por su papel de traducir nombres de ordenadores a direcciones IP. Los programas de usuario usan nombres para referirse a máquinas (por ejemplo, www.elpais.es), pero los sistemas operativos de los ordenadores necesitan conocer su dirección IP para conectar con ellos. De eso se encarga el DNS. Pero tiene otro uso: nos puede decir qué ordenador debe recibir el correo destinado a un determinado dominio, usando los llamados registros MX (Mail eXchanger).

La persona o entidad responsable de un dominio registrado en Internet, puede incluir en los registros DNS de dicho dominio, ese tipo de registros. En el ejemplo que mencionamos antes de 'empresa.com', vimos que posiblemente por falta de medios técnicos, el correo dirigido a ella debía ser recibido y gestionado por la empresa Poptel. Eso se consigue incluyendo en los registros DNS de 'empresa.com' uno del tipo MX declarando que el correo destinado a Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.' debe ser entregado al MTA de Poptel.

Si para un dominio no existe registro MX, los MTAs entienden que la parte de cominio de la dirección es el propio ordenador que gestiona un MTA. Por ejemplo, hay que enviar un mensaje destinado a ' Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.'. Si 'tricorp.com' no tiene en DNS ningún dominio MX, se entiende que el MTA responsable del mismo (y por tanto, el ordenador con el que hay que establecer la conexión SMTP para entregar el mensaje) es 'tricorp.com' (cuya dirección IP sí estará en DNS).

Fallos temporales, reintentos y prioridades de MX

Un MTA, como todo ordenador y/o sistema software, puede fallar o no estar disponible durante un tiempo. Si un MTA debe entregar un mensaje a otro y al intentar conectar con éste no puede hacerlo, conservará el mensaje para intentarlo más tarde. Reintentará el envío cada cierto tiempo y si transcurrido un plazo (típicamente de unos cuantos días) sigue sin conseguirlo, enviará de forma automática un mensaje de error informando de ello al remitente.

Pero existe una forma de evitar eso, y que una institución disponga de más de un MTA por si uno falla. Puede declarar ambos en los registros MX y así el MTA que intenta conectar con nosotros probará con todos ellos. Esos registros pueden llevar asignado un número que indica la prioridad. Intentará primero conectar con los de más prioridad, y sólo si no lo consigue, probará con los demás. Incluso un MTA de una institución puede ser MX de otra, de forma que respalda el servicio de correo de ésta en caso de que quede toda ella desconectada de Internet, por ejemplo.

En España RedIris presta este servicio (llamado a veces MX backup o, en este caso, mailbackup) a sus instituciones afiliadas. Cuando la institución vuelve a tener conexión, la que la respalda le entrega todos sus mensajes pendientes. Incluso el protocolo SMTP permite que la primera solicite al MTA de la segunda los mensajes que tenga en cola para ella. De esta forma se evita el retraso de horas hasta que los MTAs originales consiguen conectar, si no existiera este servicio.

Vemos por tanto que teniendo en cuenta todas las posibilidades anteriores, un mensaje puede pasar por varios MTAs antes de llegar a su destino. Cada uno de ellos debe añadir una cabecera 'Received:' al mensaje, las cuales nos indican el camino que éste ha seguido.

Toda esta casuística se produce porque un MTA puede recibir correo de varias fuentes:

- Mensajes generados por usuarios locales que pueden ir dirigidos a otros locales o a direcciones externas.

- Mensajes dirigidos a nuestros usuarios provenientes de cualquier punto de Internet.

Es decir, nuestro MTA puede recibir mensajes con origen y/o destino de fuera de la institución, pero debe tener cuidado.

Por ejemplo, un mensaje dirigido a una dirección externa sólo debe aceptarse si proviene de uno de nuestros usuarios. De lo contrario, alguien de fuera podría conectarse a nosotros para enviar un mensaje a otra dirección de fuera, usando nuestros recursos. Y el problema no son sólo los recursos, sino que si el mensaje es comercial o fraudulento, nos puede ocasionar todo tipo de complicaciones.

Un MTA configurado de forma que permita esto se llama 'open relay'. Antiguamente era frecuente que esto se pudiera hacer, porque las malas prácticas del correo-e no existían y casi nadie había previsto las funestas consecuencias que tiene actualmente.

Listas de correo

Las listas de correo constituyen una forma de comunicación entre una comunidad de usuarios muy efectiva. Una lista es, en resumen, una dirección de correo que funciona de forma tal que al enviarse un mensaje a la misma, todas las personas que están apuntadas (suscritas) a lista reciben una copia.

Es ésta una aplicación del correo-e que no tiene equivalente en el correo tradicional.

La dirección de correo-e de la lista está configurada de forma que los mensajes enviados a ella son procesados por un programa (el gestor de listas de correo), que se encarga de enviar copia a todos los suscriptores. Pero además las listas de correo proporcionan una serie de servicios como:

- Mecanismos para que los usuarios puedan suscribirse a la lista o borrarse de ella.

- Guarda copia de todos los mensajes enviados y normalmente permite que puedan ser consultados.

- Puede enviar periódicamente resúmenes de los mensajes mandados a la lista.

- En función de su configuración, controla quién puede suscribirse, si sólo los miembros o todo el mundo puede enviar a la misma, y si aun así los envíos deben ser autorizados antes por un administrador de la lista, etc...

Generalmente existe otra dirección de correo-e asociada a la lista, también gestionada por el software gestor de listas, pero que sirve para enviarle mensajes 'administrativos'. Algunos gestores de listas usan para este caso una dirección del 'tipo lista-request@...'. En otros casos no existe una dirección administrativa para cada lista sino una única. En este caso hay que indicar en los mensajes administrativos a qué lista nos queremos referir.

Por ejemplo, en la UCO usamos el gestor de lista llamado Majordomo. Existe una única dirección adminsitrativa: Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.. Si un usuario desea suscribirse a la lista (es sólo un ejemplo) Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo., debería mandar un mensaje a ' Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.' con el siguiente contenido: subscribe Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.

El usuario recibirá automáticamente un mensaje de vuelta indicándole si su petición ha tenido éxito o por el contrario hay algún problema.

Actualmente muchos los gestores de listas de correo permiten que este tipo de operaciones puedan ser realizadas vía Web. No es el caso de Majordomo.

Uso de las direcciones de los mensajes en las listas de correo

Las listas son un caso especial porque no son envíos persona-a-persona. Algunas cosas que hay que tener en cuenta:

- Aquí una persona envía un mensaje a la dirección de la lista, pero es el software que gestiona la lista el que lo envía a sus destinatarios. En los envíos normales, si un mensaje no llega a su destino por cualquier problema, el remitente recibe un mensaje (automáticamente generado por un programa de gestión de correo, un MTA) informándole del problema.

En una lista de correo, con potencialmente miles de suscriptores, es habitual que por cada envío se produzcan algunos errores (cuentas de suscriptores que han dejado de existir, o que sus servidores tienen problemas, etc.). Todos ellos generan mensajes de error que no deben ir a la persona que envió el mensaje original, ni tampoco al software que gestiona la lista (¿qué iba a hacer con ellos?) sino a la persona que gestiona el servidor de listas o al administrador de la lista concreta. Como los mensajes de error que genera un envío se mandan al remitente del sobre, los mensajes de listas de correo suelen llevar en ese lugar una dirección del tipo 'lista-owner@...' que es una dirección que en el gestor de listas de correo será un alias a la dirección real de la persona encargada.

- Cuando respondemos a un mensaje que nos ha llegado de una lista de correo, la respuesta puede ir al remitente original del mensaje o a la propia lista, algo muy habitual, de forma que los 'debates' que se generen sean públicos, pues se supone que interesan a todos.

Sin embargo, el remitente del mensaje (cabecera From:) debe ser la persona que realmente envió el mensaje, es lo que nos interesa. Si pulsamos el botón 'Reponder' de nuestro programa de correo, parece que el mensaje irá a esa persona, ¿no? Para estos casos existe una cabecera, 'Reply-To:', que indica a quién deben ir las respuestas. Si no existe, irán a la dirección remitente del mensaje (no del sobre).

Esa cabecera la habrá puesto el gestor de listas de correo si la lista está configurada para que las respuestas vayan a ésta en vez de al autor del mensaje.

-La dirección destino del mensaje no suele ser la personal nuestra, sino la de la lista (aunque la dirección destino del sobre sí fué la nuestra, de otra forma no nos habría llegado el mensaje). Se hace así para que distingamos claramente que ese mensaje lo recibimos a través de la lista, de otra forma sería difícil poderlo saber. De todas formas muchos gestores de listas añaden al principio del asunto (cabecera Subject:) de todos los mensajes que se envían el nombre de la lista entre corchetes. Por ejemplo: Asunto: [UsuariosLinux] Pregunta sobre...

Implantación sistema de control antispam (correo basura)

Desde el día 27 de noviembre de 2006, el Servicio de Informática ha implantado un nuevo sistema para reducir la cantidad de correos no deseados (Spam) que se reciben.

El sistema se conoce como greylisting y se basa en forzar reintentos en los servidores de correo que nos entregan mensajes, algo que los spammers no suelen hacer, pero sí cualquier servidor 'decente'.

El problema es que eso puede provocar retrasos en mensajes que se estén esperando. Para evitarlo, este filtro no se aplica a un gran número de universidades, centros de investigación y proveedores españoles.

En los primeros días de aplicación, el efecto observado es que se ha reducido drásticamente el número de mensajes basura recibidos, sin apenas retrasos apreciables.

Aun así seguimos trabajando para reducir aun más este problema.

Notas sobre el correo basura (SPAM)

Ante las molestias que supone para los usuarios del correo electrónico este problema, y las quejas de los que piden una solución, el Servicio de Informática considera oportuno difundir la siguiente información.

Los usuarios de correo electrónico habrán observado sin duda que el problema del llamado SPAM se ha ido agravando durante los últimos años. Este término se refiere a los mensajes que no hemos solicitado y nos envían con fines principalmente comerciales (aunque a veces pretenden difundir otros tipos de información, o son timos). El problema ha llegado al extremo de que hay usuarios que reciben diariamente docenas de mensajes de este tipo.

Hay que tener en cuenta que este uso del correo es totalmente ilegítimo, por lo que quienes los envían suelen falsear las cabeceras de los mensajes, de forma que a veces parece que han sido enviados por algún conocido e incluso que van destinados a una dirección distinta de la nuestra.

Quienes se dedican a enviar esta basura usan listas enormes de direcciones de correo que han recopilando de distintas formas:

- Recorriendo páginas Web. Por eso no es conveniente poner direcciones de correo en ellas.

- A veces usan tecnologías de los virus para infiltrarse en el ordenador de un usuario, leer la libreta de direcciones y enviarla al spammer.

- También puede ser que hayamos escrito nuestra dirección de correo en algún formulario Web no muy fiable, de donde haya ido a parar a manos de estos indeseables.

Existen otras formas, pues sus técnicas han llegado a un alto grado de sofisticación.

Este fenómeno constituye una grave amenaza al servicio de correo electrónico tal como existe actualmente, pues va en aumento y no tiene fácil solución. El problema es semejante al de los virus: con los protocolos y tecnologías de correo electrónico actuales es imposible discriminar de forma automatizada y totalmente fiable si un mensaje es o no SPAM. A medida que se toman medidas más o menos heurísticas para intentar detectarlo, aquellos que se dedican a enviar estos mensajes van depurando sus técnicas para anularlas.

Debido a esta falta de absoluta fiabilidad, es muy delicado rechazar mensajes mediante el uso de este tipo de técnicas porque podrían suponer la pérdida de mensajes válidos e importantes, lo cual pocos usuarios considerarían aceptable.

Cada institución tiene que decidir cómo afrontar este problema. Algunas usan técnicas más agresivas con el riesgo de la pérdida de mensajes válidos. Otras utilizan programas comerciales que pueden tener el mismo problema. Otras no toman ninguna medida, de forma que el usuario recibe todos los mensajes, dejándole la responsabilidad de decidir lo que debe rechazar, aun a pesar de la molestia que ello supone.

En la UCO, como un compromiso entre control y riesgo, hace algunos años que usamos algunas listas negras. Se trata de relaciones de ordenadores que se sabe que generan en gran cantidad este tipo de mensajes, o que están mal configuradas y permiten que se envíen a través de ellas. El problema es que estas listas están mantenidas por organizaciones ajenas a nosotros, cada una con sus propios criterios. Por ello únicamente usamos algunas de las que se consideran más fiables, aunque en algunas instituciones usan bastantes más, a pesar de sus riesgos.

Otro tipo de soluciones que se han adoptado últimamente se basan en el uso de técnicas estadísticas mediante las cuales nuestro programa de correo aprende a distinguir el correo válido del que no lo es tras un periodo de entrenamiento en el cual el usuario debe indicar al programa qué mensajes son SPAM. Pasado un tiempo, el propio programa se encarga de marcar, borrar o mover a alguna carpeta especial los mensajes que considere sospechosos.

Estas técnicas suelen funcionar relativamente bien, pero tienen sus inconvenientes:

- Debe ser entrenado por cada usuario para adaptarse al tipo de mensajes que suele recibir, el tipo de vocabulario dominante, etc. Por tanto no es práctico usar este tipo de filtros en los servidores de correo.

- Conviene revisar las decisiones del programa, con lo cual normalmente no nos evitamos un repaso a todos los mensajes.

- Como ocurre con los antivirus, pueden dar una falsa sensación de seguridad.

Un programa de correo que incluye esta funcionalidad es el Mozilla Thunderbird (excelente programa, por cierto).

Valga todo lo dicho para explicar porqué el Servicio de Informática no puede eliminar el problema (tampoco pueden en ningún otro sitio) y las razones por las que hasta ahora no ha adoptado medidas más agresivas contra el problema (fundamentalmente, el riesgo de pérdidas de mensajes).

Actualmente estamos trabajando para implantar nuevas medidas de control del correo basura, tales como etiquetar los mensajes considerados Spam para hacer más fácil al usuario su eliminación y la implantación de un sistema centralizado de clasificación estadístico entrenable de forma sencilla por los usuarios.

Aunque la mayoría de los usuarios de la UCO tienen una amplia experiencia en el uso del correo electrónico, es conveniente tener en cuenta una serie de normas para un correcto uso:

- Cuidado al revelar la lista de destinatarios. Es aceptable dejar la lista de destinatarios visible cuando se envía un correo a personas que se conocen todas entre sí y se pretende que puedan contestar a todos los demás. Sin embargo, cuando no se da esta circunstancia, es preferible, para no facilitar la recolección de direcciones que pudieran ser usadas en su momento para enviar correo basura, o bien usar la opción de copia oculta en los envíos masivos (según los clientes, aparece como CCo o Bcc), o bien usar listas de distribución o programas específicos para ello.

- Formatos y tamaño de los ficheros enviados. Cuando un documento ha sido generado digitalmente, no es conveniente imprimirlo y escanearlo para adjuntarlo a un correo electrónico: la copia así generada será de baja calidad y ocupará mucho espacio en disco). Puede enviarse en su formato original si se tiene la constancia de que los destinatarios podrán leerlo (asumiendo por ejemplo que tienen instalado Microsoft Office si se le envía un .doc) o pasarlo digitalmente a un formato de intercambio abierto y ampliamente extendido, como el PDF para documentos o el jpg para imágenes.

- Límite el tamaño de los mensajes y el uso de adjuntos. Por economía de espacio en los servidores de correo, especialmente cuando se envía un correo a varias personas, es conveniente limitar en lo posible el tamaño del mismo. Tenga además en cuenta que el destinatario puede tener problemas para leerlos, bien por su excesivo tamaño o porque el tipo de fichero (.exe, .vbs, ...) puede estar prohibido en el sistema receptor. Para ello pueden usarse las siguientes técnicas:

- Si los documentos están disponibles en una página web (por ejemplo una noticia de prensa o una ley), enviar un enlace al mismo en lugar del documento como adjunto. Esto tiene la ventaja adicional de permitir al destinatario acceder a la información en el contexto que el autor de la misma quiso que estuviera.

- Enviar los documentos comprimidos (en .zip o .rar) cuando esta compresión suponga un ahorro significativo de espacio, como suele ocurrir en los documentos .doc o .ppt.

- Cuando enviemos un adjunto indicar en el texto del mensaje cual es su contenido y su propósito para evitar que el destinatario sospeche de que se trata de un virus.

- Si se va a enviar un documento que es grande o va dirigido muchas personas, usar servicios de envío de documentos que permiten enviar en el texto sólo enlaces a los documentos finales. De este modo, no se multiplicará por el número de destinatarios el espacio ocupado por el documento original. En la UCO tenemos dos sistemas de este tipo, llamados consigna y eloads:

http://www.uco.es/consigna

http://webmail.uco.es/eloads

- No mantener correos en la Bandeja de entrada, esta es solamente para el correo pendiente de lectura, el correo en la bandeja de entrada solamente debe permanecer 1 día, si no da tiempo a leerlo debe ser transferido a otra carpeta (por ejemplo pendiente), el acumular correos en la bandeja de entrada repercute en la lentitud del servidor de correo.

- Borrar correos de la carpeta elementos enviados, esta carpeta funciona igual que la bandeja de entrada y también repercute en la lentitud del servidor.

- No responder al correo no solicitado. Responder al correo no solicitado (spam) es una forma de aumentar la cantidad de correo basura en nuestro buzón ya que indica al remitente que la cuenta es leída. Los mensajes no deseados (incluidos los que contiene o contenían virus) deben borrarse sin más.

- No abrir ficheros que no esperamos. Aunque procedan aparentemente de personas conocidas no debemos abrir mensajes no esperados que contengan adjuntos ya que puede tratarse de virus Aunque el servicio antivirus del correo UC los haya limpiado es bueno tener esta costumbre.

- No difundir correo no solicitado. No reenvié correo no solicitado (cadenas de mensajes, publicidad, rumores y bulos (por ejemplo sobre virus)...). Solo está contribuyendo a aumentar el correo no solicitado entre sus conocidos.

- Dar nuestra dirección con moderación. No proporcione su dirección de correo en webs de dudosa confianza o que puedan enviarle publicidad no deseada. Atentos al rellenar formularios para no indicar sin saberlo que queremos recibir publicidad. Es una buena idea disponer de un cuenta gratuita para registrarnos en este tipo de sitios.

- Diferenciar entre correo profesional y personal. Obtenga una cuenta de correo electrónico para asuntos personales. De esta forma podrá reducir el volumen de correo de su buzón profesional en la UC, manteniendo este para sus fines adecuados.

- Usar un estilo de redacción adecuado al destinatario. La forma de redacción debe adecuarse al destinatario. No escriba en mayúsculas ya que implica gritar. Utilice los smileys (símbolos de caras) con moderación y nunca en un mensaje formal. Si el contenido de un mensaje le irrita, no conteste de forma inmediata, haga antes una pausa. Tenga en cuenta que se trata de comunicación escrita.

- Incluya un "Asunto" del mensaje. Indique en el campo "Asunto" una frase descriptiva del mensaje. Esto facilita la clasificación, recuperación y lectura al destinatario y constituye una norma de cortesía.

- Limite el tamaño de las firmas automáticas. Las firmas automáticas y otro tipo de texto de inclusión automática debe ser lo más esquemáticas posibles. No incluya imágenes o información innecesaria. Limítelo a sus datos de contacto esenciales. Tenga presente si quiere que estos datos sean visibles cuando escribe a ciertas personas o a listas de distribución. En el lado opuesto nunca deje de identificarse con nombre y apellidos cuando nos dirigimos a personas desconocidas.

- No utilice estilos ni adornos innecesarios. Limite el uso de mensajes en formato HTML cuando sea estrictamente necesario para una mejor organización del texto. No utilice estilos con fondos de mensaje ya que recargan (en todos los sentidos) el correo y pueden provocar problemas en el destinatario.

- Respete la privacidad de los mensajes y el destinatario. No reenvié mensajes destinados a usted sin el permiso del remitente, sobre todo aquellos con contenido conflictivo o confidencial. No abuse de nuevas funcionalidades como el "aviso de lectura", su eficacia práctica es escasa y puede suponer una intromisión en la privacidad del destinatario.

- Ordenar las columnas por tamaño del mensaje periódicamente. Así podremos ver los mensajes que mas espacio nos están ocupando, para proceder a su eliminación o salvar en otro lugar si no son necesarios.