You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by "Angel L. Mateo" <am...@um.es> on 2010/01/05 12:09:27 UTC
spamassassin or spamd with amavisd-new?
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?
--
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
Re: spamassassin or spamd with amavisd-new?
Posted by Jari Fredriksson <ja...@iki.fi>.
On 5.1.2010 13:09, 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?
>
amavisd-new does not use spamd NOR spamassassin command. It is itself a
daemon like spamd, and is linked to SpamAssassin library code.
If you want to use SA via amavisd-new there is nothing to worry about,
it works efficiently.
Just disable spamd as it is redundant and takes memory uselessly.
--
http://www.iki.fi/jarif/
The Least Perceptive Literary Critic
The most important critic in our field of study is Lord Halifax. A
most individual judge of poetry, he once invited Alexander Pope round to
give a public reading of his latest poem.
Pope, the leading poet of his day, was greatly surprised when Lord
Halifax stopped him four or five times and said, "I beg your pardon, Mr.
Pope, but there is something in that passage that does not quite please me."
Pope was rendered speechless, as this fine critic suggested sizeable
and unwise emendations to his latest masterpiece. "Be so good as to mark
the place and consider at your leisure. I'm sure you can give it a better
turn."
After the reading, a good friend of Lord Halifax, a certain Dr.
Garth, took the stunned Pope to one side. "There is no need to touch the
lines," he said. "All you need do is leave them just as they are, call on
Lord Halifax two or three months hence, thank him for his kind observation
on those passages, and then read them to him as altered. I have known him
much longer than you have, and will be answerable for the event."
Pope took his advice, called on Lord Halifax and read the poem
exactly as it was before. His unique critical faculties had lost none of
their edge. "Ay", he commented, "now they are perfectly right. Nothing can
be better."
-- Stephen Pile, "The Book of Heroic Failures"
Re: spamassassin or spamd with amavisd-new?
Posted by "Angel L. Mateo" <am...@um.es>.
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
Re: spamassassin or spamd with amavisd-new?
Posted by Terry Carmen <te...@cnysupport.com>.
On 01/06/2010 02:05 PM, Kai Schaetzl wrote:
> Terry Carmen wrote on Wed, 06 Jan 2010 13:23:28 -0500:
>
>
>> How/where is this turned on in amavisd-new-2.6.4?
>>
>> I'd be happy to get rid of useless instances of spamd
>>
> This has nothing to do with amavis. spamd is a separate daemon that *you*
> enabled. As you don't seem to know this: are you sure that spamd runs at
> all or was it just an assumption?
It had been left enabled from a previous install, however I just
disabled it, and everything is still working, which is nice, since it
saves a little RAM.
Terry
Re: spamassassin or spamd with amavisd-new?
Posted by Kai Schaetzl <ma...@conactive.com>.
Terry Carmen wrote on Wed, 06 Jan 2010 13:23:28 -0500:
> How/where is this turned on in amavisd-new-2.6.4?
>
> I'd be happy to get rid of useless instances of spamd
This has nothing to do with amavis. spamd is a separate daemon that *you*
enabled. As you don't seem to know this: are you sure that spamd runs at
all or was it just an assumption?
Kai
--
Get your web at Conactive Internet Services: http://www.conactive.com
Re: spamassassin or spamd with amavisd-new?
Posted by Terry Carmen <te...@cnysupport.com>.
On 01/05/2010 09:49 PM, Matt Kettler wrote:
. . .
> 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;"
How/where is this turned on in amavisd-new-2.6.4?
I'd be happy to get rid of useless instances of spamd
Terry
Re: spamassassin or spamd with amavisd-new?
Posted by Matt Kettler <mk...@verizon.net>.
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;"