Las direcciones de correo electrónico constan de dos partes: la primera es el nombre de un dominio de correo encargada de traducir la información, o bien al anfitrión del receptor o a cualquiera que acepte correo de su parte. La segunda es la identificación exclusiva del usuario que puede ser tanto el nombre que le permite el acceso al sistema, como el nombre del usuario en formato “nombre.apellido” , o un alias que se transmitirá a un usuario o a la lista de usuarios. Otros formatos de dirección de correo como el X.400 utilizan otra serie de “atributos” que sirven para localizar al sistema anfitrión del receptor en el directorio del servidor X.400.
La interpretación de las direcciones de correo electrónico depende en gran medida del tipo de red de la que usted disponga. A hora nos centraremos en cómo los protocolos TCP/IP y UUCP interpretan las direcciones de correo electrónico.
Los sitios de Internet están ligados al estándar RFC-822, que requiere la conocida notación usuario@anfitrión.dominiopara el cual anfitrión.dominio es el nombre de dominio más adecuado para el anfitrión. El símbolo que separa ambas partes recibe el nombre de “arroba” en inglés “at.” Esta nomenclatura no especifica la ruta al sistema anfitrión. Otros mecanismos que trataremos en breve son los encargados del encaminamiento de los mensajes.
Al ejecutar un sitio en Internet encontrarás muchos RFC-822. EL estándar RFC-822 no es exclusivo del correo, ya que se ha extendido a otros servicios como los grupos de noticias. Ahora veremos el uso de RFC-822 en los grupos de noticias. Capítulo 20.
En el entorno original UUCP la forma corriente era ruta!anfitrión!usuario, para el cual la ruta indicaba una secuencia de anfitriones por los que el mensaje tenía que pasar antes de llegar a su anfitrión de destino. Este modelo recibe el nombre de notación bang path, porque en inglés coloquial, la exclamación se conoce con el nombre “bang.” Actualmente, muchas de las redes basadas en UUCP han adoptado el formato RFC-822 y aceptan las direcciones de correo basadas en el dominio.
Hay redes que usan otros sistemas de dirección. Por ejemplo, las basadas en DECnet, usan los dos puntos (:) como elemento separador de sus partes, resultando la dirección anfitrión::usuario.[1] El estándar X.400 utiliza un estilo totalmente diferente, describiendo al receptor por medio de pares de atributos como país y organización a la que éste pertenece.
En último lugar, está FidoNet, en donde cada usuario se identifica con un código como 2:320/204.9, que consiste en cuatro números que indican la zona donde se encuentra (el 2 es para Europa), la red (el 320 se refiere a París y los alrededores), el anfitrión (distribuidor local), y el punto de conexión (el ordenador del usuario). Se puede trabajar con direcciones Fidonet en RFC-822; la anterior, por ejemplo, se escribiría de la siguiente manera Thomas.Quinot@p9.f204.n320.z2.fidonet.org. No dijimos que los nombres de dominio eran fáciles de recordar?
Cuando a un conjunto de sistemas le sumamos gente inteligente, lo normal es que se intente buscar maneras para poder conectarse entre sí y trabajar en red. Por consiguiente, existen distintas pasarelas de correo que vinculan dos sistemas diferentes, de forma que el correo pueda ser transmitido de uno a otro. El problema más crítico a la hora de interconectar dos sistemas es el referente a las direcciones de correo. No vamos a centrarnos en las pasarelas de correo en sí mismas, sino que repasaremos algunas de las complicaciones referidas al correo que pueden surgir al usarlas.
Imagine que queremos trabajar con la notación bang-path de UUCP y RFC-822. No son dos formatos fáciles de combinar. Supongamos que tenemos la siguiente dirección dominioA!usuario@dominioB . No está claro si el símbolo @ tiene prioridad sobre la ruta, o viceversa: entonces, ¿tendríamos que mandar el mensaje a dominioB, que lo enviaría a dominioA!usuario, o por el contrario deberíamos hacerlo a dominioA, que lo dirigiría a usuario@dominioB ?
Aquellas direcciones formadas por distintos proveedores de correo se llaman direcciones híbridas. El tipo más común, que es el que acabamos de ilustrar, normalmente se resuelve dando prioridad al símbolo @ sobre la ruta. Esto significaría enviar primero el mensaje a dominioB en dominioA!usuario@dominioB
Sin embargo, hay una manera de especificar las ruta en RFC-822: <@dominioA,@dominioB:usuario@dominioC > indica la dirección delusuario en el dominioC, donde llegamos al dominioCpasando por dominioA y dominioB (en ese orden). Este tipo de dirección se llama con frecuencia direcciónencaminada desde la fuente Tampoco es bueno basarse exclusivamente en este sistema, ya que un posterior repaso al estándar RFC en su apartado de la descripción del encaminamiento del correo, recomienda que se intente enviar el correo directamente a su destino remoto en lugar de hacerlo por medio de la fuente.
Existe además el % proveedor de correousuario %dominioB@dominioA que lo envía primero a dominioA, y transforma el símbolo de porcentaje más indicado (que en este caso es el único) a un símbolo arroba@ sign. La direccion en este caso es usuario@dominioB, y el mensajero dirige su mensaje a dominioB, el cual lo envía al usuario. A este tipo de dirección la solemos llamar “Ye Olde ARPAnet Kludge,” y su uso no es alentador.
El uso de estos tipos distintos de direccionamiento puede tener sus repercusiones, las cuales veremos en las secciones siguientes. En un entorno RFC-822 no se deberá usar otra dirección que no sea una absoluta como usuario@anfitrión.dominio.
| [1] | Si desea acceder a una dirección DEC desde el entorno RFC-822, puede hacerlo de la siguiente manera “anfitrión::usuario@relay, siendo relay el nombre de un repetidor DEC conocido. |