On 5/1/2014 8:15 PM, Alex wrote:
...
> These are both corporate 10mbs dedicated links and I don't think latency
> and/or bandwidth is a problem.
The problem, if network related, will be UDP packet loss somewhere in
the end-to-end path, not b/w or latency on the CPE link into the
provider's net.
> It actually appears swl.spamhaus.org is the main problem. It doesn't even
> resolve when I try to do it manually.
>From here:
$ host 2.0.0.127.swl.spamhaus.org
2.0.0.127.swl.spamhaus.org has address 127.0.2.2
What response do you receive?
Due to your query volume you require paid service for Spamhaus Zen. The
same terms apply to all Spamhaus services. Your IPs may have been
blacklisted from DWL due to high query volume. Contact Spamhaus. If
your contract entitles you to all Spamhaus lists, the fix may be as
simple as changing the SWL hostname and adding your key.
> This was a recommendation I used from
> this list some time ago. Has something changed?
See above.
> postscreen_dnsbl_sites = mykey.zen.dq.spamhaus.net*3
> b.barracudacentral.org*2
> bl.spameatingmonkey.net*2
> bl.spamcop.net
> dnsbl.sorbs.net
> psbl.surriel.com
> bl.mailspike.net
With these 7 dnsbls you will have extreme overlap of listed IPs. The
last 5 will gain you little to nothing and simply add latency to your
mail transactions, which is something you do not want in a high volume
environment. I'd recommend you use Zen and BRBL, remove the rest, and
rely on SWL and dnswl for FP mitigation during SMTP. You also run
SpamAssassin on all of these hosts, so there's no need to pile on dnsbl
queries at SMTP connect.
> swl.spamhaus.org*-4
> list.dnswl.org=127.[0..255].[0..255].0*-2
> list.dnswl.org=127.[0..255].[0..255].1*-3
> list.dnswl.org=127.[0..255].[0..255].[2..255]*-4
Consolidate these last 3 to something like:
list.dnswl.org=127.0.[2..14].[2..3]*-4
To understand why, read "Return Codes" at:
http://dnswl.org/tech
> I'm also curious what resolvers people are using for their mail servers?
> bind? Looking at my query graphs, it appears to be about 30 queries/sec on
> average for each host, just as a local caching server.
That's ~2.6M queries/day/host. Eliminating the 5 unnecessary dnsbl
queries will lower this considerably. If you're not happy with bind,
check out: http://doc.powerdns.com/html/built-in-recursor.html
If you have more than a handful of hosts doing 2.5M queries/day, you
should seriously consider building a couple of resolvers homed in
different networks and having the MX hosts query the pair. This will
cut down considerably on the query load you're placing on your dns[b|w]l
servers, as resolver cache will be much more effective.
Cheers,
Stan
