On 02/12/2017 05:27 PM, Barry Warsaw wrote:
Certainly some narrowing is appropriate. We could just clamp it down as you suggest, understanding that there may already be lists in existence that use the more liberal character set, and acknowledging that we may want to relax the set based on future bug reports.
What about this: come up with an absolute black list set, e.g. the ones that will break Mailman. Come up with a second set of discouraged but allowed characters, and a third set which is the narrow list you propose. Then make the allowable set configurable, except that the black list characters are always disallowed. Now, that might be too complicated, so I'm also fine with making it narrow now, and letting the set relax based on user feedback.
Thanks Barry. FWIW, MM 2.1 has an ACCEPTABLE_LISTNAME_CHARACTERS config setting which defaults to '[-+_.=a-z0-9]'. I don't really like the + and = in that list because of their possible interaction with VERP. I have a WIP MR at <https://gitlab.com/mailman/mailman/merge_requests/248> that allows only [-_.a-z0-9] (IGNORECASE) and has no config override.
The narrow, overridable config combined with a blacklist or some kind of limitation on the overrides would be the most flexible. I'll look at adding that to the MR. Basically, I'm thinking of a fixed list of allowed characters which is liberal, testing that first and if that passes, testing the config set.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan