[Mailman-Users] Regular expressions in list config files?

[Mark Sapiro]

bernholdtde at ornl.gov wrote:

>On Tue, 19 Feb 2008 08:35:12 -0800  Mark Sapiro wrote:
>> Are you saying you see this with bin/dumpdb of the config.pck. If so,
>> that's just the way python is showing the representation of the
>> string. It is not the actual value of the string. If you doubt that,
>> try 'strings' instead of 'bin/dumpdb'.
>
>Ah, that seems to be it.  dumpdb, config_list, and the web u/i all
>show the quoting of the backslashes, but strings on the pickle show it
>as I entered it.  (Too bad such things don't "roundtrip" properly
>through tools that are supposed to do that, like config_list and the
>web u/i.)


What Mailman version is this. In my case, the web u/i shows the value I
enter without doubling the '\'.

Also, the 'round trip' issue seems OK, at least for config_list -o
followed by config_list -i. config_list reads the \\s and converts \\
to a literal \ so what gets put in the config is '\' followed by 's'
which is exactly what you want. If you gave config_list something like

header_filter_rules = [('^x-header:\s+some value$', 0, False)]

it would interpret '\s' as a literal 's' and you would lose the '\'.
config_list needs either

header_filter_rules = [('^x-header:\\s+some value$', 0, False)]

or

header_filter_rules = [(r'^x-header:\s+some value$', 0, False)]

Note that there is a big difference between '\s' in a string and say
'\n'. '\s' is two characters. '\' and 's' whereas '\n' is a single
newline character.


>So the next question is why doesn't the header_filter_rules appear to
>be working? Message are getting held (which is what I'm doing for
>testing purposes), but the indicated reason is non-subscriber posting
>rather than the header filter. (Both conditions are true for the
>majority of junk that comes through, but there are some lists where I
>really do need to allow legitimate non-subscriber posts, with
>moderator approvals.)


Good question. I think we need to determine why the web u/i is showing
the doubled '\'. It shouldn't, and whatever is making it do so, may
also be the reason for the rules not matching.


>As I understand it, SpamDetect runs before Hold, and I thought that
>the first exception kicked it out of the handler processing.


That is correct.


>Is there some logging I can turn on to see more details as to what's
>going on in here?


Unfortunately, no. You have to actually code additional logging in the
handler.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan