spamassassin-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Angel L. Mateo" <ama...@um.es>
Subject Re: spamassassin or spamd with amavisd-new?
Date Fri, 08 Jan 2010 07:36:54 GMT
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

Mime
View raw message