[Mailman-Developers] What characters should be allowed in listnames

[Barry Warsaw]

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 at example.com and
BOB at 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 at 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