Dr Smegman dice

Ningún administrador de servicios de correo es tal cosa si no sabe la secuencia SMTP para el envío de un puto email.

3 comentarios to “Dr Smegman dice”

  1. Todo en peluches, juguetes para Bebes, niños, rodados, en http://www.zonadejuguetes.cl
    @ Protocolo SMTP@

    Protocolo Simple de Transmisión de Correo (SMTP)
    El significado de las siglas de SMTP, como se señaló anteriormente, es Protocolo
    Simple de Transmisión de Correo (“Simple Mail Transfer Protocol”). Este protocolo
    es el estándar de Internet para el intercambio de correo electrónico. SMTP necesita
    que el sistema de transmisión ponga a su disposición un canal de comunicación fiable
    y con entrega ordenada de paquetes, con lo cual, el uso del protocolo TCP en la capa
    de transporte, es lo adecuado. Para que dos sistemas intercambien correo mediante el
    protocolo SMTP, no es necesario que exista una conexión interactiva, ya que este
    protocolo usa métodos de almacenamiento y reenvío de mensajes.
    Son tres los protocolos que se aplican a un correo de esta clase. El termino SMTP
    es frecuentemente y erróneamente usado para referirse a la combinación del grupo
    de protocolos involucrados en el envío de correo electrónico. Esto porque los tres
    están estrechamente relacionados, pero estrictamente hablando SMTP es uno de los
    tres protocolos. Los tres protocolos son:

    ·Un estándar para el intercambio de correo entre dos computadores (RFC 821),
    el cual especifica el protocolo usado para enviar correo entre “host” TCP/IP.
    Este estándar es SMTP.
    ·Un estándar del formato del mensaje de correo, contenido en dos RFC:

    -RFC 822 describe la sintaxis del campoo de título o cabecera del correo
    electrónico y describe la interpretación del grupo de campos de la cabecera.
    -RFC 1049 describe como un conjunto de otros tipos de documentos, que tengan
    texto ASCII, y que pueden ser usados en el cuerpo del correo electrónico.
    El nombre del protocolo oficial para este estándar es MAIL.

    ·Un estándar para el “routing” de “mail” usando el sistema de nombres de
    dominio, descrito en RFC 974. El nombre oficial del protocolo para este
    estándar es DNS-MX.

    Modo de Comunicación SMTP

    Cuando un servidor de SMTP, requiere transmitir un mensaje a otro servidor SMTP,
    el emisor (servidor que inicia la sesión SMTP) establece una conexión con el
    receptor (servidor que recibe petición de establecer sesión SMTP). Esta conexión
    es unidireccional, es decir, el emisor puede enviar correo al receptor, pero
    durante esa conexión, el receptor no puede enviar correo al emisor. Si el receptor
    tiene que enviar correo al emisor, tiene que esperar a que finalice la conexión
    establecida y establecer otra en sentido contrario, cambiando los papeles de emisor
    y receptor. Una vez establecida la conexión, el emisor envía comandos y mensajes.
    Los mensajes pueden tener como destino el receptor o un intermediario para llegar
    a un destino más lejano. El receptor puede enviar al emisor respuestas y códigos de
    estado. Los comandos son cadenas de caracteres que se pueden entender fácilmente y
    las respuestas son códigos numéricos seguidos de una explicación del código.
    Por lo señalado, SMTP (RFC 821) está basado en entrega “end-to-end”. Esto es
    diferente del principio guardar y enviar común en muchos sistemas de mensajería
    electrónica, donde el mensaje puede pasar a través de un numero de maquinas
    intermediarias su camino al destino final.
    Existen aplicaciones que permiten intercambiar correo entre el sistema de
    mensajería electrónica TCP/IP SMTP y el sistema de correo localmente usado.
    Estas aplicaciones son llamadas “Gateways” de correo (“Gateways”) o “Bridges”
    de correo. Enviar correo a través de un “Gateway” puede alterar la entrega
    “end-to-end”. El protocolo SMTP solo puede garantizar la entrega al “Gateway”
    y no al destino final que está localizado más allá de la red TCP/IP. Cuando el
    “Gateway” es usado, la transmisión SMTP “end-to-end” se realiza en varias partes,
    de “host” a “Gateway”, “Gateway” a “host” o “Gateway” a “Gateway”. El comportamiento
    más allá del “Gateway” no está especificado por SMTP. En la Fig. 2-1 se observa
    la comunicación a través de los “Gateways”.
    SMTP se basa en el modelo de comunicación que se muestra en la Fig. 2-2.

    En este modelo de comunicación en primera instancia un usuario establece la
    petición de enviar un mensaje a través de correo electrónico, luego el Emisor
    SMTP establece una conexión de dos hilos con el Receptor SMTP. El Receptor
    SMTP puede ser la destinación última o un intermediario, como es el caso del
    “Gateway”. El Emisor SMTP genera comandos que son contestados por el Receptor SMTP.

    Flujo de Transferencia de los Mensajes de Correo Electrónico

    Aunque los comandos y respuestas son estrictamente definidos por el protocolo,
    el intercambio de ellos entre emisor y receptor resultar fácil de comprender,
    como se muestra en la Fig. 2-3a y la Fig. 2-3b.
    Todo intercambio de comandos/respuesta/datos (líneas de texto) son delimitados
    por un CRLF, los que no se incluyen en las Fig. 2-3a y Fig. 2-3b para facilitar
    la compresión del protocolo SMTP. Toda respuesta tiene un código numérico al
    principio de la línea.

    El ejemplo de trasferencia se detalla a continuación:

    ·El Emisor SMTP establece una conexión TCP con el destino SMTP y luego
    espera que el servidor envíe un 220 Servicio de lectura de mensaje o un 421
    Servicio de mensaje no habilitado, esto ultimo, cuando la destinación está
    temporalmente inhabilitada para procesar el mensaje.
    ·HELO (Es una abreviación de “hello”) es enviado para que el receptor identifique
    si el Emisor SMTP está enviando su nombre de dominio. El Emisor SMTP puede usarlo
    para verificar si contactó la destinación SMTP correcta. Si el Emisor SMTP soporta
    Extensión de Servicios (“Service Extensions”) SMTP, como está definido en RFC 1651
    (Extensión de Servicios es explicada en detalle en la subseccion 2.1.4), puede
    sustituir por un comando EHELO el comando HELO. El Receptor SMTP que no soporta
    Extensión de Servicios, responde con una sintaxis de error 500, que es un comando
    de mensaje no reconocido. El Emisor SMTP debe entonces reintentar con HELO, o si
    el emisor no puede transmitir el mensaje sin uno o más de los comandos que son
    propios de Extensión de Servicios, éste debe enviar un mensaje QUIT.
    ·Si el Receptor SMTP soporta Extensión de Servicios, responde con un mensaje
    multilínea 250 OK, que incluye una lista de extensión de servicios que soporta.
    ·El Emisor SMTP, luego de recibir este comando 250 OK, inicializa la transferencia
    del mensaje enviando el comando MAIL al Receptor SMTP. Este comando contiene el
    “reverse-path” (habitualmente se utiliza para el envío del nombre de dominio del
    emisor) que puede ser usado para reportar errores. Esta ” reverse-path” puede contener
    más que solamente el nombre de dominio de usuario (del emisor), en adición, éste
    puede contener una lista de “host” de la ruta. Ejemplo de esto es cuando se pasa
    por un “Bridge” o cuando se provee explícitamente información de la ruta en la
    dirección de destino. Si el Receptor SMTP acepta responde con un 250 OK.
    ·El segundo paso del intercambio de mensajes a través de correo electrónico, consiste
    en proveer al servidor SMTP la destinación para el mensaje. Se realiza enviando uno
    o más comandos RCPT TO:forward-path. Cada uno de estos envíos es contestado por
    parte del Receptor SMTP con un 250 OK, si la destinación es conocida por el servidor,
    o un 550 NO, si tal usuario no es conocido.
    ·Cuando todos los comandos RCPT son enviados, el Emisor SMTP emite un comando
    DATA para notificar al Receptor SMTP que el contenido del mensaje será el siguiente
    envío. El Receptor SMTP responde con 354 Start mail input, end with CRLF CRLF.
    Esta secuencia final es la que el Emisor SMTP utiliza cuando termina el envío de
    datos del mensaje a transferir.
    ·El cliente ahora envía las líneas de datos, una a una, finalizando con la secuencia
    CRLF.CRLF, secuencia que el Receptor SMTP responde con un 250 OK o un mensaje de
    error si es que algo ha fallado.
    ·Luego se tienen algunas opciones:

    -El Emisor SMTP no tiene más mensajes qque enviar, por lo que se finaliza la
    conexión con un comando QUIT, a lo cual el Receptor SMTP responde con 221 Service
    closing transmission channel.
    -Si el Emisor SMTP no tiene más mensajees que enviar, pero quiere recibir mensajes
    del otro extremo. Este envía el comando TURN. Los dos extremos de la comunicación
    SMTP ahora cambian roles de Emisor/Receptor y el nuevo Emisor SMTP (Anterior
    Receptor SMTP) puede enviar mensajes partiendo del paso 3 del esquema mostrado
    en la Fig. 2-3a.
    -Si el Emisor SMTP tiene otro mensaje ppara enviar retorna al paso 3 y envía un
    comando MAIL.

  2. Hombre tostadas en polvo Says:

    conchisumá

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: