Summary

  • RFC 2369 let mailing lists advertise an unsubscribe address or URL in a message header in July 1998. A URL that performs the removal when fetched leaves an automatic scanner and a willing reader looking alike to the sender.
  • RFC 8058, published in January 2017, added List-Unsubscribe-Post: List-Unsubscribe=One-Click. A valid DKIM signature must cover that field and List-Unsubscribe; the receiver must wait for user consent before sending an HTTPS POST.
  • The POST carries the fixed key/value pair, without cookies or HTTP authorization. The sender must complete the action at that URI without an HTTPS redirect. IANA's header registry records the new field.

A visit mistaken for a vote

The first step was useful. RFC 2369 gave a list a way to put unsubscribe instructions where mail software could find them. A reader did not have to hunt through the footer of every newsletter or remember a separate account password. The list could place an HTTPS URL in List-Unsubscribe, and the receiving program could expose it. The URL was an advertised route out.

Then mail security software did what security software is supposed to do: it examined links. RFC 8058 describes anti-spam systems fetching resources named in mail headers automatically, without action by the reader. If a list treated a visit to its unsubscribe URL as the completed command, inspection became removal. From the sender's server, the automatic request and a human request could look identical. A recipient could lose a subscription because a filter had followed the instructions meant for a person.

The common defense was a landing page with a confirmation step. A scanner could fetch the page without pressing the second button; a person could finish the job. That protected the list's state, but it took away the promised convenience. The reader who really wanted to leave had to make another trip. The problem sat at the boundary between reading a link and executing an instruction. A visible address was being asked to double as proof of intent.

The 2017 header made the second verb explicit

RFC 8058 did not retire the 1998 header. It required a sender offering the new one-click action to include an HTTPS URI in List-Unsubscribe and the separate field List-Unsubscribe-Post with exactly List-Unsubscribe=One-Click. The new field tells the receiving program that a POST to the URI, with that fixed pair as its body, is the action. A fetch of the link for inspection is a different operation. The distinction rests on HTTP method and receiver behavior, rather than on guessing whether a visitor has a human hand.

The sender also has to sign the message with DKIM and include both headers in the signature's h= list. The signature ties the advertised URI and the one-click instruction to a valid signed message. RFC 8058 says a receiving program should not offer one-click unsubscribe if that signature is missing. The signature does not decide what the user wants. It makes the sender's declared operation verifiable before the receiver offers it.

Consent comes next. The receiving program must not send the POST without it; the RFC leaves the interface for getting consent to the receiver. That is a narrow allocation of power. The sender may advertise an exit and authenticate the message. The mail program controls the button and the request. The reader supplies the decision. A background scanner can still inspect a URL, but it cannot satisfy the standard's condition for the state-changing POST just by looking.

A server has to finish the job at the advertised address

The POST body is intentionally small: the single key/value pair from List-Unsubscribe-Post. It carries no cookies, HTTP authorization or other request context. The URI itself has to identify both the recipient and the list sufficiently for the sender to complete removal. RFC 8058 advises using an opaque, difficult-to-forge identifier. This concentrates the transaction at one address; a sender cannot assume a browser session will supply missing identity later.

Nor may the sender respond to that POST with an HTTPS redirect. The RFC cites the history of redirected POSTs failing or being turned into GETs. A redirect would push the decisive action onto another step whose method might change underneath it. The endpoint must accept the authorized request and finish the removal there. The Internet's familiar habit of moving a URL can be dangerous when the URL is also an instruction to alter membership.

The specification expressly leaves other uses of RFC 2369 unsubscribe URLs alone. It adds a marked path for one-click removal. IANA registered List-Unsubscribe-Post, so the signal has a recognized place in a message. Registration records the name; successful behavior still needs the signed fields, consented receiver action and working sender endpoint.

The exit is a chain, not a link

The historical change was small enough to fit in a header and large enough to rearrange responsibility. A list operator controls the signed offer and the server that handles the POST. A receiving program controls whether a reader sees the one-click action and whether consent precedes the request. The reader controls the decision. Automatic inspection remains inspection. If any part of that chain is missing, the advertised exit can become a false removal or a decorative button.

The three official records here establish the protocol and the registration. They do not count adoption by any named mail service. Dated raw messages, receiver manuals and sender endpoint logs would show where the full chain actually ran. The precise lesson of RFC 8058 is already visible: the Web made it easy for software to open a link, so email had to become exact about which opening was a command.