SMTP: transporte, cola y responsabilidad de entrega

El Simple Mail Transfer Protocol (SMTP) lleva un mensaje de un proceso de correo al siguiente. El cliente se conecta a un servidor, consulta sus capacidades, indica el remitente y los destinatarios del sobre, y solo entonces transmite el contenido del mensaje. El servidor responde a cada paso con un código numérico. De esta secuencia aparentemente sencilla surgen el enrutamiento, la puesta en cola, los reintentos y la cuestión decisiva de qué servidor tiene en ese momento la responsabilidad del mensaje (RFC 5321, secciones 1 y 2).

Para los administradores de mensajería, la característica decisiva reside en la transferencia de responsabilidad. Un establecimiento TCP correcto solo significa que un listener es accesible. Un RCPT TO aceptado reserva un destinatario dentro de la transacción en curso. Solo una finalización positiva tras el contenido completo del mensaje transfiere al sistema SMTP receptor la responsabilidad de entregar el mensaje o informar posteriormente de un error al remitente del sobre (RFC 5321, secciones 4.1.1.4 y 6.1). Por ello, el ID de cola, el código de respuesta, el MTA remoto, el estado del destinatario y la traza Received no son detalles de registro secundarios, sino la cadena de prueba de una entrega.

La explicación sigue un mensaje desde el cliente que lo presenta, pasando por la sesión SMTP, el sobre y la cola, hasta el siguiente servidor de correo o buzón. DNS, reintentos, códigos de estado, seguridad y diagnóstico se profundizan donde influyen en el recorrido.

Funciones y responsabilidades

SMTP conoce inicialmente solo cliente y servidor. En una cadena de entrega real, estas funciones cambian en cada salto: un Mail Transfer Agent acepta un mensaje como servidor, lo almacena en su cola y se convierte él mismo en cliente en el siguiente intento de entrega. Solo a partir de este cambio de funciones pueden interpretarse correctamente los registros y las responsabilidades (RFC 5321, sección 2.3.3, RFC 5598, sección 4, RFC 6409, sección 2.1).

El MSA no es simplemente un MTA en otro puerto. Message Submission separa la presentación controlada de mensajes nuevos del transporte abierto entre dominios de correo. Entre otras cosas, un MSA puede comprobar los derechos del remitente, completar campos obligatorios faltantes y adaptar los mensajes a reglas locales; por regla general, un MTA posterior no debería modificar arbitrariamente el contenido de un mensaje ya terminado (RFC 6409, secciones 1, 6 y 8). Este límite es especialmente relevante para las firmas DKIM: cualquier modificación posterior de encabezados firmados o del cuerpo puede invalidar la firma.

El gráfico muestra límites lógicos. El MSA, el MTA saliente, el gateway y el MTA entrante pueden ejecutarse como servicios separados, coincidir en un mismo sistema o quedar ocultos por un proveedor de nube. Los estándares no prescriben una arquitectura de procesos. Sin embargo, administrativamente la separación sigue siendo necesaria, porque cada transferencia aceptada puede generar una nueva cola, un nuevo estado de reintento y un nuevo responsable.

Sobre y contenido del mensaje

Antes de examinar el diálogo en detalle, deben separarse dos áreas de datos: el sobre para el transporte y el contenido del mensaje para destinatarios y programas de correo. El sobre consta de un Reverse Path de MAIL FROM y uno o varios Forward Paths de RCPT TO. El contenido sigue a DATA e incluye un área de encabezados conforme al Internet Message Format y el cuerpo, a menudo con estructura MIME (RFC 5321, sección 2.3.1, RFC 5322, sección 2.1).

Los servidores SMTP no pueden derivar la ruta final de To:, Cc: ni From:. A la inversa, las direcciones del sobre no tienen que aparecer en los encabezados del mensaje. Por eso funcionan Bcc, las listas de distribución, los reenvíos, SRS y las direcciones de rebote separadas. La separación también explica por qué un mensaje puede parecer visualmente en el cliente proceder de ceo@example.ch, mientras que su remitente del sobre utiliza otro dominio. SPF considera la ruta SMTP; DMARC establece además una referencia con el From: visible. Los detalles de estas comprobaciones se tratan en autenticación de correo (RFC 5321, apéndice C, RFC 5322, sección 3.6).

Un Reverse Path vacío se transmite como MAIL FROM:<>. Evita bucles de informes de error y es obligatorio para Delivery Status Notifications. Por tanto, un servidor que rechaza remitentes vacíos de forma general daña la ruta de retorno del sistema de correo (RFC 5321, sección 3.6.3).

Sesión y transacción SMTP

En una conexión TCP se ejecuta una sesión SMTP; dentro de ella pueden seguir varios mensajes como transacciones de correo separadas. El servidor comienza con un greeting 220; el cliente se identifica mediante EHLO y recibe una lista de capacidades ESMTP asociada a la sesión. Después, una transacción consta de MAIL, al menos un RCPT aceptado y DATA, o bien un sustituto negociado como BDAT (RFC 5321, secciones 3.1 y 4.1).

1. Conexión y greeting: El cliente se conecta; el servidor responde con 220. Si ya aquí se retrasa o rechaza, aún no existe una transacción de correo.
2. Negociación de capacidades: EHLO client.example pone a ambas partes en el estado inicial y proporciona extensiones como SIZE, STARTTLS, PIPELINING o SMTPUTF8. Un cliente no puede asumir que otro nodo del clúster o una sesión posterior ofrezca las mismas capacidades.
3. Actualización TLS opcional: Tras un STARTTLS correcto, se descartan el estado SMTP y las capacidades aprendidas previamente. El cliente vuelve a enviar EHLO dentro del canal protegido (RFC 3207, sección 4).
4. Remitente del sobre: MAIL FROM abre una transacción y vacía los búferes anteriores de sobre y datos. Los parámetros ESMTP como SIZE, BODY o SMTPUTF8 se adjuntan a este comando.
5. Destinatarios: Cada RCPT TO recibe una respuesta individual. Un servidor puede aceptar dos destinatarios y rechazar permanentemente un tercero; entonces el cliente envía el contenido para el subconjunto aceptado.
6. Contenido: Tras DATA, si está preparado, sigue 354. El cliente transmite encabezados y cuerpo como líneas terminadas en CRLF, escapa los puntos al inicio de línea y termina con una línea que consiste solo en ..
7. Finalización: La respuesta tras este marcador End-of-Data decide si el servidor asume el mensaje completo para los destinatarios previamente aceptados. RSET descarta la transacción en curso sin terminar la sesión; QUIT la cierra ordenadamente.

SMTP está orientado a lockstep, pero ESMTP-PIPELINING puede enviar grupos de comandos permitidos sin esperar cada respuesta individual. Las respuestas permanecen en orden de entrada y deben seguir asignándose correctamente a cada comando (RFC 2920). Por ello, una captura de paquetes con varias líneas MAIL-/RCPT consecutivas no constituye automáticamente una infracción del protocolo.

Con ello el diálogo está completo, pero la responsabilidad de entrega aún no se ha aclarado. Solo cambia con una respuesta muy concreta del servidor receptor.

Límite de aceptación: 250 tras End-of-Data

El límite SMTP más importante se encuentra después del contenido del mensaje. Un 250 a MAIL FROM solo acepta el Reverse Path. Un 250 a RCPT TO acepta un destinatario para la transacción actual. Solo un 250 tras el marcador End-of-Data significa que el servidor ha asumido la responsabilidad del mensaje. Después debe entregarlo o, si detecta un error posteriormente, generar un informe de no entrega; el cliente emisor puede retirar su copia local de la responsabilidad activa de entrega (RFC 5321, secciones 4.1.1.4 y 6.1).

Esta semántica hace crítica la última parte del diálogo. Si la conexión se interrumpe tras el punto, pero antes de recibir una respuesta completa, el cliente no sabe con certeza si el servidor almacenó el mensaje. Debe poder intentar la entrega de nuevo; por ello son posibles los duplicados. SMTP no ofrece una garantía global de exactamente una vez. En consecuencia, los sistemas necesitan seguimiento idempotente mediante ID de cola, Message-ID, destinatario, hora, tamaño y, si procede, una referencia de transacción propietaria, sin equiparar entre sí estos identificadores.

Los filtros de contenido, DLP, análisis de malware o firma DKIM deberían integrarse en la canalización de aceptación de modo que el servidor sepa antes de la respuesta positiva final si puede asumir responsabilidad persistente. Un proxy anterior que informe prematuramente 250 y después pierda internamente el mensaje ya no podrá devolver el error al cliente SMTP original. Precisamente aquí una arquitectura debe establecer si la aceptación se confirma solo tras una escritura durable, tras la replicación, tras el análisis o ya tras la transferencia a un broker interno. Se trata de una característica del producto, no de un requisito del estándar SMTP, y debe acreditarse mediante documentación del fabricante y pruebas de error y restauración.

Tras la aceptación, el MTA debe decidir adónde envía el mensaje a continuación. En el correo de Internet, esta decisión comienza en DNS.

Enrutamiento mediante DNS y MX

Para la entrega directa por Internet, el MTA emisor determina el siguiente destino a partir del dominio del destinatario del sobre. Consulta DNS en busca de registros MX, ordena los candidatos por valor Preference ascendente y resuelve los nombres Exchange seleccionados a direcciones A o AAAA. Varios destinos con la misma Preference forman candidatos equivalentes; un MX de respaldo con valor superior no es una réplica de la cola primaria, sino un receptor SMTP independiente con su propia política y responsabilidad de entrega (RFC 5321, sección 5).

Si falta un conjunto MX-RRset, SMTP trata históricamente el dominio como un MX implícito sobre el propio nombre de dominio e intenta sus direcciones. En cambio, un Null MX explícito con Preference 0 y Exchange . declara que un dominio no acepta correo electrónico (RFC 7505). NXDOMAIN, NODATA, SERVFAIL, los errores de validación DNSSEC y un MX accesible sin servicio SMTP operativo son estados distintos y deben permanecer diferenciados en el motivo de cola.

Las rutas de correo internas suelen usar siguientes saltos estáticos, smarthosts, conectores o tablas de enrutamiento en vez de selección MX pública. El destinatario del sobre sigue siendo la dirección de entrega; la política local de enrutamiento solo decide a qué sistema siguiente se le confía. Por ello, en cada diagnóstico deben anotarse tres nombres: el dominio destinatario, el nombre del siguiente salto seleccionado y la dirección IP realmente conectada.

Aunque el MTA conozca el destino, la entrega no siempre es posible de inmediato. Por ello, los errores temporales pasan a la cola en vez de provocar la pérdida del mensaje.

Cola, reintento y DSN

Un MTA completo es un sistema Store-and-Forward. Si no puede alcanzar inmediatamente el siguiente salto o este responde temporalmente, el MTA conserva el mensaje y el sobre en una cola persistente, programa un nuevo intento y administra el estado por destinatario. RFC 5321 exige una estrategia de reintento, pero no prescribe un algoritmo único para todos los productos. Recomienda reintentos diferidos, una notificación ante retrasos prolongados y una conservación de varios días antes del abandono definitivo (RFC 5321, sección 4.5.4). Por tanto, valores de producto como backoff, duración máxima de cola, paralelismo y concurrencia por destino deben consultarse en la configuración concreta del MTA.

Un registro de cola razonable contiene como mínimo:

• contenido del mensaje inmutable o un blob referenciado;
• remitente del sobre y estado de cada destinatario del sobre;
• momento de aceptación, siguiente intento y límite de expiración;
• transporte elegido, siguiente salto, última dirección y decisión TLS/de política;
• último código SMTP y de estado mejorado, junto con el texto remoto;
• ID de cola local, así como IDs correlacionables de saltos anteriores o posteriores;
• estados para active, deferred, hold, delivered, bounced y quarantined;
• estado de replicación, sistema de archivos o base de datos, si la aceptación debe tener alta disponibilidad.

Los errores temporales normalmente se reintentan. Los errores permanentes antes de la propia aceptación se devuelven de forma síncrona al cliente SMTP emisor. Los errores permanentes tras la propia aceptación generan una Delivery Status Notification (DSN) al Reverse Path. RFC 3464 define para ello un mensaje multipart/report legible por máquina, con campos por mensaje y por destinatario como Reporting-MTA, Final-Recipient, Action, Status y, opcionalmente, Remote-MTA o Diagnostic-Code (RFC 3464).

Un rebote no es automáticamente fiable. Las DSN pueden falsificarse, revelar el contenido original o generar backscatter cuando el remitente del sobre se ha establecido de forma abusiva. Un gateway debería rechazar mensajes no válidos durante la sesión SMTP original siempre que sea posible, en lugar de aceptarlos y enviarlos posteriormente a una dirección posiblemente falsificada.

Códigos de respuesta y significado para el diagnóstico

Las respuestas SMTP tienen un código base de tres dígitos. El rango del primer dígito describe el estado inmediato; el texto está destinado a personas y puede ser específico del producto (RFC 5321, sección 4.2).

Los Enhanced Status Codes complementan el formato x.y.z. x indica éxito, temporal o permanente; y designa el área general de fallo y z el detalle. Así, 5.1.1 pertenece a la clase de direcciones e indica un buzón de destino inexistente, mientras que 4.4.x clasifica problemas de red y enrutamiento. Los significados registrados figuran en el registro IANA de Enhanced Status Codes; un texto de fabricante no debe evaluarse en contradicción con la semántica numérica (RFC 3463, RFC 5248).

El mismo código puede afectar a algo distinto según la fase del protocolo. 550 en MAIL FROM rechaza el remitente o su autorización; en RCPT TO rechaza un destinatario concreto y, tras el contenido, la transacción completa. Por ello, un ticket sin host remoto, hora, fase, códigos base, código mejorado y texto de respuesta completo está incompleto.

ESMTP y extensiones

Extended SMTP utiliza EHLO para negociar capacidades por conexión. IANA mantiene el registro vinculante de SMTP Service Extensions. Un cliente solo puede utilizar una extensión si se ha ofrecido en la sesión actual; tras STARTTLS debe consultar de nuevo la lista.

La deriva de capacidades entre nodos de clúster es un problema operativo frecuente. Si solo algunos listeners ofrecen SMTPUTF8, el mismo valor de SIZE o mecanismos AUTH idénticos, se producen errores de entrega aparentemente aleatorios. Por ello, la monitorización no debe comprobar solo un VIP, sino cada ruta de backend relevante con el mismo SNI, nombre EHLO y red de origen.

Hasta aquí se trataba del transporte entre servidores. La presentación por usuarios y aplicaciones es un servicio propio con otros puertos, identidades y riesgos de abuso.

Submission, relay y autenticación

El puerto 25 sirve para la transferencia de MTA a MTA. El puerto 587 identifica Message Submission; el puerto 465 está registrado para submission con TLS activo desde el inicio como servicio submissions. El puerto 465 no es un puerto MX alternativo: la entrega MX pública no conoce indicación de puerto y utiliza el puerto 25 (RFC 6409, secciones 1 y 3, RFC 8314, sección 7.3, IANA Service Name and Port Number Registry).

Un servicio de submission combina autenticación y autorización. AUTH utiliza SASL y puede transportar mecanismos como PLAIN sobre TLS o tokens Bearer basados en OAuth. La identidad autenticada, la identidad de autorización solicitada y el remitente del sobre permitido son magnitudes distintas. Un inicio de sesión correcto no autoriza automáticamente a utilizar cualquier dominio de remitente ni cualquier remitente del sobre (RFC 4422, sección 3.4, RFC 4954, RFC 7628).

Un relay abierto surge cuando un MTA reenvía mensajes de fuentes no autorizadas a destinos no locales. Por tanto, una configuración segura decide por separado sobre dominios de destinatarios locales, redes de origen fiables, submission autenticada y conectores explícitos. Una allowlist de IP es una autorización de red y no sustituye a una identidad de usuario; con NAT, egreso de nube o relays compartidos puede habilitar un círculo de emisores mucho mayor del previsto.

Solo cuando están definidas la función y el puerto puede determinarse la política TLS adecuada: submission debe estar protegida y autenticada, mientras que el transporte MTA abierto necesita políticas adicionales por dominio.

Política TLS en SMTP

STARTTLS protege la conexión individual cuando ambas partes realizan la actualización. Sin embargo, en la transferencia MTA abierta, STARTTLS puro sigue siendo oportunista: un atacante activo puede eliminar la oferta o manipular destinos DNS, y un emisor sin política adicional puede volver a texto claro. DANE para SMTP vincula los datos TLSA mediante DNSSEC a la selección del destino MX. MTA-STS publica mediante DNS y HTTPS una política MX y TLS basada en PKIX. TLS-RPT informa de errores agregados con dichas políticas. El artículo TLS trata los detalles criptográficos, las rutas de certificados y los procedimientos de prueba.

Submission es diferente: aquí el cliente y el servicio están asociados administrativamente, y el usuario no debe volver silenciosamente a texto claro. RFC 8314 recomienda TLS implícito para Mail Submission y Access, y exige que el texto claro se trate como obsoleto. SMTP AUTH con mecanismos de contraseña o Bearer necesita un canal adecuadamente protegido; un servidor no debería ofrecer mecanismos débiles antes de STARTTLS (RFC 8314, sección 3, RFC 4954, sección 14).

Entrega local con LMTP

El Local Mail Transfer Protocol (LMTP) utiliza un diálogo similar a SMTP para la transferencia a un sistema sin cola de correo propia a largo plazo, por ejemplo, un servicio de buzones. La diferencia esencial aparece tras el contenido del mensaje: LMTP proporciona una respuesta final propia para cada destinatario previamente aceptado. Así, el almacén de correo puede entregar correctamente a un destinatario y rechazar a otro por cuota o error local, sin que el MTA anterior deba tratar toda la transacción como una unidad (RFC 2033, sección 4.2).

LMTP no desplaza la responsabilidad fuera del sistema. Si el almacén de correo rechaza temporalmente a un destinatario, el MTA anterior debe seguir conservando ese destinatario en su cola. En los sockets Unix desaparece la ruta de red IP, pero no la necesidad de observar permisos del socket, backpressure, tiempos de espera, respuestas por destinatario y el límite de persistencia.

Implementación y pila tecnológica

SMTP define el protocolo en el cable, no la arquitectura interna de software. En la práctica, un MTA conecta varias capas técnicas:

Las implementaciones organizan estas capas de manera distinta. Postfix divide recepción, limpieza, Queue Manager y agentes de entrega en procesos cooperativos, y separa incoming, active y deferred como estados de cola. Exim almacena sobre/encabezados y cuerpo en el spool, y deja que los queue runners procesen los intentos de entrega vencidos. Apache James se ejecuta sobre la JVM y combina servidores de protocolo, cola y una canalización Mailet con backends de almacenamiento intercambiables. Los tres hablan SMTP, pero sus modelos de procesos, colas, extensiones y recuperación no son intercambiables.

El lenguaje de programación y el runtime influyen en el empaquetado, el proceso de parches, el perfil de memoria y la extensibilidad, no en la semántica del diálogo SMTP. Postfix se compila con una toolchain C nativa para sistemas tipo Unix (Postfix INSTALL); la documentación de Exim indica ANSI C como lenguaje de implementación. En cambio, Apache James se describe como plataforma Java/Scala sobre la JVM (Apache James). Un servicio en la nube puede representar las mismas funciones RFC mediante microservicios propietarios, colas distribuidas y API. Por tanto, para la aprobación operativa deben documentarse no solo las capacidades EHLO, sino también la garantía de persistencia, el modelo de reintentos, la exportación de cola, la copia de seguridad, la gestión de claves, los límites de escalado y las zonas de fallo.

Del flujo de entrega se deriva una resolución de problemas fija: determinar el destino, comprobar la conexión y el diálogo SMTP, evaluar la respuesta y después seguir la cola y el siguiente salto.

Diagnóstico desde DNS hasta la cola

Un diagnóstico SMTP fiable sigue la ruta de entrega y mantiene separadas las capas de observación. Las pruebas deben realizarse con dominios de prueba y destinatarios autorizados; no deben utilizarse servidores ajenos para pruebas de relay, validación de direcciones o carga.

Determinar el destino MX y las direcciones

Resolve-DnsName example.ch -Type MX -DnsOnly
Resolve-DnsName mx1.example.ch -Type A -DnsOnly
Resolve-DnsName mx1.example.ch -Type AAAA -DnsOnly

dig +noall +answer example.ch MX
dig +noall +answer mx1.example.ch A
dig +noall +answer mx1.example.ch AAAA

Resolve-DnsName y dig muestran datos DNS publicados. La salida debe comprobarse respecto a Preference, Null MX, cadenas CNAME, IPv4/IPv6 y el resolvedor realmente consultado. Una respuesta DNS no acredita ni la función del listener ni la de TLS.

Comprobar la accesibilidad TCP del salto elegido

Test-NetConnection mx1.example.ch -Port 25 -InformationLevel Detailed
Test-NetConnection submit.example.ch -Port 587 -InformationLevel Detailed
Test-NetConnection submit.example.ch -Port 465 -InformationLevel Detailed

nc -vz -w 5 mx1.example.ch 25
nc -vz -w 5 submit.example.ch 587
nc -vz -w 5 submit.example.ch 465

Test-NetConnection y nc comprueban aquí únicamente la resolución DNS y el establecimiento TCP. Un éxito en el puerto 25 no indica si el greeting SMTP llega a tiempo; un éxito en 587 o 465 no dice nada sobre la política TLS y AUTH.

Comprobar STARTTLS, EHLO y el certificado

openssl.exe s_client -connect mx1.example.ch:25 -starttls smtp `
  -name probe.example.net -servername mx1.example.ch `
  -verify_hostname mx1.example.ch -verify_return_error -brief

openssl s_client -connect mx1.example.ch:25 -starttls smtp \
  -name probe.example.net -servername mx1.example.ch \
  -verify_hostname mx1.example.ch -verify_return_error -brief

openssl s_client ejecuta con -starttls smtp el diálogo en texto claro necesario, establece con -name el nombre SMTP EHLO y con -servername SNI. -verify_hostname y -verify_return_error convierten el mero handshake en una prueba explícita de nombre PKIX. El resultado describe OpenSSL con su truststore, no automáticamente la política del MTA de producción.

Probar de forma controlada el sobre y la fase de respuesta

swaks.exe --server mx1.example.ch --port 25 --tls `
  --ehlo probe.example.net --from sender@example.net `
  --to test-recipient@example.ch --quit-after RCPT

swaks --server mx1.example.ch --port 25 --tls \
  --ehlo probe.example.net --from sender@example.net \
  --to test-recipient@example.ch --quit-after RCPT

swaks registra comandos y respuestas SMTP, y puede terminar deliberadamente la prueba tras RCPT sin enviar datos de mensaje. La herramienta no es un componente del sistema en Windows; swaks.exe o una instalación de Perl debe proceder de una fuente controlada. Una prueba RCPT solo puede realizarse contra sistemas y direcciones propios o explícitamente autorizados, porque activa políticas, directorios y límites de tasa.

Examinar listeners y paquetes en el servidor

Get-NetTCPConnection -State Listen -LocalPort 25,465,587
pktmon filter add SMTP25 -p 25
pktmon start --capture --pkt-size 0
pktmon stop
pktmon etl2pcap PktMon.etl --out smtp.pcapng

ss -ltnp '( sport = :25 or sport = :465 or sport = :587 )'
tcpdump -ni any -s 0 -w smtp.pcap 'tcp port 25 or tcp port 465 or tcp port 587'

Get-NetTCPConnection y ss asignan listeners y estados TCP a procesos locales. pktmon y tcpdump capturan paquetes; las capturas de producción pueden contener direcciones de sobre, contenidos sin cifrar y datos de autenticación, y deben protegerse, limitarse y eliminarse en consecuencia. Wireshark es adecuado para analizar handshakes TCP, SMTP y TLS, pero no sustituye ni los registros de cola ni los de política.

Asignar el error a un límite

Observabilidad y modelo operativo

Un monitor SMTP no debe limitarse a enviar un correo de prueba. Debe hacer visibles los estados individuales del sistema:

• latencia de Greeting, EHLO, STARTTLS, AUTH y End-of-Data por separado;
• conexiones, sesiones, transacciones activas y rechazos por fase;
• capacidades ESMTP ofrecidas por listener y backend;
• tasa de aceptación, número de destinatarios, tamaño de mensaje y latencia de escritura durable;
• volumen de cola por antigüedad, destino, transporte, estado y último error;
• tasa de reintentos, mensaje más antiguo, entregas que expiran y generación de DSN;
• destino DNS, IP conectada, IPv4/IPv6, modo TLS, cipher y resultado de política;
• códigos de respuesta como campos estructurados en lugar de exclusivamente texto libre;
• correlación de ID de edge, ID interno de cola, ID de cola remoto, Message-ID y destinatario;
• estado LMTP/buzón por destinatario, así como rutas de cuarentena y liberación;
• capacidad de spool, latencia de I/O, estado de base de datos o broker y retraso de replicación;
• límites de protección para registros y capturas, porque el sobre, los encabezados y los contenidos contienen datos personales o confidenciales.

Las copias de seguridad de la cola por sí solas no bastan. La restauración debe considerar configuración, tablas de enrutamiento, certificados y claves, metadatos de cola, blobs de mensajes, cuarentena, estado de firma e idempotencia. Tras una restauración, una copia de destinatario ya entregada no debe reenviarse de forma incontrolada; al mismo tiempo, no deben perderse los destinatarios aún pendientes de un mensaje entregado parcialmente. Por ello, RPO y RTO deben definirse para cada componente de estado y probarse con una cola real con varios destinatarios.

Historia técnica

SMTP surgió de procedimientos de correo ARPANET anteriores. El RFC 821 de Jon Postel estandarizó en 1982 el modelo todavía reconocible de SMTP emisor, SMTP receptor, MAIL, RCPT, DATA y respuestas de tres dígitos. El formato de mensaje se describió por separado ese mismo año en RFC 822. Esta separación entre protocolo de transferencia y formato de mensaje se ha mantenido.

Con MIME, SMTP creció más allá del texto puro de 7 bits. El marco ESMTP introdujo EHLO, capacidades registradas y parámetros en MAIL y RCPT; su versión de 1995 figuraba en RFC 1869. Extensiones basadas en él como SIZE, 8BITMIME, PIPELINING, AUTH, STARTTLS, CHUNKING, DSN y, posteriormente, SMTPUTF8 desarrollaron el protocolo de forma incremental, sin crear una pila paralela de «SMTP 2».

RFC 2821 consolidó SMTP en 2001 y sustituyó RFC 821 y varios documentos complementarios. RFC 5321 siguió en 2008 como otra consolidación; el Internet Message Format correspondiente figura en RFC 5322. Message Submission se especificó inicialmente por separado y se consolidó en RFC 6409. Así, la evolución técnica avanzó mediante funciones más claras, registros de extensiones, direcciones internacionalizadas, informes de entrega y política de transporte, mientras que el diálogo básico con estado se mantuvo compatible.

Las arquitecturas de software también evolucionaron en direcciones distintas. La compatibilidad histórica con Sendmail marcó las interfaces locales de línea de comandos; Postfix apostó por procesos cooperativos separados por privilegios y colas explícitas, Exim por un enfoque de router/transporte y spool muy configurable, y sistemas JVM como Apache James hicieron extensible el procesamiento mediante componentes y Mailets. Las plataformas en nube distribuyen las mismas funciones lógicas entre frontends, brokers, servicios de política y colas regionales. Para los administradores, la semántica RFC sigue siendo el denominador común, mientras que la persistencia, escalabilidad y recuperación siempre deben acreditarse de manera específica para cada producto.

Fuentes

• RFC 5321 – Simple Mail Transfer Protocol – modelo SMTP, enrutamiento, comandos, respuestas, cola, reintentos, traza y responsabilidad de entrega.
• RFC 5598, sección 4
• RFC 6409 – Message Submission for Mail – separación entre submission y relay, funciones, puerto 587 y política MSA.
• RFC 5322 – Internet Message Format – encabezados, cuerpo, campos de dirección, Message-ID y campos de traza.
• RFC 3207 – SMTP Service Extension for Secure SMTP over TLS – STARTTLS y restablecimiento del estado SMTP.
• RFC 2920 – SMTP Command Pipelining – grupos de comandos ordenados sin un round trip por comando.
• RFC 7505 – A Null MX No Service Resource Record – identificación explícita de dominios sin capacidad de correo.
• RFC 3464 – Delivery Status Notification Format – estructura DSN legible por máquina y estado de destinatarios.
• IANA – SMTP Enhanced Status Codes – significados registrados de los códigos de detalle.
• RFC 3463 – Enhanced Mail System Status Codes – estructura y clases de códigos de estado ampliados.
• RFC 5248 – SMTP Enhanced Status Code Registry – modelo de registro para Enhanced Codes.
• IANA – Simple Mail Transfer Protocol Parameters – comandos SMTP, extensiones y palabras clave EHLO.
• RFC 1870 – SMTP SIZE Extension – negociación de tamaño y rechazo antes del contenido.
• RFC 6152 – SMTP Service Extension for 8-bit MIME Transport – 8BITMIME y parámetro BODY.
• RFC 3030 – CHUNKING and BINARYMIME – transferencia BDAT y mensajes MIME binarios.
• RFC 6531 – SMTP Extension for Internationalized Email – SMTPUTF8 y buzones internacionales.
• RFC 3461 – SMTP Service Extension for Delivery Status Notifications – parámetros de sobre para solicitudes DSN.
• RFC 4954 – SMTP Service Extension for Authentication – comando AUTH y perfil SASL para SMTP.
• RFC 8314, sección 7.3
• IANA – Service Name and Transport Protocol Port Number Registry – asignación de SMTP, Submission y Submissions a puertos.
• RFC 4422, sección 3.4
• RFC 7628 – SASL Mechanisms for OAuth – mecanismos SASL basados en OAuth para SMTP y otros protocolos.
• RFC 7672 – SMTP Security via DANE TLS – política de transporte SMTP vinculada a DNSSEC y TLSA.
• RFC 8461 – SMTP MTA Strict Transport Security – política MX y TLS basada en PKIX.
• RFC 8460 – SMTP TLS Reporting – informes agregados sobre errores TLS de transporte.
• RFC 2033, sección 4.2
• Postfix – Architecture Overview – funciones de proceso, Queue Manager y agentes de entrega.
• Exim – How Exim receives and delivers mail – modelo de spool, enrutamiento, transporte y queue runner.
• Postfix – Installation From Source Code – requisitos nativos de compilación, plataforma y toolchain.
• Exim – resumen técnico – ANSI C como lenguaje de implementación y características técnicas del producto.
• Apache James Project – arquitectura de JVM, Java/Scala y componentes.
• Microsoft Learn – Resolve-DnsName – consultas DNS en Windows.
• BIND 9 – manual de dig – consultas DNS en sistemas Unix.
• Microsoft Learn – Test-NetConnection – accesibilidad TCP en Windows.
• OpenBSD – nc(1) – conexiones TCP con Netcat.
• OpenSSL – s_client – diagnóstico de STARTTLS, SNI y certificados.
• Swaks – Swiss Army Knife for SMTP – prueba de transacciones y extensiones SMTP.
• Microsoft Learn – Get-NetTCPConnection – listeners y conexiones TCP locales.
• Linux man-pages – ss(8) – diagnóstico de sockets y estados TCP.
• Microsoft Learn – Packet Monitor – captura de paquetes de Windows y conversión PCAPNG.
• manual de tcpdump(1) – diagnóstico basado en paquetes en sistemas Unix.
• Guía de usuario de Wireshark – análisis interactivo de trazas de red y protocolo.
• RFC 821 – Simple Mail Transfer Protocol – especificación SMTP histórica de 1982.
• RFC 1869 – SMTP Service Extensions – marco ESMTP histórico y modelo EHLO.
• RFC 2821 – Simple Mail Transfer Protocol – consolidación SMTP de 2001.
• RFC 3848 – ESMTP and LMTP Transmission Types – valores with como ESMTPSA en encabezados Received.