Cancelar inscrição com um clique conecta dois sistemas: a mensagem que anuncia a ação e o serviço que a processa. Um cabeçalho com aparência correta é apenas metade da implementação. O endpoint deve identificar a assinatura pretendida, aceitar a solicitação especificada sem login e efetivar a desativação.
Construa a mensagem antes de assiná-la
RFC 8058 exige um campo List-Unsubscribe contendo um URI HTTPS e um campo List-Unsubscribe-Post contendo List-Unsubscribe =One-Click. Um válido Assinatura DKIM deve abranger ambos os campos. Outros URIs de cancelamento de assinatura não HTTP/S, como mailto, também podem aparecer em List-Unsubscribe . RFC 8058 seções 3 e 4.
Um par de cabeçalhos ilustrativo mínimo é:
List-Unsubscribe: <https://unsubscribe.example.test/u/opaque-token>
List-Unsubscribe-Post : List-Unsubscribe = Um clique
O nome do host e o token reservados são espaços reservados para ensino, não um terminal operacional. Adicione esses campos antes da etapa final de assinatura relevante. Inspecione a mensagem emitida para garantir que a lista h= da assinatura a inclua e que a verificação criptográfica seja bem-sucedida após todas as transformações.
Faça o URI identificar a ação exata
O URI deve conter informações suficientes para identificar o destinatário e a lista. O destinatário não pode fornecer um campo extra de destinatário ou responder a um questionário de preferências. Use um componente opaco e difícil de forjar e valide-o no endpoint. Evite expor endereços desnecessariamente em URLs, logs ou análises.
Trate o token como autoridade para realizar um cancelamento de assinatura com escopo restrito, não como uma credencial geral de conta. Alguém com acesso à mensagem poderá usá-la. Não permita que ele altere a propriedade da conta, faça login como usuário ou altere assinaturas não relacionadas. Escolha deliberadamente o comportamento de retenção e expiração para que mensagens antigas não se tornem caminhos inúteis de exclusão sem uma política considerada.
Processe o POST especificado diretamente
O receptor envia um HTTPS POST com o par chave/valor anunciado em seu corpo. RFC 8058 permite application/x-www-form-urlencoded e recomenda multipart/form-data. A solicitação não deve depender de cookies, autorização HTTP ou contexto anterior do navegador. O remetente não deve retornar um redirecionamento HTTPS. O receptor deve obter o consentimento do usuário antes de executar a ação.
Um link corporal ainda pode oferecer uma página de preferências legível por humanos, mas a ação POST deve ser concluída sem interação adicional. Como salvaguarda da implementação, mantenha as solicitações GET não destrutivas para que a busca automática de links não remova um assinante. Essa salvaguarda é uma recomendação de desenho operacional motivada pelo problema que a RFC aborda.
Verifique o estado do aplicativo, não apenas um código de status
Suponha que um endpoint hipotético retorne sucesso para um token de boletim informativo válido, mas a próxima exportação de campanha ainda inclua o mesmo par destinatário/lista. A solicitação de protocolo pode ter chegado ao serviço, mas a supressão operacional não foi estabelecida. Inspecione a decisão durável, o reconhecimento de propagação e a entrada de seleção de público, em vez de tratar o código de status como conclusão.
Para um teste autorizado, defina primeiro os resultados esperados: um GET e um token inválido não devem remover assinaturas; um POST válido deve afetar apenas o par pretendido; repeti-lo deve preservar o mesmo estado final. Estas são expectativas de design, não testes locais ou de produção executados.
Para implantação, verifique separadamente a validade do certificado TLS , o nome do host, a acessibilidade pública, ambas as codificações de formulário suportadas, o comportamento do proxy e os limites de taxa. Verifique se a resposta não redireciona para um serviço de login ou rastreamento. Certifique-se de que a próxima seleção de campanha respeite a supressão, incluindo quaisquer caches ou exportações de terceiros.
Opere o endpoint como um serviço durável
Torne seguras as solicitações válidas repetidas, registre um evento de auditoria mínimo e monitore falhas sem expor tokens. Alerta sobre erros de processamento e backlogs de supressão. Uma resposta que afirma ser bem-sucedida antes de uma atualização durável precisa de um design de processamento confiável e de um tempo de conclusão limitado.
Encerre a implementação com verificação de mensagens, testes de endpoint e uma exclusão observada do próximo envio para um destinatário controlado. Nada disso por si só prova que toda interface de caixa de correio exibirá um botão de cancelamento de assinatura.
Escolha o reparo no ponto de verificação com falha
Um requisito de redirecionamento ou login exige reparo do endpoint. Um mapeamento incorreto de destinatário/lista exige reparo no escopo da autorização. Um endpoint correto com uma exportação de campanha obsoleta exige reparo de propagação. Não feche todos os três porque um POST retornou sucesso.