SMTP

Profesor: Delgado Perez Julio

Alumno:
Becerril Domı́nguez Óscar Azeem
Grupo:
8CM1

Escuela Superior de Ingenierı́a Mecánica y Eléctrica. Unidad Zacatenco

9 de febrero de 2015
Índice
1. Introducción y terminologı́a 1
1.1. Modelo SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2. Procedimiento de SMTP 2
2.1. Comandos de SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Diagramas de Estado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Respuestas de SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Implementación Mı́nima de SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3. SMTP y los servicios de transporte 7

3.1. TCP servicio de transporte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. NCP servicio de transporte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. NITS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

4. Bibliografı́a 8
Índice de figuras
1. Modelo Básico del Protocolo SMTP . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Sesión Clásica del Protocolo SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Diagrama de estado SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1. Introducción y terminologı́a
SMTP se diseñó para proporcionar mecanismos eficientes, fiables, para la transferencia de
correo electrónico. SMTP transfiere mensajes de un cliente a un servidor y entre servidores,
pero no es responsable del manejo de los buzones de correo ni de permitir al ciente obtener su
correo entrante. Se basa en la secuencia comando/respuesta; el cliente debe recibir una única
respuesta antes de poder enviar otro comando y al servidor no se le permite enviar más de una
respuesta a cualquier comando.
SMTP es independiente del subsistema particular de transmisión, y requiere únicamente un
canal confiable de transmisión de información. En la seccion 3 se puede obtener una mejor des-
cripción de SMTP implementado en varios servicios de transporte. Una importante caracterı́sti-
ca de SMTP es la capacidad de relevar correo a través de entornos de servicio de transporte.
Un servicio de transporte proporciona un entorno de comunicación de interproceso (IPCE- in-
terprocess communication environment). Es importante recalcar que un sistema de transporte
es también conocido cómo: IPCE. Un proceso puede comunicar directamente con otro proceso
atraves de cualquier IPCE mutuamente conocido. Mail puede ser comunicado entre procesos
en diferentes IPCEs siendo relevado a través de un proceso conectado a dos (o más) IPCEs.
Más especı́ficamente, mail puede ser relevado entre hosts en diferentes sistemas de transporte
por un host en ambos sistemas de transporte. Esto es importante cuando existe un sistema
de transporte basado en TCP, y desea llegar a un servidor de correo en el que su sistema de
transporte está basado en NCP.
SMTP se define en la RFC821; en el siguiente listado se muestran algunos términos que usa
SMTP, para su funcionamiento:

Proceso emisor de SMTP (sender). Inicia una conexión de SMTP con el proceso
receptor para enviar correo. Envı́a comandos y recibe respuestas.

Proceso receptor de SMTP (receiver). Proceso que espera a que un proceso emisor
de SMTP establezca una conexión, a continuación recibe comandos del emisor de SMTP
y lleva a cabo la operación especificada en los comandos.

Canal de transmisión. El canal full-dúplex que se abre entre los procesos emisor y recep-
tor de SMTP con el objetivo de enviar secuencias de comandos/respuestas y transferencia
de correo.

Ruta inversa. Especifica al emisor del correo. La ruta inversa puede ser simplemente
el nombre del usuario que envı́a el correo o puede incluir una lista de hosts por los que
reenvı́a el coreo desde su emisor de SMTP original. El primer host de la lista es el reemisor
más reciente, y el último es el primer reemisor.

Ruta directa. Especifica al receptor o receptores del correo. Opcionalmente la ruta direc-
ta puede especificar una lista de reemisores que se pueden utilizar para enrutar el correo
a su receptor, siendo el receptor actual de SMTP el primero de la lista de reenvı́o y el
destino final el último de la lista.

Búfer de la ruta inversa. Se usa para guardar la lista de los parámetros de la ruta
inversa para una transacción, posiblemente incluye una lista de hosts que reenvı́an el
correo. Se puede eliminar como consecuencia del envı́o de distintos comandos.

Búfer de la ruta directa. Se usa para guardar la lista de los parámetros de la ruta directa
para una transacción, posiblemente incluyendo una lista de hosts de reenvio a quienes se
enruta el correo. También se puede eliminar como resultado de distintos comandos.

1
1.1. Modelo SMTP
A pesar de que las mejores que se han añadido a SMTP desde la RFC 821, sigue siendo un
protocolo relativamente simple. SMTP, como HTTP y FTP, es un protocolo del nivel de apli-
cación que utiliza los protocolos inferiores para asegurar la entrega de los datos. Aunque SMTP
puede utilizar otros protocolos, la descripción que sigue en este escrito, se hará suponiendo que
TCP es el protocolo subyacente que se emplea. Una imagen del modelo básico se puede observar
en la figura 1.

Figura 1: Modelo Básico del Protocolo SMTP

SMTP para ser capaz de proveer la capacidad de relevo, el servidor SMTP debe ser sumi-
nistrado con el nombre del último host destino, ası́ como el nombre de la bandeja de correo de
destino.
Los comandos y respuestas no son sensibles a las mayúsculas. Esto es, un comando o respues-
ta puede ser letra mayúscula, letra minúscula, o cualquier mezcla entre mayúscula y minúscula.
Hay que tener en cuenta que esto no es cierto en los nombres de bandeja de correo de los usuarios.
Para algunos hosts el nombre de usuario es sensible a las mayúsculas, y las implementaciones
de SMTP deben tomar lugar para preservar los nombres de usuario y como aparecen en los
argumentos de la bandeja de correo. Los nombres de Host no son sensibles a las mayúsculas.
Comandos y respuestas están compuestas de caracteres del conjunto ASCII. Esto significa que
cuando el servicio de transporte proporciona un byte en el control de transmisión, cada carácter
de 7 bits es transmitido justificado como octeto, con el bit de orden más alto colocado en cero.

2. Procedimiento de SMTP
Está sección presenta los procedimientos usados en SMTP en múltiples partes, siendo el
siguiente listado el proceso clásico, definido sencillamente como: transacción de mail.
1. La comunicación de SMTP la inicia un sistema de correo de un usuario, referido aquı́ como
el cliente o emisor de SMTP. El cliente establece un canal de transmisión full-dúplex con
un servidor de SMTP, o receptor de SMTP, enviando un comando HELO o EHLO para
comenzar la sesión.

2. Después de establecer el canal de transmisión, el cliente envı́a un comando MAIL que

informe al receptor de SMTP que desea enviar un correo. Si el servidor es capaz de recibir
el correo en ese momento, responde con una respuesta OK.

3. El emisor de SMTP (cliente) envı́a uno o más comandos RCPT que identifican al receptor
del mensaje, o mensajes, a quien se desea enviar; cada comando RCPT representa un

2
 único receptor de correo. Los receptores pueden ser otros usuarios en el mismo sistema de
correo o usuarios en dominios externos.
Si el servidor de SMTP es capaz de recibir correo dirigido al receptor indicado en el
comando RCPT, envı́a una respuesta OK al cliente y el cliente puede enviar otro comando
RCPT.

Como puede que no todos los receptores estén usando el mismo sistema SMTP, el cliente
debe proporcionar el nombre del host de destino final ası́ como el nombre del correo en dicho
sistema de correo. La sintaxis de una dirección de correo de SMTP es el familiar formato: usua-
rio@dominio. Dónde a la derecha del sı́mbolo “@” se indica el host destino y el usuario identifica
el nombre del buzón de correo en el que se debe entregar el correo.
SMTP diferencia entre enviar y entregar ; si se entrega correo, el cliente está indicando que el
correo deberı́a entregarse inmediatamente en la interfaz de correo del receptor, si el receptor
está en lı́nea y usando el sistema de correo con está funcionalidad. Más a menudo el correo se
envı́a, lo que indica que se entrega en el buzón del receptor en el servidor del receptor. Además,
la funcionalidad de entrega no se requiere en las implementaciones de SMTP.
El correo de SMTP tiene tanto una ruta directa como una inversa. La ruta directa es la ruta
que debe seguir el correo para llegar a su destino final, ya utilice una ruta directa o una serie
de reenvı́os. Es importante no confundir los reenvı́os de SMTP con enrutadores; los reemisores
de SMTP son servidores de SMTP que reciben correo de un host de SMTP y lo reenvı́an a
otro host de SMTP, independiente del mecanismo de enrutamiento utilizado. La ruta inversa
en un correo de SMTP es el nombre del emisor de SMTP, que puede ser tan simple como: usua-
rio@algundominio; o puede consistir en una lista de hosts de reemisión entre el emisor original
y el receptor actual de SMTP. El comando mail utiliza la ruta inversa como su argumento, y el
comando RCPT usa la ruta directa.

4. Una vez que el receptor de SMTP ha aceptado la dirección del receptor y ha dado la
respuesta apropiada, el cliente puede continuar con el comando DATA, que informa al
servidor de su intención de empezar la transferencia del mensaje. El servidor responde
con un código de aceptación del intento del emisor de SMTP, y el cliente puede enviar
los datos. Los datos de correo incluye no sólo el cuerpo del mensaje, sino también la
información de cabecera de memo, como el To:, cc., bcc: y lineas de subject.

5. Cuando el cliente desea terminar la sesión de SMTP, lo indica enviando el comando QUIT
y el servidor cierra la conexión. Ası́ mismo también se ocupa la instrucción hCRLF i .
hCRLF i

Una imagen del funcionamiento se puede observar en la figura 2.

3
 Figura 2: Sesión Clásica del Protocolo SMTP

2.1. Comandos de SMTP

El emisor de SMTP envı́a comandos de SMTP, que siguen una sintaxis sencilla y directa
como se muestra en el cuadro 1 (los corchetes indican los parámetros del comando). El emisor
de SMTP procesa los comandos enviados para realizar determinadas funciones como abrir un
canal de transmisión o iniciar la transferencia de correo y el proceso receptor de SMTP devuelve
las respuestas.

2.2. Diagramas de Estado

Los siguientes son diagramas de estado de una sencilla implementación STMP. Por cada
comando hay tres posibles resultados: “success” (S), “failure” (F), y “error” (E)”. En los estados
de diagrama debajo, usamos el simbolo “B” para “begin”, y el sı́mbolo ”, para “espera por
respuesta”. La figura 3 representa la mayorı́a de los comandos SMTP:

Figura 3: Diagrama de estado SMTP

4
Comando Descripción Sintaxis
AUTH AUTHENTICATE. Se usa para iniciar una se- ATRN { hSP i nombre
sión de transferencia de correo con autenticación de dominio } hCRLF i
(en la que el usuario proporciona su nombre de
usuario y contraseña al receptor de SMTP para
continuar la sesión)
DATA DATA. Las lineas que siguen a este comando DATA hCRLF i
forman los datos del correo del emisor al receptor
EHLO EXTENDED HELLO. Un cliente que dispone EHLO hSP i hdominioi
de las extensiones de SMTP envı́a este comando hCRLF i
en lugar del comando HELO al iniciar una se-
sión. Si el servidor de SMTP qu erecibe este co-
mando admite las extensiones de SMTP, devuel-
ve una respuesta 250 (Requested Mail Action
Okay, completed). Si el servidor de SMTP que
recibe el mensaje no las admite, devolverá un
mensaje 500 (Syntax Error, Command Unrecog-
nized) para indicar al emisor que no puede usar
comandos extendidos.
HELO HELLO. Se usa para identifica al emisor de HELO hSP i
SMTP ante el receptor y empezar una nueva hHostEmisorSM T P i
transacción hCRLF i
MAIL MAIL. Se usara para iniciar una transacción de Mail hSP i hRutaInvi
correo entre un emisor y un receptor de SMTP, hCRLF i
limpia el búfer de la ruta inversa, el búfer de
la ruta directa y el búfer de correo e inserta el
argumento de ruta inversa de este comando en
el búfer de ruta inversa
NOOP NO OP. No tiene ningún efecto en ningún búfer NOOP hCRLF i
y no especifica ninguna acción salvo que el re-
ceptor devuelve una respuesta OK.
QUIT QUIT. Especifica que el receptor devuelve una QUIT hCRLF i
respuesta OK y cierra el canal de transmisión.
RCPT RECIPIENT. Identifica que el receptor devuelve RCPT hSP i TO:
una respuesta OK y cierra el canal de transmi- hRutaDirectai
sión hCRLF i
RSET RESET. Especifica que la transacción actual de RSET hCRLF i
correo se abortó y se limpiaron todos los búfer.
El receptor de SMTP responde con un mensaje
de OK

Cuadro 1: Comandos comunes SMTP

5
 Dónde el diagrama de la figura 3, modela los siguientes comandos: HELO, MAIL, RCPT,
RSET, SEND, SOML, SAML, VRFY, EXPN, HELP, NOOP, QUIT, TURN.

2.3. Respuestas de SMTP

Las respuestas de SMTP las envı́a el receptor de SMTP en respuesta a los comandos del
emisor de SMTP. Todos los comandos deben generar una y sólo una respuesta. Similar a los
códigos de respuesta de los servidores de FTP, los receptores de SMTP envı́an un número
en código de tres dı́gitos seguido de un texto descriptivo. Como en FTP, el primer dı́gito del
código de la respuesta indica el tipo general de la respuesta y el segundo dı́gito proporciona
información adicional de la categorı́a de la respuesta, el tercer dı́gito ofrece una escala más fina
del significado en cada categorı́a especificado por el segundo dı́gito, por ejemplo, un comando
tal como NOOP, cuya exitosa ejecución no ofrece al emisor SMTP ninguna nueva información,
regresará una respuesta 250. La respuesta es 502 cuando el comando solicita una acción no
implementada, de ningún sitio especifico. Una refinación de eso, es la respuesta 504 por un
comando que está implementado, pero que solicita un parámetro sin aplicarse. Una explicación
más detallada de cada comando se puede apreciar en las tablas 2 y 3.

Valor del Primer Indicador Descripción

dı́gito
2yz Respuesta de ter- La acción solicitada se ha completado y se puede
minación positiva enviar un nuevo comando
5yz Respuesta de ter- Ha ocurrido un error que evita que se procese el
minación negati- comando; el comando (o secuencia de comandos)
va permanente no se deberı́a volver a enviar sin modificaciones

Cuadro 2: Códigos de respuesta SMTP. Primer dı́gito

Valor del segundo Indicador Descripción

dı́gito
x0z Sintaxis Hay un error de sintaxis; el comando enviado no
está implementado en el servidor o no reconoce
esá categorı́a de comando
x1z Información Respuesta a solicitud de información, como con
la ayuda.
x2z Conexiones Respuestas, refiriéndose a los canales de trans-
misión
x5z Sistemas de co- Estado del sistema de correo relacionado con el
rreo comando o transferencia solicitados

Cuadro 3: Códigos de respuesta SMTP. Segundo Dı́gito

2.4. Implementación Mı́nima de SMTP

En orden de hacer SMTP un entorno dónde se pueda trabajar, las siguientes implementa-
ciones de comandos son requeridos por todos los servicios:

HELO, MAIL, RCPT, DATA, RSET, NOOP, QUIT.

6
3. SMTP y los servicios de transporte
3.1. TCP servicio de transporte
El Protocolo de control de transmisión (TCP) es usado en ARPA Internet, y en cualquier
red siguiendo los estándares para protocolos de redes de internet.

Establecimiento de Conexión. El canal de Transmisión SMTP es una conexión TCP

establecida entre el puerto emisor de proceso U y el puerto receptor de proceso L. Esta
sencilla conexión full-duplex es usada como un canal de transmisión. Este protocolo es
asignado al puerto de servicio 25 (31 en octal), esto significa: L=25.

Transferencia de Información. La conexión TCP suporta la transmisión de 8-bit bytes.

La información SMTP son 7-bit carácteres ASCII. Cada carácter es transmitido como un
8-bit byte, con el bit de mayor orden limpiado a cero.

3.2. NCP servicio de transporte

El protocolo Host-a-Host de Arpanet (implementada por el programa de control de redes)
puede ser usado en ARPANET.

Establecimiento de conexión. El canal de transmisión SMTP es establecido via NCP

entre el socket del proceso emisor U y el socket de proceso receptor L. El protocolo de
conexión iniciar es seguido resultando en un par de sencillas conexiones. Este par de
conexiones es usado como el canal de transmisión. Este protocolo es asignado al socket de
contacto 25 (31 octal), esto es: L=25.

Transferencia de información. Las conexiones de información NCP, están establecidas

en un modo de 8-bits (byte). La información SMTP son 7-bit caracteres ASCII. Cada
carácter es transmitido como un 8-bit byte, con el bit de mayor orden limpiado a cero.

3.3. NITS
El servicio de transporte de red independiente (Network Independent Transport Service
-NITS), puede ser usado.

Establecimiento de conexión. El canal de transmisión SMTP es establecido via NITS

entre el proceso emisor y el proceso receptor. El proceso emisor ejecuta un primitivo
CONNECT, ay el proceso receptor ejecuta un primitivo ACCEPT.

Transferencia de información.La conexión NITS soporta la transmisión de 8-bit (by-

te).La información SMTP son 7-bit caracteres ASCII. Cada carácter es transmitido como
un 8-bit byte, con el bit de mayor orden limpiado a cero.

7
4. Bibliografı́a

Referencias
[1] RFC821, IETF. “https://www.ietf.org/rfc/rfc0821.txt”.

[2] RFC2821, IETF. “https://www.ietf.org/rfc/rfc2821.txt”.

[3] How to Run Your own Email server, Arstecnica, “http://arstechnica.com/information-

technology/2014/02/how-to-run-your-own-e-mail-server-with-your-own-domain-part-1/”.

[4] Thomas Lee, Joseph Davies “Windows 2000 TCP/IP Protocolos y servicios. Referencia
técnica”. Microsoft, 2000.