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

"John Levine" <> Mon, 30 November 2015 04:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 391E31A871D for <>; Sun, 29 Nov 2015 20:28:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 2.667
X-Spam-Level: **
X-Spam-Status: No, score=2.667 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=1.004, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id I7KG4_cuE5pv for <>; Sun, 29 Nov 2015 20:28:43 -0800 (PST)
Received: from ( [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 282841A871B for <>; Sun, 29 Nov 2015 20:28:43 -0800 (PST)
Received: (qmail 5198 invoked from network); 30 Nov 2015 04:28:41 -0000
Received: from unknown ( by with QMQP; 30 Nov 2015 04:28:41 -0000
Date: 30 Nov 2015 04:28:19 -0000
Message-ID: <20151130042819.10658.qmail@ary.lan>
From: "John Levine" <>
In-Reply-To: <>
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
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 04:28:44 -0000

>> Spam filters have been doing Received chain analysis for about 20 years.
>Yes, I know.   A friend of mine founded a company that worked using this principal.   Unfortunately, it got less and less effective as
>spammers got better and better at faking things.   The reason I asked for recent experience is that I'm curious if anyone is _still_
>getting real benefit from this.

Yes.  See the message you just replied to.

>Since the only header-field you can actually trust is the first one that your own MTA adds, ...

No, that's not correct.  See recent message.

SPF works just as well (actually, a _lot_ better) as a validation mechanism.

What?  Header chains say "this message came through this IP".  SPF
says "I assert that these IPs are allowed to send mail for this
domain."  They're completely unrelated.

We don't use header chains for validation, we use it to figure out who
to blame, who to alert, and who to block.