Resumen

  • RFC 821 permitía que el remitente antepusiera al buzón una secuencia explícita de relés; cada uno consumía su nombre y lo incorporaba a la ruta inversa.
  • RFC 1123 eligió nombres de dominio universales y DNS MX para el correo ordinario. El receptor seguía obligado a aceptar la sintaxis antigua, aunque podía descartar los saltos y usar el dominio final.
  • SMTP actual separa compatibilidad, autorización y ejecución: un servidor puede ignorar la ruta, rechazar el relevo o seguirla de manera deliberada y limitada.

El mismo destinatario ya no impone el mismo recorrido

Un cliente envía esta orden:

RCPT TO:<[relé alpha, relé beta]:[buzón user del dominio gamma]>

El buzón del usuario en el dominio gamma es el destino absoluto. La parte anterior a los dos puntos propone pasar por alpha y beta. La gramática permite distinguir ambas piezas; no decide por sí sola qué poder conserva cada una.

Un servidor puede eliminar la lista y buscar directamente gamma.example. Otro puede negarse a actuar como relé. Un tercero, habilitado para una prueba excepcional, puede contactar primero con alpha.example. Los tres interpretan bien la cadena. Lo que difiere es la política que convierte —o no— el texto en un siguiente salto.

La supervivencia de esta forma demuestra que la retrocompatibilidad puede ser asimétrica. El receptor promete comprender el pasado, no devolverle automáticamente el control de la red.

Cuando la ruta viajaba dentro del sobre

RFC 822 definía route-addr: una ruta opcional delante de la dirección absoluta. El originador podía indicar los hosts o servicios de transmisión que deseaba atravesar, sin confundirlos con el buzón final.

RFC 821 convirtió esa distinción en un algoritmo SMTP. Su ejemplo situaba los relés ONE y TWO antes del buzón de JOE en el dominio THREE: el buzón era la dirección y ONE, TWO el itinerario. Cuando el mensaje llegaba al relé correspondiente, este retiraba su identificador del forward-path, lo añadía al principio del reverse-path, asumía el papel de emisor y conectaba con el siguiente host.

La lista pendiente se acortaba y el camino de retorno crecía. Así se vinculaban el avance de la entrega y el lugar al que debía dirigirse un error posterior. Pero cada servidor conservaba la facultad de aceptar o rechazar la tarea de relevo. La ruta nunca fue una credencial para usar cualquier máquina.

El estándar también decía que esos caminos pertenecían al sobre SMTP. No tenían que aparecer en To, From o CC. La identidad visible del mensaje y la secuencia operativa podían evolucionar por separado.

El nombre duradero sustituyó a las instrucciones en serie

RFC 1123 pidió en 1989 que los emisores dejaran de generar la forma explícita de source route. La explicación no fue meramente práctica: Internet había elegido nombres universales en vez de source routing. SMTP ofrecía conectividad, DNS nombres globales independientes de ubicación y MX resolvía el caso principal que antes justificaba una secuencia escrita por el remitente.

Los mensajes siguieron pasando por relés. Cambió quién elegía. El emisor aportaba el dominio de destino; DNS describía los intercambiadores disponibles y cada servidor aplicaba su autorización y estado actuales. Si cambiaba la topología, el propietario del dominio podía actualizar DNS sin pedir a todos los corresponsales que reescribieran una lista.

El buzón se convirtió en un identificador más estable que el camino. Esa es una diferencia de gobierno, no solo una abreviación de la dirección.

La sintaxis se aceptaba y la orden se descartaba

RFC 1123 no declaró inválida la forma heredada. El receptor debía aceptarla. Si no implementaba el relevo histórico, debía intentar la entrega hacia el dominio terminal del buzón. En el ejemplo normativo se retiran los relés ALPHA y BETA y el buzón de JOE se dirige directamente al dominio GAMMA.

RFC 2821 hizo explícito el desacoplamiento. Los sistemas receptores deben reconocer la ruta, pero deberían quitarla y utilizar el dominio del buzón como si nunca se hubiera incluido. Los nombres de los relés tampoco deben copiarse al reverse-path. Ver la puntuación antigua ya no autoriza a reconstruir su contabilidad de retorno.

Negarse a analizar la forma puede romper clientes antiguos o confundir delimitadores con datos del buzón. Ejecutarla automáticamente puede permitir que un token heredado elija un intermediario fuera de la política actual. Comprender preserva el intercambio; no obedecer preserva la frontera de confianza.

Una excepción reglada, no un poder implícito

RFC 5321 mantiene A-d-l en la gramática normativa. La nota asociada reúne tres obligaciones distintas: la forma debe aceptarse, no debería generarse y debería ignorarse.

El servidor puede rechazar la dirección o negarse a proporcionar relevo. Puede suprimir la lista y dirigirse al destino final. Si decide usarla, debe enviar primero al primer dominio indicado y no inventar atajos. La ejecución excepcional sigue teniendo semántica exacta; no es una interpretación libre de un fósil.

También existe una trampa de migración. Algunos remitentes colocaban al final un nombre no válido en DNS y confiaban en que un intermediario lo resolviera. Al eliminar la ruta, un servidor conforme deja expuesta esa dependencia. La cadena todavía puede pasar el parser y, aun así, fracasar porque el modelo que la hacía útil ya no es vigente.

El estándar conserva usos poco comunes para diagnóstico o fallos graves de configuración. Esos casos requieren una decisión del operador. No devuelven a todos los clientes la facultad ordinaria de diseñar la ruta.

El encabezado conserva otra huella

RFC 5322 incluye la ruta en la gramática obsoleta de direcciones de encabezado y recomienda ignorarla al interpretar. Un lector puede así abrir correo histórico sin convertir una forma archivada en una orden SMTP viva.

Conviene mantener la separación: aceptar un viejo route-addr en To no dice a qué destinatarios se envió el sobre ni qué relés se usaron. La prueba del recorrido está en la transacción y sus trazas, no en la apariencia de un campo redactado.

Fuentes y límites

RFC 821, RFC 822, RFC 1123, RFC 2821, RFC 5321 y RFC 5322 describen la sintaxis y el cambio normativo. No miden cuántos servidores la reciben hoy, qué productos la ejecutan ni cuál es su tasa de entrega.

La conclusión histórica es más precisa: SMTP conservó una lengua antigua para no leerla mal, mientras retiraba de esa lengua la autoridad automática para escoger el trayecto.