> On 15 Feb 2016, at 02:12, John Hardin <jhar...@impsec.org> wrote: > > On Sun, 14 Feb 2016, RW wrote: > >> On Sun, 14 Feb 2016 12:22:36 +0800 >> Tino de Bruijn wrote: >> >>> I have some trouble filtering my spam, as everything I try from the >>> commandline works fine (spamc -t < spam.eml , where spam.eml is a >>> spam message i dragged out of Mail.app and uploaded to the server), >>> but when delivered to SA by my MTA (Haraka), it gets a way too low >>> score (11 vs 3.5 respectively). The spamd.log shows that the online >>> blacklist checks are not run in the last case: >> >> Even without the DNS problem implied by URIBL_BLOCKED, it's fairly >> common to get a much higher score on a retest. The reason is simply that >> that new IP addresses and domains take some time to get listed. > > That's most likely the cause here. The presence of URIBL_BLOCKED in the MTA > results shows that DNS BL lookups *are* working. > > If you have some way to re-inject that message into your mail stream for > processing, I wager you'd see new BL hits now from the MTA as well.
Ah, I guess you are right. I notice some URIBL_DBL_SPAM for example in other messages that do get scored properly. Hmm, so I guess I’ll have to train the bayes filter more to get rid of those messages then right? On a side note, I have set up bind9 as a local, non-forwarding resolver, and it’s configured as the only nameserver. This test works: # host -tA 2.0.0.127.multi.uribl.com 2.0.0.127.multi.uribl.com has address 127.0.0.14 but spamassassin still generates URIBL_BLOCKED. Any suggestions on this? Thanks, Tino
