Re: [perpass] draft-josefsson-email-received-privacy

Nick Doty <npdoty@ischool.berkeley.edu> Tue, 20 October 2015 22:10 UTC

Return-Path: <npdoty@gmail.com>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF90F1B3551 for <perpass@ietfa.amsl.com>; Tue, 20 Oct 2015 15:10:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 h5_f07YjSSE9 for <perpass@ietfa.amsl.com>; Tue, 20 Oct 2015 15:10:51 -0700 (PDT)
Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 344231ACEB7 for <perpass@ietf.org>; Tue, 20 Oct 2015 15:10:51 -0700 (PDT)
Received: by pacfv9 with SMTP id fv9so34418469pac.3 for <perpass@ietf.org>; Tue, 20 Oct 2015 15:10:50 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=/xvddCmGjkYCo4QFX4C8NZlYvXIlZZkYo3Gq3Xefc3Q=; b=DuyBDT+K057U8HyoHojiRI4RK7NxVoKFrSk0OYniXwMfO8y83oa67uyzCSVVGdU39J b2QXsTwEDStQHGCcKL7jr13wsZHj9SDJyTyXWacQV6U6hQsmL/iQhTttnrMaoQ6sKFYu Tot8G8EvzKf4lq7FBrzQWBCJqxhyryJ6g7RC9GCPqGgVJ0P3PKDurcmE0Glm3uiPzF/s wIVuNDteV8HmU0W8k3wGpmdJ3oHJQZhRx2E9BKJFui2uGa8Ol1koHzWNClF/vcmfmXXC +vgrXug1nvk/vFQ02Af0FK6d9qdRnhOz5QyU+FeytanRYkUvKXTmGWXMRTfgsUKwkvDU zWFA==
X-Received: by 10.66.233.70 with SMTP id tu6mr6519469pac.83.1445379050497; Tue, 20 Oct 2015 15:10:50 -0700 (PDT)
Received: from ?IPv6:2607:f140:400:a000:60ef:fc44:db3b:6349? ([2607:f140:400:a000:60ef:fc44:db3b:6349]) by smtp.gmail.com with ESMTPSA id qn5sm5530869pac.41.2015.10.20.15.10.48 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 20 Oct 2015 15:10:49 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
Content-Type: multipart/signed; boundary="Apple-Mail=_1A83534C-B12A-409C-96B1-AF8C2708E769"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail 2.6b2
From: Nick Doty <npdoty@ischool.berkeley.edu>
In-Reply-To: <87r3kpmm25.fsf@nordberg.se>
Date: Tue, 20 Oct 2015 15:10:44 -0700
Message-Id: <A7EEB4C3-0448-454A-80E6-66B3AC9B5BBE@ischool.berkeley.edu>
References: <87r3kpmm25.fsf@nordberg.se>
To: Linus Nordberg <linus@nordberg.se>
X-Mailer: Apple Mail (2.3094)
Archived-At: <http://mailarchive.ietf.org/arch/msg/perpass/9mG9mnLUtWfGHk3vC39L2kWmdP4>
Cc: perpass@ietf.org
Subject: Re: [perpass] draft-josefsson-email-received-privacy
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " <perpass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perpass>, <mailto:perpass-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/perpass/>
List-Post: <mailto:perpass@ietf.org>
List-Help: <mailto:perpass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perpass>, <mailto:perpass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Oct 2015 22:10:53 -0000

Thanks for writing this up and for sharing!

> On Oct 20, 2015, at 11:28 AM, Linus Nordberg <linus@nordberg.se> wrote:
> 
> Hi,
> 
> draft-josefsson-email-received-privacy-00 has been submitted, see
> https://datatracker.ietf.org/doc/draft-josefsson-email-received-privacy/
> 
> I'd be interested in hearing what people on the perpass list think of
> this.

I believe the introduction is trying to provide the use cases, but I think it would be worth elaborating in Section 2 as to why or when an operator should not add the Received header.

If the use cases are reasonably broad, then what would be the implications of recommending that all agents should not add a Received header unless engaged in debugging relay problems? If that were feasible, it seems like it would be more useful to those interested in privacy of this header if removing the header were common, rather than a positive indicator of the agent's choosing to maintain a special level of privacy.

Regarding the security considerations section, I don't think we should rely on a specification note that systems should be robust. In terms of implementations, do spam or abuse-filtering systems currently use the Received header in practice to identify and mitigate against email spam? What would be the security implications if widespread implementations removed the Received header?

Hope this helps,
Nick