Correo en Internet

noves
ecnologies
CORREO EN INTERNET
Debido a lo extenso del tema y aún teniendo
que dejar algunos puntos en el tintero, lo elaboramos
en dos partes.
Este tipo de servicio en particular es uno de los
más complejos por cómo se implementó su diseño inicial y cuál ha sido su evolución a lo largo de los años.
Se compone a su vez de numerosos protocolos
para ser lo mas versátil posible y acomodar las necesidades que van surgiendo continuamente; existen
decenas y decenas de RFCs (Request for Comments)
que definen dichos protocolos.
En las siguientes líneas intentaremos dejar un
poco más clara la funcionalidad intrínseca de esta
combinación de protocolos para ayudar tanto a nuevos
administradores de sistemas que tienen algún que
otro problema en comprender las “configuraciones”
de su servidores de correo, como a aquellos que, aún
sin tener conocimientos previos, tienen curiosidad
sobre el tema pero toda la documentación que
encuentran es demasiado enrevesada para ellos.
Abstracción
Casi todas las relaciones que se implementan
en el mundo de la informática y las telecomunicaciones, así como en muchas otras disciplinas, toman
como modelo a seguir las acciones que las personas
realizamos con nuestro entorno, día a día. Y la comu-
16
~
nicación de correo por Internet no difiere mucho, en
su abstracción más básica, del modelo seguido cuando
se envía un mensaje a través del correo convencional.
Podríamos plantear una analogía de la siguiente
manera:
Quiero enviar una carta o postal (mensaje) a un
amigo (o mejor dicho al buzón de mi amigo, es decir
el recipiente), así que llevo la carta hasta el buzón del
barrio (la MTA de mi barrio) y a la vez me convierto en
MUA. Deposito la carta en el buzón de correos y el cartero se la lleva a la estafeta de correo de mi barrio
(propiamente, mi servidor de correo saliente - protocolo SMTP/ESMTP), y allí a través de la dirección del
recipiente de destino determinan cuál es la estafeta
de correo del barrio de mi amigo (el servidor de
correo saliente de mi amigo - protocolo SMTP/ESMTP),
y el camión de correos transporta mi carta (protocolo
SMTP/ESMTP) hasta la estafeta de correo de mi
amigo. Una vez allí, el cartero de su barrio se presenta en el edificio donde vive y se la da al portero de la
finca (Delivery Agent) y la deja en el buzón.
Finalmente mi amigo con su llave (usuario/clave) se
acerca al buzón y recoge la carta (protocolo
POP3/IMAP4).
Era necesaria esta aproximación para comprender el concepto abstracto. A continuación aclararemos cada uno de los términos comentados anteriormente.
t
Juan Antonio Martínez, RESP. DPTO. S ISTEMAS ENTORNO DIGITAL
ALGUNAS DEFINICIONES
Antes de seguir adelante, vamos a necesitar algunas pocas definiciones para hacer que los párrafos siguientes
sean comprensibles, aunque algunos temas y términos tan sumamente importantes como la diferencia entre la cabecera y sobre del correo vamos a pasarlo por alto, ya que entrar en según qué matices requeriría otro nivel de profundidad en el desarrollo del tema. En la figura 1 se representa la relación de los componentes de las siguientes definiciones.
Mailbox/Recipient - Buzón
Un buzón es un fichero, o posiblemente un directorio de ficheros, donde los mensajes entrantes son almacenados.
MUA (Mail User Agent) - Agente para el Usuario de Correo
Un agente para el usuario es una aplicación ejecutada directamente por el usuario. Esta aplicación permite
crear y enviar mensajes salientes, así como visualizar los ficheros y mensajes que llegan al buzón del usuario. La MUA
remota siempre se considera la disponible en el servidor y la MUA local la que se dispone en el ordenador del usuario
final.
MTA (Mail Transfer Agent) - Agente de Transferencia de Correo
Un agente de transferencia se usa para transferir (enviar y recibir) mensajes entre servidores. Los agentes de
usuario entregan el mensaje al agente de transferencia, quien a su vez puede entregárselo a otro agente de transferencia o posiblemente a varios. Los agentes de transferencia son los responsables de encaminar los mensajes a sus destinos. Mientras sus funcionalidad está completamente oculta al usuario final, es claramente la parte más compleja.
Delivery Agent - Agente para la entrega
Un agente de entrega es usado para “colocar” el mensaje en el buzón del usuario. Cuando un mensaje llega a
su destinación, el agente de transferencia final enviará dicho mensaje al agente de entrega adecuado, que a su vez lo
procesará para añadirlo en el buzón del usuario.
Figura 1.
Relación entre los diferentes componentes y el encaminamiento de un mensaje desde su origen hasta su destinación.
Es difícil establecer un paralelismo entre estos componentes y el paradigma servidor/cliente, ya que los servidores tal como los percibimos pueden contener uno o varios de estos componentes, sin seguir una regla fija. Hay servidores de correo que disponen de una MTA solamente y se apoyan en delivers autónomos, mientras que los hay que
por el contrario disponen de MTA, sus propios delivers y otros componentes en una sola aplicación, etc. Cada esquema
tiene sus ventajas y desventajas.
17
~
PROTOCOLOS PRINCIPALES
Como cualquier relación cliente-servidor, debe existir algún tipo de reglamento que defina dichos componentes
y su interrelación. Estos reglamentos están recogidos en las especificaciones de protocolos enumerados en los correspondientes RFCs. Existen numerosos protocolos pero nos vamos a centrar solamente en los más utilizados en la suite
TCP/IP.
Figura 2.
Representación del modelo básico de abstracción a través de los protocolos más utilizados.
SMTP/ESMTP (Simple Mail Transfer Protocol/Extensions for ...)
Tan sólo para este protocolo existen más de 30 RFCs. El objetivo de este protocolo es la transferencia de correo
eficiente y fiable. Es independiente del subsistema particular de transmisión; aunque normalmente es TCP, otros transportes son posibles. Una característica importante de este protocolo es la capacidad de transferir correo entre diferentes redes (Relaying). Es usado en la transferencia de mensajes entre la MUA y la MTA (o viceversa) y entre MTAs.
POP3 (Post Office Protocol - Versión 3)
Quizá el menos complejo de todos, ya que se recoge en aproximadamente 5 RFCs. Este protocolo es usado para
poder retirar el correo del buzón del usuario que no dispone de una MUA remota y transferirlo a una MUA local. Dicho
de otra manera, si todos los usuarios tuvieran una cuenta de usuario de sistema UNIX/VMS (sistemas operativos con los
que nació Internet), este protocolo no existiría. Se usa para transferir los mensajes entre una MTA remota y una MUA
local; debido a esto para este protocolo siempre ha existido una combinación de nombre de usuario y contraseña, a
diferencia de SMTP, ya que para éste último al validarnos como usuario del sistema no necesitamos ningún otro tipo de
autenticación para poder enviar mensajes. Esto ha cambiado recientemente debido a la combinación de dominios virtuales y el SPAM/ABUSE, del que hablaremos más adelante.
MIME (Multipurpose Internet Mail Extensions)
Para este protocolo existen más de 90 RFCs. Trata las cabeceras de los mensajes (no los sobres), y ya que el
correo sólo puede transferir texto, codifica en texto otros tipos de orígenes de datos (imágenes, aplicaciones...) en
partes múltiples dentro del propio cuerpo del mensaje, para que éste pueda ser transportado; por tanto, se usa internamente dentro del transporte de SMTP/ESTMP.
18
~
t
Juan Antonio Martínez, RESP. DPTO. SISTEMAS ENTORNO DIGITAL
IMAP4 (Internet Message Access Protocol - Versión 4)
Unos 16 RFCs definen este protocolo. Es una especie de funcionalidad híbrida entre SMTP/POP3, ya que permite de forma remota gestionar íntegramente buzones remotos desde una MUA local así como la sincronización entre
cliente y servidor tras la gestión off-line. También permite crear, renombrar carpetas, etc... Este protocolo es más eficiente con poca carga de buzones y mensajes, por ello casi la completa mayoría de los servidores de correo en Internet
implementan POP en lugar de IMAP.
SASL (Simple Authentication and Security Layer)
Unos 6 RFCs definen este protocolo que no ha sido concebido específicamente para el correo, sino para añadir
soporte de autenticación en protocolos orientados a conexión que carecen de dicha autenticación. Su implementación
principalmente en SMTP/ESMTP se debe a que este protocolo no dispone de ningún método nativo de autenticación y
por lo tanto se puede hacer un uso indebido de este servicio (conocido como SPAM y ABUSE entre otros). De esta manera un usuario puede estar asociado a cualquier tipo de conexión y al autenticarse ante el servidor para poder usarlo
como relayer, se ignoran las reglas anti-spam que pueden bloquear su servicio.
En el próximo número explicaremos las técnicas de interrelación de los sistemas de correo (las listas de distribución, el correo diferido o el webmail), así como el problema del SPAM/ABUSE y sus repercusiones legales.
19
~