>> provoked a lot of responses. In any event, our goal here is to help >> make mail less lousy, not to make a statement about how we think >> people should design their systems. > >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. >> 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. >If it is merely useful to them, there's no requirement for DKIM on >the receiving side, and this is not enough to mandate DKIM in the >draft. Perhaps you meant to say that senders SHOULD use DKIM, >otherwise the one-click unsubscribe signal might not be honoured? No. See above. >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. R's, John