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 <m...@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
