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

[Viktor Dukhovni <[e-mail]>]

> On Sep 19, 2016, at 10:36 PM, John Levine <[e-mail]> 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.
> 
> 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.

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.

>>> That's an implementation detail.  In the most likely implementations,
>>> 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.
> 
> 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.

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

   The email needs at least one valid authentication identifier.  In
   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.

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.

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

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.