[side note: I run Tor middle-nodes and bridges, although I do not have the intestinal fortitude -- or a suitably supportive ISP -- to run an exit node]
On Mon, Feb 17, 2020 at 10:35:45AM +0100, Benoit Panizzon via mailop wrote: > Occasionally, spam or more often, log-in attempts and dictionary > attacks on the submission ports of the spamtraps are detected from TOR > exit nodes. So a feedback is sent to the abuse-c. > > Now I got into discussion with the operator of several TOR exit > nodes. He claims that his ISP threatened to disconnect his TOR servers > because they were subject to a couple of abuse complaints from our > spamtraps. [...] > He told me that his ISP did not care what service he operates and for > them, only the count of complaints is the criteria to get disconnected. Running a Tor exit node is always going to attract abuse complaints of varying degrees of validity and severity, so if this exit node is at an ISP which is not supportive of Tor exit nodes and will terminate service based on complaints, it's not going to last long, regardless of whether you are sending abuse reports. > As he has no way to block the abusers on the TOR network, without > completely blocking any ports involved in email abuse which would > render using email sending over TOR unusable if all TOR exit node > operators would block those ports. As has already been mentioned, the default exit node policy does not include port 25, so if this exit node is allowing connections to port 25, the operator has configured it that way... and probably shouldn't have, given their ISP's complaint handling policies. Given that Tor exit nodes would have appalling IP reputation, I'd expect very few SMTP servers would accept mail for delivery, so I have trouble imagining that a Tor exit node should really allow connections to port 25. Submission and POP3/IMAP ports, on the other hand, would be useful to access via Tor. Anonymous access to mail accounts (or even just unblocked access, from networks that have restrictive outbound policies) is undoubtedly handy. On the other hand, of course, it attracts a certain amount of abuse, but then again so do open proxies, compromised machines, and a whole host of other places, so networks have to have defences against all of them anyway -- Tor isn't special in that regard. At the end of the day, I think it comes down to your level of desire to support the Tor network and its mission. If you decided to just ignore its existence and keep sending abuse reports, I think that's a perfectly defensible position -- it *is* abuse, even though your report has no chance of stopping the abuse happening (because of the nature of the Tor network). Causing an exit node shut down due to your abuse reports is not *great*, but as I said earlier, plenty of other abuse reports will be coming in as well, so yours won't be the *only* reason it goes down. On the other hand, since you *know* that the abuse reports won't be actioned (because they *can't* be, in any meaningful sense), not sending reports about activity from known Tor exit nodes is also a reasonable position to take. Whether you "special case" Tor exit nodes in your reporting code, or just stop the abusive activity by firewalling off Tor exit nodes, or use some other method, is down to personal taste. It'll save you the angst of dealing with cranky Tor node operators, and I suppose there's an infinitesimal chance that it'll avoid some node being taken down, if you just happen to be "the straw that broke the camel's back". > But I also see a benefit from our blacklists to list abused TOR exit > nodes. There are two sorts of Tor exit nodes -- those that are being actively used for abuse at the moment, and those that will be Real Soon Now. It's not great, but it's an unfortunate side-effect of providing anonymity. Frankly, if you were feeling up to the job of scripting it, pre-emptively putting all Tor exit nodes which allow connections to port 25 in your RBL would not be a bad idea (exit nodes and their exit policies are publicly available, so you could scrape the list and maintain RBL entries based on it). - Matt _______________________________________________ mailop mailing list [email protected] https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
