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

Ned Freed <> Mon, 30 November 2015 19:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 881F51B2FFE for <>; Mon, 30 Nov 2015 11:54:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.688
X-Spam-Status: No, score=0.688 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 61jeb5KLAZ9u for <>; Mon, 30 Nov 2015 11:54:07 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 12BCD1B2FEF for <>; Mon, 30 Nov 2015 11:54:07 -0800 (PST)
Received: from by (PMDF V6.1-1 #35243) id <> for; Mon, 30 Nov 2015 11:49:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=mauve; t=1448912939; bh=GJwWw+9okzj5/w3TN/c/fIt+HpECy5KuSM0VYuVMD/Y=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=gvl6IpTjjj2GalAFixFBJQJHu7TO/tVQH1QlQuuUrQoa4N7AlEN2NnvDl6+yNTJ/J kYzvrMtGyehWoQP6UzL3DCAal85qQZ6Gv/O71W1y2xjR9vzd0g1wsM4zBAB06Gs1na kQ7f5ivl/9YZchlCnN1duCfOjrXvEQNlEHpNTkos=
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Received: from by (PMDF V6.1-1 #35243) id <>; Mon, 30 Nov 2015 11:48:50 -0800 (PST)
Message-id: <>
Date: Mon, 30 Nov 2015 09:50:58 -0800 (PST)
From: Ned Freed <>
In-reply-to: "Your message dated Mon, 30 Nov 2015 05:27:15 +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 19:54:08 -0000

> Sunday, Nov 29, 2015 11:53 PM Ned Freed wrote:
> > 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.

> Why would you want to check the Recieved: header fields in this case?   Under
> what circumstances would checking the header fields in a message known to have
> been received from, with a valid DKIM signature, add value over the
> validation you're already stipulating has happened?

Because vast amounts of spam comes through MSPs like, all nicely DKIM
signed. And of course you can't block completely - although I admit
it's really tempting sometimes.

> >> 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.

> I think we may be talking about different things.   If you are trying to
> identify spam, you wouldn't need to do this for mail received through  

Except that sometimes you do. See above.

> I'm talking about the case where someone is committing some kind of illegal
> behavior that triggers search warrants or other requests for records.  In this
> case, lawful requests can be satisfied by searching logs, and could not be
> satisfied by looking at the text of a message.   The data in such a message
> could not be considered trustworthy.

When did the needs of law enforcement become part of this?

Anyway, it is of course the case that logs are the best evidence. But logs
aren't always available, and if they are available they may not be accessible,
in which case you make do with what you have.

> > 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.

> Why would that be useful?

Oh, I don't know, perhaps to find out where gaps exists in privacy coverage
and patch them up? Service providers have proven to be fairly responsive
to customer requests for SSL/TLS 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.

> I don't think it's so much been missed as found to be of no obvious value.

> > 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.

> Yes, let us think of the children!

And with this I'm done. It is now quite apparent that not only do you have zero
clue about the operational realities of modern email systems, you aren't
interested in correcting your many misconceptions. Given that, there is
no point in continuing this discussion.