Giuseppe, > >> Of these 10s, 7-8 seconds are usually taken by DNSBL SA checking;
> > Note that DNS-based checks only add to latency and have > > little effect on throughput. Extra latency can easily be > > compensated for by running more concurrent processes > > (at the expense of more memory consumed). > > I didn't understand this. Why should have a little effect on troughput? > If a mail is processed in 3s instead of 15s (apart concurrent sending), > means that I can deliver 20 mail/min, instead of 4 mail/min. If I have > 8 processes|core then I can deliver 20*8 mail/min instead of just 4*8. SpamAssassin's bottleneck is mainly the CPU. Say for example that it takes 10 seconds to process a message, including all the network wait times. Say that 1 second is used for crunching and 9 seconds are wait times. To fully saturate your CPU resources, it would take 10 parallel child processes, which would yield an aggregate mail throughput of 1 message per second (0.1 * 10). Now, if network wait times (latencies) would be shrunk to 0 wait time, leaving 1 second for crunching, it would take one child process to fully saturate the CPU, and would again yield a 1 message/s rate. Adding more child processes would achieve nothing, the throughput can not go beyond CPU saturation point. And same for anything inbetween. Wait times can be put to good use by processing other mail messages during wait times. That's what parallel processing is for. The only cost associated is a memory usage - increasing the number of child processes requires more memory. > what you mean as "aggregate mail troughput"? The maximum sustained mail rate (number of messages per second) that a mail filtering system is capable of processing. The main tuning knob is adjusting the number of child processes, so that host's resources are fully utilized but not overutilized (which would reduce efficiency). See: http://www.ijs.si/software/amavisd/amavisd-new-magdeburg-20050519.pdf pages 10..30. > >> I tried to add sort of > >> "skip_rbl_checks 1" to user_prefs but isn't effective. > > > > It'd better be in local.cf, but it should be effective. > > well, local.cf will be local to every user, while using > /var/lib/amavis/.spamassassin/user_prefs should affect only amavisd > which is running under the amavis username. Is the same SpamAssassin installation on that host used both by amavisd and also by other tasks (mail delivery)? Why is that? I'm not sure about skip_rbl_checks, but some settings are ignored in user preferences files. Also, having rules in per-user files is probably inefficient, as SpamAssassin needs to recompile them every time, preparing for a potential switching of users. > Hmmm, the problem is rather about the checks for local delivery which > should be boosted (i.e. a mail originating from LAN and directed to the > same host), for which I'm pretty confused. I could add some whitelist, > but I'm not sure where the check is performed, i.e. which field are > checked? The From (in that case it would fail as spammers spam recently > from yourself)? The "Received" chain (in this case what if the mails > are feeded trough a local fetchmail server?) > Theoretically I could have a 2nd content filter in postfix master.cd > for the LAN IPs only, but in that case I think that amavisd is bypassed > and I don't won't to totally disable it (it could still be useful for > clamav, etc.). I find it useful to have a couple of parallel 'transports' in Postfix. Postfix processes transports in a round-robin fashion. By associating local traffic and traffic from common correspondents to one (or two) transports (feeding amavisd), and leave everything else to the remaining transport, the effect is that even in the presence of rushins of spam, the important local traffic is guaranteed a 1/3 (or 2/3) of hosts capabilities. Spam may be queueing during rush hours, but other traffic is mostly unaffected. See: http://marc.info/?l=postfix-users&m=119255333719029&w=2 > And what if for some reason, the DNS works only locally > (because remotely have a link down), i.e. how to have the system be > DNS-fail-over for local mail delivery (originating and destination) > without having long timeouts due the DNS timeouts > in resolving addresses (e.g. you can't resolve spamhaus.org)? Keep rbl timeout settings reasonably short. It is possible to give per-zone rbl timeout settings. > Or should this be handled trough custom policy banks + XFORWARD > (and can $sa_local_tests_only = 1; be local to a single policy bank)? Unfortunately the $sa_local_tests_only can not be changed by a policy bank, because SpamAssassin wants this information during its initialization. But SA rules can take into account the name of currently loaded policy banks, for example: header __L_MYNETS X-Amavis-PolicyBank =~ m{(\A|/)(MYNETS|ORIGINATING)(/|$)}m and used for example in: meta L_OTHERS_UNDISC_RECIPS UNDISC_RECIPS && !__L_MYNETS score L_OTHERS_UNDISC_RECIPS 0.841 score UNDISC_RECIPS 0.001 Mark ------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p _______________________________________________ AMaViS-user mailing list AMaViS-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amavis-user AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 AMaViS-HowTos:http://www.amavis.org/howto/
