Quando un client di posta mostra il pulsante «Annulla iscrizione» accanto al nome del mittente, non sta leggendo il link in fondo alla newsletter. Sta leggendo un'intestazione del messaggio, List-Unsubscribe, pensata proprio per permettere la disiscrizione senza aprire pagine web. Implementarla correttamente conviene a tutti: l'utente che non vuole più ricevere i messaggi ha un'alternativa al tasto «segnala come spam», e il mittente evita una segnalazione che pesa sulla sua reputazione.
Le due intestazioni
List-Unsubscribe
È l'intestazione storica e può contenere un indirizzo email, un URL o entrambi, tra parentesi angolari e separati da virgola:
List-Unsubscribe: <mailto:unsub@example.com?subject=unsub-u83kd9>, <https://example.com/unsub/u83kd9>
Con la sola versione mailto il client invia un'email all'indirizzo indicato. Con la versione URL, nella forma originaria, il client poteva aprire la pagina nel browser.
List-Unsubscribe-Post
Lo standard RFC 8058 ha aggiunto una seconda intestazione che trasforma l'URL in un'azione automatica:
List-Unsubscribe-Post: List-Unsubscribe=One-Click
Quando è presente, il client invia una richiesta HTTP POST all'URL di List-Unsubscribe, con corpo List-Unsubscribe=One-Click. Nessuna pagina da visitare, nessun modulo da compilare. È questa la forma che i grandi provider richiedono oggi ai mittenti massivi per i messaggi promozionali.
Perché proprio POST
La scelta del metodo POST non è casuale. Molti sistemi di sicurezza aziendali e alcuni filtri antispam visitano automaticamente i link contenuti nei messaggi per controllare se portano a siti malevoli. Se la disiscrizione avvenisse con una semplice richiesta GET, questi controlli disiscriverebbero gli utenti a loro insaputa. Con POST il problema si evita: i sistemi di scansione non inviano richieste POST.
Ne segue una regola pratica: l'endpoint deve disiscrivere solo su POST. Una richiesta GET allo stesso URL può mostrare una pagina di conferma, ma non deve modificare nulla.
Progettare l'endpoint
Identificare l'iscritto senza esporlo
L'URL deve contenere un identificativo opaco, non l'indirizzo email in chiaro. Un buon approccio è un token che codifica l'iscritto e la lista, firmato con una chiave segreta del server, per esempio con HMAC. Così il server può verificare che il token non sia stato manipolato senza dover consultare una tabella di token monouso.
Non chiedere nulla all'utente
La richiesta POST arriva dal client di posta, non dall'utente in un browser. L'endpoint non può chiedere accesso, conferme, cookie o CAPTCHA. Deve rispondere con un codice di successo e registrare la disiscrizione.
Essere idempotente
Lo stesso utente può premere il pulsante due volte, o il client può ripetere la richiesta in caso di errore di rete. La seconda richiesta deve produrre lo stesso risultato della prima, senza errori.
Rispondere in fretta
Il client si aspetta una risposta rapida. Se la disiscrizione richiede operazioni lente, come la sincronizzazione con un CRM, conviene registrare la richiesta e completare il resto in modo asincrono.
Uno schema minimo del comportamento atteso:
POST /unsub/u83kd9.f2a1c0
Content-Type: application/x-www-form-urlencoded
List-Unsubscribe=One-Click
→ 200 OK (iscritto u83kd9 rimosso dalla lista, operazione registrata)
La firma DKIM deve coprire le intestazioni
RFC 8058 richiede che il messaggio abbia una firma DKIM valida che includa sia List-Unsubscribe sia List-Unsubscribe-Post nell'elenco h=. Senza questa protezione, un intermediario potrebbe sostituire l'URL e trasformare il pulsante in uno strumento di abuso. Molti provider ignorano l'intestazione se non è firmata.
Errori ricorrenti
| Errore | Effetto |
|---|---|
URL in http invece di https |
molti client non mostrano il pulsante |
| Disiscrizione su GET | utenti disiscritti dagli scanner di sicurezza |
| Endpoint che reindirizza a una pagina di login | il clic singolo non funziona |
| Intestazioni non firmate DKIM | il provider può ignorarle |
| Token riutilizzabile per altre liste | disiscrizioni involontarie da tutto |
| Richieste elaborate dopo giorni | l'utente riceve ancora messaggi e li segnala |
Una lista o tutte le liste?
L'intestazione si riferisce alla lista che ha generato il messaggio. Disiscrivere l'utente da quella sola lista è il comportamento corretto e atteso. Nel corpo del messaggio si può poi offrire un centro preferenze più ricco, dove scegliere argomenti o frequenza. Le due cose convivono: il pulsante del client fa una cosa sola e la fa subito, la pagina delle preferenze offre le sfumature.
Nel mio lavoro verifico sempre il flusso completo con un messaggio reale: intestazioni presenti, firma che le copre, richiesta POST che restituisce successo, iscritto effettivamente rimosso e nessun invio successivo.
In sintesi
List-Unsubscribeindica dove disiscriversi;List-Unsubscribe-Postrende la disiscrizione automatica con un POST.- L'endpoint deve agire solo su POST, per non essere attivato dagli scanner che visitano i link.
- Il token nell'URL deve essere opaco e firmato, e l'endpoint idempotente e senza richieste all'utente.
- La firma DKIM deve includere entrambe le intestazioni.
- Il pulsante del client disiscrive da una lista; il centro preferenze nel corpo offre le opzioni più fini.
