On 1/5/2010 6:09 AM, Angel L. Mateo wrote:
> Hello,
>
> Because FH_DATE_PAST_20XX bug, I have found that when I run
> spamassassin through amavisd-new (in a postfix server) I need to
> restart spamassassin and amavisd-new after any change in spamassassin.
>
> Debugging this, I found that amavisd-new doesn't connect to my
> spamd daemon to check mails, so I think it is using spamassassin
> command instead of spamc (I have spamd running in foreground, without
> -d option and I haven't seen any connection)
>
> However, I have read in spamassassin that spamc has better
> performance than spamassassin, so I would like amavisd-new to use
> spamc instead of spamassassin.
>
> I don't know much of amavisd-new and spamassassin implementations
> details, but I have found that amavisd-new connect with spamassassin
> throught is perl interface by create a SpamAssassin object like this:
>
> my($spamassassin_obj) = Mail::SpamAssassin->new({
> debug => $sa_debug,
> save_pattern_hits => $sa_debug,
> dont_copy_prefs => 1,
> local_tests_only => $sa_local_tests_only,
> home_dir_for_helpers => $helpers_home,
> stop_at_threshold => 0,
> });
>
> Do you know if there is any option to tell perl object to use the
> spamd daemon? Is there any way to use spamd daemon with amavis? Is it
> worth in a mail gateway with hugh loads?
>
Stop, you do NOT need to do this. It would be slower.
Amavisd-new does not use the "spamassasin" command-line application
(which is really slow), it is loading perl API directly and re-using
that API instance, which is even more efficient than spamc. You don't
see the perl API method discussed very often because it only makes sense
when using an integration tool written in perl (which amavis is). In
effect, amavisd-new is already it's own spamd daemon using this method.
Invoking spamc on the command line would add more overhead to this process.
Really, all spamd does is create a reusable instance of a
Mail::SpamAssassin perl object, and keeps it loaded so it can process
several messages that spamc feeds this. This is exactly what amavisd-new
is already doing internal to its own code, so it doesn't need spamd.
Running "spamassassin" on the command line is really slow, because it
creates a new Mail::SpamAssassin object, scans a single message, and
exits. This is great for quick checks of the configuration, but not at
all efficient in a mailstream. However, amavisd-new does not do this. It
creates and re-uses a Mail::SpamAssassin object.
Read the main page of the amvavis website which states:
http://www.ijs.si/software/amavisd/
Which will point out:
"when configured to call /Mail::SpamAssassin/ (this is optional), it
orders SA to pre-load its config files and to precompile the patterns,
so performance is at least as good as with spamc/spamd setup. All Perl
modules are pre-loaded by a parent process at startup time, so forked
children need not re-compile the code, and can hopefully share some
memory for compiled code;"
