Re: [tor-relays] Leaseweb exit relay notice

The problem is compounded by the fact each BL company is racing it's way to the bottom, adding each others finds to their own lists. SpamHaus has OVER 1 *BILLION* addresses listed.
I lost several relays (11) from OVH because DanTor recorded my relays, then CBL recorded DanTor, then SpamHaus Zen recorded CBL, which allowed OVH to claim "100% of your IPs are blacklisted on multiple lists" when in reality it was from a guy in the UK who publishes all Tor relays
On 05/22/2015 12:19 AM, Speak Freely wrote: -
guard, middle, exit - that caused this whole problem for me. Not one single complaint from anyone against any of my relays.
Matt Speak Freely _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
A lot of trouble would be prevented for exit node operators if, when they brought their relays up for the first time, they ensured that the exit policy rejected port 25. Even if they desire to run as unrestricted a relay as possible, in my experience, that one really should be rejected. It is the port which email servers tend to use to deliver mail to one another, and some bad/old clients might try to use it as well. In theory, open-relay port 25 is just about sending email. It can send email on behalf of anyone in the world. Big deal, right? But in practice, open-relay port 25 is all about spam. Has been for years and years. It's always been abused by awful spammers wherever it may be found. It's never been used as some great tool for anonymity or email freedom. As far as Tor exits go specifically, there is someone out there who is apparently watching Tor for when exits appear that are willing to send on port 25. They very quickly begin dumping spam out of any such relays, should they appear. I know this because I briefly turned on relay for port 25, and the spammers found it fast. They immediately transformed it into a spam-vomiting heap of crap. Traffic graphs on it skyrocketed (although within the configured maximums). The new mail in the admin mailbox for the netblock clearly reflected what the box was doing. I closed that port off fast, and problem solved. In addition to port 25, relay operators who want to be extra careful of their relationship with their ISP may also wish to reject ports 465 and 587. Doing that would more-completely lock the Tor exit away from the tricks spammers use. By blocking off the email portion of the relay (especially port 25), the machine doesn't spew spam, and therefore doesn't get noticed by those who are trying to stop spam. This is good for the relay because the 'net is more accepting of it (IP reputation lists, RBLs, etc), and good for the exit relay operator's working relationship with the hosting ISP. Reputable ISPs tend to dislike spam, and if a billion spam complaints flood in for your relay, it's not going to help your cause. People who are trying to do anonymous email have means to do so which do not include dumping anything directly to port 25. And if a direct push from Tor to 465 or 587 is wanted, it can always go to the relays which don't perceive any ISP-related risk from it.

++ 25/05/15 12:48 -0400 - tor@t-3.net:
A lot of trouble would be prevented for exit node operators if, when they brought their relays up for the first time, they ensured that the exit policy rejected port 25. Even if they desire to run as unrestricted a relay as possible, in my experience, that one really should be rejected. It is the
Some (or most or even all) of the Leaseweb nodes didn't forward port 25. So, alltough you advice is a good one, it's not applicable to some (or most or even all) of the nodes that are discussed in this thread. -- Rejo Zenger E rejo@zenger.nl | P +31(0)639642738 | W https://rejo.zenger.nl T @rejozenger | J rejo@zenger.nl OpenPGP 1FBF 7B37 6537 68B1 2532 A4CB 0994 0946 21DB EFD4 XMPP OTR 271A 9186 AFBC 8124 18CF 4BE2 E000 E708 F811 5ACF Signal 0507 A41B F4D6 5DB4 937D E8A1 29B6 AAA6 524F B68B 93D4 4C6E 8BAB 7C9E 17C9 FB28 03
participants (2)
-
Rejo Zenger
-
tor@t-3.net