Re: [Shutup] [ietf-smtp] Proposed Charter for something
Chris Lewis <ietf@mustelids.ca> Thu, 10 December 2015 17:50 UTC
Return-Path: <ietf@mustelids.ca>
X-Original-To: shutup@ietfa.amsl.com
Delivered-To: shutup@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C971A90AC; Thu, 10 Dec 2015 09:50:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xC7rEC6qEdV; Thu, 10 Dec 2015 09:50:50 -0800 (PST)
Received: from stoat.mustelids.ca (unknown [174.35.246.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38D331A90C5; Thu, 10 Dec 2015 09:50:49 -0800 (PST)
Received: from [192.168.0.6] (badger.mustelids.ca [192.168.0.6]) (authenticated bits=0) by stoat.mustelids.ca (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
To: ietf-smtp@ietf.org
References: <20151208204227.62714.qmail@ary.lan> <56689A81.7030401@dcrocker.net> <a6568f3a-a788-4006-bca2-94dc26c2be32@gulbrandsen.priv.no> <20151210144814.GA16386@lapsedordinary.net> <55103b70-ca39-4694-92dc-07a17344d485@gulbrandsen.priv.no> <5669A568.6000907@mustelids.ca> <20151210171122.GB27258@lapsedordinary.net>
From: Chris Lewis <ietf@mustelids.ca>
X-Enigmail-Draft-Status: N1110
Message-ID: <5669BB77.2030000@mustelids.ca>
Date: Thu, 10 Dec 2015 12:50:47 -0500
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666
MIME-Version: 1.0
In-Reply-To: <20151210171122.GB27258@lapsedordinary.net>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/shutup/ESTAsCFBuEeFLWxNiky_m9hDtZI>
Cc: shutup@ietf.org
Subject: Re: [Shutup] [ietf-smtp] Proposed Charter for something
X-BeenThere: shutup@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SMTP Headers Unhealthy To User Privacy <shutup.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/shutup>, <mailto:shutup-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/shutup/>
List-Post: <mailto:shutup@ietf.org>
List-Help: <mailto:shutup-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/shutup>, <mailto:shutup-request@ietf.org?subject=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; Precisely. > 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 node. > 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.
- Re: [Shutup] [ietf-smtp] Proposed Charter for som… John Levine
- Re: [Shutup] [ietf-smtp] Proposed Charter for som… Martijn Grooten
- Re: [Shutup] [ietf-smtp] Proposed Charter for som… Dave Crocker
- Re: [Shutup] [ietf-smtp] Proposed Charter for som… John C Klensin
- Re: [Shutup] [ietf-smtp] Proposed Charter for som… John Levine
- Re: [Shutup] [ietf-smtp] Proposed Charter for som… Martijn Grooten
- Re: [Shutup] [ietf-smtp] Proposed Charter for som… Richard Clayton
- Re: [Shutup] [ietf-smtp] Proposed Charter for som… Martijn Grooten
- Re: [Shutup] [ietf-smtp] Proposed Charter for som… Martijn Grooten
- Re: [Shutup] [ietf-smtp] Proposed Charter for som… Steve Atkins
- Re: [Shutup] [ietf-smtp] Proposed Charter for som… Richard Clayton
- Re: [Shutup] [ietf-smtp] Proposed Charter for som… Chris Lewis
- Re: [Shutup] [ietf-smtp] Proposed Charter for som… Hector Santos
- Re: [Shutup] [ietf-smtp] Proposed Charter for som… Christian Huitema
- Re: [Shutup] [ietf-smtp] Proposed Charter for som… Chris Lewis
- Re: [Shutup] [ietf-smtp] Proposed Charter for som… Christian Huitema