Resumen

  • RFC 3461 permitió solicitar avisos de éxito, fallo o demora por destinatario y conservar un identificador de transacción y otro del destinatario original a través de los relevos. RFC 3464 estructuró el informe para personas y máquinas.
  • La especificación separó entrega de lectura, acción de causa y relevo de resultado final. También reconoció que una DSN podía perderse, falsificarse o detenerse ante una frontera de privacidad.

El rebote antiguo era una carta de explicación enviada por la propia infraestructura. Cada producto elegía su redacción, adjuntaba una porción distinta del mensaje y exponía diagnósticos locales con formatos incompatibles. Quien enviaba un solo correo quizá entendiera el aviso. Una lista con miles de destinatarios necesitaba saber a qué transacción, dirección y punto del trayecto pertenecía cada respuesta; el texto libre rara vez bastaba.

La aceptación SMTP agravaba el problema. Al responder positivamente a RCPT, el servidor asumía normalmente la responsabilidad de entregar o de avisar más tarde del fracaso. Sin embargo, esa obligación básica no distinguía si el remitente deseaba noticias del éxito, del fallo o de una espera extraordinaria. Tampoco mantenía por sí sola el vínculo con la dirección original después de un reenvío.

Las RFC 3461, 3463 y 3464, publicadas en enero de 2003, repartieron esas funciones. Una definió la petición en el sobre SMTP; otra, el formato del informe; la tercera, una taxonomía de estados independiente del transporte. El avance no consistía en prometer que el mensaje llegaría, sino en hacer explícita la autoridad de cada actor y el alcance de su observación.

La petición viajaba en cuatro parámetros

El servidor anuncia DSN en EHLO. No hay verbos nuevos: MAIL incorpora RET y ENVID; RCPT, NOTIFY y ORCPT.

NOTIFY se configura por destinatario. Puede combinar SUCCESS, FAILURE y DELAY, mientras NEVER debe ir solo. Si falta, el servidor puede comportarse como el SMTP tradicional y avisar del fracaso, con o sin demoras. El remitente expresa qué noticias acepta recibir; no dicta lo que ocurrirá.

La demora mantiene ese reparto. NOTIFY=DELAY no fija un cronómetro: el MTA decide cuándo la espera es inusual y, en ese instante, aún desconoce el desenlace. Una condición 4.x.x puede acompañar primero a delayed, cuando siguen los intentos, y después a failed, cuando la cola abandona.

RET elige cuánto material vuelve con un informe de fallo. FULL pide el mensaje completo; HDRS, solo las cabeceras. Cuando no se informa de un destinatario fallido, deberían regresar únicamente las cabeceras. Diagnóstico y confidencialidad compiten: devolver el cuerpo crea otra copia que puede recorrer y permanecer en sistemas diferentes.

Dos identidades sobrevivían a rutas cambiantes

ENVID identifica la transacción del sobre. Si se conserva, reaparece como Original-Envelope-Id. El sistema postal no asigna significado al valor; lo interpreta quien lo creó. Por eso no equivale al Message-Id de la cabecera. Este identifica contenido, mientras aquel distingue una entrega concreta. Un mismo contenido puede enviarse varias veces y una sola transacción puede incluir destinatarios con resultados diferentes.

ORCPT guarda la dirección que indicó originalmente el remitente. En la primera entrega debe coincidir con RCPT TO; durante el reenvío, la dirección operativa puede cambiar y la original continuar. La primera cuenta hacia dónde va el siguiente intento. La segunda permite reconocer para cuál de los destinatarios iniciales se emite la evidencia.

Ambas piezas posibilitan la conciliación automática sin mezclarlas con autenticación. Un token ENVID no demuestra quién generó el informe. ORCPT no prueba quién controla una dirección. Son referencias que solo funcionan si los relevos las preservan y si el receptor trata la DSN con la misma cautela que cualquier correo.

El verbo operativo y el diagnóstico ocupaban campos distintos

RFC 3464 construyó la DSN como multipart/report. Primero aparece una explicación legible; después, un bloque message/delivery-status con datos generales y grupos por destinatario; al final puede adjuntarse el mensaje original o sus cabeceras.

Cada destinatario recibe una Action: failed, delayed, delivered, relayed o expanded. En paralelo, el Status de RFC 3463 usa tres componentes: 2.x.x para éxito, 4.x.x para fallo transitorio persistente y 5.x.x para fallo permanente, con categorías de objeto y detalle.

No son campos redundantes. Un tiempo de espera de DNS puede mantener el mismo estado 4.x.x cuando la cola todavía reintenta y cuando, días después, decide abandonar. La Action cambia de delayed a failed: el estado describe la condición; la acción, la decisión.

failed es terminal. delayed no lo es. delivered termina la responsabilidad para ese destinatario, pero puede significar entrega a un distribuidor de listas y nunca acredita lectura. expanded registra que un alias de múltiples destinatarios aceptó y generó nuevas rutas, por lo que todavía pueden llegar informes posteriores.

relayed marca una frontera de conocimiento. El mensaje entró en un entorno que no asume la responsabilidad de informar del éxito final. El MTA acredita su relevo, no el buzón de destino. Nombrar esa discontinuidad ofrece más verdad que convertir el traspaso en una entrega imaginaria.

El informe de un fallo no debía crear otro informe

Una DSN también es correo y puede no llegar. Permitir que su fallo generase otra DSN abriría un bucle de avisos sobre avisos. Por ello, cuando viaja por SMTP utiliza la ruta inversa nula MAIL FROM:<>. La pérdida del informe no produce una nueva notificación en la red.

La decisión cede visibilidad para conservar estabilidad. El remitente quizá nunca descubra que desapareció la respuesta. Esa incógnita limitada evita una retroalimentación sin fin.

Los saltos heterogéneos introducen otra incógnita. Entre servidores compatibles deben propagarse petición e identificadores. Al entrar en otro sistema de mensajería, la pasarela solo puede traducir con el mejor esfuerzo. Además, un reenvío confidencial puede ocultar el destino, suprimir campos remotos o cortar notificaciones positivas. La trazabilidad completa no siempre es compatible con la privacidad del receptor.

La sintaxis común no certificaba la verdad

RFC 3464 advierte que las DSN pueden falsificarse tan fácilmente como el correo ordinario. Un éxito inventado puede cerrar una incidencia; un fallo falso puede provocar reintentos, expulsar una dirección de una lista o activar una decisión de atención. ENVID mejora la correlación, pero no es una firma.

También existe riesgo en lo devuelto. RET=FULL replica todo el contenido por una ruta nueva y en archivos nuevos. Las cabeceras por sí solas ya revelan interlocutores, asunto y tránsito. La elección del remitente no controla cómo cada intermediario guarda la copia.

El legado de DSN es una gramática de autoridad limitada. El remitente pide y asigna referencias. Los MTA aceptan, reintentan, abandonan y describen únicamente sus acciones. La pasarela traduce hasta donde puede. La política de confidencialidad puede terminar la observación. La lectura humana queda fuera de SMTP.

IANA mantiene DSN en su registro de extensiones SMTP con referencia a RFC 3461. Su valor duradero reside en poder decir qué transacción, qué destinatario original, qué sistema informante, qué acción y qué condición están en juego, sin inflar esa información hasta convertirla en una promesa de bandeja de entrada o atención humana.

Fuentes