[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
------------------------------------------------------
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Security Policy:
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
