Mark Martinec wrote:
>
>> and also is there a way to test the efficiency in using the compiled
>> native mode set vs plain one?
>>     
>
> One way is to look at the TIMING report by amavisd at log level 2
> or above, the 'SA check' entry.
>
> If you run SpamAssassin version 3.3 (from CVS), the TIMING-SA
> as logged by amavisd-new-2.6.2 provides a SA timing breakdown,
> see for example a typically largest consumer of regexp CPU: tests_pri_0.
>
> A third way, perhaps most accurate, is to load the HitFreqsRuleTiming
> plugin (found in: masses/plugins/HitFreqsRuleTiming.pm of the
> current SA 3.3), which writes a detailed timing report for each
> of the more time consuming rules, and writes it to a file timing.log
> in a current directory, so it's best to invoke it from a command line
> through a 'spamassassin -t' command on some test message.
>
>   
>> 2) is there a way to get good statistics about percentage of spam and
>> ham?
>>     
>
> amavisd-agent reports:
>
> InMsgs                               39985   1732/h   100.0 % (InMsgs)        
>     
> InMsgsBounce                           154      7/h     0.4 % (InMsgs)        
>     
> InMsgsBounceKilled                      49      2/h    31.8 % (InMsgsBounce)  
>     
> ContentBadHdrMsgs                       11      0/h     0.0 % (InMsgs)        
>     
> ContentCleanMsgs                      1813     79/h     4.5 % (InMsgs)        
>     
> ContentSpamMsgs                      37389   1619/h    93.5 % (InMsgs)        
>     
> ContentSpammyMsgs                       34      1/h     0.1 % (InMsgs)        
>     
> ContentVirusMsgs                       175      8/h     0.4 % (InMsgs)        
>     
>
>   
Ah, ok, I'll use that tool and I'll fix also the directory where 
amavisd-agent looks for
in the mandriva amavisd-new package (default is /var/amavis, while 
mandriva uses /var/lib/amavis).
What I don't understand it's that the statistics seems to be zeroed 
every time the amavisd service is restarted?

Furthermore wouldn't be possible for the amavisd-new to have some 
statistic about the speed|performance?
I see the cumulative time spent on processing messages, but sound not 
the number of messages per seconds
(for instance) the system can sustain.
>> I remember some perl script doing that, but when I tried were failing
>> because the postfix|mailer log wasn't in the format they was expecting,
>> and thus many messages were counted twice or three times 
>> because they were resent locally across the various ports
>> (10025:10026, etc.) 
>>     
>
> Try logwatch module by Mike Cappella
>   http://www.ijs.si/software/amavisd/#contrib
> It is being updated in sync with versions of amavisd-new.
>
>   
OK, will try maybe bundled with some mrtg or nagios stuff.
>> 3) when amavisd-new are produced in a standalone file, e.g. setting in
>> amavisd.conf the line:
>>   $LOGFILE  = "/var/log/amavis/amavisd.log
>> what is the safest way to get log rotations?
>>     
>
> Don't let amavisd log directly to a log file. It is inefficient
> and log rotation requires restarting of amavisd.
>
> The preferred way is through syslog, it is the most flexible,
> is efficient and is trouble-free. All regular syslog maintenance
> procedures can be used, e.g. for log rotation, for duplicating
> high priority messages to another log file, for providing separate
> debug file when needed, ...
>   
OK, I understand this. My request was because otherwise syslog log goes 
in /var/log/mail/{info,errors,warnings}
which are the same one where already postfix (and cyrus-imapd) writes, 
so if you have the
amavisd output too in the same file (and you have an high debug level) 
the log is a bit more confused.

A little further question. Is it possible to have whitelist, but only 
for mail sent (originated) locally? E.g. suppose
I whitelist myself (i.e. mydomain), in that case, a typical spammer 
might send messages
to me, like if they were sent to myself, and those might be whitelisted 
while shouldn't, so the spam would pass.
This is not having the open relay, but is a pretty common
scenario, and in these days this it is pretty much exploited by spammers 
(e.g. spammers get lists of email
of your domain and will send to you spam messages with your email 
address in the From: field).

Thanks.
Bye
Giuseppe.


------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
AMaViS-user mailing list
[email protected] 
https://lists.sourceforge.net/lists/listinfo/amavis-user 
 AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 
 AMaViS-HowTos:http://www.amavis.org/howto/ 

Reply via email to