SMTP se definió originalmente por dos documentos separados, RFC-821, que definió el protocolo de comunicación entre los servidores de envío y recepción, y RFC-822, que definió el formato del contenido. Las versiones actuales son RFC 5321 – Protocolo simple de transferencia de correo y RFC 5322 – Formato de mensaje de Internet. Se han seguido estándares adicionales, incluido RFC 2045: Extensiones de correo electrónico de Internet (MIME), primera parte: Formato de los cuerpos de mensajes de Internet y numerosos estándares relacionados. Explicar todo esto llevaría no solo un artículo muy largo, sino un libro.
En pocas palabras, sin embargo, el protocolo descrito en RFC 821 es esencialmente una conexión basada en texto, y de hecho puede usar un cliente telnet para emular el lado emisor. El lado emisor envía comandos y datos de texto, y el lado receptor envía códigos de respuesta para indicar que todo está bien o es un error. Una vez que se abre la conexión, un comando HELO o EHLO seguido de un comando MAIL FROM inicia la sesión. El comando RCPT TO especifica los destinatarios que el remitente solicita que el servidor receptor debe manejar. (El remitente puede haber “dividido” el mensaje y solo le pedirá al servidor receptor que entregue a un subconjunto de los destinatarios reales del mensaje). El comando DATOS indica al servidor receptor que espere que el mensaje siga. El mensaje se envía como líneas de texto. (Se requiere la codificación MIME para convertir cualquier otra cosa en una representación de texto). El mensaje finaliza mediante la transmisión de una línea que consta de un solo carácter de punto, seguido inmediatamente por dos líneas nuevas. El servidor receptor puede entregar el mensaje, o puede ser un relé que luego se convierte en el remitente en una conversación con uno o más servidores receptores. Cada servidor en el camino agregará un encabezado ‘Recibido’ al cuerpo del mensaje antes de la entrega o retransmisión, y en estricto cumplimiento de los estándares, ese es el único cambio que debe hacer en el mensaje. (En el mundo real de los antivirus y otras preocupaciones, este no es el caso).
El formato descrito en RFC 822 es una serie de líneas de encabezado, que consta de un nombre de encabezado, dos puntos y contenido de encabezado, seguido de una línea en blanco, seguida del cuerpo del mensaje. Hay una manera de crear encabezados largos “doblando” las líneas. Hay una manera de codificar caracteres no ASCII en los encabezados. Los encabezados de tipo de contenido y codificación de transferencia de contenido describen el formato del cuerpo del mensaje. El tipo puede ser texto sin formato, HTML, varios tipos de archivos y “multiparte”. Si el cuerpo consta de varias partes, habrá separadores y encabezados adicionales dentro del cuerpo, que describen el formato de cada parte. La codificación de transferencia de contenido describe cómo el remitente convierte los datos de caracteres binarios o no ASCII en texto y el receptor debe volver a convertirlos.
Hay una última cosa que quiero señalar sobre los protocolos. Puede pensar en RFC-821 como el sobre, y RFC-822 como la letra dentro de él. Además, debe pensar en el sobre como opaco. No es uno de esos sobres con una ventana para que se muestre la dirección impresa en la carta. Es un sobre opaco con la dirección impresa, es decir, el contenido de los datos del comando RCPT TO. Los encabezados son parte del contenido, por lo que los To, Cc y Bcc que puede ver dentro de su cliente de correo no forman parte del proceso de entrega. Los destinatarios enumerados en el comando RCPT TO pueden ser completamente diferentes de lo que ve en los encabezados. El encabezado From también puede ser completamente diferente de lo que se proporcionó en MAIL FROM durante la conversación SMTP RFC-821. Esta es la razón por la cual las mesas de ayuda reciben llamadas de personas que dicen “Recibí este mensaje de spam y ni siquiera me lo enviaron”, y es una gran parte de por qué la falsificación de direcciones de mensajes de correo electrónico es demasiado fácil.
