zlacker

[return to "Introducing Cloudflare Registrar"]
1. cpncru+Zy1[view] [source] 2018-09-27 23:05:34
>>jgraha+(OP)
I would never use Cloudflare. They hide spammers and refuse to do anything about them. The same mass spammer will register site after site for months, sending snowshoe spam, and cloudflare refuses to do anything. At one point this was taking up about 80% of our incoming spam, and most of it was getting through spam filters due to the snowshoeing. You could see the same registration info for hundreds of domains over months, all sending spam, but cloudflare doesn't give a shit.

The only solution I found was to put a 15 minute delay on all incoming email from a cloudflare domain, then do a second check of the blacklists. This solved the problem, as the sending ips (not cloudflare) tended to get blacklisted within 15 minutes.

In my mind if you're hiding people's websites behind your "cloud", you have a responsibility to kick off the spammers.

◧◩
2. johnkl+Az1[view] [source] 2018-09-27 23:12:47
>>cpncru+Zy1
How do you have your MTA check if a domain is hosted through Cloudflare, and what blacklists do you use? I think I'd like to do this, too.
◧◩◪
3. jlgadd+ep3[view] [source] 2018-09-28 20:23:40
>>johnkl+Az1
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

◧◩◪◨
4. cpncru+bN3[view] [source] 2018-09-29 01:29:07
>>jlgadd+ep3
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).
[go to top]