Correo Electrónico (e-mail)

INTRODUCCIÓN_____________________________________________________ 2

EL CORREO ELECTRÓNICO___________________________________________ 4

SMTP vs X.400_______________________________________________________ 6

EL POP_____________________________________________________________ 6

MIME______________________________________________________________ 7

SMTP (Simple Mail Transfer Protocol)_____________________________________ 8

Dirección de Correo___________________________________________________ 8

DNS________________________________________________________________________ 8

El Modelo SMTP_____________________________________________________ 8

Procedimientos SMTP_________________________________________________ 9

Establecimiento y Liberación de la conexión___________________________________________ 9

Transferencia de Mail___________________________________________________________ 9

Re-envio (Forwarding)__________________________________________________________ 11

Listas de Correo______________________________________________________________ 11

Casillas de correo y Terminales___________________________________________________ 12

Re-transmisión_______________________________________________________________ 12

Cambio de Roles______________________________________________________________ 13

Comando del SMTP____________________________________________________________ 14

Códigos de Respuestas del SMTP_________________________________________________ 14

Respuestas Posibles a los comandos del SMTP_______________________________________ 15

Servicio de Transporte__________________________________________________________ 16

El POP______________________________________________________________ 16

Estado de Autorización________________________________________________ 17

Estado De Transacción________________________________________________ 17

Estado de Actualización_______________________________________________ 18

Comandos Adicionales________________________________________________ 19

LAS MIME___________________________________________________________ 19

BIBLIOGRAFÍA CONSULTADA_______________________________________ 22

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 Bruno@Servidor.A se puede leer como “Bruno en Servidor.A”

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

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.

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

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>

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>

E: VRFY Smith

R: 251 User not local; will forward to <Smith@SIQ.ARPA>

E: VRFY Jones

R: 550 String does not match anything.

E: VRFY Jones

R: 551 User not local; please try <Jones@USC-ISIQ.ARPA>

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>

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: 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</