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

Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 19 September 2016 19:07 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 D2A2F12B50A for <ietf@ietfa.amsl.com>; Mon, 19 Sep 2016 12:07:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id el_lPsh8_5HN for <ietf@ietfa.amsl.com>; Mon, 19 Sep 2016 12:07:21 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E0A212B4ED for <ietf@ietf.org>; Mon, 19 Sep 2016 12:07:20 -0700 (PDT)
Received: from [172.31.24.203] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 051A9284809 for <ietf@ietf.org>; Mon, 19 Sep 2016 19:07:19 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
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 <ietf-dane@dukhovni.org>
In-Reply-To: <alpine.OSX.2.11.1609191434370.12026@ary.qy>
Date: Mon, 19 Sep 2016 15:07:18 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <6DD54672-A321-42A8-837C-0F5A85A2D796@dukhovni.org>
References: <20160913134903.53136.qmail@ary.lan> <92E953F2FB47FC32E3F4A4FC@JcK-HP8200> <F7F400B1-44BF-4B8F-AC2F-FAA345245D5C@isode.com> <73d6495b-8c74-8742-532a-2f7fcb0dae94@dcrocker.net> <alpine.OSX.2.11.1609181848420.6785@ary.lan> <d459387c-e60c-ee77-1fc7-1c10132d5cad@dcrocker.net> <alpine.OSX.2.11.1609181924360.6785@ary.lan> <ef367a2e-0c6c-10fe-00df-6e332bd76047@bbiw.net> <alpine.OSX.2.11.1609181939230.6785@ary.lan> <124a95ef-3307-893f-c638-88722b3fd9f2@dcrocker.net> <alpine.OSX.2.11.1609182007370.7133@ary.lan> <ced79576-7d7f-51ae-cd35-07d73bf7f8a8@dcrocker.net> <alpine.OSX.2.11.1609191434370.12026@ary.qy>
To: ietf@ietf.org
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/OPfbUgUj_L5pzdCBa35hxe3UsFw>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: ietf@ietf.org
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: Mon, 19 Sep 2016 19:07:23 -0000

> On Sep 19, 2016, at 2:35 PM, John R Levine <johnl@taugh.com> wrote:
> 
> I went through and addressed a bunch of the editorial suggestions, which were indeed helpful.  Before I post the next and I hope last version let's wait and see if the smoke settles.

A couple of comments:

In:

   A List-Unsubscribe header can also contain a mailto: URI with an
   address to which an unsubscription request is sent.  While these URIs
   can be for a one-click unsubscribe, experience has shown that they do
   not work well in high volume environments, because the recipient mail
   systems (typically e-mail service providers that are optimized to
   send large volumes of mail) cannot keep up with the required number
   of mailed removal requests.  Hence this document considers only HTTPS
   URIs.

It seems to me that catering to senders whose unsubscribe volume is so
high as to overwhelm their email systems should not be a priority.

Can you explain the DKIM requirement in more detail?  Is the MUA required
to verify the DKIM signature?  Or is it expected to alternatively trust
any Authentication-Results header?  What purpose does the DKIM signature
serve, if there is no required correlation between the authenticated "d="
value and the authority of HTTPS unsubscribe URI?

What are the cross-origin risks in allowing the incoming mail to trigger
a POST to a URI of the sender's choice with sender selected parameters?

The Examples in Section 7 don't have anything resembling HMAC signatures
over the recipient + list data, or opaque nonces that identify both.

-- 
	Viktor.