Lucio, > a) we presently run only spam checking, no virus checking
I'd recommend adding (at least) clamd to the mix for two reasons: if amavisd-new knows the content is infected it won't call SA and won't do it's spam-related actions on spammy-looking viruses. This saves time because virus checking with clamd is much faster than spam checking, and it prevents backscatter in a dual-MTA setup (this is a non-issue in a pre-queue setup like milter if you REJECT mail, but REJECTing viruses can produce secondary backscatter from the sending MTA anyway and is undesirable nevertheless). > b) we defined $final_spam_destiny = D_REJECT; > c) we defined $QUARANTINEDIR to be a file (Unix mbox folder) I'd recommend quarantining to individual files (or to SQL). The amavisd-release utility is unable to release quarantined mail from a mbox file. > d) we have $sa_tag_level_deflt = -999, $sa_tag2_level_deflt = 4.5, > $sa_kill_level_deflt = 4.5, $sa_dsn_cutoff_level = -999 as > in the GARR recommended configuration > > As a result of the above all spam above 4.5 (which seems pretty OK) > is NOT delivered to the recipient, but quarantined to the virusmails > folder. We plan to rotate the folder daily and send to each user one > mail with the report of the spam received. 4.5 is too low for a kill level. A 6 is more like it. Presenting recipient with false positives gives spam filter a bad reputation, it is better to err slightly in the other direction. Consider http://www.MailZu.net/ if your decide to use SQL for quarantining and reporting. > QUESTION 2) Do I interpret correctly the various statements in > http://www.ijs.si/software/amavisd/ meaning that no header editing AT ALL > is performed when using the milter ? Yes, with a milter helper that comes with a package. It is a limitation of the old amavis client protocol. The solution was provided by implementing alternative protocol (AM.PDP), and Petr's milter supports it. > f) we tried to edit $X_HEADER_TAG = 'X-Virus-Spam-Scanned' so that the > recipient could see that a spam scan was done and where, but it looks > like that in passed mail we get only the "standard" > X-Virus-Scanned: by amavisd-new > without indication of host nor of our editing. This is specific to old milter helper program, which inserts this header by itself, without ability to obtain it from amavisd daemon. AM.PDP overcomes this limitation. > g) we have $sa_auto_whitelist = 1 , and we have Bayes filter configured > in spamassassin local.cf ... but we doubt that they are operating. $sa_auto_whitelist is irrelevant with newer versions of SA. >From amavisd.conf-sample: $sa_auto_whitelist = 1; # turn on AWL in SA 2.63 or older (irrelevant # for SA 3.0, its cf option is use_auto_whitelist) > The bayes and auto-whitelist files have size zero, Make sure these files are owned/writable by uid under which amavisd is running (usually vscan or amavis). Try to manually feed one spam sample to sa-learn just to see that it it able to update the database: su vscan -c 'sa-learn --spam test.msg' Run 'amavisd debug-sa' for a short while to be able to see if SA is reporing any problems. > h) we have all $warn*sender=0 and $warn*recip=1. Let's just forget that $warn*sender settings ever existed. It is off by default anyway. $warn*recip=1 is mostly unproductive: replacing one spam message with another locally generated is more annoying than letting spam (tagged as such) through. > Rule of the house : use software bundled with OS distribution (in this > case SuSE 9.2) unless there are good reasons not to. Are there any ? We are slowly loosing amavisd-new-2.1.2 out of sight (September 2004), you should at least go to 2.3.3 or preferably to 2.4.1, if for no other reasons for better maintainability (better handling and/or clearer logging of problems). The long list of reasons is available in RELEASE_NOTES. Most advice and examples on the mailing list refer to 2.4.x (or sometimes to 2.3.3). > May 25 09:42:20 oort amavis[32186]: (k4P7gEmL032286) Passed CLEAN, <xxxx> > -> <yyyy>, Hits: -, tag=-990, tag2=4.5, kill=4.5, L/0/0/0 Are you sure you don't have spam checks bypassed? Look at amavisd log, increase the $log_level for starters (a 2 is a good compromise). > If it were an (unlogged) timeout, should we tweak $sa_timeout ? With 2.4.1 there is no need to tweak $sa_timeout > What are sensible values ? Should be less than $child_timeout, which in turn should be less than milter timeout. If you have Bayes on a berkeley db, which handles auto-expiry very slowly, one indeed had to increase $sa_timeout in versions before 2.4.1. A better solution is to have Bayes on SQL, which expires tokens much faster, so all the problems with slow bayes auto-expiry and an occasional corrupted Bayes database are avoided. Mark _______________________________________________ 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/
