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

Chris Lewis <> Sun, 06 December 2015 19:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5CB0B1A899E for <>; Sun, 6 Dec 2015 11:59:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 3.043
X-Spam-Level: ***
X-Spam-Status: No, score=3.043 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sy0y44hIMLeW for <>; Sun, 6 Dec 2015 11:59:57 -0800 (PST)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C70ED1A899C for <>; Sun, 6 Dec 2015 11:59:56 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id tB6JxsnS007992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <>; Sun, 6 Dec 2015 14:59:55 -0500
References: <> <> <05b301d1304c$bf6f3880$3e4da980$>
From: Chris Lewis <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Sun, 6 Dec 2015 14:59:54 -0500
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv: Gecko/20090812 Thunderbird/ Mnenhy/
MIME-Version: 1.0
In-Reply-To: <05b301d1304c$bf6f3880$3e4da980$>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
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: Sun, 06 Dec 2015 19:59:58 -0000

On 12/06/2015 12:37 PM, Christian Huitema wrote:
> 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." 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.

This came out of a thread started on the supposition that this effort 
was only aimed at pervasive monitoring by state actors and that all 
other aspects were out of scope as per RFC7358, including whether it was 
a good idea or not.

1) You can't fight state actors with protocol tweaks.  If a state is 
interested in these headers, they simply have to order providers to 
ignore anything we do.  They already have.

2) State actors have a much easier time of doing this at the network 
level than email headers.  The great firewall of china and the big red 
"disconnect" switch makes such measures as proposed irrelevant.

3) At best this effort becomes a game of whack a mole, where the mole 
gets to scurry around unmolested while "we" take 5 years or more to 
swing the bat each time.

4) I agree that making general improvements to privacy is generally a 
good thing.  But it cannot be if we artificially limit the discussion to 
areas where anything we could do hardly matters in the first place. 
Secondly, the results can be catastrophic failures if we refuse to 
acknowledge the drawbacks in other areas (operational problems, suicide 
prevention, handling of threats of violence, harrassment, or anti-fraud, 
anti-privacy violation efforts).

This work cannot be done in isolation.

> You are making the argument that authorities can commandeer data by imposing
> on mail providers. 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.

Yet, the best/most famous example we have to date is that of a country 
with decent rules of law, it was explicitly made legal, and that 
suppression of the source "address" equivalent (eg: callerid) wouldn't 
have made the slightest bit of difference.  Nor would it with the great 

I contend that relying on, say, a handful of illicit wire connects, 
sporadic access to relay logs, and/or "informer" recipients, is by its 
very definition not "pervasive monitoring", and is thus also 
out-of-scope by the article that began this thread.

For our effort to be useful, the scoping has to be wider, as does the 
considerations of the downsides to doing it.

I shall relate a highly relevant real-world experience: As part of the 
privacy investigation I mentioned in another posting, we were tasked at 
trying to track down a rather prolific sexual harrassment caller who 
seemed to have a surprisingly high level of intimate and accurate 
health/medical detail about the victims.

Over the span of the investigation, we verified more than 1500 (yes, 
1500!) of these calls by one guy, to as many separate individuals (well, 
subtract one, one woman was savvy enough to trick the guy into phoning 
again and taped the conversation).  1500 calls - one guy.  The 
consequences of some of these calls were pretty damaging to the women 
and their families - some were quite traumatised.

[The calls usually started out with the perp identifing themselves as a 
doctor asked to follow up on some sort of gynecological "issue" revealed 
by a recent test/procedure, scaring the women into believing that 
something was seriously wrong, and then getting their jollies by asking 
intimate questions about sexual practises and progressing to worse 
things.  Very very nasty.]

This was before callerid.

I was in the interview where we solidly identified who it was doing it 
(after brainstorming between me, other members of the commission, and 
the LE tasked with running/supervising the effort) and asking a small 
group of female workers in the "common factor" office to see if they 
could identify the voice on tape.

[I was and am still impressed by the sensitivity shown by the senior 
Detective Sergeant of the OPP who led that interview.  The officer asked 
me to be there to act as a technical bridge between him and the office 
staff, and otherwise shut up and be a sympathetic listener.]

It turned out to be a rogue insurance company employee inside a secured 
processing area harvesting the "to be shredded and incinerated" bins. 
Nailed the SOB and the calls ended.  Callerid would have made it so much 

I was never so glad as to see something as the wide-scale deployment of 
callerid a few years later.  The same (occasionally strident and 
emotional) privacy arguments we hear now about MSA submission addresses 
were made then.  Accommodations were made (facilities at threat, per-use 
suppression etc), and how many privacy advocates are tilting at callerid 
these days?  Approximately zero.  We already have the equivalent 
accommodations (tor, anon remailers, etc. etc. etc) that callerid 

Harrassment calls almost completely vanished country-wide despite the 
fact that you could opt-out of callerid.  Unfortunately, I fully expect 
them to have been on the rise again with the wide-spread spoofing of 
callerid that VOIP et. al. makes possible.  Certainly phone spammers are 
doing it already.

Be careful what you ask for, you might get it.