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

["John R Levine" <[e-mail]>]

I think I have a pretty good idea about what to add, some motivation about 
why some mailers want to make it easy to unsubscribe, and a SHOULD about 
using a unique URL with a hard to forge hash.  I don't think it's worth 
trying to define hard to forge.

The email world has gotten very concentrated and I wouldn't be surprised 
if less than ten providers handled more than half of the world's active 
mailboxes.  There's a whole lot of list providers ranging from big 
corporate ones down to little boutiques, e.g., one that only handles mail 
to subscribers of Wordpress blogs.  Out in the long tail of mailbox 
provieders there's a lot of commercial and free webmail software.  So even 
though the biggest impetus for this is Gmail, I expect to see it 
implemented by a lot of senders and receivers.

R's,
John


> --On Tuesday, September 13, 2016 13:49 +0000 John Levine
> <[e-mail]> wrote:
>
>>> Ah.   That may suggest the disconnect we are having lies
>>> somewhere other than in what I assumed.   This document
>>> appears to have been written for Standards Track and the Last
>>> Call is for publishing it as a Proposed Standard.  That
>>> implies at least a plausible assumption or realistic hope
>>> that it will be implemented and deployed by multiple
>>> independent parties.  For that purpose, it just isn't
>>> complete and doesn't contain enough information, with that
>>> issue about hashes as one example, perhaps among many.
>>
>> We already have two implementations in progress, at Gmail and
>> AOL, and as Tobias said, this got enough attention at MAAWG
>> that I think it's likely that other webmail providers will do
>> it, too, as will a lot of ESPs (bulk mail providers.)  I agree
>> that it could use some more hints about unique URLs to avoid
>> forgery.
>
> Yes, but, again, I think it is more than hints -- I think there
> either needs to be enough information in the spec for safe,
> interoperable, independent implementations to be created or that
> it isn't appropriate for a Proposed Standard.  For a situation
> like this, "enough information" isn't present and "independent"
> doesn't apply if either depends, not on the text, but on
> side-discussions between implementers or in MAAWG (or other
> bodies, even the halls of the IETF) unless the content of those
> discussions is normatively references (and meets the RFC
> Editor's criteria for accessibility of normatively referenced
> materials).
>
>> I don't know where if anywhere this would go in the draft, but
>> the ESPs that are likely to implement this have rather
>> different concerns from discussion lists like this one.  They
>> want the subscribers to get the mail, but they are much more
>> concerned about minimizing complaints for fear of their mail
>> going somewhere other than recipients' inboxes. If you make
>> the unsub process complex, a fair number of people will figure
>> (correctly for them) that it's easier just to report it all as
>> spam until it goes away.
>
>> So given a tradeoff between defending against fake
>> unsubscribes versus making it easy for people to mail the mail
>> stop, they'll pick the latter.  I doubt this will ever make it
>> into Mailman, but that's OK.
>
>> The reason we're having this discussion is that Gmail noticed
>> that people used the spam button to unsubscribe, so they added
>> an option to the spam button to unsubscribe at the same time,
>> and for that to work they need to do it without further
>> interaction.  It'd also be useful to automatically unsub from
>> mail to closed or abandoned mailboxes.
>
> IMO, that motivation and perspective is very important.  It is
> clearly not how I was thinking about the problem.
>
> After this (to me very helpful) discussion, let me summarize my
> concerns and then move on -- if no one other than myself and
> those directly involved care, I don't want to spend more time on
> it.  The two issues below are almost completely separate.
>
> (1) Traditionally, the IETF makes standards _for the Internet_.
> When the needs, perspectives, and views of tradeoffs of a few
> very specific providers (whether specific by size or some other
> criteria) are different from those of the vast majority of
> providers (by count, not number of users or, in this case,
> number of messages), then we have a problem that, as far as I
> know, the IETF community has never really addressed.  With no
> disrespect to Google or AOL (or, in other areas and for example,
> Cisco, Huawei, and Juniper) one extreme version of the question
> is whether it appropriate for 600 pound gorillas or a consortium
> or them to shape the Internet, even if that hurts or locks out
> smaller providers or users with different profiles and needs.
>
> I don't know the answer to any of those questions, nor to what
> the IETF should do about them.  They raise some old topics about
> who really has change control of a suggested or approved
> standard, but that is only part of the issue.  IMO, a serious
> discussion is probably overdue.  I don't think that discussion
> should be placed in the critical path of any given document if
> we can process those documents without setting precedents that
> preempt the discussion and its possible conclusions.
>
> (2)  For a proposed standard that meets both the criteria of RFC
> 2026 and successors and what I believe to be IETF's traditional
> approach and role, I think this document needs a lot of work.  I
> think it should be explicit about use cases and motivations
> (reflecting your comments above); that it should contain (or
> normatively reference) enough information to permit
> interoperable implementations and safe use without
> side-knowledge that is not _very_ generally available; that it
> should discuss difference (and maybe tradeoffs) among different
> types of provider and user models; and that it should have a
> sufficient discussion of security issues to permit readers to
> assess risks, including risks associated with weak
> implementations.  I don't think our norms for Proposed Standards
> permit a document to say "security is out of scope" or even
> "deliberate malicious behavior is out of scope", so that needs
> to be fixed.
>
> With one possible exception, all of this second issue is about
> the spec, not the header/protocol.   The exception is that, for
> interoperation this is appropriately safe, either you need to
> describe the conditions for a sufficiently protective hash and
> make its presence a MUST requirement or you need an in-depth
> Security Considerations discussion about that issue.
>
> YMMD and, again, I hope to not spend more of my time and that of
> the IETF list on this document and the second point above (if
> the first issue doesn't get some response in this thread, I may
> start another one).
>
> best,
>     john
>
>
>

Regards,
John Levine, [e-mail], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly