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

"John Levine" <> Mon, 30 November 2015 03:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D17E31A00C0 for <>; Sun, 29 Nov 2015 19:24:10 -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 pZPGQZSlgdO9 for <>; Sun, 29 Nov 2015 19:24:10 -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 BE9FE1A0091 for <>; Sun, 29 Nov 2015 19:24:09 -0800 (PST)
Received: (qmail 95714 invoked from network); 30 Nov 2015 03:24:08 -0000
Received: from unknown ( by with QMQP; 30 Nov 2015 03:24:08 -0000
Date: 30 Nov 2015 03:23:46 -0000
Message-ID: <20151130032346.10484.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 03:24:11 -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.

Not at all.  If you get mail from a provider you know to be
trustworthy, you can trust the headers they add.  Given that mail is
dominated by large providers, and any individual mail system tends to
exchange mail with the same people over and over, you can cover a
great deal of your mail with a modest number of sort of special cases
for providers you know.  For example, I live near Ithaca NY so I
exchange a lot of mail with Cornell, which is full of students who
never saw a malware-infested game they wouldn't install.  So it's
useful to have scripts that can look at their headers so I can tell
them who needs to be thwacked today.

>the Received: header field needs to contain is a token that can be used to backtrace the message to its origin using the logs:

Um, we have some scaling issues here.  Large providers send and
receive billions of messages a day so looking up stuff in the logs is
non-trivial.  Also, when you're trying to shut down a phish campaign,
you want to do it ideally in minutes, at worst hours, not whenever
someone can get around to pulling some log info from a distant server.

There are a lot of people on ietf-smtp familiar with large mail
systems, so perhaps it would be more productive to ask questions about
how stuff actually works.