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
