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

Jim Fenton <> Sun, 29 November 2015 22:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B96C11B384A; Sun, 29 Nov 2015 14:53:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.985
X-Spam-Status: No, score=-1.985 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_71=0.6, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5n0CfJehtwIk; Sun, 29 Nov 2015 14:53:43 -0800 (PST)
Received: from ( [IPv6:2607:f2f8:a994::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1551C1B3847; Sun, 29 Nov 2015 14:53:43 -0800 (PST)
Received: from [IPv6:2001:470:1f05:bfe:a06d:6a7c:4078:aebf] ([IPv6:2001:470:1f05:bfe:a06d:6a7c:4078:aebf]) (authenticated bits=0) by (8.14.3/8.14.3/Debian-9.4) with ESMTP id tATMrfPA024552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 29 Nov 2015 14:53:42 -0800
References: <alpine.OSX.2.11.1511282155180.1479@ary.lan> <> <Eoqbyz/axxwfm7I0m8X7QOm53qcBtCJIuS/> <> <>
From: Jim Fenton <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Sun, 29 Nov 2015 14:53:40 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------070004060306030506090107"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=supersize; t=1448837622; bh=Sgg9krUwaXPkP+Jq1Kayd7nsI+zlMaff++YhhTxRhd4=; h=Subject:To:References:From:Date:In-Reply-To; b=cVGlQurlmkeLtRvzFkvIpnU9ONhj8vxBgZx2uVYDSYpYfLPCzy12BriqFBKg/o3Bb 18tD5u6EXNNixqxFlgiJeA0esdwdfF3F5ruJCuhnkL8Gr1sTgAxrKQ1R+dhMt3PyYU YvRaoeLxoJrn0v+AJBaiq3/N6JHw/7vRUZFnUN00=
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: Sun, 29 Nov 2015 22:53:44 -0000

On 11/29/2015 09:12 AM, Chris Newman wrote:
> I oppose the current shutup charter text
> and draft-josefsson-email-received-privacy as both promote the
> elimination of mechanisms that protect users from fraud and abuse.

Agreed, and to be more specific:

The proposed charter speaks of Received header fields leaking address
information that can expose user location. Yes, they can. But, in
general, that information is essential to identifying spoofed header
fields: it's by tracing the chain of "from" addresses in Received header
fields that one can determine that someone is attempting to do something
fraudulent. Further, I don't have a lot of sympathy for organizations
that rely on the secrecy of their network topologies as an essential
security component. We're trying to increase the trust in email, not
reduce it.

There are users for whom their privacy is critically important, such as
press informants in totalitarian societies. There are many other ways to
determine their location (network monitoring coupled with a STARTTLS
downgrade attack, for one), and it would be harmful (potentially
life-threatening) if anyone thought that this would truly protect them.
They should be using something like SecureDrop and not using email at all.

draft-josefsson-email-received-privacy mentions the issue of senders'
locations appearing on mailing lists and in mailing list archives. I
have long felt that we are conflicted on whether the output of a mailing
list is a new message or the same as the one sent to the mailing list.
It usually has a different MAIL FROM address, and often has text added
to the message body, which I would think is enough of a change to make
it a new message. Yet the Message-ID and Received header fields are
preserved. I would think that an entire new message should be created,a
new Message-ID assigned, and DKIM signed by the mailing list's domain
(of course!). Only selected header fields would be transferred to the
new message. The original incoming header fields should be available
only to the list administrators, who deal with abuse issues.

What would the motivation be for anyone to implement any header privacy
improvements? There is far too much deployed infrastructure to get a
change to be made, absent a very strong business case. We could spend a
lot of time on this and not have it matter a bit.

I would support some work on the mailing list issue resulting in a set
of recommended practices, and possibly guidance on obscuring the source
IP address when an authenticated submission is made to an MSA. But
that's it.