Author: Ted Cooper Date: To: exim-users Subject: Re: [exim] question regarding spamassassin in exim,
especially headers
On 15/07/11 15:36, Phil Pennock wrote: > On 2011-07-14 at 08:54 -0700, David Mathog wrote:
>> I don't have a grasp on the relative benefits of doing the spam checking
>> in these two different ways, beyond the observation that the sa-exim one
>> ends up with the headers spamassassin is configured to add. Since there
>> is usually no free lunch, I'm guessing sa-exim is slower, user more
>> resources, or has some other problem I don't know about yet...
>
> I don't use SA and hadn't looked at sa-exim's implementation before now.
>
> Make sure you set "SAspamcSockPath" to get to use the daemon instead of
> parsing all the Perl modules for every spam received.
>
> Otherwise, there's a little more overhead even then from sa-exim but not
> enough to worry about on any modern system (reads a config file, exec's
> another binary; on the same order of the work that Exim does routinely
> anyway, so I don't expect it to be an issue).
sa-exim is the old way to do it isn't it? You should be able to do
everything you would normally do with sa-exim, with the newer built in
version.
After poking around for a bit, it seems the only real difference is when
the scanning is called. The spam verb is called whenever it is found and
the result is cached, some variables set, and then it is handled
entirely in ACL. In the other, there is just a throw off to SA just
prior to accepting the message and all decisions are made by SpamAssassin.
I'd have to agree with using the spamd socket though - the startup time
of spamassassin compared to spamd & spamc is HUGE.
