Hispanopedia Wiki
Articulo de referencia

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

Hispanopedia WikiContenido en espanolLectura gratuita

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 únicamente para enviar mensajes a un servidor de correo para su reenvío, y normalmente envían el correo saliente al servidor de correo a través del puerto 465 o 587, según la RFC 8314. Para recuperar mensajes, se utilizan ampliamente IMAP y POP , pero los servidores propietarios también suelen implementar protocolos propietarios, por ejemplo, Exchange ActiveSync . 

El protocolo SMTP se originó en 1980, basándose en conceptos implementados en ARPANET desde 1971. Ha sido actualizado, modificado y ampliado en múltiples ocasiones. La versión del protocolo de uso común hoy en día tiene una estructura extensible con diversas extensiones para autenticación , cifrado , transferencia de datos binarios y direcciones de correo electrónico internacionalizadas . Los servidores SMTP suelen usar el Protocolo de Control de Transmisión en los puertos 25 (entre servidores) y 587 (para el envío de clientes autenticados), con o sin cifrado, y en el puerto 465 con cifrado para el envío.

Historia

Predecesores de SMTP

En la década de 1960 se utilizaron diversas formas de mensajería electrónica individual . Los usuarios se comunicaban mediante sistemas desarrollados para ordenadores centrales específicos . A medida que se interconectaban más ordenadores, especialmente en la red ARPANET del gobierno estadounidense , 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 entre dos computadoras en ARPANET. [ 2 ] [ 3 ] [ 4 ] En junio de 1973 se presentó otra propuesta para un Protocolo de Correo en el RFC 524, [ 5 ] que tampoco se implementó. [ 6 ] 

El uso del Protocolo de Transferencia de Archivos (FTP) para el "correo de red" en ARPANET se propuso en el RFC 469 en marzo de 1973. [ 7 ] A través de los 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 ]

SMTP surgió de estos estándares desarrollados durante la década de 1970. Ray Tomlinson habló sobre el correo en red entre el Grupo Internacional de Trabajo de Redes (INWG) en la nota de protocolo 2 , escrita en septiembre de 1974. [ 10 ] El INWG discutió protocolos para 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 de Experimentos 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 a FTP y asignó el puerto 57 para TCP y UDP , [ 15 ] una asignación que posteriormente fue 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 de uno a muchos con algunas similitudes. [ 15 ]

SMTP se popularizó a principios de la década de 1980. En aquel entonces, complementaba el Programa de Copia de Unix a Unix (UUCP), más adecuado para gestionar transferencias de correo electrónico entre máquinas con conexión intermitente. SMTP, en cambio, funciona mejor cuando tanto la máquina emisora ​​como la receptora están conectadas a la red permanentemente. 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, [ 16 ] UUCP como protocolo de transporte de correo prácticamente ha desaparecido [ 17 ] junto con las " rutas bang " que utilizaba como encabezados de enrutamiento de mensajes. [ 18 ]

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

El protocolo SMTP original solo admitía comunicaciones de texto ASCII de 7 bits no autenticadas y sin cifrar, susceptibles a ataques de intermediario , suplantación de identidad y spam , y requería que cualquier dato binario se codificara a 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, [ 21 ] pero menos del 1 % en 2002. [ 22 ] Debido a las preocupaciones por el spam, la mayoría de los proveedores de correo electrónico bloquean los relés abiertos, [ 23 ] lo que hace que el SMTP original sea esencialmente impráctico para el uso general en Internet.

SMTP moderno

En noviembre de 1995, el RFC 1869 definió el Protocolo de Transferencia de Correo Simple Extendido (ESMTP), que estableció una estructura general para todas las extensiones existentes y futuras, con el objetivo de incorporar las funcionalidades que faltaban en el SMTP original. ESMTP define métodos consistentes y manejables para identificar clientes y servidores ESMTP, y para que los servidores indiquen las extensiones compatibles. 

El envío de mensajes ( RFC 2476 ) y la autenticación SMTP ( RFC 2554 ) se introdujeron en 1998 y 1999, respectivamente, describiendo nuevas tendencias en la entrega de correo electrónico. Originalmente, los servidores SMTP solían ser internos a una organización, recibiendo correo para la organización desde el exterior y reenviando mensajes de la organización al exterior . Pero con el tiempo, los servidores SMTP (agentes de transferencia de correo) ampliaron sus funciones para convertirse en agentes de envío de mensajes para agentes de usuario de correo , algunos de los cuales ahora reenviaban correo desde fuera de una organización (por ejemplo, un ejecutivo de la empresa desea enviar un correo electrónico durante un viaje utilizando el servidor SMTP corporativo). Este problema, consecuencia de la rápida expansión y popularidad de la World Wide Web , implicó que SMTP tuviera que incluir reglas y métodos específicos para reenviar correo y autenticar usuarios para prevenir abusos como el reenvío de correo electrónico no solicitado ( spam ). El trabajo sobre el envío de mensajes ( RFC 2476 ) se inició debido a que los servidores de correo más populares solían reescribir los mensajes para corregir problemas, como añadir un nombre de dominio a una dirección no cualificada. Este comportamiento resulta útil cuando el mensaje que se corrige es un envío inicial, pero es peligroso y perjudicial cuando el mensaje se origina en otro lugar y se reenvía. Se consideró que separar claramente el correo en envío y reenvío era una forma de permitir y fomentar la reescritura de los envíos, al tiempo que se prohibía la reescritura del reenvío. Con el aumento del spam, también se consideró una forma de autorizar el envío de correo desde una organización, además de facilitar la trazabilidad. Esta separación entre reenvío y envío se convirtió rápidamente en la base de las prácticas modernas de seguridad del correo electrónico.   

As this protocol started out purely ASCII text-based, it did not deal well with binary files, or characters in many non-English languages. Standards such as Multipurpose Internet Mail Extensions (MIME) were developed to encode binary files for transfer through SMTP. Mail transfer agents (MTAs) developed after Sendmail also tended to be implemented 8-bit clean, so that the alternate "just send eight" strategy could be used to transmit arbitrary text data (in any 8-bit ASCII-like character encoding) via SMTP. Mojibake was still a problem due to differing character set mappings between vendors, although the email addresses themselves still allowed only ASCII. 8-bit-clean MTAs today tend to support the 8BITMIME extension, permitting some binary files to be transmitted almost as easily as plain text (limits on line length and permitted octet values still apply, so that MIME encoding is needed for most non-text data and some text formats). In 2012, the SMTPUTF8 extension was created to support UTF-8 text, allowing international content and addresses in non-Latin scripts like Cyrillic or Chinese.

Many people contributed to the core SMTP specifications, among them Jon Postel, Eric Allman, Dave Crocker, Ned Freed, Randall Gellens, John Klensin, and Keith Moore.

Mail processing model

Blue arrows depict implementation of SMTP variations.

Email is submitted by a mail client (mail user agent, MUA) to a mail server (mail submission agent, MSA) using SMTP on TCP port 465 or 587. Most mailbox providers still allow submission on traditional port 25. The MSA delivers the mail to its mail transfer agent (MTA). Often, these two agents are instances of the same software launched with different options on the same machine. Local processing can be done either on a single machine, or split among multiple machines; mail agent processes on one machine can share files, but if processing is on multiple machines, they transfer messages between each other using SMTP, where each machine is configured to use the next machine as a smart host. Each process is an MTA (an SMTP server) in its own right.

El MTA de borde utiliza DNS para buscar el registro MX (servidor 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 remitente selecciona un servidor receptor y se conecta a él para completar el intercambio de correo.

La transferencia de mensajes puede realizarse mediante una única conexión entre dos MTA o a través de una serie de saltos mediante sistemas intermedios. Un servidor SMTP receptor puede ser el destino final, un "retransmisor" intermedio (que almacena y reenvía el mensaje) o una "puerta de enlace" (que puede reenviar el mensaje utilizando un protocolo distinto de SMTP). Según la sección 2.1 de la RFC 5321 , cada salto constituye una transferencia formal de la responsabilidad del mensaje, por la cual el servidor receptor debe entregarlo o informar adecuadamente de su fallo. 

Una vez que el último nodo acepta el mensaje entrante, lo entrega a un agente de entrega de correo (MDA) para su distribución local. Un MDA guarda los mensajes en el formato de buzón correspondiente . Al igual que con el envío, la recepción puede realizarse con uno o varios ordenadores, pero en el diagrama anterior el MDA se representa como un recuadro cerca del buzón del intercambiador de correo. Un MDA puede entregar los mensajes directamente al almacenamiento o reenviarlos a través de una red mediante SMTP u otro protocolo como el Protocolo de Transferencia de Correo Local (LMTP), una variante de SMTP diseñada para este fin.

Una vez entregado al servidor de correo local, el correo se almacena para su recuperación por lotes mediante clientes de correo autenticados (MUA). Las aplicaciones de usuario final, denominadas clientes de correo electrónico, recuperan el correo mediante el Protocolo de Acceso a Mensajes de Internet (IMAP), un protocolo que facilita el acceso al correo y gestiona el correo almacenado, o mediante el Protocolo de Oficina Postal (POP), que normalmente utiliza el formato de archivo de correo tradicional mbox 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 de mensajes , no el contenido del mensaje . Por lo tanto, define el sobre del correo y sus parámetros, como el remitente del sobre , pero no la cabecera (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 (cabecera y cuerpo), conocido formalmente como 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 mediante el envío 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 TCP ( Protocolo de Control de Transmisión ). 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 receptor o receptor) para que se abra la sesión y se intercambien los parámetros de la misma. 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, [ 24 ] ruta inversa, [ 25 ] dirección de rebote , mfrom o remitente del sobre.
  2. El comando RCPT se utiliza para establecer el destinatario del mensaje. Este comando puede emitirse varias veces, una por cada destinatario. Estas direcciones también forman parte del sobre.
  3. DATA indica el inicio del texto del mensaje ; es decir, el contenido del mensaje, a diferencia de su sobre. Consta de una cabecera y un cuerpo del mensaje separados por una línea en blanco. DATA es en realidad un conjunto de comandos, y el servidor responde dos veces: una vez al comando DATA , para confirmar que está listo para recibir el texto, y una segunda vez, tras la secuencia de fin de datos, para aceptar o rechazar el mensaje completo.

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 indica un fallo 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 iniciador, el cliente SMTP, puede ser el cliente de correo electrónico de un usuario final , identificado funcionalmente como agente de usuario de correo (MUA), o el agente de transferencia de correo (MTA) de un servidor de retransmisión, es decir, un servidor SMTP que actúa como cliente SMTP en la sesión correspondiente para reenviar el correo. Los servidores SMTP con plena capacidad mantienen colas de mensajes para reintentar las transmisiones que hayan sufrido fallos transitorios.

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 conforme (no todos lo son) busca en su lugar el registro A. Los servidores de retransmisión también se pueden configurar para usar un host inteligente . Un servidor de retransmisión inicia una conexión TCP al servidor en el " puerto conocido " para SMTP: puerto 25, o para conectarse a un MSA, puerto 465 o 587. La principal diferencia entre un MTA y un MSA es que la conexión a un MSA requiere autenticación SMTP .

SMTP frente a recuperación de correo

SMTP es un protocolo de entrega únicamente. En su 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 en función del servidor de destino, no del usuario o usuarios individuales a los que va dirigido. Otros protocolos, como el Protocolo de Oficina de Correos (POP) y el Protocolo de Acceso a Mensajes de Internet (IMAP), están diseñados específicamente para que los usuarios individuales recuperen mensajes y administren buzones de correo . Para permitir que un servidor de correo con conexión intermitente extraiga mensajes de un servidor remoto bajo demanda, SMTP cuenta con una función para iniciar el procesamiento de la cola de correo en un servidor remoto (véase Inicio de la cola de mensajes remotos más adelante). POP e IMAP no son protocolos adecuados para el reenvío de correo por parte de máquinas con conexión 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 del reenvío 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 inicie el procesamiento de la cola de correo en un servidor para que pueda recibir los mensajes destinados a él mediante el envío de un comando correspondiente. El TURNcomando original se consideró inseguro y se amplió en el RFC 1985 con el comando que opera de forma más segura utilizando un método de autenticación basado en la información del Sistema de nombres de dominio . [ 26 ] ETRN

Servidor SMTP de correo saliente

Un cliente de correo electrónico necesita conocer la dirección IP de su servidor SMTP inicial, la cual debe especificarse en su configuración (generalmente como un nombre DNS ). Este servidor se encargará de enviar los mensajes salientes en nombre del usuario.

Restricciones de acceso al servidor de correo saliente

Los administradores de servidores necesitan imponer cierto control sobre qué clientes pueden usar el servidor. Esto les permite lidiar con abusos, por ejemplo, el spam . Se han utilizado comúnmente dos soluciones:

  • Anteriormente, muchos sistemas imponían restricciones de uso según la ubicación del cliente, permitiendo únicamente el acceso a clientes cuya dirección IP estuviera controlada por los administradores del servidor. El acceso desde cualquier otra dirección IP de cliente estaba prohibido.
  • Los servidores SMTP modernos suelen ofrecer un sistema alternativo que requiere la autenticación de los clientes mediante credenciales antes de permitir el acceso.

Restricción de acceso por ubicación

Bajo este sistema, el servidor SMTP de un proveedor de servicios de Internet (ISP) no permitirá el acceso a usuarios que se encuentren fuera de su red. Más precisamente, el servidor solo 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 a través de ese mismo ISP. Un usuario móvil a menudo puede estar en una red distinta a la de su ISP habitual y, en consecuencia, encontrará que el envío de correos electrónicos falla porque el servidor SMTP configurado ya no está disponible.

Este sistema presenta varias variantes. Por ejemplo, el servidor SMTP de una organización puede prestar servicio únicamente a usuarios de la misma red, reforzando esta restricción mediante un cortafuegos que bloquea el acceso a usuarios de internet. O bien, el servidor puede realizar comprobaciones de rango en la dirección IP del cliente. Estos métodos solían ser utilizados por empresas e instituciones como universidades, que disponían de un servidor SMTP para el correo saliente exclusivamente para uso interno. Sin embargo, la mayoría de estas entidades ahora utilizan métodos de autenticación de cliente, como se describe a continuación.

Cuando un usuario es móvil y puede usar diferentes proveedores de servicios de internet (ISP) para conectarse, este tipo de restricción de uso resulta engorrosa, y modificar la dirección del servidor SMTP de correo saliente configurado es poco práctico. Es muy conveniente poder usar la información de configuración del cliente de correo electrónico, que no requiere cambios.

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 restringirlo por ubicación como se describió anteriormente. Este sistema más flexible es ideal para usuarios móviles y les permite elegir un servidor SMTP de salida configurado. La autenticación SMTP , a menudo abreviada como SMTP AUTH, es una extensión del protocolo SMTP que permite 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 usan puertos de "envío" específicos. Los servicios de correo generalmente aceptan el envío de correo electrónico desde clientes en uno de los siguientes puertos:

  • 465 Este puerto quedó obsoleto después de RFC 2487 , hasta la publicación de RFC 8314 .  
  • 587 (Presentación), según lo formalizado en RFC 6409 (anteriormente RFC 2476 )  

Es posible que algunos proveedores individuales utilicen el puerto 2525 y otros, pero nunca han recibido soporte oficial.

Muchos proveedores de servicios de Internet ahora bloquean todo el tráfico saliente del puerto 25 de sus clientes. Principalmente como medida anti-spam, [ 27 ] pero también para compensar el mayor costo que tienen al dejarlo abierto.

Ejemplo de transporte SMTP

Un ejemplo típico de envío de un mensaje mediante SMTP a dos buzones de correo ( alice y theboss ) ubicados en el mismo dominio de correo ( example.com ) se reproduce en el siguiente intercambio de sesión. (En este ejemplo, las partes de la conversación tienen como prefijo S: y C:, que corresponden a 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 fiable con el receptor del mensaje (servidor SMTP), la sesión se abre con un saludo del servidor, que normalmente 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 una dirección literal si no hay ninguna disponible). [ 28 ]

S: 220 smtp.example.com ESMTP Postfix C: HELO relay.example.org S: 250 Hola relay.example.org, me alegra conocerte C: MAIL FROM:<bob@example.org> S: 250 OK C: RCPT TO:<alice@example.com> S: 250 OK C: RCPT TO:<theboss@example.com> S: 250 OK C: DATA S: 354 Fin de los 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: QUIT S: 221 Adiós {El servidor cierra la conexión}From:"BobExample"<bob@example.org>To:"AliceExample"<alice@example.com>Cc:theboss@example.comDate:Tue, 15 Jan 2008 16:02:43 -0500Subject:Testmessage

El cliente notifica al destinatario de la dirección de correo electrónico de origen del mensaje en un MAIL FROMcomando. Esta también es la dirección de retorno o rebote en caso de que el mensaje no pueda entregarse. En este ejemplo, el mensaje de correo electrónico se envía a dos buzones en el mismo servidor SMTP: uno para cada destinatario que aparece en los campos de encabezado To:y Cc:. El comando SMTP correspondiente es RCPT TO. Cada recepción y ejecución exitosa de un comando es confirmada 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, luego se transmite textualmente línea por línea y finaliza con una secuencia de fin de datos. Esta secuencia consta de un salto de línea ( <CR><LF>), un punto ( .), 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 relleno de puntos .

La respuesta positiva del servidor al fin de los datos, como se ejemplifica, implica que el servidor ha asumido la responsabilidad de entregar el mensaje. Un mensaje puede duplicarse si hay un fallo de comunicación en este momento, por ejemplo, debido a un corte de energía: hasta que el remitente reciba 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. [ 29 ] La probabilidad de que ocurra un fallo 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 límite se especifica en 10 minutos. [ 30 ]

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 subsiguientes después de que los destinos actuales se hayan puesto en cola. La información que el cliente envía en los comandos HELOy MAIL FROMse agrega (no se muestra en el código de ejemplo) como campos de encabezado adicionales al mensaje por el servidor receptor. Agrega un campo de encabezado Receivedy , respectivamente.Return-Path

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

Extensiones SMTP

Mecanismo de descubrimiento de extensiones

Los clientes aprenden las opciones admitidas por un servidor usando 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. [ 31 ]

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

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: 250-SIZE 14680064 S: 250-PIPELINING S: 250 HELP

Por lo tanto, smtp2.example.com declara que puede aceptar un tamaño máximo fijo de mensaje que no sea mayor de 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 una extensión EHLO. Sin embargo, según la RFC 1870 , el parámetro numérico de la extensión en la respuesta es opcional. 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 protocolo SMTP original solo admite un único cuerpo de texto ASCII; por lo tanto, cualquier dato binario debe codificarse como texto dentro de ese cuerpo del mensaje antes de la transferencia, y luego ser decodificado por el destinatario. Normalmente se utilizaban codificaciones de binario a texto , como uuencode y BinHex .

El comando 8BITMIME se desarrolló para abordar esto. Se estandarizó en 1994 como RFC 1652 [ 33 ]. 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 . 

Servicio de retransmisión de correo a demanda

El servicio de retransmisión de correo bajo demanda ( ODMR , por sus siglas en inglés) es una extensión SMTP estandarizada en el RFC 2645 que permite que un servidor SMTP con conexión intermitente reciba el correo electrónico que se encuentra en cola cuando está conectado. 

Extensión de internacionalización

El protocolo SMTP original solo admite direcciones de correo electrónico compuestas por caracteres ASCII , lo cual resulta inconveniente para usuarios cuyo alfabeto nativo no se basa en el alfabeto latino o que utilizan diacríticos que no pertenecen al conjunto de caracteres ASCII. Esta limitación se mitigó mediante extensiones que habilitan UTF-8 en los nombres de las direcciones. El RFC 5336 introdujo el comando experimental [ 32 ] y posteriormente fue reemplazado por el RFC 6531 , que introdujo el comando. Estas extensiones brindan soporte para caracteres multibyte y no ASCII en las direcciones de correo electrónico, como aquellos con diacríticos y caracteres de otros idiomas, como el griego y el chino . [ 34 ] UTF8SMTP SMTPUTF8

El soporte actual es limitado, pero existe un gran interés en la adopción generalizada del RFC 6531 y los RFC relacionados en países como China , que tienen una gran base de usuarios donde el alfabeto latino (ASCII) es un sistema de escritura extranjero. 

Extensiones

Al igual que SMTP, ESMTP es un protocolo utilizado para transportar correo electrónico por Internet. Se utiliza tanto como protocolo de transporte entre servidores como (con ciertas restricciones de comportamiento) 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(HELLO extendido), en lugar de HELO(Hello, el estándar RFC 821 original ). Un servidor responderá con éxito (código 250), fallo (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 las dos opciones . HELOQUIT

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

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

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

El formato ESMTP se reformuló en el RFC 2821 (que sustituyó al RFC 821) y se actualizó a la definición más reciente en el RFC 5321 en 2008. La compatibilidad con el comando en los servidores se volvió obligatoria y se designó como una alternativa requerida.  EHLOHELO

Mediante acuerdo bilateral, se pueden utilizar extensiones de servicio no estándar y no registradas. Estos servicios se identifican mediante una EHLOpalabra clave en el mensaje que comienza con "X", y cualquier parámetro o verbo adicional se marca de forma similar.

Los comandos SMTP no distinguen entre mayúsculas y minúsculas. Se presentan aquí en mayúsculas únicamente para enfatizarlos. Un servidor SMTP que requiera un método de capitalización específico infringe el estándar. [ 28 ]

8BITMIME

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

Los siguientes servidores pueden configurarse para anunciar 8BITMIME, pero no realizan la conversión de datos de 8 bits a 7 bits al conectarse a repetidores 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 mediante el cual el cliente inicia sesión en el servidor de correo durante el proceso de envío de mensajes. Los servidores que admiten SMTP-AUTH generalmente se pueden configurar para que requieran 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 la RFC 4954 . 

SMTP-AUTH permite que los usuarios legítimos reenvíen correo, pero deniega el servicio a usuarios no autorizados, como los spammers . Sin embargo, no garantiza la autenticidad del remitente del sobre SMTP ni del encabezado "From:" de la RFC 2822. Por ejemplo, la suplantación de identidad (en la que un remitente se hace pasar por otro) sigue siendo posible con SMTP-AUTH, a menos que el servidor esté configurado para limitar las direcciones de remitente a las direcciones para las que el usuario autenticado 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 reenviar correo. En general, esto requiere que el servidor receptor confíe en el servidor remitente, lo que significa que este aspecto de SMTP-AUTH rara vez se utiliza en Internet. [ 41 ]

SMTPUTF8

Los servidores compatibles incluyen:

Extensiones de seguridad

El envío de correo puede realizarse tanto a través de texto plano como mediante conexiones cifradas; sin embargo, es posible que las partes que se comunican no sepan de antemano si la otra parte tiene la capacidad de utilizar un canal seguro.

STARTTLS o "TLS oportunista"

La extensión STARTTLS permite a los servidores SMTP compatibles notificar a los clientes que se conectan que admiten la comunicación cifrada TLS y ofrece 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 se realiza en texto plano y un atacante activo puede eliminar fácilmente los comandos de 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 inválidas o inesperadas como una indicación de que la otra no admite correctamente STARTTLS, y recurren a la transferencia de correo tradicional en texto plano. [ 50 ] Cabe señalar que STARTTLS también está definido para IMAP y POP3 en otros RFC, pero estos protocolos tienen propósitos diferentes: 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 forma similar a la lista " HTTPS Everywhere ", permitía a las partes que confiaban en la comunicación descubrir a otras que admitían la comunicación segura sin comunicación previa. El proyecto dejó de aceptar envíos el 29 de abril de 2021, y la EFF recomendó cambiar a DANE y MTA-STS para descubrir información sobre la compatibilidad con TLS de los pares. [ 51 ]

El RFC 8314 declaró oficialmente obsoleto el texto plano y recomendó utilizar siempre TLS para el envío y acceso al correo electrónico, añadiendo puertos con TLS implícito. 

DANE para SMTP

RFC 7672 introdujo la capacidad de que los registros DNS declaren las capacidades de cifrado de un servidor de correo. Mediante DNSSEC , los operadores de servidores de correo pueden publicar un hash de su certificado TLS, mitigando así la posibilidad de comunicaciones no cifradas. [ 52 ] 

Microsoft espera habilitar la compatibilidad total con SMTP DANE para los clientes de Exchange Online para finales de 2024. [ 53 ]

SMTP MTA Seguridad estricta en el transporte

Un RFC 8461 más reciente de 2018 , denominado "SMTP MTA Strict Transport Security (MTA-STS)", busca abordar el problema de los adversarios activos definiendo un protocolo para que los servidores de correo declaren su capacidad para usar canales seguros en archivos específicos del servidor y registros DNS TXT específicos. La parte confiable verificarí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 no seguros hasta que el registro expire. [ 50 ] Cabe señalar 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 política organizativa o técnica. En esencia, MTA-STS es un medio para extender dicha política a terceros. 

En abril de 2019, Google Mail anunció su compatibilidad con MTA-STS. [ 54 ]

Informes SMTP TLS

Los protocolos diseñados para la entrega segura de mensajes pueden fallar debido a configuraciones incorrectas o interferencias deliberadas, lo que provoca que los mensajes no se entreguen o se envíen a través de canales no cifrados o no autenticados. El RFC 8460, "SMTP TLS Reporting", describe un mecanismo y un formato para compartir estadísticas e información específica sobre posibles fallos con los dominios receptores. Estos dominios pueden utilizar esta información para detectar posibles ataques y diagnosticar configuraciones incorrectas involuntarias. 

En abril de 2019, Gmail anunció la compatibilidad con SMTP TLS Reporting. [ 54 ]

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

El diseño original de SMTP no incluía ningún mecanismo para autenticar a los remitentes ni para comprobar que los servidores estuvieran autorizados a enviar correos en su nombre, lo que posibilita la suplantación de identidad por correo electrónico , una práctica común en el spam y el phishing .

Ocasionalmente se presentan propuestas para modificar SMTP sustancialmente o reemplazarlo por completo. Un ejemplo de ello es Internet Mail 2000 , pero ni este ni ningún otro han logrado avances significativos frente al efecto de red que supone la enorme base instalada de usuarios del SMTP clásico.

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

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 que este protocolo se haya implementado alguna vez "
  2. ↑ El primer correo electrónico en red , Ray Tomlinson , BBN
  3. ↑ Imagen de " El primer ordenador de correo electrónico " de Dan Murphy, un 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 – Un protocolo de correo propuesto 
  6. ↑ Crocker, David H. (diciembre de 1977). "Marco y funciones del sistema de mensajería personal "MS"" (PDF) . The RAND Corporation . Archivado (PDF) del original el 13 de mayo de 2022. Recuperado el 17 de abril de 2022 .
  7. ↑ RFC 469 – Resumen de la reunión sobre correo de red 
  8. ↑ RFC 733, 21 de noviembre de 1977, Estándar 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 primera mano". IEEE Annals of the History of Computing . 33 (1): 66– 71. Bibcode : 2011IAHC...33a..66M . doi : 10.1109/MAHC.2011.9 . ISSN 1934-1547 . S2CID 206443072 .  
  11. ↑ Barber, D., y J. Laws, "Un esquema básico de correo para el EIN", INWG 192, febrero de 1979.
  12. ↑ IEN 85 . IETF .
  13. ↑ IEN 113 . IETF .
  14. ↑ "Índice de notas sobre experimentos de Internet" . www.rfc-editor.org . Consultado el 7 de julio de 2024 .
  15. 1 2 Postel, J. (agosto de 1982). Protocolo simple de transferencia de correo (Informe). Editor de RFC. doi : 10.17487/rfc0821 .
  16. ↑ "Tldp.org" . Archivado del original el 17 de agosto de 2007. Consultado el 25 de agosto de 2007 .
  17. ↑ Barber, Stan O. (19 de diciembre de 2000). "draft-barber-uucp-project-conclusion-05 – La conclusión del proyecto de mapeo UUCP" . Archivado del original el 13 de octubre de 2007. Recuperado el 25 de agosto de 2007 .
  18. ↑ El artículo sobre la reescritura del remitente contiene información técnica de fondo sobre la historia temprana de SMTP y el enrutamiento de origen antes de RFC 1123 . 
  19. ↑ Eric Allman (1983), Sendmail – Un enrutador de correo para redes (PDF) , conjunto de documentación BSD UNIX, Berkeley: Universidad de California, archivado (PDF) del original el 20 de mayo de 2013 , recuperado el 29 de junio de 2012.
  20. ↑ 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, pp. 3–29 , Bibcode : 2008IAHC...30b...3P , doi : 10.1109/MAHC.2008.32 , S2CID 206442868 , archivado del original (PDF) el 12 de mayo de 2011   
  21. ↑ Paul Hoffman (1 de febrero de 1998). "Permitir el reenvío en SMTP: una revisión" . Internet Mail Consortium . Archivado del original el 5 de marzo de 2016. Recuperado el 30 de mayo de 2010 .
  22. ↑ Paul Hoffman (agosto de 2002). "Permitir el reenvío en SMTP: una serie de encuestas" . Internet Mail Consortium . Archivado del original el 18 de enero de 2007. Recuperado el 30 de mayo de 2010 .
  23. ↑ "¿En Unix, qué es un relé de correo abierto? - Base de conocimientos" . 17 de junio de 2007. Archivado del original el 17 de junio de 2007. Consultado el 15 de marzo de 2021 .
  24. ↑ "Los verbos MAIL, RCPT y DATA" Archivado el 22 de febrero de 2014 en Wayback Machine , [DJ Bernstein]
  25. ↑ RFC 5321 Sección 7.2 
  26. ↑ Sistemas de mensajería. "Message Systems presenta la última versión de Momentum con nuevas capacidades basadas en API" . www.prnewswire.com (Comunicado de prensa). Archivado del original el 19 de julio de 2020. Consultado el 19 de julio de 2020 .
  27. ↑ Cara Garretson (2005). "Los ISP colaboran para detener el spam" . PC World . Archivado del original el 28 de agosto de 2015. Recuperado el 18 de enero de 2016. El mes pasado, la Alianza Técnica Antispam, 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.
  28. 1 2 J. Klensin (octubre de 2008). Protocolo simple de transferencia de correo . Grupo de trabajo de redes IETF . doi : 10.17487/RFC5321 . RFC 5321 .Borrador de estándar. Actualizado por RFC 7504. Sustituye a RFC 2821. Actualiza RFC 1123 .   
  29. ↑ RFC 1047 
  30. ↑ Klensin, John C. (octubre de 2008). "Terminación de datos: 10 minutos" . Protocolo simple de transferencia de correo . IETF . sec. 4.5.3.2.6. doi : 10.17487/RFC5321 . RFC 5321. Recuperado el 7 de junio de 2010 . 
  31. ↑ 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 .
  32. 1 2 "Parámetros de MAIL" . IANA. 14 de febrero de 2020. Archivado del original el 28 de mayo de 2019. Recuperado el 28 de mayo de 2019 .
  33. ↑ Que quedó obsoleto en 2011 por RFC 6152 correspondiente al entonces nuevo STD 71 
  34. ↑ Jiankang Yao (19 de diciembre de 2014). "Dirección de correo electrónico china" . EAI (Lista de correo). IETF . Archivado del original el 2 de octubre de 2015. Recuperado el 24 de mayo de 2016 .
  35. ↑ "Parámetros de extensión del servicio SMTP" . IANA. Archivado del original el 28 de mayo de 2019. Recuperado el 5 de noviembre de 2013 .
  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. ↑ El servicio 8BITMIME se anunció en respuesta a EHLO en gmail-smtp-in.l.google.com puerto 25, comprobado el 23 de noviembre de 2011.
  38. ↑ Errores y sugerencias de Qmail . Home.pages.de. Consultado el 17 de julio de 2013.
  39. ↑ La extensión 8BITMIME se archivó el 7 de junio de 2011 en Wayback Machine . Créditos: yp.to. Consultado el 17 de julio de 2013.
  40. ↑ "La extensión del servicio de transporte MIME de 8 bits" . Extensión del servicio SMTP para transporte MIME de 8 bits . IETF . Marzo de 2011. sec. 3. doi : 10.17487/RFC6152 . RFC 6152 . 
  41. ↑ Hazel, Philip (2007). El servidor de correo Exim SMTP (2.ª ed.). Cambridge: UIT Cambridge. pág. 418. ISBN   978-0-9544529-7-5.{{cite book}}: Valor de comprobación |isbn=: suma de comprobación ( ayuda )
  42. ↑ " El soporte para Postfix SMTPUTF8 está habilitado por defecto " Archivado el 7 de agosto de 2020 en Wayback Machine , 8 de febrero de 2015, postfix.org
  43. ↑ «Message Systems presenta la última versión de Momentum con nuevas capacidades basadas en API» (Comunicado de prensa). Archivado del original el 15 de septiembre de 2020. Consultado el 17 de septiembre de 2020 .
  44. ↑ "Historial de revisiones de la versión 6.2" . CommuniGate.com . Archivado del original el 29 de octubre de 2020. Consultado el 17 de septiembre de 2020 .
  45. ↑ Sam Varshavchik (18 de septiembre de 2018). "Nuevos lanzamientos de paquetes de Courier" . courier-announce (Lista de correo). Archivado del original el 17 de agosto de 2021. Recuperado el 17 de septiembre de 2020 .
  46. ↑ "Registro de cambios de Halon MTA" . GitHub . 9 de noviembre de 2021. Archivado del original el 18 de septiembre de 2020. Consultado el 17 de septiembre de 2020. v4.0 : Nuevo soporte para SMTPUTF8Actualizado para nuevas versiones
  47. ↑ "MS-OXSMTP: Extensiones del Protocolo Simple de Transferencia de Correo (SMTP)" . 24 de julio de 2018. Archivado del original el 16 de agosto de 2021. Consultado el 17 de septiembre de 2020 .
  48. ↑ "Preparación para EAI en TLDs" (PDF) . 12 de febrero de 2019. Archivado (PDF) del original el 24 de enero de 2021. Recuperado el 17 de septiembre de 2020 .
  49. ↑ "Notas de la versión del servidor de mensajería de comunicaciones" . oracle.com . Octubre de 2017. Archivado del original el 24 de noviembre de 2020. Consultado el 17 de septiembre de 2020 .
  50. 1 2 "Presentación de la Seguridad Estricta en el Transporte de la MTA (MTA-STS) | Blog de Hardenize" . www.hardenize.com . Archivado del original el 25 de abril de 2019. Recuperado el 25 de abril de 2019 .
  51. ↑ "STARTTLS Everywhere" . EFF. Archivado del original el 9 de agosto de 2019. Consultado el 4 de diciembre de 2021 .
  52. ↑ v-mathavale (21 de julio de 2023). "Cómo la autenticación de entidades nombradas basada en DNS SMTP (DANE) protege las comunicaciones por correo electrónico" . learn.microsoft.com . Consultado el 5 de marzo de 2024 .
  53. ↑ "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 .
  54. 1 2 Cimpanu, Catalin. "Gmail se convierte en el primer proveedor importante de correo electrónico en admitir MTA-STS y TLS Reporting" . ZDNet . Archivado del original el 29 de abril de 2019. Recuperado el 25 de abril de 2019 .
  55. ↑ "Mensaje no conforme con RFC 5322" . Archivado del original el 17 de enero de 2023. Recuperado el 20 de enero de 2021 .
  56. ↑ "No se pudo entregar el mensaje. Asegúrese de que el mensaje cumpla con la norma RFC 5322" . Archivado del original el 28 de enero de 2021. Recuperado el 20 de enero de 2021 .
  57. ↑ "¿Por qué se rechazan los correos electrónicos enviados a la cuenta de Microsoft por motivos de política?" . Archivado del original el 14 de febrero de 2021. Consultado el 20 de enero de 2021 .

Referencias

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

Lecturas adicionales

  • RFC 1123 – Requisitos para hosts de Internet: aplicación y soporte (STD 3) 
  • RFC 1870 – Extensión del servicio SMTP para la declaración del tamaño del mensaje (sustituye a: RFC 1653 )  
  • RFC 2505 – Recomendaciones anti-spam para MTA SMTP (BCP 30) 
  • RFC 2821 – Protocolo simple de transferencia de correo 
  • RFC 2920 – Extensión del servicio SMTP para la canalización de comandos (STD 60) 
  • RFC 3030 – Extensiones del servicio SMTP para la transmisión de mensajes MIME binarios y de gran tamaño 
  • RFC 3207 – Extensión del servicio SMTP para SMTP seguro sobre Transport Layer Security (sustituye a RFC 2487 )  
  • RFC 3461 – Extensión del servicio SMTP para notificaciones de estado de entrega (sustituye a RFC 1891 )  
  • RFC 3463 – Códigos de estado mejorados para SMTP (sustituye a RFC 1893 , actualizado por RFC 5248 )   
  • RFC 3464 – Un formato de mensaje extensible para notificaciones de estado de entrega (sustituye a RFC 1894 )  
  • RFC 3798 – Notificación de disposición de mensajes (actualiza RFC 3461 )  
  • RFC 3834 – Recomendaciones para respuestas automáticas a correos electrónicos 
  • RFC 3974 – Experiencia operativa de SMTP en entornos mixtos IPv4/v6 
  • RFC 4952 – Descripción general y marco para el correo electrónico internacionalizado (actualizado por RFC 5336 )  
  • RFC 4954 – Extensión del servicio SMTP para autenticación (sustituye a RFC 2554 , actualiza RFC 3463 , actualizado por RFC 5248 )    
  • RFC 5068 – Operaciones de envío de correo electrónico: Requisitos de acceso y rendición de cuentas (BCP 134) 
  • RFC 5248 – Un registro para códigos de estado del sistema de correo mejorado SMTP (BCP 138) (actualiza RFC 3463 )  
  • RFC 5321 – Protocolo simple de transferencia de correo (sustituye a RFC 821 , también conocido como STD 10, RFC 974 , RFC 1869 , RFC 2821 , y actualiza RFC 1123 )      
  • RFC 5322 : formato de mensajes de Internet (obsoleto RFC 822 , también conocido como STD 11 y RFC 2822 )   
  • RFC 5504 – Mecanismo de degradación para la internacionalización de direcciones de correo electrónico 
  • RFC 6409 – Envío de mensajes para correo electrónico (STD 72) (sustituye a RFC 4409 y RFC 2476 )   
  • RFC 6522 – El tipo de contenido Multipart/Report para la generación de informes de mensajes administrativos del sistema de correo (sustituye a RFC 3462 y, a su vez, a RFC 1892 )   
  • RFC 6531 – Extensión SMTP para direcciones de correo electrónico internacionalizadas (actualiza RFC 2821 , RFC 2822 , RFC 4952 y RFC 5336 )     
  • RFC 8314 – El texto plano se considera obsoleto: Uso de la seguridad de la capa de transporte (TLS) para el envío y acceso por correo electrónico. 
  • RFC 1869 Extensiones del servicio SMTP 
  • RFC 5321 Protocolo simple de transferencia de correo 
  • RFC 4954 Extensión del servicio SMTP para autenticación (sustituye a RFC 2554 )  
  • RFC 3848 Registro de tipos de transmisión SMTP y LMTP (con ESMTPA) 
  • RFC 6409 Envío de mensajes para correo (obsoleto RFC 4409 , que queda obsoleto RFC 2476 )   
Lecturas relacionadas
6 articulos
Figura 2. Protocolos en relación con el esquema de capas de Internet.Protocolo de comunicaciónUn protocolo de comunicación es un sistema de reglas que permite que dos o más entidades de un sistema de comunicaciones transmitan información a t...Estándar de InternetEstándar de InternetEn ingeniería de redes informáticas , un estándar de Internet es una especificación normativa de una tecnología o metodología aplicable a Internet ...Página semiprotegidaCorreo electrónicoEl correo electrónico (generalmente abreviado como email ; también escrito con guion e-mail ) es un método para transmitir y recibir mensajes digit...Agente de transferencia de mensajesAgente de transferencia de mensajesDentro del sistema de correo electrónico de Internet , un agente de transferencia de mensajes ( MTA ), [1] agente de transferencia de correo , [2] ...Cliente de correo electrónicoCliente de correo electrónicoUn cliente de correo electrónico , un lector de correo electrónico o, más formalmente, un agente de usuario de mensajes (MUA) o un agente de usuari...Solicitud de comentariosUna solicitud de comentarios ( RFC ) es una publicación de una serie de los principales organismos de desarrollo técnico y establecimiento de están...