Re: [mailop] Opinions? Email Abuse over TOR Network? (spamtraps)
[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 mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Ideas for possible content for FAQ: "Best Practices for running a mail server"
> On Feb 17, 2020, at 1:18 PM, G. Miliotis via mailop wrote: > > On 17/2/2020 22:39, Luis E. Muñoz via mailop wrote: >> One could state facts – i.e., pointing out that SPF will break straight >> forwarding and mailing lists that do not rewrite – without introducing >> judgement. > > How about a small section in the FAQ about decisions that the mail admin must > make? Such as factors to consider with SPF (in this case), DMARC, quarantine, > RBLs and so on. Let the new guy know what he's getting into, probably early > on in the documentation. If it's too much material, just a mention to get > them started. To me, this will work much better. Best regards -lem ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Ideas for possible content for FAQ: "Best Practices for running a mail server"
On 17/2/2020 22:39, Luis E. Muñoz via mailop wrote: One could state facts – i.e., pointing out that SPF will break straight forwarding and mailing lists that do not rewrite – without introducing judgement. How about a small section in the FAQ about decisions that the mail admin must make? Such as factors to consider with SPF (in this case), DMARC, quarantine, RBLs and so on. Let the new guy know what he's getting into, probably early on in the documentation. If it's too much material, just a mention to get them started. Best regards, --GM ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Ideas for possible content for FAQ: "Best Practices for running a mail server"
On Mon, Feb 17, 2020 at 2:45 PM Luis E. Muñoz via mailop wrote: > Unfortunately, we are operating in a world where legitimate forwarding > is far outweighed by spoofed email and SPF is a response to that. If > forwarding is expected, cooperating mail systems can make arrangements > – i.e., ARC is an attempt to do this at a larger scale – but this > is part of the consensual aspect of email transmission. > > As for SPF-breaking mailing lists, this is likely a self-correcting > problem. ARC would also help with this use case. > > One could state facts – i.e., pointing out that SPF will break > straight forwarding and mailing lists that do not rewrite – without > introducing judgement. Luis is right. SPF is broadly used and in the operational context people need better guidance than "run away." Cheers, Al Iverson -- al iverson // wombatmail // chicago dns tools are cool! https://xnnd.com ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Ideas for possible content for FAQ: "Best Practices for running a mail server"
On 17 Feb 2020, at 11:20, Hans-Martin Mosner via mailop wrote: My personal experience with SPF is that it is less helpful than harmful, at least when mail server operators use it for rejection instead of tagging. It can help reject some mails with fake sender information, but at the same time it prevents some legitimate forwarded mails from getting through. And this is a decision of the sending mail system. Editorializing on this does not help. Many of us have personal experience that shape our own decision making process. Those experiences don't necessarily map well to others'. Unfortunately, we are operating in a world where legitimate forwarding is far outweighed by spoofed email and SPF is a response to that. If forwarding is expected, cooperating mail systems can make arrangements – i.e., ARC is an attempt to do this at a larger scale – but this is part of the consensual aspect of email transmission. As for SPF-breaking mailing lists, this is likely a self-correcting problem. ARC would also help with this use case. One could state facts – i.e., pointing out that SPF will break straight forwarding and mailing lists that do not rewrite – without introducing judgement. Best regards -lem ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Ideas for possible content for FAQ: "Best Practices for running a mail server"
Am 17.02.20 um 19:21 schrieb Alessandro Vesely via mailop: > On Sun 16/Feb/2020 15:21:34 +0100 Hans-Martin Mosner via mailop wrote: >> (opinionated) Don' use SPF, it's broken by design. > > I don't think that a FAQ starting with such opinionated entries is going > anywhere. > > > Best > Ale I deliberately did not start the list with this, instead put it as the last point because I know opinions differ on this topic. A public FAQ should probably not be place this into the "agreed-upon best practices" but the "controversial opinions" department. My personal experience with SPF is that it is less helpful than harmful, at least when mail server operators use it for rejection instead of tagging. It can help reject some mails with fake sender information, but at the same time it prevents some legitimate forwarded mails from getting through. I do know about SRS, even had it running some time ago, and if someone wants to run it to improve deliverability of forwarded mail that's perfectly fine with me. But if you run a mail server and your users aren't getting mails forwarded from their accounts on other mail servers because you reject based on SPF, you're not exactly helping deliverability. Cheers, Hans-Martin ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
[mailop] Suggestions for mailops.org website - forum?
Regarding the suggestion for "content/questions/answers/links to put on the website" - have you ever considered making this mailing list into a forum? I just like discussion forums a lot better than I do discussion mailing lists. In my opinion, it's easier to contribute within a forum environment than it is within a mailing list environment. And mailing lists tend have deliverability issues where certain replies get delivered before the original message. That's avoided within forums. Maybe the forums discussion has been had before and I missed it. But just a thought. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Ideas for possible content for FAQ: "Best Practices for running a mail server"
On Sun 16/Feb/2020 15:21:34 +0100 Hans-Martin Mosner via mailop wrote: > (opinionated) Don' use SPF, it's broken by design. I don't think that a FAQ starting with such opinionated entries is going anywhere. Best Ale -- ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Ideas for possible content for FAQ: "Best Practices for running a mail server"
Am 16.02.2020 22:15, schrieb Jaroslaw Rafa via mailop: Dnia 16.02.2020 o godz. 15:21:34 Hans-Martin Mosner via mailop pisze: 1. Don't hide behind anonymity. Mail server domain whois should have an identifiable registrant organization, there [...] 8. (opinionated) Don' use SPF, it's broken by design. 9. If you want to send mail to recipients who have accounts at big email providers, be aware that all of the above cannot guarantee that these providers won't reject your mail, put it straight into recipient's spam folder or just silently discard it - they just impose their own rules on anyone and you virtually can't do anything about it. You're right, following best practices won't guarantee delivery, this is a caveat that should be added to such a list. However, that's just an observation of fact, and if you can't do anything about it, it doesn't belong among the best practices. BTW, in some rare cases, when you have alternative means of contact, notifying the recipients and suggesting they leave their mail-unfriendly provider for a better place may help. Cheers, Hans-Martin ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] correos.es unreachable?
On Mon, Feb 17, 2020, ngel via mailop wrote: > I contacted them in order to warn them about the issue. They are not > aware of any email issue and asked for the destination mailbox that had > problems. I was given the e-mail address correosduap...@correos.es from a local post office and it worked fine from Nov 2019 to end of Jan 2020. I just checked my mailbox again and also found the .com address, so I will use that from now if needed. Many thanks for your help! ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] correos.es unreachable?
Hello I contacted them in order to warn them about the issue. They are not aware of any email issue and asked for the destination mailbox that had problems. The most interesting piece was that they mentioned their email addresses use correos.com not correos.es correos.com does have a working MX: $ host correos.com correos.com has address 13.80.110.246 correos.com mail is handled by 10 smtp.correos.com. Not sure how you could have ended up with the "wrong" domain from a working mail exchange (a badly configured Reply-To:? a legacy domain that is no longer being forwarded to the main one?). Hope this helps. Best regards ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Opinions? Email Abuse over TOR Network? (spamtraps)
Hi, On Mon 17/Feb/2020 10:35:45 +0100 Benoit Panizzon via mailop wrote: > > We operate Spamtraps which feed the SWINOG Anti-Spam Blacklist. > > A feedback loop is sent to the abuse-c of the IP Address from which > email or attackts to spamtraps was detected. > > 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. It must be login attempts, since port 25 is not available to Tor users. > 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. > > 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. For port 25, that's already the case: What about spammers? First of all, the default Tor exit policy rejects all outgoing port 25 (SMTP) traffic. So sending spam mail through Tor isn't going to work by default. It's possible that some relay operators will enable port 25 on their particular exit node, in which case that computer will allow outgoing mails; but that individual could just set up an open mail relay too, independent of Tor. In short, Tor isn't useful for spamming, because nearly all Tor relays refuse to deliver the mail. https://2019.www.torproject.org/docs/faq-abuse.html.en#WhatAboutSpammers For port 587, I too send abuse reports on authentication failures. Only once I happened to get a reply from a Tor operator. Their web sites has a curious faq entry: Emerald Onion Repeat Infringer Termination Policy Emerald Onion does not have subscribers or account holders and cannot identify the IP addresses of individuals who send communications over the Tor network. Nonetheless, it is our policy to terminate the use of Emerald Onion by repeat infringers in appropriate circumstances. https://emeraldonion.org/faq/ Don't ask me how do they identify repeat infringers, I have no idea. However, I get hundreds of bad login attempts, and tens of auto reply follow-up every day. Only one was from Tor, so it seems that they somehow can manage. I heard about Tor users who access imap and submission accounts via Tor just because their University blocks those ports and Tor was the easiest workaround they found. Hence, it's not that it is inconvenient to use Tor. Perhaps, since most of those desperate dictionary attacks seem to come from Owned hosts, low abuse rates are due to Tor operators detecting/ avoiding intrusions better than others...? Best Ale ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Ideas for possible content for FAQ: "Best Practices for running a mail server"
> Either links to existing material or specific stuff written for pages > on would be welcome. Blocking of compromised mail accounts (for Exim): https://github.com/Exim/exim/wiki/BlockCracking ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
[mailop] Opinions? Email Abuse over TOR Network? (spamtraps)
Dear List We operate Spamtraps which feed the SWINOG Anti-Spam Blacklist. A feedback loop is sent to the abuse-c of the IP Address from which email or attackts to spamtraps was detected. 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. 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. I told him to sort this out with his ISP and that his ISP would for sure understand, that he is not himself be the origin of this abuse. 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. So he suggests I use public available TOR exist node lists, to block them from accessing the spamtraps. I understand his claim. But I also see a benefit from our blacklists to list abused TOR exit nodes. So what are your opinions about this? How do other spamtrap / honeypot operators deal with TOR exit nodes? Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G-Leiter Commerce Kunden __ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 PrattelnFax +41 61 826 93 01 Schweiz Web http://www.imp.ch __ ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
