You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by jonathan <je...@ryerson.ca> on 2007/08/30 17:17:30 UTC
spamd and plugins
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.
Re: spamd and plugins
Posted by Mark Martinec <Ma...@ijs.si>.
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 amavisd invoking SA once per message. In other words, amavisd
is just like spamd, but uses a different protocol to talk with MTA
(a standard SMTP vs. a proprietary spamc protocol + unix pipe).
Mark
Re: spamd and plugins
Posted by jonathan <je...@ryerson.ca>.
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.002000
>
so given that amavisd is already daemonized... does this suggest that
there would be minimal gains in moving to spamd called from postfix?
(bearing in mind that amavisd is going to have to stay for virus
filtering regardless).
thanks,
jonathan.
Re: spamd and plugins
Posted by Matthias Leisi <ma...@leisi.net>.
-----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 believe) what amavis does). Being able to handle
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.002000
> substantially more messages would help us quite a bit as our incoming
> mail volume is rapidly on the rise.
>
> If I've got loadplugin commands in my various custom .cf files, will
> these be properly heeded by spamd?
If the custom .cf file are in a location that is read by your spamd
process, yes.
- -- Matthias
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFG1wwqxbHw2nyi/okRAqq7AKCvhlJA1qdtBKcDDLbLfjbLROsbNQCfYNHk
J/RhHuegL0cH2WRwOTPrknQ=
=hZMI
-----END PGP SIGNATURE-----
Re: spamd and plugins
Posted by jonathan <je...@ryerson.ca>.
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. I understand this side of things, and we're not going to be able to
ditch amavisd due to our virus filtering setup.
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 believe) what amavis does). Being able to handle
substantially more messages would help us quite a bit as our incoming
mail volume is rapidly on the rise.
If I've got loadplugin commands in my various custom .cf files, will
these be properly heeded by spamd?
Re: spamd and plugins
Posted by Matthias Leisi <ma...@leisi.net>.
-----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 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.
> the various perl plugins (imageinfo, pdfinfo, botnet, etc...)? Are
I run various incarnations of SA (through sendmail-milter, through
amavisd, spamc as a Postfix content_filter), and I can access any plugin
I want in any of these environments. Being able to run a plugin is more
a Perl issue (having the necessary @INC paths for the user running the
"container", filesystem permissions etc) than a SA issue.
- -- Matthias
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFG1wKVxbHw2nyi/okRAvoiAJ9Dj3d1PyC4aD9t4a5U6SEnK143WwCZAX0h
3PquILgowvAxKq5QlJR89SE=
=88lT
-----END PGP SIGNATURE-----