[Mailman-Developers] Regexp filtering

[Barry Warsaw]

On Feb 27, 2016, at 02:02 PM, Stephen J. Turnbull wrote:

>I hope we haven't propagated this rather user-unfriendly interface
>(the convention of accepting both regexps and literals, distinguishing
>by "^" in column 0) to Mailman 3.

Sadly, it's true.

Mostly this is historical since we've essentially just ported the data and
code from Mailman 2.  It was implemented this way because of the limitations
for data modeling, and the unsophisticated web ui in MM2.

We could do better in MM3, both because we can model the data better, we can
expose the distinction in REST, and Postorius could expose the difference in a
much better web ui.

Here's a rough sketch of what you'd have to do in the core to make this
change.  As always merge requests are welcome!

IBan would need to have a flag which indicate whether the `email` is a literal
address or a pattern.  I don't think it's worth having two separate
interfaces/models, but we might want to rename `email` to something more
generic (`pattern` would be fine, with the understanding that is_regexp=False
means the pattern is a literal).  You'll need to change a bunch of checks and
what-not in the ban management code.

This also shows up in AcceptableAliases, so a similar change would have to be
made to IAcceptableAlias, the various model implementation bits of that
interface, and the implicit_dest.py rule.

The REST API for these would probably need some additional work, but that
can't easily be done.  The trickiest part would be if IBan.email is renamed,
in which case you'd probably want to continue to accept the old data format
for the 3.0 API (and translate it into the new model layer), but only accept
the new data format in the 3.1 API.  There are examples of how to do
API-version differentiation.

It's still used in the *_these_nonmember checks (moderation.py rule), but as
these are legacy facilities from Mailman 2, I'm not sure they need to change.
Eventually, we want to remove these settings anyway, since all the
functionality is implemented differently and better in MM3 already.

Another odd use of this is in the `withlist` subcommand.

(It's also used in the wsgiref/falcon plumbing layer, but since that's all
internal implementation details, nothing here needs to change.)

You'd need to handle database migrations and documentation updates too, along
with a robust test suite, but there's nothing intractable about any of this.

Cheers,
-Barry