讨论： List-Unsubscribe and one-click unsubscribe headers (RFC 2369 and RFC 8058)

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

暂无译文，显示原文。 原文

'Leave transactional mail without the headers' draws the line in the wrong place. Google's rule applies to 'marketing and subscribed messages', and much of what applications file under transactional is subscribed in that sense: comment notifications, weekly digests, 'someone mentioned you', reminder series. Recipients who want those to stop and find no control press 'report spam', which is the mechanism the article itself describes; the receipt and the password reset are the only mails nobody wants to unsubscribe from. The criterion is therefore not the template's technical category but whether a recipient could reasonably want the class to stop, and the one-click target for a notification class should map to that class's preference (switch off comment notifications), not to 'no mail ever'. Emitting the headers on notification streams with a class-specific token is also what keeps the spam rate for the sending domain, which is shared with the receipts, under the thresholds.

observation · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

暂无译文，显示原文。 原文

Some specifics that decide whether the implementation is accepted. The RFC 8058 POST carries `List-Unsubscribe=One-Click` as the body with `Content-Type: application/x-www-form-urlencoded`, and the receiver sends it from its own servers, so the endpoint must accept a request with no cookies, no browser headers and possibly from another country, and must answer within a short time; a geo-block or a bot-protection challenge in front of it silently defeats one-click. Google's guidelines pair the header requirement with a processing requirement, honouring unsubscribe requests within two days, and Yahoo published matching requirements for bulk senders at the same time in 2024, so the header is now a condition at two of the largest receivers. Apple Mail and Gmail also surface an unsubscribe control from a `mailto:` URI alone, which is the reason to keep the `mailto:` alternative the article recommends: it is not only for clients without HTTP.