Why would a Match, looking in the body, using *1*@*.* not find test339113test[at]test.com?

Well, hard to say with the little bit of information you provided, but perhaps that address was in the headers and not the body? Perhaps it was encoded and your client can see it but spamcop filters can not? Perhaps only certain body types are checked (only html or only plain text)? Perhaps the message is not in the Inbox or is being moved there by another rule? Perhaps multiple *'s are not allowed? Perhaps body filters don't work properly (I don't use them and I don't remember them being offered in the previous version of webmail)?

Body filters do work. Hence the discussion about web filters for Cyrillic using body contains koi8-r
(you also have to test for self-defined header Content-Type: contains koi8-r)

I suggest doing the test varying only one field at a time since I don't even know that * is meant to work, like what if you want to test X-Spam-Level ?

Good point. * does work as a character in that instance because I have a filter to do that (for building my stats from time to time).

X-Spam-Level: *** does not match X-Spam-Level: **

Yes, I did test it adequately, which means I used the webmail interface only. No, I didn't do something stupid. It doesn't work, and it should. No one seems to know why. Disappointing.

But the real question is where the boundary come between what works and what doesn't.

Were all your tests with tiny bodies ?

Does it works with a encoded body like quoted printable, koi8-r etc. ?


So: What does work ?

For the lurkers, this seems to involve the test "matches" (rather than "contains" which is the only test available for every other text field) see the context help available when setting up a new filter field by clicking on the 'lifebelt' on the right. The test on size allows "greater than" and "less than" (units kilobytes at a guess) but that's all.
The explanation also keeps saying 'lines' so do we understand that a test is 'true' if true for any line of the body or what ?

I copy =================
There are 3 components to each condition in a rule. The first is the field to examine. The second is the type of comparison to perform. The third is the value to which the field should be compared. There are a few different types of comparisons that can be performed. The comparisons available for any given field will depend on both the type of the field and what the underlying filtering software can handle. Thus, all potential matching options listed below may not appear for a given field.

Contains
Will be considered to be true if the specified string is found anywhere on the line. Example: user[at]example would match joe_user[at]example.com

Doesn't Contain
Will be considered to be true if the specified string is not found anywhere on the line. Example: user[at]example would not match joe_user[at]example.com

Is
Will be considered to be true if the specified string matches the line exactly. Example: user[at]example.com is user[at]example.com

Isn't
Will be considered to be true if the specified string does not match the line exactly. Example: user[at]example is not user[at]example.com

Begins with
Will be considered to be true if the specified string matches the beginning of the line. Example: user[at]example will match user[at]example.com

Doesn't begin with
Will be considered to be true if the specified string does not match the beginning of the line. Example: user[at]example.com will not match user[at]example

Ends with
Will be considered to be true if the specified string matches the end of the line. Example: example.com will match user[at]example.com

Doesn't end with
Will be considered to be true if the specified string does not match the end of the line. Example: horde.org will not match user[at]example.com

Exists
Will be considered to be true if the specified header exists in the message, regardless of what its value is.

Doesn't Exist
Will be considered to be true if the specified header does not exist in the message.

Regex
Regex allows you to use complex POSIX compatible regular expressions to compare against message headers. Example: "Received from [*\.*\.*\.*] by (hosta|hostb).example.com*" would match "Received from [172.16.100.1] by hosta.example.com on Tuesday"

Matches
Matches is similar to contains, with the exception that you may use * and ? as wildcards. An * will match any number of characters, and a ? will match exactly one charater. Example: "*user?@example.com" will match both "user1[at]example.com" and "otheruser2[at]example.com"

Doesn't match
Doesn't match is the same as matches except that it will evaluate to false if the specified value matches the string in the message header.

Less than
This is a relational test which will compare the value you specify and the value in the message header numerically.

-snipped

Greater than
This is a relational test which will compare the value you specify and the value in the message header numerically.
=========

I was searching for filtering problems and ran across this question.

The regexp that is used by most Unix Shells (ksh, sh, bash, etc) is a little different than the actual regexp syntax defined in most function/method libraries. The function/method libraries are probably what is used in webmail.

The expression that you wrote would work in most shells if you were searching for a file with that name, but may not match as a regexp because it differs from the syntax of a regexp as defined in most function/method manuals.

One place that has a definition of regexp is the Wiki at (http://en.wikipedia.org/wiki/Regular_expression#Syntax), but the definition of the specific regexp parser used is probably best found in the manuals for the libraries being used. Regexp's have been around for a while so, looking at any regexp definition would probably be helpful in any case.

Usually, in a regexp, the asterisk character means any number of the previous character. The asterisk at the beginning of your expression might just match an asterisk, but I'm not sure of that. Since, there is no previous character to the asterisk, the "previous character" method action can't be used, so I'm guessing that the starting asterisk is not used as a wild character, but is used as just an asterisk.

In any case the regular expression you gave might evaluate to: one asterisk followed by zero or more numeric 1's followed by zero or more asterisks followed by anything (even nothing).

If that is the correct interpretation, then the regular expression would not match your test case because:

1) There is no asterisk before the 1
2) The 1 isn't followed by an @ sign

This is just my interpretation of the regular expression that you gave in your example.

In the example that you gave, I would write the regular expression in a different way. For your example, I would think you would have to write it this way:

.*1.*@.*\..*

The .* matches any character of any length including zero (meaning that it matches nothing) followed by the single digit of "1" followed by again any character of any length including zero followed by the at sign followed by again any character of any length including zero followed by a single period followed by again any character of any length including zero.

I would point out that this would even match the three character string: 1 @ . (I had to add spaces for the forum parser.)

I'm not sure what webmail uses, but michaelanglo made the comment that a regexp can contain POSIX compliant regular expressions. If that is true, you might be able to be pretty specific about your regular expressions.

Correction ... That sentence should have read:

The regular expression you gave might evaluate to: one asterisk followed by zero or more numeric 1's followed by zero or more at signs followed by anything (even nothing).