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.