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. 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.
El siguiente paso en la expansión era conectar varias LAN para que intercambiaran los mensajes dirigidos a sus usuarios. 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 clientede 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 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.
SMTP vs X.400
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 factode 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.
EL POP
Estos protocolos funcionan adecuadamente cuando los destinatarios están permanentemente conectados a la INTERNET 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.
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.
MIME
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.
SMTP (Simple Mail Transfer Protocol)
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.
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.
DNS
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
El Modelo 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>
Procedimientos SMTP
Establecimiento y Liberación de la conexión 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
Transferencia de Mail
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
E: MAIL FROM:<Smith@Alpha.ARPA>
R: 250 OK
E: RCPT TO:<Jones@Beta.ARPA>
R: 250 OK
E: RCPT TO:<Green@Beta.ARPA>
R: 550 No such user here
E: RCPT TO:<Brown@Beta.ARPA>
R: 250 OK
E: DATA
R: 354 Start mail input; end with <CRLF>.<CRLF>
E: Blah blah blah...
E: ...etc. etc. etc.
E: <CRLF>.<CRLF>
R: 250 OK
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.
Re-envio (Forwarding)
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.
E: RCPT TO:Postel@USC-ISI.ARPA
R: 251 User not local; will forward to <Postel@USC-ISIF.ARPA>
O
E: RCPT TO:<Paul@USC-ISIB.ARPA>
R: 551 User not local; please try Mockapetris@USC-ISIF.ARPA
Listas de Correo
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.
E: VRFY Smith
R: 250 Fred Smith <Smith@USC-ISIF.ARPA>
O
E: VRFY Smith
R: 251 User not local; will forward to <Smith@SIQ.ARPA>
O
E: VRFY Jones
R: 550 String does not match anything.
O
E: VRFY Jones
R: 551 User not local; please try <Jones@USC-ISIQ.ARPA>
O
E: VRFY Jones
R: 553 User ambiguous.
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.
E: EXPN Lista_Gente
R: 250-Jon Postel <Postel@USC-ISIF.ARPA>
R: 250-Fred Fonebone <Fonebone@USC-ISIQ.ARPA>
R: 250-Sam Q. Smith <SQSmith@USC-ISIQ.ARPA>
R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA>
R: 250-<joe@foo-unix.ARPA>
R: 250 <xyz@bar-unix.ARPA>
O
E: EXPN Executive-Washroom-List
R: 550 Access Denied to You.
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.
Casillas de correo y Terminales
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.
Re-transmisión
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.
E: MAIL FROM:<>
R: 250 ok
E: RCPT TO:<@HOSTX.ARPA:JOE@HOSTW.ARPA>
R: 250 ok
E: DATA
R: 354 send the mail data, end with .
E: Date: 23 Oct 81 11:22:33
E: From: SMTP@HOSTY.ARPA
E: To: JOE@HOSTW.ARPA
E: Subject: Mail System Problem
E:
E: Sorry JOE, your message to SAM@HOSTZ.ARPA lost.
E: HOSTZ.ARPA said this:
E: "550 No Such User"
E: .
R: 250 ok
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.
Cambio de Roles
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.
Comando del SMTP
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.
HELO <SP> <dominio> <CRLF>
MAIL <SP> FROM:<camino-inverso> <CRLF>
RCPT <SP> TO:<camino-directo> <CRLF>
DATA <CRLF>
RSET <CRLF>
SEND <SP> FROM:<camino-inverso> <CRLF>
SOML <SP> FROM:<camino-inverso> <CRLF>
SAML <SP> FROM:<camino-inverso> <CRLF>
VRFY <SP> <cadena> <CRLF>
EXPN <SP> <cadena> <CRLF>
HELP [<SP> <cadena>] <CRLF>
NOOP <CRLF>
QUIT <CRLF>
TURN <CRLF>
Códigos de Respuestas del SMTP
211 System status, or system help reply
214 Help message
220 <domain> Service ready
221 <domain> Service closing transmission channel
250 Requested mail action okay, completed
251 User not local; will forward to <forward-path>
354 Start mail input; end with <CRLF>.<CRLF>
421 <domain> Service not available,
closing transmission channel
450 Requested mail action not taken: mailbox unavailable
[E.g., mailbox busy]
451 Requested action aborted: local error in processing
452 Requested action not taken: insufficient system storage
500 Syntax error, command unrecognized
[This may include errors such as command line too long]
501 Syntax error in parameters or arguments
502 Command not implemented
503 Bad sequence of commands
504 Command parameter not implemented
550 Requested action not taken: mailbox unavailable
[E.g., mailbox not found, no access]
551 User not local; please try <forward-path>
552 Requested mail action aborted: exceeded storage
553 Requested action not taken: mailbox name not allowed
554 Transaction failed
Respuestas Posibles a los comandos del SMTP
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 >
S: 220
F: 421
HELO
S: 250
E: 500, 501, 504, 421
MAIL
S: 250
F: 552, 451, 452
E: 500, 501, 421
RCPT
S: 250, 251
F: 550, 551, 552, 553, 450, 451, 452
E: 500, 501, 503, 421
DATA
I: 354 -> datos -> S: 250
F: 552, 554, 451, 452
F: 451, 554
E: 500, 501, 503, 421
RSET
S: 250
E: 500, 501, 504, 421
SEND
S: 250
F: 552, 451, 452
E: 500, 501, 502, 421
SOML
S: 250
F: 552, 451, 452
E: 500, 501, 502, 421
SAML
S: 250
F: 552, 451, 452
E: 500, 501, 502, 421
VRFY
S: 250, 251
F: 550, 551, 553
E: 500, 501, 502, 504, 421
EXPN
S: 250
F: 550
E: 500, 501, 502, 504, 421
HELP
S: 211, 214
E: 500, 501, 502, 504, 421
NOOP
S: 250
E: 500, 421
QUIT
S: 221
E: 500
TURN
S: 250
F: 502
E: 500, 503
Servicio de Transporte
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 POP
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.
Estado de Autorización
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.
Estado De Transacción
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.
C: STAT
S: +OK 2 320
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
C: LIST
S: +OK 2 messages (320 bytes)
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 maildrop
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.
C: RETR 1
S: +OK 120 Bytes
S: <El servidor POP3 envía todo el mensaje completo>
S: .
DELE : tiene como parámetro el número de mensaje. Este numero de mensaje es el que se va a marcar como eliminado.
C: DELE 1
S: +OK message 1 deleted
...
C: DELE 2
S: -ERR message 2 already deleted
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.
Estado de Actualización
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.
Comandos Adicionales
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.
C: TOP 1 10
S: +OK
S: <El POP3 envía las 10 primeras líneas del mensaje 1>
S: .
O
C: TOP 100 3
S: -ERR no such message
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 MIME
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.
MIME-Version: 1.0
From: Nathaniel Borenstein <>
To: Ned Freed <>
Subject: A multipart example
Content-Type: multipart/mixed;
boundary=unique-boundary-1
La primera parte llamada preámbulo debería ser ignorada por los productos que implementan la lectura de MIME.
--unique-boundary-1
...Este texto si aparece en el mensaje......
(el valor por omisión de tipo es text/plain y charset=US-ASCII)
--unique-boundary-1
Content-type: text/plain; charset=US-ASCII
.... este mensaje indica de forma explícita el tipo y el juego de caracteres que se usa .....
--unique-boundary-1
Content-Type: multipart/parallel;
boundary=unique-boundary-2
--unique-boundary-2
Content-Type: audio/basic
Content-Transfer-Encoding: base64
... Aquí va un base64-encoded 8000 Hz single-channel
mu-law-format audio ....
--unique-boundary-2
Content-Type: image/gif
Content-Transfer-Encoding: base64
... los datos de la imagen de base64-encoded van aquí....
--unique-boundary-2--
--unique-boundary-1
Content-type: text/richtext
Esto es <bold><italic>texto enriquecido.</italic></bold>
<smaller>definido pop la RFC 1341</smaller>
--unique-boundary-1
Content-Type: message/rfc822
From: (mailbox in US-ASCII)
To: (address in US-ASCII)
Subject: (subject in US-ASCII)
Content-Type: Text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: Quoted-printable
... el texto en ISO-8859-1 va aquí...
--unique-boundary-1--
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
. Asu vez, tenéis la posibilidad de utilizar los campos que aparecen debajo de el campo de destinatario, éstos son los denominados CC y CCO. Ambos sirven para enviar copias del mensaje a otros usuarios. El primero, es decir CC, permite enviar una copia a todas aquellas personas que estén incluidas en este campo, pero verán que no va dirigida a ellos sino a los destinatarios que se hayan incluido en el campo “Para”. El segundo, CCO, es parecido al anterior, la única diferencia es que este campo no es visible para aquellas personas que reciben el mensaje.
