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

"John Levine" <> Mon, 30 November 2015 05:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E96BF1A1EF7 for <>; Sun, 29 Nov 2015 21:52: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 DNZOHJh3q6Pz for <>; Sun, 29 Nov 2015 21:52: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 781281A1BF4 for <>; Sun, 29 Nov 2015 21:52:43 -0800 (PST)
Received: (qmail 18300 invoked from network); 30 Nov 2015 05:52:41 -0000
Received: from unknown ( by with QMQP; 30 Nov 2015 05:52:41 -0000
Date: 30 Nov 2015 05:52:20 -0000
Message-ID: <20151130055220.10923.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 05:52:45 -0000

>  I can't see how what you described could
>possibly scale to anything a large email provider would ever do, ...

This argument is going into the weeds.  The question is whether the
information in Received headers is useful for mail system management
(which is not a synonym for spam filtering) and your apparent
assertion that it only matters what giant mail systems do is pretty

> Do you seriously think that Google has special-case header parsing to deal with spam from Cornell students' infected computers? No, they just use machine learning.

Unfortunately, due to NDA's I can't talk about Google's spam

>SPF allows me to discard all messages that claim to be from domain X but come from IP addresses not listed for domain X,

Yeah, we know what SPF does, and the many and wonderful ways that it
doesn't quite do what it's supposed to.  But since nobody has ever
said that we use Received headers for sender authorization, there's
still no point here.

> And if the site _is_ trustworthy, then modulo a few small exceptions
> like Cornell, it's not originating anything that can be reasonably
> identified as spam, because if it could have been reasonably
> identified as spam, it would never have been forwarded.

Aw, come on.  I get plenty of spam from Gmail and Yahoo, all of which
is 100% SPF, DKIM, and DMARC compliant and has 100% real Received
headers.  Unless you are extremely unusual, you do too.  Crooks sign
up for public mail systems to send spam, and on mail systems of all
sizes they steal or guess AUTH credentials to spam through compromised
accounts, or compromise web servers and spam through buggy old
drupal and wordpress setups.

>> We don't use header chains for validation, we use it to figure out who
>> to blame, who to alert, and who to block.
>I don't know who "we" is here.   Is this really how Google, et al., operate?

I can't talk about Google, but I can tell you from direct experience
working around their DMARC damage that some other large mail systems
use Received headers as part of their spam filtering process, which is
not just checking sender authorization.

Some of us go to conferences like MAAWG where we spend a lot of time
talking to people who run all sorts of medium and large mail systems,
and other conferences where we talk about security problems and
responses to them with various combinations of cops and nerds.  It's
OK that you're not as familiar with all this stuff, just as I am not
as familiar with a lot of the DNS and IPv6 stuff you do.  But you
might consider the possibility that we actually do know something
about the areas in which we work.