El e-mail uno de los servicios de
la internet
más populares. Este trabajo describe desde los elementos
necesarios para las comunicaciones, hasta las especificaciones para la
extensiones del protocolo SMTP.
Pasando por una breve reseña de los protocolos que lo
hacen posible, el POP3, el SMTP, las MIME y el X.400.
INTRODUCCIÓN *
EL CORREO
ELECTRÓNICO
SMTP vs X.400 *
EL POP *
MIME *
SMTP (Simple Mail Transfer
Protocol) *
Dirección de Correo *
DNS *
Procedimientos SMTP *
Establecimiento y Liberación de la
conexión *
Transferencia de Mail *
Re-envio (Forwarding) *
Listas de Correo *
Casillas de correo y Terminales *
Re-transmisión *
Cambio de Roles *
Comando del SMTP *
Códigos de Respuestas del SMTP *
Respuestas Posibles a los comandos del
SMTP *
Servicio de Transporte *
El POP *
Estado de Autorización *
Estado De Transacción *
Estado de Actualización *
Comandos Adicionales *
LAS MIME *
BIBLIOGRAFÍA
CONSULTADA *
INTRODUCCIÓN
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
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.
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.
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
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>
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
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.
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>
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.
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.
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.
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
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
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.
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.
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.
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 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
Bruno Aguirre
Redes de
Información
Universidad
Tecnológica Nacional
Facultad Regional
Mendoza
Mayo de
1999