This will only scratch the surface of this problem and approaches to it, because it'd be hundreds of lines long if I did more than that. 1. This problem is massive because of two contributing factors: (1) ~1000 junk gTLDs that nobody needed or wanted except registrars and abusers (2) ubiquitous cloud hosting by providers who don't care about any abuse that's (a) outbound or (b) facilitated, only (c) inbound. 2. There's little-to-no point in complaining to registrars or clouds because they don't care, they don't want to care, nobody will make them care, and the most likely outcome is that they'll forward your complaint to the abusers. 3. If you run your own MTA, I highly recommend blocking all ~1000 junk gTLDs and punching specific holes in those blocks only for the domains that you want to receive email from. For small to medium sized operations, this works pretty well. (Do remember to exempt postmaster@, abuse@, etc.) 4. To supplement (3), configure your MTA to check the usual SpamHaus DNSBLs and RHSBLs. Doing (3) first will minimize the traffic to Spamhaus, which is good for you and for them. 5. If you're not running your own MTA, then get your provider to do (4) if possible. They probably won't do (3). 6. (5) leaves you with choices on the receiving side, and they're all onerous. But procmail (if available) is one way to tackle this. I use it locally as a backup to what's in the MTA. In particular, I have several hundred rules that attempt to grab obvious spam and are modestly successful at doing so. If you're interested, I'll be happy to share the ruleset with you off-list. You *could* supplement this list with rules for all of those ~1000 junk gTLDs but it would probably be easier to to write the far smaller number of rules required to handle the non-junk gTLDs (and any ccTLDs of interest to you) -- and then to make exceptions if/when they become necessary. ---rsk