Re: Last Call: <draft-levine-herkula-oneclick-04.txt> (Signalling one-click functionality for list email headers) to Proposed Standard

[Dave Crocker <[e-mail]>]

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=[e-mail]
>
>    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=[e-mail]
>
>
>
>
>
>
>
>
> Levine & Herkula         Expires March 19, 2017                 [Page 6]
>
>
> Internet-Draft            One click unsubscribe           September 2016
>
>
> 7.2.  Complex
>
>    Header in Email
>
> List-Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>,
>     <https://example.com/unsubscribe.html?campaign=123456789>
> List-Unsubscribe-Post: List-Unsubscribe=One-Click&recip=[e-mail]
>
>    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=[e-mail]
>
> 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: [phone]
>    Email: [e-mail]
>    URI:   http://jl.ly
>
>
>    Tobias Herkula
>    optivo GmbH
>    Wallstrasse 16
>    Berlin  10179
>    DE
>
>    Phone: [phone]
>    Email: [e-mail]
>    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