Tabla de contenidos 
Aplicaciones de DNSTabla de contenidos Aplicaciones de DNS
Figura: SMTP("Simple Mail Transfer Protocol")
El correo electrónico (E-mail) es probablemente la aplicación TCP/IP más usada. Los protocolos de correo básicos de correo proporcionan intercambio de correo y mensajes entre hosts TCP/IP hosts; se han añadido servicios para la transmisión de datos que no se pueden representar con texto ASCII de 7 bits.
Hay tres protocolos estándares que se aplican a este tipo de correo. Todos son recomendados. El término SMTP se emplea con frecuencia para referirse a la combinación de los tres protocolos, por su estrecha interrelación, pero estrictamente hablando, SMTP es sólo uno de los tres. Normalmente, el contexto hace evidente de cuál de los tres se está hablando. Cuando haya ambigüedad, se emplearán los números STD o RFC. Los tres estándares son:
El nombre oficial del protocolo para este estándar es MAIL.
El STD 10/RFC 821 establece que los datos enviados por SMTP son ASCII de 7-bis, con el bit de orden superior a cero. Esto es adecuado para mensajes en inglés, pero no para otros lenguajes o datos que no sean texto. Hay dos estrategias para superar estas limitaciones:
El RFC 1651 modifica el 821 para permitir que un cliente agente SMTP solicite al servidor una lista de las extensiones de servicio que soporta el inicio de una sesión SMTP. Si el servidor no soporta este RFC, responderá con un error y el cliente podrá terminar la sesión o intentar iniciar una sesión según las reglas RFC 821. Si sí lo soporta, puede responder con una lista de las extensiones que soporta. IANA mantiene un registro de servicios: la lista inicial del RFC 1651 contiene los comandos listados en el RFC 1123 - Requerimientos para hosts de Internet - Aplicación y soporte como opcionales en servidores SMTP. Se han definido otras extensiones con RFCs del modo habitual. Los dos siguientes RFCs definen extensiones específicas:
Las extensiones de MIME y SMTP son estrategias que se complementan más que competir entre sí. En particular, el RFC 1652 se titula SMTPSE para transporte MIME en codificación "8bit", ya que MIME permite declarar mensajes con bytes de 8 bits, en vez de 7. Tales mensajes no se pueden transmitir con agentes SMTP que sigan estrictamente el RFC 821, pero se pueden transmitir cuando tanto el cliente como el servidor siguen los RFCs 1651 y 1652. Siempre que un cliente intenta enviar datos de 8 bits a un servidor que no soporta esta extensión, el cliente SMTP debe codificar el mensaje a 7 bits según el estándar MIME o devolver un mensaje de error permanente al usuario.
Esta extensión no permite el envío de datos binarios arbitrarios porque el RFC 821 fija la longitud máxima de las líneas aceptadas por un servidor SMTP a 1000 caracteres. Los datos que no son texto pueden tener con facilidad secuencias de más de 1000 caracteres sin una secuencia <CRLF>.
Nota: Las extensiones limitan específicamente el uso de caracteres no ASCII(aquellos con valor decimal superior a 127) al cuerpo de los mensajes - no están permitidos en las cabeceras RFC 822.
Todas estas extensiones son borradores y tienen status electivo.
SMTP está basado en la entrega punto-a-punto; un cliente SMTP contactará con el servidor SMTP del host de destino directamente para entregar el correo. Guardará el correo hasta que se haya copiado con éxito en el receptor. Esto difiere del principio de retransmisión común a muchos sistemas de correo en las que el correo atraviesa un número de host intermedios de la misma red y donde una transmisión con éxito implica sólo que el correo ha alcanzado el host correspondiente al siguiente salto.
En varias implementaciones, existe la posibilidad de intercambiar correo entre los sistemas de correo locales y SMTP. Estas aplicaciones se denominan pasarelas o puentes de correo. Enviar correo a través de una pasarela puede alterar la entrega punto-a-punto, ya que SMTP sólo garantiza la entrega fiable a la pasarela, no al host de destino, más allá de la red local. La transmisión punto SMTP en estos casos es host-pasarela, pasarela-host o pasarela-pasarela; SMTP no define lo que ocurre más allá de la pasarela. CSNET proporciona un interesante ejemplo de servicio de pasarela de correo. Diseñada en principio como un servicio barato para interconectar centros científicos y de investigación, CSNET opera una pasarela que permite a sus suscriptores enviar y recibir correo en Internet con sólo un módem con dial. La pasarela sondea a los suscriptores a intervalos regulares, les entrega su correo y recoge el correo de salida. A pesar de no ser una entrega punto-a-punto, ha demostrado ser un sistema muy útil.
Cada mensaje tiene:
Todo lo que hay tras la línea nula es el cuerpo del mensaje, una secuencia de líneas con caracteres ASCII(aquellos con valor menor del 128 decimal).
El RFC 821 define un protocolo cliente/servidor. Como siempre, el cliente SMTP es el que inicia la sesión (el emisor) y el servidor el que responde a la solicitud de sesión(el receptor). Sin embargo, como el cliente suele actuar como servidor para un programa de correo del usuario, es más sencillo referirse a él como emisor SMTP, y al servidor como receptor SMTP.
Normalmente, el usuario no tiene por qué preocuparse de la cabecera, que es responsabilidad de SMTP.
El RFC 822 contiene un análisis completo de la cabecera. La sintaxis es BNF("Backus-Naur Form") extendida. El RFC 822 contiene una descripción de BNF, y muchos RFCs relacionados usan el mismo formato. Además describe como convertir una cabecera a su forma canónica, uniendo las líneas de continuación, los espacios no significativos, los comentarios, etc. Es una sintaxis poderosa, pero relativamente difícil de analizar. Aquí se incluye una breve descripción.
Brevemente, la cabecera es una lista de líneas de la forma:
field-name: field-value
Los campos comienzan en la columna 1: las líneas que comienzan con caracteres en blanco(SPACE o TAB) son líneas de continuación que se unen para crear una sola línea para cada campo en la forma canónica. Las cadenas entre comillas ASCII señalan que los caracteres especiales que limitan no son significativos sintácticamente. Muchos valores importantes(como los de los campos "To" y "From") son buzones. Las formas más corrientes para estos son:
La cadena "The Octopus" ha de ser leída por receptores humanos y es el nombre del propietario del buzón. "octopus@garden.under.the.sea" es la dirección para la máquina del buzón(el > y el < delimitan la dirección pero no forman parte de ella). Se ve que esta forma de direccionamiento está relacionada con DNS. De hecho, el cliente SMTP utiliza el DNS para determinar la dirección de destino del buzón.
Algunos campos habituales son:
El diseño de SMTP se basa en el modelo de comunicación mostrado en Figura - Modelo para SMTP. Como resultado de la solicitud de correo de un usuario, el emisor SMTP establece una conexión en los dos sentidos con el receptor SMTP. El receptor puede ser el destinatario final o un intermediario(pasarela de correo). El emisor generará comandos a los que replicará el receptor.
Figura: Modelo para SMTP
Aunque los comandos y réplicas de correo están definidas rígidamente, el intercambio se puede seguir en Figura - Flujo de datos normal de SMTP. Todos los comandos, réplicas o datos intercambiados son líneas de texto, delimitadas por un <CRLF>. Todas las réplicas tienen un código numérico el comienzo de la línea.
Si el emisor SMTP soporta las extensiones de SMTP definidas en el RFC 1651, puede sustituir el comando HELO por EHLO. Un receptor SMTP que no soporte las extensiones responderá con un mensaje "500 Syntax error, command unrecognized". El emisor SMTP debería intentarlo de nuevo con HELO, o si no puede retransmitir el mensaje sin extensiones, enviar un mensaje QUIT.
Si un receptor SMTP soporta las extensiones de servicio, responde con un mensaje multi-línea 250 OK que incluye una lista de las extensiones de servicio que soporta.
Figura: Flujo de datos normal de SMTP - Se entrega un correo al buzón de destino.
en su forma general, parte-localt@nombre de dominio, puede adoptar distintos esquemas:
En la descripción anterior, sólo los comandos más importante se han mencionado. Todos ellos son comandos que deben estar reconocidos en cualquier implementación SMTP. Existen otros comandos, pero la mayoría son opcionales, es decir, el RFC no los requiere. Sin embargo, implementan funciones muy interesantes tales como retransmisión, correo, listas, etc.
Para una lista completa de comandos, ver el RFC 821 - SMTP("Simple Mail Transfer Protocol") y el RFC 1123 - Requerimientos para hosts de Internet - Aplicación y soporte. Para detalles de las extensiones SMTP, ver los RFCs 1651 - SMTPSE("SMTP Service Extensions"), 1652 - SMTPSE para transporte MIME con codificación "8bit" y 1653 - SMTPSE para la declaración de tamaños de mensaje.
En el siguiente escenario, el usuario abc en el host vm1.stockholm.ibm.comando envía una nota a los usuario xyz, opq u rst en el host delta.aus.edu. Las líneas precedidas por R: son las enviadas por el receptor, las que empiezan por S: las enviadas por el emisor.
R: 220 delta.aus.edu Simple Mail Transfer Service Ready S: HELO stockholm.ibm.comando R: 250 delta.aus.edu S: MAIL FROM:<abc@stockholm.ibm.comando> R: 250 OK S: RCPT TO:<xyz@delta.aus.edu> R: 250 OK S: RCPT TO:<opq@delta.aus.edu> R: 550 No such user here S: RCPT TO:<rst@delta.aus.edu> R: 250 OK S: DATA R: 354 Start mail input, end with <CRLF>.<CRLF> S: Date: 23 Jan 89 18:05:23 S: From: Alex B. Carver <abc@stockholm.ibm.comando> S: Subject: Important meeting S: To: <xyz@delta.aus.edu> S: To: <opq@delta.aus.edu> S: cc: <rst@delta.aus.edu> S: S: Blah blah blah S: etc..... S: . R: 250 OK S: QUIT R: 221 delta.aus.edu Service closing transmission channel Nótese que la cabecera del mensaje es parte de los datos a transmitir.
Si la red usa el concepto de dominio, un SMTP no puede entregar simplemente correo a TEST.IBM.comando abriendo una conexión TCP con TEST.IBM.comando. Primero debe consultar al servidor de nombres para hallar a que host(en un nombre de dominio) debería entregar el mensaje.
Para la entrega de mensajes, el servidor de nombres almacena los RRs("resource records") denominados MX RRs. Mapean un nombre de dominio a dos valores:
También es posible que el servidor de nombres responda con una lista vacía de RRs MX. Esto significa que el nombre de dominio se halla bajo la autoridad del servidor, pero no tiene ningún MX asignado. En este caso, el emisor SMTP puede intentar establecer la conexión con el mismo nombre del host.
El RFC 974 da una recomendación importante. Recomienda que tras obtener los registros MX, el emisor SMTP debería consultar los registros WKS(Well-Known Services) del host, y chequear que el host referenciado tiene como entrada WKS a SMTP.
Nota: Esto es sólo una opción del protocolo, aunque aparece en numerosas implementaciones.
Aquí hay un ejemplo de RRs MX:
fsc5.stn.mlv.fr. IN MX 0 fsc5.stn.mlv.fr.
IN MX 2 psfred.stn.mlv.fr.
IN MX 4 mvs.stn.mlv.fr.
IN WKS 152.9.250.150 TCP (SMTP)
En el ejemplo anterior, el correo para fsc5.stn.mlv.fr debería, por prioridad, ser entregado al propio host, pero en caso de que el host sea inalcanzable, el correo también podría ser entregado a psfred.stn.mlv.fr o a mvs.stn.mlv.fr (si psfred.stn.mlv.fr no se pudiera alcanzar tampoco).
Debido a que un receptor de correo SMTP es un servidor, y SMTP es una aplicación punto-a-punto más que de retransmisión, es necesario que el servidor esté disponible cuando un cliente desea enviarle correo. Si el servidor SMTP reside en una estación de trabajo o en un PC, ese host debe estar ejecutando el cuando el cliente quiera transmitir. Esto no suele ser un problema en sistemas multiusuario porque están disponibles la mayor parte del tiempo. En sistemas monousuario, sin embargo, este no es el caso, y se requiere un método para asegurar que el usuario tiene un buzón disponible en otro servidor. Hay varias razones por las que es deseable descargar a la estación de trabajo de las funciones del servidor de correo, entre ellas la falta de recursos en estaciones de trabajo pequeñas, la falta o encarecimiento de la conectividad TCP, etc.
La estrategia más simple es, por supuesto, usar un sistema multiusuario para las funciones de correo, pero esto no suele ser deseable -- quizá el usuario no lo va a usar para nada más, o quiere tener acceso a Alternativamente, el usuario final puede ejecutar un cliente que comunique con un programa servidor en un host. Este servidor actúa tanto como emisor como receptor. Recibe y envía el correo del usuario.
Un método intermedio es descargar la función de servidor SMTP de la estación de trabajo del usuario final, pero no la función de cliente. Es decir, el usuario envía correo directamente desde la estación, pero tiene un buzón en un servidor. El usuario debe conectar con el servidor para recoger su correo.
El POP describe cómo un programa que se ejecuta en una estación de trabajo final puede recibir correo almacenado en sistema servidor de correo. POP usa el término "maildrop" para referirse a un buzón gestionado por un servidor POP. POP 3 es un borrador y su status es elective. Las versión es un protocolo histórico con status no recomendado.
Cuando un usuario emplea un servidor para las funciones de correo, la dirección del buzón que ven otros usuarios SMTP se refiere exclusivamente al servidor. Por ejemplo, si dos sistemas se llaman:
usándose el primero como cliente y el segundo como servidor, la dirección de correo podría ser:
Esta dirección de buzón aparecería en el campo "From:" de la cabecera de todo el correo saliente y en los comandos SMTP a servidores remotos lanzados por el servidor.
Sin embargo, cuando el usuarios emplea un servidor POP, la dirección de correo contiene el nombre de host de la estación de trabajo(por ejemplo steve@hayes.itso.ral.ibm.comando). En este caso, el emisor debería incluir un campo "Reply-To:" en la cabecera para indicar que las réplicas no se deberían enviar al emisor. Por ejemplo, la cabecera podría tener este aspecto:
Date: Fri, 10 Feb 95 15:38:23 From: steve@hayes.itso.ral.ibm.comando To: "Steve Hayes" <tsgsh@gford1.warwick.uk.ibm.comando> Reply-To: hayes@itso180.itso.ral.ibm.comando Subject: Test Reply-To: header field
Se espera que el agente de correo envíe las respuestas a la dirección "Reply-To:" y no a "From:".
Una alternativa al uso del campo "Reply-To:" es usar el DNS para dirigir el correo al buzón correcto. El administrador del DNS con autoridad para el dominio que contiene la estación del usuario y el servidor de nombres pueen añadir registros MX al DNS para dirigir el correo, tal como se describe en SMTP y el DNS. Por ejemplo, los siguientes registros MX indican a los clientes SMTP que, si el servidor SMTP en hayes.itso.ral.ibm.comando no está disponible, hay un servidor de correo en itso.180.ral.ibm.comando (9.24.104.180) que se debería usar en su lugar.
itso180.itso.ral.ibm.comando. IN WKS 9.24.104.180 TCP (SMTP)
hayes.itso.ral.ibm.comando. IN MX 0 hayes.itso.ral.ibm.comando.
IN MX 1 itso180.itso.ral.ibm.comando.
Una pasarela SMTP es un host con dos conexiones a redes distintas. Las pasarelas SMTP se pueden implementar de forma que conecten distintos tipos de redes.
Una pasarela SMTP-RSCS/NJE se configura utilizando un fichero de configuración SMTP como el que se muestra abajo. Para configurar un host que no es pasarela, no se debe especificar la sentencia GATEWAY.
.........
;
GATEWAY ; accept mail from and deliver mail to RSCS host
RSCSDOMAIN RSCSNET ; pseudo domain name of associated RSCS network
LOCALFORMAT NETDATA ; local recipients receive mail in Netdata format
RSCSFORMAT NETDATA ; RSCS recipients receive mail in Netdata format
REWRITE822HEADER NO ; Only set to no if you do not want SMTP to
; rewrite the 822 headers on all mail passing
; from RSCS to TCP through gateway.
Se puede prohibir el acceso a la pasarela a determinados nodos de la red, empleando la sentencia de configuración RESTRICT.
Alternativamente, la seguridad se puede implementar con un fichero de autorización de accesos, que es una tabla en la que se especifican de quién y a quién se puede enviar correo por la pasarela. La siguiente tabla es un ejemplo de este tipo de archivo:
MIME ("Multipurpose Internet Mail Extensions")