INTRODUCCIÓN *

EL CORREO ELECTRÓNICO *

SMTP (Simple Mail Transfer Protocol) *

El POP *

LAS MIME *

BIBLIOGRAFÍA CONSULTADA *

El ser humano se ha caracterizado por ser un animal netamente social, y se diferencia de las demás bestias por su capacidad de razonamiento, la cual según algunas teorías psicológicas se manifiesta por medio del lenguaje; es decir, la habilidad de comunicarse, que permite al hombre exteriorizar sus pensamientos. Las formas más primitivas de comunicación implicaban las presencia física de ambas partes de la comunicación; tanto emisor como receptor debían estar juntos al establecer la comunicación.

Con el advenimiento de la escritura esto cambió radicalmente, ya no era necesario la presencia de ambas partes de la comunicación para poder entablar una; En cambio se necesitó de el transporte físico del mensaje, generalmente en papel, y así nació un primer concepto de portadora de un mensaje. Los antiguos Incas implementaron un ingenioso sistema de transmisión de mensajes utilizando personas que recorrían la extensión de su reino llevando consigo y pasando de boca en boca el contenido del mensaje hasta que éste alcanzara a su destinatario.

Éste primer intento de un sistema de correo se acerca bastante al que funciona actualmente a nivel mundial. Un poco mas refinado, con jerarquías de distribución, legislación que lo regula y protege; pero el concepto fundamental es el mismo, el transporte físico un mensaje. El problema con este sistema es que hace uso de medios de transporte que por lo general son caros y lentos. Cuenta la leyenda que mientras Samuel Morse viajaba por Europa su madre, en Estados Unidos, cayó gravemente enferma, inmediatamente su familia intentó contactarlo por medio de una carta pero para cuando ésta llegó a él su madre ya había muerto. Esta situación condujo a Morse llevar a cabo una profunda investigación sobre las propiedades de la transmisión de la corriente eléctrica a través de un cable. La cual finalizó con la invención del telégrafo. Y éste fue el primer medio de transmisión eléctrico del que se tiene registro. Pronto la líneas telegráficas se extendieron por todo el mundo y cuando estas líneas no podían establecerse se recurrió a la radio transmisión; ahora se contaba con un medio de transporte rápido y, relativamente, barato. El telégrafo fue casi totalmente reemplazado 40 años después de su nacimiento por el revolucionario invento de Graham Bell, el teléfono, tan revolucionario que 120 años después sigue vigente. Este sistema tiene una escala global y conecta una inmensa jerarquía de conmutadores, multiplexores y conversores de señales que permiten una comunicación a cualquier lugar del mundo.

Éste sistema se adecua perfectamente para la transmisión de voz de un extremo al otro, bueno casi perfectamente, pero para la transmisión de datos resultaba bastante deficiente por lo que se construyó paralelamente a la red telefónica la red de telex, que a mediados de los años 20 nació como la manera más rápida de tener información bursátil actualizada, una máquina telex podía comunicarse con cualquier otra máquina por medio de una línea telex, también se proporcionaba una relativa seguridad ya que éstas máquinas para establecer una comunicación tenían una especie de protocolo de acuerdo (handshaking). A medida que pasaron los años la información fue ganando mayor importancia en la vida empresarial y en los ‘60 las grandes compañías comenzaron a instalar grandes computadoras y a conectar terminales bobas a ellas; teniendo así acceso a su información y a sus otros recursos, memoria, procesador, dispositivos de E/S, etc.

Ésta gran computadora o Mainframe hacía las veces de servidor a las terminales que servía, de ahí que también se la llamara Server (Servidor), Dependiendo de los servicios que proporcionara se denominaría File-Server (servidor de archivos) , Print-Server (servidor de impresión). Luego de que los usuarios de familiarizaran con esta nueva metodología de trabajo; se hizo evidente la posibilidad de hacer que los usuarios mismos pudieran dar información a otros usuarios, y hacer así la interacción más dinámica y eficiente, sin la necesidad de que los usuarios tuvieran que estar físicamente juntos, así surgió la implementación de un Mail-Server (servidor de correo) como el que se muestra en la Figura 1.

A su vez, y paralelamente con la expansión de las redes de computadoras en la industria y el comercio, el Departamento de Defensa de los EE.UU. comenzó su incursión en este mundo y con la ayuda de Universidades y de abnegados estudiantes puso en marcha la ARPANET la predecesora en cierta manera de la INTERNET. En este contexto se tiene como registro de la primera transmisión de un e-mail en el año 1971.

Con la llegada del auge, en los precios, de las computadoras personales, la idea de red cambió radicalmente, hoy no hablamos más de procesamiento centralizado, en su lugar tenemos procesamiento distribuido, cada día más empresas instalan LANs de computadoras personales, y con la posibilidad de conectar varias LAN surge inevitablemente una gran red mundial, la INTERNET.

Con la aparición de la INTERNET nace en los profesionales de la informática un sueño casi utópico, La aldea Global, librar al mundo de las fronteras físicas, crear un espacio donde el tiempo es un concepto muy flexible, no en el sentido relativista, introducir las ideas de tiempo y distancia cero; aunque todavía estamos lejos de la implementación de semejante empresa estamos en la búsqueda y el correo electrónico es una de las herramientas que nos llevará a conseguir tan anhelado sueño.

El e-mail comenzó como la posibilidad que permitía a distantes colegas que trabajaban para una empresa que tenía una LAN trabajar juntos, compartir experiencias, e intercambiar ideas y proyectos. Esta implementación ya se mostró en la figura 1, luego se vislumbró la posibilidad de hacer que un usuario pudiera acceder a este mismo servicio en forma remota es decir sin estar conectado a la red, en realidad conectado por medio de una línea telefónica y un MODEM, como se muestra en la figura 2.

El siguiente paso en la expansión era conectar varias LAN para que intercambiaran los mensajes dirigidos a sus usuarios, Figura 3. Esta implementación incluye una dificultad adicional cada servidor de correo de conocer sus usuarios locales (conectados a su red) y los remotos (de la otra red) así se introducen las direcciones de correo y los dominios.

El proceso de envío de un mensaje de correo, consistía originalmente En un usuario escribiendo el mensaje en un programa de aplicación llamado cliente de correo, en contraposición con el servidor de correo, que consistía de un editor de texto, posiblemente un corrector ortográfico, una base de datos de la forma de una libreta de direcciones, un administrador de archivos (los mensajes recibidos o no enviados) y un módulo de comunicaciones para poder transferirlos.

El mensaje quedaba almacenado en el mail-server hasta que el usuario destinatario usando su cliente de correo se conectara con él y solicitara los mensaje que le tuviera reservados, el proceso inverso de envío de mensajes era muy parecido cuando el usuario terminara de escribir su mensaje, especificando la dirección de el destinatario, se conectaba con el servidor a fin de depositar el archivo hasta que el destinatario lo solicitara. Cuando el servidor está conectado a sólo una red la única limitación de la dirección de destino, además de no permitir espacios en blanco en la dirección, era que cada dirección debía identificar de forma unívoca a cada usuario, con una LAN esta restricción es fácil de implementar pero con más de una ya pasa a ser un problema mayor; así se introducen los dominios de los usuarios que representan a que servidor pertenecen y que tienen la forma de una dirección válida, es decir sin espacios en blanco ni caracteres prohibidos, para diferenciar el nombre del usuario de su dominio se adoptó en caracter "@" que significa "en" (at) entonces la dirección Bruno@Servidor.A se puede leer como "Bruno en Servidor.A"

Un problema surgió cuando se intentaron, conectar servidores de correo que utilizaban productos comerciales distintos, que aunque conceptualmente hacía lo mismo eran totalmente incompatibles. El hecho era que hasta el momento no existía un estándar que reglamentara cómo debían implementar los productos este servicio. La necesidad de un estándar se hizo más patente cuando redes totalmente distintas comenzaron a conectarse mediante la INTERNET. Una compañía, posiblemente multinacional, que tuviera asiento en distintos países del mundo y quisiera intercambiar e-mail tenía que contratar a un ISP (INTERNET SERVICE PROVIDER) y así tener acceso ilimitado a la INTERNET. Este arreglo podría tener la forma de la figura 4.

Como solución a este caos de variedades de mensajes de e-mail totalmente incompatible, surgieron dos soluciones, dos estándares, aunque parezca contradictorio, el primer estándar es el de facto de la INTERNET y publicó en 1982 bajo la forma de la RFC 821 y se denominó SMTP (simple mail transfer protocol), el protocolo simple de transferencia de mail, y como su nombre lo indica la intención de la gente que hizo el estándar era que conservara la simplicidad de sus predecesores; uno par de años más tarde, y quizá demasiado, llegó el estándar oficial de la CCITT para el manejo de mensajes en INTERNET y se llamó X.400 este estándar nunca llegó a imponerse en la INTERNET debido a su complejidad, lo poco flexible de las direcciones y a que llegó un poco demasiado tarde, el hecho es que el estándar de INTERNET para la transferencia de correo es el SMTP que se usa aún hoy ampliamente en toda la red, con algunas excepciones, que debido a su formato de transferencia que será explicado en la próxima sección, el SMTP no soporta los caracteres extendidos que son imprecindible en idiomas como el francés y el alemán, en particular los gobiernos de Francia y Canadá impulsaron el X.400 como estándar ya que se adaptaban mucho mejor a sus necesidades, ahora estos dos países son los únicos que soportan estos protocolos y debido a esto se necesitó la creación de pasarelas de conversión de un sistema al otro.

Estos protocolos funcionan adecuadamente cuando los destinatarios están permanentemente conectados a la INTERNET como en la figura 4 pero unos años después de la publicación de los estándares se hizo más común la INTERNET para usuarios domésticos que desde sus casa se conectaban, mediante un MODEM, esporádicamente a la INTERNET. Estos usuarios tienen un contrato con un ISP que está siempre conectado a la red y al llegar aun mensaje de correo para un usuario de ese ISP el mail-server del ISP debe guardar el mensaje hasta que el usuario se conecte y lo solicite. Esta situación se ilustra en la figura 5.

Este ambiente se requirió la especificación de otro estándar para estos usuarios, de esta manera apareció en escena el protocolo de oficina postal, POP, que actualmente se encuentra en su versión 3. Esta protocolo será explicado más en detalle en las siguientes secciones, permite un interfaz simple para la recepción de mensajes y se complementa perfectamente con el SMTP, en la forma en que este último se encarga del envío de correo y su tránsito por la INTERNET hasta el mail-server destino y el POP se encarga de el transporte de los mensajes almacenados en el servidor a usuarios que esporádicamente se conecta a él. Este arreglo podría se algo parecido al de la figura 6. Nótese que no es necesario que los clientes estén conectados permanentemente en cambio los servidores si.

El último tema de discusión se centrará en las extensiones del protocolo SMTP para hacer más flexible el adjuntamiento de archivos de distinto tipos, así como también la posibilidad de incluir otros juegos de caracteres que no fueran los US-ASCII (caracteres ascii norteamericanos) como se especificaron en SMTP. Estas extensiones se llamaron MIME (multipurpose internet mail extensions) por Extensiones de correo multipropósito de INTERNET, estas recomendaciones se dividieron en cinco parteE: Formato de cuerpo del mensaje, el sistema de escritura de MIME, la inclusión de un campo en la cabecera del SMTP para manejar caracteres no US-ASCII, la especificación del registro de servicio relacionados con MIME, y el último proporciona ejemplos, créditos y bibliografía utilizadas. Estos documentos se publicaron como los RFC 2045 al 2049 respectivamente.

Es hora de ver más a fondo el protocolo básico de el sistema actual de correo en INTERNET. Pero antes de eso y para una mayor claridad haremos un breve estudio de las dirección de correo.

La dirección de correo tiene la forma de una cuenta (un espacio en un servidor) y un nombre de dominio, separados como se mencionó antes por el caracter especial @, el nombre de dominio está especificado en el URL (Universal Resource Locator) del sitio específico de INTERNET, y lo identifica unívocamente en el contexto de la red. Un URL tiene la forma de:

HTTP:\\WWW.BRUNO.COM

De donde se extrae el protocolo, el nombre la máquina servidora, y por último el dominio de esa máquina. Así una dirección de correo para este dominio sería alguien@bruno.com, los nombre de dominio no están reglamentados, sin embargo por lo general éstos finalizan con un código de dos letras que identifican al país en el que se encuentra el dominio, su omisión significa que está ubicado en el EE.UU.

El SMTP hace uso de los dominios para transferir los mensajes, pero para conocer la dirección de red de un dominio dado, usa los servicios de un DNS o sistema de nombres de dominio; que convierte un nombre de dominio dado en una dirección de red que en el contexto de INTERNET significa una dirección IP

Ahora si podemos ingresar de lleno en el funcionamiento de el SMTP

Como consecuencia de la solicitud de un cliente de correo, a su mail-server, del envío de un mensaje, el mail-server se transforma en un emisor SMTP el cual establece una conexión duplex integral con el receptor SMTP, el cual puede ser la dirección de destino o un host en el camino intermedio hacia éste. El emisor y receptor intercambian mensajes y respuestas en un diálogo del tipo parada y espera; los comandos enviados por el emisor se verán con detalle más adelante así como las respuestas a estos comandos.

Estos comandos tienen la forma de cuatro caracteres ASCII y cuando es necesario uno o más parámetros, también en la forma de caracteres ASCII; tanto los comandos como las respuestas finalizan con la combinación de caracteres especiales <CR/LF> . Además se proporciona un código de respuesta de tres dígitos decimales. También existe la posibilidad de enviar comandos que contengan múltiples líneas de parámetro; por ejemplo el comando DATA, que indica que a continuación se enviará el texto del mensaje, es un comando de líneas múltiples, se delimita estos mensajes con una secuencia <CR/LF> . <CR/LF>

Una vez abierto el canal de transmisión, los hosts conectados hacen un intercambio de información para asegurarse, que están hablando con quien ellos quieren. Para esto se el emisor envía un comando HELO seguido de su dominio. Para finalizar la conexión simplemente el emisor envía el comando QUIT y se libera la conexión. Un ejemplo ilustrará mejor este procedimiento.

<Se establece la conexión >

R: 220 RECEPTOR.COM.AR simple mail transfer service ready

E: HELO TRANSMISOR.COM.BR

R: 250 RECEPTOR.COM.AR

E: QUIT

R: 221 RECEPTOR.COM.BR service closing transmission chanel

<Se libera la conexión >

Como convención usaremos las etiquetas R: y E: para referirnos al receptor y emisor respectivamente

La transferencia de mail tiene tres pasos necesarios cada uno con un comando específico, y con respuestas afirmativas o negativas para cada uno de ellos. El primer paso es el envío del comando MAIL especificando el origen del mensaje con el "camino inverso", que se usará para reportar errores si los hubiera, el host receptor puede tanto aceptar el mensaje entrante, con una respuesta Positiva (250 OK), como rechazarlo con una respuesta negativa. Este comando indica al receptor el inicio de la transacción de mail por lo que éste debe poner en cero sus tablas de estado, buffers, etc., este comando resetea al receptor. El camino inverso, es la ruta, lista de hosts, que ha seguido el mensaje hasta el host emisor, y tiene a éste al principio de la lista.

El segundo paso comienza con el envío del comando RCPT que indica a quien está destinado el mensaje, con un "camino directo" que indica la ruta que siguió el mensaje hasta el receptor y éste encabeza la lista de hosts del camino. Por simplicidad en este punto supondremos que sólo puede conocer al destinatario si es un usuario local, en cuyo caso acepta el mensaje para él (250 OK), si no conoce ese usuario entonces responde negativamente al comando del emisor (550). Luego veremos que éstas no son las únicas posibilidades que caven. Este comando debe repetirse la cantidad de veces necesarias para que el emisor envíe todos los mensajes que tiene para ese dominio.

El ultimo paso de la transacción es el comando DATA, si el receptor acepta envía una respuesta 354, indicando que está listo para recibir el mensaje. Las líneas del mensaje se envían secuencialmente y se marca el final con una línea conteniendo sólo un punto, es decir la secuencia <CR/LF> . <CR/LF>, se usa un método de relleno de caracteres para prevenir la aparición de esta secuencia dentro del texto, es decir si en el cuerpo del mensaje el emisor verifica que el primer caracter de una línea es un punto "." entonces agrega una adicional para que no se malinterprete como un final de texto. En el receptor se lleva a cavo el proceso inverso, a saber, inspecciona cada línea del mensaje si encuentra sólo un punto sabe que es el fin del mensaje, si encuentra un punto seguido de otros caracteres en la misma línea, elimina el punto que agregó el emisor. Al detectar el final del mensaje el receptor envía al emisor una respuesta 250 OK si todo anduvo bien y responde negativamente y no contaba con los recursos necesarios para almacenar el mensaje, por ejemplo.

Ahora se presenta un ejemplo de una transacción de mail

En el ejemplo el usuario Smith del hots Alpha.arpa envía tres mensajes a Jones, Green y Brown. Todos usuarios del host receptor, Beta.arpa, excepto el segundo que recibe una respuesta negativa.

En algunos casos la información del destino es incorrecta, pero el host receptor conoce la verdadera dirección del destinatario. Si este es el caso pude tomar dos acciones; o tomar el mensaje y él mismo re-enviarlo, o informar la dirección de destino correcta y rechazar el mensaje. Ambas acciones se informan con una respuesta al comando RCPT, ahora debe quedar claro que el host no solo conoce a sus usuarios locales. Ambas respuestas entregan al emisor la dirección correcta para su uso futuro.

Las dos situaciones se muestran en el ejemplo.

Las listas de correo son tablas en el hosts conteniendo pares nombre de usuario, casilla de correo, éstos son todos los usuarios que el host reconoce pueden ser locales o remotos. El comando VRFY que tiene como parámetro una cadena de caracteres, que indica e nombre de usuario que se está buscando, y responde el nombre completo del usuario y su casilla de correo, si lo encuentra en su tabla. El ejemplo muestra todas las respuestas posibles a este comando.

La primer respuesta significa que el usuario es local, la segunda indica que no es local pero se aceptan sus mensajes para re-enviarlos, el usuario no existe, el usuario no es local y no se aceptan sus mensajes, y hay más de un usuario con ese nombre.

El ejemplo muestra las respuestas posibles para el comando EXPN el parámetro indica la lista de correo que se quiere ver. La respuesta positiva muestra los usuarios que pertenecen a la lista; y la respuesta negativa es un acceso negado a esa información.

En la época de publicación del RFC 821 era muy común que los host tuvieran terminales conectadas a ellos por eso, el protocolo provee la posibilidad de enviar mensaje a la casilla de correo (mailing) o enviarlos directamente a la terminal (sending). Para implementar esta distinción se proveen tres comandos que involucran esta emisión de mensajes.

El comando SEND envia un mensaje a una terminal si ésta está activa, en caso contrario devuelve una respuesta negativa 450.

SOML significa Send OR MaiL, que funciona igual al anterior pero si la terminal no está activa el mensaje se guarda en su casilla de correo.

SAML Send And Mail lleva a cavo las dos acciones, un send si es posible y un mail en cualquier caso.

Cuando llega un mensaje a un host se indica su camino inverso (cómo llegó hasta aquí) y su camino directo (cómo llegar a su destino), el primer elemento del camino inverso debe contener el domino del host emisor del mensaje, y el primer elemento del camino directo deber ser el host receptor de el mensaje actual, en cada retransmisión exitosa del mensaje, el receptor elimina su dominio del camino directo y lo anexa al camino inverso, esto significa que el mensaje pasó por aquí, o por lo menos eso va a intentar, ahora el receptor del mensaje pasa a ser emisor y se conecta con el próximo host del camino directo, si la transmisión tiene éxito el host receptor repetirá el procedimiento hasta llegar al host destino, el último del camino directo. En caso de no tener éxito con la re-transmisión de mensaje, el host debe informar al emisor original del mensaje sobre las causas de la falla, y para eso utiliza la información contenida en el camino inverso, y construye un mensaje de "mail inentregable". Este mensaje se envía con una emisor nulo (MAIL FROM : <>) para así evitar notificaciones de notificaciones, si la notificación no llegó no es tan importante y se previenen potenciales ciclos de notificaciones. Un ejemplo de notificación se presenta a continuación, las razones para que un host no acepte un mensaje pueden ser varias y se desprenden de los comandos RCPT o MAIL.

El mensaje de notificación informa el usuario emisor que en la trayectoria especificada al destino ocurrió un problema, en este caso el host HOSTZ.ARPA no reconoció al usuario destinatario del mensaje.

Por lo general los host no sólo toman esta acción sino que continúan intentando enviar el mensaje durante un período dado, por ejemplo 4 días, por si el host estaba temporariamente inhabilitado.

En muchas implementaciones es útil que los procesos intercambien los roles de emisor y receptor, para hacer esto el emisor envía un comando TURN, el receptor está en libertad de aceptar (respuesta 250), y pasar a ser el emisor; o rechazar la propuesta (respuesta 502). Este comando es especialmente útil cuando el costo de establecer la conexión es alto, por ejemplo cuando se usa la red pública de teléfonos como canal de transmision.

La siguiente es un lista de los comandos del protocolo SMTP con sus parámetros y sintaxis correcta. Los códigos <SP> y <CRLF> significan un espacio en blanco y un retorno de carro, respectivamente.

A continuación se listan los comandos y las posibles respuestas para cada uno. Indicando si la respuesta se refiere a un éxito (S), fallo (F), intermedia (I) o a un error (E)

<Se establece la conexión >

Al implemetar el SMTP sobre los servicios de el TCP se debe establecer una conexión entre un puerto x en el emisor y el puerto 25 del receptor. El protocolo ya tiene asignado este puerto para las conexiones en TCP. De esta manera el SMTP está escuchando el puerto 25 y cuando la conexión está establecida envía la respuesta 220.

TCP soporta la transmisión de bytes de 8 bits, mientras que SMTP transmite caracteres de 7 bits, para hace transparente esta conversión el bit más significativo se establece en cero.

El protocolo de oficina postal fue diseñado para trabajar conjuntamente con el protocolo TCP, inicialmente el proceso está escuchando el puerto 110, a la espera de una conexión, cuando esta se establece el servidor envía un saludo y luego comienza un diálogo en el que se intercambian comandos y respuestas, hasta que la conexión se libera. El POP3 va cambiando entre 3 distintos estados a lo largo de su vida, dependiendo de los resultados de algunos comandos especiales. Los comandos POP3 consisten de 3 o 4 caracteres, con ninguno y algunos parámetros separados por un espacio en blanco. Cada comando finaliza con el par <CRLF>.

Las respuestas muestra el estado de el comando, puede ser positivo (+OK) y negativo (-ERR), y además ser seguido por algún tipo de información adicional. En las respuestas multi-línea cada línea enviada termina con el par <CRLF> y la última línea de la transmisión debe ir seguida de un punto "." y el par <CRLF>. Cualquier ocurrencia de esta secuencia en el texto de la respuesta generará un relleno de ese caracter del mismo modo que en el SMTP.

Los estados del POP3 son, Autorización en el que se entra cuando se establece la conexión TCP y sirve para que los usuarios se identifiquen ante el protocolo. Se entra en el estado de Transacción cuando se hace un identificación positiva del usuario que quiere ingresar, aquí los mensajes pasan del servidor a el cliente, un vez finalizado esto, se pasa al estado Actualización, donde elimina los mensajes que el usuario recibió, y así finaliza la conexión y se libera.

Una vez que se establece la conexión TCP el host servidor envía una respuesta positiva como una bienvenida. Por ejemplo

+OK POP3 server ready

Se entra así al modo de autorización; el usuario tiene dos maneras de identificarse con el juegos de comandos USER, PASS que especifican en nombre de usuario y su contraseña como parámetros respectivamente. Y con el comando APOP que envía ambos parámetros al mismo tiempo con la diferencia que la contraseña viaja encriptada mediante el algoritmo MD5. Resultaba demasiado peligroso tener viajando por la red el nombre de usuario y la contraseña sin ningún tipo de seguridad. Cualquiera de los dos métodos con una respuesta positiva hacen entrar al protocolo en el estado de transacción, previo un bloqueo del buzón, para asegurar la consistencia de los datos.

Al entrar en este estado se abre el buzón y se numera a cada mensaje con números decimales comenzando por el 1 y registrando el tamaño en bytes de cada uno. Ahora son posibles los comandos descriptos a continuación, no hay ni una cantidad ni una secuencia especifica para la ejecución de estos comandos, a excepción del comando QUIT que es el que finaliza el estado de transacción:

STAT : no posee argumentos y la respuesta es la cantidad de mensajes actuales en el buzón que no están marcados como eliminados y su tamaño en bytes.

LIST : tiene como parámetro opcional el número de mensaje. Sin parámetro hace que el servidor responda dando la lista de los mensajes no marcados como eliminados en el buzón, junto con el tamaño en bytes de cada uno de ellos. Si se da como parámetro un mensaje se muestra la información de ese mensaje en particular

RETR : tiene como parámetro obligatorio el número de mensaje. Y devuelve una respuesta multi-línea donde la primera indica, si el mensaje existe, el tamaño y a continuación envía el mensaje.

DELE : tiene como parámetro el número de mensaje. Este numero de mensaje es el que se va a marcar como eliminado.

RSET : No tiene parámetros y su acción es desmarcar los mensajes que fueron marcados para su eliminación durante esta transacción.

QUIT : Pasa al próximo estado.

El estado de actualización desaloja los mensajes marcados como eliminados en el estado de transacción, esto lo hará sólo si el cliente emite un comando QUIT en este estado en caso contrario los mensajes quedarán marcados como eliminados pero no desalojados de el almacenamiento. Además esta comando libera la conexión TCP e informa el estado actual del buzón.

El POP3 posee además un par de comandos especiales que no son necesarios para su operación básica. Estos comandos son:

TOP: requiere dos parámetros un identificador de mensaje y un número no negativo que indica la cantidad de líneas que se deben enviar de ese mensaje.

UIDL: tiene como parámetro opcional un número de mensaje, y devuelve el id único de el mensaje que se dio como parámetro, o el de todos los mensajes de el buzón. Este id único identifica unívocamente al mensaje dentro del servidor y es asignado por éste. Los mensajes marcados como eliminados no se listan.

Las extensiones MIME para el SMTP no hacen más que complementarlo para hacer más flexible su uso con tipos de datos no-ASCII, MIME especifica tres campos que se incluyen en la cabecera del mensaje, estos son MIME-Version, que especifica que versión del MIME se uso para codificar ese mensaje; el campo Content-Type que especifica el tipo y subtipo de los datos no-ASCII; y Content-Transfer-Encoding que especifica el tipo de codificación usado para traducir los datos en ASCII.

Los valores legales para el campo Content-Type son: Text, Image, Audio, Video, Application, Multipart y Message.

Los valores definidos para Content-Transfer-Encoding son: 7bit, 8bit, binary, quoted-printable, base64, itef-token, x-token.

Los tipos del campo contenido, casi hablan por si mismos a excepción de uno, el tipo multipart; que tiene 4 subtipos, mixed, alternative, parallel y digest. Este tipo significa que el mensaje contiene en sí mismo información de diferentes tipos o en distintos formatos. Cada una de las partes del mensaje se separa con un delimitador, que toma la forma de una cadena especificada en el campo Boudary que sigue al Content-Type. El subtipo Mixed indica que el mensaje encierra parte de distintos tipos, en cada comienzo de una nueva parte, después de la cadena delimitadora, debe especificarse el tipo y la codificación de la parte. El subtipo Alternative permite que el mismo mensaje se codifique usando distintos métodos, para asegurarse que el mensaje pueda ser leído por el programa del destinatario. El subtipo Parallel indica que las partes deben mostrarse juntas. Y por último el subtipo Digest indica que contiene un conjunto de mensaje, por ejemplo una discusión por e-mail.

RFC 1939 POP3 de J.Myers, C. Mellon, M.Rose. Dover Beach Consulting. Mayo 1996

RFC 821 SMTP de J. Postel. Information Sciences Institute. Agosto 1982

RFC 2045 MIME de N. Freed y N. Borenstien. Innosoft, First Virtual. Noviembre 1996

VICOMSOFT KNOWLEDSHARE. Junio 1998

REDES DE COMPUTADORAS. Andrew Tanenbaum. 1990

Bruno@Yifan.net