I usually report them via Spamcop and add their IPs and/or domain names into our local blocklist. If this causes issues with legitimate mail from them, they can use the link that we give in every SMTP error reply to contact us. I just don't have time to educate mail ops who didn't request it.
Cheers, Hans-Martin Am 3. Februar 2025 10:53:09 schrieb Doug via mailop <mailop@mailop.org>: > About 24 hours ago, I started receiving hundreds of "failure notice" > emails from an external mailer daemon. > > I was concerned that this was due to some kind of compromise on my > server. It was not - nothing weird with logins or anomalous IPs or > anything that would indicate compromise on our end. The sending server > has compromised accounts. Those compromised accounts are forging the > return path, from address, and message ID. > > It's backscatter from a phishing campaign. At first, I tried to contact > the server owner through their abuse@ account. They have us blocked for > ... "sending spam". (is this characteristic? do blocklists not do SPF > verification? can someone just send a bunch of emails with forged return > paths and from addresses to get them added to a blocklist? seems very > easy to abuse) > > They eventually did respond today after the several calls I had made an > hour or two into the backscatter attack. The problem has subsided > slightly, but I'm still getting a few failure emails every minute. These > aren't emails from Pooping Secret about Ancient "Poop Hack" From Japan, > but rather an ISP. > > What is The Way™, if any, to deal with backscatter? It doesn't seem like > there is a turnkey BATV solution for Postfix. I was considering writing > a Milter to do it, but I have no idea if it's even worth trying. > > I did end up adding the backscatterer RBL, which at least sends these > emails to spam. It does remind me of why I don't really like UCEPROTECT > blocklists, though - they're very adamant about having my server on the > list because it's in a "bad neighborhood", but this ISP sending > thousands of emails (that could have been prevented at this point by > just recognizing that a single email account on their service is > generating thousands of bounces) is considered clean. Maybe I > misunderstand the purpose of the RBL and my bias against UCEPROTECT is > influencing me here. > > I am still not sure what to think of MIPSpace, but I'm a pretty annoyed > that they blocked us such that we were unable to contact the abuse@ > account for the ISP. Kinda irresponsible, especially because the ISP is > also running MagicMail, so I would have expected some better integration > where we got some grace to send one or two SPF-verified emails to abuse@ > to resolve the issue. > > Finally, these backscatter emails seem like something else that can be > abused. If someone forges the return path for an email, but has access > to it in some way, they can use it to find out which emails don't exist. > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop