Read the two fields and the self-contained HTTPS URI
02The email contains one List-Unsubscribe field and one List-Unsubscribe-Post field. The HTTPS URI must carry enough information to select the recipient and list.
A mailto URI may accompany the HTTPS URI. Only the HTTPS URI is the target of this mechanism; RFC2369 usage otherwise stays unchanged.
Source for this drawing: RFC 8058 · Read RFC section 3.1 ↗
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
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
The URI identifies what to remove; the fixed body identifies the action.
- Use one of each header field. List-Unsubscribe MUST contain one HTTPS URI; other non-HTTP/S URIs such as mailto are permitted. List-Unsubscribe-Post MUST contain only List-Unsubscribe=One-Click.
- The HTTPS URI MUST contain enough information to identify the mail recipient and list for automatic removal. There are no extra POST arguments and no follow-up question asking which address or list.
- The URI SHOULD include an opaque or other hard-to-forge component, and the endpoint SHOULD verify it. Opaque means its meaning is not exposed to the reader; opacity alone does not establish unforgeability.
The URI example is public RFC8058§8.1. A hypothetical server-side mapping illustrates meaning, not a required database design or a real subscriber. The mailto alternative is not the HTTPS one-click POST target. Field syntax is shown, not a complete signed email.
Read the RFC section ↗