On Sat, 2016-12-17 at 13:03 -0800, frede...@ofb.net wrote: > I'm still investigating the problem, but I just noticed that > "spamassassin" gives the message a score of 12.0, while > "spamc"/"spamd" (which my mail setup is configured to use) still give > it a 4.0. So it seems that something more mundane is going on, > although I'm not sure what. I hope it's not that I've just done > something stupid again. > Two possibilities:
1) If running the message through spamassassin hits a lot of URIBL and DNSBL rules that the spamc/spamd run didn't AND this was done some time after spamc/spamd scanned the message then thats normal because the blacklists now know about the new spam source. 2) Are you sure, i.e. can you prove that, both spamassassin and spamc/spamd are using the same configuration? A way to check that would be to run the message through spamassassin and immediately run it through spamc/spamd, i.e: $ spamassasin <spam.txt >spam1.out; spamc <spam.txt >spam2.out $ diff spam1.out spam2.out If the lists of rule hits in the two outputs differ, then its likely that spamassassin and spamc are not using the same configuration. IOW your comparisons between spamassassin and spamc results are meaningless and will remain so until you've arranged things so that both are using the same configuration. In general, if the configuration is in the default location, /etc/mail/spamassassin on my systems, and both spamassassin and spamc are using the default configuration, they should both be using the same one, but if you're using glue like amavis-new to run spamassassin then this may not be true. FWIW my SA rule development and test setup runs on a different machine from the one running my live SA installation, BUT: - both SA instances keep their configurations in the default location for my OS (Fedora Linux) - both run SA as the spamd daemon and use spamc to pass messages to it - I use a set of bash scripts to maintain the production SA configuration by copying the complete configuration from my SA test and development environment to the production environment and immediately restart the production spamd instance. Thus, although the production system runs SA as part of my getmail MDA script while my development system has a manually triggered bash script that I use to feed selected test messages to spamc, as far as SA is concerned, the two environments and SA configurations are effectively identical. Martin > Also, it seems that I should have set up a "caching nameserver". I've > attached the report from "spamassassin -t" (with a "URIBL_BLOCKED" > rule). > > Thank you, > > Frederick > > On Sat, Dec 17, 2016 at 07:16:43PM +0000, David Jones wrote: > > > > > > > > > > From: RW <rwmailli...@googlemail.com> > > > Sent: Saturday, December 17, 2016 8:02 AM > > > To: users@spamassassin.apache.org > > > Subject: Re: recent increase in spam getting through > > > > > > > > On Sat, 17 Dec 2016 13:35:16 +0000 > > > David Jones wrote: > > > > > > > > > > > > > > > That mail server IP above is on a very high number of RBLs: > > > > http://multirbl.valli.org/lookup/173.230.94.183.html > > > > > > > > > > MultiRBL.valli.org - Results of the query 173.230.94.183 > > > multirbl.valli.org > > > DNSBL and FCrDNS test results of the query '173.230.94.183'. > > > > > > > > > > > > > > > > > The edge MX server 104.197.242.163 must not be doing any > > > > MTA checks of RBLs. > > > > > > > > > > As I already mentioned it's normal to get huge scores when > > > retesting > > > spam because most net rules are reactive. It doesn't imply > > > anything > > > about RBL results at the time it was received. > > > > When I looked at that RBL link above a few hours ago, it was listed > > on > > 30 RBLs and now it says 42 so I agree with you that this is not a > > direct > > indicator of receive time results. I use that link above after the > > receive > > time just to get a quick idea how bad it is. When I see a mail > > server IP > > with more than 10 to 12 hits, then it has been sending spam > > recently. > > > > My point was that a mail server doesn't get listed on 30 or 42 RBLs > > in > > a few hours. It would have to have been sending a lot of spam for > > at > > least a few days so this email would have been blocked by > > postscreen > > on my servers for weeks. Looking at the senderscore.org report for > > that IP, it has been sending spam for about 3 weeks and has a score > > of 0 out of 100. Trustworthy mail servers should have a score in > > the > > 90's. > > > > SA comes with a few major RBL rules that should have blocked this > > message recently. With Postfix postscreen configured with major > > RBLs weighted high and less reliable RBLs weighted lower, you can > > get much better blocking at the MTA level using dozens of RBLs' > > combined scoring. Each mail admin has to assess which RBLs > > are considered reliable for their location and users. > > > > If the edge MX server just had a single zen.spamhaus.org RBL > > configured and assuming it would be querying under the free > > limit, then that email most likely would have been rejected before > > SA and the OP would have never started this thread.
