zlacker

If you've ever ran Postfix on a public-facing MX host, you're probably familiar with so-called "restrictions" like "check_client_access", "check_recipient_access", and "check_sender_access".

There are also several other (seemingly lesser known) restrictions available, such as "check_sender_a_access", "check_client_mx_access", and "check_helo_ns_access" (plus similar variations you can likely think of) that you can use to take action based upon things like the IP address(es) listed in the A RR for the client MTA's hostname, the hostname(s) listed in the MX RRs for the client MTA's IP address, and/or the authoritative DNS servers of the domain name provided by the client MTA during the HELO/EHLO phase.

Imagine a spammer that had hundreds of domain names, all of which used her own DNS servers, jack.ns.example.com and jill.ns.example.com. Using check_sender_ns_access, for example, you can quickly and easily reject all mail where the domain name in the envelope from address uses one of these authoritative DNS servers.

If you get creative, you can come up with some really effective combinations that are actually pretty simple.

[0]: http://www.postfix.org/postconf.5.html

>>jlgadd+(OP)
Well, this is the problem with cloudflare...you can't block cloudflare because there are so many legitimate domains hosted there. The 15 minute delay followed by a second blacklist check is the best solution I've come up with (it seems to work almost 100% of the time from what I can tell).