One BUG found: userpref whitelist pattern BUG/DOC prob;

[Linda Walsh <sa...@tlinx.org>]

Bowie Bailey wrote:
> Linda Walsh wrote:
>> I get many emails addressed to internal sendmail <id>'s.
>>   123456@mydomain,       1abd56.ef7890@mydomain
>>
>> (seem to fit a basic pattern but don't know how to specify the
>> pattern (or I don't have it right):
>>   <(start of an email-address)>[0-9][0-9a-fA-F\.]+\@mydomain

> I think this is what you are looking for (untested):
> 
> header MY_NUMBER_EMAIL To:addr =~ /^\d[0-9a-f\.]+\@mydomain/i
> 
> Look in the "Rule Definition" section of the man page for
> Mail::SpamAssassin::Conf for more info on the ':addr' option.
--------------

	I found, BURIED, in the doc "Mail::SpamAssassin::Conf the broken,
primitive rules for white/black list patterns allowed:

            Whitelist and blacklist addresses are now file-glob-style patterns,
            so "friend@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".

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".

Attempts to match <user-id's> of form:
     "^[0-9][0-9a-f].*.domain$"      (ex: "0123@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
    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*")

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.6ab89c@domain" as email addrs, which in my setup are completely
bogus.

-linda

Re: One BUG found: userpref whitelist pattern BUG/DOC prob;

[LuKreme <kr...@kreme.com>]

On 1-Apr-2009, at 13:12, Linda Walsh wrote:
> 	I found, BURIED, in the doc "Mail::SpamAssassin::Conf the broken,
> primitive rules for white/black list patterns allowed:
>
>           Whitelist and blacklist addresses are now file-glob-style  
> patterns,
>           so "friend@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.


This text is pretty much in the default user_prefs file.

# Whitelist and blacklist addresses are now file-glob-style patterns, so
# "friend@somewhere.com", "*@isp.com", or "*.domain.net" will all work.
# whitelist_from        someone@somewhere.com

> "[0-9][0-9a-f]*.domain", "[0-9]*.domain", "[^0-9]*.domain"

[0-9] is a regex. So is [^0-9]. It's just that most shells support  
most basic regex.

> 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".

Yes it is clear.  Since @domain is not the same globbing as *@domain*,  
the matches ar enot the same.  ^ and $ are part of 'all other  
metacharacters' and not supported.

Granted, I think the lack of regex support in whitelist is a really  
stupid mistake, but that's me and I'm probably wrong.


-- 
Advance and attack! Attack and destroy! Destroy and rejoice!