Investigación sobre El Proceso de enviar un correo Electronico

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 'jperz@univer.es', 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 ' xxx@uco.es' debe entregarlos al usuario 'xxx'
Una empresa usa direcciones del tipo ' xxx@empresa.com', 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 ' xxx@empresa.com' 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 ' xxx@poptel.com', para su personal o sus direcciones de contacto).

Más adelante explicamos cómo saben otros MTAs que los mensajes dirigidos a ' xxx@empresa.com' 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 ' xxx@servicio.uco.es'. Esos mensajes deben llegar al único MTA de entrada (el mismo encargado del dominio '@uco.es') 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 '@empresa.com' 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 'xxx@tricorp.com'. 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).