SpamAssassin/DCC integration

Craig R Hughes <craig@hughes-family.org> writes:

> Hearing good reports from cutting edge SpamAssassin users who've
> installed recent CVS builds and activated the new DCC/SA integration
> stuff.

At the risk of repeating others...


> And already we're seeing the first person who's concerned with DCC
> performance, and wants to run their own local dccd.

That concern was over network performance.  That problem will be there
regardless of what language the DCC code is implemented in.


> So here's my question: how easy would it be to re-implement the DCC
> client side in perl (haven't looked at the DCC source yet), so that
> SpamAssassin doesn't have to fork a dcc client process for each
> message it processes, and doesn't have to create a copy of the
> message text to pipe into the dcc process, etc.  I'd be neat (and
> probably a heck of a lot faster) to do the DCC client side stuff in
> perl, and just call it directly from the main SA code instead of
> forking and piping.  Anyone looked at doing this before?

I'd say if performance is a problem, then SpamAssassin should be
written in a language faster than Perl.  The fork/exec + pipe of the
message into dccproc is not going to be a huge bottleneck for
SpamAssassin users.


-- 
matt