Re: [Shutup] Proposed Charter for the "SMTP Headers Unhealthy To User Privacy" WG

Ned Freed <> Mon, 07 December 2015 16:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6C92C1B384E for <>; Mon, 7 Dec 2015 08:20:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.936
X-Spam-Status: No, score=0.936 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DATE_IN_PAST_12_24=1.049, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Muk8m2IeGmVA for <>; Mon, 7 Dec 2015 08:20:44 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A17B71B384D for <>; Mon, 7 Dec 2015 08:20:44 -0800 (PST)
Received: from by (PMDF V6.1-1 #35243) id <> for; Mon, 7 Dec 2015 08:15:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=mauve; t=1449504939; bh=+pUqDZwGq9bHKHyuE/wEExsNmRX/EYmRkwGu1EOLSc8=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=TxoSNZCIohhqUyxzkYk3dkIyLRTiHaIxWOWWpsURb5XYfQg+ve7RMXvLN4cSeKV1q rMz7/9qpBKrRVKZS0ttw+JMSE2Zvz5cVZWvyKvfpANtcA5MnseXkAgArL6YLBdVg7i hz2hm+fkpBdIf8Fp7qlfDmDCNSN0V3ncY17eExh0=
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Received: from by (PMDF V6.1-1 #35243) id <>; Mon, 07 Dec 2015 08:15:37 -0800 (PST)
Message-id: <>
Date: Sun, 06 Dec 2015 11:31:44 -0800 (PST)
From: Ned Freed <>
In-reply-to: "Your message dated Sun, 06 Dec 2015 09:37:14 -0800" <05b301d1304c$bf6f3880$3e4da980$>
References: <> <> <05b301d1304c$bf6f3880$3e4da980$>
To: Christian Huitema <>
Archived-At: <>
Cc: 'SM' <>, 'Ned Freed' <>,
Subject: Re: [Shutup] Proposed Charter for the "SMTP Headers Unhealthy To User Privacy" WG
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, 07 Dec 2015 16:20:46 -0000

> On Saturday, December 5, 2015 10:52 PM, Ned Freed wrote:
> > SM <> writes:
> >
> > > An attack on organization is a security issue; it isn't a privacy
> > > issue.  The privacy issue is about mail-related metadata which can be
> > > collected by state surveillance agencies.  Will the proposed working
> > > group attempt to fix that?
> >
> > As I pointed out on the perpass list when the Received: field draft was
> first
> > posted, there are definitely privacy issues associated with Received:
> fields,
> > but metadata collection by state actors really isn't one of them. Why
> bother
> > with Received: fields when you can simply collect transaction logs from
> > ISPs/MSPs.

> Ned, you are basically saying, "why bother plugging one leak when the same
> data can leak somewhere else."

Stop. Right. There. In the text you quoted, I said, "there are definitely
privacy issues associated with Received: fields". That in no way, shape, or
form equates to my saying that Received: fields are not worth worrying about.
In fact in this message:

I said:

  ... there is a real privacy gain in not including [IP addresses]
  in messages. State actors with subpeona powers may have easy access to ISP/MSP
  logs, but other players, including legitimate message recipients, do not. And
  my location at the time I send a piece of mail really isn't the concern of any
  of the message's recipients unless I choose to reveal it.

That's almost the exact opposite of the position you claim I held.

You really need to start reading what people are actually saying.

> Well, I think it is actually important to
> plug all the privacy leaks, much like in security it is important to plug
> all the holes.

And if that was the only factor in play it would be a no-brainer to simply
remove the IP addresses. But it isn't the only factor.

> You are making the argument that authorities can commandeer data by imposing
> on mail providers.

That's a statement of fact, not an argument.

> They can, but in countries with decent rule of laws there
> are limits, such as requesting probable cause and not going through fishing
> expeditions. We have seen rogue agencies attempt to bypass these limits by
> just taking the data whichever way they can, and we want to stop that. We
> also worry that what these agencies can do today, organized gangs can do
> tomorrow, and petty criminals after that.

The claim has been made - and still is made in the draft under consideration - 
that IP addresses in  Received: field are of significant value to state actors
and should be removed for that reason alone. But that claims fails because
state actors have the ability to get a better version of that information from
transaction logs.

Unless you can demonstrate that state actors have an easier time going after
message content - and that's demonstratably false in the United States and
probably most of other jurisdictions - the specifics of what restrictions apply
to state actors overall are entirely irrelevant.

And once again, this does *not* constitute an argument that there aren't
*other* privacy implications for IP addresses in Received: fields that are
worth considering. It's an argument against a specific claim that has been and
continues to be made.

> The email traces are particular because they are carried to multiple places,
> not just the submission site but also every relay and every mail recipient.
> That multiplies the chances of compromise. My email provider has some reason
> to try maintain my trust, but relays and recipients may not. For me, it
> makes a great deal of difference whether the information can be obtained
> from just one place or from many.

Yes, I believe I have some small awareness of how email works.

> As I wrote in a previous message, we have a specific problem with the
> correlation between IP address and user identity. Once that correlation is
> established, it becomes possible to attribute 5-tuple traces to specific
> individuals. You may think that the relation between someone's home IP
> address and their identity is static, but in many case it is not. Some ISP
> can provide you with addresses that deliberately vary over time. You can use
> VPN. You can use Wi-Fi hot spots. That's exactly what privacy conscious
> users do. And that's why I find the listing of submission IP in traces
> problematic.

And I also believe I have some small awareness of how modern networking

> I understand that there are good use of the information, and that managing
> email systems is hard.

Except that you apparently refuse to acknowledge it, preferring instead to put
words in other people's mouths, not to mention assuming they don't understand
the most basic operational characteristics of modern email.

Even more important, you also apparently refuse to acknowledge some of those
uses have significant privacy implications of their own. A lot of people here
are saying that the inclusion of IP addresses in Received: fields is of
use in shutting down phishing attacks. And phishing is tremedounsly damaging
to user privacy.

So what we have here is a tradeoff. On the one hand, if we include client IP
addresses in Received: fields, we leak information about message senders which
may be exploited by message recipients, service providers etc. (but not state
actors). But on the other hand, if we don't include client IP information, we
make it harder to prevent spam and phishining attacks from reaching mail
recipients, which when those attacks are successful - as some percentage always
are - utterly compromises user privacy.

And this is going to be a very difficult tradeoff to weigh for a bunch of
reasons. For one thing, it's something of an applies to oranges comparison - a
small loss of privacy for a large group in aggregate is difficult to compare to
a major loss of privacy to a much smaller group. And that's assuming we can
find the means of assessing the sizes and characteristics of the groups. And in
the case of phishing attacks, if the past is any indication, the efficacy of
using a particular piece of information like client IP is going to change over
time as attackers change their strategy.

But none of this is helped by your failure to actually read what other people
are saying, and your frankly insulting assumptions that I don't understand
the most basic principles of how email and networks work.