Patrick Bogen wrote:
Mark Sapiro wrote:
The messages are being discarded because they have an
X-Spam-Status: Yes
Mark, this isn't strictly correct, I think. cre.search() is going to look for any place in the string where the regex matches, so they're *actually* being discarded because they have a header: X-Spam-Status: .*Yes.*
You are correct. I was thinking of Spamassassin's X-Spam-Flag: header which is either "X-Spam-Flag: YES" or absent, and which is much safer to test than X-Spam-Status: for exactly these reasons.
(Assuming the leading space is stripped when the header value is stored in a message- this seems like reasonable behaviour to me, but I'm not sure what the protocol says about spaces there.)
SpamDetect, when checking KNOWN_SPAMMERS uses the get_all() message method to get the contents of all the headers of a type. In this case, a list of the contents of all the X-Spam-Status: headers in the message. Leading spaces between "X-Spam-Status:" and the first non-blank of the rest of the header are stripped, but trailing spaces if any are not.
Now, here's the problem with this.
X-Spam-Status for a non-spam message may look like:
X-Spam-Status: No, score=-5.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 ...
(and keeps going for a while.)
As should be pretty obvious, 'Yes' case-insensitively is found in 'BAYES'. This won't occur with the header_filter_rules, because they match the header as a line, rather than treating the value separately. So, as an alternative, it should be possible to use a KNOWN_SPAMMER of ('X-Spam-Status', '^Yes').
Correct, but I'd still use X-Spam-Flag:.
I think it's pretty unlikely that any of your messages /don't/ have the X-Spam-Status, assuming you're doing your own scanning.
I think that's correct and may well explain why they were all deleted.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan