On 2/28/06, Mark Sapiro <msapiro@value.net> wrote:

If you really think this is resulting in messages being discarded that shouldn't be, I suggest you remove the KNOWN_SPAMMERS entry from mm_cfg.py and instead, put

^X-Spam-Status:\s*Yes

in header_filter_rules for some of the problem lists with action Hold.

I just got done configuring something very similar, but I was having problems. I was originally matching against '^X-Spam-Status: Yes', which never matched. Removing the '^' did the trick. I'm not sure why this is.

--

• Patrick Bogen

Mark Saprio 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.*

(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.)

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').

On 3/1/06, Joel Heenan <joel.heenan@sensorynetworks.com> wrote:

I'll do some research if I get time today but I'm fairly sure something is borked with this spam filtering. Looking through the code I can see that if a header is not found its not supposed to return a spam match. My SpamDetect module looks alright (to my largely python-ignorant eyes). See above for why this wasn't working. 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.

• Patrick Bogen

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