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

Ted Lemon <> Tue, 01 December 2015 16:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 60DF71ACE0F; Tue, 1 Dec 2015 08:52:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.912
X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id azhIkGm4pjqm; Tue, 1 Dec 2015 08:52:05 -0800 (PST)
Received: from ( [IPv6:2a01:7e01::f03c:91ff:fee4:ad68]) by (Postfix) with ESMTP id 9C4031ACE07; Tue, 1 Dec 2015 08:51:56 -0800 (PST)
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14489887132630.24058211967349052"
From: Ted Lemon <>
In-Reply-To: <>
References: <20151130042819.10658.qmail@ary.lan> <> <> <> <> <> <> <>
Date: Tue, 01 Dec 2015 16:51:53 +0000
Message-Id: <>
MIME-Version: 1.0
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 16:52:07 -0000

Tuesday, Dec 1, 2015 8:13 AM Paul Smith wrote:
> Once that document exists, then no one will add the trace fields, because people are paranoid (often rightly so, but not, I believe, in this case). They won't read the document fully. It may say 'you can remove IP address information from trace headers, but should think long and hard about it because doing so may come back to bite you and leaving the information in has minimal risk unless you're so stupid you haven't bothered with a firewall'. They'll get as far as the first comma, and stop.

I had no idea RFCs were so powerful.

> To be honest, I'm (pleasantly) surprised IP address information is still put in Received headers nowadays. IMHO, the fact that it is suggests that there's a very good reason for it to stay there.

No, it doesn't.   It suggests that there are one or more reasons why it has stayed there, zero or more of which may be good reasons.

> Many service providers and software publishers 'stretch' the rules somewhat, so if this was a big problem without any down-sides, then IP addresses would have disappeared from Received: headers some years ago.

We are seeing providers right now disappearing IP address information for the submission IP source address, so your logic here would suggest that there is in fact a downside to including that information; otherwise it would not have disappeared.

> If there were compatibility issues (eg some SMTP servers rejecting mail without the IP address info there), then that would still be a problem even if a new RFC comes out, unless SMTP is totally deprecated and a new mail standard replaces it. 

There is no such compatibility issue, because there is no required content in Received: header fields (the only thing that's even strongly recommended is "via") .   There is advice about what should be in them.   People are able to extract data from them anyway, because implementations tend to have default behavior which nobody bothers to change; this behavior tends to follow the examples in e.g. RFC 5821.

>If there are no compatibility issues with removing the IP address, then why aren't most providers/systems already removing it nowadays?

We've already heard that some Email SPs _are_ removing IP addresses in the most obviously problematic case.   The reason they aren't removing IP addresses in more cases is quite likely that they are using stock software (probably Postfix, but could also be MS Exchange or other products) that have default behavior, and they have not been motivated to override the default behavior for cases other than the submit source address case, which has the biggest doxing potential.

Sent from Whiteout Mail -

My PGP key: