[SA-exim] Conflicting spamc.conf

[Magnus Holmgren]

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. :-)

[Marc MERLIN]

Post by Magnus Holmgren
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.

Post by Magnus Holmgren
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.

Post by Magnus Holmgren
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.

Post by Magnus Holmgren
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