Visual RFC.
ALL RFCs / RFC 8058
Read the RFC ↗
RFC 8058 / ONE-CLICK EMAIL UNSUBSCRIBE

Separate a link fetch from consent to unsubscribe

01

Mail scanners fetch links without user action. One-click uses a consented HTTPS POST rather than treating that fetch as the unsubscribe command.

RFC 8058 · § 1EXAMPLE
3 / 3
Separate a link fetch from consent to unsubscribeThree independent comparisons assume sender support and required DKIM coverage. An automatic mail scanner GET fetches a manual confirmation page; that is not the one-click action. A mail receiver with no user consent stops before sending the POST. With consent the receiver sends the defined HTTPS POST, and the sender handles list removal without another manual confirmation. Timing and UI of consent are not prescribed, and no response status is invented.Link inspection is not consent to unsubscribeMail receiverSender endpointconsented HTTPS POSTList-Unsubscribe=One-ClickRequired DKIM checks assumed passedSender handles the identified removalNo further manual confirmation
03
Consent permits the defined action.

Assuming the required signed headers and sender support, the receiver posts the defined body and the sender handles removal without another manual confirmation. The response status is not specified here.

Source for this drawing: RFC 8058 · Read RFC section 1 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

A message needs an address.

Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.

Helpful first, if these ideas are unfamiliar

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Terms in this drawing
HTTPS
HTTP carried over an authenticated encrypted connection to the selected server.
POST
An HTTP method used here to submit the defined unsubscribe action.
DKIM
DomainKeys Identified Mail: message signatures checked by the receiver.
Opaque identifier
A value whose internal meaning is not exposed; it should also be hard to forge for this use.
Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

Fetching a link and authorizing removal are different events.

  • An automatic GET can lead to a manual confirmation page; fetching a URI alone is not the defined one-click POST action. Other List-Unsubscribe URI use remains unchanged.
  • A mail receiver MUST NOT perform the one-click POST without user consent. When and how it obtains consent is outside this specification.
  • With consent, required authenticated headers and sender support, the receiver can process removal in the background without further user interaction or a confirmation-page interpretation.
DETAILS

A mail receiver is software handling received mail, including a Mail User Agent (MUA). The sender operates the list and its unsubscribe endpoint. These comparisons assume the required DKIM checks in chapter3. Consent need not be collected at a particular button or time; this RFC does not define that UI.

Read the RFC section ↗

All chapters in RFC 8058

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗