> On Sep 19, 2016, at 10:36 PM, John Levine <johnl@xxxxxxxxx> 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.