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 usan SMTP solo para enviar mensajes a un servidor de correo para su retransmisión y, por lo general, envían correos electrónicos salientes al servidor de correo en el puerto 587 o 465 según RFC 8314. Para recuperar mensajes, IMAP (que reemplazó al antiguo POP3 ) es Los servidores estándar, pero 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 ha actualizado, modificado y ampliado varias veces. La versión del protocolo de uso común hoy en día 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 el puerto número 25 (para texto sin formato) y 587 (para comunicaciones cifradas).
En la década de 1960 se utilizaron diversas formas de mensajería electrónica uno a uno . Los usuarios se comunicaban utilizando sistemas desarrollados para computadoras centrales específicas . A medida que se interconectaron más computadoras, especialmente en ARPANET del gobierno de EE. UU ., se desarrollaron estándares para permitir el intercambio de mensajes entre diferentes sistemas operativos.
El correo en ARPANET tiene sus raíces en 1971: el protocolo de buzón de correo, que no se implementó, [1] 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. [2] [3] [4] Se hizo otra propuesta para un protocolo de correo en RFC 524 en junio de 1973, [5] que no se implementó. [6]
El uso del Protocolo de transferencia de archivos (FTP) para "correo de red" en ARPANET se propuso en RFC 469 en marzo de 1973. [7] A través de RFC 561, RFC 680, RFC 724 y finalmente RFC 733 en noviembre de 1977, un estándar Se desarrolló un marco para el "correo electrónico" utilizando servidores de correo FTP. [8]
SMTP surgió de estos estándares desarrollados durante la década de 1970.
En 1980, Jon Postel y Suzanne Sluizer publicaron el RFC 772 que proponía el Protocolo de transferencia de correo como sustituto del uso del 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 , [ cita requerida ] una asignación que desde entonces ha sido eliminada por la IANA . En noviembre de 1981, Postel publicó el 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 uno a muchos con algunas similitudes. [ cita necesaria ]
SMTP se volvió ampliamente utilizado 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 tanto la máquina emisora como la receptora 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, [9] UUCP como transporte de correo prácticamente ha desaparecido [10] junto con las " rutas de explosión " que utilizaba como encabezados de enrutamiento de mensajes. [11]
Sendmail , lanzado con 4.1cBSD en 1983, fue uno de los primeros agentes de transferencia de correo en implementar SMTP. [12] 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. [13]
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 spam , 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 un retransmisor de correo abierto . El Internet Mail Consortium (IMC) informó que el 55% de los servidores de correo eran retransmisiones abiertas en 1998, [14] pero menos del 1% en 2002. [15] Debido a preocupaciones sobre el spam, la mayoría de los proveedores de correo electrónico incluyen en listas bloqueadas las retransmisiones abiertas, [16] haciendo originales SMTP esencialmente poco práctico para uso general en Internet.
En noviembre de 1995, RFC 1869 definió el Protocolo simple extendido de transferencia de correo (ESMTP), que estableció una estructura general para todas las extensiones existentes y futuras cuyo objetivo era agregar las funciones que faltaban en el SMTP original. ESMTP define medios consistentes y manejables mediante los cuales se pueden identificar los clientes y servidores ESMTP y los servidores pueden indicar las 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 eran típicamente internos de una organización, recibían correo para la organización desde el exterior y transmitían mensajes desde la organización al exterior . Pero a medida que pasó el tiempo, los servidores SMTP (agentes de transferencia de correo), en la práctica, fueron ampliando sus funciones para convertirse en agentes de envío de mensajes para agentes de usuarios de correo , algunos de los cuales ahora retransmitían correo desde el exterior de una organización. (por ejemplo, un ejecutivo de una empresa desea enviar un correo electrónico mientras está de viaje utilizando el servidor SMTP corporativo). Este problema, consecuencia de la rápida expansión y popularidad de la World Wide Web , significó 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 en 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 en él, por ejemplo, agregando un nombre de dominio a una dirección no calificada. Este comportamiento es útil cuando el mensaje que se está arreglando 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 envíos y al mismo tiempo prohibir la reescritura de retransmisión. A medida que el spam se hizo más frecuente, también se vio como una forma de proporcionar autorización para el envío de correo desde una organización, así como también 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 manejaba bien archivos binarios ni caracteres en muchos idiomas distintos del inglés. Se desarrollaron estándares como las Extensiones multipropósito de correo de Internet ( 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 "solo envía ocho" podría usarse para transmitir datos de texto arbitrarios (en cualquier codificación de caracteres tipo ASCII de 8 bits) a través de SMTP. Mojibake seguía siendo un problema debido a las diferentes asignaciones de juegos de caracteres entre los proveedores, aunque las direcciones de correo electrónico todavía permitían solo ASCII . Los MTA de 8 bits limpios hoy en día tienden a admitir la extensión 8BITMIME, lo que permite que algunos archivos binarios se transmitan casi tan fácilmente como el texto sin formato (aún se aplican límites en la longitud de línea y los valores de octeto permitidos, por lo que la codificación MIME es necesaria para la mayoría de los archivos que no son de texto). datos y algunos formatos de texto). En 2012, SMTPUTF8se creó la extensión para admitir texto UTF-8 , lo que permite contenido y direcciones internacionales en escrituras no latinas como cirílico o chino .
Mucha gente contribuyó a las especificaciones centrales de SMTP, entre ellos Jon Postel , Eric Allman , Dave Crocker, Ned Freed , Randall Gellens, John Klensin y Keith Moore .
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 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 iniciado 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 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 emisor selecciona un servidor 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 "retransmisión" intermedio (es decir, almacena y reenvía el mensaje) o una "puerta de enlace" (es decir, puede reenviar el mensaje utilizando algún protocolo distinto de SMTP). Según la sección 2.1 de RFC 5321, cada salto es un traspaso formal de responsabilidad por el mensaje, mediante el cual 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 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 de arriba el MDA se muestra como un cuadro cerca del buzón del intercambiador 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 que los clientes de correo autenticados (MUA) lo recuperen por lotes. El correo se recupera mediante aplicaciones de usuario final, denominadas clientes de correo electrónico, mediante el Protocolo de acceso a mensajes de Internet (IMAP), un protocolo que facilita el acceso al correo y gestiona el correo almacenado, o el Protocolo de oficina postal (POP), que normalmente utiliza 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 utilizar cualquiera de los métodos, pero el protocolo de recuperación no suele ser un estándar formal.
SMTP define el transporte de mensajes , no el contenido del mensaje . Así, define el sobre de 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), denominado formalmente 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 emitiendo cadenas de comandos y suministrando los datos necesarios a través de un canal de flujo de datos ordenado confiable, generalmente 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 escucha o 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:
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ó. Una 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) 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 transmisiones de mensajes que resultaron en fallas transitorias.
Un MUA conoce el servidor SMTP de correo saliente por 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 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: el puerto 25, o para conectarse a un MSA, el puerto 587. La principal diferencia entre un MTA y un MSA es que conectarse a un MSA requiere Autenticación SMTP .
SMTP es únicamente un protocolo de entrega. En uso normal, el correo se "envía" a un servidor de correo de destino (o servidor de correo del siguiente salto) a medida que llega. El correo se enruta según el servidor de destino, no 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 remota a continuación). POP e IMAP son protocolos inadecuados para retransmitir correo mediante 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 del correo (el "sobre de correo").
El inicio remoto de la cola de mensajes permite a un host remoto iniciar el procesamiento de la cola de correo en un servidor para que pueda recibir los mensajes destinados a él enviando el comando correspondiente. El comando original TURNse consideró inseguro y se amplió en RFC 1985 con el comando que opera de manera más segura utilizando un método de autenticación basado en la información del Sistema de nombres de dominio . [19]ETRN
Un cliente de correo electrónico necesita conocer 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á mensajes salientes en nombre del usuario.
Los administradores del servidor deben imponer cierto control sobre qué clientes pueden utilizar el servidor. Esto les permite hacer frente a abusos, por ejemplo, spam . Se han utilizado dos soluciones de forma comú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 precisamente, el servidor sólo podrá permitir el acceso a usuarios con una dirección IP proporcionada por el ISP, lo que equivale a exigir que estén conectados a Internet utilizando ese mismo ISP. Un usuario móvil a menudo puede estar en una red distinta a la de su ISP normal y luego descubrir que el envío de correo electrónico falla porque ya no se puede acceder a la opción de servidor SMTP configurada.
Este sistema tiene varias variaciones. Por ejemplo, el servidor SMTP de una organización sólo puede proporcionar servicio a usuarios de la misma red, imponiendo esto mediante un cortafuegos 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 los utilizaban normalmente 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 ahora utilizan métodos de autenticación de clientes, como se describe a continuación.
Cuando un usuario es móvil y puede utilizar diferentes ISP para conectarse a Internet, este tipo de restricción de uso es oneroso y no es práctico alterar la dirección del servidor SMTP de correo electrónico saliente configurado. Es muy deseable poder utilizar información de configuración del cliente de correo electrónico que no sea necesario cambiar.
Los servidores SMTP modernos normalmente requieren 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.
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 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:
Algunos proveedores individuales pueden utilizar el puerto 2525 y otros, pero nunca han sido compatibles oficialmente.
Muchos proveedores de servicios de Internet ahora bloquean todo el tráfico saliente del puerto 25 de sus clientes. Principalmente como medida antispam, [20] pero también para subsanar el mayor coste que tienen al dejarlo abierto, quizás cobrando más a los pocos clientes que lo requieren abierto.
En el siguiente intercambio de sesiones se reproduce un ejemplo típico de envío de un mensaje vía SMTP a dos buzones de correo ( alice y theboss ) ubicados en el mismo dominio de correo ( ejemplo.com ). (En este ejemplo, las partes de la conversación tienen el prefijo S: y C: , para servidor y cliente , respectivamente; estas etiquetas no forman parte del intercambio).
Después de 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.ejemplo. .com . El cliente inicia su diálogo respondiendo con un HELOcomando identificándose en el parámetro del comando con su FQDN (o una dirección literal si no hay ninguna disponible). [21]
S: 220 smtp.example.com ESMTP Postfix C: HELO retransmisión.example.org S: 250 Hola retransmisión.example.org, encantado de conocerte C: CORREO DE:<[email protected]> S: 250 Ok C: RCPT A:<[email protected]> S: 250 Ok C: RCPT A:<[email protected]> S: 250 Ok C: DATA S: 354 Finalizar datos con <CR><LF>.<CR ><LF> 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: SALIR 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 -0500Subject: 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 devolución o devolución en caso de que el mensaje no pueda entregarse. 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 enumerado en los campos de encabezado To:y Cc:. El comando SMTP correspondiente es RCPT TO. El servidor reconoce cada recepción y ejecución exitosa de un comando 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 palabra por palabra línea por línea y finaliza 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 solo un punto como parte del texto, el cliente envía dos puntos cada vez que una línea comienza con un punto; en consecuencia, el servidor reemplaza cada secuencia de dos puntos al comienzo de una línea por 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 se puede duplicar si hay un fallo de comunicación en ese 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. [22] La probabilidad de que ocurra una falla de comunicación exactamente en este paso es directamente proporcional a la cantidad de filtrado que el servidor realiza en el cuerpo del mensaje, generalmente con fines antispam. El tiempo de espera límite se especifica en 10 minutos. [23]
El QUITcomando finaliza la sesión. Si el correo electrónico tiene otros destinatarios ubicados en otro lugar, el cliente se QUITconectará a un servidor SMTP apropiado para los destinatarios posteriores después de que los destinos actuales hayan sido puestos 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 por parte del servidor receptor. Agrega un campo Receivedy Return-Pathencabezado, 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 es posible que se omitan las dos últimas líneas. Esto provoca un error en el servidor al intentar enviar la 221 Byerespuesta.
Los clientes aprenden las opciones admitidas por un servidor usando el EHLOsaludo, como se ejemplifica a continuación, en lugar del original HELO. Los clientes recurren HELOsolo si el servidor no admite EHLOsaludos. [24]
Los clientes modernos pueden utilizar la palabra clave de extensión ESMTP SIZEpara consultar al servidor 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 la red, incluido el tiempo de conexión a los enlaces de la red que se paga por minuto. [25]
Los usuarios pueden determinar manualmente de antemano el tamaño máximo aceptado por los servidores ESMTP. El cliente reemplaza el HELOcomando con el EHLOcomando.
S: 220 smtp2.example.com ESMTP Postfix C: EHLO bob.example.org S: 250-smtp2.example.com Hola bob.example.org [192.0.2.201] S : TAMAÑO 250 14680064 S: TUBERÍAS 250 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 archivo EHLO. Sin embargo, segú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 admite solo un cuerpo de texto ASCII, por lo tanto, cualquier dato binario debe codificarse como texto en ese cuerpo del mensaje antes de la transferencia y luego el destinatario debe decodificarlo. Normalmente se utilizaban codificaciones de binario a texto , como uuencode y BinHex .
El comando 8BITMIME fue desarrollado para solucionar este problema. Fue estandarizado en 1994 como RFC 1652 [26] . Facilita el intercambio transparente de mensajes de correo electrónico que contienen octetos fuera del conjunto de caracteres ASCII de siete bits codificándolos como partes de contenido MIME , normalmente codificadas con Base64 .
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.
SMTP original admite direcciones de correo electrónico compuestas únicamente de caracteres ASCII , lo cual resulta inconveniente para los usuarios cuya escritura nativa no está basada en el latín o que utilizan signos diacríticos que no están en el conjunto de caracteres ASCII. Esta limitación se alivió mediante extensiones que permitieron UTF-8 en los nombres de direcciones. RFC 5336 introdujo el comando experimental [25] y luego fue reemplazado por el RFC 6531 que introdujo el comando. Estas extensiones brindan soporte para caracteres multibyte y no ASCII en direcciones de correo electrónico, como aquellas con signos diacríticos y caracteres de otros idiomas, como griego y chino . [27] UTF8SMTPSMTPUTF8
El soporte actual es limitado, pero existe un gran interés en una amplia adopción 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 utilizado para transportar correo de Internet. Se utiliza como protocolo de transporte entre servidores y (con un comportamiento restringido impuesto) como protocolo de envío de correo.
La principal característica de identificación para los clientes ESMTP es abrir una transmisión con el comando EHLO(HOLA extendido), en lugar de (Hola, el estándar RFCHELO 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 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 RFC 821: SEND, SOML(Enviar o enviar por correo), SAML(Enviar y enviar por correo), EXPN, HELPy TURN. Se configuró el formato de los verbos SMTP adicionales y para los nuevos parámetros en MAILy RCPT.
Algunas palabras clave relativamente comunes (no todas correspondientes a comandos) utilizadas hoy en día son:
8BITMIME – Transmisión de datos de 8 bits, RFC 6152ATRN – Autenticado TURNpara retransmisión de correo bajo demanda , RFC 2645AUTH – SMTP autenticado, RFC 4954CHUNKING – Fragmentación, RFC 3030DSN – Notificación de 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 remota TURN, RFC 1985HELP – Proporcionar información útil, RFC 821PIPELINING – Canalización de comandos, RFC 2920SIZE – Declaración del tamaño del mensaje, RFC 1870STARTTLS – Seguridad de la capa de transporte , RFC 3207 (2002)SMTPUTF8 – Permitir codificación UTF-8 en nombres de buzones y campos de encabezado, RFC 6531UTF8SMTP – Permitir codificación UTF-8 en nombres de buzones y campos de encabezado, RFC 5336 (obsoleto [28] )El formato ESMTP se reformuló en RFC 2821 (que reemplaza a RFC 821) y se actualizó a la última definición en RFC 5321 en 2008. La compatibilidad con el comando en servidores se volvió obligatoria y designó un respaldo requerido.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 únicamente para dar énfasis. Un servidor SMTP que requiere un método de capitalización específico es una violación del estándar. [ cita necesaria ]
Al menos los siguientes servidores anuncian la extensión 8BITMIME:
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:
La extensión SMTP-AUTH proporciona un mecanismo de control de acceso. Consiste en un paso de autenticación mediante el 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 exigir que los clientes utilicen esta extensión, lo que garantiza que se conozca la verdadera identidad del remitente. La extensión SMTP-AUTH está definida en RFC 4954.
SMTP-AUTH se puede utilizar para permitir a los usuarios legítimos retransmitir correo y al mismo tiempo negar 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 RFC 2822 "De:". 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 mensajes a 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 destinatario confíe en el servidor emisor, lo que significa que este aspecto de SMTP-AUTH rara vez se utiliza en Internet. [ cita necesaria ]
Los servidores de soporte incluyen:
La entrega de correo puede realizarse tanto a través de texto plano como de conexiones cifradas; sin embargo, es posible que las partes que se comunican no sepan de antemano la capacidad de la otra parte para utilizar 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 la oportunidad a los clientes de actualizar 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 TLS depende de que el cliente que se conecta decida ejercer esta opción, de ahí el término TLS oportunista .
STARTTLS es efectivo sólo contra ataques de observación pasiva, ya que la negociación STARTTLS ocurre en texto plano y un atacante activo puede eliminar trivialmente los comandos STARTTLS. Este tipo de ataque de intermediario 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 admite adecuadamente STARTTLS, por lo que se utiliza de forma predeterminada la transferencia de correo de texto sin formato tradicional. [41] Tenga en cuenta que STARTTLS también se define para IMAP y POP3 en otros RFC, pero estos protocolos sirven para 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, la Electronic Frontier Foundation inició el proyecto "STARTTLS Everywhere" que, de manera similar a la lista " HTTPS Everywhere ", permitió a las partes confiantes descubrir otras que admitieran 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 sus pares. [42]
RFC 8314 declara oficialmente obsoleto el texto sin formato y recomienda usar siempre TLS para el envío y acceso al correo, agregando puertos con TLS implícito.
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 comprobaría periódicamente la existencia de dicho registro, 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 el registro caduque. [41] 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. Básicamente, MTA-STS es un medio para extender dicha política a terceros.
En abril de 2019, Google Mail anunció compatibilidad con MTA-STS. [43]
Los protocolos diseñados para entregar mensajes de forma segura pueden fallar debido a configuraciones erróneas o interferencia activa deliberada, lo que provoca mensajes no entregados o entrega a través de canales no cifrados o no autenticados. RFC 8460 "Informes SMTP TLS" describe un mecanismo y formato de informes para compartir estadísticas e información específica sobre posibles fallas con los dominios de los destinatarios. Luego, los dominios de los destinatarios pueden utilizar esta información para detectar posibles ataques y diagnosticar configuraciones erróneas no intencionadas.
En abril de 2019, Google Mail anunció compatibilidad con informes SMTP TLS. [43]
El diseño original de SMTP no tenía ninguna función para autenticar a los remitentes ni verificar que los servidores estuvieran autorizados para enviar en su nombre, con el resultado de que la suplantación de correo electrónico es posible y se usa comúnmente en correo no deseado y phishing .
Ocasionalmente se hacen propuestas para modificar SMTP ampliamente o reemplazarlo por completo. Un ejemplo de ello es Internet Mail 2000 , pero ni él ni ningún otro ha avanzado mucho ante el 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, [44] [45] DomainKeys Identified Mail , Sender Policy Framework y DMARC , DNSBL y listas grises para rechazar o poner en cuarentena correos electrónicos sospechosos. [46]
El mes pasado, la Anti-Spam Technical Alliance, formada el año pasado por Yahoo, America Online, EarthLink y Microsoft, publicó una lista de recomendaciones antispam que incluye el filtrado del Puerto 25.
v4.0: Nuevo soporte SMTPUTF8Actualizado para nuevas versiones.