SA Bugzilla – Bug 524
AWL should ignore whitelist_from entries
Last modified: 2002-08-14 08:58:18 UTC
First - the bug. I'm using a common file for AWL rather than personal DB files. The reason is - I'm running virtual email and there is no real users. Having said that, if the permissions on the common DB file are wrong, SA fails to score the message. It also creates the DB file with the wrong permissions for shared access. What should happen is that if there is a DB access error, it should just ship that test gracefully and report an error about the access denial to the DB file. ------------- Second issue. Many spammers who spam me use my own email address as the return address as if I'm sending it to myself. And because of that they score white points based on my own white email history. So - if the delivery address matches the from address or return path - then AWL points should not be calculated. There should also be other logic to not assign AWL points from forged email - especially if it gains the impersonator white points. -------------- Third - and I can't really document this - but there are messages that come from spammers that get assigned white points for no reason at all - and one case where one of our staff got assigned black points for no reason - as if the database is confused as to who is who. -------------- And finally - I really like AWL if it would work better that would be great.
Since a few AWL issues are being lumped together here, let me add one more: the AWL should not count messages that are whitelisted due to a whitelist_from entry. Example: I get a spam with user@oreilly.com as a forged From address. Oreilly.com is listed in whitelist_from, so the message gets -100 points. I remove the whitelist_from entry to prevent this. The next spam that has this forged address gets -80 or so points from the AWL. In other words, the AWL is serving to make whitelist_from entries "sticky" long after they're removed...
ok, the first 2 parts of this bug ;) are fixed. the 3rd one is a bit tricky and I think will need more info. the last one -- Mike's -- I'm not going to get into this late before 2.40. resolving to LATER....