Linda Walsh wrote: > > I found, BURIED, in the doc "Mail::SpamAssassin::Conf the broken, > primitive rules for white/black list patterns allowed:
Where else would they be? This is the main location for documentation of the SA configuration and rule definitions. > Whitelist and blacklist addresses are now file-glob-style > patterns, so "fri...@somewhere.com", "*...@isp.com", or > "*.domain.net" will all work. Specifically, "*" and "?" > are allowed, but all other metacharacters are not. > Regular expressions are not used for security reasons. > ======================= > > These are NOT file-glob style patterns. As on linux > These are examples of non-regex file-glob patterns that don't work > under > SA: "[0-9][0-9a-f]*.domain", "[0-9]*.domain", "[^0-9]*.domain". The documentation you quoted above clearly states that only "*" and "?" metacharacters are allowed. > They don't work: the "bracket notation for a single character" > doesn't work. > 1) Instead you need: > 0*.domain > 1*.domain > 2*.domain > 3*.domain > 4*.domain > 5*.domain > 6*.domain > 7*.domain > 8*.domain > 9*.domain > ----- > 2) There is no way to express negation. > 3) The documentation is ALSO unclear if the expression is a full or > partial match, as "^ and "$" are also not included. > So unclear if "@domain" is same as "*...@domain". If it's a fileglob-style match, then it would have to be a full match. > Attempts to match <user-id's> of form: > "^[0-9][0-9a-f].*.domain$" (ex: "0...@domain") > fail to match as well as any more complex file-glob. > > white/black lists should not claim 'file-glob' matching ability if > they don't even include single char 'range' matches. > > This was the answer THAT NO ONE understood or could answer. > > If the format of white/black list entries in 'userprefs' is SO > arcane, limited, and poorly documented, I assert it is a bug. > > Short-term, documentation would be quickest fix (get rid of file-glob > description as it's not true in normal sense of fileglob, but longer > term, might be real-file globs The documentation already states exactly what is allowed. > AND > making clear whether the pattern provided must match the full email > address, or if a partial match will be considered a a positive match > (i.e. "@foobar" is same as "*...@foobar*") I agree that it would be useful to have this stated explicitly in the documentation. > Sorry if I am coming across a bit terse, but this hard-to-find and > misleading description has been a long-term "bug" in my filtering > rules. > > Seems like a alot of email-harvesting progs see mail-ID numbers like > "12345.6ab...@domain" as email addrs, which in my setup are completely > bogus. I can see that it would be useful to have full (or at least limited) regex abilities here. The docs say that this is not done for security reasons. I'm not sure what the security concern is here, but maybe they will get it changed eventually. At the moment, you can get a similar effect by using header rules such as I posted previously. -- Bowie
