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

From: John C Klensin <[email-masked]>
Date: Mon, 12 Sep 2016 21:05:37 -0400

--On Monday, September 12, 2016 09:58 -0700 The IESG
<[email-masked]> wrote:

> 
> The IESG has received a request from an individual submitter
> to consider the following document:
> - 'Signalling one-click functionality for list email headers'
>   <draft-levine-herkula-oneclick-04.txt> as Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and
> solicits final comments on this action. Please send
> substantive comments to the [email-masked] mailing lists by
> 2016-10-10. 

Hi.  I've looked through this and find it a little troubling,
partially because I don't like the problem rather than not
liking the details of the solution.

I've seen deliberate attempts to disrupt mailing lists by
unsubscribing participants.  While crude, a message to a user
asking for verification of intent to unsubscribe is an important
protection against that behavior.  Similarly, having anti-spam
system follow/execute links in headers (as distinct from links
in message bodies) seems like a bad idea generally, but
verification messages or other two-step processes are an
important protection against accidental (but, IMO, badly
designed) or malicious bad behavior.   So this specification
proposed a way to bypass those safeguards and protection?   I'm
not convinced that is a good idea and what the document has to
say about it is 

	"This document does not address problems associated with
	deliberate malicious behavior."

That seems to me to be equivalent to "we don't need to worry
about bad guys because they will never attempt to use this
feature".  Really?

The one protection that it offers is DKIM verification of the
sending domain and headers.  That is fine, modulo all of the
concerns about how easy DKIM is to spoof and the observation
that it really just validates a sending domain.  However,
consider the following case, remembering that a message for
which this is relevant should be coming from a mailing list:

   ...
   MAIL FROM:<[email-masked]>
   RCPT TO:<[email-masked]>
   ...
   From: [email-masked]
   To:  [email-masked]
   ...
   DKIM-Signature:  ...; d=ietf.org; ...
      h=From:...:List-Unsubscribe:List-Unsubscribe-Post:...
   ...
   List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>,
      <mailto:[email-masked]?subject=unsubscribe>
   List-Unsubscribe-Post: 
      List-Unsubscribe=One-Click&recip=[email-masked]

Now the signature verifies just fine because the message was
sent from example.com, and the MUA promptly issues a POST that
removes poor Sucker from the IETF list.   Even more interesting,
consider what happens if the last line of that example is 

      List-Unsubscribe=One-Click&recip=[email-masked]

Unless I've misunderstood this feature, unless the list manager
does some checking --several versions of which checking this
mechanism is designed to eliminate or forbid-- the MUA (or
delivery server or anti-spam mechanism) associated with
[email-masked] promptly unsubscribes [email-masked] from
the IETF list.

Without studying the spec further, I'm not sure how much this
would help, but I'd expect to see at least a check that the
DKIM-signed sender domain for the list manager matches the
domains in the List-Unsubscribe field.   Without that check,
this seems far too hazardous, even with a disclaimer that
malicious behavior is out of scope.  

I do wonder about other topic areas in which one could create an
I-D and propose it for Standards Track by putting a short
section in the middle that says "This document does not
address...deliberate malicious behavior" and thereby avoid the
tedious and time-consuming requirement of BCP 72 to describe
what can go wrong with various types of easily-predicted attacks.

     john

---

From: "John R. Levine" <[email-masked]>
Date: 12 Sep 2016 21:45:47 -0400

> proposed a way to bypass those safeguards and protection?

No, of course not.  The unsubscribe links in the mail this will affect are 
invariably unique to the message's recipient with a hard to forge hash of 
some sort.  So if you have the message, you are the subscriber or the 
subscriber gave the message to you.

I've talked at some length to the people at Gmail who plan to implement 
this, and they've clearly dealt with more mail forgery than any of us.

By the way, in the US, it is not just poor practice to require 
confirmation of unsubscribe requests for commercial mail, but under the 
FTC's CAN SPAM rules, it is illegal to do so.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Mon, 12 Sep 2016 23:15:52 -0400

--On Monday, September 12, 2016 21:45 -0400 "John R. Levine"
<[email-masked]> wrote:

> No, of course not.  The unsubscribe links in the mail this
> will affect are invariably unique to the message's recipient
> with a hard to forge hash of some sort.  So if you have the
> message, you are the subscriber or the subscriber gave the
> message to you.

But that doesn't show up in your the examples and, as far as I
can tell from quick reading, there is nothing in the text that
says "the unsubscribe links need to contain a hard to forge hash
or this would be a really bad idea" or something equivalent.
My guess is that this would be harmless at worst if the security
and operational issues were spelled out, but they aren't.

AFAICT, such a hash would be a better solution than the weaker
one I was contemplating with DKIM, so there may be just a
documentation problem rather than a technical one.

> I've talked at some length to the people at Gmail who plan to
> implement this, and they've clearly dealt with more mail
> forgery than any of us.

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.   

If you want to see this as a Proposed Standard, then I think
there needs to be enough information, clearly spelled out, to
let people implement it in a way that is both interoperable and
safe.

The other possibility is that this is a Gmail idea or plan and
the real purpose of publication is to register a new header
field and tell MUA authors what they should do if they get some
fields Gmail is about to start producing.  That would make a
perfectly sensible Informational document that could be
descriptive rather than normative about what they sender/
mailing list software does and only use more or less the current
text to specify what the recipient/ would-be unsubscriber does.
You could probably even submit it through the Independent Stream
and try to convince the ISE to accept Section 4 or a variation
on it -- I believe that section and the narrowly-focused
Security Considerations one that results violates the intent and
requirements of BCP 72 that apply, AFAICT, to all IETF Stream
technical specifications.

    john

---

From: <[email-masked]>
Date: Tue, 13 Sep 2016 11:09:33 +0200

On Mon, 12 Sep 2016 23:15:52 -0400

> documentation problem rather than a technical one.

In section 5.1 it only forces the sending side to implement it in a
way, so that they can identify the recipient by only the information
they but into the two Header fields. We for example use something like
this:

List-Unsubscribe: <http://example.com/go/13/1UJBVSN4-1UAMMHU8-1UHCJOWL-122U7IX.html>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

This requirement does not stretches to the receiving entity. The
purpose of the document is to standardize the way to inform the
receiving entity that the HTTPS URI provided in the List-Unsubscribe
Header offers one-click functionality.

More requirements are not needed and would to a certain point even
diminish interop, as almost every single bulk-mail provider and
mailinglist manager have their own beliefs in how to handle their
unsubscription processes...

> technical specifications.

If an attacker has access to these Headers he also has access to the
body of the mail, so from an security standpoint in makes no
difference, that is the reason this document does not try to fix this
vector, it is out of scope.

The intention for this came from an Open Round Table discussion at
M³AAWG from last year and a wide acceptance in the group of mail
handling entities at M³AAWG is the reason this document was brought up
to the IETF. There are at least 2 major ISPs, 3 E-Mail Service
Providers and 2 other related parties already working on the
implementation.

Kind regards,

/ Tobias Herkula

--
optivo GmbH
Head of Deliverability & Abuse Management
Wallstraße 16
10179 Berlin
Germany

Tel: +49(0)30-768078-129
Fax: +49(0)30-768078-499

Email:    mailto:[email-masked]
Website:  http://www.optivo.com
Linkedin: http://www.linkedin.com/in/tobiasherkula

Commercial register: HRB 88738 District Court Berlin-Charlottenburg
Executive board: Dr. Rainer Brosch, Thomas Diezmann
Vat reg. no.: DE813696618

optivo A company of Deutsche Post DHL Group

---

From: "John Levine" <[email-masked]>
Date: 13 Sep 2016 13:49:03 -0000

>information, with that issue about hashes as one example,

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.

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.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Tue, 13 Sep 2016 10:54:19 -0400

--On Tuesday, September 13, 2016 13:49 +0000 John Levine
<[email-masked]> wrote:

>> 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

---

From: "John R Levine" <[email-masked]>
Date: 13 Sep 2016 11:16:59 -0400

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

> the first issue doesn't get some response in this thread, I may

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 13 Sep 2016 15:36:16 +0000

On Tue, Sep 13, 2016 at 10:54:19AM -0400, John C Klensin wrote:

> it isn't appropriate for a Proposed Standard.

I agree that the specification needs to provide sufficient guidance
so that implementors don't make various otherwise likely mistakes.

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 16 Sep 2016 00:50:49 -0000

I've submitted a -05 version that clarifies the motivation and the
security issues.  The bits on the wire are the same.

https://datatracker.ietf.org/doc/draft-levine-herkula-oneclick/

R's,
John

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 18 Sep 2016 11:42:41 +0100

Hi John,

> On 13 Sep 2016, at 15:54, John C Klensin <[email-masked]> wrote:
> 

The document got updated by John L. and I think your issues were addressed. As the document only spent 4 days in IETF LC, I will let it continue. I can add an extra week for reviews after the LC  is finished, to make sure people have enough time to review changes.

Best Regards,
Alexey

---

From: Dave Crocker <[email-masked]>
Date: Sun, 18 Sep 2016 15:40:49 -0700

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

---

From: Dave Crocker <[email-masked]>
Date: Sun, 18 Sep 2016 16:21:57 -0700

On 9/18/2016 3:49 PM, John R Levine wrote:
> Thanks for your comments.  Since the people at mail systems who have
> already implemented this had no problems understanding it, I'm not
> inclined to make further revisions.

Oh.  Wow.

d/
-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Sun, 18 Sep 2016 16:47:44 -0700

On 9/18/2016 4:40 PM, John R Levine wrote:
> Here's the XML.  Feel free to rewrite it (really), keeping in mind that
> the bits on the wire are already cast in concrete.

oh.  well, that would make the IETF process a very pure example of a 
rubber stamp, which it has historically been quite vigorous in refusing 
to be.

So, sorry, but no thanks.

d/

-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Mon, 19 Sep 2016 11:14:05 -0700

John,

On 9/18/2016 5:15 PM, John R Levine wrote:
>> rubber stamp, which it has historically been quite vigorous in
>> refusing to be.
>
> I probably shouldn't try and answer mail when dinner is burning on the
> stove.  Sigh.
>
> In any event, where you see a rubber stamp (and I could swear that
> someone with a name similar to yours was part of the group that dropped
> DMARC on the IETF), I see a question of whether the IETF has defined
> itself into irrelevance.

That you think the two situations are equivalent is broken at a very 
basic level.

> I don't remember whether you were at the MAAWG in Philadelphia, but when
> I was there I stumbled upon a conversation with Tobias and Sri from
> Gmail et al, who were ready to implement a truly dreadful design for
> one-click, using magic fragment identifiers in http GETs.  I stuck in my
> oar, explained why POST would be semantically better and no harder to
> code, and then ran off to fix Tobias' design, which is where this draft
> comes from.
>
> Gmail and AOL and probably all the other large mail systems are going to
> implement this whether or not it has an IETF stamp on it.  I'd rather it
> be documented so people outside the MAAWG club can interoperate, too,
> and I think that's more important than whatever tiny tweaks might make
> it more IETF-ishly optimal.  What do you think?

First, you appear to be thinking that I don't like the proposal, but my 
review didn't criticize the intent or basic approach.  I took issue with 
some of the details and some of the writing.  I made suggestions where I 
could.

I note that you have not yet responded to the very specific technical 
concerns I raised.

Given the tone and language of your responses, I then took issue with 
your stated inflexibility.

A 'take it or leave it' stance with existing work being handed to the 
IETF qualifies the work for non-standards track status.[*]  So publish 
the thing as Independent Stream and Informational.

The premise behind IETF standards track is that the work is subject to 
IETF community input.  Your comments have taken a position against 
incorporating that input.

d/

[*] When existing work has an installed base, then assessing how 
important it is to preserve that base is part of the acceptance process 
when the IETF work is chartered.  Since there's no working group 
chartering process here, there's been no discussion about the need for 
protecting the installed base.  Rather, you have simply imposed the 
requirement by fiat.  And as an afterthought, quite late in this very 
abbreviated process.

-- 

   Dave Crocker

---

From: "John R Levine" <[email-masked]>
Date: 19 Sep 2016 14:35:41 -0400

I went through and addressed a bunch of the editorial suggestions, which 
were indeed helpful.  Before I post the next and I hope last version let's 
wait and see if the smoke settles.

Regards,

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 19 Sep 2016 15:07:18 -0400

> On Sep 19, 2016, at 2:35 PM, John R Levine <[email-masked]> wrote:
> 
> I went through and addressed a bunch of the editorial suggestions, which were indeed helpful.  Before I post the next and I hope last version let's wait and see if the smoke settles.

A couple of comments:

In:

It seems to me that catering to senders whose unsubscribe volume is so
high as to overwhelm their email systems should not be a priority.

Can you explain the DKIM requirement in more detail?  Is the MUA required
to verify the DKIM signature?  Or is it expected to alternatively trust
any Authentication-Results header?  What purpose does the DKIM signature
serve, if there is no required correlation between the authenticated "d="
value and the authority of HTTPS unsubscribe URI?

What are the cross-origin risks in allowing the incoming mail to trigger
a POST to a URI of the sender's choice with sender selected parameters?

The Examples in Section 7 don't have anything resembling HMAC signatures
over the recipient + list data, or opaque nonces that identify both.

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 19 Sep 2016 22:37:17 -0000

>high as to overwhelm their email systems should not be a priority.

People at large mail systems tell me it's a fact of life.  Long before
this particular hack ever came up, they already had problems of
accidentally DoS'ing other mail systems by mistake when something
provoked a lot of responses.  In any event, our goal here is to help
make mail less lousy, not to make a statement about how we think
people should design their systems.

>any Authentication-Results header?

That's an implementation detail.  In the most likely implementations,
it's web mail so the MDA and MUA are all the same system.

> What purpose does the DKIM signature

It gives the recipient system a handle to use to decide whether they
trust the message enough to use the list-unsubscribe and
list-unsubscribe-post.  The postmaster at the world's largest mail
system has told me that this is useful to them.

>a POST to a URI of the sender's choice with sender selected parameters?

I would think that it's about the same as the GET that
List-Unsubscribe already can trigger.  We've lived with that for nearly
two decades.

>over the recipient + list data, or opaque nonces that identify both.

The examples in the upcoming -06 are slightly opacified.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 19 Sep 2016 18:49:15 -0400

> On Sep 19, 2016, at 6:37 PM, John Levine <[email-masked]> wrote:
> 

If they DoS a few spammers, seems like a win... :-)  In any case,
there's no need for this as a motivation in the RFC.

> it's web mail so the MDA and MUA are all the same system.

The requirement for DKIM signing is a mystery in the draft.  If is
there, its purpose should be explained.  What are MUAs supposed to
do in its presence or absence?  What happens when DKIM is validated
at the border and conveyed via Authentication-Results headers?

> system has told me that this is useful to them.

If it is merely useful to them, there's no requirement for DKIM on
the receiving side, and this is not enough to mandate DKIM in the
draft.  Perhaps you meant to say that senders SHOULD use DKIM,
otherwise the one-click unsubscribe signal might not be honoured?

> List-Unsubscribe already can trigger.  We've lived with that for nearly

I think not, "GET" is supposed to not have non-idempotent side-effects.
I would strongly suggest that there be a requirement to include an
"Origin: mailto:<envelope-sender>" header in the POST, which would
indicate to the target webserver that it is dealing with a cross-origin
request.

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 20 Sep 2016 02:36:15 -0000

>there's no need for this as a motivation in the RFC.

I wouldn't disagree, except that the reason it's there is about six messages
ago people were complaining that I didn't explain why you had to use https
rather than mailto.

>there, its purpose should be explained.

Really, it's what I said. It's so receipient systems have a handle to
evaluate the message.  As you are doubtless aware, MUST means "do this
if you want to interoperate."  At least one very large mail system has
told me that they will only do one-click on signed mail.  So senders
MUST sign it so they can, you know, interoperate.

>otherwise the one-click unsubscribe signal might not be honoured?

No.  See above.

>indicate to the target webserver that it is dealing with a cross-origin

If you can find a non-trivial mailer who actually wants that, and you
are offering to update RFC 6454 so that header would be valid, I'd
consider it.  They've already got the List-Unsubscribe=One-Click if
they want a clue about why the POST is happening.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 19 Sep 2016 23:16:36 -0400

> On Sep 19, 2016, at 10:36 PM, John Levine <[email-masked]> wrote:
> 

I think there is a better reason to use HTTP(S) rather then email.

   * Immediate success/fail feedback with lower resource cost and latency
     for both the client and the server.

> MUST sign it so they can, you know, interoperate.

The draft fails to explain that this is *sender* obligation.

I see no MUST above, nor is it clear that the MUA is not obligated to
check this, but the sender MUST sign, else some MUAs might not honour
the signal.  I honestly had no idea what that paragraph was saying,
until you explained it as a sender obligation in this thread.

> they want a clue about why the POST is happening.

I am not talking about mailers wanting or not wanting this.  The issue is
avoiding a cross-origin attack vector.  A malicious sender can
get the MUA to POST arbitrary form content to an arbitrary URL.

If the MUA uses some common HTTP library, the request might end-up
authenticated (cached cookies, client certs, ...).

An "Origin" request header can help the target server identify the
request as a cross-origin request.

   https://www.w3.org/TR/cors/#origin-request-header
   https://tools.ietf.org/html/rfc6454#section-7

If your concern is that the syntax in RFC6454 is "scheme://host"
or "null", which does not include "mailto:address", then "null"
would be an adequate choice, or frankly "mailto://domain" (perhaps
from DKIM rather than the envelope).  In any case the POST specified
in this draft is clearly a cross-origin request, and so I rather think
it needs an "Origin" header.

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 20 Sep 2016 17:51:21 -0000

>I think there is a better reason to use HTTP(S) rather then email.

Nothing personal, but for interop purposes, the opinions of ops people
at large mail systems matter a lot more than your opinion or mine.

>The draft fails to explain that this is *sender* obligation.

I'm having trouble imagining someone implementing this who doesn't
already know that senders put on the DKIM signatures, but I've
twiddled the language in the draft to make the DKIM MUST clearer.

>>> "Origin: mailto:<envelope-sender>" header ...

>I am not talking about mailers wanting or not wanting this.

Yes, that's clear.  Like I said, if there is a shred of evidence that
anyone would actually use this extra non-standard header, I'd be happy
to think about it.  Once again, this goal of this draft is to enable
people to interoperate, not to tell them how you or I think they
should run their systems.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Tue, 20 Sep 2016 12:19:16 -0700

> at large mail systems matter a lot more than your opinion or mine.

So, the only discussion I see for this draft is during this last call, 
on this list.

I see postings from a total of 4 people, other than yourself and the 
sponsoring AD.

None of the content of the postings relate to the issue about which you 
are asserting definitive information, above.

That reduces your assertion to one of your own authority on the topic.

No doubt, your assessment is perfectly correct.  However the IETF has 
typically sought a broader base for assessing such assertions, lest 
Internet Standards be reduced to individual whim.

Simply put:  The folk who want this spec and who want it to be exactly 
as you've specified it need to show up here and post their informed 
views on the spec.  Otherwise, there is no objective basis for 
estimating the actual need or likely uptake of the spec.

d/

-- 

   Dave Crocker

---

From: "John R Levine" <[email-masked]>
Date: 20 Sep 2016 15:50:58 -0400

I really hope you're wrong, because if you're not, the only sensible thing 
to do is to tell the mail providers to go ahead and implement the draft, 
maybe the IETF will do something, maybe not.  Registrar EPP has been 
working this way for over a decade, and it would be a shame for IETF 
sclerosis to make it happen to mail, too.

I assume you saw the mail on dispatch last month from Sri Somanchi 
at Google explaining in detail why they want this, and the various 
messages from my co-author Tobias.  I believe they're why this advanced 
from a random draft to AD sponsored.

R's,
John

On Tue, 20 Sep 2016, Dave Crocker wrote:

> So, the only discussion I see for this draft is during this last call, on 
> this list.
>
> None of the content of the postings relate to the issue about which you are 
> asserting definitive information, above.
>
> typically sought a broader base for assessing such assertions, lest Internet 
> Standards be reduced to individual whim.
>
> Simply put:  The folk who want this spec and who want it to be exactly as 
> you've specified it need to show up here and post their informed views on the 
> spec.  Otherwise, there is no objective basis for estimating the actual need 
> or likely uptake of the spec.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 20 Sep 2016 21:03:44 +0000

> at large mail systems matter a lot more than your opinion or mine.

They may have their views, but the spec is for the world at large,
and I do think that the "email unsubs may DoS the sender" rationale
will be seen as a feature and not a bug by many potential adopters.
We can provide a more broadly useful rationale.

[ The repeated appeals to higher authority, that "outranks" my
  views, are IMHO uncalled for. ]

> >> So senders

Of course the senders do the signing, the question is about the
text in the draft that requires DKIM.  Is this something that
senders must add because some receivers might want it, or (as I
read it at first) something that receivers must insist on for some
unexplained security reason.  Making this clear is important.

> should run their systems.

The "Origin:" header is quite standard, and a useful signal to 3rd
party HTTPS servers of potential cross-origin attacks.

There's a reason why browsers send "Origin:" headers, the MUA should
do the same when doing POST requests based on email headers.

-- 
	Viktor.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 20 Sep 2016 15:58:39 -0700

On 9/20/2016 12:50 PM, John R Levine wrote:
> I really hope you're wrong, because if you're not, the only sensible

Wrong about what, exactly?  I've no idea what you are referring to.

But the implication that there was anything unusual or incorrect in my 
previous note is, itself, pretty remarkable, since it stated nothing 
other than long-standing IETF policy/practice.

> I assume you saw the mail on dispatch last month from Sri Somanchi at
> Google explaining in detail why they want this, and the various messages
> from my co-author Tobias.  I believe they're why this advanced from a
> random draft to AD sponsored.

I hadn't.  And yes, that's the sort of posting I was asking for, just as 
Mary Barnes did in Dispatch, to which Sri's note was the only response.

So apparently your view is that having a gmail product manager posting 
support is sufficient substantiation for declaring an IETF standard, and 
it needed be done during Last Call for an individual submission?

We don't even need AOL to post a comment, in spite of your reference to 
their support?

d/
-- 

   Dave Crocker