James Nelson wrote:
[...] I would agree with that, but the server in question is handling several hundred thousand messages a day and the only ones not being scored for some odd reason, contain the habeas data. I do think the two are linked. I just can't figure out why. I know it should not act in this manner, but it is.
One thought is that habeas checks just happen to be "one check too many" for the default timeout setting. more below...
As I said before, I do have scored and blocked messages that contain habeas data. But of all the unscored email, they ALL contain the fake habeas headers. Its got to be more than just a coincidence.
If spamc fails, it will return the unmodified message, so what you're seeing makes sense. Test it manually to verify. Could it be a timeout issue? spamc fails silently, then just returns the (unscored) message in that case (using now default -f setting. read up in spamc manpage on -x -- though I wouldn't recommend that just yet.)
I will try running the message directly with spamc and spamassassin and see what happens. Currently I am scanning them through procmail to spamc. I am running a centralized bayes db, and using most of the custom rules contained on the wiki site, no other tools are being used but the default scoring.
If testing manually (on same system) and it fails, perhaps try "-t 30" or higher and see if it eventually DOES complete, or just hangs indefinitely.
Users do have custom user_prefs that may contain whitelist_from, blcklist_from, and lower thresholds but no other settings as the user_prefs files are controlled via a custom web application.
Sounds like all of that is being skipped, due to some sort of failure.
Good luck with it!
- Bob
