Re: [Shutup] [ietf-smtp] Proposed Charter for something

John C Klensin <john-ietf@jck.com> Mon, 07 December 2015 07:31 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: shutup@ietfa.amsl.com
Delivered-To: shutup@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9B8B1A1A72; Sun, 6 Dec 2015 23:31:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 PAvuY5R4A3Lh; Sun, 6 Dec 2015 23:31:35 -0800 (PST)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9095F1A02BE; Sun, 6 Dec 2015 23:31:35 -0800 (PST)
Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1a5qGj-0002mJ-SR; Mon, 07 Dec 2015 02:31:33 -0500
Date: Mon, 07 Dec 2015 02:31:28 -0500
From: John C Klensin <john-ietf@jck.com>
To: John Levine <johnl@taugh.com>, ietf-smtp@ietf.org, shutup@ietf.org
Message-ID: <A30A1DCAF4E8522A8FA65578@JcK-HP8200.jck.com>
In-Reply-To: <20151207023426.54934.qmail@ary.lan>
References: <20151207023426.54934.qmail@ary.lan>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <http://mailarchive.ietf.org/arch/msg/shutup/VGteShKr-BwSU3mDGg1ID9RArks>
X-Mailman-Approved-At: Mon, 07 Dec 2015 00:31:17 -0800
Cc: ietf@mustelids.ca
Subject: Re: [Shutup] [ietf-smtp] Proposed Charter for something
X-BeenThere: shutup@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SMTP Headers Unhealthy To User Privacy <shutup.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/shutup>, <mailto:shutup-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/shutup/>
List-Post: <mailto:shutup@ietf.org>
List-Help: <mailto:shutup-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/shutup>, <mailto:shutup-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Dec 2015 07:31:37 -0000


--On Monday, December 07, 2015 02:34 +0000 John Levine
<johnl@taugh.com> wrote:

>...
> This is increasingly looking like a RG, not a WG.  There's a
> lot of speculation about what aspects of mail messages and
> SMTP sessions have what privacy implications, with an
> extremely premature focus on IP address logging.  I'd much
> rather back up a step or two and see if we can catalog the
> aspects of mail messages with estimates of the privacy
> benefits and risks of each, keeping in mind the context.  
> 
> For example, how much new information is there in the date
> stamp in a Received header in the usual case that it's a few
> seconds after the timestamp in the Date: header?  On the other
> hand, most Received headers have a unique ID that's really
> handy to identify the message and the path it took (That's how
> you tell who's sending spam reports from AOL and Yahoo, even
> though they redact all the addresses.)
> 
> That would be a useful catalog, and we can think about models
> that look at the net personal information, and diagnostic and
> anti-abuse information provided by various combinations of
> features or the lack thereof.  That would be interesting on
> its own, and would give us a much better foundation from which
> to consider changes that could produce an actual overall
> privacy improvement.

This strikes me as a really good idea.  This is probably what
John has in mind but, to be explicit, if it could also catalog
(not just allow "thinking about"), for each item, the
substantive uses to which any relevant aspect or datum is being
legitimately put today, differentiating things that are
specifically anti-spam from anti-phishing and mitigation of
malware and other types of attacks, that would be even better.
As many people have suggested in the previous threads, "more
privacy", whether about location or other information, is not
free but involves tradeoffs with other priorities and it is
important to consider the tradeoffs and balance.   

For me at least, Dave Crocker's subsequent comments reinforce
that view.

     john