Re: [Shutup] [ietf-smtp] Proposed Charter for something

Chris Lewis <> Thu, 10 December 2015 17:50 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D7C971A90AC; Thu, 10 Dec 2015 09:50:55 -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 7xC7rEC6qEdV; Thu, 10 Dec 2015 09:50:50 -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 38D331A90C5; Thu, 10 Dec 2015 09:50:49 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id tBAHolsN005267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 10 Dec 2015 12:50:47 -0500
References: <20151208204227.62714.qmail@ary.lan> <> <> <> <> <> <>
From: Chris Lewis <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Thu, 10 Dec 2015 12:50:47 -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: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Shutup] [ietf-smtp] Proposed Charter for something
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: Thu, 10 Dec 2015 17:50:56 -0000

On 12/10/2015 12:11 PM, Martijn Grooten wrote:
> On Thu, Dec 10, 2015 at 11:16:40AM -0500, Chris Lewis wrote:
>> There really are no technical differences whatsoever between a
>> blackhat and a whitehat trying to protect their identity. The ONLY
>> saving grace is that (in the spam space) the blackhat is forced to
>> resort to methods that scale high enough for an adequate ROI, while
>> the whitehat usually doesn't care that much.
> Most spam filtering - again used in the broad sense - only cares about
> the identity of the sending organisation (ISP, company, etc.). And
> sometimes not even that. If an email body matches some (fuzzy)
> signature, it gets blocked, often regardless of who sent it from where.

I would contend that very little spam filtering cares what the identity 
is at all.  The identifier tokens just being more grist for the 
filtering engine that may help or may not.

For example, Bayes doesn't care what the words it scans mean, it looks 
for statistical similarity with stuff it knows is bad and stuff it knows 
is good.

> It's only when said organisation doesn't do a good enough job of
> checking the identity (or the hat colour) of the sender, that being able
> to find the actual sender matters to everyone else.

Or, sometimes, when you're trying to figure out where it's going to pop 
up next and/or warn providers of the toxic customer.

>> Tor, for example, being a case in point.  Tor would be ideal for
>> spam. And it was for a bit.  Slow, but worked.  I don't know whether
>> the fact that the tor network became so slow as to be unuseable, or
>> that the screams from the "spammed" turned the day, but so few tor
>> exit nodes support outbound port 25 nowadays that it isn't a big
>> problem.
> If they hadn't all blocked that port (it's the default, I believe)

Newbie ;-)  It wasn't always that way.  How do you think that came to be 
that way?

> then every DNSBL would add the exit nodes;


> Tor, by design, doesn't hide the
> nodes' IP addresses and it's easy to check if a certain IP address is
> or was a Tor exit node at a given time.

The aforementioned boilerplate describes that in copious detail so as to 
make it easier for the DNSBL operator to use their exit node list to 
whitelist them unconditionally no matter what comes out of them.

Er, no.  We're very polite.  We have boilerplate for that too.

They also get told that at least we don't treat tor nodes any 
differently than any other, and a reminder to not co-locate a tor node 
with their own servers/network and thus share the reputation of the exit 

> If being able to hide (the geolocation of) your submission IP address is
> of vital importance, then this is the way to use email. For most people,
> this isn't necessary, but it is my belief that at the very least we
> should help organisations that wish to protect personal data for all of
> its users to do so in a way that doesn't seriously harm the existing
> email infrastructure.

The tor "group" had to make a similar decision, when it came to the 
serious harm to the viability of their own infrastructure by what, at 
the time, was unfettered spam.

I2P is going through a similar revolution now - going from a theology of 
the "bits must be free and more importantly private" to a realization 
that their future relevance relies on not becoming an infamous source of 
harm.  They have to come up with innovative ways to preserve what they 
want it to be, in the face of those wishing to pervert it to being a 
safe haven conduit for their abuse.