[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: tmda (was Re: Attach filter)



On Mon, Jul 12, 2004 at 12:31:00PM -0700, Steve Lamb wrote:
> David Fokkema wrote:
> >>  - The math for C-R simply doesn't scale.
> 
> > ?
> 
>     I'm not sure what Karsten had in mind here but let me give my first hand
> view on this piece.  My current employment gives me access to TMDA in
> production use.  In one instance a client of ours gets over 9,000 messages *a
> day*.  Virtually all of it is spam.  They have configured TMDA to C-R.  So
> follow the math.
> 
> 9,000 messages a day for 14 days (default pending queue) is 126,000 messages
> in the pending queue at any given time.  I believe this is a modified maildir
> format.  Not pretty.
> 
> 9,000 challenges sent out a day.  Most of which are to invalid addresses.
> Those that aren't are sent to an innocent 3rd party.
> 
> Close to 9,000 bounces generated a day thanks to the above challenges being
> sent out.
> 
>     So for an initial investment of 9,000 messages we've generated close to
> 18,000 more, all of which are worthless but need to be processed.  Those are
> tons of connections going out, loads of logs being written.  CPU time wasted,
> hard-drive space taken up.  And that's just one client with a modest number of
> addresses (5-6?).
> 
>     C-R does not scale because in its best implementation, barring any other
> filtering, is an n*2 (spam + challenge) and often is a n*3 solution (spam +
> challenge + bounce).  As the spam problem gets worse C-R compounds it.
> 
>     Mind you that the offical TMDA party line might be to use it as part of a
> grander scheme but some people have come here to this list to tell those of us
> with a little clue that C-R (in particular their broken implementation, not
> TMDA) was far superior than spam filtering and that spam filtering simple was
> not needed and a waste.
> 
>     C-R works best when integrated into a larger spam-filtering solution.  IE,
> any marginal message within a narrowly defined statistical range would get a
> challenge.  Anything below that narrow range is passed through.  Anything
> above is rejected.  But as Karsten has pointed out at that point what's the
> point since filtering is doing virtually all the work anyway?
> 
>     Filtering does not compound the problem.  Filter those 9k messages and
> reject most at SMTP time you've only had to process.... 9,000 messages.  Not
> 18,000.  Not 24,000.  9,000.

Got it, thanks!

David

-- 
Hi! I'm a .signature virus. Copy me into
your ~/.signature to help me spread!



Reply to: