Protocolo de transferencia de correo simple (SMTP)

El Protocolo de transferencia de correo simple o SMTP por sus siglas en inglés Simple Mail Transfer Protocol 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 generalmente usan SMTP solo para enviar mensajes a un servidor de correo para la retransmisión y, por lo general, 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 reemplazó al antiguo POP3) es estándar, pero los servidores propietarios también suelen implementar protocolos propietarios, por ejemplo, Exchange ActiveSync.

Los orígenes de SMTP comenzaron en 1980, basándose en conceptos implementados en ARPANET desde 1971. Ha sido actualizado, modificado y ampliado varias veces. La versión del protocolo de uso común en la actualidad tiene una estructura extensible con varias extensiones para la autenticación, el cifrado, la transferencia de datos binarios y las direcciones de correo electrónico internacionalizadas. Los servidores SMTP suelen utilizar el Protocolo de control de transmisión en el número de puerto 25 (para texto sin formato) y 587 (para comunicaciones cifradas).

Descripción general del protocolo

SMTP es un protocolo basado en texto 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 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, el remitente o el transmisor) y las respuestas correspondientes del servidor SMTP (el agente de escucha o el receptor) para que se abra la sesión y se intercambien 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 llamado return-path, reverse-path, bounce address, mfrom, o remitente del sobre.
2. Comando RCPT, para establecer un destinatario del mensaje. Este comando se puede emitir varias veces, una para cada destinatario. Estas direcciones también forman parte del sobre.
3. DATA para señalar el comienzo del texto del mensaje; el contenido del mensaje, a diferencia de su sobre. Consiste en un encabezado de mensaje y un cuerpo de mensaje separados por una línea vacía. DATA es en realidad un grupo de comandos, y el servidor responde dos veces: una vez al comando DATA en sí mismo, para reconocer que está listo para recibir el texto, y la segunda vez después de la secuencia de fin de datos, para aceptar o rechazar. todo el mensaje.

Además de la respuesta intermedia para DATA, 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 drop es una respuesta positiva seguida de un descarte de mensaje en lugar de una entrega.

El host iniciador, el cliente SMTP, puede ser un cliente de correo electrónico del 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 correspondiente, con el fin de retransmitir el correo. Los servidores SMTP totalmente capaces mantienen colas de mensajes para reintentar las transmisiones 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 generalmente 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 conforme (no todos lo son) busca 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 conectarse a un MSA requiere Autenticación SMTP.

SMTP vs recuperación de correo

SMTP es solo un protocolo de entrega. En uso normal, el correo es "empujado" 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 se dirige. 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 extraigamensajes de un servidor remoto bajo demanda, 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 remotos a continuación). POP e IMAP son protocolos inadecuados para retransmitir correo a través 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 correcto funcionamiento de la retransmisión de correo (el "sobre de correo").

Inicio de la cola de mensajes remotos

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 del comando correspondiente. El TURNcomando original se consideró inseguro y se amplió en RFC 1985 con el ETRNcomando que funciona de manera más segura utilizando un método de autenticación basado en la información del Sistema de nombres de dominio.

Servidor SMTP de correo saliente

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

Restricciones de acceso al servidor de correo saliente

Los administradores del servidor deben imponer cierto control sobre qué clientes pueden usar el servidor. Esto les permite lidiar con el abuso, por ejemplo, el spam. Dos soluciones han sido de uso común:

• En el pasado, muchos sistemas imponían restricciones de uso según la ubicación del cliente, y solo permitían el uso de clientes cuya dirección IP estaba bajo el control de los administradores del servidor. No se permite el uso desde cualquier otra dirección IP de cliente.
• Los servidores SMTP modernos suelen ofrecer un sistema alternativo que requiere la autenticación de los clientes mediante credenciales antes de permitir el acceso.

Restricción de acceso por ubicación

Bajo este sistema, el servidor SMTP de un ISP no permitirá el acceso de usuarios que estén fuera de la red del ISP. Más concretamente, el servidor sólo podrá permitir el acceso a los usuarios con una dirección IP facilitada por el ISP, lo que equivale a exigir que estén conectados a Internet a través de ese mismo ISP. Un usuario móvil a menudo puede estar en una red distinta a la de su ISP normal, y luego encontrará que el envío de correo electrónico falla porque ya no se puede acceder a la opción de servidor SMTP configurado.

Este sistema tiene varias variaciones. Por ejemplo, el servidor SMTP de una organización solo puede brindar servicio a los usuarios en la misma red, lo que hace cumplir esto mediante un firewall para bloquear el acceso de los usuarios en Internet en general. 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 solo para uso interno dentro de la organización. Sin embargo, la mayoría de estos organismos ahora utilizan métodos de autenticación de clientes, como se describe a continuación.

Cuando un usuario es móvil y puede usar diferentes ISP para conectarse a Internet, este tipo de restricción de uso es onerosa y alterar la dirección del servidor SMTP del correo electrónico saliente configurado no es práctico. Es muy deseable poder utilizar la información de configuración del cliente de correo electrónico que no es necesario cambiar.

Autenticación del cliente

Los servidores SMTP modernos generalmente requieren 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 SMTP AUTH, es una extensión de SMTP para iniciar sesión mediante un mecanismo de autenticación.

Puertos

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

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

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

Algunos proveedores individuales pueden usar el puerto 2525 y otros, pero nunca han recibido soporte oficial.

Muchos proveedores de servicios de Internet ahora bloquean todo el tráfico saliente del puerto 25 de sus clientes. Principalmente como medida anti-spam, pero también para curar el mayor costo que tienen al dejarlo abierto, quizás cobrando más a los pocos clientes que lo requieren abierto.

Modelo de procesamiento de correo

El correo electrónico lo envía un cliente de correo (agente de usuario de correo, MUA) a un servidor de correo (agente de envío de correo, MSA) usando SMTP en el puerto TCP 587. La mayoría de los proveedores de buzones aún permiten el envío en el puerto tradicional 25. El MSA entrega el correo a su agente de transferencia de correo (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 puede realizarse 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 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. Según el host de destino y otros factores, el MTA de envío selecciona un servidor de destino y se conecta a él para completar el intercambio de correo.

La transferencia de mensajes puede ocurrir en una sola 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 "retransmisor" intermedio (es decir, almacena y reenvía el mensaje) o una "puerta de enlace" (es decir, puede reenviar el mensaje usando algún protocolo que no sea SMTP). Según la sección 2.1 de RFC 5321, cada salto es una transferencia formal de responsabilidad por el mensaje, por lo que el servidor receptor debe entregar el mensaje o informar adecuadamente la falla al hacerlo.

Una vez que el salto final acepta el mensaje entrante, lo entrega a un agente de entrega de correo (MDA) para la 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 una casilla cerca de la casilla del intercambiador de correo. Un MDA puede enviar 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 fin.

Una vez entregado al servidor de correo local, el correo se almacena para que los clientes de correo autenticado (MUA) lo recuperen por lotes. El correo lo recuperan las aplicaciones del usuario final, llamadas clientes de correo electrónico, utilizando 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 de correos (POP), que generalmente usa el correo mbox tradicional. formato de archivo o un sistema propietario como Microsoft Exchange/Outlook o Lotus Notes/Domino. Los clientes de correo web pueden usar cualquiera de los dos métodos, pero el protocolo de recuperación a menudo no es un estándar formal.

SMTP define el transporte de mensajes, no el contenido del mensaje. Por lo tanto, define el sobre de correo y sus parámetros, como el remitente del sobre, pero no el encabezado (excepto la información de rastreo) 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), denominado formalmente formato de mensaje de Internet.

Ejemplo de transporte SMTP

Un ejemplo típico de envío de un mensaje vía SMTP a dos buzones (alice y theboss) ubicados en el mismo dominio de correo (example.com) se reproduce en el siguiente intercambio de sesiones. (En este ejemplo, las partes de la conversación tienen el prefijo S: y C:, para el servidor y el cliente, 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), el servidor abre la sesión con un saludo, 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).

S: 220 smtp.example.com ESMTP Posfijo
C: HELO relé.ejemplo.org
S: 250 Hola relay.example.org, me alegro de conocerte
C: CORREO DE:<bob@example.org>
S: 250 Vale
C: RCPT A:<alice@example.com>
S: 250 Vale
C: RCPT A:<theboss@example.com>
S: 250 Vale
C: DATOS
S: 354 Finalizar datos con <CR><LF>.<CR><LF>
C: De: "Ejemplo de Bob" <bob@example.org>
C: Para: "Ejemplo de Alice" <alice@example.com>
C: CC: theboss@example.com
C: Fecha: martes, 15 de enero de 2008 16:02:43 -0500
C: Asunto: Mensaje de prueba
C:
C: Hola Alicia.
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: SALIR
S: 221 Adiós
{El servidor cierra la conexión}

El cliente notifica al receptor la dirección de correo electrónico de origen del mensaje en un MAIL FROMcomando. Esta es también la dirección de devolución o rebote en caso de que el mensaje no se pueda entregar. En este ejemplo, el mensaje de correo electrónico se envía a dos buzones 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 (p. ej., 250 Ok).

La transmisión del cuerpo del mensaje de correo se inicia con un DATAcomando, después del cual se transmite palabra por línea y finaliza con una secuencia de fin de datos. Esta secuencia consta de un salto de línea (<CR><LF>), un único punto final (.), seguido de otro salto de línea (<CR><LF>). Dado que el cuerpo de un mensaje puede contener una línea con solo 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 dot-stuffing.

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 se puede duplicar 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 fue entregado. Por otro lado, después de que el receptor ha decidido aceptar el mensaje, debe asumir que el mensaje le ha sido entregado. Así, durante este lapso de tiempo, ambos agentes tienen copias activas del mensaje que intentarán entregar.La probabilidad de que se produzca un error de comunicación exactamente en este paso es directamente proporcional a la cantidad de filtrado que realiza el servidor en el cuerpo del mensaje, con mayor frecuencia con fines antispam. El límite de tiempo de espera se especifica en 10 minutos.

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 apropiado para los destinatarios posteriores después de que los destinos actuales se hayan puesto en cola. 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 del servidor receptor. Agrega un campo de cabecera Receivedy Return-Path, respectivamente.

Algunos clientes están implementados para cerrar la conexión después de que se acepta 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.

Extensiones SMTP

Mecanismo de descubrimiento de extensiones

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 HELOsolo si el servidor no admite el EHLOsaludo.

Los clientes modernos pueden usar la palabra clave de extensión ESMTP SIZEpara consultar al servidor sobre 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 los recursos de la red, incluido el tiempo de conexión a los enlaces de la red que se paga por minuto.

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

S: 220 smtp2.example.com ESMTP Posfijo
C: EHLO bob.ejemplo.org
S: 250-smtp2.example.com Hola bob.example.org [192.0.2.201] 
S: 250-SIZE 14680064 
S: 250-PIPELINING 
S: 250 AYUDA

Por lo tanto, smtp2.example.com declara que puede aceptar un tamaño de mensaje máximo fijo que no supere los 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 EHLO. Sin embargo, según RFC 1870, el parámetro numérico de la SIZEextensión en la EHLOrespuesta es opcional. En cambio, los clientes pueden, al emitir un MAIL FROMcomando, 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.

Transferencia de datos binarios

El SMTP original solo admite un único cuerpo de texto ASCII, por lo tanto, los datos binarios deben codificarse como texto en ese cuerpo del mensaje antes de la transferencia y luego ser decodificados por el destinatario. Normalmente se usaban codificaciones de binario a texto, como uuencode y BinHex.

El comando 8BITMIME se desarrolló para abordar esto. Fue estandarizado en 1994 como RFC 1652. 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 codificados con Base64.

Extensiones del mecanismo de entrega de correo

Retransmisión de correo bajo demanda

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

Extensión de internacionalización

El SMTP original admite direcciones de correo electrónico compuestas solo por caracteres ASCII, lo que es un inconveniente para los usuarios cuya escritura nativa no está basada en el latín o que usan signos diacríticos que no están en el conjunto de caracteres ASCII. Esta limitación se alivió mediante extensiones que permitían UTF-8 en los nombres de direcciones. RFC 5336 introdujo el comando experimental y luego fue reemplazado por RFC 6531 que introdujo el comando. Estas extensiones brindan soporte para caracteres de varios bytes y que no son ASCII en las direcciones de correo electrónico, como aquellos con diacríticos y otros caracteres de idiomas como el griego y el chino. UTF8SMTPSMTPUTF8

El soporte actual es limitado, pero existe un gran interés en la adopción generalizada de 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.

Extensiones

Al igual que SMTP, ESMTP es un protocolo utilizado para transportar correo de Internet. Se utiliza como protocolo de transporte entre servidores y (con un comportamiento restringido aplicado) 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(HOLA 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), dependiendo de 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 probar HELOo QUIT.

Cada extensión de servicio se define en un formato aprobado en RFC posteriores y se registra con la Autoridad de Números Asignados de Internet (IANA). Las primeras definiciones fueron los servicios opcionales RFC 821: SEND, SOML(Enviar o Correo), SAML(Enviar y Correo), EXPN, HELPy TURN. Se estableció el formato de verbos SMTP adicionales y 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 bajo demanda, RFC 2645
• AUTH – SMTP autenticado, RFC 4954
• CHUNKING – Fragmentación, RFC 3030
• DSN – Notificación de estado de entrega, RFC 3461 (consulte 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 los nombres de los buzones y los campos de encabezado, RFC 6531
• UTF8SMTP – Permitir la codificación UTF-8 en los nombres de los buzones y los campos de encabezado, RFC 5336 (obsoleto)

El formato ESMTP se reformuló en RFC 2821 (reemplazando a RFC 821) y se actualizó a la definición más reciente en RFC 5321 en 2008. El soporte para el EHLOcomando en los servidores se volvió obligatorio y se HELOdesignó como un respaldo requerido.

Las extensiones de servicio no estándar, no registradas, se pueden utilizar por acuerdo bilateral, estos servicios se indican mediante una EHLOpalabra clave de mensaje que comienza con "X", y con cualquier parámetro adicional o verbos marcados de manera similar.

Los comandos SMTP no distinguen entre mayúsculas y minúsculas. Se presentan aquí en mayúsculas solo para enfatizar. Un servidor SMTP que requiere un método de capitalización específico es una violación del estándar.

8BITMIME

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

• Apache James (desde 2.3.0a1)
• Ciudadela (desde las 7.30)
• Servidor de correo de mensajería
• Gmail
• Deformación de hielo
• Servicio IIS SMTP
• Kerio Conectar
• dominó de loto
• Microsoft Exchange Server (a partir de Exchange Server 2000)
• Novell GroupWise®
• Abrir SMTPD
• Servidor de mensajería de comunicaciones de Oracle
• 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 retransmisiones 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. Esto no causa problemas en la práctica, ya que prácticamente todos los repetidores de correo modernos están limpios en 8 bits.
• Microsoft Exchange Server 2003 anuncia 8BITMIME de forma predeterminada, pero la retransmisión a un par que no es 8BITMIME da como resultado un rebote. Esto está permitido por RFC 6152 sección 3.

SMTP-AUTENTICACIÓN

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 efectivamente en el servidor de correo durante el proceso de envío de correo. Los servidores que admiten SMTP-AUTH generalmente se pueden configurar para requerir que los clientes usen 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 el correo mientras niegan el servicio de retransmisión a usuarios no autorizados, como los remitentes de spam. No garantiza necesariamente la autenticidad del remitente del sobre SMTP ni del encabezado RFC 2822 "De:". Por ejemplo, la suplantación de identidad, en la que un remitente se hace pasar por otra persona, todavía es posible con SMTP-AUTH a menos que el servidor esté configurado para limitar las direcciones de origen de los mensajes a las direcciones para las que este usuario AUTHed 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 usa en Internet.

SMTPUTF8

Los servidores de apoyo incluyen:

• Postfix (versión 3.0 y posteriores)
• Momentum (versiones 4.1 y 3.6.5 y posteriores)
• Sendmail (en desarrollo)
• Exim (experimental a partir de la versión 4.86)
• CommuniGate Pro a partir de la versión 6.2.2
• Courier-MTA a partir de la versión 1.0
• Halon a partir de la versión 4.0
• Microsoft Exchange Server a partir de la revisión del protocolo 14.0
• Haraka y otros servidores.
• Oracle Communications Messaging Server a partir de la versión 8.0.2.

Extensiones de seguridad

La entrega de correo puede ocurrir tanto a través de texto sin formato como de conexiones cifradas, sin embargo, es posible que las partes que se comunican no sepan con anticipación la capacidad de la otra parte para usar un canal seguro.

STARTTLS o "TLS Oportunista"

Las extensiones STARTTLS permiten que los servidores SMTP admitan que notifiquen a los clientes que se conectan que admiten la comunicación cifrada TLS y ofrecen la oportunidad de que los clientes actualicen su conexión enviando el comando STARTTLS. Los servidores que admiten la extensión no obtienen inherentemente ningún beneficio de seguridad de su implementación por sí solos, ya que la actualización a una sesión cifrada con 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 sin formato y un atacante activo puede eliminar los comandos de STARTTLS de manera trivial. Este tipo de ataque man-in-the-middle a veces se denomina 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 parte no es compatible correctamente con STARTTLS, por lo que la transferencia de correo tradicional de texto sin formato es predeterminada. Tenga en cuenta que STARTTLS también se define para IMAP y POP3 en otros RFC, pero estos protocolos tienen diferentes propósitos: SMTP se usa 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, Electronic Frontier Foundation inició el proyecto "STARTTLS Everywhere" que, de manera similar a la lista "HTTPS Everywhere", permitió a las partes confiables descubrir a otras personas que respaldan la comunicación segura sin comunicación previa. El proyecto dejó de aceptar presentaciones el 29 de abril de 2021 y EFF recomendó cambiar a DANE y MTA-STS para descubrir información sobre el soporte TLS de sus pares.

RFC 8314 declaró oficialmente obsoleto el texto sin formato y recomienda usar siempre TLS, agregando puertos con TLS implícito.

SMTP MTA Seguridad de transporte estricta

Un nuevo RFC 8461 de 2018 llamado "SMTP MTA Strict Transport Security (MTA-STS)" tiene como objetivo abordar el problema del adversario activo definiendo un protocolo para que los servidores de correo declaren su capacidad de usar canales seguros en archivos específicos en el servidor y DNS específicos. Registros TXT. La parte que confía verificaría periódicamente la existencia de dicho registro y lo almacenaría en caché durante el tiempo especificado en el registro y nunca se comunicaría a través de canales inseguros hasta que caduque el registro. Tenga en cuenta que los registros MTA-STS solo se aplican 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 Transport Layer Security con SMTP/MSA, IMAP, POP3 o HTTPS en combinación con una política organizativa o técnica. Esencialmente, MTA-STS es un medio para extender dicha política a terceros.

En abril de 2019, Google Mail anunció la compatibilidad con MTA-STS.

Informes SMTP TLS

Varios protocolos permiten la entrega segura de mensajes, pero pueden fallar debido a configuraciones incorrectas o interferencia activa deliberada, lo que genera mensajes no entregados o entregas a través de canales no cifrados o no autenticados. RFC 8460 "Informes SMTP TLS" 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 usar esta información para detectar posibles ataques y diagnosticar errores de configuración no intencionales.

En abril de 2019, Google Mail anunció la compatibilidad con los informes SMTP TLS.

Suplantación de identidad y spam

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

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

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

Solicitudes de comentarios relacionadas

• RFC 1123: requisitos para hosts de Internet: aplicación y soporte (STD 3)
• RFC 1870: extensión del servicio SMTP para la declaración del tamaño del mensaje (obsoleta: RFC 1653)
• RFC 2505: recomendaciones antispam para SMTP MTA (BCP 30)
• RFC 2821: Protocolo simple de transferencia de correo
• RFC 2920: extensión del servicio SMTP para canalización de comandos (STD 60)
• RFC 3030: extensiones de servicio SMTP para la transmisión de mensajes MIME grandes y binarios
• RFC 3207: extensión del servicio SMTP para SMTP seguro sobre la seguridad de la capa de transporte (RFC 2487 obsoleto)
• RFC 3461: extensión del servicio SMTP para notificaciones de estado de entrega (RFC 1891 obsoleto)
• RFC 3463: códigos de estado mejorados para SMTP (obsoleta RFC 1893, actualizada por RFC 5248)
• RFC 3464: un formato de mensaje extensible para notificaciones de estado de entrega (RFC 1894 obsoleto)
• RFC 3798: notificación de disposición de mensaje (actualiza RFC 3461)
• RFC 3834 – Recomendaciones para Respuestas Automáticas al Correo Electrónico
• RFC 3974: experiencia operativa de SMTP en entornos mixtos de IPv4/v6
• RFC 4952: descripción general y marco para correo electrónico internacionalizado (actualizado por RFC 5336)
• RFC 4954: extensión del servicio SMTP para autenticación (obsoleta RFC 2554, actualiza RFC 3463, actualizado por 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 del sistema de correo mejorado SMTP (BCP 138) (actualiza RFC 3463)
• RFC 5321: el protocolo simple de transferencia de correo (obsoleto RFC 821, también conocido como STD 10, RFC 974, RFC 1869, RFC 2821, actualiza RFC 1123)
• RFC 5322: formato de mensaje de Internet (obsoleta 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) (obsoleta RFC 4409, RFC 2476)
• RFC 6522: el tipo de contenido de varias partes/informe para la notificación de mensajes administrativos del sistema de correo (obsoleta RFC 3462 y, a su vez, 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: texto sin cifrar considerado obsoleto: uso de la seguridad de la capa de transporte (TLS) para el envío y el acceso a correos electrónicos