From: /dev/rob0 (rob0gmx.co.uk)
Date: Thu Apr 03 2008 - 15:30:10 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Wed April 2 2008 09:01:36 Bill Cole wrote:
> > reject_rbl_client zen.spamhaus.org
>
> While this is usually a good idea and I am a huge fan of the Spamhaus
> DNSBL's, there is something that anyone running a serious mail server
> using them should be aware of: they expect large users to chip in,
> and will stop answering your queries if you do too many. To
> understand what their limits on free use are, see
> http://www.spamhaus.org/organization/dnsblusage.html
>
> This is not an issue to take lightly. There have been days when my
> personal domain (never more than a dozen actual users) has had more
> than the 80k SMTP connections per day limit they set, although that's
> very rare and it didn't generate the 320k queries/day limit they set
> which is what would be noticeable by Spamhaus. If you have a mail
> system handling mail for more than a hundred people, you stand a very
> strong chance of exceeding their limits on a regular basis and a risk
> of having your DNS queries ignored by Spamhaus without warning. One

I have a split MX setup, some mail going to my static IP server, other
going to a server on residential Comcast cable. Spamhaus apparent has
cut off Comcast, because as you said, without warning I suddenly had a
deluge of spam, and DNS errors in the logs.

I solved my problem with a "type forward" zone declaration for
zen.spamhaus.org., forwarding queries through 3 other sites. The
volume of queries coming from all three combined wouldn't be anywhere
near the Spamhaus threshold, even with the home server's queries.

> should *never* rely on an upstream ISP's recursing resolvers for an
> inbound mail server's DNS resolution, but a lot of small businesses
> do so routinely and I have seen multiple reports of Spamhaus cutting
> off resolution for ISP resolvers, presumably because they aggregate
> the usage of thousands of tiny operators into a tremendous flood of

Although I don't intentionally use Comcast's nameservers, it's quite
possible that they have transparently proxied DNS traffic.

> queries. Anyone turning on DNSBL queries either by way of
> reject_rbl_client or by the use of something like SpamAssassin that
> is not as obvious about its use of those resources needs to look
> carefully at their DNS infrastructure to avoid both rudeness and
> performance problems.

And here it is for the Google record: residential Comcast users might
encounter this issue, as I did.
--
    Offlist mail to this address is discarded unless
    "/dev/rob0" or "not-spam" is in Subject: header

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]