Resumen

  • SMTP AUTH añadió una negociación SASL antes de la transacción de correo. El servidor podía otorgar derechos de envío según una identidad autorizada, no según la mera dirección de red del cliente.
  • La autenticación solo describía esa sesión. La identidad autorizada, el remitente del sobre, el supuesto emisor original, el autor visible y el contenido seguían siendo afirmaciones independientes.

El viajero legítimo parecía un extraño

Restringir el relevo a las direcciones IP de un proveedor funcionaba mientras el usuario permanecía en la red del proveedor. Al viajar, el mismo cliente aparecía desde otro acceso y perdía el privilegio. Abrir el servidor a cualquiera arreglaba la movilidad a costa de convertirlo en infraestructura para abuso.

Hubo soluciones indirectas. POP-before-SMTP observaba un acceso reciente al buzón y, durante una ventana, confiaba en la misma IP para enviar. Esa asociación mezclaba dos protocolos, dependía de una dirección cambiante y podía conceder permiso al siguiente usuario de la IP. Faltaba una prueba dentro del propio acto de envío.

La extensión de 1999 y su sustituta, RFC 4954, añadieron AUTH a SMTP. Tras EHLO, el servidor publica los mecanismos SASL que acepta. El cliente elige uno y completa el intercambio antes de comenzar con MAIL FROM. Una respuesta exitosa establece que el servidor aceptó las credenciales y derivó una identidad de autorización para la sesión.

Eso basta para decidir el acceso al relevo. No basta para atribuir el mensaje.

Dos identidades evitaban una conclusión falsa

SASL nombra por separado la identidad de autenticación, vinculada a las credenciales, y la identidad de autorización, aquella como la que el cliente pide actuar. El servidor verifica ambas relaciones: que la credencial es válida y que su titular puede asumir el rol solicitado.

La distinción permite delegación sin ficción. Un servicio de cola se autentica como servidor y transporta mensajes enviados originalmente por muchos usuarios. Una cuenta administrativa puede actuar por varios buzones. Una persona puede tener derecho sobre un alias y no sobre otro. La misma contraseña correcta puede acompañar una petición no autorizada.

Por eso ni el argumento MAIL FROM, ni el From del encabezado, ni el nombre de usuario sustituyen la decisión de autorización. Cada uno responde a una pregunta distinta. La sesión dice quién se presentó; la política dice qué puede hacer; el sobre dice dónde deben ir los informes y qué identidad de transporte se afirma; el contenido todavía necesita su propia evidencia.

El límite adecuado fue el servidor de envío

RFC 6409 separó al Message Submission Agent del Message Transfer Agent. El primero recibe un mensaje nuevo desde el agente del usuario, normalmente por el puerto 587; el segundo acepta o retransmite correo entre sistemas. La misma gramática SMTP sirve a relaciones operativas diferentes.

El MSA debe rechazar por defecto el comando MAIL con 530 si la sesión no está autenticada ni cuenta con otra autorización independiente, como una subred protegida. El requisito pertenece al servicio de envío, donde proveedor y cliente mantienen una relación de cuenta. No convierte todos los saltos públicos en un login de usuario.

Así fue posible que una persona enviara desde una red ajena sin que el proveedor abriera el relevo. El operador podía asociar límites, dominios y delegaciones a la cuenta. El MTA seguía recibiendo correo destinado a sus dominios aunque el emisor remoto no fuera cliente del proveedor.

AUTH=<> conservaba una ausencia

Además del comando, RFC 4954 define un parámetro AUTH= en MAIL FROM. Sirve para asociar cada mensaje con la identidad que supuestamente lo introdujo en el sistema de entrega. No repite necesariamente la identidad con la que el relevo actual inició sesión.

Entre agentes cooperantes y fiables, esa información puede cruzar varios saltos. Un servidor de cola mantiene la procedencia de cada mensaje aunque use una sola credencial para toda la conexión. El receptor decide si la relación con el par justifica creer la afirmación.

Cuando no hay suficiente confianza, el protocolo no exige inventar un nombre. AUTH=<> declara que el emisor original es desconocido o insuficientemente autenticado. Si el relevo actual se autentica, no debe ocupar automáticamente ese espacio. Saber quién entregó el paquete ahora no revela quién lo depositó al principio.

Este detalle es más importante que la sintaxis. La incertidumbre queda transportable. Los registros y filtros pueden conservarla en vez de convertir una conexión válida en una biografía falsa.

El canal seguro no ampliaba la afirmación

Un mecanismo como PLAIN necesita protección contra la escucha. RFC 4954 exige que exista una configuración que no lo anuncie sin TLS u otra capa protectora. Después de STARTTLS, el servidor puede publicar una lista distinta de mecanismos; el cambio refleja el nuevo canal, no un cambio mágico de identidad.

RFC 8314 recomienda TLS para todo el tráfico entre agentes de usuario y servidores de envío. El puerto 587 puede elevar la conexión mediante STARTTLS y el 465 comienza con TLS implícito. Si el cliente valida el certificado, reduce el riesgo de entregar la credencial a un impostor.

El cifrado termina en ese servidor. No prueba la autoría del cuerpo, no autentica automáticamente el siguiente salto y no convierte el encabezado visible en verdad. RFC 4954 excluye expresamente esa conclusión: SMTP AUTH autentica el envío, no la autoría del contenido.

La huella operativa tenía tamaño de un salto

RFC 3848 permite que el servidor escriba ESMTPA o ESMTPSA en Received cuando hubo AUTH, o AUTH más TLS, en su recepción. Un operador puede reconstruir si un mensaje entró por el canal de clientes o por transferencia pública.

La línea vale lo que vale su productor. Una cabecera creada fuera del perímetro puede imitar la palabra; una cabecera interna solo narra lo observado en esa frontera. De igual modo, 235 indica éxito del intercambio, 530 exige autenticación y 535 rechaza credenciales. Ningún código decide la reputación, la verdad del remitente ni la aceptación final.

Dos registros, ninguna oficina de cuentas

IANA registra la extensión SMTP y, por separado, los nombres de mecanismos SASL. Esa división permite que SMTP conserve una interfaz estable mientras mecanismos concretos cambian de estado o aparecen otros nuevos. Cliente y servidor comparten vocabulario sin fijar para siempre una forma de contraseña.

El registro no administra usuarios. No decide qué buzón puede usar una credencial ni cuánto correo puede relevar. La coordinación común llega hasta los nombres y referencias; la ejecución, el riesgo y la revocación permanecen en los sistemas que aceptan la sesión.

SMTP AUTH tuvo éxito porque limitó el alcance de su respuesta. Un login podía abrir una puerta, activar una política y dejar evidencia local. No firmaba la carta. Esa modestia convirtió una credencial en control útil sin convertirla en autoridad sobre todo el mensaje.

Fuentes