Review of: Signalling one-click functionality for list email headers
I-D: draft-levine-herkula-oneclick-05
Reviewed by: D. Crocker
Review Date: 18 Sept 2016
Summary
-------
It would be helpful to make it easier for users to unsubscribe from
mailing lists, ideally reducing the effort down to one mouse click, for
a URL that is already visible in material being directly presented to
the user. This specification seeks to satisfy that goal.
The Introduction and Motivation section is initial a bit confusing, in
terms of both the nature of who will use this and why it is needed. The
first section needs to consider it's sequencing of text more carefully
and make its distinctions more clearly.
The text variously seems to indicate multiple uses for this mechanism
(automated conversion of a user clicking the spam button into an
unsubscribe, versus user clicking unsubscribe) but then seems to mandate
only user-initiated -- or at least user-aware -- unsubscribe.
RFC2360 (List-Unsubscribe) supports specification of multiple URLs. The
current draft does not indicate how to correlate the -post information
with a particular URL from a list. This issue goes away if the -post
header field is made self-contained, including the URL.
d/
Detailed Comments
-----------------
Abstract
This document describes a method for signaling a one-click function
The term "one-click function" is used here as a term of art, and is the
only language in the Abstract meant to explain what the actual mechanism
is. While the term has intuitive appeal, it doesn't really explain much
and certainly doesn't explain what problem is being solved. As usual in
the IETF, talking about user interface functionality is part of the
challenge.
for the list-unsubscribe email header. The need for this arises out
of the actuality that mail software sometimes fetches URLs in mail
headers, and thereby accidentally triggers unsubscriptions in the
case of the list-unsubscribe header.
1. Introduction and Motivation
An [RFC2369] email header can contain HTTPS [RFC7230] URIs. In a
header field
List-Unsubscribe Header the HTTPS URI is intended to unsubscribe the
recipient of the email from the list. But anti-spam software often
fetches all resources in mail headers automatically, without any
header fields
The anti-spam sentence doesn't seem to be connected to the rest of the
paragraph. I'm not understanding how it's point is relevant to the
purpose of the mechanism.
I also don't know what "accidental unsubscriptions" means, how it occurs
or how serious a problem it is. (Really, I hadn't heard of it before this.)
action by the user. To prevent accidental unsubscriptions, senders
return landing pages with a confirmation step to finish the
unsubscribe request. This has undesirable consequences for mailers
who wish for the unsubscription process to be as simple as possible.
The document should make the problem it is solving clear in terms of
nature and seriousness.
What are the "undesirable consequences" other than requiring the user to
read the page and make one more click, and why is that onerous?
(Presumably it's onerous because the barrier to use in click sequences
tends to go up non-linearly, so that even one more click can
significantly reduce use? Since one more click doesn't sound that bad
to many/most folk, this should be documented explicitly. Whatever the
is the actual motivation for reducing the number of clicks, it needs to
be justified more substantively here.)
Different types of mailing lists are managed in different ways. Non-
commercial discussion lists that exchange messages among the list's
subscribers typically try to ensure that requests to subscribe and
unsubscribe are valid, but don't worry too much about message
Sorry, but it is not at all clear what the term 'non-commercial
discussion lists' means. Really. Is it about the nature of the list
management economic model, the content of the discussion, or what? In
general, my sense of mailing lists is that their basic management and
operation is pretty much the same, no matter who owns them or how it is
run.
The following text seems to try to clarify this, but it's worth
improving...
delivery, since all the messages are typically delivered to the
recipients. Commercial broadcast lists are much more concerned about
deliverability, whether the mail is delivered to the recipients and
how the messages are presented, e.g., whether in the primary inbox or
in a junk folder. Many mail systems allow recipients to report mail
as spam or junk, and mail from senders with a lot of junk reports
tends to have poor deliverability. Hence the mailers want to make it
as easy as possible for recipients to unsubscribe, since the
Again, the anti-spam reference seems out of place, since unsubscribing
is not the same as reporting abuse.
I think the intended distinction, above, is between 'discussion groups'
and 'uni-directional (marketing) multicast lists'.
The commercial/non-commercial distinction is distracting and probably
specious. Whether the marketing multicast list is commercial,
political, religious or whatever doesn't matter.
However even with a clarification of this, the functional import between
discussion list and multicast list, for the specification here, is not
at all clear. Is there some reason it is ok for unsubscription from a
discussion list to be different/harder than for a marketing list.
Levine & Herkula Expires March 19, 2017 [Page 2]
Internet-Draft One click unsubscribe September 2016
recipient's alternative to a difficult unsubscription process is to
report mail from the sender as junk until it goes away.
The recipient mail systems are aware that their users do not make a
Even with recent advances in AI, mail systems have no awareness.
Perhaps what is meant here is the operators of recipient mail systems?
clear distinction between unsubscription and junk, so in many cases
they allow trustworthy mailers to request notification when their
mail is reported as junk, so they can unsubscribe the recipient.
Since the process of identifying trustworthy mailers and notifying
them does not scale well to large numbers of small mailers, this
specification provides a way for recipient systems to notify the
mailer automatically, using only information within the mail message.
From the above sequence, it appears that 'trustworthiness' is
irrelevant to this mechanism. Certainly the connection between the
trust-based mechanism that doesn't scale and the one proposed here is
not made.
Some recipient systems might wish to send an unsubscription notice to
mailers whenever a user reports a message as junk, or they might give
the user the option to report and unsubscribe.
If a mail recipient is unsubscribing manually and the unsubscription
process requires confirmation, the resulting web page is presented to
the recipient who can then click the appropriate button. But when
the unusubscribe action is combined with a MUA junk report, there is
no direct user interaction with the mailer's web site. Similarly,
there can be no interaction when the action is performed
automatically on mail sent to an abandoned or closed mailbox. In
those cases, the unsubscription process has to work without manual
intervention, and in particular without requiring that software
attempt to interpret the contents of a confirmation page.
This document addresses this part of the problem, with a POST action
for receivers that senders can distinguish from other requests and
handle as a one-click unsubscription without manual intervention by
the mail recipient.
"POST"? What is this referring to? There's nothing beforehand that
sets it up.
A List-Unsubscribe header can also contain a mailto: URI with an
address to which an unsubscription request is sent. While these URIs
can be for a one-click unsubscribe, experience has shown that they do
not work well in high volume environments, because the recipient mail
systems (typically e-mail service providers that are optimized to
send large volumes of mail) cannot keep up with the required number
Referential confusion: 'recipient mail systems... that are optimized to
send..."?? huh? They receive. They don't send.
of mailed removal requests. Hence this document considers only HTTPS
URIs.
This doesn't make sense to me. Why would one stream of unsubscribes be
more difficult/slower to process than the other?
This document has several goals.
o Allow email senders to signal that a [RFC2369] List-Unsubscribe
header has One-Click functionality.
o Allow MUA designers to implement independent user interface
features for a better user experience.
Instead of the broad and judgemental assertion by authority that this
will be superior, please describe what the technical nature of the user
experience difference is intended to be. I can make some guesses about
what is intended here, but the reader should not have to make guesses.
Levine & Herkula Expires March 19, 2017 [Page 3]
Internet-Draft One click unsubscribe September 2016
o Allow MUA users to trigger intended actions in a familiar
environment and without leaving the MUA context.
This bullet is really redundant with the previous bullet.
I think that what's missing from the list is something like:
o Allow receiving systems to do background unsubscription requests
and know that they can be fully processed by the list owner's
system.
2. Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] when written
in all capital letters.
"One-click" describes an action that directly triggers a change in a
system's state, intended to be applied only with a user's intent.
Except that really isn't the only scenario that's provided for, here,
given the reference to mapping a spam click into an unsubscribe.
"a system" is too vague, since there are least two systems at play here.
3. Implementation
3.1. Mail senders
An entity which is responsible for sending an email that wishes to
emails have wishes?
perhaps: An email-sending operator who wishes...
or: An email-sending entity can add an HTTPS...
add an HTTPS URI for one-click unsubscriptions places both a List-
Unsubscribe and a List-Unsubscribe-Post header in the message. The
I'm still not understanding why a new header field is needed, given that
we already have List-Unsubscribe.
List-Unsubscribe-Post header may contain multiple key value pairs
needed by the sending entity. It also MUST contain the key value
pair "List-Unsubscribe=One-Click".
"the sending entity" is ambiguous, since there is mail sending and
https-sending. I suspect what is meant here is the sender of the POST
(although the fact this this section is "Mail senders" probably means
I'm wrong... sigh.)
The combination of the URI in the List-Unsubscribe header and the
POST arguments in the List-Unsubscribe-Post header MUST contain
enough information to identify the mail recipient and the list from
which the recipient is to be removed, so that the unsubscription
process can complete automatically. In particular, One-click has no
way to ask the user what address he or she wishes to unsubscribe.
Given the claim that this is for user convenience, then the claim that
there is no access to the user seems a non-sequitur. This needs to be
explained more clearly.
The URI and POST arguments SHOULD include a hard to forge component
such as a hash in addition to or instead of the plain-text names of
in addition to or instead of the -> in addition to, or instead of, the
It isn't just that it's difficult to forge. It's that it serves to
identify that the information came from the list itself.
So perhaps: include a component serving as a list operator
identification token that is difficult to forge, such as a hash of the
unsubscribe information. This should be in addition to, or instead of, ...
the list and the subscriber. This will deter attacks in which a
malicious party sends fraudulent mail purporting to be from the list,
with the intention of getting the user to unsubscribe from the actual
list.
The problem with this guidance is that it is only a should and therefore
the user and the user's system will have no way of being certain what is
a forged message...
The sending entity needs to provide the infrastructure to handle POST
requests to the specified URI in the List-Unsubscribe header, and to
to the specified URI in the -> to the URI specified in the...
handle the reasonably foreseeable volume of unsubscribe requests that
its mail will provoke.
The One-Click action triggered by this URI SHOULD complete promptly
and not burden the requester in an inappropriate way. The sending
entity cannot expect that HTTPS redirects are followed by the
requester, since redirected POST actions have historically not worked
reliably.
"cannot expect" isn't very useful specification language.
To ensure interoperability, this sounds like it needs to be a MUST NOT.
Levine & Herkula Expires March 19, 2017 [Page 4]
Internet-Draft One click unsubscribe September 2016
3.2. Mail receivers
A receiving entity which wants to use a List-Unsubscribe HTTPS URI
which wants to use a List-Unsubscribe
->
that supports the List-Unsubscribe
from an email that also contains a List-Unsubscribe-Post header
performs an HTTPS POST to the first HTTPS URI in the List-Unsubscribe
header and sends the content of the List-Unsubscribe-Post header as
the request body.
Are there any cases in which a List-Unsubscribe-Post can be present
without a List-Unsubscribe? I assume not.
So really what needs to be said here is:
A receiving entity that supports List-Unsubscribe-Post performs an
HTTPS POST...
(and, of course, header -> header field...)
The POST content SHOULD be sent as "multipart/form-data" [RFC7578]
and MAY be sent as "application/x-www-form-urlencoded". These
encodings are the ones used by web browsers when sending forms. The
How is the system sending the POST supposed to know which form will work?
Make it a single required media type. If a site is adding support for
-post, it should be sure to support that one, standardized form.
If there is a clear and compelling reason to make that media type a
SHOULD rather than a MUST, then remove the MAY statement: SHOULD means
"MUST, unless you know what you are doing". If you know what you are
doing, you don't need further guidance or permission from the spec...
target of the POST action will typically be the same as or similar to
the one in the manual confirmation page when doing a two-click
unsubscribe, so this is intended to allow the same server code to
handle both.
The above sentence seems uninformative and gratuitous.
The receiving entity MUST NOT perform a POST on the the HTTPS URI
without user consent. When and how the user consent is obtained is
not part of this specification.
Huh? So, converting a 'spam' click into an 'unsubscribe' request isn't
supported by this spec?
The Request uses the HTTPS verb POST. The HEAD and GET requests are
not intended to be used to trigger a state change. PUT and DELETE
would offer similar functionality but are often unavailable.
This is strikingly later in the text than it should be. It should be
earlier, to introduce use of POST.
4. Additional Requirements
The email needs at least one valid authentication identifier. In
"needs" isn't normative. So it isn't clear what to do with this
'requirement'. But since it's a 'requirement' why not simply state this
normatively?
valid -> validated
this version of the specification the only supported identifier type
is DKIM [RFC6376], that provides a domain-level identifier in the
content of the "d=" tag of a validated DKIM-Signature header field.
The List-Unsubscribe and List-Unsubscribe-Post headers need to be
covered by the signature, and hence must be included in the "h=" tag
of a valid DKIM-Signature header field.
State the exact purpose of this requirement.
5. Header Syntax
field
The following ABNF imports fields, WSP, and CRLF from [RFC5322]. It
imports ALPHA and DIGIT from [RFC5234].
Levine & Herkula Expires March 19, 2017 [Page 5]
Internet-Draft One click unsubscribe September 2016
fields /= l-u-post
ldh = ALPHA 0*(ALPHA | DIGIT | "-")
l-u-post = "List-Unsubscribe-Post:" 0*1WSP postarg 0*("&" postarg) CRLF
postarg = ALPHA 0*ldh "=" freetext
freetext = 1*(%x20-%xfe)
; ampersand, percent, and equal sign must be percent encoded
6. IANA Considerations
IANA is requested to add a new entry to the Permanent Message Header
Field Names registry.
Header field name: List-Unsubscribe-Post
Applicable protocol: mail
Status: standard
Author/Change controller: IETF
Specification document: this document
7. Examples
7.1. Simple
Header in Email
List-Unsubscribe: <https://example.com/unsubscribe.html>
List-Unsubscribe-Post:
List-Unsubscribe=One-Click&recip=user(_at_)example(_dot_)com
Resulting POST request
POST /unsubscribe.html HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 49
List-Unsubscribe=One-Click&recip=user(_at_)example(_dot_)com
Levine & Herkula Expires March 19, 2017 [Page 6]
Internet-Draft One click unsubscribe September 2016
7.2. Complex
Header in Email
List-Unsubscribe:
<mailto:listrequest(_at_)example(_dot_)com?subject=unsubscribe>,
<https://example.com/unsubscribe.html?campaign=123456789>
List-Unsubscribe-Post:
List-Unsubscribe=One-Click&recip=user(_at_)example(_dot_)com
Resulting POST request
POST /unsubscribe.html?campaign=123456789 HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 49
List-Unsubscribe=One-Click&recip=user(_at_)example(_dot_)com
8. Security Considerations
The List-Unsubscribe-Post header will typically contain the recipient
address, but that address is usually also in the To: header. This
specification allows anyone with access to a message to unsubscribe
the recipient of the message, but that's typically the case with
existing List-Unsubscribe, just with more steps.
A creative mailer could send spam with content intended to provoke
large numbers of unsubscriptions, with suitably crafted headers to
send POST requests with arbitrary contents to servers that perhaps
don't want them. But it's been possible to provoke GET requests in a
similar way for a long time (and much easier, due to spam filter
auto-fetches) so the chances of significantly increased annoyance
seem low.
Since the mailer's server that receives the POST request cannot in
general tell where it is coming from, the URI or POST arguments
SHOULD contain a hash or other hard to forge component to verify the
list and recipient address to ensure that the request originated from
List-Unsubscribe and List-Unsubscribe-Post headers in a message the
mailer sent.
9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
Levine & Herkula Expires March 19, 2017 [Page 7]
Internet-Draft One click unsubscribe September 2016
[RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax
for Core Mail List Commands and their Transport through
Message Header Fields", RFC 2369, DOI 10.17487/RFC2369,
July 1998, <http://www.rfc-editor.org/info/rfc2369>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008,
<http://www.rfc-editor.org/info/rfc5322>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011,
<http://www.rfc-editor.org/info/rfc6376>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>.
[RFC7578] Masinter, L., "Returning Values from Forms: multipart/
form-data", RFC 7578, DOI 10.17487/RFC7578, July 2015,
<http://www.rfc-editor.org/info/rfc7578>.
Appendix A. Change Log
Remove this section before publication, please.
A.1. Changes from -04 to -05
Reorganize first sections and add more background. Add ABNF. Add
more security advice.
A.2. Changes from -03 to -04
Require HTTPS. More motivation.
A.3. Changes from -02 to -03
Describe motivation in intro. Clarify required DKIM. More paranoid
scenarios.
Levine & Herkula Expires March 19, 2017 [Page 8]
Internet-Draft One click unsubscribe September 2016
Authors' Addresses
John Levine
Taughannock Networks
PO Box 727
Trumansburg, NY 14886
Phone: +1 831 480 2300
Email: standards(_at_)taugh(_dot_)com
URI: http://jl.ly
Tobias Herkula
optivo GmbH
Wallstrasse 16
Berlin 10179
DE
Phone: +49 30 768078 129
Email: t(_dot_)herkula(_at_)optivo(_dot_)com
URI: https://www.optivo.com
Levine & Herkula Expires March 19, 2017 [Page 9]
Html markup produced by rfcmarkup 1.119, available from
https://tools.ietf.org/tools/rfcmarkup/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net