SMTP: Protocolo de Transferencia de Correo simple

Introducción
El correo electrónico (e-mail) es indudablemente una de las aplicaciones más populares. [Paxson
1993] encontró que en promedio, un mensaje de correo contiene alrededor de 1500 bytes de datos,
pero algunos mensajes contienen varios megabytes de datos. Esto es porque por medio del correo
electrónico a veces se envían archivos. La Figura siguiente muestra un entorno de intercambio de
correo electrónico utilizado por TCP/IP.

Nota: Esta introducción así como los ejemplos de cada uno de los casos, además de las gráficas
fueron extractados de TCP/IP Illustrated, Volumen 1, de W. Richard Stevens.

Perfil del correo electrónico en Internet.

Los usuarios tratan con un agente de usuario. Este se puede escoger entre una gran variedad. Los
agentes de usuario mas populares para UNIX incluyen MH, Berkeley Mail, Elm, y Mush.

El intercambio de correo que usa TCP es realizado por un agente de transferencia de mensajes
(MTA). El MTA más común para los sistemas UNIX es Sendmail. Los usuarios normalmente no
tratan con el MTA. La configuración del MTA local es responsabilidad del administrador del sistema.
Sin embargo, los usuarios tienen a menudo opciones para escoger sus agentes de usuario.

Este resumen examina el intercambio de correo electrónico entre MTAs que usan TCP. Nosotros no
prestaremos atención al l funcionamiento o al diseño de los agentes de usuario.

RFC 821 [Postel 1982] especifica el protocolo SMTP. Este describe cómo se comunican entre sí
dos MTAs a través de una conexión TCP.
RFC 822 [Crocker 1982] especifica el formato del mensaje de correo electrónico que se transmite
utilizando RFC 821 entre dos MTAs.

Protocolo SMTP
La comunicación entre dos MTAs utiliza NVT ASCII. Los comandos son enviados desde el cliente
al servidor, y el servidor responde con códigos de respuesta numéricos y strings optativos
comprensibles por humanos. Esto es similar a lo que nosotros vimos con FTP en la ficha anterior
(ref. Introducción a FTP).

Hay menos de 12 comandos que un cliente puede enviar a un servidor (Por comparación,
recordemos que FTP tiene más de 40 comandos). En lugar de describir cada uno de ellos,
nosotros empezaremos con un ejemplo simplificado para mostrar su comportamiento cuando
enviamos un correo.
Ejemplo simple
Enviaremos un mensaje de una línea y miraremos la conexión SMTP. Para hacer esto invocaremos a nuestro
agente de usuario con el parámetro - v, que se pasará al agente de transporte de correo (Sendmail en este
caso). Cuando se especifica este parámetro, nuestro MTA despliega lo que se envía y recibe a través de la
conexión SMTP. Las líneas que empiezan con ">>>" son comandos enviados por el cliente SMTP, y las líneas
que empiezan con un código de 3 dígitos son respuestas del servidor SMTP. Aquí esta la sesión interactiva:
sun % mail -v rstevens@noao.edu Invoca a nuestro agente de usuario
To: rstevens@noao.edu Esta es la salida para el agente de usuario
Subject : testing Prompteamos un tema
El agente usuario agrega una línea en blanco entre el
encabezado y el cuerpo
1, 2, 3. Esto es lo que nosotros tipeamos como el cuerpo del
mensaje
. Nosotros tipeamos un punto sobre una línea para
indicar que terminamos
Sending letter ...
rstevens@noao.edu... Mensaje emergente desde el agente usuario
Lo siguiente es la salida de MTA (Sendmail)
Connecting to mailhost via ether...
Trying 140.252.1.54... connected.
220 noao.edu Sendmail 4.1/SAG-Noao.G89 ready at Mon, 19 Jul 93 12:47:34
MST
>>> HELO sun.tuc.noao.edu.
250 noao.edu Hello sun.tuc.noao.edu., pleased to meet you
>>> MAIL From: <rstevens@sun.tuc.noao.edu>
250 <rstevens@sun.tuc.noao.edu>... Sender ok
>>> RCPT To:<rstevens@noao.edu>
250 <rstevens@noao.edu>... Recipient ok
>>> DATA
354 Enter mail, end with "." on a line by itself
>>> .
250 Mail accepted
>>> QUIT
221 noao.edu delivering mail
Rstevens@noao.edu... Sent

Solamente son utilizados cinco comandos SMTP para enviar el correo: HELO, MAIL, RCPT, DATA,
y QUIT.

Nosotros escribimos mail para invocar a nuestro agente de usuario. Luego prompteamos el tema
(referido al correo que se va a enviar), y después tipeamos el cuerpo del mensaje. Escribiendo en
una línea solo un punto, el agente de usuario pasa el correo al MTA para la entrega.

El cliente hace una apertura activa al puerto TCP 25. A continuación espera un mensaje de regreso
correspondiente a un saludo del servidor (código de respuesta 220). La respuesta de este servidor
debe empezar con el nombre de dominio completo del host servidor: "noao.edu" en este ejemplo:
220 noao.edu Sendmail 4.1/SAG-Noao.G89 ready at Mon, 19 Jul 93 12:47:34 MST
(Normalmente el texto que sigue al código de respuesta numérico es optativo, aquí es requerido el
nombre de dominio y el texto que empieza con "Sendmail" es optativo.)
Luego el cliente se identifica con el comando HELO. El argumento debe ser el nombre del dominio
completo del host cliente: sun.tuc.noao.edu:

>>> HELO sun.tuc.noao.edu.

El comando MAIL identifica al creador del mensaje:
>>> MAIL From: <rstevens@sun.tuc.noao.edu>
El próximo comando, RCPT, identifica al destinatario:
>>> RCPT To:<rstevens@noao.edu>
Pueden emitirse mas de un comando RCPT si hay múltiples destinatarios.
El contenido del mensaje de correo es enviado por el cliente usando el comando DATA:
>>> DATA
El fin del mensaje es especificado por el cliente enviando una línea que contiene simplemente un
punto. El comando final, QUIT, termina el intercambio del correo.

La Figura siguiente es una línea de tiempo de la conexión SMTP entre el remitente SMTP (el
cliente) y el receptor SMTP (servidor). Nosotros hemos quitado el establecimiento y finalización de
la conexión y los anuncios clásicos de tamaño de ventana.

La cantidad de datos que nosotros tipeamos a nuestro agente de usuario fue un mensaje del una
línea ("1, 2, 3. "). De igual forma son enviados 393 bytes de datos en el segmento 12. Las siguiente
12 líneas comprenden los 393 bytes que se envían por el cliente:
Received: by sun.tuc.noao.edu. (4.1/SMI-4.1)
id AA00502; Mon, 19 Jul 93 12:47:32 MST
Message-Id: <9307191947.AAO0502@sun.tuc.noao.edu.>
From: rstevens@sun.tuc.noao.edu (Richard Stevens)
Date: Mon, 19 Jul 1993 12:47:31 -0700
Reply-To: rstevens@noao.edu
X-Phone: +1 602 676 1676
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: rstevens@noao.edu
Subject: testing
1, 2, 3.

Las primeras tres líneas (Received y Message-Id): son agregados por el MTA, y las próximas
nueve son generadas por el agente de usuario.

Comandos SMTP
Una aplicación de SMTP básica necesita 8 comandos. Nosotros vimos cinco de ellos en el ejemplo
anterior: HELO, MAIL, RCPT, DATA, y QUIT.

El comando RSET aborta la transacción de correo actual y causa que el cliente y el servidor
finalicen para poder restablecerse. Cualquier información almacenada sobre el remitente, los
destinatarios, o los datos del correo será descartada.

El comando VRFY permite al cliente verificar una dirección de destinatario, antes de enviar el
correo. Es usado a menudo y de forma manual por el administrador del sistema para solucionar
problemas de reparto. En la próxima sección mostraremos un ejemplo de esto.

El comando NOOP no hace nada, salvo forzar al servidor para responder con una contestación OK
código (200).

Hay comandos adicionales, optativos. EXPN extiende una lista de correo, y se usa a menudo por el
administrador del sistema, de igual forma que VRFY. De hecho, la mayoría de las versiones de
Sendmail manejan los dos idénticamente (excepto la versión 8 de Sendmail en BSD 4.4).

El comando TURN permite al cliente y al servidor cambiar de roles, para enviar el correo en
dirección inversa, sin tener que bajar la conexión TCP y crear una nueva. (Sendmail no soporta
este comando). Hay otros tres comandos (SEND, SOML, y SAML), qué raramente son
implementados, y que reemplazan al comando MAIL.

Los sobres, el encabezado, y el cuerpo

El correo electrónico está compuesto de tres partes:
Los sobres, el encabezado, y el cuerpo como se menciona en el titulo de esta sección.

1- El sobre es utilizado por los MTAs para la entrega. En nuestro ejemplo el sobre fue especificado
por los dos comandos (MAIL Y RCPT) de SMTP:

MAIL From: <rstevens@sun.tuc.noao.edu>

RCPT To:<rstevens@noao.edu>

RFC 821 especifica los contenidos e interpretación del sobre, y el protocolo usado para el
intercambio de correo a través de una conexión TCP.

2- Los encabezados son usados por los agentes de usuario. Nosotros vimos en nuestro ejemplo
nueve campos de encabezado:
Received
Message-Id
 From
Date
Reply-To
X-Phone
X-Mailer
To
Subject
Cada campo del encabezado contiene un nombre seguido por dos puntos, y a continuación el
valor del campo. RFC 822 especifica el formato e interpretación de los campos del encabezado.
(Los encabezados que empiezan con una X son campos definidos por el usuario. Los otros se
definen por RFC 822). El largo de los campos de encabezado, tal como "Recibed" en el ejemplo,
se despliega sobre múltiples líneas.

3- El cuerpo es el contenido del mensaje enviando al usuario receptor. RFC 822 especifica el
cuerpo como líneas de NVT (texto ASCII). Cuando se realiza la transferencia usando el comando
DATA, se envía primero el encabezado, seguido por una línea en blanco, y a continuación el
cuerpo. Cada línea transferida usando el comando DATA debe tener menos de 1000 bytes.

El agente del usuario toma lo que nosotros especificamos como cuerpo, agrega algunos
encabezados, y pasa el resultado al MTA. El MTA agrega mas encabezados, el sobre, y envía el
resultado a otro MTA.

El término "content" describe a menudo la combinación de encabezado y cuerpo. "Content" se

envía con el comando DATA.

Agentes de parada (Relay)

La primera línea de salida informada por nuestro MTA local en nuestro ejemplo es "Connecting to
mailhost via ether.". Esto es porque el sistema del autor se ha configurado para enviar el correo
saliente no local a una máquina de parada ("Relay Agent") para la entrega.

Esto se hace por dos razones. Primero, simplifica la configuración de todos los otros MTAs del
sistema de MTA de parada. (Configurar un MTA no es simple, como cualquiera que halla trabajado
alguna vez con Sendmail puede atestiguar). Segundo, permite a un sistema en una organización
actuar como buzón de correo, dando la posibilidad de esconder todos los sistemas individuales.

En este ejemplo el sistema de parada tiene un nombre de host "mailhost" en el dominio local
(.tuc.noao.edu) y todos los sistemas individuales se configuran para enviar su correo a este host.
Nosotros podemos ejecutar el comando host para ver cómo se define este nombre en el DNS:

sun % host mailhost

mailhost.tuc.noao.edu CNAME noao.edu Nombre canónico
noao.edu A 140.252.1.54 dirección IP

Si el host usado como parada cambiara en el futuro, sólo se necesitaría cambiar su nombre DNS
(la configuración del correo de todos los sistemas individuales no cambia.)

Hoy, la mayoría de las organizaciones está usando sistemas parada. La figura que sigue es una
representación del correo de Internet, teniendo en cuenta que el host emisor y el host receptor final
utilizan probablemente un host de parada.
 Correo electrónico de Internet, con un sistema de parada a ambos extremos.

En este esquema hay cuatro MTAs entre el remitente y receptor. El MTA local en el host del
remitente apenas entrega el correo a su MTA de parada. (Este MTA de parada podría tener un
nombre de host "hostmail" en el dominio de la organización). Esta comunicación usa SMTP por la
red local de la organización. El MTA de parada en la organización del remitente envía entonces el
correo al MTA de parada del host receptor por la Internet. Entonces este otro MTA de parada
entrega el correo al host receptor, a través de la comunicación con el MTA local del host receptor.
Todos los MTAs en este ejemplo utilizan SMTP, aunque existe la posibilidad de que utilicen otros
protocolos.

NVT ASCII
Un rasgo de SMTP es que utiliza NVT ASCII para el sobre, los encabezados, y el cuerpo. Este es
un código de caracteres de 7-bit, transmitidos como bytes de 8-bit, con el bit de mayor orden
seteado a 0.

Mas adelante discutiremos algunos rasgos más nuevos del correo de Internet, SMTP extendido y
correo multimedial (MIME), estos permiten el envío y recepción de datos tales como audio y vídeo.
Nosotros veremos la forma en que trabaja MIME con NVT ASCII para el sobre, el encabezado, y el
cuerpo, con los cambios que se requieren solo en los agentes de usuario.
Intervalos para reintentar enviar un mensaje.
Cuando un agente del usuario pasa un nuevo mensaje de correo a su MTA, la entrega
normalmente se intenta inmediatamente. Si la entrega falla, el MTA debe encolar el mensaje y
volver a intentarlo mas tarde.

RFC recomienda una interrupción inicial de por lo menos 30 minutos. El remitente no debe rendirse
durante por lo menos 4-5 días. Además, los fracasos de entrega son a menudo transeúntes (se
puede deber a una pérdida temporal de la conectividad de la red), esto hace que tenga sentido
probar dos intentos de conexiones durante la primera en la que el mensaje está en la cola.

Ejemplos de SMTP
En la sección anterior mostramos un reparto normal, aquí nosotros mostraremos cómo son usados
los registros MX para el reparto de correo, e ilustraremos los comandos VRFY y EXPN.

Registros MX: host no conectados directamente a la Internet

Un tipo de registros de recursos DNS llamados registros MX son los registros de intercambio de
correo. En el ejemplo siguiente nosotros mostraremos cómo se usan los registros MX para enviar
el correo a host que no se conectan directamente a Internet. RFC 974 [Partridge 11986] describe el
manejo de registros MX por parte de los MTAs.

El host mlfarm.com no se conecta directamente a Internet, pero tiene un registro MX que apunta a
un "forwardeador"* de correo que está en la Internet:

*Nota: el termino "forwardeador" seguramente lo hemos inventado nosotros aquí, esto se debe a
que nos pareció que no se podía reemplazar adecuadamente por otro mejor. Para nuestro caso
representa a "una entidad capaz de recibir el mensaje y reenviarlo".

sun % host -a-v-t mx mlfarm.com

The following answer is not authoritative:
10
Mlfarm.com 86388 IN MX
mercury.hsi.com
Mlfarm.com 86388 IN MX 15 hsi86.hsi.com
Additional information:
Mercury.hsi.com 86388 IN A 143.122.1.91
Hsi86.hsi.com 172762 IN A 143.122.1.6

Como se ve en la tabla, hay dos registros MX, cada uno con una preferencia diferente. Nosotros
esperamos que el MTA empiece con el más bajo de los dos valores de preferencia.

La escritura siguiente muestra el mail enviado a este host:

sun % mail -v ron@mlf arm.com El parametro -v para ver que haca el MTA
To: ron@mlf arm.com
Subject: MX test message
El cuerpo de mensaje se tipea aquí (no se muestra).
Un punto sobre una línea completa se utiliza para
finalizar el mensaje
Sending letter ... ron@mlfarm.com...
Connecting to mlfarm.com via tcp
... mail exchanger is mercury.hsi.com El registro MX fue encontrado
Trying 143.122.1.91... connected. Primero intenta uno con la preferencia mas baja
220 mercury.hsi.com ... El remitente es un transferidor SMTP normal

Nosotros podemos ver en esta salida que el MTA descubrió que el host destino tenía un registro
MX y usó el registro MX con el valor de preferencia más bajo.
Antes de ejecutar este ejemplo desde el host "sun", este fue configurado para no usar a su host de
parada normal, para que nosotros pudiéramos ver el intercambio de correo con el host destino.
También fue configurado para usar el servidor de nombres en el host noao.edu (el cual es accedido
a través de su enlace SLIP (dialup)), para que nosotros pudiéramos capturar la transferencia de
correo y el trafico DNS usando tcpdump sobre el enlace SLIP. La figura siguiente muestra la
porción inicial de la salida de tcpdump.

1 0.0 Sun.1624 > noao.edu.53: 2+ MX? mlfarm.com. (28)

2 0.445572 (0.4456) Noao.edu.53 > sun.1624: 2* 2/0/2 MX mercury.hsi.com. 10 (113)
3 0.505739 (0.0602) Sun.1143 > mercury.hsi.com.25: S 1617536000:1617536000(0) win 4096
Mercury.hsi.com.25 > sun.1143: S 1832064000:1832064000(0) ack
4 0.985428 (0.4797) 1617536001 win 16384
5 0.986003 (0.0006) Sun.1143 > mercury.hsi.com.25: . ack 1 win 4096
6 1.735360 (0.7494) Mercury.hsi.com.25 > sun.1143: P 1:90(89) ack 1 win 16384

Envío de correo utilizando registros MX

En la línea 1 el MTA pregunta a su servidor de nombre por un registro MX para "mlfarm.com". La

contestación en la línea 2 tiene el bit autoritario puesto (el asterisco que sigue a 2) y contiene 2
respuestas RRs (los dos nombres de host MX), 0 RRs autoridad, y 2 RRs adicionales (la dirección
IP de los dos host).

En las líneas 3-5 se establece una conexión TCP con el servidor SMTP sobre el host
mercury.hsi.com. La respuesta inicial del servidor 220 se muestra en la línea 6.

De algún modo el host mercury.hsi.com debe entregar este mensaje de correo al destino,
mlfarm.com. Los protocolos de UUCP son una manera popular para intercambiar correo con su
sitio de MX en un sistema no conectado a la Internet.

En este ejemplo el MTA pide un registro MX, consigue un resultado positivo, y envía el correo.
Desgraciadamente la interacción entre un MTA y los DNS puede diferir entre las aplicaciones. RFC
974 especifica que un MTA debe pedir los registros MX primero, y si no se encuentra ninguno,
intentar la entrega al host destino. Los MTAs también deben tratar con los registros CNAME en el
DNS (nombres canónicos).

Como un ejemplo, si nosotros enviamos el correo a rstevens@mailhost.tuc.noao.edu desde un host

BSD/386, el MTA (Sendmail) ejecuta los siguientes pasos.

1- Sendmail le pide al DNS los registros CNAME para mailhost.tuc.noao.edu. Vemos que un
registro de CNAME existe:

sun % host -t cname mailhost.tuc.noao.edu

mailhost.tuc.noao.edu CNAME noao.edu

2- Se emite una consulta DNS para los registros de CNAME para noao.edu y la contestación dice
que no existe ninguno.

3- Entonces Sendmail le pregunta a DNS por los registros MX para noao.edu y consigue un
registro MX:

sun % host -t mx noao.edu

noao.edu MX noao.edu

4- Sendmail consulta el DNS por un registro A (dirección IP) para noao.edu y obtiene el valor
140.252.1.54. (Este registro A probablemente fue retornado por el servidor de nombres para
noao.edu como un RR adicional con la respuesta MX en el paso 3.)
5- Se comienza una conexión SMTP a 140.252.1.54 y el correo se envía.

Registros MX: Host que están desconectados

Otro uso de los registros MX es proporcionar un receptor de correo alternativo cuando el host
destino está desconectado. Si nosotros miramos la entrada DNS para nuestro host "sun" nosotros
vemos que tiene dos registros MX:

sun % host -a-v-t mx sun.tuc.noao.edu

sun.tuc.noao.edu 86400 IN MX 0 sun.tuc.noao.edu
sun.tuc.noao.edu 86400 IN MX 10 noao.edu
Additional information:
sun.tuc.noao.edu 86400 IN A 140.252.1.29
sun.tuc.noao.edu 86400 IN A 140.252.13.33
noao.edu 86400 IN A 140.252.1.54

Los registros MX con la preferencia más baja indican que debe intentarse primero la entrega
directa a ese mismo host, y la próxima preferencia es entregar el correo al host noao.edu.

En el siguiente párrafo nos enviamos el correo a nosotros mismos al host sun.tuc.noao.edu, desde
el host vangogh.cs.berkeley.edu, después de apagar el servidor de SMTP destino. Cuando una
demanda de conexión llega al puerto 25, TCP debe responder con un RST, a partir de que ningún
proceso tiene una apertura pasiva pendiente para ese puerto.

vangogh % mail -v rstevens@sun.tuc.noao.edu

A test to a host that's down.
EOT
rstevens@sun.tuc.noao.edu... Connecting to sun.tuc.noao.edu. (smtp)...
rstevens@sun.tuc.noao.edu... Connecting to noao.edu. (smtp)...
220 noao.edu remainder is normal SMTP mail transfer

Nosotros vemos que el MTA intenta contactar a sun.tuc.noao.edu y entonces se rinde y encambio
contacta a noao.edu.

La tabla siguiente es la salida de tcpdump que muestra que TCP responde al SYNs entrante con
un RST.

1 0.0 vangogh.3873 > 140.252.1.29.25: S 2358303745:2358303745(0) ...

2 0.000621 (0.0006) 140.252.1.29.25 > vangogh.3873: R 0:0(0) ack 2358303746 win 0
3 0.300203 (0.2996) vangogh.3874 > 140.252.13.33.25: S 2358367745:2358367745(0) ...
4 0.300620 (0.0004) 140.252.13.33.25 > vangogh.3874; R 0:0(0) ack 2358367746 win 0
Esfuerzo por conectar a un servidor de SMTP que no esta corriendo.

En la línea 1 "vangogh" le envía un SYN al puerto 25 de la dirección IP primaria para "sun":

140.252.1.29. En la línea 2 se rechaza. El cliente SMTP en "vangogh" entonces prueba la próxima
dirección IP para "sun": 140.252.13.33 (línea 3), y esto también causa que sea retornado un RST
(línea 4).

El cliente SMTP no intenta diferenciar entre los diferente errores retornados desde su apertura
activa en la línea 1, por lo cual intenta otras direcciones IP en la línea 3. Si el error hubiera sido
algo como "host unreachable" para el primer intento, es posible que el segundo intento pudiera
trabajar.

Si el motivo de que las aperturas activas de los clientes SMTP fallen es porque el host servidor
esta desconectado, nosotros veríamos que el cliente retransmitiría el SYN a la dirección IP
140.252.1.29 durante un periodo total de 75 segundos, a continuación el cliente enviara otros tres
SYNs a la dirección IP 140.252.13.33 durante otros 75 segundos. Después de 150 segundos el
cliente seguiría al próximo registro MX con la preferencia más alta.

Comandos VRFY y EXPN

El comando VRFY verifica que una dirección de destinatario este correcta, sin enviar el correo
realmente. Se piensa que EXPN extiende una lista de mailing, sin enviar el correo a la lista.
Muchas aplicaciones de SMTP (como Sendmail) consideran igualmente a los dos, pero
mencionaremos que las más nuevas versiones de Sendmail diferencian entre ambos.

Como una prueba simple podemos conectarnos a una nueva versión de Sendmail y ver la
diferencia.

sun % telnet vangogh.cs.berkeley.edu 25

220-vangogh.CS. Berkeley. EDU Sendmail 8.1C/6.32 ready at Tue, 3 Aug 1993
14: 59:12 -0700
220 ESMTP spoken here
helo bsdi.fcuc.noao.edu
250 vangogh.CS.Berkeley.EDU Hello sun.tuc.noao.edu [140.252.1.29],
pleased to meet you
vrfy nosuchname
550 nosuchname... User unknown
vrfy rstevens
250 Richard Stevens <rstevens@vangogh.CS.Berkeley.EDU>
expn rstevens
250 Richard Stevens <rstevens@noao.edu>

Primero avisa que nosotros tecleamos intencionalmente un hostname erróneo en el comando

HELO: "bsdi" en lugar de "sun". La mayoría de los servidores de SMTP toma las dirección de IP del
cliente, realiza una consulta DNS y compara los nombres de host. Esto permite al servidor loguear
la conexión del cliente basado en la dirección de IP, no en el nombre que un usuario podría haber
tecleado. Algunos servidores responden con mensajes cómicos, como "Usted es un charlatán", o
"por qué no se llama usted mismo... ". Nosotros vemos en este ejemplo que este servidor solo
imprime nuestro nombre de dominio real desde el indicador de consulta con nuestra dirección de
IP:
250 vangogh.CS.Berkeley.EDU Hello sun.tuc.noao.edu [140.252.1.29],
pleased to meet you

Nosotros tecleamos un comando VRFY para un nombre no válido, y el servidor responde con un
error 550 . Luego nosotros tecleamos un nombre válido, y el servidor responde con el nombre de
usuario el host local. Luego nosotros intentamos el comando EXPN y obtenemos una contestación
diferente. El comando EXPN determina que el correo para este usuario está remitiéndose, e
imprime la dirección de forwardeo*.

Muchos sitios desactivan los comandos VRFY y EXPN, a veces por privacidad, y a veces en la
creencia que es un agujero de seguridad. Por ejemplo, nosotros podemos probar estos comandos
con el servidor de SMTP en la Casa Blanca:

sun % telnet whitehouse.gov 25

220 whitehouse.gov SMTP/smap Ready.
helo aun.tuc.noao.edu
250 (sun.tuc.noao.edu) pleased to meet you.
vrfy Clinton
500 Command unrecognized
expn Clinton
500 Command unrecognized
Futuro de SMTP
Algunos cambios están teniendo lugar en el correo de Internet. Recuerde las tres partes que
comprenden el correo de Internet: el sobre, el encabezado, y el cuerpo. Están agregándose nuevos
comandos SMTP que afectan al sobre, pueden usarse los caracteres no-ASCII en los encabezados
y sé esta agregando estructura al cuerpo (MIME). En esta sección nosotros consideraremos las
extensiones a cada una de estas tres partes en orden.

Cambios del sobre: SMTP extendido

RFC 1425 [Klensin 1993] define la estructura de trabajo para agregar las extensiones a SMTP. El
resultado se llama SMTP extendido (ESMTP). Como con otros nuevos rasgos que nosotros hemos
descrito en el texto, estos cambios están agregándose de una que continúe la compatibilidad con lo
anterior, para que las aplicaciones existentes no sean afectadas.

Un cliente que desea usar a las nuevas características inicia la sesión con el servidor emitiendo un
comando EHLO, en lugar de HELO. Un servidor compatible responde con un código 250. Esta
contestación normalmente es multilinea, y cada línea contiene una palabra clave y un argumento
optativo. Estas palabras claves especifican las extensiones SMTP soportadas por el servidor. En
un RFC se describirán las nuevas extensiones y se registrarán en el IANA. (En una contestación
multilinea todas las líneas excepto la última tienen un guión después del código de respuesta
numérica. La última línea tiene un espacio después del código de respuesta numérica.)

Nosotros mostraremos la conexión inicial a cuatro servidores de SMTP tres de los cuales soportan
SMTP extendido. Nos conectamos a ellos usando Telnet, pero ha sido removida la salida del
cliente Telnet
sun % telnet vangogh.cs.berkeley.edu 25
220-vangogh.CS.Berkeley.EDU Sendmail 8.1C/6.32 ready at Mon, 2 Aug 1993
15: 47:48 -0700
220 ESMTP spoken here
ehlo sun.tuc.noao.edu
250-vangogh.CS.Berkeley.EDU Hello sun.tuc.noao.edu [140.252.1.29],
pleased to meet you
250-EXPN
250-SIZE
250 HELP

Este servidor da una contestación multilinea 220 para su mensaje de saludo. Los comandos
extendidos listados en la contestación 250 para el comando EHLO son EXPN, SIZE, y HELP. El
primero y último son de la especificación original RFC 821, pero ellos son comandos optativos. Los
servidores de ESMTP declaran que comandos opcionales optativos RFC 821 son soportados,
además de los más nuevos comandos.

La palabra clave SIZE que este servidor soporta se define en RFC 1427 [Klensin, Freed, y Moore
1993]. Permite al cliente especificar el tamaño del mensaje en bytes sobre la línea de comandos
MAIL FROM. Esto permite al servidor verificar que aceptará un mensaje de ese tamaño, antes de
que el cliente empiece a enviarlo. Este comando se agregó a partir de que el tamaño de los
mensajes de correo de Internet empezó a crecer, con el soporte para el contenido de otros
mensajes distintos de las líneas ASCII(es decir, imágenes, audio, etc.).

El próximo host también soporta ESMTP. La respuesta 250 especifica que la palabra clave SIZE
soporta un argumento optativo. Esto indica que este servidor aceptará un tamaño de mensaje de
hasta 461 Mbytes.
sun % telnet ymir.claremont.edu 25
220 ymir.claremont.edu -- Server SMTP (PMDF V4.2-13 #4220)
ehlo sun.tuc.noao.edu
250-ymir.claremont.edu
250-8BITMIME
250-EXPN
250-HELP
250-XADR
250 SIZE 461544960

La palabra clave 8BITMIME es de RFC 1426 [Klensin. 1993]. Esto le permite al cliente agregar la
palabra clave BODY al comando MAIL FROM, especificando mientras si el cuerpo contiene
caracteres NVT ASCII (valor predeterminado) o datos del 8-bits. A menos que el cliente reciba la
palabra clave 8BITMIME del servidor en respuesta a un comando EHLO, al cliente se le prohibe
enviar cualquier carácter de otra forma que no sea NVT ASCII. (Cuando hablemos sobre MIME en
esta sección, veremos que un transporte SMTP de 8-bits no es requerido por MIME.)

Este servidor también anuncia la palabra clave de XADR. Cualquier palabra clave que empieza con
un X se refiere a una extensión de SMTP local.

El próximo servidor también soporta ESMTP, mientras anuncia las palabras claves HELP y SIZE
que nosotros ya hemos visto. También apoya tres extensiones locales que empiezan con una X.

sun % telnet dbc.mtview.ca.us 25

220 dbc.mtview.ca.us Sendmail 5.65/3.1.090690, it's Mon, 2 Aug 93
15:48:50 -0700
ehlo sun. tuc.noao.edu
250-Hello sun.tuc.noao.edu, pleased to meet you
250-HELP
250-SIZE
250-XONE
250-XVRB
250 XQUE

Finalmente veremos lo que pasa que cuando el cliente intenta usar ESMTP emitiendo el comando
EHLO a un servidor que no lo soporta.

sun % telnet relay1.uu.net 25

220 relay1.UU.NET Sendmail 5.61/UUNET-internet-primary ready at Mon, 2
Aug 93 18:50:27 -0400
ehlo sun.tuc.noao.edu
500 Command unrecognized
rset
250 Reset state

En lugar de recibir una contestación 250 al comando EHLO, el cliente recibe una contestación 500.
El cliente debe emitir entonces el comando RSET, seguido por un comando HELO.

Cambios del encabezado: Caracteres no-ASCII

RFC 1522 [Moore 1993] especifica una manera de enviar los caracteres no-ASCII en los mensajes
de encabezado RFC 822. El uso principal de esto es permitir los caracteres adicionales en el
remitente, el nombre del receptor, y en el asunto. Los campos del encabezado pueden contener las
palabras puestas en código. Ellos tienen el siguiente formato:

=? charset ? encoding ? encoded-text ?=

charset es el carácter que setea la especificación. Los valores válidos son dos strings us-ascii e
iso-8859-X dónde X es un solo dígito, como en el iso-8859-1.

encoding es un solo carácter para especificar el método de codificación. Se soportan dos valores.

1- Q encoding significa citado-imprimible, y se utiliza para los juegos de los caracteres latinos. La
mayoría de los caracteres se envían como NVT ASCII (con el bit de mayor orden seteado a 0).
2- B encoding significa codificación base-64. Tres bytes consecutivos de texto (24 bits) se ponen
en código como cuatro valores de 6-bits. Los 64 caracteres ASCII NVT representan cada uno
de los posibles valores de 6-bit.Se muestra en la tabla siguiente.

ASCII ASCII ASCII ASCII

6-bit value 6-bit value 6-bit value
6-bit value char char char char
0 A 10 Q 20 g 30 w
1 B 11 R 21 h 31 x
2 C 12 S 22 i 32 y
3 D 13 T 23 j 33 z
4 E 14 U 24 k 34 0
5 F 15 V 25 l 35 1
6 G 16 W 26 m 36 2
7 H 17 X 27 n 37 3
8 I 18 Y 28 o 38 4
9 J 19 Z 29 p 39 5
A K 1a a 2a q 3a 6
B L 1b b 2b r 3b 7
C M 1c c 2c s 3c 8
D N 1d d 2d t 3d 9
E O 1e e 2e u 3e +
F P 1f f 2f v 3f /

Codificación de valores de 6-bit (codificación base-64).

Cuando el número de caracteres para poner en código no es un múltiplo de tres, se usan las
señales "igual" como los caracteres de almohadilla.

El ejemplo siguiente de estas dos codificaciones es de RFC 1522:

From: =?US-ASCII?Q?Keith_Moore?= <moore@cs.utk.edu>

To: =?ISO-8859-l?Q?Kelcl_J=F8rn_Simonsen?= <keld@dkuug.dk>
CC: =?ISO-8859-l?Q?Andr=E9_?= Pirard <PIRARD@vml.ulg.ac.be>
Subject: =?ISO-8859-1?B?SWYgeW911GNhbiByZWFklHRoaXMgeW8=?= =?ISO-8859-2?
B?dSBIbinRlcnNOYW5klHRoZSBIeGFtcGxlLg==?=

Un agente del usuario capaz de ocuparse de estos encabezados podría interpretar:

From: Keith Moore <moore@cs.utk.edu>

To: Keld J0rn Simonsen <keld@dkuug.dk>
CC: Andre Pirard <PIRARD@vml.ulg.ac.be>
Subject: If you can read this you understand the example.

Para ver cómo trabaja la codificación base-64, mire los primeros cuatro caracteres puestos en
código en la línea: SWYg. Escriba en otro lado los valores de 6-bits para estos cuatro caracteres de
la tabla anterior en binario:
(S=0xl2, W=0xl6, Y=0xl8, g=0x20)
010010 010110 011000 100000

Luego reagrupa estos 24 bits dentro de los tres bytes de 8-bit:

01001001 01100110 00100000

=0x49 =0x66 =0x20

Los cuales están en representación ASCII para I, f, y un espacio.

Cambios del cuerpo: Las Extensiones de Correo de Internet multiproposito (MIME)

Nosotros hemos dicho que RFC 822 especifica el cuerpo como líneas de texto ASCII NVT, sin
estructura. RFC 1521 [Borenstein y Freed1993] definen extensiones que permiten la estructura en
el cuerpo. Esto se llama MIME, Extensiones de Correo de Internet Multiproposito.

MIME no requiere ninguna de las extensiones que nosotros hemos descripto previamente en esta
sección. MIME solo agrega algunos nuevos encabezados (de acuerdo con RFC 822) que le dicen
la estructura del cuerpo al destinatario.
El cuerpo puede transmitirse todavía usando NVT ASCII, sin tener en cuenta los contenidos del
correo. Todo lo que se exige para intercambiar los mensajes MIME con la otra parte es que ambos
extremos tengan un agente de usuario que entienda MIME. Ningún cambio se requiere en
cualquiera de los MTAs. MIME define cinco nuevos campos del encabezado:

Mime-Version:
Content-Type:
Content-Transfer-Encoding:
Content-ID:
Content-Description:

Como un ejemplo, las siguiente dos líneas de encabezado pueden aparecer en un mensaje de
correo de Internet:
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

La versión del MIME actual es la 1.0 y el tipo de contenido es texto plano ASCII, o sea el valor
predeterminado para el correo de Internet. La palabra PLAIN es considerada un subtipo del
contenedor de tipos (TEXT), y el string charset=US-ASCII es un parámetro.

El texto es solo uno de los siete tipos contenidos definidos de MIME. La tabla siguiente resume los
16 tipos diferentes contenidos y subtipos definidos en RFC 1521. Pueden especificarse los
numerosos parámetros con toda seguridad para ciertos tipos de contenidos y subtipos.

El tipo de contenido y la codificación del traslado usado para el cuerpo son independientes. El tipo
de contenido se especifica por el campo de encabezado Content-Type, y la codificación del
traslado por el campo de encabezado Content-Transfer-Encoding. Hay cinco formatos de
codificación diferentes definidos en RFC 1521.

1- 7bit,valor predeterminado NVT ASCII.

2- citado-imprimible, nosotros vimos un ejemplo antes con los encabezados no-ASCII. Es útil
cuando sólo un fragmento pequeño de los caracteres tiene su juego de ocho bits.
3- base64 (visto anteriormente).
4- 8bit conteniendo líneas de caracteres, algunos de los cuales son no-ASCII y tienen su juego de
ocho bits.
5- codificación binaria, que es de 8-bits de datos que no necesitan contener líneas.

Tipo de contenido Subtipo Descripción

 Texto sin formato.
plain
Text richtext Texto con formato simple, tal como negrita, cursivas, subrayado,
enriched etc.
Una clarificación, simplificación, y refinamiento de richtext.
Múltiples partes del cuerpo a ser procesadas secuencialmente.
Mixed Múltiples partes del cuerpo que pueden ser procesadas
parallel paralelamente.
Multipart
digest Un digest de mail electrónico.
alternative Múltiplex partes del cuerpo son presentadas, todas con idénticos
contenidos semánticos.
rfc822 El contenido es otro mensaje de mail RFC 822.
Message partial El contenido es un fragmento de un mensaje de mail.
external-body El contenido es un puntero al mensaje actual.
octet-stream Datos arbitrarios binarios
Application
postscript Un programa PostScript.
Jpeg Formato ISO 10918.
Image
gif Formato CompuServe's Graphic Interchange.
Audio basic Codificación utilizando 8-bit ISDN //-formato ley .
Video mpeg Formato ISO 11172.
MIME los tipos y subtipos contenidos.

Sólo los primero tres de éstos son válidos para los MTA RFC 821, por que estos tres generan un
cuerpo que contiene sólo caracteres de NVT ASCII. Usando SMTP extendido con 8BITMIME
permite soporte para usar codificación de 8bit.

Aunque el contenedor de tipos y la codificación son independientes, RFC 1521 recomienda citado
-imprimible para el texto con los datos no-ASCII, y base64 para la imagen, audio, vídeo, y flujos de
octetos de datos de aplicación. Esto permite la interoperabilidad máxima con RFC 821. También los
tipos de contenidos, multiparte y mensaje deben ser codificados como 7bit.

Como un ejemplo de un tipo de contenido multiparte la figura siguiente muestra un mensaje de

correo de la lista de distribución RFC. El subtipo es mixto, lo que significa que cada una de las
partes deberán procesarse secuencialmente, y el límite entre las partes es el string NextPart,
precedido por dos guiones al inicio de una línea.

Cada límite puede seguirse con una línea que especifica los campos del encabezado para la
próxima parte.

Como una línea blanca sigue al primer límite, y sin campos de encabezado, se asume que el tipo
contenido de los datos entre los primeros y segundos límites es texto plano con un juego de
caracteres us-ascii. Ésta es una descripción textual del nuevo RFC.

El segundo límite, sin embargo, continua con los campos del encabezado. Especifica otro mensaje multiparte,
con un límite de otros accesos. El subtipo es alternativo, y dos alternativas diferentes están presentes. La
primera alternativa de otros accesos alternativos es sacar el RFC usando el correo electrónico, y la segundo es
sacarlo usando FTP anónimo. Un agente de usuario de MIME listaría las dos alternativas, nos permitiría
escoger una, y entonces automáticamente sacaría una copia del RFC que usa utilizando por correo o FTP
anónimo
To: rfc-dist@nic.ddn.mil
Subject: RFC1479 on IDPR Protocol
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Fri, 23 Jul 93 12:17:43 PDT
From: "Joyce K. Reynolds" <jkrey@isi.edu>
--NextPart --NextPart
A new Request for Comments is now available in online RFC libraries.
... ...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version of the RFCs.
--NextPart --NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server@nisc-sri.com"
Content-Type; text/plain
SEND rfcl479.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfcl479.txt";
site="ds.internic.net",
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
--OtherAccess--
--NextPart-- --NextPart--
Ejemplo de un mensaje de multiparte de MIME.
Esta sección ha sido una apreciación global breve de MIME. Para los detalles adicionales y
ejemplos de MIME, vea RFC 1521 y [Rose 1993].

Resumen
El correo electrónico involucra a un agente de usuario a ambos extremos (el remitente y receptor) y
dos o más MTAs. Nosotros podemos dividir un mensaje de correo en tres partes: el sobre, los
encabezados, y el cuerpo. También vimos cómo se intercambian las tres partes usando SMTP.
Todas se intercambian como caracteres de NVT ASCII.

También hemos visto las más nuevas extensiones para las tres partes: SMTP extendido para el
sobre, encabezados no-ASCII, y el agregado de estructura al cuerpo que usa MIME. La estructura
y codificación utilizada por MIME permite intercambiar datos binarios arbitrarios, usando SMTP
con MTAs de 7-bits existentes.

Referencia:
TCP/IP Illustrated, Volumen 1, de W. Richard Stevens