On 06/01/10 03:49, Matt Kettler wrote:
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;"
OK. Thank you for your complete explanation. I'm going to disable spamd
daemon.
--
Angel L. Mateo Martínez
Sección de Telemática
Área de Tecnologías de la Información _o)
y las Comunicaciones Aplicadas (ATICA) / \\
http://www.um.es/atica _(___V
Tfo: 868887590
Fax: 868888337
