Delivery-Date: Fri, 24 Apr 2015 04:26:14 -0400
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.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
	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 33D0B1E01AE
	for <archiver@seul.org>; Fri, 24 Apr 2015 04:26:12 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 3C35635172;
	Fri, 24 Apr 2015 08:26:08 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id CB7743516D
 for <tor-talk@lists.torproject.org>; Fri, 24 Apr 2015 08:26:03 +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 gV78Gy97j4Bp for <tor-talk@lists.torproject.org>;
 Fri, 24 Apr 2015 08:26:03 +0000 (UTC)
Received: from dd15500.kasserver.com (dd15500.kasserver.com [85.13.136.184])
 (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
 (Client did not present a certificate)
 by eugeni.torproject.org (Postfix) with ESMTPS id 7C4C535168
 for <tor-talk@lists.torproject.org>; Fri, 24 Apr 2015 08:26:02 +0000 (UTC)
Received: from 127.0.0.1 (tor31.anonymizer.ccc.de [217.115.10.131])
 by dd15500.kasserver.com (Postfix) with ESMTPSA id 8D3825CE00A3
 for <tor-talk@lists.torproject.org>; Fri, 24 Apr 2015 10:25:58 +0200 (CEST)
Message-ID: <5539FE14.8040503@sophiehassfurther.com>
Date: Fri, 24 Apr 2015 08:25:56 +0000
From: Sophie Hassfurther <sophie@sophiehassfurther.com>
MIME-Version: 1.0
To: tor-talk@lists.torproject.org
References: <20150416215238.37FBBC03DD@smtp.hushmail.com>
 <55315DC9.50802@sophiehassfurther.com>
 <20150424000609.73C53E04DA@smtp.hushmail.com>
In-Reply-To: <20150424000609.73C53E04DA@smtp.hushmail.com>
Subject: Re: [tor-talk] TorBirdy seems to connect to the same exit node
 again and again
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>

Hi Leeroy,

Yes, Atlas was a poor choice. Before you suggested searching the log
through Terminal, I wasn't even thinking of that possibility.

As for improvements: I think a) would be quite important. Using a better
port worked, as far as I can tell, and I was not aware that I put myself
in a very bad position when choosing port 25. But then my life is not
depending on TorBirdy, while other peoples' lives do, so maybe a hint in
the "Before using TorBirdy" advice or a warning message from within
TorBirdy could help those who are not tech-savvy.

Options b) and c) would be very luxurious, but option a) really solved
my problem, and seems quite important for those who come from a
different background.

Other things that come to mind:
"Test proxy settings" could be somewhere more prominent, for users like
me :) I am the kind of person that does not disable the warning message
that pops up when clicking on the TorBirdy preferences.

I am -manually- logging what exit ports TorBirdy uses, out of curiosity.
I will keep you posted in case something weird happens again.

Thanks for the help!
Sophie



l.m:
> Hi Sophie,
> 
> Hmm...Perhaps Atlas isn't the best choice here. At any given time the
> exits you can choose from are those you know of locally. It might be
> better to focus on TorBirdy instead. 
> 
> When using Tor Browser, the tor process is kind enough to take notice
> when using certain ports (WarnPlaintextPorts). So maybe TorBirdy
> should do the same. That is to say, make TorBirdy more verbose about
> choices for mail server port. Had you been warned that port 25 is not
> the port you're looking for you might have chosen differently. Even if
> the port was chosen temporarily, a reminder could've helped. To make
> things worse you have to switch between TorBirdy and Tor Browser to
> change identities. Then you have to run something like
> check.torproject.org to ensure your ip is different from a
> (potentially blocked) previous ip.
> 
> So things TorBirdy could do better to avoid this problem in the future
> include:
> a) Be more verbose about choosing the mail server port. Possibly
> include a reminder which can be disabled. Warn when making a hazardous
> choice such as 25. A known abuse port and one which is blocked in the
> default exit policy and reduced exit policy.
> b) Provide new identity functionality in TorBirdy. It would need to be
> careful not to "step on the toes" of Tor Browser. To this end it could
> emulate the NEWNYM signal by leveraging stream isolation. New
> identities triggered by TorBirdy would create streams isolated from
> previous streams. By tracking streams associated with mail servers
> TorBirdy can ensure old connections are closed before new ones. It can
> do this in a way such that no interference occurs with Tor Browser.
> c) Enable TorBirdy to configure use of TrackHostExits/Expire. Purely a
> preference to deal with Tor Browser triggering a new identity when you
> might prefer to have TorBirdy continue to use the last exit for a
> time. If you've triggered a new identity in TorBirdy to avoid a
> blocked exit this could also mitigate the problem of a blocked exit
> being reused. Is there a better way to achieve the same result here?
> 
> Comments, suggestions, criticisms?
> 
> --leeroy
> 

-- 
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

