Resumen

Una carta electrónica, varias identidades

La dirección que ve quien abre un mensaje no tiene por qué coincidir con la identidad usada por los servidores al transmitirlo. Esa diferencia se agranda con los reenvíos. Una política publicada en DNS puede indicar qué máquinas están autorizadas a enviar correo por un dominio, pero el servidor receptor debe decidir primero qué dominio está comprobando.

La carta de trabajo de MARID puso ese problema al principio. Enumeró From y Sender en las cabeceras, MAIL FROM en SMTP y EHLO como identidades posibles, y encargó al grupo escoger una. Sender ID empleaba, entre otras piezas, el algoritmo PRA para localizar una supuesta dirección responsable en las cabeceras. SPF miraba la identidad del intercambio SMTP. Compartían el DNS como escaparate de políticas, pero no necesariamente el objeto de la autorización.

Esa diferencia cambió el riesgo para una persona que esperaba un mensaje. Si dos receptores leían la misma declaración con reglas distintas, uno podía aceptar el correo y el otro descartarlo. La controversia de estándares salía de la sala de reuniones y entraba en la bandeja de entrada.

El peaje no era una regalía

En su carta abierta a MARID, Apache dijo que el acuerdo de patente de Microsoft entonces vigente era incompatible con la licencia Apache 2.0 y que sus proyectos no implementarían ni desplegarían Sender ID bajo esos términos. Expuso dos trabas especialmente reveladoras: los derechos no pasaban con facilidad a los destinatarios posteriores mediante sublicencia y, según Apache, quien quisiera cambiar el nombre o redistribuir el software debía contactar con Microsoft.

En el software libre, la distribución posterior no es un caso marginal. Los paquetes cambian de mantenedor, se adaptan y viajan a través de terceros. Un acuerdo que obliga a cada actor a tratar por separado con el dueño de la patente deja a ese dueño una puerta dentro de la cadena de difusión, aunque no cobre por abrirla. Apache ejerció su autoridad sobre sus propios proyectos; su carta no prohibió a otros escribir código Sender ID.

La distinción importa porque el desenlace de Sender ID tuvo más de un escenario. Apache discutía las condiciones de implementación. El IETF aún tenía que documentar dos propuestas con diferencias técnicas sin presentar una paz que no existía.

Publicar dos RFC no reparó la discrepancia

En abril de 2006, el IETF publicó simultáneamente SPF y Sender ID como RFC experimentales. La nota del IESG reconoció que faltaba consenso técnico general y que habían fracasado los intentos de conciliación. Advirtió que Sender ID podía aplicar su heurística a registros DNS creados para SPF y provocar la pérdida de mensajes legítimos. También señaló el efecto de ciertas cabeceras Resent-* y los reenviadores automáticos.

El sello «Experimental» era una descripción honesta del estado del acuerdo. Dejaba documentos para probar, junto con el fallo que había que vigilar. El hecho de que un texto estuviera publicado no confería a los operadores una interpretación única de todos los registros existentes.

El balance del IETF en 2012 constató que SPF tenía despliegue amplio, mientras PRA y SUBMITTER, piezas de Sender ID, reunían poco uso. Encontró implementaciones de ambos enfoques y concluyó que la falta de software disponible no había decidido la elección. Ese balance observó adopción; no otorgó un premio a la corrección matemática de uno frente al otro. SPF pasó a la vía de estandarización en 2014 y el IETF declaró históricas las tres RFC de Sender ID en 2020.

Apache había cerrado una puerta concreta en 2004. La adopción del correo cerró otra, mucho más amplia, durante los años siguientes. Entre ambas quedó la advertencia del IESG: si un registro puede significar cosas distintas según el receptor, el coste de la ambigüedad lo paga el mensaje que no llega.