Lucio, > This is a shorter request for clarification (see previous longer post for > details) about our attempt to replace our pure sendmail with DNSBL > filtering policy with one based on sendmail 8.13.1, amavisd-new-2.1.2 in > the "milter" configuration and spamassassin (spamd ??) 3.0.4
Before going into details: your life would be easier by switching to Postfix. TLS is easy, and interfacing to IMAP, Mailman, webmail, procmail is no more difficult than in sendmail. Sendmail+milter setup with heavy-weight filter like SA offers poor control on mail rush-ins. Not to mention that amavisd-new would gain full control on mail header edits. A price for keeping congestions under control would be a loss of ability to REJECT spam (except for greylisting and obvious violations). > What we want to achieve is that : filtering is all performed on one of our > "entrance" MX machines; spam is quarantined (not tagged and not delivered > to recipient) ; spam generates an explanatory reject error (to inform > generators of false positives) ; the other messages are forwarded to the > user workstations (NO centralized delivery) ; we exploit the spamassassin > auto-learning and auto-whitelisting capabilities. > QUESTION 0) is spamd necessary ? No. The amavisd daemon behaves just like spamd and is used in its place. > In our present configuration we start (in the order) : spamd, > amavisd-new with its milter, sendmail. > > I thought the milter will act as an intermediate layer between > sendmail and amavisd-new and the latter was talking with spamd > > but now I have the doubt that it calls spamassassin modules > directly without need of spamd > > Shall we run spamd or not ? If your clients do not call spamc/spamd on their own (like for per-recipient rulesets), you don't need spamd if you have amavisd-new. > Having realized that the default milter coming with amavisd-new does not > perform full spamassassin header editing, we remain with the more radical > doubt > > QUESTION 5) bayes autolearn and autowhitelist > > Are these spamassassin features working in milter configuration, or > are they forbidden ? In latter case is there a workaround ? Bayes autolearn and autowhitelist work just fine with amavisd-new, no matter how it interfaces with MTA. A global Bayes database is used though - which can be a benefit or a drawback, depending on diversity of your users. > The above question is quite relevant. We thought to "train" the bayes > filter with a collection of old spam (we plan to do it next week), but if > it does not autolearn, is there any sense with it ? If you have a good set of rules (SA 3.1.2 and recent SARE rules) and usual networks tests like DCC, Razor2 and RBL/URIBL enabled, there is probably no need to pre-train bayes, just let it autolearn for a couple of days of regular mail traffic, perhaps with temporarily lowered scores for BAYES_* rules. Later it suffices to feed it an occasional FP and FN. > I also have a curiosity question > > QUESTION 3) Hits: - in syslog > > We see in the mail log some "amavis Passed CLEAN" entries which have a > non-numeric spamassassin score (Hits: -). A '-' score means SA didn't produce any score. It normally means SA was not called by amavisd because mail was too big (over $sa_mail_body_size_limit), or spam checking was disabled for all recipients of the message (bypass_*) or sender was black or whitelisted for all recipients. > Is this related to $sa_timeout ? Rarely. > Should we raise this timeout to a value > higher than default ? Will it be honoured in milter configuration ? The default in amavisd-new 2.4.1 suffices (and is larger and computed differently than in previous versions). Setting the $sa_timeout is now unnecessary. 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/
