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

Richard Clayton <> Mon, 30 November 2015 12:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 12B7B1AC3F7; Mon, 30 Nov 2015 04:05:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.353
X-Spam-Level: *
X-Spam-Status: No, score=1.353 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AYnaQ91DCYyk; Mon, 30 Nov 2015 04:05:50 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0BAE51AC3E6; Mon, 30 Nov 2015 04:05:50 -0800 (PST)
Received: from localhost ([]:31046 by with esmtp (Exim 4.86) (envelope-from <>) id 1a3NDH-0008ci-Ds; Mon, 30 Nov 2015 12:05:47 +0000
Message-ID: <>
Date: Mon, 30 Nov 2015 12:04:36 +0000
To: Ted Lemon <>
From: Richard Clayton <>
References: <20151130042819.10658.qmail@ary.lan> <>
In-Reply-To: <>
MIME-Version: 1.0
X-Mailer: Turnpike Integrated Version 5.03 M <bW2$+Pb377P5BNKLWCX+d+VIeV>
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 12:05:51 -0000

Hash: SHA1

In message <>om>, Ted
Lemon <> writes

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

... and one of the things that the ML will be processing will be the
(tokenised contents of the) header fields... so having a pattern (of any
kind) within the header fields has the potential to be extremely helpful
in distinguishing good from bad

>SPF allows me to discard all messages that claim to be from domain X but come 
>from IP addresses not listed for domain X, which means that I never have to 
>write a Received: header for that message.

It rather escapes me how one of your users will be able to determine
whether you received the email from a domain which had SPF at the time
at which you received it unless you record that information along with
the email (or do you think that DNS results are constant for all time?)

If you're relaying the email on to somewhere else then you're assuming
that there's a mechanism by which your policy regarding SPF becomes
known to those other people.

I'm unaware of such a mechanism existing at the moment -- and (this
might be relevant to charters, albeit I really don't think that there's
any real mileage in this topic at all) that although we have a scheme
for originators of email to publish policy recommendations about the
handling of email from their domains we don't have a similar policy for
relaying machines (and absent a Received header field it's unclear to me
what indicator we'd use to look up what that policy was).

>   If there is no SPF for the domain 
>that sent the message, I would like to just discard it as spam, but that's not 
>safe to do because so many small sites don't implement SPF or get it wrong.   
>But in any case where there is no SPF record, the site is definitely not 

that's a shame, I consider myself very trustworthy and I've never
bothered with SPF :-(

- -- 
richard                                                   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

Version: PGPsdk version 1.7.1