Delivery-Date: Tue, 10 Nov 2015 17:22:04 -0500
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED,
	DKIM_SIGNED,FREEMAIL_FROM,RCVD_IN_DNSWL_MED,T_DKIM_INVALID,T_RP_MATCHES_RCVD
	autolearn=ham version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [38.229.72.13])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id 6B64D1E0CAD;
	Tue, 10 Nov 2015 17:22:02 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 4981A37E5F;
	Tue, 10 Nov 2015 22:21:57 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 5C81E37C7E
 for <tor-talk@lists.torproject.org>; Tue, 10 Nov 2015 22:21:51 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at 
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id MkujwE49cGl7 for <tor-talk@lists.torproject.org>;
 Tue, 10 Nov 2015 22:21:51 +0000 (UTC)
Received: from mail-io0-x236.google.com (mail-io0-x236.google.com
 [IPv6:2607:f8b0:4001:c06::236])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (Client CN "smtp.gmail.com",
 Issuer "Google Internet Authority G2" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id 3274837D94
 for <tor-talk@lists.torproject.org>; Tue, 10 Nov 2015 22:21:51 +0000 (UTC)
Received: by iody8 with SMTP id y8so16796638iod.1
 for <tor-talk@lists.torproject.org>; Tue, 10 Nov 2015 14:21:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:from:date:message-id:subject:to
 :content-type; bh=X9d5I8fmO7aXmqpdYiE0owgkAKItzlIZa49pAPuszsg=;
 b=zOGdx0eXBpr8ZIJbR2zF46+1D6Aja8hbZXgkRt21AJIL9G8hGYrJ7au0SXKjPbEf7a
 bk0gW2a0TzZ+mtZSpqWogboEFgSGHewCdy853bdBrWZHPk44JJgOuuQiCz8N/lPu5sLy
 VNMgzkB73qOhPkbhPvZplH/aTE6bofZw4gVXuknkUTVeFk2/66Y98zrLI3rgWwLPxSEX
 9jJWPKIpu3eyy7IyyguxmHbEK/Byz8mcesgEs/L/pCdkzqwoxad1Ior8aDWZbftcQojI
 ykfHZlbq+LaPeI5ZtT/O8Ad5o//vTL61pUJsQnurSaObIKWm7sw1PzUsUH4JxiBeTGCs
 0JGg==
X-Received: by 10.107.40.199 with SMTP id o190mr6554147ioo.17.1447194108889;
 Tue, 10 Nov 2015 14:21:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.36.137.197 with HTTP; Tue, 10 Nov 2015 14:21:09 -0800 (PST)
In-Reply-To: <CAD2Ti2-ynabPCZdwhesxz3Ufh7iL=oFQZm8D5tC7Htime1EsWw@mail.gmail.com>
References: <20151110061812.A5342212@taggart.lackof.org>
 <CAD2Ti2_g81BVSry7P=d6+y3Maj3ihEyckX96MRRKoEZpbvtNFA@mail.gmail.com>
 <20151110075938.ED72B212@taggart.lackof.org>
 <CAD2Ti2-ynabPCZdwhesxz3Ufh7iL=oFQZm8D5tC7Htime1EsWw@mail.gmail.com>
From: grarpamp <grarpamp@gmail.com>
Date: Tue, 10 Nov 2015 17:21:09 -0500
Message-ID: <CAD2Ti28-OQtXKCFypGYxxBC8=MJV41VA0rx=Ctf3727yaqbOjA@mail.gmail.com>
To: tor-talk@lists.torproject.org
Subject: Re: [tor-talk] [bad-relays] relays in spamhaus DROP list
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

Regarding blocking at scale of exits to various services...

  http://www.spamhaus.org/drop/
  http://www.spamhaus.org/faq/section/DROP%20FAQ
  http://www.spamhaus.org/sbl/
  http://www.spamhaus.org/faq/section/Spamhaus%20SBL
  http://www.spamhaus.org/sbl/query/SBL216916
  http://www.spamhaus.org/sbl/query/SBL202964
  https://globe.torproject.org/#/search/query=46.29.248


> But I think this means that relay traffic between the relays listed in DROP
> and providers hidden services (and general Tor nodes, and the dirauth
> server) will be dropped. What does Tor do in that case? Establish a
> different circuit?

The user's app gets a TCP close or reset or stack times out.
There might be an option someday for that, but there's already
a 'new identity' button to do it manually.

>> > I do NOT think the question is:
>> >    Is it OK for spammers to run a Tor relay?
>>
>> Tor is one process. Whatever else is running is another process.
>> I don't think tor's in a position or has desire to dictate other processes.
>>
>> > I think the question is:
>> >    Is it OK for someone to run a relay from IP space from which any
>> >    traffic exiting is likely to be blocked by many routers on the
>> >    internet?
>>
>> Seems a bit of a mixed question of utility vs bad-relays@ malicious
>> sort of thing. The tor-relays@ list, and the metrics of tor, bwauths,
>> etc tends to help with utility and nonsense configuration issues.
>>

>>> whipped up a quick python script(attached) that grabs the DROP list and
>>> compares it with the relay list and that turned up a two more, here's the

>> > I think a good first step would be to setup something like his script
>> > in a cronjob/nagios check/etc and have it alert when relays are using these
>> > IP ranges. Then a human could look at them and decide what to do. It may be
>> > enough to block a few, or maybe it turns into wack-a-mole, who knows.
>>
>> I'd do two things...
>> 1) As you and he suggested... get a handle on how many relays are
>> on which lists and why. See RBL removal DontBlockMe doc here...
>>
>> https://trac.torproject.org/projects/tor/wiki/org/projects/DontBlockMe
>>
>> 2) But not assume that they have no utility just because
>> they can't use provider. A better guage of that would be
>> to setup accounts on all the mail providers and exitmap
>> mail from all exits through all of them into a testbin at tpo.

Over half the exits support modern SUBMISSION, msmtp.sf.net
would easily test this (with fetchmail or mpop testing pulls)...

wc -l /tmp/25 /tmp/465 /tmp/587
      40 /tmp/25
     532 /tmp/465
     522 /tmp/587
sort /tmp/25 /tmp/465 /tmp/587 | uniq | wc -l
     547

>> If both provider and some overriding number of other
>> mail providers on the net were blocking tor exits
>> then perhaps some action could be taken in the
>> same way as if a particular exit had a port open
>> in their torrc but was blocking it in their packet filter,
>> or it was being blocked by their upstream, both
>> causing lack of utility.
>
> Well it's not just email, the DROP is intended to be used by ISPs and
> backbone providers. Maybe such an availability check should be even more
> generic.

It's worth looking into. I'd guess the percent of exits actually
affected would be quite low. Tier-n backbones don't subscribe
to such things, and last hop ISP's are too small to effect much.
Ie: Many exits and their users would repeatedly notice and report
that some /etc/service was being globally blocked in front of their
exits, mark the hoster (end ISP) on the goodbadisp wiki, etc.
I'm not aware of such quantity of reports. It could also be
that exits are testing their own exit's view first, and moving to
another hoster without reporting if their view sucks before
their exit has time to be used by users.

>> I don't mean they are consciously blocking exits,
>> but that choice is being made to subscribe
>> to a potentially blocky blocklist service.

>> Another option is to import the blocklists
>> into local configs after parsing out exit relays
>> via tordns queries.

> Or reject mail from those relays with a different message like "please use
> the tor hidden service instead".

Other than the web page docs an in-protocol message is a
good notification place too.

Let's see if whoever on tor-talk wants to pick this up as something
to be tested for as a project, then consider what the results mean.
Perhaps for any given "service / app" there will be a certain global
level of utility, less than which exits might then be recommended to
try to resolve it, relocate, or deconfigure that service in torrc.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

