[SA-exim] Re: [Exim] SA-Exim vs. ExiScan - at an initial glance

[Marc MERLIN]

On Wed, Nov 26, 2003 at 02:30:38PM -0800, Tor Slettnes wrote:
> Specifically, from a superficial glance, these are the strengths of
> ExiScan (as compared to SA-Exim):

Exiscan is a versatile virus scanner that also has the basic functionality
of sa-exim.  If you're collecting protection money from windows users,
that's the one you want :)
If you're just interested in spam checking and rejection, sa-exim will
probably offer you more options.

>     the ExiScan statements are even reached (whereas SA-Exim is launched
>     on every message, and its configuration needs a separate conditional
>     statement if one does not wish to scan messages from certain hosts, say).
 
That's true, although sa-exim is really in memory already. Exim makes a call
to its function and it returns right away. In real life, it's about the
same.
 
>   o Allows more flexibility in routing, accepting, rejecting messages
>     based on SA's score (through the 'spam' driver which evaluates to

While you would do it a bit differently, you can do the same with sa-exim

>   o Does not modify the original message unless told to (SA is processing
>     a copy of the message).  This may be a disadvantage too; see below.

Actually with sa-exim, it's the same:  sa-exim just copies a few headers
back to the original message headers (admittedly you can't turn it off
there, since it's trivial to use header_remove on the ones you don't want),
and sa-exim optionally can modify the body which is a must if you use
report_safe.

>   o Talks to 'spamd' directly, rather than launching 'spamc' do do so
>     (should reduce process creation overhead a little..)
 
Right. sa-exim should probably do that too. The only reason I haven't is
that the speed improvements are probably very very small vs running SA
anyway, and that running spamc lets you change the spamc/spamd pair without
recompiling sa-exim (which is a clear advantage when you manage a system
with precompiled packages)
 
> In any case - both of these are really, really powerful Exim add-ons;
> nobody should live without them. :^}
 
The good news is that you can also run both :)
 
On Wed, Nov 26, 2003 at 04:40:21PM -0600, Coax wrote:
> If you do anything in the ACL subsystem, teergrubing is available.  Its
> just a call to 'delay'. :)
 
This is not real teergrubing. A delay does not send any data to the sender.
teergrubing sends data to make the other side keep listening as long as you
can.
 
> That said, sa-exim was written in a different way than ExiScan.  Marc's
> takes advantage of replacing the local_scan function..  There are bound to
> be pro's and con's to doing it EITHER way..

The obvious pro is that you don't need to upgrade sa-exim with every version
of exim.
The con is that exiscan hooks in directly inside exim and has more access
than sa-exim does (although in real life, sa-exim can do what it needs
through the local_scan interface)

On Thu, Nov 27, 2003 at 09:42:47AM +0000, Nigel Metheringham wrote:
> I do wonder how easy it would be to take a message that has header
> markup only and encapsulate it, producing the SA body report - this
> could easily be done in a transport if the basic encapsulator was
> available without a full re-run of SA.

That would indeed be an intersting project :)

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/   |   Finger marc_f at merlins.org for PGP key