Cancelar suscripción con un clic conecta dos sistemas: el mensaje que anuncia la acción y el servicio que la procesa. Un encabezado que luzca correcto es sólo la mitad de la implementación. El punto final debe identificar la suscripción prevista, aceptar la solicitud especificada sin iniciar sesión y hacer efectiva la exclusión voluntaria.
Construir el mensaje antes de firmarlo.
RFC 8058 exige un campo List-Unsubscribe que contenga un URI HTTPS y un campo List-Unsubscribe-Post que contenga List-Unsubscribe =One-Click. Un válido firma DKIM debe cubrir ambos campos. Otros URI para cancelar suscripción que no sean HTTP/S, como mailto, también pueden aparecer en List-Unsubscribe . RFC 8058 secciones 3 y 4.
Un par de encabezados ilustrativo mínimo es:
List-Unsubscribe: <https://unsubscribe.example.test/u/opaque-token>
List-Unsubscribe-Post : List-Unsubscribe = Un clic
El nombre de host reservado y el token son marcadores de posición de enseñanza, no un punto final operativo. Agregue estos campos antes del último paso de firma relevante. Inspeccione el mensaje emitido para asegurarse de que la lista h= de la firma los incluya y que la verificación criptográfica se realice correctamente después de todas las transformaciones.
Hacer que el URI identifique la acción exacta
El URI debe contener suficiente información para identificar al destinatario y la lista. El receptor no puede proporcionar un campo de destinatario adicional ni responder un cuestionario de preferencias. Utilice un componente opaco y difícil de falsificar y valídelo en el punto final. Evite exponer direcciones innecesariamente en URL, registros o análisis.
Trate el token como una autoridad para realizar una cancelación de suscripción de alcance limitado, no como una credencial de cuenta general. Alguien que tenga acceso al mensaje podrá utilizarlo. No permita que cambie la propiedad de la cuenta, inicie sesión como usuario ni modifique suscripciones no relacionadas. Elija deliberadamente el comportamiento de retención y caducidad para que los mensajes antiguos no se conviertan en rutas de exclusión inútiles sin una política considerada.
Procesar el POST especificado directamente
El receptor envía un HTTPS POST con el par clave/valor anunciado en su cuerpo. RFC 8058 permite application/x-www-form-urlencoded y recomienda multipart/form-data. La solicitud no debe depender de cookies, autorización HTTP o contexto previo del navegador. El remitente no debe devolver una redirección HTTPS. El receptor debe obtener el consentimiento del usuario antes de realizar la acción.
Un enlace de cuerpo aún puede ofrecer una página de preferencias legible por humanos, pero la acción POST debe completarse sin más interacción. Como medida de protección de implementación, mantenga las solicitudes GET no destructivas para que la recuperación automática de enlaces no elimine a un suscriptor. Esa salvaguarda es una recomendación de diseño operativo motivada por el problema que aborda el RFC.
Verifique el estado de la aplicación, no solo un código de estado
Supongamos que un punto final hipotético arroja éxito para un token de boletín válido, pero la siguiente exportación de campaña aún incluye el mismo par de destinatario/lista. Es posible que la solicitud de protocolo haya llegado al servicio, pero no se establece la supresión operativa. Inspeccione la decisión duradera, el reconocimiento de propagación y la entrada de selección de audiencia en lugar de tratar el código de estado como una finalización.
Para una prueba autorizada, defina primero los resultados esperados: un GET y un token no válido no deberían eliminar las suscripciones; un POST válido debería afectar sólo al par previsto; repetirlo debería preservar ese mismo estado final. Estas son expectativas de diseño, no pruebas locales o de producción ejecutadas.
Para la implementación, verifique por separado la validez del certificado TLS , el nombre de host, la accesibilidad pública, ambas codificaciones de formulario admitidas, el comportamiento del proxy y los límites de velocidad. Compruebe que la respuesta no redirija a un servicio de inicio de sesión o de seguimiento. Asegúrese de que la siguiente selección de campaña respete la supresión, incluidos los cachés o las exportaciones de terceros.
Opere el punto final como un servicio duradero
Haga seguras las solicitudes válidas repetidas, registre un evento de auditoría mínimo y supervise las fallas sin exponer tokens. Alerta sobre errores de procesamiento y retrasos en la supresión. Una respuesta que pretende ser exitosa antes de una actualización duradera necesita un diseño de procesamiento confiable y un tiempo de finalización limitado.
Cierre la implementación con verificación de mensajes, pruebas de puntos finales y una exclusión observada del próximo envío para un destinatario controlado. Ninguno de estos prueba por sí solo que cada interfaz de buzón mostrará un botón para cancelar la suscripción.
Elija la reparación del punto de control fallido
Un requisito de redireccionamiento o inicio de sesión exige la reparación del endpoint. Una asignación incorrecta de destinatario/lista requiere reparación del alcance de la autorización. Un punto final correcto con una exportación de campaña obsoleta requiere reparación de propagación. No cierre los tres porque una POST arrojó éxito.