Resumen

  • RFC 2369, de julio de 1998, permitió anunciar la salida de una lista en una cabecera de correo. Si visitar la URL completaba la baja, el servidor no podía distinguir la inspección automática de la voluntad del lector.
  • RFC 8058, de enero de 2017, añadió List-Unsubscribe-Post: List-Unsubscribe=One-Click. Una firma DKIM válida debe cubrir las dos cabeceras de baja; el receptor necesita consentimiento antes de enviar el HTTPS POST.
  • El POST lleva únicamente el par clave-valor fijado por la norma, sin cookies ni autorización HTTP. El servidor no debe redirigirlo por HTTPS. La cabecera nueva consta en el registro de IANA.

Una visita tomada por una decisión

El primer arreglo era útil. RFC 2369 dio a las listas un lugar visible para anunciar cómo salir. Una aplicación de correo podía leer List-Unsubscribe y ofrecer una acción sin mandar al usuario a buscar un enlace en el pie de cada mensaje. La cabecera podía contener una URL HTTPS. Hacía visible la puerta, pero no acreditaba la identidad de quien la abría.

También la abrían los programas de seguridad. RFC 8058 describe filtros antispam que recuperan de manera automática recursos indicados en las cabeceras, sin intervención del destinatario. Si la lista eliminaba al abonado con la mera visita, la exploración del enlace se convertía en una baja. Desde el servidor, aquella solicitud no revelaba mecánicamente si provenía de una persona o de un proceso en segundo plano. El software destinado a proteger el buzón podía borrar al lector de la lista.

Los operadores interpusieron páginas de confirmación. Un escáner podía abrir la página sin pulsar el siguiente botón; una persona sí podía terminar. Se evitaba la baja accidental, a costa de añadir otro paso a la baja voluntaria. El problema no era el tamaño del botón. Se había pedido a una dirección publicada para ser consultada que funcionara también como autorización para cambiar un registro.

La cabecera de 2017 indicó qué verbo usar

RFC 8058 conservó el mecanismo anterior y añadió una señal para la operación con un solo gesto. El remitente debe poner una URI HTTPS en List-Unsubscribe y el valor exacto List-Unsubscribe=One-Click en List-Unsubscribe-Post. Tras obtener el consentimiento, la aplicación receptora envía a esa URI un HTTPS POST cuyo cuerpo contiene ese par. Recuperar una página para examinarla y enviar un POST para modificar la suscripción son operaciones distintas incluso para el protocolo.

El remitente también debe aplicar una firma DKIM válida que cubra ambas cabeceras e incluya sus nombres en el campo h=. Así, la dirección de salida y la declaración de que admite la operación viajan como parte verificable del mismo mensaje. Si falta esa firma, el receptor no debería ofrecer la baja con un solo gesto. La firma acredita la declaración del remitente, no la voluntad del usuario.

La voluntad tiene su propia regla. La aplicación receptora no debe enviar el POST sin consentimiento. RFC 8058 deja a la aplicación la forma concreta de pedirlo. El remitente publica y firma la oferta; el programa muestra la opción y hace la solicitud; el lector decide. Un escáner que visita la URL no cumple esos tres papeles por accidente.

El servidor tiene que resolverlo donde prometió

El cuerpo del POST contiene solo el par señalado en la cabecera. No incluye cookies, autorización HTTP ni información adicional. Por ello, la URI debe identificar suficientemente al destinatario y la lista de la que saldrá. El RFC aconseja un identificador opaco y difícil de adivinar. Un servidor que dependa de la sesión de un navegador para saber qué cuenta borrar no podrá atender la petición prevista.

Tampoco puede responder al POST con una redirección HTTPS. El texto recuerda que los POST redirigidos han fallado históricamente y que algunos navegadores los han convertido en GET. Si la acción decisiva ocurre al final de una cadena de saltos, el verbo cuidadosamente elegido puede perderse por el camino. El servidor debe completar la baja en la dirección que anunció.

El RFC no modifica los demás usos de las URL de baja descritos en RFC 2369. Señala un itinerario específico para la baja en un gesto. IANA registra List-Unsubscribe-Post, pero un nombre registrado no realiza la operación: hacen falta la firma, el consentimiento, el POST y un servidor capaz de tramitarlo.

La salida es una cadena, no un enlace

El operador de la lista controla la oferta firmada y su servidor. La aplicación de correo controla la presentación y el momento de la petición. El lector controla la decisión. La inspección automática sigue siendo inspección. Ese reparto, escrito en pocas líneas de una cabecera, era la reparación histórica. Cuando un eslabón falta, la salida puede convertirse en una máquina de bajas indebidas o en un botón que no termina nada.

Los documentos oficiales usados aquí prueban el diseño y el registro de la cabecera. Para medir su uso en un servicio concreto harían falta mensajes originales fechados, manuales de los receptores y registros de los servidores. La conclusión histórica ya es precisa: la Web facilitó que el software abriera enlaces; el correo tuvo que especificar cuál de esas aperturas era una orden.