Conflicting spamc.conf

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.

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.

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'm of course already working on it. :-)

-- 
Magnus Holmgren        [email protected]
                       (No Cc of list mail needed, thanks)

  "Exim is better at being younger, whereas sendmail is better for 
   Scrabble (50 point bonus for clearing your rack)" -- Dave Evans

_______________________________________________
SA-Exim mailing list
[email protected]
http://lists.merlins.org/lists/listinfo/sa-exim

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQBFcjfNk7mRNn1h4+YRAmDfAKCMSz/Aga2VQaPXOn8wkrxpH66zVgCgsPL8
7l0EA8uRebQrb44whC3JF1E=
=vCxx
-----END PGP SIGNATURE-----