On Tue, Sep 20, 2016 at 05:51:21PM -0000, John Levine wrote:
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.
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
MUST sign it so they can, you know, interoperate.
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.
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.
I would strongly suggest that there be a requirement to include an
"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.
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.