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.