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

Ned Freed <> Mon, 30 November 2015 05:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 779131A8934 for <>; Sun, 29 Nov 2015 21:18:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.587
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FOsB5YKA13yC for <>; Sun, 29 Nov 2015 21:18:57 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id EC6AC1A8928 for <>; Sun, 29 Nov 2015 21:18:56 -0800 (PST)
Received: from by (PMDF V6.1-1 #35243) id <> for; Sun, 29 Nov 2015 21:13:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; 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 by (PMDF V6.1-1 #35243) id <>; Sun, 29 Nov 2015 21:13:45 -0800 (PST)
Message-id: <>
Date: Sun, 29 Nov 2015 20:53:17 -0800 (PST)
From: Ned Freed <>
In-reply-to: "Your message dated Mon, 30 Nov 2015 02:18:03 +0000" <>
References: <20151129181346.9221.qmail@ary.lan> <>
To: Ted Lemon <>
Archived-At: <>
Subject: Re: [Shutup] [ietf-smtp] Proposed Charter for the "SMTP Headers Unhealthy To User Privacy" WG (fwd)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SMTP Headers Unhealthy To User Privacy <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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, 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.