Monografias.com > Computación > Redes
Descargar Imprimir Comentar Ver trabajos relacionados

Correo electrónico (e-mail)




Enviado por bruno



    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 *

    El Modelo
    SMTP
    *

    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 CORREO
    ELECTRÓNICO

    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.

    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 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.

    EL POP

    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.

    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–

    BIBLIOGRAFÍA
    CONSULTADA

    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

    Bruno@Yifan.net

    Redes de
    Información

    Universidad
    Tecnológica Nacional

    Facultad Regional
    Mendoza

    Mayo de
    1999

    Nota al lector: es posible que esta página no contenga todos los componentes del trabajo original (pies de página, avanzadas formulas matemáticas, esquemas o tablas complejas, etc.). Recuerde que para ver el trabajo en su versión original completa, puede descargarlo desde el menú superior.

    Todos los documentos disponibles en este sitio expresan los puntos de vista de sus respectivos autores y no de Monografias.com. El objetivo de Monografias.com es poner el conocimiento a disposición de toda su comunidad. Queda bajo la responsabilidad de cada lector el eventual uso que se le de a esta información. Asimismo, es obligatoria la cita del autor del contenido y de Monografias.com como fuentes de información.

    Categorias
    Newsletter
    Comments
    All comments.
    Comments