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

2017-02-12 Thread Mark Sapiro 
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  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 The highway is for gamblers,
San Francisco Bay Area, Californiabetter 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

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

2017-02-12 Thread 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 b...@example.com and
b...@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@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
___
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