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

Ted Lemon <> Tue, 01 December 2015 17:29 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B9D301B2B7F; Tue, 1 Dec 2015 09:29:22 -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 UlWq_KpLVMwM; Tue, 1 Dec 2015 09:29:21 -0800 (PST)
Received: from ( [IPv6:2a01:7e01::f03c:91ff:fee4:ad68]) by (Postfix) with ESMTP id 0E1D81B2B79; Tue, 1 Dec 2015 09:29:19 -0800 (PST)
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14489909566920.23402652656659484"
From: Ted Lemon <>
In-Reply-To: <>
References: <20151130042819.10658.qmail@ary.lan> <> <> <> <> <> <> <> <>
Date: Tue, 01 Dec 2015 17:29:16 +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 17:29:22 -0000

Tuesday, Dec 1, 2015 12:11 PM Steve Atkins wrote:
> > On Dec 1, 2015, at 8:54 AM, Ted Lemon <> wrote:
>> Tuesday, Dec 1, 2015 7:27 AM Arnt Gulbrandsen wrote:
>>>> Sure, but in this case wouldn't deferring to the end systems> argue in favor of allowing end systems to make the decision as> to whether their private information should be exposed?
>>> As I see it, that's not the question here. The question is: Should there be an RFC that can be used/misused to apply pressure regarding trace fields etc?
>> 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!

> When people routinely hide their identities - to the extent that a recipient cannot tell that two emails were sent by the same person - that eliminates many social and technical pressures on bad behaviour. But it *also* removes the ability for people to help them when their endpoints have been compromised.

Your entire argument relies on this point, so I will just respond to this one point; I don't disagree with what you say afterwards, but I think that you are wrong in suggesting that obfuscating the Received: header field for the email submission causes the problem you say it does.

The claim you have made is that the person submitting the email is hiding their identity, but this is not the case.   First, they have to prove their identity in order to submit the mail in the first place, most likely.   Secondly, their IP address is visible to the submit server, and is likely logged.   It is the submit server that, we are theorizing, should hide their identity.

The entity responsible for providing support to _that person_ is the entity that operates the SMTP submit server.   That entity knows the end user's identity, and knows what IP address they used to submit the email.   So they are not prevented from providing the support that you rightly say they should provide.

It is certainly true that if the submit server is not operated by a responsible entity, then we have a problem.   The right fix for that problem is probably something similar to what John has said AOL did in a similar situation: start greylisting mail from that provider so that the high rate of spam chokes their queues, and they will start to be more proactive in addressing problems.

There is no need to violate the privacy of legitimate end-users who are doing nothing wrong in order to address this problem.

Sent from Whiteout Mail -

My PGP key: