Lucio, > We have an institute-wide spamassassin+amavisd arrangement running on our > mx's, which generally behaves very well. Spam is quarantined in a system > wide folder, and then a daily crontab sends a "spam report" to each user > (so that they can reclaim false positives, which occurs about once per > month). > > We have this in the spamassassin systemwide local.cf > > whitelist_from x...@lambrate.inaf.it > whitelist_from x...@iasf-milano.inaf.it > whitelist_from_rcvd *...@lambrate.inaf.it lambrate.inaf.it > whitelist_from_rcvd *...@iasf-milano.inaf.it lambrate.inaf.it > > which we interpreted as : > > - everything coming "apparently" (From kwd) xyzt (not the real username, > anyhow it's our system manager personal account) should pass unfiltered
Yes. Not safe to use, get rid of it if you can. > - everything coming THROUGH (Received kwd) one of our local machines, > from an user in either one of our two domains, should pass unfiltered Right. > Now reading "perldoc Mail::SpamAssassin::Conf", I find > > whitelist_from_rcvd a...@lists.sourceforge.net sourceforge.net > Use this to supplement the whitelist_from addresses with a > check against the Received headers. > > ... the word "supplement" leaves me perplexed. Does this mean the two > conditions above are ANDed instead of ORed ? The description is misleading, each whitelisting mechanism functions independently. So, the answer to your question is "OR" - each whitelist mechanism which triggers, contributes its negative score points. As it happens, if a whitelist_from fires, a test for whitelist_from_rcvd is skipped, but this can be regarded as just an optimization trick. Perhaps a phrasing like the following would be more appropriate: <<< Use this to supplement the whitelist_from addresses with a check against the Received headers. >>> Works similarly to whitelist_from, except that in addition to matching a sender address, a relay's rDNS name must match too for the whitelisting rule to fire. > If so, messages coming e.g. from r...@ourserver.lambrate.inaf.it should > not be subject to the whitelist_from_rcvd (which is not what we want). The r...@ourserver.lambrate.inaf.it doesn't match any of your sender patterns: x...@lambrate.inaf.it, x...@iasf-milano.inaf.it, *...@lambrate.inaf.it, *...@iasf-milano.inaf.it, so no whitelisting takes place. > In fact we noticed (for the first time, and after a long weekend holiday > during which there was a burst of spam, which was quenched in a couple of > days) that a few of our daily spam reports (originated by the crontab and > sent as r...@ourserver.lambrate.inaf.it) were quarantined (and also the > relevant mailer-daemon replies), with a score marginally above threshold. > > We did also a check_whitelist /etc/mail/spamassassin/awlst/awl looking for > address r...@ourserver.lambrate.inaf.it and ip=155.253 (so truly > from our LAN), and found a score of -1.0 (which should mean it is > correctly whitelisted). Don't confuse AWL with whitelisting. AWL is just an averaging mechanism, independent from whitelist_from, whitelist_from_rcvd, and other whitelist rules. > Nevertheless the reports were quarantined. So the suspects are : > > - whitelist_from_rcvd does NOT unconditionally whitelist messages > irrespective of other scores > > - whitelist_from_rcvd is de facto NOT ENABLED for root (because of > the AND/OR confusion quoted above) > > Any clue ? Thanks You need to add a whitelist_from_rcvd rule which will match your sending address r...@ourserver.lambrate.inaf.it, something like: whitelist_from_rcvd r...@ourserver.lambrate.inaf.it lambrate.inaf.it or relax your existing rule, like: whitelist_from_rcvd *...@lambrate.inaf.it lambrate.inaf.it whitelist_from_rcvd *...@*.lambrate.inaf.it lambrate.inaf.it Mark
