Protocolo Simple de Transmisión de Correo (SMTP)

El significado de las siglas de SMTP, es Protocolo Simple de Transmisión de Correo ("Simple Mail Transfer Protocol"). Este protocolo es el estándar de Internet para el intercambio de correo electrónico. SMTP necesita que el sistema de transmisión ponga a su disposición un canal de comunicación fiable y con entrega ordenada de paquetes, con lo cual, el uso del protocolo TCP en la capa de transporte, es lo adecuado. Para que dos sistemas intercambien correo mediante el protocolo SMTP, no es necesario que exista una conexión interactiva, ya que este protocolo usa métodos de almacenamiento y reenvío de mensajes.

Son tres los protocolos que se aplican a un correo de esta clase. El termino SMTP

es frecuentemente y erróneamente usado para referirse a la combinación del grupo

de protocolos involucrados en el envío de correo electrónico. Esto porque los tres

están estrechamente relacionados, pero estrictamente hablando SMTP es uno de los

tres protocolos. Los tres protocolos son:

·Un estándar para el intercambio de correo entre dos computadores (RFC 821),

el cual especifica el protocolo usado para enviar correo entre "host" TCP/IP.

Este estándar es SMTP.

·Un estándar del formato del mensaje de correo, contenido en dos RFC:

-RFC 822 describe la sintaxis del campoo de título o cabecera del correo

electrónico y describe la interpretación del grupo de campos de la cabecera.

-RFC 1049 describe como un conjunto de otros tipos de documentos, que tengan

texto ASCII, y que pueden ser usados en el cuerpo del correo electrónico.

El nombre del protocolo oficial para este estándar es MAIL.

·Un estándar para el "routing" de "mail" usando el sistema de nombres de

dominio, descrito en RFC 974. El nombre oficial del protocolo para este

estándar es DNS-MX.

Modo de Comunicación SMTP

Cuando un servidor de SMTP, requiere transmitir un mensaje a otro servidor SMTP,

el emisor (servidor que inicia la sesión SMTP) establece una conexión con el

receptor (servidor que recibe petición de establecer sesión SMTP). Esta conexión

es unidireccional, es decir, el emisor puede enviar correo al receptor, pero

durante esa conexión, el receptor no puede enviar correo al emisor. Si el receptor

tiene que enviar correo al emisor, tiene que esperar a que finalice la conexión

establecida y establecer otra en sentido contrario, cambiando los papeles de emisor

y receptor. Una vez establecida la conexión, el emisor envía comandos y mensajes.

Los mensajes pueden tener como destino el receptor o un intermediario para llegar

a un destino más lejano. El receptor puede enviar al emisor respuestas y códigos de

estado. Los comandos son cadenas de caracteres que se pueden entender fácilmente y

las respuestas son códigos numéricos seguidos de una explicación del código.

Por lo señalado, SMTP (RFC 821) está basado en entrega "end-to-end". Esto es

diferente del principio guardar y enviar común en muchos sistemas de mensajería

electrónica, donde el mensaje puede pasar a través de un numero de maquinas

intermediarias su camino al destino final.

Existen aplicaciones que permiten intercambiar correo entre el sistema de

mensajería electrónica TCP/IP SMTP y el sistema de correo localmente usado.

Estas aplicaciones son llamadas "Gateways" de correo ("Gateways") o "Bridges"

de correo. Enviar correo a través de un "Gateway" puede alterar la entrega

"end-to-end". El protocolo SMTP solo puede garantizar la entrega al "Gateway"

y no al destino final que está localizado más allá de la red TCP/IP. Cuando el

"Gateway" es usado, la transmisión SMTP "end-to-end" se realiza en varias partes,

de "host" a "Gateway", "Gateway" a "host" o "Gateway" a "Gateway". El comportamiento

más allá del "Gateway" no está especificado por SMTP.

En este modelo de comunicación en primera instancia un usuario establece la

petición de enviar un mensaje a través de correo electrónico, luego el Emisor

SMTP establece una conexión de dos hilos con el Receptor SMTP. El Receptor

SMTP puede ser la destinación última o un intermediario, como es el caso del

"Gateway". El Emisor SMTP genera comandos que son contestados por el Receptor SMTP.

Flujo de Transferencia de los Mensajes de Correo Electrónico

Aunque los comandos y respuestas son estrictamente definidos por el protocolo,

el intercambio de ellos entre emisor y receptor resultar fácil de comprender.

Todo intercambio de comandos/respuesta/datos (líneas de texto) son delimitados

por un CRLF, para facilitar la compresión del protocolo SMTP. Toda respuesta tiene un código numérico al principio de la línea.

El ejemplo de trasferencia se detalla a continuación:

·El Emisor SMTP establece una conexión TCP con el destino SMTP y luego

espera que el servidor envíe un 220 Servicio de lectura de mensaje o un 421

Servicio de mensaje no habilitado, esto ultimo, cuando la destinación está

temporalmente inhabilitada para procesar el mensaje.

·HELO (Es una abreviación de "hello") es enviado para que el receptor identifique

si el Emisor SMTP está enviando su nombre de dominio. El Emisor SMTP puede usarlo

para verificar si contactó la destinación SMTP correcta. Si el Emisor SMTP soporta

Extensión de Servicios ("Service Extensions") SMTP, como está definido en RFC 1651

(Extensión de Servicios es explicada en detalle en la subseccion 2.1.4), puede

sustituir por un comando EHELO el comando HELO. El Receptor SMTP que no soporta

Extensión de Servicios, responde con una sintaxis de error 500, que es un comando

de mensaje no reconocido. El Emisor SMTP debe entonces reintentar con HELO, o si

el emisor no puede transmitir el mensaje sin uno o más de los comandos que son

propios de Extensión de Servicios, éste debe enviar un mensaje QUIT.

·Si el Receptor SMTP soporta Extensión de Servicios, responde con un mensaje

multilínea 250 OK, que incluye una lista de extensión de servicios que soporta.

·El Emisor SMTP, luego de recibir este comando 250 OK, inicializa la transferencia

del mensaje enviando el comando MAIL al Receptor SMTP. Este comando contiene el

"reverse-path" (habitualmente se utiliza para el envío del nombre de dominio del

emisor) que puede ser usado para reportar errores. Esta " reverse-path" puede contener

más que solamente el nombre de dominio de usuario (del emisor), en adición, éste

puede contener una lista de "host" de la ruta. Ejemplo de esto es cuando se pasa

por un "Bridge" o cuando se provee explícitamente información de la ruta en la

dirección de destino. Si el Receptor SMTP acepta responde con un 250 OK.

·El segundo paso del intercambio de mensajes a través de correo electrónico, consiste

en proveer al servidor SMTP la destinación para el mensaje. Se realiza enviando uno

o más comandos RCPT TO:forward-path. Cada uno de estos envíos es contestado por

parte del Receptor SMTP con un 250 OK, si la destinación es conocida por el servidor,

o un 550 NO, si tal usuario no es conocido.

·Cuando todos los comandos RCPT son enviados, el Emisor SMTP emite un comando

DATA para notificar al Receptor SMTP que el contenido del mensaje será el siguiente

envío. El Receptor SMTP responde con 354 Start mail input, end with CRLF CRLF.

Esta secuencia final es la que el Emisor SMTP utiliza cuando termina el envío de

datos del mensaje a transferir.

·El cliente ahora envía las líneas de datos, una a una, finalizando con la secuencia

CRLF.CRLF, secuencia que el Receptor SMTP responde con un 250 OK o un mensaje de

error si es que algo ha fallado.

·Luego se tienen algunas opciones:

-El Emisor SMTP no tiene más mensajes qque enviar, por lo que se finaliza la

conexión con un comando QUIT, a lo cual el Receptor SMTP responde con 221 Service

closing transmission channel.

-Si el Emisor SMTP no tiene más mensajees que enviar, pero quiere recibir mensajes

del otro extremo. Este envía el comando TURN. Los dos extremos de la comunicación

SMTP ahora cambian roles de Emisor/Receptor y el nuevo Emisor SMTP (Anterior

Receptor SMTP) puede enviar mensajes partiendo del paso 3 del esquema mostrado

en la Fig. 2-3a.

-Si el Emisor SMTP tiene otro mensaje ppara enviar retorna al paso 3 y envía un

comando MAIL.