Signaling One-Click Functionality for List Email Headers
Extracted elements (20)
Anti-spam software automatically fetches URLs in mail header fields, causing accidental unsubscriptions when GET-based List-Unsubscribe URIs are used. The RFC introduces a POST-based mechanism so senders can distinguish intentional user actions from automated fetches.
HTTPS redirects are explicitly prohibited in response to the POST because redirected POSTs have historically been unreliable and browsers have often silently converted them to GETs, which would undermine the one-click mechanism.
Mailers currently require a confirmation landing page to guard against accidental GET-triggered unsubscriptions, making the process require more than one click. This specification enables automated unsubscription (e.g., combined with junk reporting or for closed mailboxes) without manual intervention.
The target of the POST action is the same URI used for a manual GET-based unsubscription, so the same server-side code can handle both one-click automated unsubscriptions and user-initiated browser-based unsubscriptions.
This document does not update RFC 2369; usage of List-Unsubscribe URIs other than for one-click unsubscription remains unchanged, and the List-Unsubscribe header MAY still contain non-HTTP/S URIs such as MAILTO: alongside the HTTPS URI.
A mail sender enabling one-click unsubscription MUST place one List-Unsubscribe header field containing one HTTPS URI and one List-Unsubscribe-Post header field containing the single key/value pair 'List-Unsubscribe=One-Click'.
Senders MUST apply at least one valid DKIM signature to the message; if the message lacks the required DKIM signature, the mail receiver SHOULD NOT offer a one-click unsubscribe for that message.
The mail receiver MUST NOT perform a POST on the HTTPS URI without user consent; when and how user consent is obtained is outside the scope of this specification.
The mail sender MUST NOT return an HTTPS redirect in response to the POST request, since redirected POST actions have historically not worked reliably and many browsers convert redirected HTTP POSTs into GETs.
The message MUST have a valid DKIM signature that covers at least the List-Unsubscribe and List-Unsubscribe-Post headers, and both headers MUST be included in the 'h=' tag of a valid DKIM-Signature header field.
The POST content SHOULD be sent as 'multipart/form-data' (RFC 7578) or MAY be sent as 'application/x-www-form-urlencoded', matching the encodings used by web browsers when sending forms.
The POST request to the unsubscription URI MUST NOT include cookies, HTTP authorization, or any other context information, to prevent inappropriately linking the unsubscribe to previous web activity.
The URI in the List-Unsubscribe header MUST contain enough information to identify the mail recipient and the list from which the recipient is to be removed, so that unsubscription can complete automatically without extra POST arguments.
The URI SHOULD include an opaque identifier or another hard-to-forge component in addition to or instead of plaintext names of the list and subscriber, and the server SHOULD verify that this component is valid.
The List-Unsubscribe-Post header field is a new email header whose value is fixed to the single key/value pair 'List-Unsubscribe=One-Click', signaling that the corresponding List-Unsubscribe HTTPS URI supports one-click POST-based unsubscription.
IANA added a new entry 'List-Unsubscribe-Post' to the 'Permanent Message Header Field Names' registry with applicable protocol 'mail' and status 'standard', as specified by RFC 8058.
A malicious mailer could craft spam with List-Unsubscribe headers to trigger POST requests to arbitrary servers. The fixed 'List-Unsubscribe=One-Click' postarg value limits harm by preventing simulation of arbitrary form submissions on victim websites.
The List-Unsubscribe URI SHOULD contain an opaque or hard-to-forge component to verify that POST requests originated from a message the mailer sent, deterring attacks where spam triggers unsubscriptions from victim lists.
The unsubscription operation confirms to the mailer that the recipient address is valid, providing an address-validation oracle. However, simpler methods (e.g., embedded image links) already exist for this purpose, so the incremental risk is low.
The List-Unsubscribe-Post header is defined by the ABNF: 'list-unsubscribe-post = "List-Unsubscribe-Post:" 0*1WSP postarg CRLF' where 'postarg = "List-Unsubscribe=One-Click"'. The fixed postarg value prevents injection of arbitrary form fields.