Resumen

  • Una ruta fuente SMTP era estado mutable del sobre: cada relevo consumía su primer elemento del forward-path y lo incorporaba al reverse-path.
  • La ruta no era el buzón absoluto, y los caminos del sobre no eran los campos To: y From: del mensaje. Tampoco autenticaban al autor ni certificaban los saltos recorridos.
  • MX y los dominios globalmente interpretables trasladaron la elección cotidiana de ruta al MTA, DNS y la política local. Comprender la forma antigua no obligaba a concederle tránsito.

El relevo que se borró sin desaparecer

La mecánica se ve mejor dentro de una transacción. Después de que el remitente SMTP presente un reverse-path con MAIL FROM, envía:

RCPT TO:<@ONE,@TWO:JOE@THREE>

RFC 821 llama forward-path al argumento de RCPT. El buzón absoluto es JOE@THREE. La parte @ONE,@TWO es la source route, una indicación de cómo llegar. La especificación advierte que el buzón y la ruta son conceptos distintos, aunque aparezcan en una sola forma delimitada por dos puntos.

ONE ve su identidad como primer elemento y la elimina del forward-path. El próximo estado de ida es @TWO:JOE@THREE. A la vez, ONE antepone su identificador al reverse-path. Lo que era una orden para una entrega todavía no ejecutada se convierte en una pieza del camino por el que podría regresar un aviso de imposibilidad.

La ruta, por tanto, se consumía. El relevo no era un lector pasivo de una dirección; ejecutaba una transición con dos salidas coordinadas. El itinerario restante se acortaba mientras el rastro funcional de responsabilidad aceptada crecía en sentido inverso.

El sobre no era la carta

MAIL FROM no designa necesariamente al autor que el lector ve en From:. Su reverse-path pertenece al transporte y a la gestión de errores. No equivale a Reply-To:, no autentica una identidad y no prueba quién redactó el cuerpo.

RCPT TO tampoco es una copia obligatoria de To: o Cc:. Un mismo contenido puede viajar a varios destinatarios de sobre; una copia oculta puede no aparecer en la cabecera; una dirección escrita en el mensaje puede no participar en esa transacción.

RFC 822 separa en route-addr la ruta y el addr-spec, y desaconseja el enrutamiento fuente salvo necesidad especial. Esa evidencia muestra que las direcciones históricas podían exponer una ruta, pero no autoriza a fundir formato de mensaje y comandos SMTP.

Si un archivo conserva solo el mensaje entregado, quizá haya perdido la ruta explícita recibida. Si conserva solo el reverse-path, tampoco posee prueba de autoría. Para investigar hay que retener la capa, el momento y la transformación de cada valor.

Un mismo sistema podía llamarse de otra forma al salir

Al añadirse al reverse-path, ONE debía usar el nombre por el que se lo conocía en el entorno al que enviaba, no repetir sin más el nombre del entorno de entrada. La regla de RFC 821 anticipaba pasarelas entre espacios de nombres y comunidades de correo distintas.

Así, el itinerario escrito por el emisor no era una lista universal autosuficiente. Cada frontera podía necesitar una representación local del mismo relevo. La aparente precisión de la cadena dependía de contextos que el propio texto no contenía por completo.

Si el servidor receptor no coincide con el primer elemento, tampoco puede consumirlo arbitrariamente. Puede usarlo para seleccionar el próximo SMTP y, según el proceso histórico, incorporar su propio identificador al reverse-path. El acto de borrar exige coincidencia entre posición e identidad.

Nada de esto convierte los nombres en testimonios criptográficos. Una ruta no demuestra control de dominio, paso real por cada máquina ni honestidad del sistema que la escribió. Era una instrucción interoperable, no un registro inmutable de procedencia.

MX retiró el mapa de la dirección

RFC 974 hizo que un dominio de destino pudiera anunciar intercambiadores de correo con preferencias. El SMTP emisor consulta el dominio y prueba candidatos conforme a reglas, disponibilidad y política. El usuario puede conservar user@domain mientras el dominio cambia los servidores que lo reciben.

No se trasladó @ONE,@TWO a una zona DNS. Un conjunto MX no es una serie de relevos que deban recorrerse en orden. RFC 974 advierte incluso contra perseguir de manera recursiva los MX de un MX para fabricar rutas complejas.

La nueva separación es de autoridad. El usuario nombra el destino; el MTA decide el próximo salto con información vigente. Una libreta de direcciones ya no necesita copiar una fotografía topológica que se volverá obsoleta. El dominio puede modificar su punto de entrada sin cambiar la identidad de cada buzón.

La diferencia también afecta a los fallos. Una ruta fuente rota queda replicada en mensajes, alias y colas. Un cambio de MX puede corregirse en el lugar responsable del dominio y ser observado por nuevos envíos. La ruta pasa de ser contenido permanente de la dirección a ser resultado temporal de una decisión.

La retirada empezó por dejar de fabricar

RFC 1123 dice que un Sender-SMTP no debería enviar en RCPT una ruta explícita @...:. La decisión arquitectónica favorecía nombres universales: user@domain, un dominio significativo globalmente y MX debían cubrir la necesidad principal.

Sin embargo, el Receiver-SMTP todavía debía aceptar la sintaxis. Aceptar la forma no significa aceptar la tarea de retransmitir para cualquier tercero. Si el servidor no implementaba el recorrido solicitado, podía, bajo las condiciones indicadas, intentar entrega directa al dominio situado a la derecha del último @.

Esta asimetría permite jubilar un protocolo sin romper todo lo que ya está instalado. Los clientes nuevos dejan de crear rutas; los servidores siguen pudiendo leer las que quedaron en directorios, gateways y colas. La capacidad de interpretar sobrevive a la autoridad de ordenar.

Si se suprimieran ambas en el mismo instante, los datos antiguos se volverían errores de sintaxis. Si se conservara toda la fuerza de la instrucción, la retirada nunca terminaría. La compatibilidad ocupa el espacio intermedio: comprender, decidir y registrar sin obedecer automáticamente.

Reconocer la gramática no abre el relevo

El tratamiento antiabuso exige separar el parser de la autorización. Un servidor puede reconocer la ruta, extraer el buzón final y aun así negar el tránsito según la identidad del cliente, el dominio de origen, el destino o la red de conexión.

RFC 2821 declara deprecated las source routes. Los servidores deben estar preparados para recibir la sintaxis, normalmente deberían ignorar la ruta y pueden rechazar el relay. Los clientes no deberían generarla.

Cuando se ignora el recorrido, los nombres intermedios no deben copiarse al reverse-path. La transferencia de RFC 821 pertenece al modo que usa realmente la ruta. Presentarla como una operación de todo SMTP actual confundiría una compatibilidad reconocida con el comportamiento ordinario.

Si un servidor elige usarla en un caso excepcional, debe encaminar al primer dominio indicado y no adivinar atajos. La alternativa explícita es ignorarla o rechazarla; obedecer solo los fragmentos convenientes produciría una semántica imposible de auditar.

Por eso una alerta que diga únicamente “aceptó una source route” es incompleta. ¿Aceptó la sintaxis, el destinatario, la responsabilidad tras DATA o el tránsito a un tercero? Cada aceptación ocurre en un punto diferente.

La topología del usuario tuvo sentido entre islas

RFC 1711, publicado en 1994, describe la source route explícita como la incorporación a la dirección del MTA por el que el usuario quiere pasar. Cuando el mensaje llega, ese MTA se quita a sí mismo y enruta lo restante.

Su contexto histórico son las “islas de correo” conectadas de forma dispersa. Saber qué pasarela alcanzaba una isla remota podía ser información que la infraestructura no distribuía por sí sola. El usuario que poseía ese mapa podía convertirlo en parte de la dirección y hacer posible una entrega.

Con una Internet más interconectada, el conocimiento topológico del usuario se volvió innecesario en el caso ordinario y propenso a quedar viejo. RFC 1711 señala además que los relevos no trataban esas direcciones de manera uniforme.

La observación pertenece a 1994; no es un censo contemporáneo. Tampoco prueba que todos los gateways o usos de diagnóstico desaparecieran. Lo que sí documenta es el cambio de ventaja: una ruta escrita por el usuario pasó de llenar un vacío de conectividad a competir con sistemas dinámicos que conocían mejor el estado presente.

El percent hack, las rutas UUCP con signos de admiración y los mapeos de gateways son adaptaciones cercanas, no sinónimos. Pueden ocultar saltos en el local-part o usar otra gramática. Este artículo se limita a la forma @relay1,@relay2:user@host y a su transición forward/reverse.

La gramática sobrevivió a su razón cotidiana

RFC 5321 explica que MX eliminó la necesidad regular de source routes y que exigir nombres de dominio plenamente cualificados quitó la última justificación general importante. Los clientes no deberían usarlas salvo circunstancias inusuales, como depuración o un problema DNS grave y transitorio.

Los servidores siguen reconociendo la sintaxis obsoleta. Pueden negar el relay, ignorar el recorrido y tratar el destino final, o usarlo dentro de las condiciones estrechas del protocolo. La presencia en la gramática ya no concede normalidad operacional.

Tampoco hay garantía de rescate por borrado. Algunas direcciones antiguas dependían de un nombre comprensible únicamente en un entorno intermedio. Al retirar la ruta, el dominio final puede no ser resoluble globalmente. La compatibilidad no puede inventar la correspondencia de un espacio de nombres perdido.

El estado correcto tiene más de dos valores. Una implementación puede reconocer, conservar, ignorar, rechazar o usar. El dominio final puede resolver o fallar. La responsabilidad puede no haberse aceptado aún o haberse aceptado antes de un fallo posterior. “Soporta source routes” no describe esa matriz.

Una ruta escrita no certifica una ruta recorrida

Una base de datos que contiene @ONE,@TWO demuestra la existencia de esos caracteres en un registro, nada más. Para afirmar que ONE consumió el primer tramo, que TWO fue contactado o que THREE recibió el correo hacen falta la sesión, sus respuestas, la resolución de próximo salto y la cola.

El problema inverso aparece después de normalizar. Ver solo JOE@THREE no demuestra que ese fuera el argumento original. Un MTA de borde pudo eliminar la ruta o un recolector pudo conservar únicamente el buzón interpretado. Los campos del mensaje pueden no haber contenido nunca la ruta.

Un registro útil mantiene el valor bruto, el resultado del parseo, la decisión use/ignore/reject, la identidad de los extremos, el tiempo y el resultado. La forma normalizada puede coexistir como proyección; no debe reemplazar la evidencia recibida.

El reverse-path acumulado sigue siendo un instrumento de manejo de errores, no una firma de trayecto. No autentica cada nombre ni garantiza un salto único y honesto. La inferencia debe terminar donde termina la función especificada.

Qué cierran las fuentes

RFC 821, RFC 822, RFC 974, RFC 1123, RFC 1711, RFC 2821 y RFC 5321 sostienen la gramática, las reglas y la transición histórica. No miden prevalencia actual, implementación universal, incidentes, tasa de éxito ni exposición de relay.

Tampoco convierten la source route SMTP en source routing IP. LSRR y SSRR operan sobre datagramas y routers; aquí el objeto es el sobre de correo y los MTA. Un parecido verbal no transfiere hechos ni riesgos.