On Sep 19, 2016, at 10:36 PM, John Levine <johnl(_at_)taugh(_dot_)com> 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.