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

Viktor Dukhovni <> Tue, 20 September 2016 03:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CCF7812B5F2 for <>; Mon, 19 Sep 2016 20:16:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CLd8KBmgn8QQ for <>; Mon, 19 Sep 2016 20:16:39 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A598112B5DC for <>; Mon, 19 Sep 2016 20:16:39 -0700 (PDT)
Received: from vpro.lan ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id C0293284ADC for <>; Tue, 20 Sep 2016 03:16:37 +0000 (UTC) (envelope-from
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: Last Call: <draft-levine-herkula-oneclick-04.txt> (Signalling one-click functionality for list email headers) to Proposed Standard
From: Viktor Dukhovni <>
In-Reply-To: <20160920023615.83210.qmail@ary.lan>
Date: Mon, 19 Sep 2016 23:16:36 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <20160920023615.83210.qmail@ary.lan>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 20 Sep 2016 03:16:42 -0000

> On Sep 19, 2016, at 10:36 PM, John Levine <> 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.

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.