stringtranslate.com

Protocolo simple de transferencia de correo

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

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

Historia

Predecesores de SMTP

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

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

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

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

SMTP original

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

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

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

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

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

SMTP moderno

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

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

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

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

Modelo de procesamiento de correo

Las flechas azules representan la implementación de variaciones de SMTP

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

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

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

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

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

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

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 y fiable, normalmente una conexión de Protocolo de control de transmisión (TCP). Una sesión SMTP consta de comandos originados por un cliente SMTP (el agente iniciador , remitente o transmisor) y las respuestas correspondientes del servidor SMTP (el agente de escucha o receptor) de modo que se abre la sesión y se intercambian los parámetros de la sesión. Una sesión puede incluir cero o más transacciones SMTP. Una transacción SMTP consta de tres secuencias de comando/respuesta:

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

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

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

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

SMTP vs recuperación de correo

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

Inicio de cola de mensajes remota

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

Servidor SMTP de correo saliente

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

Restricciones de acceso al servidor de correo saliente

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

Restringir el acceso por ubicación

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

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

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

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 como SMTP AUTH, es una extensión del SMTP para iniciar sesión mediante un mecanismo de autenticación.

Puertos

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

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

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

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

Ejemplo de transporte SMTP

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

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

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

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

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

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

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

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

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 a HELOsolo si el servidor no admite EHLOel saludo. [30]

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

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

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

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

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

Transferencia de datos binarios

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

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

Extensiones del mecanismo de entrega de correo

Retransmisión de correo a pedido

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

Extensión de internacionalización

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

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

Extensiones

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

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

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

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

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

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

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

8BITMIME

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 relés que no son 8BITMIME:

Autenticación SMTP

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

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

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

SMTPUTF8

Los servidores de soporte incluyen:

Extensiones de seguridad

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

STARTTLS o "TLS oportunista"

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

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

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

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

DANE para SMTP

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

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

Seguridad de transporte estricta del MTA SMTP

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

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

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 da lugar a mensajes no entregados o a la entrega a través de canales no cifrados o no autenticados. RFC  8460 "SMTP TLS Reporting" describe un mecanismo y un formato de informes para compartir estadísticas e información específica sobre posibles fallas con los dominios de los destinatarios. Los dominios de los destinatarios pueden utilizar esta información para detectar posibles ataques y diagnosticar configuraciones incorrectas no intencionales.

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

Suplantación de identidad y envío de correo basura

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

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

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

Implementaciones

Véase también

Notas

  1. ^ La historia del correo electrónico Archivado el 2 de diciembre de 2017 en Wayback Machine . Tom Van Vleck : " No está claro si este protocolo se implementó alguna vez "
  2. ^ El primer correo electrónico en red, Ray Tomlinson , BBN
  3. ^ Imagen de "La primera computadora con correo electrónico" de Dan Murphy, una PDP-10
  4. ^ Documentos de Dan Murphy sobre TENEX y TOPS-20 Archivados el 18 de noviembre de 2007 en Wayback Machine .
  5. ^ RFC  524 – Propuesta de protocolo de correo
  6. ^ Crocker, David H. (diciembre de 1977). «Marco y funciones del sistema de mensajes personales «MS»» (PDF) . The RAND Corporation . Archivado (PDF) del original el 13 de mayo de 2022. Consultado el 17 de abril de 2022 .
  7. ^ RFC  469 – Resumen de la reunión sobre correo en red
  8. ^ RFC 733, 21 de noviembre de 1977, Norma para el formato de mensajes de texto de la red ARPA
  9. ^ "Una historia del correo electrónico: colaboración, innovación y el nacimiento de un sistema". Washington Post . 20 de mayo de 2023. ISSN  0190-8286 . Consultado el 7 de julio de 2024 .
  10. ^ McKenzie, Alexander (2011). "INWG y la concepción de Internet: un relato de testigo ocular". IEEE Annals of the History of Computing . 33 (1): 66–71. doi :10.1109/MAHC.2011.9. ISSN  1934-1547. S2CID  206443072.
  11. ^ Barber, D. y J. Laws, "Un esquema de correo básico para EIN", INWG 192, febrero de 1979.
  12. ^ IEN 85.
  13. ^ IEN 113.
  14. ^ "Índice de notas sobre experimentos de Internet". www.rfc-editor.org . Consultado el 7 de julio de 2024 .
  15. ^ "Tldp.org". Archivado desde el original el 17 de agosto de 2007. Consultado el 25 de agosto de 2007 .
  16. ^ Barber, Stan O. (19 de diciembre de 2000). «draft-barber-uucp-project-conclusion-05 – La conclusión del proyecto de mapeo UUCP». Archivado desde el original el 13 de octubre de 2007. Consultado el 25 de agosto de 2007 .
  17. ^ El artículo sobre la reescritura del remitente contiene información técnica básica sobre el historial de SMTP y el enrutamiento de origen antes del RFC  1123.
  18. ^ Eric Allman (1983), Sendmail – An Internetwork Mail Router (PDF) , conjunto de documentación BSD UNIX, Berkeley: Universidad de California, archivado (PDF) del original el 20 de mayo de 2013 , consultado el 29 de junio de 2012
  19. ^ Craig Partridge (2008), El desarrollo técnico del correo electrónico en Internet (PDF) , IEEE Annals of the History of Computing, vol. 30, IEEE Computer Society, págs. 3-29, doi :10.1109/MAHC.2008.32, S2CID  206442868, archivado desde el original (PDF) el 12 de mayo de 2011
  20. Paul Hoffman (1 de febrero de 1998). «Permitir la retransmisión en SMTP: una encuesta». Internet Mail Consortium . Archivado desde el original el 5 de marzo de 2016. Consultado el 30 de mayo de 2010 .
  21. ^ Paul Hoffman (agosto de 2002). "Permitir la retransmisión en SMTP: una serie de encuestas". Internet Mail Consortium . Archivado desde el original el 18 de enero de 2007. Consultado el 30 de mayo de 2010 .
  22. ^ "En Unix, ¿qué es un relé de correo abierto? - Base de conocimiento". 17 de junio de 2007. Archivado desde el original el 17 de junio de 2007 . Consultado el 15 de marzo de 2021 .
  23. ^ "Los verbos MAIL, RCPT y DATA" Archivado el 22 de febrero de 2014 en Wayback Machine . [DJ Bernstein]
  24. ^ RFC  5321 Sección 7.2
  25. ^ Sistemas, Mensaje. "Message Systems presenta la última versión de Momentum con nuevas capacidades basadas en API". www.prnewswire.com (Nota de prensa). Archivado desde el original el 19 de julio de 2020 . Consultado el 19 de julio de 2020 .
  26. ^ Cara Garretson (2005). "Los ISP colaboran para detener el spam". PC World . Archivado desde el original el 28 de agosto de 2015. Consultado el 18 de enero de 2016. 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.
  27. ^ RFC  5321, Protocolo simple de transferencia de correo , J. Klensin, The Internet Society (octubre de 2008)
  28. ^ RFC  1047
  29. ^ Klensin, John C. (octubre de 2008). "rfc5321#sección-4.5.3.2.6". Archivado desde el original el 16 de enero de 2015 . Consultado el 7 de junio de 2010 .
  30. ^ John Klensin; Ned Freed; Marshall T. Rose; Einar A. Stefferud; Dave Crocker (noviembre de 1995). Extensiones del servicio SMTP. IETF . doi : 10.17487/RFC1869 . RFC 1869.
  31. ^ ab "Parámetros de MAIL". IANA. 14 de febrero de 2020. Archivado desde el original el 28 de mayo de 2019 . Consultado el 28 de mayo de 2019 .
  32. ^ Que quedó obsoleto en 2011 por el RFC  6152 correspondiente al entonces nuevo STD 71
  33. ^ Jiankang Yao (19 de diciembre de 2014). «Dirección de correo electrónico china». EAI (Lista de correo). IETF . Archivado desde el original el 2 de octubre de 2015. Consultado el 24 de mayo de 2016 .
  34. ^ "Parámetros de extensión del servicio SMTP". IANA. Archivado desde el original el 28 de mayo de 2019. Consultado el 5 de noviembre de 2013 .
  35. ^ Klensin, John C. (octubre de 2008). Protocolo simple de transferencia de correo (informe). Grupo de trabajo de ingeniería de Internet.
  36. ^ James Server - Registro de cambios Archivado el 20 de febrero de 2020 en Wayback Machine . James.apache.org. Consultado el 17 de julio de 2013.
  37. ^ Servicio 8BITMIME anunciado en respuesta a EHLO en gmail-smtp-in.l.google.com puerto 25, verificado el 23 de noviembre de 2011
  38. ^ Errores y lista de deseos de Qmail. Home.pages.de. Consultado el 17 de julio de 2013.
  39. ^ La extensión 8BITMIME Archivado el 7 de junio de 2011 en Wayback Machine . Cr.yp.to. Consultado el 17 de julio de 2013.
  40. ^ "La compatibilidad con Postfix SMTPUTF8 está habilitada de forma predeterminada" Archivado el 7 de agosto de 2020 en Wayback Machine , 8 de febrero de 2015, postfix.org
  41. ^ "Message Systems presenta la última versión de Momentum con nuevas capacidades basadas en API" (nota de prensa). Archivado desde el original el 15 de septiembre de 2020 . Consultado el 17 de septiembre de 2020 .
  42. ^ "Historial de revisiones de la versión 6.2". CommuniGate.com . Archivado desde el original el 29 de octubre de 2020. Consultado el 17 de septiembre de 2020 .
  43. ^ Sam Varshavchik (18 de septiembre de 2018). «Nuevos lanzamientos de paquetes de Courier». courier-announce (Lista de correo). Archivado desde el original el 17 de agosto de 2021 . Consultado el 17 de septiembre de 2020 .
  44. ^ "Registro de cambios de Halon MTA". GitHub . 9 de noviembre de 2021. Archivado desde el original el 18 de septiembre de 2020 . Consultado el 17 de septiembre de 2020 . v4.0: Nueva compatibilidad con SMTPUTF8Actualizado para nuevas versiones
  45. ^ "MS-OXSMTP: extensiones del Protocolo simple de transferencia de correo (SMTP)". 24 de julio de 2018. Archivado desde el original el 16 de agosto de 2021. Consultado el 17 de septiembre de 2020 .
  46. ^ "EAI Readiness in TLDs" (PDF) . 12 de febrero de 2019. Archivado (PDF) del original el 24 de enero de 2021 . Consultado el 17 de septiembre de 2020 .
  47. ^ "Notas de la versión de Communications Messaging Server". oracle.com . Octubre de 2017. Archivado desde el original el 24 de noviembre de 2020 . Consultado el 17 de septiembre de 2020 .
  48. ^ ab "Presentación de MTA Strict Transport Security (MTA-STS) | Blog de Hardenize". www.hardenize.com . Archivado desde el original el 25 de abril de 2019 . Consultado el 25 de abril de 2019 .
  49. ^ "STARTTLS Everywhere". EFF. Archivado desde el original el 9 de agosto de 2019. Consultado el 4 de diciembre de 2021 .
  50. ^ v-mathavale (21 de julio de 2023). "Cómo la autenticación de entidades con nombre (DANE) basada en DNS de SMTP protege las comunicaciones por correo electrónico". learn.microsoft.com . Consultado el 5 de marzo de 2024 .
  51. ^ "Implementación de DANE SMTP entrante con DNSSEC para el flujo de correo de Exchange Online". techcommunity.microsoft.com . Consultado el 5 de marzo de 2024 .
  52. ^ ab Cimpanu, Catalin. "Gmail se convierte en el primer proveedor de correo electrónico importante en admitir informes MTA-STS y TLS". ZDNet . Archivado desde el original el 29 de abril de 2019. Consultado el 25 de abril de 2019 .
  53. ^ "Mensaje no conforme con RFC 5322". Archivado desde el original el 17 de enero de 2023 . Consultado el 20 de enero de 2021 .
  54. ^ "No se pudo enviar el mensaje. Asegúrese de que el mensaje cumpla con la norma RFC 5322". Archivado desde el original el 28 de enero de 2021 . Consultado el 20 de enero de 2021 .
  55. ^ "¿Por qué los correos enviados a la cuenta Microsoft son rechazados por razones de política?". Archivado desde el original el 14 de febrero de 2021. Consultado el 20 de enero de 2021 .

Referencias

Lectura adicional

Enlaces externos