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 suelen utilizar SMTP solo para enviar mensajes a un servidor de correo para retransmitirlos 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. Se actualizó, modificó y amplió 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).

Historia

Predecesoras de SMTP

En la década de 1960 se utilizaron varias formas de mensajería electrónica uno a uno. Los usuarios se comunicaban usando sistemas desarrollados para computadoras centrales específicas. A medida que se interconectaron 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. SMTP surgió de estos estándares desarrollados durante la década de 1970.

El correo en ARPANET tiene sus raíces en 1971: el Protocolo de buzón de correo, que no se implementó, pero se analiza en 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. En el RFC 524 de junio de 1973 se hizo una propuesta adicional para un Protocolo de correo, que no se implementó.

El uso del Protocolo de transferencia de archivos (FTP) para el "correo de red" sobre ARPANET se propuso en RFC 469 en marzo de 1973. A través de RFC 561, RFC 680, RFC 724 y finalmente RFC 733 en noviembre de 1977, un marco estandarizado para "correo electrónico" Se desarrolló el uso de servidores de correo FTP.

SMTP original

En 1980, Jon Postel y Suzanne Sluizer publicaron el RFC 772, que proponía el Protocolo de transferencia de correo como reemplazo del uso de FTP para el correo. RFC 780 de mayo de 1981 eliminó todas las referencias a FTP y asignó el puerto 57 para TCP y UDP, una asignación que IANA eliminó desde entonces. En noviembre de 1981, Postel publicó RFC 788 "Protocolo simple de transferencia de correo".

El estándar SMTP se desarrolló casi al mismo tiempo que Usenet, una red de comunicación de uno a muchos con algunas similitudes.

SMTP comenzó a utilizarse ampliamente a principios de la década de 1980. En ese momento, era un complemento del Programa de copia de Unix a Unix (UUCP), que era más adecuado para manejar transferencias de correo electrónico entre máquinas que estaban conectadas de forma intermitente. SMTP, por otro lado, funciona mejor cuando las máquinas de envío y recepción están conectadas a la red todo el tiempo. Ambos utilizaron 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, UUCP como transporte de correo virtualmente ha desaparecido junto con los "bang paths" se usaba como encabezados de enrutamiento de mensajes.

Sendmail, lanzado con 4.1cBSD en 1983, fue uno de los primeros agentes de transferencia de correo en implementar SMTP. 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.

El protocolo SMTP original solo 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 correo no deseado, y requería que 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 una retransmisión de correo abierta. El Consorcio de correo de Internet (IMC) informó que el 55 % de los servidores de correo eran repetidores abiertos en 1998, pero menos del 1 % en 2002. Debido a las preocupaciones sobre el spam, la mayoría de los proveedores de correo electrónico bloquean los repetidores abiertos, lo que hace que el SMTP original sea esencialmente poco práctico para el uso general en Internet..

SMTP moderna

En noviembre de 1995, RFC 1869 definió el Protocolo simple de transferencia de correo (ESMTP) extendido, que estableció una estructura general para todas las extensiones existentes y futuras con el objetivo de agregar las funciones que faltaban en el SMTP original. ESMTP define medios consistentes y manejables por los cuales los clientes y servidores de ESMTP pueden identificarse y los servidores pueden indicar extensiones admitidas.

El envío de mensajes (RFC 2476) y SMTP-AUTH (RFC 2554) se introdujeron en 1998 y 1999 y ambos describen nuevas tendencias en la entrega de correo electrónico. Originalmente, los servidores SMTP solían ser internos de una organización, recibían correo para la organización desde el exterior y retransmitían mensajes de la organización hacia el exterior. Pero a medida que pasó el tiempo, los servidores SMTP (agentes de transferencia de correo), en la práctica, ampliaron sus funciones para convertirse en agentes de envío de mensajes para los agentes de usuario de correo, algunos de los cuales ahora retransmitían correo desde el exterior de un organización. (por ejemplo, un ejecutivo de la empresa desea enviar correos electrónicos durante un viaje usando el servidor SMTP corporativo). Este problema, una consecuencia de la rápida expansión y popularidad de la World Wide Web, significaba que SMTP tenía que incluir reglas y métodos específicos para retransmitir el correo. y autenticar a los 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 a menudo reescribían el correo en un intento de solucionar problemas, por ejemplo, agregando 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. La separación limpia del correo en envío y retransmisión se consideró una forma de permitir y fomentar la reescritura de envíos y prohibir la reescritura de retransmisión. A medida que el spam se volvió más frecuente, también se lo vio como una forma de proporcionar autorización para el envío de correo desde una organización, así como la trazabilidad. Esta separación entre retransmisión y envío se convirtió rápidamente en la base de las prácticas modernas de seguridad del correo electrónico.

Como este protocolo comenzó puramente basado en texto ASCII, no funcionó 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 transferirlos a través de SMTP. Los agentes de transferencia de correo (MTA) desarrollados después de Sendmail también solían implementarse con una limpieza de 8 bits, de modo que la alternativa "solo envía ocho" podría usarse para transmitir datos de texto arbitrarios (en cualquier codificación de caracteres similar a ASCII de 8 bits) a través de SMTP. Mojibake seguía siendo un problema debido a las diferentes asignaciones de conjuntos de caracteres entre los proveedores, aunque las direcciones de correo electrónico solo permitían ASCII. Actualmente, los MTA limpios de 8 bits tienden a admitir la extensión 8BITMIME, lo que permite que algunos archivos binarios se transmitan casi tan fácilmente como texto sin formato (todavía se aplican los límites en la longitud de línea y los valores de octeto permitidos, por lo que se necesita la codificación MIME para la mayoría de los archivos que no son de texto). datos y algunos formatos de texto). En 2012, se creó la extensión SMTPUTF8 para admitir texto UTF-8, lo que permite contenido y direcciones internacionales en alfabetos no latinos, como el cirílico o el chino.

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

Modelo de procesamiento de correo

Las flechas azules representan la aplicación de las variaciones SMTP

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) mediante 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" (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). De acuerdo con 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 del mensaje, no el contenido del mensaje. 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 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.

Descripción general del protocolo

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 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) para que se abra la sesión, y se intercambian parámetros de 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. MAIL comando, para establecer la dirección de retorno, también llamado retorno-path, reverso-path, dirección de rebote, mfrom o envoltorio.
2. RCPT comando, para establecer un destinatario del mensaje. Este comando se puede emitir varias veces, una para cada destinatario. Estas direcciones son también parte del sobre.
3. DATOS para indicar el comienzo del texto; el contenido del mensaje, en lugar de su sobre. Se compone de un encabezado del mensaje y a cuerpo de mensaje separado por una línea vacía. DATA es en realidad un grupo de comandos, y el servidor responde dos veces: una vez al DATA command en sí mismo, reconocer que está listo para recibir el texto, y la segunda vez después de la secuencia final 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 caída es una respuesta positiva seguida del descarte del mensaje en lugar de la 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) del servidor de retransmisión., es decir, un servidor SMTP que actúa como cliente SMTP, en la sesión correspondiente, para 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 versus 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 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 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 comando TURN original se consideró inseguro y se amplió en RFC 1985 con el comando ETRN, que funciona de forma más segura mediante 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 impusieron restricciones de uso por ubicación del cliente, sólo permite el uso de clientes cuya dirección IP es una que los administradores del servidor controlan. El uso de cualquier otra dirección IP cliente está desactivado.
• Los servidores SMTP modernos suelen ofrecer un sistema alternativo que requiere autenticación de clientes por credenciales antes de permitir el acceso.

Restringir el 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 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 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.

Correo clientes; sin embargo, generalmente no se usa esto, sino que se usa un "envío" puertos Los servicios de correo generalmente aceptan el envío de correos electrónicos de los clientes en uno de:

• 587 (Submission), as formalized in RFC 6409 (previously RFC 2476)
• 465 Este puerto fue deprecado después de RFC 2487, hasta el número 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 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.

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 servidor y cliente, respectivamente; estas etiquetas no son parte del intercambio).

Después de que el remitente del mensaje (cliente SMTP) establezca 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.ejemplo.com. El cliente inicia su diálogo respondiendo con un comando HELO identificándose 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 PostfixC: HELO relay.example.org
S: 250 Hola relé. example.org, I am glad to meet youC: MAIL DE: hechosbob@example.org
S: 250 OkC: RCPT TO: hechosalice@example.com
S: 250 OkC: RCPT TO: detecttheboss@example.com
S: 250 OkC: DATOS
S: 354 Datos finales con el título de usuario.C: De: "Bob Ejemplo"
C: A: "Alice Ejemplo"
C: Cc: theboss@example.com
C: Fecha: Tue, 15 ene 2008 16:02:43 -0500
C: Asunto: Mensaje de prueba
C:
C: Hola Alice.
C: Este es un mensaje de prueba con 5 campos de cabecera y 4 líneas en el cuerpo del mensaje.
C: Tu amigo,
C: Bob
C:
S: 250 Ok: queued as 12345C: QUIT
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 comando MAIL FROM. 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 enumerado 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 comando DATA, 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, p. debido a un corte de energía: Hasta que el remitente haya recibido esa respuesta 250 Ok, 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 comando QUIT finaliza la sesión. Si el correo electrónico tiene otros destinatarios ubicados en otro lugar, el cliente QUIT y se conectarí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 HELO y MAIL FROM se agrega (no se ve en el código de ejemplo) como campos de encabezado adicionales al mensaje del servidor receptor. Agrega un campo de encabezado Received y Return-Path, respectivamente.

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

Extensiones SMTP

Mecanismo de descubrimiento de extensiones

Los clientes conocen las opciones admitidas por un servidor mediante el saludo EHLO, como se muestra a continuación, en lugar del HELO original. Los clientes recurren a HELO solo si el servidor no admite el saludo EHLO.

Los clientes modernos pueden usar la palabra clave de extensión ESMTP SIZE para 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 comando HELO con el comando EHLO.

S: 220 smtp2.example.com ESMTP PostfixC: EHLO bob.example.org
S: 250-smtp2.example.com Hola bob.example.org [192.0.2.201]S: 250-SIZE 14680064S: 250-PIPELININGS: 250 HELP

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 SIZE máximo inmediatamente después de recibir un EHLO. Sin embargo, según RFC 1870, el parámetro numérico de la extensión SIZE en la respuesta EHLO es opcional. En cambio, los clientes pueden, al emitir un comando MAIL FROM, incluir una estimación numérica del tamaño del mensaje que están transfiriendo, para que el servidor pueda rechazar la recepción de mensajes demasiado grandes.

Transferencia de datos binarios

El SMTP original solo admite un 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, el destinatario debe descodificarlos. Normalmente se usaban codificaciones de binario a texto, como uuencode y BinHex.

El comando 8BITMIME se desarrolló para solucionar este problema. 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 UTF8SMTP y luego fue reemplazado por RFC 6531 que introdujo el comando SMTPUTF8. 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 idioma como el griego y el chino.

La compatibilidad actual es limitada, pero existe un gran interés en la adopción generalizada de RFC 6531 y los RFC relacionados en países como China, que tiene una gran base de usuarios donde el latín (ASCII) es una escritura extranjera.

Extensiones

Al igual que SMTP, ESMTP es un protocolo que se utiliza para transportar el 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 ampliado), en lugar de HELO (Hola, 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 HELO o 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 (Envío o correo), SAML (Envío y correo), EXPN, HELP y TURN. Se estableció el formato de verbos SMTP adicionales y para nuevos parámetros en MAIL y RCPT.

Algunas palabras clave relativamente comunes (no todas correspondientes a comandos) que se usan hoy en día son:

• 8BITMIME– Transmisión de datos de 8 bits, RFC 6152
• ATRN– Authenticated TURN para Relé de Correo en Demand, RFC 2645
• AUTH– SMTP autentificado, RFC 4954
• CHUNKING– Chunking, RFC 3030
• DSN– notificación de estado de entrega, RFC 3461 (Ver ruta de retorno de sobre variable)
• ETRN– Versión extendida del comando de arranque de cola de mensajes remotos TURN, RFC 1985
• HELP– Suministro de información útil, RFC 821
• PIPELINING– tubería de mando, RFC 2920
• SIZE– Declaración de 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 buzón y campos de cabecera, RFC 6531
• UTF8SMTP– Permitir la codificación UTF-8 en nombres de buzón y campos de cabecera, RFC 5336 (deprecido)

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. La compatibilidad con el comando EHLO en los servidores se volvió obligatoria y HELO designó un respaldo requerido.

Las extensiones de servicio no estándar, no registradas, se pueden usar mediante un acuerdo bilateral, estos servicios se indican mediante una palabra clave de mensaje EHLO 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
• Gmail
• IceWarp
• IIS SMTP Service
• Kerio Connect
• Lotus Domino
• Microsoft Exchange Server (como Exchange Server 2000)
• Novell GroupWise
• OpenSMTPD
• Oracle Communications Servidor de mensajería
• Postfix
• 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 no 8BITMIME, como exige el RFC. Esto no causa problemas en la práctica, ya que prácticamente todos los relés de correo moderno están limpios de 8 bits.
• Microsoft Exchange Server 2003 anuncia 8BITMIME por defecto, pero retransmitir a un par de no 8BITMIME resultados en un rebote. Esto es 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 se deniega 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 RFC 2822 "De:" encabezamiento. Por ejemplo, la suplantación de identidad, en la que un remitente se hace pasar por otra persona, aún 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 posterior)
• Momentum (versiones 4.1 y 3.6.5 y posteriores)
• Sendmail (en desarrollo)
• Exim (experimental as of the 4.86 release)
• CommuniGate Pro como versión 6.2.2
• Courier-MTA como versión 1.0
• Halon como versión 4.0
• Microsoft Exchange Server como revisión de protocolo 14.0
• Haraka y otros servidores.
• Oracle Communications Servidor de mensajería como de liberación 8.0.2.

Extensiones de seguridad

La entrega de correo puede ocurrir tanto a través de texto sin formato como de conexiones encriptadas, 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 compatibles 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 forma 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 comenzó "STARTTLS Everywhere" proyecto que, de manera similar a "HTTPS Everywhere" lista, permitió a las partes de confianza descubrir a otros 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 pares. Soporte TLS.

RFC 8314 declaró oficialmente obsoleto el texto sin formato y recomienda usar siempre TLS para el envío y el acceso al correo, 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 registros DNS TXT específicos. 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 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 Transport Layer Security con SMTP/MSA, IMAP, POP3 o HTTPS en combinación con una organización. o política 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

Los protocolos diseñados para entregar mensajes de forma segura pueden fallar debido a configuraciones incorrectas o interferencias activas deliberadas, 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 de informes y un formato 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, por lo que la suplantación de identidad por correo electrónico es posible y se usa comúnmente en correo no deseado y phishing.

Se realizan 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 greylisting para rechazar o poner en cuarentena correos electrónicos sospechosos.

Implementaciones

Solicitudes de comentarios relacionadas

• RFC 1123 – Requisitos para hospedadores de Internet—Aplicación y Soporte (STD 3)
• RFC 1870 – Prórroga de Servicio SMTP para la Declaración de Tamaño del Mensaje (obsoletos: RFC 1653)
• RFC 2505 – Recomendaciones antiespama para los TLC SMTP (BCP 30)
• RFC 2821 – Simple Protocolo de Transferencia de Correos
• RFC 2920 – SMTP Extensión de servicio para la tubería de mando (STD 60)
• RFC 3030 – SMTP Extensiones de servicio para la transmisión de MIME grande y binario Mensajes
• RFC 3207 – SMTP Service Extension for Secure SMTP over Transport Layer Security (obsoletes RFC 2487)
• RFC 3461 – SMTP Service Extension for Delivery Status Notifications (obsoletes RFC 1891)
• RFC 3463 – Códigos de Estado mejorados para SMTP (obsoletos RFC 1893, actualizados por RFC 5248)
• RFC 3464 – Formato de mensaje extensible para notificaciones de estado de entrega (obsoletos 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 – SMTP Experiencia operacional en IPv4/v6 mixto Environments
• RFC 4952 – Resumen y Marco para el Email Internacionalizado (actualizado por RFC 5336)
• RFC 4954 – SMTP Service Extension for Authentication (obsoletes RFC 2554, actualizaciones RFC 3463, actualizado por RFC 5248)
• RFC 5068 – Email Submission Operaciones: Necesidades de acceso y rendición de cuentas (BCP 134)
• RFC 5248 – Registro de Códigos de Estado del Sistema de Correo mejorado SMTP (BCP 138) (actualizaciones RFC 3463)
• RFC 5321 – El protocolo de transferencia de correo simple (obsoletes RFC 821 aka STD 10, RFC 974, RFC 1869, RFC 2821, actualiza RFC 1123)
• RFC 5322 – Formato de Mensaje de Internet (obsoletos RFC 822 aka STD 11, y RFC 2822)
• RFC 5504 – Reducción Mechanism for Email Address Internationalization
• RFC 6409 – Mensaje de envío para correo (STD 72) (obsoletes RFC 4409, RFC 2476)
• RFC 6522 – Tipo de Contenido Multiparto/Informe para la Presentación de Informes de Mensajes Administrativos del Sistema de Correo (obsoletos RFC 3462, y a su vez RFC 1892)
• RFC 6531 – Prórroga SMTP para direcciones de correo electrónico internacionalizadas (actualizaciones RFC 2821, RFC 2822, RFC 4952 y RFC 5336)
• RFC 8314 – Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access