bernholdtde@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@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan