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

Keep web context out and recognize security limits

05

The operation uses the message URI, not a logged-in browser session. The endpoint must handle the POST directly, and message possession still carries risk.

DIAGRAMRead RFC section 6 ↗
RFC 8058 · § 6EXAMPLE
3 / 3
Keep web context out and recognize security limitsThree independent safety examples. A consenting receiver sends only the message-defined HTTPS POST and fixed body, with cookies, Authorization and other previous web context absent. A prohibited sender redirect stops before returning to the mail receiver; direct POST handling is required. A hypothetical server follows SHOULD and checks the hard-to-forge URI component, then applies the identified removal. A copied valid URI can still be used by its holder; DKIM and HTTPS do not prove that holder is the subscriber.Separate request isolation from identityURI componentSender endpointSHOULD verify componentExample: valid hard-to-forge componentApply list A / recipient R removalA copied valid URI can still be usedNot proof of the subscriber’s identity
03
Check the URI component without overclaiming identity.

A hypothetical endpoint follows SHOULD and verifies the hard-to-forge component before applying the identified removal. Someone holding a copied valid URI can still make that request; DKIM and HTTPS do not prove subscriber identity.

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

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

RFC 5322 Email message format RFC 6376 DKIM mail signatures RFC 9110 HTTP

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

Related RFCs and changes

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

KEY POINT

Required isolation and recommended token checks solve different problems.

  • The POST MUST NOT include cookies, HTTP authorization or any other context information. It is logically separate from previous web activity; HTTPS does not remove this requirement.
  • The sender MUST NOT return an HTTPS redirect for this action. It must provide infrastructure that handles the advertised POST URI without relying on redirected POST behavior.
  • The endpoint SHOULD verify an opaque or hard-to-forge URI component. Anyone with access to the message can unsubscribe its recipient; a successful POST is not proof of the human subscriber’s identity. An unsubscribe can also reveal address validity to the mailer.
DETAILS

Three independent safety examples, not stages of one request. Fake list/recipient/token labels are teaching data only. A hard-to-forge URI helps deter forged requests; it does not make a copied message private or prove whoever sent the POST is its original recipient. Consent collection policy and UI are outside the RFC.

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 ↗