INSTITUTO POLITECNICO NACIONAL ESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA INGENIERIA EN COMUNICACIONES Y ELECTRONICA

ACADEMIA DE COMUNICACIONES

REDES DE AREA AMPLIA

PROFESOR:
DELGADO PREZ JULIO

ALUMNOS: HERNNDEZ HERNNDEZ MARIA TERESA HERNNDEZ LPEZ AUDOMARO IBARRA MONTERO JESS ALBERTO MONTERO GOMEZ FERNANDO

GRUPO: 8CM2

PROTOCOLOS DEL SERVICIO DE EMAIL

Tabla de contenido
Introduccin ...................................................................................................................................2 POP3 .............................................................................................................................................. 3 Introduccin .......................................................................................................................3 Operacin bsica ................................................................................................................3 Fase de autorizacin ..........................................................................................................4 Fase de transaccin.............................................................................................................5 Fase de actualizacin ..........................................................................................................7 Ordenes POP3 opcionales ..................................................................................................8 IMAP ............................................................................................................................................ 12 Protocolos del cliente emisor y servidor receptor ......................................................................15 SMTP ............................................................................................................................................ 22 Introduccin .............................................................................................................................22 Desarrollo ................................................................................................................................22 Estructura bsica .......................................................................................................................23 Funcionamiento de SMTP .........................................................................................................24 Resumen simple del funcionamiento del protocolo SMTP ........................................................26 Ejemplo de una comunicacin SMTP ........................................................................................27 MIME ........................................................................................................................................... 38 Descripcin general...................................................................................................................39 El campo "Content-Type" ..........................................................................................................40 El campo "Content-transfer-encoding" .....................................................................................45 BIBLIOGRAFA .............................................................................................................................. 52

INTRODUCCIN

El nacimiento del correo electrnico (email) ocurri a principios de los aos 60. El buzn era un archivo en el directorio principal de un usuario al cual slo el mismo poda acceder. Las aplicaciones de correo primitivas anexaban nuevos mensajes de texto a la parte inferior de un archivo, y el usuario tena que buscar a lo largo del archivo en constante crecimiento para encontrar un mensaje particular. Este sistema slo era capaz de enviar mensajes a usuarios en el mismo sistema. La primera transferencia verdadera de correo electrnico en la red se llev a cabo en 1971 cuando un ingeniero de computacin llamado RayTomlinson envi un mensaje de prueba entre dos mquinas a travs de ARPANET el precursor de Internet. La comunicacin a travs de correo electrnico rpidamente se volvi muy popular, pasando a formar el 75 por ciento del trfico de ARPANET en menos de dos aos. Hoy da, los sistemas de correo electrnico basados en protocolos de red estandarizados han evolucionado para convertirse en uno de los servicios ms usados de la Internet. Red Hat Enterprise Linux ofrece muchas aplicaciones avanzadas para servir y acceder al correo electrnico. Hoy da, el correo electrnico es entregado usando una arquitectura cliente/servidor. Un mensaje de correo electrnico es creado usando un programa de correo cliente. Este programa luego enva el mensaje a un servidor. El servidor luego lo redirige al servidor de correo del recipiente y all se le suministra al cliente de correo del recipiente. Para permitir todo este proceso, existe una variedad de protocolos de red estndar que permiten que diferentes mquinas, a menudo ejecutando sistemas operativos diferentes y usando diferentes programas de correo, enven y reciban correo electrnico o email. La entrega de correo desde una aplicacin cliente a un servidor, y desde un servidor origen al servidor destino es manejada por el Protocolo simple de transferencia de correo (Simple Mail Transfer Protocol o SMTP). Hay dos protocolos principales usados por las aplicaciones de correo cliente para recuperar correo desde los servidores de correo: el Post Office Protocol (POP) y el Internet Message Access Protocol (IMAP). A diferencia de SMTP, estos protocolos requieren autenticacin de los clientes usando un nombre de usuario y una contrasea. Por defecto, las contraseas para ambos protocolos son pasadas a travs de la red sin encriptar.

POP3 INTRODUCCIN

Con frecuencia, en algunos nodos pequeos de Internet no resulta prcticomantener un sistema de transporte de mensajes (MTS, messagetransportsystem). Por ejemplo, una estacin de trabajo puede no tener suficientesrecursos (ciclos, espacio en el disco) para permitir un servidor SMTP, y mantener de forma residente y en continua ejecucin el sistemade transporte de correo asociado. De forma similar puede resultar costoso(o imposible) mantener un equipo personal interconectado a una red detipo IP durante periodos largos de tiempo (el nodo carece del recursoconocido como "conectividad"). Sin embargo, a veces resulta muy til poder gestionar correo en esosnodos ms pequeos, y a menudo tienen soporte para un agente de usuario(useragent UA) para ayudar en las tareas de gestin del correo. Parasolucionar este problema, un nodo que pueda gestionar un MTS ofrece unservicio de buzn a esos nodos menos dotados. ElPost Office Protocol(N. del T. Protocolo de Oficina de Correos) - Versin3 (POP3) se utiliza para permitir a una estacin de trabajo transferirel correo que guarda el servidor. La orientacin del protocolo POP3 no es proporcionar amplias operacionesde correo en el servidor; normalmente el correo se transfiere ydespus se borra. OPERACIN BSICA Inicialmente, el equipo servidor inicia el servicio POP3 escuchando el puerto TCP 110. Cuando un equipo cliente quiere hacer uso del servicio, establece una conexin TCP con el equipo servidor. Cuando la conexin se ha establecido, el servidor POP3 enva un saludo. El cliente y el servidor POP3 a partir de entonces intercambian rdenes y respuestas hasta que se cierre o interrumpa la conexin. Las rdenes en el protocolo POP3 consisten en una serie de palabras claves sin diferenciar maysculas de minsculas, posiblemente seguidas de uno o ms argumentos. Todos las rdenes terminan con un par CRLF (CarriageReturnLine Feed, Retorno de Carro Nueva Lnea). Las rdenes y sus argumentos estn compuestos de caracteres ASCII imprimibles, separados de sus argumentos por un slo carcter ESPACIO. Las rdenes tiene tres o cuatro caracteres de longitud. Cada argumento puede tener hasta 40 caracteres. Las respuestas en el POP3 estn formada por un indicador de estado y una palabra clave, posiblemente seguida de informacin adicional. Todas las respuestas estn terminadas por un par CRLF. Las respuestas pueden tener hasta 512 caracteres de longitud, incluyendo el CRLF del final. Actualmente hay dos indicadores de estado: el positivo ("+OK") y el negativo ("-ERR"). Los servidores deben enviar "+OK" y el "-ERR" en maysculas. Las respuestas a ciertas rdenes son multilnea. En esos casos, que se indicarn claramente ms adelante, tras enviar la primera lnea de la respuestas y un CRLF, pueden enviarse ms lneas, cada una de ellas tambin terminadas por el par CRLF. Cuando se han enviado todas las lneas de la respuesta, se enva una lnea final que consiste en un octeto terminal(cdigo decimal 046, ".") y un par CRLF. Si cualquier lnea de la respuesta multilnea comienza con el octeto terminal, se anteponeel octeto terminal a esa lnea en la respuesta. De este modo, una respuestamultilnea termina con los cinco octetos "CRLF.CRLF".
3

Cuando examina una respuesta multilnea, el cliente comprueba si la lnea comienza con el octeto terminal. Si es as y si le siguen otros octetos que no sean CRLF, el primer octeto de la lnea (el octeto terminador) se elimina. Tras esto, y si al carcter terminador le sigue un CRLF, entonces la respuesta del servidor POP termina, y la lnea que contiene ".CRLF" no se considerar parte de la respuesta multilnea. Una sesin POP3 pasa por varios estados durante su periodo de vida. Una vez abierta la conexin TCP y tras enviar el servidor POP3 el saludo, la sesin entra en la fase de AUTORIZACIN. En esta fase, el cliente debe identificarse ante el servidor POP3. Una vez el cliente lo realiza con xito,el servidor adquiere los recursos asociados con el buzn del cliente, y la sesin entra en la fase de TRANSACCIN. En esta fase, el cliente solicita la actuacin al servidor POP3. Tras el envo por el cliente de la orden QUIT, la sesin entra en la fase de AUTORIZACIN. En esta fase,el servidor POP3 libera cualquier recurso adquirido durante la fase de TRANSACCIN, y dice adis. En ese momento se cierra la conexin TCP. Un servidor debe responder a una orden no reconocida, no implementada o no vlida sintcticamente, con un indicador de estado negativo. El servidor debe responder a una orden enviada en una fase incorrecta con un indicador de estado negativo. No existe un mtodo general para que un cliente pueda distinguir entre un servidor que no implementa una orden opcional y otro que no puede o no quiere procesarla. Un servidor POP3 PUEDE tener un contador de inactividad para cerrar la conexin. Ese contador DEBE de ser de al menos 10 minutos de duracin. La recepcin de cualquier orden durante el intervalo debera bastar para reiniciar el contador. Cuando el contador se agota, la sesin NO entra en fase de ACTUALIZACIN: el servidor debera cerrar la conexin TCP sin eliminar ningn mensaje ni enviar ninguna respuesta al cliente. FASE DE AUTORIZACIN Una vez que el cliente POP3 abre la conexin TCP, el servidor POP3 lanza una lnea de saludo. Esta puede ser cualquier respuesta positiva. Un ejemplo podra ser: S: +OK servidor POP3 preparado La sesin POP3 est ahora en la fase de AUTORIZACIN. El cliente debe identificarse y autentificarse al servidor POP3.Una vez que el servidor POP3 ha determinado a travs del uso de las rdenes de autenticacin que puede autorizar el acceso del cliente al buzn adecuado, el servidor POP3 abre un acceso exclusivo al buzn, siendo esto necesario para evitar que los mensajes puedan ser modificados o eliminados antes de que la sesin entre en la fase de actualizacin. Si se adquiere correctamente el acceso exclusivo, el servidor POP3 responde con una indicacin de estado positiva. La sesin POP3 entra ahora en la fase de TRANSACCIN, en la cual no hay ningn mensaje marcado para su borrado. Si el buzn no puede abrirse por alguna razn (por ejemplo, la exclusividad no puede adquirirse, al cliente se le ha denegado el acceso, o el buzn no puede ser examinado), el servidor POP3 responde con un indicador de estado

negativo. (Si la exclusividad fue adquirida pero el servidor POP3 responde con un indicador de estado negativo, el servidor POP3 debe dejar su exclusividad antes de rechazar la orden.) Tras devolver un indicador de estado negativo, el servidor puede cerrar la conexin. Si el servidor no cierra la conexin, el clientepuede elegir tanto enviar una nueva orden de autenticacin y empezar de nuevo, como enviar la orden QUIT. Despus de que el servidor POP3 halla abierto el buzn, asigna un nmero a cada mensaje, y mira el tamao de cada uno en octetos. Al primer mensaje en el buzn se le asigna el nmero "1", al segundo se le asigna el "2", y as seguido, de modo que el ensimo mensaje del buzn tiene asignado el nmero de mensaje "N". En las rdenes y respuestas POP3, los nmeros y tamaos de todos los mensajes se expresan en base 10 (decimal). Este es un resumen de la orden QUIT cuando se utiliza en la fase de AUTORIZACIN: Ejemplos: C: QUIT S: +OK dewey POP3 server signing off FASE DE TRANSACCIN Una vez que el cliente se ha identificado a si mismo con xito ante el servidor POP3, y ste ha puesto el cerrojo y abierto el buzn adecuado, la sesin POP3 se encuentra en la fase de TRANSACCIN. El cliente ahora puede enviar repetidamente cualquiera de las rdenes POP3 que detallaremos a continuacin. Tras recibir cada orden, el servidor POP3 enva una respuesta. Eventualmente, el cliente puede enviar la orden QUITy la sesin POP3 entrar en la fase de ACTUALIZACIN. ORDENES: *STAT El servidor POP3 enviar un respuesta positiva con una lnea que contendr informacin del buzn. A esta lnea se le denomina el "anlisis de buzn" ("droplisting") para ese buzn. Para simplificar el anlisis, todos los servidores POP3 deben usar un formato determinado para los listados de mensajes. La respuesta positiva consiste en un "+OK" seguido de un espacio, el nmero de mensajes en el buzn, otro espacio, y el tamao del buzn en octetos. Ejemplos: C: STAT S: +OK 2 320 *LIST Si se enva el argumento, el servidor POP3 devuelve una respuesta positiva con una lnea conteniendo informacin para ese mensaje. Esta lnea se denomina de anlisis de mensaje (scanlisting) para ese mensaje. Si no se da ningn argumento y el servidor POP3 devuelve una respuesta positiva, entonces sta es multilnea. Tras la respuesta +OK inicial, por cada mensaje en el buzn el servidor POP3 responde con una lnea que contiene informacin de ese mensaje. Esta lnea tambin
5

se denomina de anlisis de mensaje (scanlisting) para ese mensaje. Si no hay mensaje en el buzn, el servidor POP3 responde sin anlisis de mensajes: enva una respuesta positiva seguida de una lnea que contiene el octeto terminal y un par CRLF. Para simplificar el anlisis, todos los servidores POP3 tienen que usar un formato determinado de listados. Un listado consiste en el nmero del mensaje, seguido de un espacio, y el tamao mximo del mensaje en octetos. Respuestasposibles: +OK scan listing follows -ERR no such message Ejemplos: C: LIST S: +OK 2 messages (320 octets) S: 1 120 S: 2 200 S: . ... C: LIST 2 S: +OK 2 200 ... C: LIST 3 S: -ERR no such message, only 2 messages in mail *RETR Si el servidor POP3 enva una respuesta positiva, entonces sta es multilnea. Tras el +OK inicial el servidor POP3 enva mensaje correspondiente al nmero de mensaje dado, teniendo cuidado de anteponer el carcter terminal (como en todas las respuestas multilnea). Respuestasposibles: +OK message follows -ERR no such message Ejemplos: C: RETR 1 S: +OK 120 octets S: <Aqu el servidor POP3 enva el mensaje entero> S: *DELE El servidor POP3 marca el mensaje como borrado. Cualquier referencia futura al nmero asociado al mensaje en el servidor POP3 genera un error. El servidor POP3 realmente no borra ningn mensaje hasta que la sesin POP3 entra en fase de actualizacin.
6

Respuestasposibles: +OK message deleted -ERR no such message Ejemplos: C: DELE 1 S: +OK message 1 deleted ... C: DELE 2 S: -ERR message 2 already deleted

*NOOP El servidor POP3 no hace nada, simplemente devuelve una respuesta positiva Respuestas posibles: +OK Ejemplos: C: NOOP S: +OK RSET Si el servidor POP3 ha marcado algn mensaje como borrado, se elimina esa marca. El servidor POP3 devuelve una respuesta positiva. Respuestas posibles: +OK Ejemplos: C: RSET S: +OK mailbox has 2 messages (320 octets) LA FASE DE ACTUALIZACIN Cuando el cliente enva la orden QUIT en la fase de TRANSACCIN, la sesin POP3 entra en la fase de ACTUALIZACIN. (Obsrvese que si el cliente enva una orden QUIT durante la fase de AUTORIZACIN, la sesin POP3 termina pero NO entra en la fase de ACTUALIZACIN.)
7

Si la sesin termina por cualquier motivo que no sea una orden QUIT enviada por el cliente, la sesin POP3 NO entra en la fase de actualizacin y no debe eliminar ningn mensaje del buzn. *QUIT El servidor POP3 elimina cualquier mensaje marcado como borradodel buzn y responde segn el resultado de esta operacin. Si hay algn error, como escasez de recursos, encontrado cuando se estaba eliminando el mensaje, puede darse el caso de que el buzn tenga algunos o ninguno de los mensajes marcados para borrado. En ningn caso el servidor debe eliminar mensajes que no estn marcados para borrado. Independientemente de que el borrado se haya llevado a cabo con xito o no, el servidor libera el cerrojo de acceso exclusivo sobre el buzn y cierra la conexin TCP Respuestasposibles: +OK -ERR some deleted messages not removed Ejemplos: C: QUIT S: +OK dewey POP3 server signing off (mailbox empty) ... C: QUIT ORDENES POP3 OPCIONALES Las rdenes POP3 comentados con anterioridad deben ser compatibles con todas las implementaciones mnimas de servidor POP3. Las rdenes POP3 opcionales descritos a continuacin permiten al cliente POP3 una mayor libertad en el manejo de mensajes, mientras se preserva una implementacin mnima del servidor POP3. *TOP Si el servidor POP3 enva una respuesta positiva, entonces sta es multilnea. Tras el +OK inicial, el servidor POP3 enva lascabeceras del mensaje, y el nmero de lneas del cuerpo del mensaje, cuidando especialmente de anteponer el carcter de terminacin (como en todas las respuestas multilnea). Obsrvese que si el nmero de lneas requeridas por el cliente POP3 es mayor que el nmero de lneas del cuerpo, el servidor POP3 enviar el mensaje entero. Respuestasposibles: +OK top of message follows -ERR no such message Ejemplos: C: TOP 1 10 S: +OK S: <el servidor POP3 enva las cabeceras de mensaje, una lnea en blanco y las primeras 10 lneas del mensaje>
8

S: . ... C: TOP 100 3 S: -ERR no such message *UIDL Si el argumento fue transmitido, el servidor POP3 devuelve una respuesta positiva con una Lnea con informacin para ese mensaje Esta lnea se denomina un listado de ID exclusiva (unique-id listi1ng)para ese mensaje. Si no se dio ningn argumento y el servidor POP3 devuelve una respuesta positiva, entonces esa respuesta es multilnea. Tras el +OK inicial, por cada mensaje en el buzn el servidor POP3 responder con una lnea que contendr informacin para ese mensaje. Esta lnea se denomina listado de ID exclusiva para ese mensaje. Para simplificar el anlisis, todos los servidores POP3 deben usar un formato determinado para los listados de ID exclusiva. Un listado de ID exclusiva consiste en el nmero de mensaje, seguido de un solo espacio, y el ID exclusiva del mensaje. Ninguna informacin sigue al ID exclusiva en el listado de ID exclusiva. La ID exclusiva del mensaje es una cadena determinada arbitrariamente por el servidor que consiste en uno de los 70 caracteres en el rango de 0x21 a 0x7E, que unvocamente identifica un mensaje dentro del buzn y que persiste entre sesiones. Esta persistencia se requiere incluso si la sesin no entra en la fase de ACTUALIZACIN. EL servidor nunca debera volver a utilizar una ID exclusiva para un mismo buzn, mientras la entidad que utiliza actualmente la ID exclusiva siga existiendo. Obsrvese que los mensajes marcados como borrados no se enumeran. Aunque es generalmente preferible que las implementaciones de los servidores asignen ID exclusivas de forma arbitraria al buzn, esta especificacin permite calcular las ID exclusivas a partir de una funcin hash del mensaje. Los clientes deberan ser capaces de manejar una situacin en la que dos copias idnticas de un mensaje en un buzn Comparten la misma ID exclusiva. Respuestasposibles: +OK unique-id listing follows -ERR no such message Ejemplos: C: UIDL S: +OK S: 1 whqtswO00WBw418f9t5JxYwZ S: 2 QhdPYR:00WBw1Ph7x7 S: . ... C: UIDL 2 S: +OK 2 QhdPYR:00WBw1Ph7x7 ... C: UIDL 3 S: -ERR no such message, only 2 messages in mailbox
9

*USER Una cadena que identifica un buzn (requerido) que SLO tiene significado para el servidor. Solo puede darse en la fase de AUTORIZACIN despus de que el servidor POP3 enve el saludo o tras unos rdenes USER o PASS fallidos. Para autentificar utilizando la combinacin de rdenes USER y PASS, el cliente primero debe enviar la orden USER. Si el servidor POP3 responde con un indicador de estado positivo ("+OK"), entonces el cliente puede enviar tanto la orden PASSpara completar la autenticacin, como la orden QUIT para terminar la sesin POP3. Si el servidor POP3 responde con un indicador de estado negativo ("-ERR") la orden USER, entonces el cliente puede tanto enviar una nueva orden de autenticacin como enviar la orden QUIT. El servidor puede devolver una respuesta positiva incluso si no existe tal buzn. El servidor puede devolver una respuestanegativa si el buzn existe, pero no permite autenticacin por texto plano. Respuestasposibles: +OK name is a valid mailbox -ERR never heard of mailbox name Ejemplos: C: USER frated S: -ERR sorry, no mailbox for frated here ... C: USER mrose S: +OK mrose is a real hoopyfrood *PASS Una clave especfica del servidor y el buzn (requerida). Slo puede darse en la fase de AUTORIZACIN, despus de una orden USER con xito. Cuando el cliente enva la orden PASS, el servidor POP3 utiliza el par de argumentos de las rdenes USER y PASS para determinar si al cliente debera proporcionrsele el acceso al buzn adecuado. POP3 puede tratar los espacios en el argumento como parte de la contrasea en lugar de como separador de argumentos. Respuestasposibles: +OK buzn locked and ready -ERR invalid password -ERR unable to lock mailbox Ejemplos: C: USER mrose S: +OK mrose is a real hoopyfrood C: PASS secret S: -ERR mailbox already locked ...
10

C: USER mrose S: +OK mrose is a real hoopyfrood C: PASS secret S: +OK mrose's mailbox has 2 messages (320 octets) *APOP Una cadena que identifica un buzn y una cadena resumen MD5(ambas requeridas).Slo puede darse en la fase de AUTORIZACIN tras el saludo delservidor POP3 o tras un USER o PASS sin xito. Normalmente, cada sesin POP3 empieza con un intercambio USER/PASS. Esto tiene como resultado que una clave especfica servidor/usuario se enve en claro por la red. Para usos intermitentes del POP3, esto puede que no represente un riesgo considerable. Sin embargo, muchas implementaciones de clientes POP3 se conectan al servidor POP3 de forma regular (para comprobar si hay nuevo correo). En este caso el intervalo o inicializacin de sesin puede ser del orden de cinco minutos. Por lo tanto el riesgo de que la clave sea capturada aumenta considerablemente. Se requiere por tanto un mtodo alternativo de autenticacin que proporcione tanto autenticacin del origen como proteccin contra intrusiones, lo cual implica que la clave no debe enviarse en claro por la red. La orden APOP proporciona esta funcionalidad. Un servidor POP3 que implemente la orden APOP deber incluir una marca de tiempo en su mensaje de saludo. La sintaxis de la marca de tiempo se corresponde a la del 'msg-id' del [RFC822], y DEBE ser diferente cada vez que el servidor POP3 enve el mensaje de saludo. Por ejemplo, en una implementacin UNIX en la que se utilicen procesos UNIX separados para cada instancia del servidor POP3, la sintaxis de la marca de tiempo podra ser:<ID-proceso.reloj@nombrehuesped> Donde "ID proceso" es el valor decimal del PID del proceso, "reloj" es el valor decimal del reloj del sistema, y "nombrehuesped" es el nombre de dominio totalmente cualificado que corresponde al equipo husped donde se ejecuta el servidor POP3. El cliente POP3 toma nota de esta marca de tiempo, y entonces enva la orden APOP. El parmetro "nombre" tiene la misma semntica que el parmetro 'nombre' de la orden USER. El parmetro 'resumen' se calcula aplicando el algoritmo MD5 [RFC1321] a una cadena que consiste en la marca de tiempo (incluyendo los smbolos de mayor y menor), seguidos de un secreto compartido. Este secreto compartidoes una cadena conocida slo por el cliente y el servidor POP3. Debe tenerse mucho cuidado en prevenir un acceso no autorizado a ese secreto, dado que el conocimiento del mismo permitir a cualquier entidad enmascararse como el usuario nombrado. El propio parmetro 'resumen' es un valor de 16 octetos enviado en formato hexadecimal, utilizando caracteres ASCII con letras minsculas. Cuando el servidor POP3 recibe la orden APOP, verifica elresumen proporcionado. Si el resumen es correcto, el servidor POP3 enva una respuesta positiva, y la sesin POP3 entra en la fase de transaccin. Si no, se enva una respuesta negativa y la sesin POP3 permanece en la fase de AUTORIZACIN. Obsrvese que segn aumenta la longitud del secreto compartido aumenta la dificultad para derivarlo. Por ello, los secretos compartidos deberan ser cadenas largas (considerablemente ms largas que el ejemplo de 8 caracteres mostrado ms abajo).
11

Respuestasposibles: +OK mailbox locked and ready -ERR permission denied Ejemplos: S: +OK POP3 server ready C: APOP mrose c4c9334bac560ecc979e58001b3e22fb S: +OK maildrop has 1 message (369 octets) Sesin de ejemplo POP3 S: <espera de conexin POP3 por el puerto 110> C: <conexinabierta> S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us> C: APOP mrose c4c9334bac560ecc979e58001b3e22fb S: +OK mrose's mailbox has 2 messages (320 octets) C: STAT S: +OK 2 320 C: LIST S: +OK 2 messages (320 octets) S: 1 120 S: 2 200 S: . C: RETR 1 S: +OK 120 octets S: <el servidor POP3 enva el mensaje 1> S: . C: DELE 1 S: +OK message 1 deleted C: RETR 2 S: +OK 200 octets S: <el servidor POP3 enva el mensaje 2> S: . C: DELE 2 S: +OK message 2 deleted C: QUIT S: +OK dewey POP3 server signing off (mailbox empty) C: <cierre de la conexin> S: <espera de la siguiente conexin>

12

IMAP La principal diferencia que encontramos respecto a POP es que tanto los mensajes como las carpetas se guardan en el Host. Esto, que puede parecer un inconveniente, es muy til para conectarse desde ordenadores compartidos, ya que los mensajes no pueden ser ledos por terceras personas, al no quedarse en el PC, adems, si no tenemos la posibidad de conectarnos siempre del mismo ordenador, conseguimos siempre acceder a la totalidad de nuestros mensajes. Hay que tener la precaucin de ir borrandolos de vez en cuando para no sobrepasar el lmite de capacidad de nuestro buzn. En cuanto al soporte de este protocolo, aunque son pocos los programas de correo que lo soportan por ahora, tenemos la suerte que los dos navegadores ms extendidos (Netscape e Internet Explorer -Con Outlook Express u Outlook 98-) s que pueden trabajar con l. El programa de correo que viene por defecto con el Internet Explorer es Outlook 97. Este programa, como he mencionado anteriormente, no dispone de soporte para protocolo IMAP, aunque s el Outlook Express (que se puede descargar desde internet) u Outlook 98. Adems, estoslti- mos soportan el poder configurar varias cuentas de correo, cosa que no puede hacer el Outlook 97. IMAP y POP3 (Post Office Protocol versin 3) son los dos protocolos ms prevalecientes para la obtencin de correo electrnico. Todos los servidores y clientes de email estn virtualmente soportados por ambos, aunque en algunos casos hay algunas interfaces especficas del fabricante tpicamente propietarias. Por ejemplo, mientras que los protocolos propietarios utilizados entre el cliente Microsoft Outlook y su servidor Microsoft Exchange Server o el cliente Lotus Notes de IBM y el servidor Domino, estos productos tambin soportan interoperabilidad con IMAP y POP3 con otros clientes y servidores. La versin actual de IMAP, IMAP versin 4 revisin 1 (IMAP4ver1), est definida por el RFC 3501. IMAP fue diseado como una moderna alternativa a POP por Mark Crispin en el ao de 1986 . Fundamentalmente, los dos protocolos le permiten a los clientes de correo acceder a los mensajes almacenados en un servidor de correo. Algunas de las caractersticas importantes que tiene IMAP y que carece POP3 incluyen: Soporte para los modos de operacin connected y disconnected Al utilizar POP3, los clientes se conectan al servidor de correo brevemente, solamente lo que les tome descargar los nuevos mensajes. Al utilizar IMAP4, los clientes permanecen conectados el tiempo que su interfaz permanezca activa y descargan los mensajes bajo demanda. El patrn de IMAP4 puede dar tiempos de respuesta ms rpidos para usuarios que tienen una gran cantidad de mensajes. Soporte para la conexin de mltiples clientes simultneos a un mismo destinatario El protocolo POP3 asume que el cliente conectado es el nico dueo de una caja de correo. En contraste, el protocolo IMAP4 permite accesos simultneos a mltiples clientes y

13

proporciona ciertos mecanismos a los clientes para que se detecten los cambios hechos a un mailbox por otro cliente concurrentemente conectado. Soporte para acceso a partes MIME de los mensajes y obtencin parcial Casi todo el email del internet es transmitido en formato MIME. El protocolo IMAP4 le permite a los clientes obtener separadamente cualquier parte MIME individual as como, obtener porciones de las partes individuales los mensajes completos. Soporte para que la informacin de estado del mensaje se mantenga en el servidor A travs de la utilizacin de banderas definidas en el protocolo IMAP4 de los clientes, se puede vigilar el estado del mensaje, por ejemplo, si el mensaje ha sido o no ledo, respondido o eliminado. Estas banderas se almacenan en el servidor, de manera que varios clientes conectados al mismo correo en diferente tiempo pueden detectar los cambios hechos por otros clientes. Soporte para accesar mltiples buzones de correo en el servidor Los clientes de IMAP4 pueden crear, renombrar o eliminar correo (por lo general presentado como carpetas al usuario) del servidor, y mover mensajes entre cuentas de correo. El soporte para mltiples buzones de correo tambin le permite al servidor proporcionar acceso a los folders pblicos y compartidos. Soporte para bsquedas de parte del servidor IMAP4 proporciona un mecanismo para los clientes le pidan al servidor que busque mensajes de acuerdo a una cierta variedad de criterios. Este mecanismo evita que los clientes descarguen todos los mensajes de su buzn de correo con el fin de agilizar las bsquedas. Soporte para un mecanismo de extensin definido Como reflejo de la experiencia en versiones anteriores de los protocolos de internet, IMAP define un mecanismo explcito mediante el cual puede ser extendido. Se han propuesto muchas extensiones de IMAP4 y son de uso comn. Un ejemplo de extensin es el IMAP IDLE, que sirve para que el servidor avise al cliente cuando ha llegado un nuevo mensaje de correo y y stos se sincronicen. Sin esta extensin, para realizar la misma tarea el cliente debera contactar peridicamente al servidor para ver si hay mensajes nuevos. Ya sea que se utilice POP3 o IMAP4 para obtener los mensajes, los clientes utilizan SMTP para enviar mensajes. Los clientes de correo electrnico son comnmente denominados clientes POP IMAP, pero en ambos casos se utiliza SMTP. IMAP es utilizado frecuentemente en redes grandes; por ejemplo los sistemas de correo de un campus. IMAP le permite a los usuarios acceder a los nuevos mensajes instantneamente en sus computadoras, ya que el correo est almacenado en la red. Con
14

POP3 los usuarios tendran que descargar el email a sus computadoras o acceder va web. Ambos mtodos toman ms tiempo de lo que le tomara a IMAP, y se tiene que descargar el email nuevo o refrescar la pgina para ver los nuevos mensajes. De manera contraria a otros protocolos de Internet, IMAP4 soporta mecanismos nativos de cifrado. La transmisin de contraseas en texto plano tambin es soportada. Los documentos RFC (RequestforComment, Peticin de comentarios) del protocolo IMAP contienen detalles y especificaciones sobre cmo debe funcionar el protocolo. El documento RFC-1730 define en primer lugar el modo en el que el protocolo IMAP debe utilizar la versin 4, pero el RFC-3501 (que sustituye al RCF-2060) contiene las cuestiones de implantacin de IMAP actuales que utilizan muchos servidores IMAP y que se denomina versin IMAP4rev1. IMAP4rev1 soporta un servidor nico. En el RFC-2244 se discute un mecanismo (ACAP) para acceder a la informacin de configuracin para soportar mltiples servidores IMAP4rev1. Nivel de Enlace El protocolo IMAP4rev1 asume un flujo de datos fiable tal como el que proporciona TCP. Cuando se usa TCP, un servidor IMAP4rev1 escucha en el puerto 143. rdenes y Respuestas Una conexin IMAP4rev1 consiste en el establecimiento de una conexin de red cliente/servidor, la bienvenida inicial desde el servidor e interacciones cliente/servidor. Estas interacciones cliente/servidor consisten en una orden del cliente, datos del servidor y composicin del resultado de la respuesta. Todas las interacciones transmitidas por el cliente y el servidor estn en la forma de lneas, esto es, cadenas que terminan con CRLF. El receptor del protocolo de un cliente o servidor IMAP4rev1 puede leer una lnea o una secuencia de octetos de una longitud conocida seguido de una lnea.

PROTOCOLOS DEL CLIENTE EMISOR Y SERVIDOR RECEPTOR La orden del cliente comienza una operacin. Cada orden del cliente lleva como prefijo un identificador (tpicamente una cadena alfanumrica corta, por ejemplo A0001, A0002, etc.) denominada "etiqueta" (tag). El cliente genera una etiqueta diferente para cada orden. Los clientes DEBEN seguir la sintaxis remarcada en esta especificacin estrictamente. Es un error de sintaxis enviar una orden faltando argumentos o con espacios de ms o de menos. Hay dos casos en los cuales una lnea del cliente no representa una orden completa. En un caso, un argumento de la orden se entrecomilla con una cuenta de un octeto; en el otro caso,
15

los argumentos de la orden requieren realimentacin del servidor. En cualqueir caso, el servidor enva una respuesta de peticin de continuacin de la orden si est preparado para los octetos (en caso apropiado) y el resto de la orden. Esta respuesta lleva como prefijo el token "+". NOTA Si en su lugar, el servidor detecta un error en la orden, enva una respuesta de MAL completado(BAD) con una etiqueta que coincide con la de la orden para rechazar la orden y prevenir al cliente para que no enve nada ms de la orden. Es tambin posible que el servidor enve una respuesta de completado para alguna otra orden (si hay varias rdenes en progreso), o datos sin etiqueta. En cualquier caso la peticin de continuacin de la orden permanece pendiente; el cliente ejecuta la accin apropiada para la respuesta y lee otra respuesta del servidor. En todos los casos el cliente DEBE enviar una orden completa antes de iniciar una nueva orden. El protocolo del receptor de un servidor IMAP4rev1 lee una lnea de rdenes del cliente, la interpreta incluyendo sus argumentos y transmite los datos del servidor y responde con la orden de completado de rdenes del servidor.

16

Listado de rdenes IMAP es un protocolo con estados. En la figura siguiente se muestran los estados posibles secuencializados en el orden en que se deben ir ejecutando las acciones.

(1) (2) (3) (4) (5) (6) (7)

conexin sin pre-autentificacin (OK greeting) conexin pre-autentificada (PREAUTH greeting) conexin rechazada (BYE greeting) orden LOGIN o AUTHENTICATE satisfactoria orden SELECT o EXAMINE satisfactoria orden CLOSE, o un SELECT o EXAMINE fallido orden LOGOUT, apagado del servidor o cierre de conexin

17

Se muestran a continuacin las rdenes que se pueden enviar, clasificadas por cliente/servidor y separadas por estados en los cuales se puede utilizar la orden.

rdenes del Cliente en cualquier estado CAPABILITY Solicita una lista de las capacidades soportadas por el servidor. Se define en el RFC 3501 NOOP Siempre se ejecuta positivamente, se utiliza para mantener la conexin y permitir que el servidor pueda informar de la llegada de nuevos mensajes. Esto es as puesto que en cualquier respuesta el servidor puede notificar cambios en los buzones. Se define en el RFC 3501 LOGOUT Informa al servidor que el cliente ha terminado con la conexin. El servidor debe responder con un BYE sin etiquetar antes de enviar el OK con su etiqueta correspondiente y luego cerrar la conexin. Se define en elRFC 3501 rdenes del Cliente en el estado NO AUTENTIFICADO En el estado no autentificado las rdenes LOGIN o AUTHENTICATE establecen la autentificacin y llevan al estado autentificado. STARTTLS Introduce la negociacin [TLS] inmediatamente despus del CRLF final de la lnea de respuesta OK del servidor. Cuando se enva esta orden el cliente DEBE esperar la respuesta del servidor antes de intentar enviar ninguna otra orden. Se define en el RFC 3501. AUTHENTICATE Indica un mecanismo de autentificacin [SASL] al servidor. Si el servidor soporta el mtodo de autentificacin solicitado lo utiliza para validar al cliente, en caso contrario el servidor enva un mensaje de rechazo de autentificacin. Se define en el RFC 3501 LOGIN Identifica al cliente frente al servidor utilizando contrasea en texto plano. Se define en el RFC 3501 rdenes del Cliente en el estado AUTENTIFICADO SELECT Selecciona un buzn de tal forma que se puede acceder a los mensajes que contiene. Solo se puede acceder a un buzn en una conexin, para acceder a varios buzones se tienen que
18

establecer sesiones separadas para cada uno de ellos. Se define en el RFC 3501 EXAMINE Es idntico a SELECT y se obtienen las mismas respuestas, pero el buzn se marca como de solo lectura de tal forma que no se permiten cambios en el estado. Se define en el RFC 3501 CREATE Crea un buzn con el nombre que se le pasa como parmetro. Se define en el RFC 3501 DELETE Elimina permanentemente un buzn. No permite borrar INBOX, puesto que eso generara una respuesta de error. Se define en el RFC 3501 RENAME Cambia el nombre de un buzn. Se define en el RFC 3501 SUBSCRIBE Aade el buzn especificado al conjunto de buzones "activos" o "suscritos". La orden LSUB muestra los buzones suscritos. Se define en el RFC 3501 UNSUBSCRIBE Elimina el buzn especificado de la lista de buzones "activos" o "suscritos". Se define en el RFC 3501 LIST Devuelve el conjunto de los nombres de buzones disponibles para el cliente. Se devuelven cero o ms respuestas sin etiquetar de la LISTA, conteniendo las cualidades, el delimitador de la jerarqua, y el nombre conocidos. Se define en el RFC 3501 LSUB Devuelve el subconjunto de nombres de buzn marcados por el cliente. Se define en el RFC 3501 STATUS Solicita el estado del buzn indicado. Es una manera alternativa a abrir una segunda conexin para solo dar la orden EXAMINE. Se define en el RFC 3501 APPEND Aade un nuevo mensaje al final del buzn. Se define en los RFC 3501 y RFC 3502 rdenes del Cliente en el estado Seleccionado
19

En este estado se permiten rdenes que manipulen los mensajes del buzn. CHECK Pone un punto de comprobacin en el buzn, si lo soporta el servidor; en caso contrario es equivalente a NOOP. Se define en el RFC 3501 CLOSE Elimina del buzn seleccionado, de forma permanente, los mensajes marcados como para borrar y retorna al estado autentificado. Se define en el RFC 3501 UNSELECT Permite cerrar un buzn sin eliminar los mensajes marcados como borrables. Se define en el RFC 3691 EXPUNGE Borra de forma permanente los mensajes marcados como borrables. Se define en el RFC 3501 SEARCH Explora el buzn en busca de mensajes que coincidan con el criterio indicado. En el criterio se pueden poner varias claves, en cuyo caso el resultado es la interseccin (y lgica) de todos los mensajes que tienen las claves indicadas. Se define en el RFC 3501 FETCH Recupera los datos asociados a un mensaje del buzn. Se define en el RFC 3501 STORE Modifica los datos asociados a un mensaje del buzn. Se define en el RFC 3501 COPY Copia el mensaje especificado al final del buzn indicado. Se conservan los indicadores y el estado del mensaje. Se define en el RFC 3501 UID Tiene dos formas: en la primera es como un COPY, STORE o FETCH, pero en lugar de utilizar el nmero de orden del mensaje utiliza su identificador nico; en la segunda es como un SEARCH pero usando el identificador nico. Se define en el RFC 3501 rdenes del Cliente Experimentales X<atom> Las rdenes precedidas de X son experimentales y exigen que la respuesta tambin lleve la X como prefijo. Se define en el RFC 3501
20

Respuestas del servidor El cliente est preparado para recibir cualquier respuesta del servidor en cualquier momento. Las respuestas pueden ser etiquetadas o no etiquetadas, en el primer caso el cliente sabe a que orden se est respondiendo; en el segundo la respuesta no se corresponde con una orden explcita del cliente. Extensiones de control de acceso SETACL Modifica la lista de control de acceso en el buzn especificado. Se define en el RFC 2086 DELETEACL Elimina cualquier par <identificador, derechos> de la lista de control de acceso. Se define en el RFC 2086 GETACL Devuelve la lista de control de acceso del buzn especificado. Se define en el RFC 2086 LISTRIGHTS Devuelve los derechos que tiene el usuario indicado en el buzn al que hace referencia. Se define en el RFC 2086 MYRIGHTS Devuelve los derechos que tiene el usuario en el buzn indicado. Se define en el RFC 2086 Extensiones de control de cuota SETQUOTA Pone lmites a la raz indicada para el buzn seleccionado. Se define en el RFC 2087 GETQUOTA Indica el uso de los recursos de la raz especificada. Se define en el RFC 2087 GETQUOTAROOT Usa el nombre del buzn para obtener la lista de las races del buzn. Se define en el RFC 2087

21

SMTP (SIMPLE MAIL TRANSFER PROTOCOL - PROTOCOLO SIMPLE DE TRANSFERENCIA DE CORREO) Introduccin. El Protocolo Simple de Transferencia de Correo (SMTP) ha venidoproporcionando una base estable y efectiva para las transferenciasrealizadas por los agentes de correo. A pesar de que tiene ms de unadcada, SMTP ha demostrado una fortaleza notable. Sin embargo se hahecho patente la necesidad de varias extensiones del protocolo. Enlugar de describir estas extensiones como entes separados ydesordenados, este documento realza de forma clara SMTP como la basesobre la que se pueden construir de forma sencilla y consistentefuturas extensiones. Desarrollo. El protocolo SMTP es elprotocolo estndar que permite la transferencia de correo de un servidor a otro mediante una conexin punto a punto. SMTP est diseado para ofrecer mecanismos eficaces para la transferencia de correo electrnico. Transfiere mensajes de correo entre un cliente de correo y un servidor de correo y entre servidores de correo. No obstante, SMTP no es responsable de administrar buzones o de permitir que un cliente descargue correo entrante. RFC 821 define SMTP, aunque se han agregado caractersticas y mejoras en las siguientes RFC. Aunque SMTP utiliza tecnologa comn, algunos trminos quiz sean desconocidos y se definen a continuacin: Cliente SMTP Programa que inicia una conexin SMTP con un proceso SMTP receptor para enviar correo. El proceso cliente SMTP controla la transferencia de correo entre s mismo y el servidor SMTP, emite rdenes y recibe respuestas del servidor SMTP. Proceso de servidor SMTP Proceso que espera a que un proceso cliente SMTP establezca una conexin. A continuacin recibe rdenes desde el cliente y realiza operaciones en esas rdenes. Canal de transmisin Canal dplex completo abierto entre el cliente SMTP y los procesos de servidor con el fin de realizar transferencias de correo y secuencias de rdenes y respuestas. Ruta reversible Especfica el emisor del correo. La ruta reversible puede ser simplemente el nombre del usuario que enva el correo, o puede incluir una lista de host que retransmiten este correo desde su emisor original. El primer host que aparece es la retransmisin ms reciente, y el ltimo host que aparece es la primera retransmisin. Ruta directa Especifica los destinatarios del correo. De forma opcional, la ruta directa puede especificar una lista de retransmisiones que se utilizarn para enrutar
22

el correo a sus destinatarios, donde el servidor SMTP actuales la primera retransmisin y el ltimo destino es la ltima. Bfer de ruta reversible Se utiliza para mantener la lista de parmetros de ruta reversible para una transaccin, posiblemente incluyendo una lista de host que retransmiten el correo. Esto se puede borrar emitiendo varias rdenes. Bfer de ruta directa Se utiliza para mantener la lista de parmetros de ruta directa de una transaccin, posiblemente incluyendo una lista de host de retransmisin a los que se debe enrutar el correo. Esto se puede borrar emitiendo varias rdenes.

ste es un protocolo que funciona en lnea, encapsulado en una trama TCP/IP. El correo se enva directamente al servidor de correo del destinatario. El protocolo SMTP funciona con comandos de textos enviados al servidor SMTP (al puerto 25 de manera predeterminada). A cada comando enviado por el cliente (validado por la cadena de caracteres ASCII CR/LF, que equivale a presionar la tecla Enter) le sigue una respuesta del servidor SMTP compuesta por un nmero y un mensaje descriptivo. Estructura bsica. La estructura bsica de SMTP se puede describir de la siguiente manera:

Modo de comunicacin SMTP Cuando un servidor de SMTP, requiere transmitir un mensaje a otro servidor SMTP, el emisor (servidor que inicia la sesin SMTP) establece una conexin con el receptor (servidor que recibe peticin de establecer sesin SMTP). Esta conexin es unidireccional, es decir, el emisor puede enviar correo al receptor, pero durante esa conexin, el receptor no puede enviar correo al emisor. Si el receptor tiene que enviar correo al emisor, tiene que esperar a que finalice la conexin establecida y establecer otra en sentido contrario, cambiando los papeles de emisor y receptor. Una vez establecida la conexin, el emisor enva comandos y mensajes. Por lo tanto, el diseo de SMTP se basa en el siguiente modelo de comunicacin: Como respuesta a una solicitud de un usuario de enviar un correo electrnico, el emisor SMTP establece una conexin con el receptor SMTP. El receptor SMTP debe ser el destinatario ltimo del correo o un intermediario. Para ello el emisor
23

genera los comandos SMTP en formato ASCII y los enva al receptor y el receptor genera las respuestas a los comandos enviados por el emisor. Una vez establecido el canal de transmisin, el emisor enva el comando MAIL para indicando que l es el emisor del correo. Si el receptor puede aceptar correo responde con el comando OK. El emisor enva el comando RCPT identificando el destinatario destinatario del correo. Si el receptor puede aceptar correo para ese destino responde con una respuesta OK; si no, responde rechazando el correo para ese destino. Una vez negociado el destino, el emisor comienza a enviar datos (cabeceras y cuerpo), terminando con una una secuencia especial. Si el receptor ha procesado correctamente los datos, responde con el comando OK.

La siguiente figura muestra los componentes que actan en este modelo de uso del protocolo.

La cual es la misma (o similar) a la figura anterior mente mostrada.

Funcionamiento de SMTP. Aunque se han planeado e implantado varias mejoras a SMTP desde el documento RFC 821, sigue siendo un protocolo cliente/servidor bastante sencillo. SMTP, al igual que HTTP y FTP, es un protocolo de la capa de aplicacin que se basa en los protocolos subyacentes para garantizar la entrega de datos. Aunque SMTP puede en teora utilizar otros protocolos, TCP es el ms comn y se puede suponer que es el protocolo subyacente en esta seccin. La comunicacin SMTP la inicia un sistema sistema de correo de usuario, el cliente SMTP. El cliente SMTP establece una sesin de correo con un servidor SMTP abriendo una conexin TCP con el servidor y, a continuacin, emitiendo una orden HELO o EHLO SMTP para iniciar una sesin. Las implementaciones implementaciones extendidas de SMTP, como la que se incluye en IIS 6, se pueden configurar para exigir que el cliente proporcione credenciales creden de autenticacin que verifiquen que el cliente puede utilizar el servidor SMTP. Con frecuencia, stas suelen ser un nombre de usuario u y contrasea que el sistema receptor tor reconoce.

24

Despus de establecer el canal de transmisin, el cliente SMTP emite una orden MAIL que informa al servidor SMTP que desea enviar correo. Si el servidor es capaz de recibir correo en ese momento, responder con una respuesta OK. El cliente SMTP emite una o ms rdenes RCPT que identifican los destinatarios de los mensajes que desea enviar; cada una de las rdenes RCPT representa un nico destinatario de correo. Los destinatarios pueden ser otros usuarios en el mismo sistema de correo o usuarios en dominios externos. Si el servidor es capaz de recibir correo dirigido al destinatario nombrado en la orden RCPT, emite una respuesta OK al cliente y el cliente es libre de emitir otra orden RCPT. Si el servidor SMTP no es capaz de entregar correo al destinatario designado, devuelve una respuesta de error al cliente y el cliente podr avanzar a la siguiente orden. La secuencia de rdenes y repuestas se ordena estrictamente; el cliente debe recibir una nica respuesta antes de que el servidor pueda emitir otra orden, y un servidor no podr emitir ms de una respuesta a cualquier orden. Como no todos los destinatarios pueden utilizar el mismo sistema SMTP, el cliente deber proporcionar el nombre del ltimo host de destino, as como el nombre del buzn de ese sistema de correo. La sintaxis de las direcciones de correo SMTP tiene el formato nombreDeusuario@dominio tan conocido, donde la informacin a la derecha del smbolo @ identifica el host de destino, y el nombre de usuario identifica el nombre del buzn al que se debera entregar el correo. SMTP diferencia entre enviar (sending) y enviar por correo (mailing): si el correo se enva, el cliente designa que el correo se debera entregar inmediatamente a la interfaz de correo del destinatario, siempre que el destinatario este en lnea y mediante un sistema de correo que utiliza esta funcin. No obstante, lo ms frecuente es que el correo se envi por correo, lo que se designa que se debera entregar al buzn del destinatario en un servidor de recepcin. Adems, la funcin de envi no es una implementacin SMTP necesaria y en este captulo se hace referencia a la funcin de correo electrnico a menos que se especifique lo contrario. El correo SMTP tiene una ruta directa y una ruta reversible. La ruta directa es la ruta que el correo debe seguir para llegar al destino final, independientemente que utilice una ruta directa o una serie de retransmisiones. Es importante que no confunda las retransmisiones SMTP con los enrutadores, las retransmisiones SMTP son servidores SMTP, independientemente de los mecanismos de enrutamiento subyacentes. La ruta reversible en un mensaje de correo SMTP es el nombre del emisor, que puede ser tan sencilla como nombreDeusuario@dominio. De lo contrario, podra estar formada por una lista de host de retransmisin entre el emisor original y el SMTP receptor actual. La orden MAIL utiliza la ruta reversible como argumento, y el orden RCTP utiliza la ruta directa. Si varios buzones de distintos destinatarios residen en el mismo host SMTP, SMTP recomienda enviar una nica copia del correo al host SMTP de destino.

25

Cuando el SMTP receptor haya aceptado las direcciones del destinatario y se ofrezca la respuesta adecuada, el cliente es libre de iniciar la emisin de la orden DATA, que informara al servidor de su intencin de empezar a transferir el mensaje de correo. El servidor responde con un cdigo que acepta la intencin del emisor, y el cliente emite a continuacin los datos. Los datos del correo incluyen no solo el cuerpo del correo, sino tambin la informacin de la cabecera de memoria, como las lneas Para:, CC:, CCO: y Asunto. Si la transferencia de los datos de correo es correcta, el servidor responde con un mensaje que indique la recepcin y el procesamiento, y el cliente a continuacin podr emitir rdenes para terminar la conexin de transmisin. Si el emisor especifica informacin de destino no valida en la ruta directa del correo, pero el servidor conoce el destino correcto, el servidor podr responder al emisor con un mensaje que permita al cliente corregir el error. Cuando el cliente desee terminar la sesin SMTP. Lo indicara emitiendo la orden QUIT y el servidor, a continuacin, cerrara la conexin de transmisin. Resumen simple del funcionamiento del protocolo SMTP

Cuando un cliente establece una conexin con el servidor SMTP, espera a que ste enve un mensaje 220 Serviceready o 421 Service non available Se enva un HELO desde el cliente. Con ello el servidor se identifica. Esto puede usarse para comprobar si se conect con el servidor SMTP correcto. El cliente comienza la transaccin del correo con la orden MAIL FROM. Como argumento de esta orden se puede pasar la direccin de correo al que el servidor notificar cualquier fallo en el envo del correo (Por ejemplo, MAIL FROM:<fuente@host0>). Luego si el servidor comprueba que el origen es vlido, el servidor responde 250 OK. Ya le hemos dicho al servidor que queremos mandar un correo, ahora hay que comunicarle a quien. La orden para esto es RCPT TO:<destino@host>. Se pueden mandar tantas rdenes RCPT como destinatarios del correo queramos. Por cada destinatario, el servidor contestar 250 OK o bien 550 No suchuserhere, si no encuentra al destinatario. Una vez enviados todos los RCPT, el cliente enva una orden DATA para indicar que a continuacin se envan los contenidos del mensaje. El servidor responde 354 Start mail input, endwith<CRLF>.<CRLF> Esto indica al cliente como ha de notificar el fin del mensaje. Ahora el cliente enva el cuerpo del mensaje, lnea a lnea. Una vez finalizado, se termina con un <CRLF>.<CRLF> (la ltima lnea ser un punto), a lo que el servidor contestar 250 OK, o un mensaje de error apropiado. Tras el envo, el cliente, si no tiene que enviar ms correos, con la orden QUIT corta la conexin. Tambin puede usar la orden TURN, con lo que el
26

cliente pasa a ser el servidor, y el servidor se convierte en cliente. Finalmente, si tiene ms mensajes que enviar, repite el proceso hasta completarlos. Puede que el servidor SMTP soporte las extensiones definidas en el RFC 1651, en este caso, la orden HELO puede ser sustituida por la orden EHLO, con lo que el servidor contestar con una lista de las extensiones admitidas. Si el servidor no soporta las extensiones, contestar con un mensaje "500 Syntax error, commandunrecognized".

Ejemplo de una comunicacin SMTP En primer lugar se ha de establecer una conexin entre el emisor (cliente) y el receptor (servidor). Esto puede hacerse automticamente con un programa cliente de correo o mediante un cliente telnet. En el siguiente ejemplo se muestra una conexin tpica. Se nombra con la letra C al cliente y con S al servidor.

S: 220 Servidor ESMTP C: HELO miequipo.midominio.com S: 250 Hello, please to meet you C: MAIL FROM: <yo@midominio.com> S: 250 Ok C: RCPT TO: <destinatario@sudominio.com> S: 250 Ok C: DATA S: 354 End data with <CR><LF>.<CR><LF> C: Subject: Campo de asunto C: From: yo@midominio.com C: To: destinatario@sudominio.com C: C: Hola, C: Esto es una prueba. C: Hasta luego. C:
27

C: . S: 250 Ok: queued as 12345 C: quit S: 221 Bye

rdenes SMTP. El cliente SMTP emite rdenes SMTP para el servidor SMTP. La orden SMTP sigue una sintaxis muy sencilla, como se muestra a continuacin (los corchetes indican parmetros de orden opcionales): <0RDEN-SMTPD> [<espacio> ARGUMENTOS-0RDEN>] <crlf> El proceso cliente SMTP emite rdenes para realizar funciones, como abrir un canal de transmisin o iniciar una transferencia de correo. En cambio, el proceso de servidor SMTP intenta ejecutar la orden y, a continuacin, devolver las respuestas. Las rdenes se pueden emitir individualmente o como parte de una serie de rdenes, aunque a cada orden le debe seguir una respuesta desde el servidor SMTP. La siguiente tabla muestra las rdenes SMTP ms habituales, sus descripciones y su sintaxis.

Orden.

Descripcin.

Sintaxis.

ATRN

AUTHENTICATED TURN. Si la sesin entre uncliente y un servidor SMTP se ha autenticado (el usuario ha proporcionado credenciales de identificacin vlidas), esto especifica que el cliente SMTP deber devolver una respuesta OK y asumir la funcin de emisor del correo, o devolver un rechazo (Puerta de enlace errnea, 502) y conservar la funcin de cliente SMTP.

ATRN [<SP> nombre dominio [,nombre dominio]] <CRLF>

28

AUTH

AUTHENTICATE. Se utiliza para iniciar unasesin de transferencia de correo autenticada (donde un usuario podr proporcionar un nombre de usuario y contrasea al servidor SMTP para continuar la sesin).

AUTH LOGIN <CRLF>

DATA

DATA. Las lneas que siguen a esta DATA <CRLF> ordense especifican como datos de correo desde el cliente SMTP al servidor.

EHLO

EXTENDED HELLO. Un cliente que admite ''extensiones SMTP emite esta orden en lugar de la orden HELO cuando inicia una sesin.Si el servidor SMTP que recibe esta orden admite extensiones SMTP, devuelve una respuesta 250 (Accin de solicitud de correo correcta, Finalizado). Si el servidor SMTP que recibe el mensaje no admite extensiones SMTP, devolver un mensaje 500 (Error de sintaxis,Orden no reconocida), que indica al emisor que no puede utilizar rdenes SMTP extendidas.

EHLO <SP><dominio><CRLF>

ETRN

EXTENDED TURN. Una orden SMTPextendida que solicita al servidor que comience el procesamiento de sus colas de
29

ETRN <SP> [<carcter de opcin>] <nombre-nodo><CRLF>

correo para los mensajes que esperan que el servidor entregue al cliente.

Orden.

Descripcin.

Sintaxis.

EXPN

EXPAND. Solicita al servidor SMTP que verifiqueque el argumento pasado es una lista de correo.Si el argumento no representa una lista de correo, la pertenencia de la lista se devolver al cliente SMTP, en forma de nombres completos del usuario y buzones. Esto puede suponer un riesgo de seguridad y muchos servidores SMTP permiten al administrador deshabilitar esta orden.

EXPN <SP><nombre lista de correo><CRLF>

HELO

HELLO. Se utiliza para identificar al clienteSMTP ante el servidor FSMTP y comenzar una nueva sesin.

HELO <SP> nombre de host del cliente SMTP><CRLF>

HELP

HELP. Hace queel servidor SMTP devuelvainformacin de ayuda al emisor; esta orden puede contener argumentos.

HELP [<SP><argumentos>] <CRLF>

MAIL

MA1L. Se utiliza para iniciar una

30

MAIL <SP><ruta-

reversible><CRLF> transaccinde correo entre el cliente y el servidor SMTP.Borra el bfer de ruta reversible, el bfer de ruta directa y el bfer de correo, e inserta el argumento de ruta reversible de su orden en el bfer de ruta reversible.

NOOP

NO OP. No tiene efectos sobre ninguno de losbferes y especifica la accin de que el cliente SMTP devuelva una respuesta OK.

NOOP <CRLF>

QUIT

QUIT. Especifica que el receptor devuelva unarespuesta OK y cierre el canal de transmisin.

QUIT <CRLF>

RCPT

RECIPIENT. Identifica el destinatario delcorreo electrnico que se enva; se pueden especificar varios destinatarios emitiendo repetidamente la orden.

RCPT <SP> TO:<rutareversible><CRLF>

Orden.

Descripcin.

Sintaxis.

RSET

RSET <CRLF> RESET. Especifica que la transaccinde correo actual se anule y se borren todos los bferes. El servidor SMTP responde con un

31

mensaje OK.

SAML

SEND AND MAIL. Inicia una transaccin queespecifica la entrega de los datos de correo a cualquier destinatario con nombre conectado activamente y capaz de recibir correo, as como la entrega a los buzones de los destinatarios especificados. Borra el bfer de ruta reversible, el bfer de ruta directa y el bfer de correo, e inserta la informacin de ruta reversible proporcionada con la orden en el bfer de ruta reversible.

SAML <SP>FROM: <rutareversible><CRLF>

SEND

SEND. Inicia una transaccin que SEND <SP>FROM: <rutareversible><CRLF> especifica quelos datos de correo se entreguen inmediatamente a cualquier destinatario con nombre conectado activamente y capaz de recibir correo. Si un destinatario no est conectado o no es capaz de recibir correo, se devuelve una respuesta 450 (Buzn no disponible). Esto borra el bfer de ruta reversible, el bfer de ruta directa y el bfer de correo, e inserta la informacin de ruta reversible proporcionada con la orden en el bfer de ruta reversible.

32

SIZE

SIZE. Permite que el emisor especifique el tamaodel correo que desee enviar, que el servidor podr rechazar si el tamao es demasiado grande. Slo es vlido en las implementaciones SMTP queadmiten las extensiones de servicio.

SIZE <SP> 1000000 <CRLF> o bien MAIL <SP>FROM: <rutareversible><SP> SIZE = 100000<CRLF>

Orden.

Descripcin.

Sintaxis.

SOML

SEND OR MAIL. Inicia una transaccin queespecfica que los datos del correo se entreguen inmediatamente a cualquier destinatario con nombre conectado activamente y capaz de recibir correo. Si un destinatario no est conectado o es incapaz de recibir correo, se especifica la entrega al buzn del destinatario. Esto borra el bfer de ruta reversible, el bfer de ruta directa y el bfer de correo, e inserta la informacin de ruta reversible proporcionada con la orden en el bfer de ruta reversible.

SOML <SP>FROM: <rutareversible><CRLF>

TURN

TURN. Especifica que el servidor SMTPdebe devolver una respuesta OK y asumir la funcin del emisor (cliente SMTP) del correo, o devolver un rechazo
33

SMTP. TURN <CRLF>

(502) y mantener la funcin del servidor.

VRFY

VERIFY. Solicita que el SMTP receptor verifique el nombre del usuario especificado en el argumento. Si el nombre del usuario es vlido, se devolvern elnombre completo y el buzn del usuario. Esto notendr efecto alguno sobre el bfer de ruta reversible,el bfer de ruta directa o el bfer de correo.

VRFY <SP><nombreDeusuario><CRLF>

Respuestas SMTP. Las respuestas SMTP las emite el servidor SMTP en respuesta a las rdenes enviadas por el cliente=-SMTP. Cada orden debe generar una y slo una respuesta. De forma similar a los cdigos de respuesta emitidos por los servidores FTP, los receptores SMTP emiten un nmero de cdigo de tres dgitos seguido por texto descriptivo. Como en FTP, el primer dgito del cdigo de respuesta indica el tipo general de respuesta, y el segundo dgito ofrece informacin adicional sobre esa categora de respuesta. Las siguientes tablas muestran los valores y significados de los valores del primer y segundo dgito.

Valor del primer digito.

Indicador.

Descripcin.

1yz

Respuesta preliminar positiva

La orden se ha aceptado y espera la confirmacin de esta respuesta y dems instrucciones sobre si el SMTP receptor debera continuar o anular el procesamiento. No obstante, no hay rdenes SMTP que permitan
34

este tipo de respuesta, por lo que no existen rdenes para continuar o anular.

2yz

Respuesta de finalizacin positiva.

La accin solicitada se ha completado y ahora se puede emitir otra orden.

3yz

Respuesta intermedia positiva.

La orden se ha aceptado y se mantiene, pendiente eso s de la recepcin de ms informacin del cliente SMTP.

4yz

Respuesta de finalizacin positiva temporal.

Se ha producido un error transitorio que evita el procesamiento de la orden, y el cliente SMTP debera volver a emitir la orden (o secuencia de rdenes).

5yz

Respuesta de finalizacin negativa permanente.

Se ha producido un error que evita el procesamiento de la orden; la orden (o secuencia de rdenes) no se debera volver a emitir sin modificacin. Esta modificacin puede ser algo tan sencillo como la correccin de un error ortogrfico, aunque este error puede indicar un error de servidor no transitorio.

De los tres dgitos del cdigo numrico, el primero indica la categora de la respuesta, estando definidas las siguientes categoras:

2XX, la operacin solicitada mediante el comando anterior ha sido concluida con xito
35

3XX, la orden ha sido aceptada, pero el servidor est pendiente de que el cliente le enve nuevos datos para terminar la operacin 4XX, para una respuesta de error, pero se espera a que se repita la instruccin 5XX, para indicar una condicin de error permanente, por lo que no debe repetirse la orden

Valor del segundo digito.

Indicador.

Descripcin.

X0z

Sintaxis.

Existe un error de sintaxis, la orden emitida no la implementa el servidor o el servidor no reconoce la categora de la orden.

X1z

Informacin.

Responde a solicitudes de informacin, como "Help".

X2z

Conexiones.

Responde haciendo referencia al canal de transmisin.

x5z

Sistema de correo.

Estado del sistema de correo en relacin a la orden o transferencia solicitadas.

Hay una serie de respuestas estndar que nos encontramos siempre y que hacen referencia a errores. Las descripciones que acompao son genricas, y en cada caso, el servidor nos enva una descripcin ajustada al error. 500 - Comando no reconocido. Error de sintaxis 501 - Error en los argumentos del parmetro. 502 - Comando no implementado 503 - Secuencia de comandos incorrecta 504 - Argumento no implementado 550 - Buzn de correo no disponible
36

551 - Usuario no es local 552 - Accin abortada por exceso de datos 553 - Buzn de correos no accesible 554 - Transaccin fallida

Otras respuestas nos informan de que el comando ha tenido xito. 220 - El servidor SMTP nos ha reconocido y esta preparado 221 - La solicitud de cierre de la comunicacin ha sido aceptada 250 - Solicitud aceptada 251 - Usuario no es local, pero se acepta el envo 354 - Acepta el resto de datos que enviemos como texto libre. Otras respuestas nos informan de otros problemas. 421 - El servicio no est disponible. 450 - Solicitud rechazada. (Por ejemplo: buzn lleno) 451 - Solicitud abortada. (Posible error interno) 452 - Solicitud no aceptada. (Por ejemplo: disco lleno)

37

AMPLIACIN DE CORREO INTERNET MULTIOBJETIVO ("Multipurpose Internet Mail Extensions", MIME)

Figura: MIME("Multipurpose Internet Mail Extensions")

MIME es una ampliacin del marco de trabajo del RFC 822 y est pensada para solventar algunos de los problemas y limitaciones en la utilizacin de SMTP y el RFC 822 para correo electrnico. [MURP95] indica las siguientes limitaciones del esquema SMTP/822: 1. SMTP no puede transmitir ficheros ejecutables u otros objetos binarios. Se utilizanuna serie de esquemas para convertir ficheros binarios a formato de texto de forma que se pueda utilizar el sistema de correo de SMTP, incluido el esquema de popular UNIX UUencode/UUdecode. Sin embargo ninguno de estos procedimientos de conversin es un estndar ni siquiera de facto. 2. SMTP no puede transmitir datos de texto que incluyan caracteres de un lenguaje nacional ya que stos se representan por cdigos de 8bits con valores de 128 decimal o superiores, y SMTP est limitado a caracteres ASCII de 7 bits.

3. Los servidores SMTP pueden rechazar mensajes de correo a partir de un cierto tamao. 4. Lasarelas SMTP que traducen de caracteres ASCII a cdigos EBCDIC no utilizan un conjunto consistente de correspondencias, lo que da lugar a problemas de traduccin. 5. Las pasarelas SMTP a redes con correo electrnico X.400 no pueden gestionar datos que no son texto y que pueden estar incluidos en los mensajes X.400. Eliminacin, incorporacin o reordenamiento de caracteres retorno de carro y fin de lnea. Truncar o dividir lneas mayores de 76 caracteres.
38

Eliminar espacios finales (caracteres, tabuladores o blancos). Relleno de lneas en un mensaje para conseguir la misma longitud. Conversin de los caracteres tabuladores en mltiples caracteres de espacio.

MIME est pensado para resolver estos problemas de forma que resulte compatible con las implementaciones de RFC 822. La especificacin se encuentra en los RFC 2045 a 2049.

Descripcin general Las especificaciones MIME incluyen los siguientes elementos: 1. Se definen cinco campos nuevos de la cabecera del mensaje, que pueden ser incluidos en una cabecera RFC 822. Estos campos proporcionan informacin sobre el cuerpo del mensaje. 2. Se definen varios formatos de contenido, normalizando as las representaciones que dan soporte al correo electrnico multimedia. 3. Se definen esquemas de codificacin de transferencia posibilitando as la conversin de cualquier formato de contenido a un formato que est protegido por cambios del sistema de correo. Introduccin a los los cinco campos de cabecera de mensaje. MIME-Version Debe tener el valor "1.0". Este campo indica que el mensaje cumple con el RFC. Content-Type Describe como se ha de interpretar el objeto dentro del cuerpo. El valor por defecto es "text/plain; charset=us-ascii" que indica texto de 7 bits sin formato (cuerpo de mensaje segn la definicin de RFC 822). Content-transfer-encoding Describe cmo est codificado el objeto de modo que se puede incluir en el correo de forma fiable. Content-Description Una descripcin en texto plano del objeto del cuerpo que es til cuando el objeto no es legible (por ejemplo, datos de audio). Content-ID Un valor unvoco especificando el contenido de esta parte del mensaje.

39

Nota: el RFC 1521 incluye una definicin del trmino "cuerpo" tal como se emplea arriba, adems de los trminos "parte del cuerpo", "entidad", y mensaje. La forma ms simple de cuerpo es el cuerpo del mensaje como lo define el RFC 822. EL CAMPO CONTENT-TYPE El cuerpo del mensaje se describe con un campo Content-Type de la forma: Content-Type: type/subtype ;parameter=value ;parameter=value Los parmetros admisibles son dependientes de "type" y "subtype". Algunos pares "type/subtype", algunos los tienen opcionales, otros obligatorios, y otros ambos. El parmetro de "subtype" no se puede omitir, pero s todo el campo, y en este caso el valor por defecto es text/plain. Hay siete "content-types" estndares: text Slo tiene un "subtype": plain Texto sin formatear. El juego de caracteres se puede especificar con el parmetro charset. Se admiten los siguientes valores. us-ascii El texto consiste en caracteres ASCII en el rango de 0 a 127(decimal). Este es el valor por defecto (por compatibilidad con RFC 822). iso-8859-x spotis8859 donde la "x" est en el rango de 1 a 9 para las distintas partes del estndar ISO-8859. El texto consiste en caracteres ISO en el rango de 0 a 255(decimal). Todos los juegos de caracteres ISO-8859 estn basados en ASCII con caracteres nacionales en el rango de 128 a 255. Si el juego no contiene caracteres con valores mayores de 127, se debera usar "us-ascii", ya que as se pueden representar adecuadamente. Se pueden aadir nuevos "subtypes" para describir otros formatos de texto(tales como formatos de procesadores de texto) que contengan informacin para que una aplicacin mejore el aspecto del texto, siempre que el software en cuestin no tenga que interpretar el significado del texto. multipart El cuerpo del mensaje contiene mltiples objetos de tipos de datos independientes. En cada caso, el cuerpo se divide en partes denominadas separadores de encapsulado. El contenido de los separadores se define con un parmetro en el campo "content-type", por ejemplo: Content-Type: multipart/mixed; boundary="1995021309105517" El separador no debera aparecer dentro de ninguna de las partes del mensaje. Es sensible a maysculas y minsculas y tiene de 1 a 70 caracteres elegidos de un conjunto de 75
40

seleccionados por su robustez en pasarelas de correo, y no puede acabar en espacio. Cada separador consiste en su valor prefijado por la secuencia <CRLF> y dos guiones(para la compatibilidad con RFC 934). El ltimo separador que marca el fin de la ltima parte tiene adems como sufijo de dos guiones. Dentro de cada parte hay una cabecera MIME, que como las cabeceras del correo ordinario termina en la secuencia <CRLF><CRLF> pero que puede estar vaca. El campo de cabecera define el contenido del mensaje encapsulado. Se definen cuatro subtipos: mixed Las distintas partes son independientes pero se han de transmitir juntas. Se le deberan mostrar al receptor en el mismo orden en el que aparecen en el mensaje. parallel Difiere del anterior slo en que las partes no tienen orden inherente y el programa receptor de correo puede, por ejemplo, mostrarlas en paralelo. alternative Las distintas partes son versiones alternativas de la misma informacin. Se ordenan de menor a mayor fidelidad al original, y el sistema de correo receptor debera mostrar al usuario la versin ms fiel. digest Es una variante de "mixed" en la que el par "type/subtype" es "message/rfc822" en vez de "text/plain". Se usa en el caso frecuente de que se transmitan juntos mltiples mensajes RFC 822 o MIME. message el cuerpo es un mensaje encapsulado, o parte de uno. Estn definidos tres subtipos: rfc822 el mismo cuerpo es un mensaje encapsulado con la sintaxis de un mensaje RFC 822. Sin embargo, a diferencia de los mensajes de "alto nivel" de RFC 822, no tiene que tener el formato mnimo "From:", "To:" y una cabecera de destino al menos. Nota: RFC822 se refiere a la sintaxis de los "sobres" de los mensajes encapsulados. partial Este tipo se usa para permtir la fragmentacin de correos grandes de forma anloga a la fragmentacin IP. Debido a que los agentes SMTP pueden imponer lmites superiores al tamao del correo, puede que sea necesario enviarlos en fragmentos. La finalidad de este campo es que la fragmentacin sea transparente al receptor. El agente del usuario receptor debera reensamblar los fragmentos para crear un nuevo mensaje con semntica idntica a la del original. Hay tres parmetros para el campo "Content-type":
41

id= Un identificador unvoco comn a todas las partes del mensaje. number= El nmero de secuencia de esta parte; la primera parte se numera con el 1. total= El nmero total de partes. Es opcional en todas, excepto en la ltima. La ltima parte se identifica con la igualdad entre el parmetro "number" y "total". El mensaje original es siempre un mensaje que sigue las reglas RFC 822. La primera parte es sintcticamente equivalente a un mensaje "messagge/rfc822"(es decir, el propio cuerpo contiene cabeceras) y las partes siguientes a mensajes "text/plain". Al reconstruir el mensaje, los campos de cabecera RFC822 se toman del mensaje de alto nivel, con la excepcin de aquellos campos que no se pueden copiar del mensaje interior al exterior cuando existe fragmentacin(por ejemplo, el campo "Content-Type"). Nota: est permito de forma explcita fragmentar an ms un mensaje "messagge/partial". Esto permite que las pasarelas de correo fragmenten los mensajes libremente para asegurarse de que todas las partes son lo bastante pequeas para ser transmitidas. Si este no fuera el caso, el agente de correo que realice la fragmentacin tendra que conocer el mnimo tamao mximo que los correos se encontraran en su ruta hacia el destino. external-body Este tipo contiene un puntero a un objeto que existe en algn otro sitio. Tiene la sintaxis del tipo "message/rfc822". La cabecera del mensaje de alto nivel define como se ha de acceder el objeto externo, usando el parmetro "access-type:"(tipo de acceso) del campo "ContentType:'' y un conjunto de campos adicionales que son especficos del access-type. La finalidad de esto es que el lector de correo sea capaz de acceder de modo sncrono al objeto externo usando el "acces type". Estn definidos los siguientes "access types": ftp File Transfer Protocol. Se supone que el receptor ha de proporcionar el identificaddor de usuario y el password necesarios -- por razones de seguridad, estos nunca se transmiten con el mensaje. tftp Trivial File Transfer Protocol. anon-ftp FTP annimo. local-file
42

Los datos estn accesibles en un fichero a travs del sistema de ficheros local del receptor. afs Los datos estn accesibles en un fichero por el sistema de ficheros global Andrew("Andrew File System"). mail-server Los datos son accesibles por medio de un servidor de correo. A diferencia de los otros este acceso es necesariamente asncrono. Cuando el objeto externo ha sido recibido, el mensaje deseado se obtiene aadiendo el objeto a la cabecera del mensaje encapsulado dentro del cuerpo del mensaje "message/external-body". Esta cabecera encapsulada tiene que se interpretada(ha de tener un campo "Content-ID:'' , y normalmentte tendr un campo "Content-Type:"). El cuerpo encapsulado no se usa(despus de todo, el mensaje real est en algn otro lado) y por tanto se denomina "cuerpo fantasma". Hay una excepcin a esto: si el "access type" es "mailserver" el cuerpo fantasma contiene los comandos del servidor de correo necesarios para extraer el cuerpo real del mensaje. Esto se debe a que las sintaxis del servidor de correo varan mucho y es mucho ms sencillo usar el cuerpo fantasma, que de otra forma sera redundante, que codificar una sintaxis para codificar comandos arbitrarios del servidor de correo como parmetros del campo "Content-Type:". image el cuerpo contiene imgenes que requieren un display grfico o algn otro ispositivo para mostrarlas. Inicialmente hay definidos dos subtipos: jpeg la imagen est en formato JPEG, codificacin JFIF. gif formato GIF. video el cuerpo contiene imgenmes en movimiento(posiblemente con sonido sincronizado con ellas) lo que requiere una terinal inteligente o una estacin de trabajo multimedia para mostrarlas. Inicialmente slo est definido un subtipo: mpeg formato MPEG. audio el cuerpo contiene imgenes que requieren altavoces y una tarjeta de sonido(o hardware similar) para reproducirlas. Inicialmente slo est definido un subtipo:
43

basic El mnimo comn formato en ausencia de cualquier estndar de facto para la codificacin de audio. Especficamente, es la codificacin mu-law ISDN de 8 bits y un solo canal a 8kHz. application Tipo orientado a tipos queno se pueden clasificar en otras categoras, y particularmente para datos a ser procesados por un programa de aplicacin antes de ser presentados al usuario, tales como hojas de texto. Tambin va dirigido a programas de aplicacin que han de ser procesados como parte del proceso de lectura del correo(por ejemplo, el tipo PostScript indicado abajo). Este tipo de uso supone graves riesgos de seguridad a menos que la implementacin asegure que los mensajes de correo ejecutables se ejecuten en un entorno seguro o de "celda acolchada". Inicialmente hay dos subtipos definidos: PostScript Systems PostScript (nivel 1 o 2). Cuestiones de seguridad: aunque suele pensarse que PostScript es un formato de impresin, es un lenguaje de programacin y el uso de un intrprete de PostScript para procesar el tipo "application/PostScript" es una amenaza potencial a la seguridad. Cualquier lector de correo que interprete automticamente programas de PostScripts es equivalente, en principio, a uno que ejecute automticamente los programas ejecutables que recibe. El RFC 1521 perfila las posibles consecuencias. octet-stream Este subtipo indica datos binarios generales consistentes en bytes de 8 bits. Es adems el subtipo que un lector de correo debera asumir al encontrarse un tipo o subtipo desconocidos. Se permite cualqier parmetro, y el RFC menciona dos: "type=", para informar al receptor del tipo general y "padding=" para indicar un flujo de bits codificado en un flujo de bytes(su valor es el nmero de ceros aadidos para alinear el flujo a un nmero entero de bytes). Se recomienda que las implementaciones ofrezcan al usuario la opcin de utilizar los datos como entrada a un programa de usuario o de almacenarlos en un fichero(no hay estndar para el nombre por defecto de tal fichero, aunque el RFC 1521 menciona un campo "Content-Disposition:" a ser definido en un RFC posterior. Cuestiones de seguridad: el RFC desaconseja enrgicamente que una implementacin ejecute una parte "application/octet-stream" automticamente o que la emplee como entrada a un programa especificado en la cabecera. Hacerlo implicara exponer la integridad del sistema y de cualquier red a la que est conectado.

44

Obviamente, hay muchos tipos de datos que no caen dentro de ninguno de los subtipos indicados arriba. Los programas de correo cooperativos, manteniendo las reglas del RFC 822, usan tipos y/o subtipos que comienzan por "X-" como valores privados. No se permiten otros valores que no hayan sido registrados previamente con IANA. Ver el RFC 1590 para ms detalles. La intencin es que se necesiten pocos o ningn tipo adicional, pero que se aadan muchos subtipo al conjunto. EL CAMPO "CONTENT-TRANSFER-ENCODING" Como ya se ha indicado, los agentes SMTP y las pasarelas de correo pueden ejercer fuertes restricciones sobre los contenidos de los mensajes que se pueden transmitir fiablemente. Los tipos MIME descritos arriba son una lista de un variado conjunto de distintos tipos de objetos que se pueden incluir en un correo y la mayora de ellos no se hallan dentro de estas restricciones. Por lo tanto, es necesario codificar estos datos de forma que se puedan transmitir y decodificar a su recepcin. RFC 1521 define dos formas fiables de codificacin. La razn de que haya dos formas y no una es que no es posible, dado el pequeo conjunto de caracteres fiables, desarrollar una sola forma que codifique tanto texto con un impacto mnimo en la legibilidad y datos binarios de un modo lo bastante compacto como para ser prctico. Estas dos codificaciones se usan slo para los cuerpos, no para las cabeceras. La codificacin de cabeceras se describe en Usando caracteres no-ASCII en las cabeceras de los mensajes. El campo "Content-Transfer-Encoding:" define la codificacin usada. Aunque engorroso, este campo enfatiza el hecho de que la codificacin es una caracterstica del transporte y no una propiedad intrnseca del objeto enviado. A pesar de haber slo dos formas de codificacin, este campo puede tomar cinco valores(no sensibles a maysculas y minsculas). Tres de ellos especifican que no se ha realizado ninguna codificacin; la diferencia entre ellos reside en que cada uno implica distintas razones por las que no ha habido codificacin. Es un punto sutil pero importante. SMTP no es el nico agente de correo posible de MIME, a pesar de la popularidad de sistemas de correo SMTP en Internet. Por ello, MIME permite la transmisin de datos no fiables por los estndares SMTP(STD 10/RFC 821). Si un correo de esta clase alcanza una pasarela para pasar a un sistema ms restrictivo, el mecanismo de codificacin especificado permite a la pasarela decidir, para cada tem de correo, si el cuerpo se debe codificar para transmitirlo fiablemente. Las cinco "codificaciones" son:

"7bit"(por defecto si se omite la cabecera "Content-Transfer-Encoding:"). "8bit" "Binary" "Quoted-Printable" "Base64"

Se describen en la siguiente seccin.

45

Codificacin 7bit

Codificacin 7bit significa que no se ha hecho ninguna codificacin y que el cuerpo consiste en lneas de texto ASCII con longitud no mayor de 1000 caracteres. Por ello, es fiable para cualquier sistema de correo que siga estrictamente las normas STD 10/RFC 821(por defecto, ya que son las restricciones que se aplican a los mensajes pre-MIME STD 11/RFC 822). Nota: esta codificacin no garantiza la total fiabilidad de los contenidos por dos razones. Primero, porque las pasarelas a redes EBCDIC tienen un conjunto de caracteres fiables ms pequeo, y segundo, porque hay muchas implementaciones que no siguen SMTP.
Codificacin 8bit

Codificacin 8bit implica que las lneas son lo bastante cortas para el transporte SMTP, pero que puede haber caracteres no ASCII. Esta codificacin slo es posible en los agentes SMTP que soporten el SMTP Service Extension for 8bit-MIMEtransport("Extensin SMTP para transporte MIME de 8 bits"), descrito en el RFC 1652. En otro caso, las implementaciones de SMTP deberan poner el bit de orden superior a cero, de modo que la codificacin 8bit no sera vlida.
Codificacin "Binary"

Indica que pueden aparecer caracteres no-ASCII y que las lneas pueden ser demasiado largas para el transporte SMTP(es decir, puede haber secuencias de 999 ms caracteres sin una secuencia CRLF). En la actualidad no estndares para el transporte de datos binarios sin codificar en sistemas de correo de TCP/IP, por lo que el nico caso en el que se puede usar codificacin "binary" en un mensaje MIME en una red TCP/IP es en la cabecera de un parte externa de un cuerpo. Se podra usar en otros casos si MIME se empleara junto con otros mecanismos de transporte o con una extensin hipottica de SMTP.
Codificacin "Quoted-Printable"

Es la primera de las dos codificaciones propiamente dichas y su fin es mantener la mxima legibilidad de los ficheros de texto en su forma codificada.

Representa los caracteres no fiables con la forma hexadecimal de sus valores ASCII. Para mantener la longitud de cada lnea a 76 caracteres o menos introduce saltos de lnea reversibles ("soft").

Esta codificacin utiliza el signo igual para sealar estos dos casos. Tiene cinco reglas que son: 1. Cualquier carcter excepto uno que sea parte de una secuencia de nueva lnea(es decir, X'0D0A' en un fichero de texto) se puede representar con "=XX" donde XX son dos dgitos hexadecimales en mayscula. Si ninguna de las dems reglas se aplica, el carcter debe representarse as.

46

2. Cualquier carcter en el rango X'21' a X'7E' excepto X'3D' ("=") se puede representar en ASCII. 3. Los caracteres ASCII TAB (X'09') y SPACE (X'20') se pueden representar en ASCII excepto cuando son el ltimo carcter de la lnea. 4. Un salto de lnea se debe representar con la secuencia <CRLF>(X'0D0A'). Al codificar datos binarios, X'0D0A' no es un salto de lnea y se debera codificar, segn la regla 1, como "=0D=0A". 5. Las lneas codificadas no pueden tener ms de 76 caracteres(sin contar el <CRLF>). Si una lnea es mayor, se debe introducir un salto de lnea reversible en o antes de la columna 75. Se representa con la secuencia "=<CRLF>"(X'3D0D0A'). Este esquema es un compromiso entre legibilidad, eficiencia y robustez. Como las reglas 1 y 2 utilizan la expresin "se pueden codificar", las implementaciones tienen bastante libertad a la hora de decidir a cuntos caracteres les aplican estas reglas. Si se aplican en el mnimo nmero de caracteres, la codificacin funcionar con agentes SMTP ASCII fiables. Para pasarelas EBCDIC fiables, se aade el siguiente conjunto de caracteres ASCII: !"#$@[\]^`{|}~ a la lista de caracteres a los que les son aplicables las reglas. Para una robustez total, es mejor aplicar las reglas a todos los caracteres, excepto al conjunto de 73 caracteres que no vara al atravesar la pasarela, es decir, las letras(A-Z,a-z), los dgitos(0-9) y los siguientes 11 caracteres: '()+,-./:=? Nota: Esta lista de invariantes ni siquiera incluye el carcter SPACE. Con fines prcticos, al codificar ficheros de texto slo se debera marcar con las reglas un SPACE al final de la lnea. De otra forma, la legibilidad se ve seriamente afectada.

Codificacin "Base64

Esta codificacin se destina a datos que no consisten principalmente en texto. Trata el flujo de entrada como un flujo de bits, reagrupando los bits en bytes ms cortos, que luego rellena hasta 8 bits para traducirlos a caracteres fiables. Como se indic en la seccin previa, slo hay 73 caracteres fiables, por lo que la longitud mxima utilizable de cada byte es de 6 bits, que se pueden representar con slo 64 caracteres(de hay el nombre "Base64"). Como tanto la entrada como la salida son flujos de bytes, la codificacin se debe hacer en grupos de 24 bits(3 de entrada y cuatro de salida). El proceso se puede ver de la siguiente forma:

47

Figura: Codificacin "Base64" - Conversin de 3 bytes de entrada a 4 bytes de salida en el esquema de codificacin "Base64".

La

tabla

de

traduccin

usada

se

llama

el alfabeto

"Base64".

Figura: El alfabeto "Base64"

Se necesita un carcter adicional(el "=") para el relleno. Como la entrada es un flujo de bytes que se codifica en grupos de 24 bits, le podrn faltar 0, 8 16 bits, al igual que a la salida. Si la salida tiene la longitud adecuada, no hace falta relleno. Si a la salida le faltan 8bits, esto se corresponde con una salida de cuarto de dos bytes completos, un "short byte" y un byte faltante. El "short byte" se rellena con los 2 bits de orden inferior a cero. Los dos bytes faltantes se sustituyen con un carcter "=". Si a la salida le faltan 16 bits, esto se corresponde con una salida de cuarto de un byte completo, un "short byte" y dos bytes faltantes. El "short byte" se rellena con los 6 bits de orden inferior a cero. Los dos bytes faltantes se sustituyen con un carcter "=". Si se utilizaron "cero caracteres", el agente receptor no sera capaz de decir al decodificar el flujo de entrada si X'00' caracteres de cola
48

en la ltima o en las dos ltimas posiciones eran datos orelleno. Con caracteres de relleno, el nmero de "="s (0, 1 o 2) da la longitud del flujo de entrada en mdulo 3(0, 2 1 respectivamente).
Conversin entre codificaciones

La codificacin "Base64" se puede traducir libremente de y a la forma "binary" sin ambigedad ya que ambas tratan los datos como flujos de bytes. Esto se cumple tambin en el caso de la traduccin de "Quoted-Printable" a cualquiera de las otras dos(en el caso de la conversin a "binary", se puede ver como un proceso con una traduccin con una codificacin "binary" intermedia), convirtiendo las secuencias de caracteres marcados a su forma de 8 bits, borrando los saltos de lnea reversibles y sustituyendo los saltos de lnea por secuencias <CRLF>. Esto no es estrictamente cierto para el proceso inverso ya que la codificacin "Quoted-Printable" est orientada a registros: hay una diferencia entre un salto de lnea y una secuencia "=0D=0A" embebida(por ejemplo, se mapearan de distinta forma en un sistema EBCDIC).
Codificaciones mltiples

MIME no permite el anidamiento de codificaciones. Cualquier "Content-Type" que indique recursivamente otros campos Content-Type no puede usar un "Content-Transfer-Encoding" que no sea "7bit", "8bit" o "binary". Todas las codificaciones se deben hacer en el nivel ms interno. El fin de esa restriccin es simplificar el uso de los agentes de correo. Si no se permiten codificaciones anidadas, la estructura de todo el mensaje siempre le es visible para el agente sin tener que decodificar capas externas del mismo. Esta simplificacin para los agentes de correo tiene un precio: complejidad para las pasarelas. Como un agente puede especificar codificacin "8bit" o "binary", una pasarela a una red en la que estas codificaciones no sean seguras tendrn que codificar el mensaje antes de pasrselo a la segunda red. La solucin obvia, codificar el cuerpo del mensaje y cambiar el campo "Content-Transfer-Encoding:", no est permitida en los tipos "multipart" o "message" ya que violara las restricciones indicadas ms arriba. La pasarela, por tanto, debe descomponer el mensaje en sus componentes y recodificar las partes internar cuando sea necesaria. Hay todava otra restriccin: en los tipos "message/partial" la codificacin debe ser siempre "7bit"(no se permiten "8bit" y "binary"). La razn para esto es que si una pasarela necesita recodificar un mensaje, requiere disponer todo el mensaje, pero puede que no todas las partes del mismo estn disponibles(las partes se pueden transmitir en serie, debido a que la pasarela no sea capaz de almacenar todo el mensaje o incluso se pueden haber encaminado independientemente por diferentes pasarelas). Por ello, las partes de los cuerpos de los mensajes "message/partial" deben ser fiables hasta en el peor caso; es decir, deben codificarse en "7bit". Usando caracteres no ASCII en cabeceras de mensajes

49

Todos los mecanismos estudiados arriba se refieren exclusivamente a los cuerpos, y no a las cabeceras. Los contenidos de las cabeceras de los mensajes an se han de codificar en US ASCII. En cabeceras que incluyan texto legible, este juego de caracteres no es apto para lenguajes distintos del ingls. Un mecanismo para incluir caracteres nacionales est definido en la segunda parte de MIME(RFC 1522). Este mecanismo difiere de la codificacin "Quoted-Printable", que se usara en el cuerpo del mensaje por las siguientes razones:

El formato de las cabeceras est codificado estrictamente en RFC 822, por lo que la codificacin de la cabecera debe trabajar dentro de unos mrgenes ms estrechos que los del cuerpo. Los programas de retransmisin de mensajes suelen cambiar las cabeceras, por ejemplo reordenando sus campos, borrando algunos de ellos, reordenando los buzones dentro de las listas de correo o dispersando campos por distintas posiciones del mensaje original. Algunos programas de manipulacin de mensajes no manejan correctamente algunas de las caractersticas ms antiguas de RFC 822(como el uso de "\" para marcar caracteres especiales como "<" y ">.").

El enfoque de MIME es reservar secuencias improbables de caracteres ASCII legales que no son sintcticamente importantes en RFC 822. Las palabras de los campos de cabecera que tienen caracteres nacionales se reemplazan con palabras codificadas que tienen la forma: =?charset?encoding?word?= donde: charset es el valor admitido para el parmetro "charset" usado con el tipo MIME "text/plain", es decir, "us-ascii", "iso-8859-1" a "iso-8859-9". encoding "B" o "Q. "B" es idntica a la codificacin "Base64" aplicada a los cuerpos. "Q" es similar a "Quoted-Printable" pero utiliza "_" para representar X'20'(SPACE). La codificacin (18) Q requiere codificar los caracteres "_" y no permite saltos de lnea. Cualquier carcter ASCII diferente de "_", "=" y SPACE no tienen que marcarse en la palabra codificada a menos que sea sintcticamente significativo cuando cabecera se descompone por RFC 822."charset" y "encoding" no son sensibles a maysculas y minsculas. word es una ristra de ASCII caracteres ASCII distintos de SPACE de acuerdo a las reglas de la codificacin dada.
50

Una palabra codificada no debe tener caracteres en blanco embebidos(SPACE o TAB), puede tener hasta 75 caracteres, y puede no estar en una lnea de ms de 76 caracteres(sin contar <CRLF>). Estas reglas aseguran que las pasarelas no plegarn las palabras codificadas por el medio. Las palabras codificadas, en general, se pueden usar en las partes legibles de los campos de la cabecera. Por ejemplo, si un buzn se especifica de la forma: The Octopus <octopus@garden.under.the.sea> se podra utilizar una palabra codificada en la seccin "The Octopus" pero no en la parte de direccin entre el "<" y el ">"). RFC 1522 especifica precisamente donde se pueden usar palabras codificadas en relacin con la sintaxis RFC 822.

51

Bibliografa.

Microsoft Windows Server 2003. Protocolos y Servicios TCP/IP. Joseph Davies Thomas Lee. http://www.rfc-es.org/ RFC 821, 1869, 2821.

http://es.kioskea.net/contents/279-protocolos-de-mensajeria-smtp-pop3-e-imap4
Protocolos de mensajera (SMTP, POP3 e IMAP4). http://www.falconmarbella.com/esigranada/dmdocuments/Punto_235_Correo_electr onico.pdf 3er Curso de Informtica. (Tecnologas de la Comunicacin e Internet.) EL SISTEMA DE CORREO ELECTRNICO (SMTP Y POP3) http://es.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol Simple Mail Transfer Protocol. http://www.telecable.es/personales/jrubi/index.htm?resumen/res00266.htm SMTP. Funcionamiento.

52