Resumen

  • El correo normal ofrece un reverse-path para fallas posteriores. Una notificación usa MAIL FROM:<> para que su propio fracaso no reclame otra notificación.
  • Null es un estado explícito del envelope, no un From: ausente, anonimato legítimo ni exención de control. Debe aceptarse en submission y SPF aún puede evaluar el host mediante HELO.
  • Los DSN estructurados separaron resultados por destinatario y mejoraron la correlación. Mantuvieron vacío el sender porque más detalle no concede permiso para iniciar otra rama de error.

El error conocido y el error tardío

Si un servidor conoce la falla mientras el cliente sigue conectado, puede rechazar MAIL o RCPT. El reply negativo devuelve el hecho en la misma sesión; el cliente conserva la responsabilidad. No hay bounce.

La situación cambia después de aceptar DATA. Un relay puede almacenar el mensaje y responder positivamente, pero descubrir después una mailbox inexistente, una lista imposible de expandir o un gateway caído. Entonces el error se convierte en correo y viaja al reverse-path original.

Si esa notificación tuviera sender ordinario, su falla exigiría una notificación al sender de la notificación. Cada promesa de fiabilidad podría crear la siguiente. RFC 821 ya advirtió en 1982 que no debían enviarse notices sobre problemas con notices y mostró MAIL FROM:<>.

Los ángulos vacíos no representan una mailbox sin nombre. Eliminan el destino remoto de un futuro reporte. El mensaje sigue teniendo sistema productor, conexión, RCPT y trace. “Senderless” confunde ausencia de retorno con ausencia de actor.

Soportar el vacío pasó a ser obligatorio

RFC 1123 exigió soporte para el empty reverse-path. Un servidor no puede tratarlo como error de sintaxis sólo porque espera una dirección habitual.

También exigió que el aviso post-aceptación use <> y que no se genere otro aviso cuando la dirección original ya es null. Aceptar la forma y desobedecer el efecto recrea el loop; rechazarla siempre elimina mensajes legítimos.

La implementación correcta reconoce que null transporta información positiva. Significa “esta transacción no tendrá un receptor remoto para su DSN”, no “el programador olvidó un campo”.

El envelope no era el autor visible

MAIL FROM distribuye responsabilidad de transporte. From: presenta autor o servicio al lector. Reply-To orienta una respuesta humana. Un auto-response puede mostrar una dirección mantenida por personas y llevar simultáneamente MAIL FROM:<>.

El destinatario humano conserva un canal para denunciar una respuesta defectuosa. El MTA, en cambio, sabe que no debe crear mail adicional si la respuesta no se entrega. La diferencia permite usabilidad sin abrir una rama automática.

Un robot que, ante envelope vacío, copia el header From está adivinando una autoridad que el protocolo negó. No está reparando datos incompletos: está modificando el grafo de fallas.

Rechazar durante la transacción reducía backscatter

El RFC 5321 sitúa el handoff formal en el positive completion tras DATA. Antes, la negativa informa al peer real. Después, el receiver debe entregar o informar.

Un atacante puede falsificar el reverse-path ordinario con la dirección de una víctima. Si el servidor acepta y luego rebota, la víctima recibe el DSN. El null sender del DSN impide que ese DSN genere otro, pero no corrige el primer backscatter.

Por eso early rejection, autorización del host y null reverse-path no son sustitutos. El primero evita crear mail cuando la decisión ya existe. La autorización reduce direcciones falsas. Null termina la rama inevitable de un reporte tardío.

Cuando la notificación terminal también falla, RFC 5321 permite log o aviso local, incluso hacia postmaster. La información no debe desaparecer; sólo debe dejar de generar DSN externo. El operador que llegó al final conserva el deber de reparar.

Pedir reportes sin alterar admisión

RFC 3461 creó parámetros DSN. ENVID ayuda a correlacionar; RET controla material original retornado; NOTIFY solicita SUCCESS, FAILURE o DELAY y permite el valor exclusivo NEVER; ORCPT conserva el recipient original.

Parámetros válidos no deben cambiar si MAIL o RCPT se aceptarían. Solicitud de evidencia y admisión son decisiones separadas.

Un MTA no debe emitir DSN para un mensaje cuyo MAIL FROM era null, aunque encuentre una dirección plausible en los headers. Buscarla allí contradice el terminador. Al transmitir el DSN, su sender debe ser <>; no usa RET y, si usa NOTIFY, debe ser NEVER.

La misma transacción puede, por tanto, contener información rica y una negativa absoluta a recibir otro informe.

Un bounce obtuvo estructura por recipient

RFC 3464 definió multipart/report con tipo delivery-status. Puede combinar explicación humana, bloque machine-readable message/delivery-status y material original según reglas de privacidad y retorno.

Un DSN corresponde a un mensaje original, pero contiene estados separados por recipient. Action diferencia failed, delayed, delivered, relayed y expanded. Status, Reporting-MTA, Remote-MTA y Diagnostic-Code hacen posible actuar sin analizar frases locales.

Un delayed indica que aún habrá intentos; un failed señala abandono. Con varios recipients, un éxito y una falla no deben comprimirse en un solo resultado. Las listas pueden actuar sobre la suscripción realmente rota.

La estructura tampoco autentica. Un reporte puede falsificarse y puede revelar forwarding, recipient o contenido. La evidencia debe limitarse a lo necesario. <> continúa siendo esencial porque un reporte más grande haría más costoso un loop.

Vacation bots también podían multiplicarse

Los errores no son los únicos mensajes automáticos. Dos vacation responders pueden contestarse; un service responder puede amplificar una solicitud con retorno falsificado. RFC 3834 prohíbe responder cuando el destino sería una dirección null.

La respuesta automática suele dirigirse a Return-Path, no a una inferencia desde From o Reply-To. Si la respuesta no espera respuesta automática, puede usar MAIL FROM:<> y se recomienda NOTIFY=NEVER.

Esto no autoriza respuestas enormes. Como los return addresses son falsificables, un servicio necesita evidencia de autorización antes de producir gran volumen o efectos secundarios. Terminación y consentimiento gobiernan riesgos distintos.

La política debía reconocer uso legítimo

RFC 6409 dice que un message submission agent no debe rechazar por sí solo un null return path. Los MUA generan legítimamente notifications, incluidas disposition notifications.

El MSA todavía autentica la cuenta, controla autorización, rate y content. Lo que no puede hacer es declarar abuso por un único valor reservado.

RFC 7208 mantiene una superficie SPF. Cuando el reverse-path es null, la identidad MAIL FROM se construye como postmaster en el dominio HELO. La mailbox ausente no borra la identidad del host SMTP.

SPF autoriza host/domain; no certifica el cuerpo, el fallo narrado ni una persona. Un sistema autorizado puede emitir un DSN erróneo. Null no es invisibilidad ni autenticidad.

Null MX no era esta ausencia

Null MX declara en DNS que un domain no recibe correo. Null reverse-path viaja dentro del envelope de un mensaje que sí se está entregando. Uno cierra recepción en un namespace; el otro cierra informes de falla para una transacción.

El vacío explícito evita que silencio y olvido sean indistinguibles. <> dice que la rama terminó deliberadamente.

Fuentes y límites de evidencia

El origen del loop breaker está en RFC 821: https://www.rfc-editor.org/rfc/rfc821.html

El soporte obligatorio y la prohibición de notificar null están en RFC 1123: https://www.rfc-editor.org/rfc/rfc1123.html

Los parámetros DSN y NOTIFY=NEVER están en RFC 3461: https://www.rfc-editor.org/rfc/rfc3461.html

El formato estructurado y límites de seguridad están en RFC 3464: https://www.rfc-editor.org/rfc/rfc3464.html

Las reglas de auto-response están en RFC 3834: https://www.rfc-editor.org/rfc/rfc3834.html

El handoff actual y la escalada local están en RFC 5321: https://www.rfc-editor.org/rfc/rfc5321.html

El uso legítimo en submission está en RFC 6409: https://www.rfc-editor.org/rfc/rfc6409.html

La identidad SPF basada en HELO está en RFC 7208: https://www.rfc-editor.org/rfc/rfc7208.html

Los RFC prueban obligaciones, no autenticidad de un DSN ni práctica universal. Null no prueba legitimidad o abuso. No se afirman tasas actuales de bounce, rechazo, spam o despliegue.