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

"John Levine" <> Tue, 01 December 2015 17:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4E3DE1B2B85 for <>; Tue, 1 Dec 2015 09:40:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.037
X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8EtTE-be3BIC for <>; Tue, 1 Dec 2015 09:40:48 -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 288781AD2C0 for <>; Tue, 1 Dec 2015 09:40:48 -0800 (PST)
Received: (qmail 61984 invoked from network); 1 Dec 2015 17:40:46 -0000
Received: from unknown ( by with QMQP; 1 Dec 2015 17:40:46 -0000
Date: 1 Dec 2015 17:40:25 -0000
Message-ID: <20151201174025.18409.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: Tue, 01 Dec 2015 17:40:49 -0000

>Yes, I agree that this is what we are discussing.   I think it's pretty clear that for
>Received header fields that refer to the IP address of the end-user, the answer is "yes,
>there should be such an RFC."   I haven't heard anyone seriously propose that this is not
>true, although I'd be interested to hear such an argument!

Of course there is such an RFC.  RFC 6409 refers to RFC 5321 which
describes the content of the Received header in section 4.4.  It
includes the IP address from which the message was received.

If, perhaps, you are wondering if there should be an RFC that updates
that advice to say to do something else, that's totally unresolved,
since nobody yet has made a plausible argument of what to change and
why there would be an overall benefit from doing so.

Until we look at the actual costs and benefits, it's grossly premature
to propose any changes.