Re: Spamassasin over RBL, was Re: rblsmtpd -t?
On Thu, May 02, 2002 at 06:52:33PM +1000, Jason Lim wrote:
>
> > procmail/spamassasin process mails yes "inside" the server, I just
> > give you a made up example:
> >
> > 60 Mails incoming per Minute,
> >
> > 5 seconds average Spamassasin procesing time per Mail
> >
> > => 60-12 = 48 Mails per Minute piling up on your incoming mail
> > queue = 48 new Spamassasin processes per Minute consuming your
> > resources.
> >
> > While RBL throttles Mail Flow (and spares Disk space) thus protecting
> > you in advance, Spamassasin puts the load on your side.
>
> Well, they are not exactly comparable, as the rule-based Spamassassin does
> things based on "keywords and "keyphrases" and that kind of thing, while
> RBLs do things based on actual spam activity. In my view, the collateral
> damage of using Spamassassin's rule based blocks is too great.
>
> The only RBL a business should really use is the Spamcop.net RBL, because
> is blocks only when actual spam occurs, and not just blocks "all of Asia"
> as some other RBLs do. I'm not going to get into the whole RBL comparison
> thing, but just wanted to point out the "collateral damage" point.
Collateral damage is, however, the only leverage one has get some
of these spam friendly ISPs and lazy admins to enforce reasonable use.
We just got a dictionary (?) attack from sympatico.ca using forged reply
addresses covering all printable characters in this range:
[\001-\255][\001-255][\001-\255]@maine.com, our domain, sent all over.
Response from sympatica.ca security/abuse .... Not their
responsibility.
So a fast rblsmtpd, presumably with local rbl database, set to defer
not accept on overload would be preferable.
Collateral damage happens if you **accept** that email too and try
to filter afterwards. That amounts to DOS. Legitimate email is delayed
and bounces. We don't run with a week in the queue, but only hours
now - that too because of the spam that won't bounce back. We shut
down our off-site MX because spam would come in through that. Yes
our reliability has been heavily compromised; more collateral damage.
That aaa attack generated triple bounces so it would have been
approx 200*200*200*3 messages if it went to completion? We're
seeing spammers running linux boxes on roadrunner cable connections;
I don't want to buy the horsepower and sink the time into handling
that without "damage". Seems to me it will always take an order
of magnitude more power to filter accepted garbage than it will to
generate that garbage. No way to win that.
Anyway, the approach we are taking now is the strictest possible
RBL plus an accept list and no spamfilters, precisely because it
seems the lightest on resources and the most effective long term.
Clients here can opt out of that (getting all email), go with our
default, or pay extra for filtering after receipt.
cfm
--
Christopher F. Miller, Publisher cfm@maine.com
MaineStreet Communications, Inc 208 Portland Road, Gray, ME 04039
1.207.657.5078 http://www.maine.com/
Content/site management, online commerce, internet integration, Debian linux
--
To UNSUBSCRIBE, email to debian-isp-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: