jonathan,
> so given that amavisd is already daemonized... does this suggest that
> there would be minimal gains in moving to spamd called from postfix?
Yes, practically no difference in throughput, possibly even some loss
in throughput due to spamc/spamd being invoked once per recipient,
and ama
Matthias Leisi wrote:
Amavisd does not use the spamassassin command line binary, but:
- --- cut ---
package Amavis::SpamControl;
[..]
use Mail::SpamAssassin;
- --- cut ---
In the logfile of amavisd, you'll also see something like:
| Aug 30 20:26:11 amavis[27896]: Module Mail::SpamAssassin 3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
jonathan schrieb:
> I'm more concerned about the overhead of calling spamassassin over and
> over from within amavis. Some suggest three or four times better
> performance using spamc/d over calling the spamassassin command directly
> (which is (i
Matthias Leisi wrote:
Amavisd uses the SpamAssassin Perl module directly (ie not really spamc
or spamd).
For a high-volume site, amavisd has advantages if you want to do
additional checks besides SA (eg virus checking). If you only want to
run SA, you could avoid the overhead of amavisd.
Ok
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
jonathan schrieb:
> For a high-volume site, is there any reason to not be running
> spamc/spamd over amavisd/spamassassin? Specifically, can you use all of
Amavisd uses the SpamAssassin Perl module directly (ie not really spamc
or spamd).
For a hi
For a high-volume site, is there any reason to not be running
spamc/spamd over amavisd/spamassassin? Specifically, can you use all of
the various perl plugins (imageinfo, pdfinfo, botnet, etc...)? Are
there any other tradeoffs to this configuration?
thanks,
Jonathan.
