On Feb 12, 2017, at 03:58 PM, Mark Sapiro wrote:
Core validates listnames by ensuring the fqdn_listname is a valid email address. This is too liberal. RFC 5321 allows many characters in the local part of a list name. We don't allow quite all of them, but we allow this set [-0-9a-z!#$%&'*+./=?@_`{}~].
Since list names form parts of a URI, both in Postorius/HyperKitty and in the Core's REST API, it is clear that characters that will cause problems there should not be allowed. These include [#%&/?] and maybe others.
I suppose if we did continue to allow them, they would have to be escaped in the URL. I'm not sure how much that helps, or even whether it should be part of our decision to allow them or not.
Additionally, I don't think we want @ in an email address local part and + and = might cause problems with VERP which whittles it down to [-0-9a-z!$'*._`{}~], but I'm thinking of being even more conservative and going with just [-0-9a-z._].
I think it's entirely reasonable for Mailman to narrow the list of allowable characters in the local part of list names. We already make some opinionated decisions about allowable email addresses; for example, we support case-preserving, case-insensitive addresses so we treat bob@example.com and BOB@example.com as identical.
I'm amenable to the conservative set you propose (obviously, case insensitive), although I have some concerns about how dots in the local part would interfere with any List-ID operations. E.g. foo.bar@example.com becomes List-ID: foo.bar.example.com. As an identifier with comparison rules according to RFC 2919 I think it's fine (it just has to be unique). I'm not sure whether in practice it would cause problems with the core.
The other question is whether we're unfairly closing the door on i18n list names. OTOH, we haven't yet had any requests for that afaict.
I don't intend to change the email address validation except maybe to remove @, but the code is such that an address with multiple @ won't validate anyway.
I'd like feedback on this. What are your thoughts on what characters should be allowed in list names?
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.
Cheers, -Barry