Re: [Shutup] [ietf-smtp] Proposed Charter for the "SMTP Headers Unhealthy To User Privacy" WG (fwd)

Ned Freed <ned.freed@mrochek.com> Mon, 30 November 2015 05:18 UTC

Return-Path: <ned.freed@mrochek.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 779131A8934 for <shutup@ietfa.amsl.com>; Sun, 29 Nov 2015 21:18:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.587
X-Spam-Level:
X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.585, SPF_HELO_PASS=-0.001, 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 FOsB5YKA13yC for <shutup@ietfa.amsl.com>; Sun, 29 Nov 2015 21:18:57 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id EC6AC1A8928 for <shutup@ietf.org>; Sun, 29 Nov 2015 21:18:56 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PTP8TD5Q4W00AR8C@mauve.mrochek.com> for shutup@ietf.org; Sun, 29 Nov 2015 21:13:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1448860431; bh=BFNdmK7CLYtTVcHU45W2LOgh8pXgkv3JJQemoO0xr9k=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=VzieBhhinkv8lar+jwD/9PPQCmHCeuBVVtLlRCUVxsj6IUl9Pdxfjnb3AVAk+SKjM RTDh7RtxVkh6YoeMv+1tXBjbhlPooI0iEqigwxEdoX1E6Ki8KLGyvZsUFeIRBAC4gv /Tr899HJFBZSHw4wqsk2sPH40matGAPornU1QhoQ=
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PTC2EECTPC01729W@mauve.mrochek.com>; Sun, 29 Nov 2015 21:13:45 -0800 (PST)
Message-id: <01PTP8T9GMFM01729W@mauve.mrochek.com>
Date: Sun, 29 Nov 2015 20:53:17 -0800 (PST)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Mon, 30 Nov 2015 02:18:03 +0000" <1448849884345-6302c7ad-3551840c-2a0b598f@fugue.com>
References: <20151129181346.9221.qmail@ary.lan> <1448849884345-6302c7ad-3551840c-2a0b598f@fugue.com>
To: Ted Lemon <mellon@fugue.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/shutup/qOl1VGz_CSjZO0a9sQg6TM36FGY>
Cc: shutup@ietf.org
Subject: Re: [Shutup] [ietf-smtp] Proposed Charter for the "SMTP Headers Unhealthy To User Privacy" WG (fwd)
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, 30 Nov 2015 05:18:58 -0000

> Sunday, Nov 29, 2015 1:13 PM John Levine wrote:
> > It's not even privacy vs. ops support, it's privacy issues via some
> > hints of sender's location vs. privacy issues via the recipient
> > getting spammed, phished, and malware'd.

> The only Received: header fields that you can trust are the ones that were
> added by servers in your administrative domain.

Nonsense. The most obvious counterexample is when you receive mail from a
trusted server in some other trusted domain.

In fact this is now the most common case: Mail is submitted to a large service
provider which if it exits the administrative domain at all goes directly to
your administrative domain. The Received: header fields from, say, aol.com is
entirely trustable, especially since you can check the DKIM signature.

A certain amount of heurisitics are involved, but these are well understood.

> Anything else, you have to trace back through the logs hop by hop to actually
> know that the mail transited those systems; otherwise, an attacker can fake up
> whatever Received: header fields they want in order to cast blame on whomever
> they want to harm.

No, they really can't. See above.

> That being the case, all the Received: header field needs to contain is a
> token that can be used to backtrace the message to its origin using the
> logs: anything else is superfluous.

Nope. For one thing, the use of a token would require some means
of accessing logs across administrative domains. That's not going to happen
for a whole bunch of reasons.

And the "from" clause d is far from the only thing of use in a Received: field.
In fact it's far from the only thing that has privacy implications. Just
as one example, "with" clauses can be used to indicate whether or 
not SSL/TLS was used to secure the connection. An unbroken Received: chain
can provide assurance (or repudiation) of end-to-end transport protection.

Unfortunately, so far the "analysis" that's been done of the privacy
considerations of email trace information has been so shallow that stuff  like
this has been missed. 

> So postcarding all kinds of private
> information about the end user is not only not actually useful for the
> reason you suggest, it is actively harmful to the end user.

Nonsense again. In a world where almost email is spam or worse, any mechanism
that provides benefits in the fight against spam is beneficial to end users.

				Ned