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> Tue, 20 September 2016 21:03 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 B3D5C12B9C4 for <ietf@ietfa.amsl.com>; Tue, 20 Sep 2016 14:03:47 -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 aQg9FBd8pZEB for <ietf@ietfa.amsl.com>; Tue, 20 Sep 2016 14:03:46 -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 86CA612B12A for <ietf@ietf.org>; Tue, 20 Sep 2016 14:03:45 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 50777284809; Tue, 20 Sep 2016 21:03:44 +0000 (UTC)
Date: Tue, 20 Sep 2016 21:03:44 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
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
Message-ID: <20160920210344.GR4670@mournblade.imrryr.org>
References: <4CEBA33A-6E57-4121-AC9D-9A2A9528E2B2@dukhovni.org> <20160920175121.85977.qmail@ary.lan>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160920175121.85977.qmail@ary.lan>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/3GongunlH4LN6HtxEmqaz61zZM4>
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: Tue, 20 Sep 2016 21:03:48 -0000

On Tue, Sep 20, 2016 at 05:51:21PM -0000, John Levine wrote:

> >I think there is a better reason to use HTTP(S) rather then email.
> 
> Nothing personal, but for interop purposes, the opinions of ops people
> at large mail systems matter a lot more than your opinion or mine.

They may have their views, but the spec is for the world at large,
and I do think that the "email unsubs may DoS the sender" rationale
will be seen as a feature and not a bug by many potential adopters.
We can provide a more broadly useful rationale.

[ The repeated appeals to higher authority, that "outranks" my
  views, are IMHO uncalled for. ]

> >> So senders
> >> MUST sign it so they can, you know, interoperate.
> >
> >The draft fails to explain that this is *sender* obligation.
> 
> I'm having trouble imagining someone implementing this who doesn't
> already know that senders put on the DKIM signatures, but I've
> twiddled the language in the draft to make the DKIM MUST clearer.

Of course the senders do the signing, the question is about the
text in the draft that requires DKIM.  Is this something that
senders must add because some receivers might want it, or (as I
read it at first) something that receivers must insist on for some
unexplained security reason.  Making this clear is important.

> >>> I would strongly suggest that there be a requirement to include an
> >>> "Origin: mailto:<envelope-sender>" header ...
> 
> >I am not talking about mailers wanting or not wanting this.
> 
> Yes, that's clear.  Like I said, if there is a shred of evidence that
> anyone would actually use this extra non-standard header, I'd be happy
> to think about it.  Once again, this goal of this draft is to enable
> people to interoperate, not to tell them how you or I think they
> should run their systems.

The "Origin:" header is quite standard, and a useful signal to 3rd
party HTTPS servers of potential cross-origin attacks.

There's a reason why browsers send "Origin:" headers, the MUA should
do the same when doing POST requests based on email headers.

-- 
	Viktor.