Re: Last Call: <draft-levine-herkula-oneclick-04.txt> (Signalling one-click functionality for list email headers) to Proposed Standard

["John Levine" <[e-mail]>]

>> 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