SMTP y el ecosistema de correo

SMTP mueve mensajes entre sistemas y recibe envíos de clientes. El correo visible en un buzón es el resultado de varias capas: resolución DNS, transporte SMTP, políticas de dominio, contenido MIME, filtrado y acceso posterior mediante IMAP, POP3 o una API.

El MTA emisor consulta los registros MX del dominio destinatario. El número menor tiene mayor preferencia. Si no existe MX, SMTP permite recurrir al registro A o AAAA del dominio bajo condiciones definidas por RFC 5321.

dig +short MX example.test
dig +short A mail.example.test
dig +short AAAA mail.example.test

Un MX identifica una ruta de recepción, no el servicio de submission de los usuarios ni todos los sistemas que pueden enviar por el dominio.

El puerto orienta. El banner, EHLO, TLS, AUTH y la política aplicada confirman el rol efectivo.

SMTP usa líneas terminadas por CRLF. El servidor inicia con 220. El cliente envía EHLO para ESMTP o HELO para SMTP básico. Las respuestas se agrupan por primera cifra:

• 2xx: operación aceptada
• 3xx: se espera información adicional
• 4xx: fallo temporal que permite reintento
• 5xx: fallo permanente para esa transacción

Una respuesta multilínea repite el código con guion y termina con el mismo código seguido de espacio.

Una sesión atraviesa tres estados:

1. conexión y saludo
2. transacción de correo
3. actualización o cierre

Los comandos principales son:

El servidor puede aceptar varios RCPT TO para un solo mensaje. Tras DATA, una línea con un único punto termina el contenido. Dot-stuffing duplica un punto inicial para que no se confunda con el terminador.

El envelope controla transporte:

MAIL FROM:<bounce@example.test>
RCPT TO:<recipient@example.net>

Las cabeceras están dentro de DATA:

From: Display Name <author@example.test>
To: Recipient <recipient@example.net>
Subject: Example

MAIL FROM y From: pueden ser distintos. SPF normalmente evalúa la identidad MAIL FROM o HELO. DMARC evalúa la alineación con el dominio visible de From:. Una UI puede mostrar solo la cabecera y ocultar la ruta real.

Cada MTA añade una cabecera Received al principio. La cadena se lee desde abajo hacia arriba para reconstruir saltos, pero las líneas más antiguas pueden proceder de una fuente no confiable. Conserva cabeceras completas, Return-Path, Authentication-Results, DKIM-Signature y MIME antes de interpretar autenticidad.

EHLO puede anunciar:

• SIZE: tamaño máximo aceptado
• PIPELINING: varios comandos sin esperar cada respuesta
• STARTTLS: actualización a TLS
• AUTH: mecanismos SASL
• 8BITMIME: cuerpos con octetos de ocho bits
• SMTPUTF8: direcciones y cabeceras internacionalizadas
• DSN: notificaciones de estado de entrega
• CHUNKING: transferencia mediante BDAT

La lista puede cambiar después de STARTTLS o autenticación. Envía un nuevo EHLO tras actualizar el canal.

STARTTLS protege la conexión a partir de su negociación. No cifra el saludo anterior. Tampoco demuestra que el emisor valide el certificado, que todos los saltos usen TLS o que el servidor rechace downgrade.

AUTH suele usar SASL. Mecanismos frecuentes incluyen PLAIN, LOGIN, CRAM-MD5, OAuth bearer y NTLM en entornos Microsoft. PLAIN y LOGIN codifican datos con Base64, no los cifran. Su protección depende de TLS.

Submission normalmente exige autenticación y aplica identidad, rate, tamaño y destinatarios. Un MTA de entrada puede aceptar correo no autenticado solo para sus dominios locales. Esa diferencia es la base de una prueba de relay.

Un 250 tras RCPT TO o tras el final de DATA significa que ese servidor asumió responsabilidad según esa fase. La entrega final todavía puede depender de:

• lookup del destinatario posterior
• content filtering y sandbox
• políticas antispam
• cola y reintentos
• siguiente MTA
• cuota o reglas del buzón
• generación de bounce

Greylisting responde temporalmente a una combinación desconocida y espera que un MTA legítimo reintente. Tarpitting retrasa respuestas. Catch-all acepta destinatarios desconocidos. Estas técnicas alteran enumeración, timing y significado de un único código.

SPF publica una política DNS TXT que autoriza IP para la identidad del envelope. No firma el contenido y el forwarding puede romper su relación.

dig +short TXT example.test

DKIM añade una firma que cubre cabeceras seleccionadas y un hash del cuerpo. La clave pública vive en SELECTOR._domainkey.DOMAIN.

dig +short TXT SELECTOR._domainkey.example.test

DMARC publica política en _dmarc.DOMAIN y exige alineación del dominio visible From: con una validación SPF o DKIM:

dig +short TXT _dmarc.example.test

p=none solicita observación. quarantine y reject expresan tratamiento deseado, pero el receptor mantiene la decisión efectiva.

MTA-STS publica un indicador DNS y una política HTTPS que permite exigir TLS y MX válidos para transferencias entrantes:

dig +short TXT _mta-sts.example.test
curl --fail --silent --show-error \
  https://mta-sts.example.test/.well-known/mta-sts.txt

TLS Reporting publica _smtp._tls.DOMAIN para recibir informes agregados de fallos TLS:

dig +short TXT _smtp._tls.example.test

Estas políticas no son equivalentes. SPF, DKIM y DMARC tratan identidad y autenticidad. MTA-STS y TLS-RPT tratan protección y fallos del transporte SMTP.

• Enumeración SMTP convierte un endpoint en un modelo verificado.
• IMAP y POP3 cubre acceso al correo almacenado.
• Explotación y abuso del correo separa relay, spoofing, credenciales, NTLM y delivery.

• RFC 5321: Simple Mail Transfer Protocol
• RFC 5322: Internet Message Format
• RFC 3207: SMTP STARTTLS
• RFC 6409: Message Submission
• RFC 8314: Cleartext Considered Obsolete
• RFC 7208: SPF
• RFC 6376: DKIM
• RFC 7489: DMARC
• RFC 8461: MTA-STS
• RFC 8460: SMTP TLS Reporting