[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [tor-talk] TorBirdy seems to connect to the same exit node again and again



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