SMTP

El correo electrónico no suele viajar directamente del cliente del remitente al buzón final. Pasa por submission, transferencia entre dominios, gateways y entrega local. Simple Mail Transfer Protocol (SMTP) coordina esos saltos mediante una conversación de texto y un modelo store-and-forward: un servidor acepta responsabilidad por el envelope y decide qué hacer después.

Por eso un 250 no tiene el mismo significado en todas las fases. Puede aceptar un comando, un destinatario o el mensaje completo sin demostrar todavía entrega. El endpoint también puede cambiar su política según puerto, origen, TLS y autenticación. Enumerar SMTP consiste en identificar ese rol, recorrer sus estados y conservar exactamente hasta qué punto llegó cada aceptación.

Los ejemplos usan TARGET_IP, FQDN, SENDER, RECIPIENT y EXTERNAL_RECIPIENT como placeholders.

SMTP y el ecosistema de correo desarrolla estados, envelope, cabeceras, MX, autenticación y políticas de dominio. Esta página se centra en obtener y contrastar señales remotas.

Antes del socket, registra MX, direcciones, SPF, DMARC, MTA-STS y TLS-RPT. Los selectores DKIM suelen obtenerse de mensajes reales o convenciones conocidas, no de una enumeración DNS universal.

dig +short MX DOMAIN
dig +short A MAIL_FQDN
dig +short AAAA MAIL_FQDN
dig +short TXT DOMAIN
dig +short TXT _dmarc.DOMAIN
dig +short TXT _mta-sts.DOMAIN
dig +short TXT _smtp._tls.DOMAIN

Relaciona cada nombre con IP, ASN, proveedor, certificado y rol aparente. Un gateway cloud puede recibir correo mientras la organización usa otro endpoint para submission.

Una ruta de correo puede incluir un Mail User Agent, un servicio de submission, varios Mail Transfer Agents y un Mail Delivery Agent. Los puertos orientan, pero el diálogo confirma el rol:

SMTP usa respuestas numéricas. 2xx indica éxito, 3xx espera más datos, 4xx es un fallo temporal y 5xx uno permanente. El código 220 abre la sesión, 250 acepta una operación y 354 pide el contenido del mensaje.

nc -nv evita resolución de nombres y muestra el resultado de la conexión. Al conectar, el servidor suele enviar un banner 220:

nc -nv TARGET_IP 25

Empieza con EHLO FQDN. A diferencia de HELO, EHLO solicita las extensiones ESMTP:

EHLO FQDN

Cada línea 250- anuncia una capacidad. En la última, el guion que sigue a 250 se sustituye por un espacio para cerrar la respuesta. Son frecuentes SIZE, PIPELINING, STARTTLS, AUTH, 8BITMIME, SMTPUTF8 y DSN. Una extensión anunciada puede seguir condicionada por TLS, autenticación, dirección de origen o fase de la transacción.

Nmap puede automatizar la misma pregunta. smtp-commands envía EHLO y otros comandos de descubrimiento:

nmap -sV -p 25 --script smtp-commands TARGET_IP

Usa herramientas, automatización y NSE para SMTP para elegir scripts concretos. No ejecutes smtp-*: en Nmap 7.99 el glob incluye fuerza bruta y comprobaciones de vulnerabilidades intrusivas.

swaks conserva una transacción reproducible y permite detenerse en una fase. --server fija el endpoint, --port el puerto, --ehlo la identidad del cliente y --quit-after EHLO evita comenzar un envelope:

swaks --server TARGET_IP --port 25 \
  --ehlo FQDN --quit-after EHLO

STARTTLS actualiza una conexión SMTP existente. openssl s_client -starttls smtp realiza EHLO, solicita STARTTLS y continúa con el handshake. -connect fija el endpoint y -servername envía SNI:

openssl s_client -connect FQDN:25 -starttls smtp -servername FQDN

Después de negociar TLS debe enviarse un nuevo EHLO, porque las capacidades pueden cambiar. Por ejemplo, AUTH puede aparecer solo dentro del canal cifrado. La presencia de STARTTLS no demuestra que otros servidores estén obligados a usarlo ni que la validación del certificado sea estricta.

Para el puerto 465 no se utiliza -starttls smtp, ya que TLS comienza al conectar:

openssl s_client -connect FQDN:465 -servername FQDN

Registra versión TLS, cipher, cadena, SAN, emisor, validez y resultado de verificación. Repite EHLO dentro de TLS y compara capacidades. Un endpoint que anuncia AUTH antes de TLS puede permitir credenciales sobre texto claro aunque el cliente habitual no lo haga.

El envelope SMTP se construye con MAIL FROM y RCPT TO. No es lo mismo que las cabeceras From: y To: incluidas después de DATA.

EHLO FQDN
MAIL FROM:<SENDER>
RCPT TO:<RECIPIENT>
RSET
QUIT

RSET descarta la transacción actual sin cerrar la sesión. Las respuestas a RCPT TO pueden revelar si el servidor acepta un destinatario local, lo rechaza inmediatamente o aplaza la validación. Catch-all, greylisting, tarpitting y validación posterior pueden impedir deducir la existencia de una cuenta a partir de una única respuesta.

VRFY pide verificar una identidad y EXPN expandir una lista. Muchos servidores los deshabilitan o devuelven respuestas deliberadamente ambiguas:

VRFY USERNAME

Una respuesta 252 Cannot VRFY user no confirma ni descarta la cuenta. Compara códigos, texto y tiempo de respuesta con candidatos inexistentes antes de extraer una conclusión.

Compara controles válidos, inválidos y sintácticamente erróneos mediante un único método. Cambia solo el local-part. Registra código, texto y latencia. Las diferencias pueden aparecer en:

• VRFY USERNAME
• EXPN LIST
• RCPT TO:<USERNAME@DOMAIN> después de un MAIL FROM
• autenticación, cuando la política y el bloqueo están caracterizados

smtp-user-enum automatiza VRFY, EXPN o RCPT. -M elige el método, -U el archivo de usuarios, -t el objetivo y -D el dominio:

smtp-user-enum -M RCPT -U users.txt -D DOMAIN -t TARGET_IP

La herramienta genera intentos por cada candidato. Define límite, pausa y criterios de parada antes de una lista amplia. Catch-all produce positivos para usuarios inventados. Greylisting produce fallos temporales. Tarpitting hace que la velocidad aparente cambie. Un gateway puede aceptar todos los destinatarios y validarlos en otro salto.

Usa un control aleatorio por lote y detén la enumeración si válidos e inválidos convergen.

Un relay acepta un mensaje y lo reenvía hacia otro dominio. Un servidor de entrada debe aceptar correo destinado a sus dominios, pero no debería retransmitir correo arbitrario entre remitentes y destinatarios externos sin una relación de confianza.

La comprobación se realiza sobre el envelope. Tras EHLO, se usa un remitente no local y RCPT TO apunta a EXTERNAL_RECIPIENT:

EHLO FQDN
MAIL FROM:<SENDER>
RCPT TO:<EXTERNAL_RECIPIENT>
RSET
QUIT

No es necesario enviar DATA para observar si el destinatario se acepta en esa fase. Un 250 todavía puede terminar en rechazo posterior, moderación o entrega fallida. Registra origen de red, TLS, autenticación y secuencia, porque la política puede variar con cada factor.

El script smtp-open-relay prueba varias combinaciones de envelope. Su output debe validarse manualmente para conocer cuál fue aceptada:

nmap -p 25 --script smtp-open-relay TARGET_IP

El script pertenece a external e intrusive en Nmap 7.99 y usa valores predeterminados si no recibe dominio, remitente y destinatario. Define destinos controlados mediante argumentos o usa swaks:

swaks --server TARGET_IP --port 25 \
  --ehlo FQDN \
  --from SENDER \
  --to EXTERNAL_RECIPIENT \
  --quit-after RCPT

Un 250 en RCPT sostiene la hipótesis de aceptación en esa fase. Para confirmar relay efectivo puede ser necesaria una entrega controlada y la revisión de cabeceras, pero esa acción cambia el estado y debe estar prevista en el plan.

Compara AUTH antes y después de STARTTLS. Registra mecanismos, políticas de cifrado, realm o dominio y respuestas a un control conocido. No pongas contraseñas en la línea de comandos si la herramienta puede leerlas de forma interactiva o desde un descriptor protegido.

Una cuenta válida se prueba primero con una sola autenticación. Antes de password spraying hay que conocer bloqueo, rate limiting, MFA, alertas y tratamiento de identidades federadas. La explotación y abuso del correo contiene las ramas posteriores.

Cruza banner, EHLO, certificado, formato de errores, hostnames y tiempos. No atribuyas una versión solo por el banner.

Cuando AUTH NTLM está disponible, algunos servicios Microsoft devuelven un mensaje NTLMSSP de challenge ante una negociación sin credenciales. Puede exponer nombres NetBIOS, DNS y build. El script smtp-ntlm-info automatiza esa petición. Valida que los nombres pertenezcan al backend actual y no a una respuesta cacheada o gateway.

Según la acción, el operador produce:

• consultas DNS públicas o internas
• conexión TCP y banner
• EHLO, HELP, STARTTLS y handshake
• comandos VRFY, EXPN, MAIL y RCPT
• eventos de autenticación y bloqueo
• entrada de cola si se completa DATA
• mensajes y cabeceras en un buzón controlado

Un gateway puede registrar la IP de origen, EHLO, envelope, TLS fingerprint, latencia, comando rechazado y reputación. Conserva transcripción con CRLF normalizado y una captura acotada cuando necesites explicar el estado.

Actualiza:

1. rol por endpoint
2. capacidades antes y después de TLS
3. certificados y nombres
4. dominios locales, relay y recipient validation
5. autenticación y mecanismos
6. políticas SPF, DKIM, DMARC, MTA-STS y TLS-RPT
7. incertidumbres y controles que impidieron concluir
8. siguientes ramas hacia IMAP/POP3, credenciales, relay o delivery

La checklist SMTP protege la cobertura y la cheatsheet recupera sintaxis.

En Postfix, postconf -n muestra parámetros no predeterminados y postconf -M los servicios definidos en master.cf:

postconf -n
postconf -M

Relaciona myhostname, mydomain, mydestination, mynetworks, relay_domains, restricciones de cliente, remitente y destinatario, mapas virtuales y parámetros TLS. La decisión final puede depender de mapas externos, milters y policy services, no solo de una directiva.

Amplía Swaks, smtp-user-enum y NSE en herramientas y automatización. La checklist controla dominio, endpoint, TLS, destinatarios y relay. La cheatsheet recupera consultas ya explicadas.

• RFC 5321: Simple Mail Transfer Protocol
• RFC 3207: SMTP Service Extension for Secure SMTP over TLS
• RFC 6409: Message Submission for Mail
• RFC 8314: Cleartext Considered Obsolete
• Postfix Basic Configuration
• Nmap NSE: smtp-open-relay
• Swaks documentation
• smtp-user-enum