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 usuarioTo: 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 MSTMessage-Id: <9307191947.AAO0502@sun.tuc.noao.edu.>From: rstevens@sun.tuc.noao.edu (Richard Stevens)Date: Mon, 19 Jul 1993 12:47:31 -0700Reply-To: rstevens@noao.eduX-Phone: +1 602 676 1676X-Mailer: Mail User's Shell (7.2.5 10/14/92)To: rstevens@noao.eduSubject: 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:

ReceivedMessage-Id

FromDateReply-ToX-PhoneX-MailerToSubject

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:

Mlfarm.com 86388 IN MX 10 mercury.hsi.com

Mlfarm.com 86388 IN MX 15 hsi86.hsi.comAdditional information:Mercury.hsi.com 86388 IN A 143.122.1.91Hsi86.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 MTATo: 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

4 0.985428 (0.4797) Mercury.hsi.com.25 > sun.1143: S 1832064000:1832064000(0) ack 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.edusun.tuc.noao.edu 86400 IN MX 10 noao.eduAdditional information:sun.tuc.noao.edu 86400 IN A 140.252.1.29sun.tuc.noao.edu 86400 IN A 140.252.13.33noao.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. EOTrstevens@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 25220-vangogh.CS. Berkeley. EDU Sendmail 8.1C/6.32 ready at Tue, 3 Aug 1993 14: 59:12 -0700220 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 nosuchname550 nosuchname... User unknown vrfy rstevens250 Richard Stevens <rstevens@vangogh.CS.Berkeley.EDU> expn rstevens250 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 25220 whitehouse.gov SMTP/smap Ready. helo aun.tuc.noao.edu250 (sun.tuc.noao.edu) pleased to meet you. vrfy Clinton500 Command unrecognized

expn Clinton500 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 Telnetsun % telnet vangogh.cs.berkeley.edu 25220-vangogh.CS.Berkeley.EDU Sendmail 8.1C/6.32 ready at Mon, 2 Aug 1993 15: 47:48 -0700220 ESMTP spoken here ehlo sun.tuc.noao.edu250-vangogh.CS.Berkeley.EDU Hello sun.tuc.noao.edu [140.252.1.29], pleased to meet you250-EXPN250-SIZE250 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 25220 ymir.claremont.edu -- Server SMTP (PMDF V4.2-13 #4220) ehlo sun.tuc.noao.edu250-ymir.claremont.edu250-8BITMIME250-EXPN250-HELP250-XADR250 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 25220 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 you250-HELP250-SIZE250-XONE250-XVRB250 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 25220 relay1.UU.NET Sendmail 5.61/UUNET-internet-primary ready at Mon, 2 Aug 93 18:50:27 -0400 ehlo sun.tuc.noao.edu500 Command unrecognized rset250 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.

6-bit valueASCII char 6-bit value ASCII

char 6-bit value ASCII char 6-bit value ASCII

char0 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.0Content-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

Text plain richtextenriched

Texto sin formato.Texto con formato simple, tal como negrita, cursivas, subrayado, etc. Una clarificación, simplificación, y refinamiento de richtext.

Multipart

Mixedparalleldigestalternative

Múltiples partes del cuerpo a ser procesadas secuencialmente.Múltiples partes del cuerpo que pueden ser procesadas paralelamente.Un digest de mail electrónico.Múltiplex partes del cuerpo son presentadas, todas con idénticos contenidos semánticos.

Message rfc822partialexternal-body

El contenido es otro mensaje de mail RFC 822.El contenido es un fragmento de un mensaje de mail.El contenido es un puntero al mensaje actual.

Application octet-streampostscript

Datos arbitrarios binariosUn programa PostScript.

Image Jpeggif

Formato ISO 10918.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ónimoTo: rfc-dist@nic.ddn.mil Subject: RFC1479 on IDPR Protocol

Mime-Version: 1.0Content-Type: Multipart/Mixed; Boundary="NextPart"Date: Fri, 23 Jul 93 12:17:43 PDTFrom: "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