Servicio de Informática

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.

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

Notas sobre el correo basura (SPAM)

Todos los usuarios de correo electrónico hemos observado 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.

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.