zen.spamhaus.org RBL

[uxbod]

Just remember with any free RBL a constraint of the service is how many lookups you are performing ... too many and you will be classed as a commercial service which will incur a charge.

[jones0610]

Understood and thanks for the reminder. My volumes are quite low (less the unsolicited spam that I get because I registered my domain name over 15 years ago) so I think there won't be any issues with the various providers that I use.. Projects like Spamhaus do monitor usage and will tell you if you need to upgrade.

[uxbod]

I am low volume; run a caching DNS server; plus upstream. Perhaps your upstream is making to many queries ?

[jones0610]

Looks like using OpenDNS resolved this. Spamhaus test says:

{snip}
554 5.7.1 Service unavailable; Client host [192.203.178.107] blocked using zen.spamhaus.org; http://www.spamhaus.org/SBL/sbl.lasso?query=SBL230
Terminating conversation

I raised the issue with my ISP but thaty haven't gotten back to me. My caching DNS server uses my ISP name servers to forward to so I'll need to see what's involved in going to OpenDNS assuming that they are going to be mega-reliable moving forward.

[ArcaneMagus]

I have never once had a problem with OpenDNS in the year or so I have been using them. Their system status can be found here OpenDNS > System (also available at http://208.69.38.170/). Any problems with a data center cause traffic to be re-routed to the nearest center. I would say that any system that handles 19+ billion queries a day would have to be pretty reliable

For BIND you just need to change the forwarders directive.

[rusty]

Quick question.

What file is the command zmprov mcf zimbraMtaRestriction altering?

I just want to make a copy of it before I start. Thanks.

[phoenix]

Originally Posted by rusty

Quick question.

What file is the command zmprov mcf zimbraMtaRestriction altering?

I just want to make a copy of it before I start. Thanks.

You can find out with:

zmprov gcf zimbraMtaRestriction

zmprov help commands

[csmwww]

It can be both confusing and/or inconvenient use an upstream DNS server to for DNSBL service like SPAMAUS:

• an upstream DNS server might be "firewalled out" to limit over use of "zen.spamhaus.org" (see The Spamhaus Project "zen -> DNSBL usage terms"). For example the commonly used DNS server "4.2.2.1" can't resolve "d.c.b.a.zen.spamhaus.org", even for blacklisted IPs, presumably for this reason. And, if you find one that works today then it might not tomorrow, for this reason, and it is beyond your control and would be confusing.
• you may be using such a DNS server quietly if you are not thinking about this issue actively. If not directly then perhaps as a "forwarder" for unknown DNS resolution. So you should figure out what you are using, perhaps starting with nslookup.

But folks should also consider that it is neither responsible nor right to do so:

• especially when using such a nice (often free) service like SPAMHAUS you should think about "right". I mean, you are better than SPAMMERS, aren't you?
• using an upstream DNS server penalizes them for your usage. Specifically in the case of SPAMHAUS, your lookups will appear to come from the upstream provider, and not be attributed to you. You should approach SPAMHAUS directly so your usage can be properly attributed to you, not someone else.
• using an upstream DNS sever for high frequency DNS resolution is an unreasonable offloading of recursive DNS resolution to servers that are not really meant for that. ISP servers should be for resolving end user names, like websites and stuff, and high volume automated recursive DNS resolution should be handled directly by the beneficiary.
• you are blowing caches, overloading the internet. Such use loads the upstream DNS server's cache with DNS names that are not likely to be of use to other users, perhaps flushing others of value causing more traffic.

I suggest anyone who is running automated tools like a mail service should be utilizing their own DNS server that does all the DNS recursive resolution itself, based only on root servers. This means making sure you have your own DNS server that is not set up to "Forward" requests for unknown names to another upstream server and instead uses only the root servers with its recursive lookup enabled, that you keep your root server list up-to-date (you could set a watch on the page http://www.internic.net/zones/named.root), and that your service uses that DNS server.

Doing this will both stabilize your system setup, and be more responsible.