Protocolo simple de transferencia de correo

El Protocolo simple de transferencia de correo ( SMTP ) es un protocolo de comunicación estándar de Internet para la transmisión de correo electrónico . Los servidores de correo y otros agentes de transferencia de mensajes utilizan SMTP para enviar y recibir mensajes de correo. Los clientes de correo electrónico de nivel de usuario normalmente utilizan SMTP solo para enviar mensajes a un servidor de correo para su retransmisión, y normalmente envían el correo electrónico saliente al servidor de correo en el puerto 587 o 465 según RFC  8314. Para recuperar mensajes, IMAP (que sustituyó al antiguo POP3 ) es estándar, pero los servidores propietarios también suelen implementar protocolos propietarios, por ejemplo, Exchange ActiveSync .

Los orígenes del protocolo SMTP se remontan a 1980, basándose en conceptos implementados en ARPANET desde 1971. Se ha actualizado, modificado y ampliado en múltiples ocasiones. La versión del protocolo de uso común en la actualidad tiene una estructura extensible con varias extensiones para autenticación , cifrado , transferencia de datos binarios y direcciones de correo electrónico internacionalizadas . Los servidores SMTP suelen utilizar el Protocolo de control de transmisión en los puertos 25 (entre servidores) y 587 (para envíos desde clientes autenticados), tanto con cifrado como sin él.

En la década de 1960 se utilizaron diversas formas de mensajería electrónica uno a uno . Los usuarios se comunicaban mediante sistemas desarrollados para computadoras centrales específicas . A medida que se interconectaban más computadoras, especialmente en ARPANET del gobierno de los EE. UU ., se desarrollaron estándares para permitir el intercambio de mensajes entre diferentes sistemas operativos.

El correo en ARPANET tiene sus orígenes en 1971: el Protocolo de Buzón de Correo, que no se implementó, ^[1] pero se analiza en el RFC  196; y el programa SNDMSG , que Ray Tomlinson de BBN adaptó ese año para enviar mensajes a través de dos computadoras en ARPANET. ^{[2] [3] [4]} Se realizó otra propuesta para un Protocolo de Correo en el RFC 524 en junio de 1973, ^[5] que no se implementó. ^[6]

El uso del Protocolo de Transferencia de Archivos (FTP) para el "correo en red" en ARPANET fue propuesto en el RFC 469 en marzo de 1973. ^[7] A través del RFC 561, RFC 680, RFC 724 y finalmente RFC 733 en noviembre de 1977, se desarrolló un marco estandarizado para el "correo electrónico" utilizando servidores de correo FTP. ^{[8] [9]}

El SMTP surgió de estos estándares desarrollados durante la década de 1970. Ray Tomlinson analizó el correo en red en el marco del Grupo de Trabajo de Redes Internacionales en la nota 2 del Protocolo del INWG , escrita en septiembre de 1974. ^[10] El INWG analizó los protocolos para el correo electrónico en 1979, ^{[11] a lo que} Jon Postel hizo referencia en su trabajo inicial sobre el correo electrónico en Internet. Postel propuso por primera vez un Protocolo de Mensajes de Internet en 1979 como parte de la serie de Notas Experimentales de Internet (IEN). ^{[12] [13] [14]}

En 1980, Postel y Suzanne Sluizer publicaron el RFC  772, que proponía el Protocolo de Transferencia de Correo como reemplazo del uso del FTP para el correo. El RFC  780 de mayo de 1981 eliminó todas las referencias al FTP y asignó el puerto 57 para TCP y UDP , ^{[ cita requerida ]} una asignación que desde entonces ha sido eliminada por la IANA . En noviembre de 1981, Postel publicó el RFC  788 "Simple Mail Transfer Protocol".

El estándar SMTP se desarrolló casi al mismo tiempo que Usenet , una red de comunicación de uno a muchos con algunas similitudes. ^{[ cita requerida ]}

El SMTP se empezó a utilizar ampliamente a principios de los años 80. En aquel momento, era un complemento del Unix to Unix Copy Program (UUCP), que era más adecuado para gestionar transferencias de correo electrónico entre máquinas que estaban conectadas de forma intermitente. El SMTP, por otra parte, funciona mejor cuando tanto la máquina emisora ​​como la receptora están conectadas a la red todo el tiempo. Ambos utilizaban un mecanismo de almacenamiento y reenvío y son ejemplos de tecnología push . Aunque los grupos de noticias de Usenet todavía se propagaban con UUCP entre servidores, ^[15] el UUCP como transporte de correo prácticamente ha desaparecido ^[16] junto con las " rutas bang " que utilizaba como encabezados de enrutamiento de mensajes. ^[17]

Sendmail , lanzado con 4.1cBSD en 1983, fue uno de los primeros agentes de transferencia de correo en implementar SMTP. ^{[18] Con el tiempo, a medida que BSD Unix se convirtió en el sistema operativo más popular en Internet, Sendmail se convirtió en el} MTA (agente de transferencia de correo) más común . ^[19]

El protocolo SMTP original sólo admitía comunicaciones de texto ASCII de 7 bits no autenticadas y sin cifrar, susceptibles a ataques triviales de intermediarios , suplantación de identidad y envío de correo basura , y que requerían que todos los datos binarios se codificaran en texto legible antes de la transmisión. Debido a la ausencia de un mecanismo de autenticación adecuado, por diseño cada servidor SMTP era un relé de correo abierto . El Consorcio de Correo de Internet (IMC) informó que el 55% de los servidores de correo eran relés abiertos en 1998, ^[20] pero menos del 1% en 2002. ^[21] Debido a las preocupaciones por el correo basura, la mayoría de los proveedores de correo electrónico bloquean los relés abiertos, ^[22] lo que hace que el SMTP original sea esencialmente impráctico para el uso general en Internet.

En noviembre de 1995, la RFC  1869 definió el Protocolo simple de transferencia de correo extendido (ESMTP), que establecía una estructura general para todas las extensiones existentes y futuras que apuntaban a agregar las características que faltaban en el SMTP original. ESMTP define medios consistentes y manejables por los cuales se pueden identificar los clientes y servidores ESMTP y los servidores pueden indicar las extensiones compatibles.

El envío de mensajes ( RFC  2476) y SMTP-AUTH ( RFC  2554) se introdujeron en 1998 y 1999, ambos describiendo nuevas tendencias en la entrega de correo electrónico. Originalmente, los servidores SMTP eran típicamente internos a una organización, recibiendo correo para la organización desde el exterior y retransmitiendo mensajes de la organización al exterior . Pero a medida que pasó el tiempo, los servidores SMTP (agentes de transferencia de correo), en la práctica, expandieron sus funciones para convertirse en agentes de envío de mensajes para agentes de usuario de correo , algunos de los cuales ahora retransmitían correo desde el exterior de una organización. (por ejemplo, un ejecutivo de la empresa desea enviar un correo electrónico mientras está de viaje utilizando el servidor SMTP corporativo). Este problema, una consecuencia de la rápida expansión y popularidad de la World Wide Web , significó que SMTP tuvo que incluir reglas y métodos específicos para retransmitir correo y autenticar usuarios para evitar abusos como la retransmisión de correo electrónico no solicitado ( spam ). El trabajo sobre el envío de mensajes ( RFC  2476) se inició originalmente porque los servidores de correo populares solían reescribir el correo en un intento de solucionar problemas en él, por ejemplo, añadiendo un nombre de dominio a una dirección no calificada. Este comportamiento es útil cuando el mensaje que se está reparando es un envío inicial, pero peligroso y dañino cuando el mensaje se originó en otro lugar y se está retransmitiendo. Separar claramente el correo en envío y retransmisión se consideró una forma de permitir y fomentar la reescritura de los envíos y prohibir la reescritura de la retransmisión. A medida que el spam se hizo más frecuente, también se consideró una forma de proporcionar autorización para el envío de correo desde una organización, así como trazabilidad. Esta separación de retransmisión y envío se convirtió rápidamente en una base para las prácticas de seguridad del correo electrónico modernas.

Como este protocolo comenzó siendo puramente basado en texto ASCII , no se manejaba bien con archivos binarios o caracteres en muchos idiomas distintos del inglés. Se desarrollaron estándares como Multipurpose Internet Mail Extensions ( MIME ) para codificar archivos binarios para su transferencia a través de SMTP. Los agentes de transferencia de correo (MTA) desarrollados después de Sendmail también tendían a implementarse en 8 bits limpios , de modo que la estrategia alternativa de "solo enviar ocho" pudiera usarse para transmitir datos de texto arbitrarios (en cualquier codificación de caracteres de 8 bits similar a ASCII) a través de SMTP. Mojibake seguía siendo un problema debido a las diferentes asignaciones de conjuntos de caracteres entre proveedores, aunque las propias direcciones de correo electrónico todavía permitían solo ASCII . Los MTA limpios de 8 bits actuales tienden a admitir la extensión 8BITMIME, lo que permite que algunos archivos binarios se transmitan casi tan fácilmente como texto sin formato (aún se aplican límites en la longitud de línea y los valores de octetos permitidos, de modo que la codificación MIME es necesaria para la mayoría de los datos que no son texto y algunos formatos de texto). En 2012, SMTPUTF8se creó la extensión para admitir texto UTF-8 , lo que permite contenido internacional y direcciones en alfabetos no latinos, como el cirílico o el chino .

Muchas personas contribuyeron a las especificaciones básicas de SMTP, entre ellas Jon Postel , Eric Allman , Dave Crocker, Ned Freed , Randall Gellens, John Klensin y Keith Moore .

El correo electrónico se envía mediante un cliente de correo ( agente de usuario de correo , MUA) a un servidor de correo ( agente de envío de correo , MSA) mediante SMTP en el puerto TCP 587. La mayoría de los proveedores de buzones de correo aún permiten el envío en el puerto tradicional 25. El MSA entrega el correo a su agente de transferencia de correo (MTA). A menudo, estos dos agentes son instancias del mismo software lanzado con diferentes opciones en la misma máquina. El procesamiento local se puede realizar en una sola máquina o dividirse entre varias máquinas; los procesos del agente de correo en una máquina pueden compartir archivos, pero si el procesamiento se realiza en varias máquinas, transfieren mensajes entre sí mediante SMTP, donde cada máquina está configurada para usar la siguiente máquina como un host inteligente . Cada proceso es un MTA (un servidor SMTP) por derecho propio.

El MTA de límite utiliza DNS para buscar el registro MX (intercambiador de correo) del dominio del destinatario (la parte de la dirección de correo electrónico a la derecha de @). El registro MX contiene el nombre del MTA de destino. En función del host de destino y otros factores, el MTA de envío selecciona un servidor de destinatario y se conecta a él para completar el intercambio de correo.

La transferencia de mensajes puede ocurrir en una única conexión entre dos MTA o en una serie de saltos a través de sistemas intermediarios. Un servidor SMTP receptor puede ser el destino final, un "relé" intermedio (es decir, que almacena y reenvía el mensaje) o una "puerta de enlace" (es decir, que puede reenviar el mensaje utilizando algún protocolo distinto de SMTP). Según la sección 2.1 de RFC  5321, cada salto es una transferencia formal de responsabilidad por el mensaje, por la cual el servidor receptor debe entregar el mensaje o informar adecuadamente de la falla en la entrega.

Una vez que el último salto acepta el mensaje entrante, lo entrega a un agente de entrega de correo (MDA) para su entrega local. Un MDA guarda los mensajes en el formato de buzón correspondiente . Al igual que con el envío, esta recepción se puede realizar utilizando una o varias computadoras, pero en el diagrama anterior el MDA se representa como un cuadro cerca del cuadro de intercambio de correo. Un MDA puede entregar mensajes directamente al almacenamiento o reenviarlos a través de una red utilizando SMTP u otro protocolo como el Protocolo de transferencia de correo local (LMTP), un derivado de SMTP diseñado para este propósito.

Una vez entregado al servidor de correo local, el correo se almacena para su recuperación por lotes por parte de clientes de correo autenticados (MUA). El correo se recupera por parte de aplicaciones de usuario final, llamadas clientes de correo electrónico, mediante el Protocolo de acceso a mensajes de Internet (IMAP), un protocolo que facilita el acceso al correo y administra el correo almacenado, o el Protocolo de oficina postal (POP), que normalmente utiliza el formato de archivo de correo mbox tradicional o un sistema propietario como Microsoft Exchange/Outlook o Lotus Notes / Domino . Los clientes de correo web pueden utilizar cualquiera de los dos métodos, pero el protocolo de recuperación a menudo no es un estándar formal.

SMTP define el transporte del mensaje , no el contenido del mismo . Por lo tanto, define el sobre del correo y sus parámetros, como el remitente del sobre , pero no el encabezado (excepto la información de seguimiento ) ni el cuerpo del mensaje en sí. STD 10 y RFC  5321 definen SMTP (el sobre), mientras que STD 11 y RFC  5322 definen el mensaje (encabezado y cuerpo), formalmente denominado Formato de Mensaje de Internet .

SMTP es un protocolo basado en texto y orientado a la conexión en el que un remitente de correo se comunica con un receptor de correo mediante la emisión de cadenas de comandos y el suministro de los datos necesarios a través de un canal de flujo de datos ordenado y fiable, normalmente una conexión de Protocolo de control de transmisión (TCP). Una sesión SMTP consta de comandos originados por un cliente SMTP (el agente iniciador , remitente o transmisor) y las respuestas correspondientes del servidor SMTP (el agente de escucha o receptor) de modo que se abre la sesión y se intercambian los parámetros de la sesión. Una sesión puede incluir cero o más transacciones SMTP. Una transacción SMTP consta de tres secuencias de comando/respuesta:

1. Comando MAIL , para establecer la dirección de retorno, también llamada ruta de retorno, ^[23] ruta inversa, ^[24] dirección de rebote , mfrom o remitente del sobre.
2. Comando RCPT , para establecer un destinatario del mensaje. Este comando puede emitirse varias veces, una para cada destinatario. Estas direcciones también forman parte del sobre.
3. DATA indica el comienzo del texto del mensaje , el contenido del mensaje, en contraposición a su envoltura. Consiste en un encabezado y un cuerpo del mensaje separados por una línea vacía. DATA es en realidad un grupo de comandos y el servidor responde dos veces: una al comando DATA en sí, para confirmar que está listo para recibir el texto, y la segunda vez después de la secuencia de fin de datos, para aceptar o rechazar el mensaje completo.

Además de la respuesta intermedia para DATOS, la respuesta de cada servidor puede ser positiva (códigos de respuesta 2xx) o negativa. Las respuestas negativas pueden ser permanentes (códigos 5xx) o transitorias (códigos 4xx). Un rechazo es una falla permanente y el cliente debe enviar un mensaje de rebote al servidor del que lo recibió. Un descarte es una respuesta positiva seguida del descarte del mensaje en lugar de su entrega.

El host de inicio, el cliente SMTP, puede ser un cliente de correo electrónico de un usuario final , identificado funcionalmente como un agente de usuario de correo (MUA), o un agente de transferencia de correo (MTA) de un servidor de retransmisión, es decir, un servidor SMTP que actúa como un cliente SMTP, en la sesión relevante, para retransmitir correo. Los servidores SMTP totalmente capaces mantienen colas de mensajes para volver a intentar la transmisión de mensajes que resultaron en fallas transitorias.

Un MUA conoce el servidor SMTP de correo saliente a partir de su configuración. Un servidor de retransmisión normalmente determina a qué servidor conectarse buscando el registro de recursos DNS MX (Mail eXchange) para el nombre de dominio de cada destinatario . Si no se encuentra ningún registro MX, un servidor de retransmisión compatible (no todos lo son) busca en su lugar el registro A. Los servidores de retransmisión también se pueden configurar para utilizar un host inteligente . Un servidor de retransmisión inicia una conexión TCP con el servidor en el " puerto conocido " para SMTP: puerto 25, o para conectarse a un MSA, puerto 587. La principal diferencia entre un MTA y un MSA es que la conexión a un MSA requiere autenticación SMTP .

SMTP es un protocolo de entrega únicamente. En uso normal, el correo se "envía" a un servidor de correo de destino (o servidor de correo de siguiente salto) a medida que llega. El correo se enruta en función del servidor de destino, no de los usuarios individuales a los que está dirigido. Otros protocolos, como el Protocolo de oficina postal (POP) y el Protocolo de acceso a mensajes de Internet (IMAP), están diseñados específicamente para que los utilicen usuarios individuales que recuperan mensajes y administran buzones de correo . Para permitir que un servidor de correo conectado de forma intermitente extraiga mensajes de un servidor remoto a pedido, SMTP tiene una función para iniciar el procesamiento de la cola de correo en un servidor remoto (consulte Inicio de la cola de mensajes remota a continuación). POP e IMAP son protocolos inadecuados para la retransmisión de correo por parte de máquinas conectadas de forma intermitente; están diseñados para funcionar después de la entrega final, cuando se ha eliminado la información crítica para el funcionamiento correcto de la retransmisión de correo (el "sobre de correo").

El inicio remoto de la cola de mensajes permite que un host remoto comience a procesar la cola de correo en un servidor para que pueda recibir mensajes destinados a él mediante el envío de un comando correspondiente. El TURNcomando original se consideró inseguro y se amplió en RFC  1985 con el comando que funciona de forma más segura utilizando un método de autenticación basado en la información del sistema de nombres de dominio . ^[25]ETRN

Un cliente de correo electrónico necesita conocer la dirección IP de su servidor SMTP inicial y esta debe proporcionarse como parte de su configuración (normalmente se proporciona como un nombre DNS ). Este servidor entregará los mensajes salientes en nombre del usuario.

Los administradores de servidores deben imponer cierto control sobre qué clientes pueden utilizar el servidor. Esto les permite lidiar con el abuso, por ejemplo, el correo basura . Se han utilizado dos soluciones comunes:

• En el pasado, muchos sistemas imponían restricciones de uso según la ubicación del cliente, y solo permitían el uso a clientes cuya dirección IP estuviera controlada por los administradores del servidor. No se permitía el uso desde ninguna otra dirección IP del cliente.
• Los servidores SMTP modernos generalmente ofrecen un sistema alternativo que requiere la autenticación de los clientes mediante credenciales antes de permitir el acceso.

En este sistema, el servidor SMTP de un ISP no permitirá el acceso a usuarios que se encuentren fuera de la red del ISP. Más precisamente, el servidor sólo puede permitir el acceso a usuarios con una dirección IP proporcionada por el ISP, lo que equivale a exigirles que estén conectados a Internet utilizando el mismo ISP. Un usuario móvil puede estar a menudo en una red distinta a la de su ISP habitual y, en ese caso, descubrirá que el envío de correo electrónico falla porque la opción de servidor SMTP configurada ya no es accesible.

Este sistema tiene varias variantes. Por ejemplo, el servidor SMTP de una organización puede proporcionar servicio únicamente a los usuarios de la misma red, y para ello utiliza un cortafuegos que bloquea el acceso a los usuarios de Internet. O el servidor puede realizar comprobaciones de rango en la dirección IP del cliente. Estos métodos solían ser utilizados por corporaciones e instituciones como universidades, que proporcionaban un servidor SMTP para el correo saliente únicamente para uso interno dentro de la organización. Sin embargo, la mayoría de estos organismos utilizan ahora métodos de autenticación de clientes, como se describe a continuación.

Cuando un usuario es móvil y puede utilizar distintos ISP para conectarse a Internet, este tipo de restricción de uso resulta onerosa y modificar la dirección del servidor SMTP de correo electrónico saliente configurado resulta poco práctico. Es muy conveniente poder utilizar información de configuración del cliente de correo electrónico que no necesite modificarse.

Los servidores SMTP modernos suelen requerir la autenticación de los clientes mediante credenciales antes de permitir el acceso, en lugar de restringir el acceso por ubicación, como se describió anteriormente. Este sistema más flexible es amigable para los usuarios móviles y les permite tener una opción fija de servidor SMTP saliente configurado. La autenticación SMTP , a menudo abreviada como SMTP AUTH, es una extensión del SMTP para iniciar sesión mediante un mecanismo de autenticación.

La comunicación entre servidores de correo generalmente utiliza el puerto TCP estándar 25 designado para SMTP.

Sin embargo, los clientes de correo generalmente no utilizan esto, sino que utilizan puertos de "envío" específicos. Los servicios de correo generalmente aceptan el envío de correo electrónico de los clientes en uno de los siguientes:

• 587 (Presentación), tal como se formaliza en RFC  6409 (anteriormente RFC  2476)
• 465 Este puerto quedó obsoleto después de RFC  2487, hasta la emisión de RFC  8314.

El puerto 2525 y otros pueden ser utilizados por algunos proveedores individuales, pero nunca han recibido soporte oficial.

Muchos proveedores de servicios de Internet bloquean ahora todo el tráfico saliente del puerto 25 de sus clientes. Principalmente como medida antispam, ^[26] pero también para compensar el mayor coste que supone dejarlo abierto, tal vez cobrando más a los pocos clientes que lo requieran.

En el siguiente intercambio de sesiones se reproduce un ejemplo típico de envío de un mensaje por SMTP a dos buzones de correo ( alice y theboss ) ubicados en el mismo dominio de correo ( example.com ). (En este ejemplo, las partes de la conversación tienen como prefijo S: y C: , para server y client , respectivamente; estas etiquetas no forman parte del intercambio).

Una vez que el remitente del mensaje (cliente SMTP) establece un canal de comunicación confiable con el receptor del mensaje (servidor SMTP), la sesión se abre con un saludo del servidor, que generalmente contiene su nombre de dominio completo (FQDN), en este caso smtp.example.com . El cliente inicia su diálogo respondiendo con un HELOcomando que se identifica en el parámetro del comando con su FQDN (o un literal de dirección si no hay ninguno disponible). ^[27]

S:  220 smtp.example.com ESMTP Postfix C: HELO relay.example.org S:  250 Hola relay.example.org, me alegro de conocerte C: MAIL FROM:<[email protected]> S:  250 Ok C: RCPT TO:<[email protected]> S:  250 Ok C: RCPT TO:<[email protected]> S:  250 Ok C: DATA S:  354 Finalizar datos con <CR><LF>.<CR><LF> C:  C: C : C: C : C: C: C: Hola Alice. C: Este es un mensaje de prueba con 5 campos de encabezado y 4 líneas en el cuerpo del mensaje. C: Tu amigo, C: Bob C: . S: 250 Ok: en cola como 12345 C: QUIT S: 221 Adiós {El servidor cierra la conexión}From: "Bob Example" <[email protected]> To: "Alice Example" <[email protected]> Cc: [email protected] Date: Tue, 15 Jan 2008 16:02:43 -0500 Subject: Test message  

El cliente notifica al receptor la dirección de correo electrónico de origen del mensaje mediante un MAIL FROMcomando. Esta es también la dirección de retorno o rebote en caso de que el mensaje no pueda ser entregado. En este ejemplo, el mensaje de correo electrónico se envía a dos buzones de correo en el mismo servidor SMTP: uno para cada destinatario que aparece en los campos de encabezado To:y Cc:. El comando SMTP correspondiente es RCPT TO. Cada recepción y ejecución exitosa de un comando es reconocida por el servidor con un código de resultado y un mensaje de respuesta (por ejemplo, 250 Ok).

La transmisión del cuerpo del mensaje de correo se inicia con un DATAcomando, después del cual se transmite textualmente línea por línea y se termina con una secuencia de fin de datos. Esta secuencia consta de una nueva línea ( <CR><LF>), un único punto ( .), seguido de otra nueva línea ( <CR><LF>). Dado que el cuerpo de un mensaje puede contener una línea con sólo un punto como parte del texto, el cliente envía dos puntos cada vez que una línea comienza con un punto; correspondientemente, el servidor reemplaza cada secuencia de dos puntos al comienzo de una línea con uno solo. Este método de escape se llama relleno de puntos .

La respuesta positiva del servidor al final de los datos, como se ejemplifica, implica que el servidor ha asumido la responsabilidad de entregar el mensaje. Un mensaje puede duplicarse si hay una falla de comunicación en este momento, por ejemplo debido a un corte de energía: hasta que el remitente haya recibido esa 250 Okrespuesta, debe asumir que el mensaje no se entregó. Por otro lado, después de que el receptor haya decidido aceptar el mensaje, debe asumir que el mensaje se le ha entregado. Por lo tanto, durante este lapso de tiempo, ambos agentes tienen copias activas del mensaje que intentarán entregar. ^[28] La probabilidad de que ocurra una falla de comunicación exactamente en este paso es directamente proporcional a la cantidad de filtrado que realiza el servidor en el cuerpo del mensaje, la mayoría de las veces con fines antispam. El tiempo de espera límite se especifica en 10 minutos. ^[29]

El QUITcomando finaliza la sesión. Si el correo electrónico tiene otros destinatarios ubicados en otro lugar, el cliente se QUITconectaría a un servidor SMTP adecuado para los destinatarios posteriores después de que se hayan puesto en cola los destinos actuales. La información que el cliente envía en los comandos HELOy MAIL FROMse agrega (no se ve en el código de ejemplo) como campos de encabezado adicionales al mensaje por parte del servidor receptor. Agrega un campo de encabezado Receivedy , respectivamente.Return-Path

Algunos clientes están implementados para cerrar la conexión después de aceptar el mensaje ( 250 Ok: queued as 12345), por lo que las dos últimas líneas pueden omitirse. Esto provoca un error en el servidor al intentar enviar la 221 Byerespuesta.

Los clientes aprenden las opciones admitidas por un servidor mediante el EHLOsaludo, como se ejemplifica a continuación, en lugar del original HELO. Los clientes recurren a HELOsolo si el servidor no admite EHLOel saludo. ^[30]

Los clientes modernos pueden utilizar la palabra clave de extensión ESMTP SIZEpara consultar al servidor cuál es el tamaño máximo de mensaje que se aceptará. Los clientes y servidores más antiguos pueden intentar transferir mensajes de tamaño excesivo que serán rechazados después de consumir recursos de red, incluido el tiempo de conexión a enlaces de red que se paga por minuto. ^[31]

Los usuarios pueden determinar manualmente de antemano el tamaño máximo aceptado por los servidores ESMTP. El cliente reemplaza el HELOcomando por el EHLOcomando.

S:  220 smtp2.example.com Postfijo ESMTP C: EHLO bob.example.org S:  250-smtp2.example.com Hola bob.example.org [192.0.2.201] S:  250-TAMAÑO 14680064 S:  250-TUBERÍA S:  250 AYUDA

Por lo tanto, smtp2.example.com declara que puede aceptar un tamaño de mensaje máximo fijo no mayor a 14.680.064 octetos (bytes de 8 bits).

En el caso más simple, un servidor ESMTP declara un máximo SIZEinmediatamente después de recibir un mensaje .  Sin embargo, EHLOsegún RFC 1870, el parámetro numérico de la extensión en la respuesta es opcional. En cambio, los clientes pueden, al emitir un comando, incluir una estimación numérica del tamaño del mensaje que están transfiriendo, de modo que el servidor pueda rechazar la recepción de mensajes demasiado grandes.SIZEEHLOMAIL FROM

El SMTP original solo admite un único cuerpo de texto ASCII, por lo que cualquier dato binario debe codificarse como texto en ese cuerpo del mensaje antes de la transferencia y luego el destinatario debe decodificarlo. Se utilizaban normalmente codificaciones de binario a texto , como uuencode y BinHex .

El comando 8BITMIME se desarrolló para abordar este problema. Se estandarizó en 1994 como RFC  1652 ^[32]. Facilita el intercambio transparente de mensajes de correo electrónico que contienen octetos fuera del conjunto de caracteres ASCII de siete bits al codificarlos como partes de contenido MIME , generalmente codificadas con Base64 .

On-Demand Mail Relay ( ODMR ) es una extensión SMTP estandarizada en RFC  2645 que permite que un servidor SMTP conectado intermitentemente reciba correo electrónico en cola cuando está conectado.

El SMTP original admite direcciones de correo electrónico compuestas únicamente de caracteres ASCII , lo que resulta un inconveniente para los usuarios cuya escritura nativa no está basada en el latín o que utilizan diacríticos que no están en el conjunto de caracteres ASCII. Esta limitación se alivió mediante extensiones que habilitaban UTF-8 en los nombres de direcciones. RFC  5336 introdujo un comando experimental ^[31] y luego fue reemplazado por RFC  6531 que introdujo un comando. Estas extensiones brindan soporte para caracteres multibyte y no ASCII en direcciones de correo electrónico, como aquellas con diacríticos y otros caracteres de idiomas como el griego y el chino . ^[33] UTF8SMTPSMTPUTF8

El soporte actual es limitado, pero hay un fuerte interés en la adopción amplia del RFC  6531 y los RFC relacionados en países como China que tienen una gran base de usuarios donde el latín (ASCII) es una escritura extranjera.

Al igual que SMTP, ESMTP es un protocolo que se utiliza para transportar correo de Internet. Se utiliza como protocolo de transporte entre servidores y (con un comportamiento restringido) como protocolo de envío de correo.

La característica de identificación principal para los clientes ESMTP es abrir una transmisión con el comando EHLO(HELLO extendido), en lugar de HELO(Hello, el estándar RFC  821 original). Un servidor responderá con éxito (código 250), falla (código 550) o error (código 500, 501, 502, 504 o 421), según su configuración. Un servidor ESMTP devuelve el código 250 OK en una respuesta de varias líneas con su dominio y una lista de palabras clave para indicar las extensiones admitidas. Un servidor compatible con RFC 821 devuelve el código de error 500, lo que permite a los clientes ESMTP intentar cualquiera de los dos o .HELOQUIT

Cada extensión de servicio se define en un formato aprobado en RFC posteriores y se registra en la Autoridad de Números Asignados de Internet (IANA). Las primeras definiciones fueron los servicios opcionales de RFC 821: SEND, SOML(Enviar o enviar correo), SAML(Enviar y enviar correo), EXPN, HELP, y TURN. El formato de verbos SMTP adicionales se estableció para nuevos parámetros en MAILy RCPT.

Algunas palabras clave relativamente comunes (no todas ellas correspondientes a comandos) utilizadas hoy en día son:

• 8BITMIME – Transmisión de datos de 8 bits, RFC  6152
• ATRN – Autenticado TURNpara retransmisión de correo a pedido , RFC  2645
• AUTH – SMTP autenticado, RFC  4954
• CHUNKING – Fragmentación, RFC  3030
• DSN – Notificación del estado de entrega, RFC  3461 (Ver Ruta de devolución de sobre variable )
• ETRN – Versión extendida del comando de inicio de cola de mensajes remotos TURN, RFC  1985
• HELP – Proporcionar información útil, RFC  821
• PIPELINING – Canalización de comandos, RFC  2920
• SIZE – Declaración del tamaño del mensaje, RFC  1870
• STARTTLS – Seguridad de la capa de transporte , RFC  3207 (2002)
• SMTPUTF8 – Permitir la codificación UTF-8 en nombres de buzones y campos de encabezado, RFC  6531
• UTF8SMTP – Permitir la codificación UTF-8 en nombres de buzones y campos de encabezado, RFC  5336 (obsoleto ^[34] )

El formato ESMTP fue reformulado en RFC  2821 (reemplazando a RFC 821) y actualizado a la última definición en RFC  5321 en 2008. El soporte para el comando en servidores se volvió obligatorio y se designó como una alternativa obligatoria.EHLOHELO

Se pueden utilizar extensiones de servicio no estándar y no registradas mediante acuerdo bilateral; estos servicios se indican mediante una EHLOpalabra clave de mensaje que comienza con "X" y con cualquier parámetro o verbo adicional marcado de manera similar.

Los comandos SMTP no distinguen entre mayúsculas y minúsculas. Se presentan aquí en mayúsculas para enfatizar únicamente. Un servidor SMTP que requiera un método de uso de mayúsculas específico es una violación del estándar. ^[35]

Al menos los siguientes servidores anuncian la extensión 8BITMIME:

• Apache James (desde 2.3.0a1) ^[36]
• Ciudadela (desde las 7.30)
• Servidor de correo de mensajería
• Gmail ^[37]
• Deformación de hielo
• Servicio SMTP de IIS
• Conexión Kerio
• Dominó de loto
• Microsoft Exchange Server (a partir de Exchange Server 2000)
• Novell GroupWise
• OpenSMTPD
• Servidor de mensajería de Oracle Communications
• Sufijo
• Sendmail (desde 6.57)

Los siguientes servidores se pueden configurar para anunciar 8BITMIME, pero no realizan la conversión de datos de 8 bits a 7 bits cuando se conectan a relés que no son 8BITMIME:

• Exim y qmail no traducen mensajes de ocho bits a siete bits cuando intentan transmitir datos de 8 bits a pares que no son 8BITMIME, como lo requiere el RFC. ^[38] Esto no causa problemas en la práctica, ya que prácticamente todos los relés de correo modernos son de 8 bits limpios . ^[39]
• Microsoft Exchange Server 2003 anuncia 8BITMIME de forma predeterminada, pero la retransmisión a un par que no sea 8BITMIME da como resultado un rebote. Esto está permitido por la sección 3 de RFC 6152.

La extensión SMTP-AUTH proporciona un mecanismo de control de acceso. Consiste en un paso de autenticación a través del cual el cliente inicia sesión en el servidor de correo durante el proceso de envío de correo. Los servidores que admiten SMTP-AUTH generalmente se pueden configurar para exigir a los clientes que utilicen esta extensión, lo que garantiza que se conozca la verdadera identidad del remitente. La extensión SMTP-AUTH se define en RFC  4954.

SMTP-AUTH se puede utilizar para permitir que los usuarios legítimos retransmitan correo y denegar el servicio de retransmisión a usuarios no autorizados, como los spammers . No garantiza necesariamente la autenticidad del remitente del sobre SMTP ni del  encabezado "De:" de RFC 2822. Por ejemplo, la suplantación de identidad , en la que un remitente se hace pasar por otra persona, sigue siendo posible con SMTP-AUTH a menos que el servidor esté configurado para limitar las direcciones de remitente de los mensajes a las direcciones para las que este usuario autentificado esté autorizado.

La extensión SMTP-AUTH también permite que un servidor de correo indique a otro que el remitente ha sido autenticado al retransmitir correo. En general, esto requiere que el servidor del destinatario confíe en el servidor de envío, lo que significa que este aspecto de SMTP-AUTH rara vez se utiliza en Internet. ^{[ cita requerida ]}

Los servidores de soporte incluyen:

• Postfix (versión 3.0 y posteriores) ^[40]
• Momentum (versiones 4.1 ^[41] y 3.6.5, y posteriores)
• Sendmail (soporte experimental en 8.17.1)
• Exim (experimental a partir de la versión 4.86, bastante maduro en la versión 4.96)
• CommuniGate Pro a partir de la versión 6.2.2 ^[42]
• Courier-MTA a partir de la versión 1.0 ^[43]
• Halon a partir de la versión 4.0 ^[44]
• Microsoft Exchange Server a partir de la revisión de protocolo 14.0 ^[45]
• Haraka y otros servidores. ^[46]
• Oracle Communications Messaging Server a partir de la versión 8.0.2. ^[47]

La entrega de correo puede ocurrir tanto a través de texto simple como de conexiones cifradas, sin embargo las partes que se comunican podrían no saber de antemano si la otra parte puede usar un canal seguro.

Las extensiones STARTTLS permiten que los servidores SMTP notifiquen a los clientes que se conectan que admiten la comunicación cifrada TLS y ofrecen a los clientes la oportunidad de actualizar su conexión enviando el comando STARTTLS. Los servidores que admiten la extensión no obtienen inherentemente ningún beneficio de seguridad por su implementación por sí sola, ya que la actualización a una sesión cifrada TLS depende de que el cliente que se conecta decida ejercer esta opción, de ahí el término TLS oportunista .

STARTTLS es efectivo solo contra ataques de observación pasiva, ya que la negociación de STARTTLS ocurre en texto simple y un atacante activo puede eliminar trivialmente los comandos STARTTLS. Este tipo de ataque de intermediario a veces se conoce como STRIPTLS , donde la información de negociación de cifrado enviada desde un extremo nunca llega al otro. En este escenario, ambas partes toman las respuestas no válidas o inesperadas como una indicación de que la otra no admite STARTTLS correctamente, y recurren a la transferencia de correo de texto simple tradicional. ^[48] Tenga en cuenta que STARTTLS también se define para IMAP y POP3 en otras RFC, pero estos protocolos sirven para diferentes propósitos: SMTP se utiliza para la comunicación entre agentes de transferencia de mensajes, mientras que IMAP y POP3 son para clientes finales y agentes de transferencia de mensajes.

En 2014, la Electronic Frontier Foundation inició el proyecto "STARTTLS Everywhere" que, de manera similar a la lista " HTTPS Everywhere ", permitía a las partes confiables descubrir a otras que admitían comunicaciones seguras sin comunicación previa. El proyecto dejó de aceptar presentaciones el 29 de abril de 2021, y la EFF recomendó cambiar a DANE y MTA-STS para descubrir información sobre el soporte TLS de los pares. ^[49]

RFC  8314 declaró oficialmente obsoleto el texto simple y recomendó siempre usar TLS para el envío y acceso de correo, agregando puertos con TLS implícito.

La RFC  7672 introdujo la capacidad de los registros DNS para declarar las capacidades de cifrado de un servidor de correo. Al utilizar DNSSEC , los operadores de servidores de correo pueden publicar un hash de su certificado TLS, mitigando así la posibilidad de comunicaciones no cifradas. ^[50]

Microsoft espera habilitar el soporte completo de SMTP DANE para los clientes de Exchange Online a fines de 2024. ^[51]

Un nuevo RFC  8461 de 2018 llamado "SMTP MTA Strict Transport Security (MTA-STS)" tiene como objetivo abordar el problema de los adversarios activos al definir un protocolo para que los servidores de correo declaren su capacidad de usar canales seguros en archivos específicos en el servidor y registros TXT DNS específicos . La parte que confía verificaría regularmente la existencia de dicho registro y lo almacenaría en caché durante la cantidad de tiempo especificada en el registro y nunca se comunicaría a través de canales inseguros hasta que el registro caduque. ^[48] Tenga en cuenta que los registros MTA-STS se aplican solo al tráfico SMTP entre servidores de correo, mientras que las comunicaciones entre el cliente de un usuario y el servidor de correo están protegidas por la seguridad de la capa de transporte con SMTP/MSA, IMAP, POP3 o HTTPS en combinación con una política organizativa o técnica. Básicamente, MTA-STS es un medio para extender dicha política a terceros.

En abril de 2019, Google Mail anunció el soporte para MTA-STS. ^[52]

Los protocolos diseñados para entregar mensajes de forma segura pueden fallar debido a configuraciones incorrectas o interferencias activas deliberadas, lo que da lugar a mensajes no entregados o a la entrega a través de canales no cifrados o no autenticados. RFC  8460 "SMTP TLS Reporting" describe un mecanismo y un formato de informes para compartir estadísticas e información específica sobre posibles fallas con los dominios de los destinatarios. Los dominios de los destinatarios pueden utilizar esta información para detectar posibles ataques y diagnosticar configuraciones incorrectas no intencionales.

En abril de 2019, Google Mail anunció la compatibilidad con informes SMTP TLS. ^[52]

El diseño original de SMTP no tenía ninguna función para autenticar a los remitentes ni verificar que los servidores estuvieran autorizados a enviar en su nombre, con el resultado de que la suplantación de correo electrónico es posible y se usa comúnmente en el correo no deseado y el phishing .

Ocasionalmente se hacen propuestas para modificar SMTP en gran medida o reemplazarlo por completo. Un ejemplo de esto es Internet Mail 2000 , pero ni éste ni ningún otro ha avanzado mucho frente al efecto red de la enorme base instalada de SMTP clásico.

En cambio, los servidores de correo ahora utilizan una variedad de técnicas, como una aplicación más estricta de estándares como RFC  5322, ^{[53] [54]} DomainKeys Identified Mail , Sender Policy Framework y DMARC , DNSBL y listas grises para rechazar o poner en cuarentena correos electrónicos sospechosos. ^[55]

• Dirección de rebote
• CRAM-MD5 (un mecanismo SASL para ESMTPA) RFC  2195
• Correo electrónico
  • Cifrado de correo electrónico
• DKIM
• Ident
• Lista de software de servidor de correo
• Lista de códigos de retorno del servidor SMTP
• POP antes de SMTP / SMTP después de POP
• Extensión de contenido binario del Protocolo de acceso a mensajes de Internet RFC  3516
• Marco de políticas de remitentes (SPF)
• Capa de seguridad y autenticación simple (SASL) RFC  4422
• Autenticación SMTP
• Ruta de retorno de envolvente variable
• Comparación de clientes de correo electrónico para obtener información sobre la compatibilidad con SMTP

• Hughes, L (1998). Correo electrónico en Internet: protocolos, estándares e implementación . Artech House Publishers. ISBN 978-0-89006-939-4.
• Hunt, C (2003). Libro de recetas sendmail . O'Reilly Media. ISBN 978-0-596-00471-2.
• Johnson, K (2000). Protocolos de correo electrónico de Internet: guía para desarrolladores . Addison-Wesley Professional. ISBN 978-0-201-43288-6.
• Loshin, P (1999). Estándares esenciales de correo electrónico: RFC y protocolos prácticos . John Wiley & Sons. ISBN 978-0-471-34597-8.
• Rhoton, J (1999). Guía del programador para correo de Internet: SMTP, POP, IMAP y LDAP . Elsevier. ISBN 978-1-55558-212-8.
• Wood, D (1999). Programación del correo electrónico en Internet . O'Reilly. ISBN 978-1-56592-479-6.

• RFC  1123 – Requisitos para los hosts de Internet: aplicación y soporte (STD 3)
• RFC  1870 – Extensión del servicio SMTP para la declaración del tamaño de los mensajes (obsoleto: RFC  1653)
• RFC  2505 – Recomendaciones antispam para MTA SMTP (BCP 30)
• RFC  2821 – Protocolo simple de transferencia de correo
• RFC  2920 – Extensión del servicio SMTP para la canalización de comandos (STD 60)
• RFC  3030 – Extensiones del servicio SMTP para la transmisión de mensajes MIME grandes y binarios
• RFC  3207 – Extensión del servicio SMTP para SMTP seguro sobre seguridad de la capa de transporte ( RFC  2487 obsoleta)
• RFC  3461 – Extensión del servicio SMTP para notificaciones de estado de entrega (reemplaza la RFC  1891)
• RFC  3463 – Códigos de estado mejorados para SMTP ( RFC  1893 obsoleto, actualizado por RFC  5248)
• RFC  3464: un formato de mensaje extensible para notificaciones de estado de entrega (deja obsoleto el RFC  1894)
• RFC  3798 – Notificación de disposición de mensajes (actualiza RFC  3461)
• RFC  3834 – Recomendaciones para respuestas automáticas al correo electrónico
• RFC  3974 – Experiencia operativa de SMTP en entornos mixtos IPv4/v6
• RFC  4952: descripción general y marco para el correo electrónico internacionalizado (actualizado por RFC  5336)
• RFC  4954 – Extensión del servicio SMTP para autenticación (deja obsoleto el RFC  2554, actualiza el RFC  3463, actualizado por el RFC  5248)
• RFC  5068 – Operaciones de envío de correo electrónico: requisitos de acceso y responsabilidad (BCP 134)
• RFC  5248 – Un registro para códigos de estado de sistema de correo mejorado SMTP (BCP 138) (actualiza RFC  3463)
• RFC  5321 – Protocolo simple de transferencia de correo (deja obsoleto el RFC  821, también conocido como STD 10, RFC  974, RFC  1869, RFC  2821, actualiza el RFC  1123)
• RFC  5322: formato de mensajes de Internet (obsoleto RFC  822, también conocido como STD 11 y RFC  2822)
• RFC  5504 – Mecanismo de degradación para la internacionalización de direcciones de correo electrónico
• RFC  6409 – Envío de mensajes por correo (STD 72) (deja obsoletos a RFC  4409 y RFC  2476)
• RFC  6522 – El tipo de contenido Multipart/Report para la generación de informes de mensajes administrativos del sistema de correo (deja obsoleto el RFC  3462 y, a su vez, el RFC  1892)
• RFC  6531 – Extensión SMTP para direcciones de correo electrónico internacionalizadas (actualiza RFC  2821, RFC  2822, RFC  4952 y RFC  5336)
• RFC  8314 – El texto claro se considera obsoleto: uso de la seguridad de la capa de transporte (TLS) para el envío y acceso a correos electrónicos

• RFC  1869 Extensiones del servicio SMTP
• RFC  5321 Protocolo simple de transferencia de correo
• RFC  4954 Extensión del servicio SMTP para autenticación (reemplaza la RFC  2554)
• RFC  3848 Registro de tipos de transmisión SMTP y LMTP (con ESMTPA)
• RFC  6409 Envío de mensajes para correo (deja obsoleto el RFC  4409, que a su vez deja obsoleto el RFC  2476)