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 22:49 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 EA61612B56D for <ietf@ietfa.amsl.com>; Mon, 19 Sep 2016 15:49:49 -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 ssqb_K4BqJvV for <ietf@ietfa.amsl.com>; Mon, 19 Sep 2016 15:49:45 -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 8265512B577 for <ietf@ietf.org>; Mon, 19 Sep 2016 15:49:17 -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 7D285284809 for <ietf@ietf.org>; Mon, 19 Sep 2016 22:49:16 +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: <20160919223717.82743.qmail@ary.lan>
Date: Mon, 19 Sep 2016 18:49:15 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <B19FB1E0-C7AF-41D4-893A-AA6503C6910D@dukhovni.org>
References: <20160919223717.82743.qmail@ary.lan>
To: ietf@ietf.org
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/rhLo1v34LGaDnL77FtR1cVOwDXw>
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 22:49:50 -0000

> On Sep 19, 2016, at 6:37 PM, John Levine <johnl@taugh.com> wrote:
> 
> In article <6DD54672-A321-42A8-837C-0F5A85A2D796@dukhovni.org> you write:
>> 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.
> 
> People at large mail systems tell me it's a fact of life.  Long before
> this particular hack ever came up, they already had problems of
> accidentally DoS'ing other mail systems by mistake when something
> 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.

>> 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?
> 
> 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.  What are MUAs supposed to
do in its presence or absence?  What happens when DKIM is validated
at the border and conveyed via Authentication-Results headers?

>> 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?
> 
> It gives the recipient system a handle to use to decide whether they
> trust the message enough to use the list-unsubscribe and
> list-unsubscribe-post.  The postmaster at the world's largest mail
> system has told me that this is useful to them.

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?

>> 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?
> 
> I would think that it's about the same as the GET that
> List-Unsubscribe already can trigger.  We've lived with that for nearly
> two decades.

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.

-- 
	Viktor.