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

Startseite
Nachricht löschen
Nachricht beantworten
Autor: Marc MERLIN
Datum:  
To: Tor Slettnes, Coax, Nigel Metheringham, Chris Edwards
CC: sa-exim, exim-users
Betreff: Re: [Exim] SA-Exim vs. ExiScan - at an initial glance
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@??? for PGP key