[SA-exim] Conflicting spamc.conf

Marc MERLIN marc at merlins.org
Sat Dec 2 18:48:03 PST 2006


On Sun, Dec 03, 2006 at 03:34:52AM +0100, Magnus Holmgren wrote:
> Recent versions of spamc has the ability to read command-line options from a 
> configuration file. The options read can conflict with normal SA-Exim 
> operation (there is no way to specify that you want normal filtering 
> operation except by not specifying -E, -r, -R etc., and 
> hardcoding -F /dev/null will surely result in an error with older versions.
 
True.
 
> Isn't it time to reconsider the decision not to talk the spamc/spamd protocol 
> directly? If it's done right, new protocol versions shouldn't be a problem 
> since spamd will give its response using a version corresponding to the 
> version the client uses.

At the time I was hoping to have the sa-exim.so binary be fully independent
of spamassassin versions and API changes, and not have to worry about
linking and later possible linking version mismatches between sa-exim and
SA.
Also, the SA API and linking didn't seem very mature when first wrote
SA-Exim. Things have change since then obviously.

> There are some advantages with this. First and foremost, the score and whether 
> it's spam or not don't have to be pulled from the X-Spam-* headers. That 
> means more freedom to the user as to the formatting of the X-Spam-Status 
> header (but it's still needed for greylisting). Second, the forking business 
> goes away (some other business takes its place, of course, but it's not not 
> necessarily more difficult business).

I've never found forking to really be a bottleneck there compared to the
heavy stuff that SA does in perl for each call. I would go as far as saying
that I'm almost certain that you will never able to benchmark a difference
between forking spamc and calling SA via the API compared to the CPU time
used by the spamd work after that.

> I'm of course already working on it. :-)

I'm not against it, I've just never seen sufficient incentive to work on it
myself. It may be the better solution today.

Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems & security ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: Digital signature
Url : http://lists.merlins.org/archives/sa-exim/attachments/20061202/603ee33c/attachment-0001.pgp 


More information about the SA-Exim mailing list