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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
