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

"John Levine" <johnl@taugh.com> Tue, 20 September 2016 02:36 UTC

Return-Path: <johnl@taugh.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A2912B161 for <ietf@ietfa.amsl.com>; Mon, 19 Sep 2016 19:36:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kneenpSfCs8s for <ietf@ietfa.amsl.com>; Mon, 19 Sep 2016 19:36:38 -0700 (PDT)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7766812B172 for <ietf@ietf.org>; Mon, 19 Sep 2016 19:36:38 -0700 (PDT)
Received: (qmail 73772 invoked from network); 20 Sep 2016 02:36:35 -0000
Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 20 Sep 2016 02:36:35 -0000
Date: 20 Sep 2016 02:36:15 -0000
Message-ID: <20160920023615.83210.qmail@ary.lan>
From: "John Levine" <johnl@taugh.com>
To: ietf@ietf.org
Subject: Re: Last Call: <draft-levine-herkula-oneclick-04.txt> (Signalling one-click functionality for list email headers) to Proposed Standard
In-Reply-To: <B19FB1E0-C7AF-41D4-893A-AA6503C6910D@dukhovni.org>
Organization:
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/16jHryaIPVBPl9Sl1NkV-3imJOw>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Sep 2016 02:36:40 -0000

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