[Mailman3-dev] Suggestions for MMV3

Barry Warsaw barry at python.org
Mon Mar 15 18:41:48 EST 2004

On Mon, 2004-03-15 at 00:12, Jon Carnes wrote:
> we should consider contacting folks like CPanel who already incorporate
> Mailman in their products and see what we can do to make it easier for
> them, and what features they would like to see most in the next version.

I've sent messages to the CPanel folks, inviting them to join this
list.  If there are any other big 3rd party folks you know of, feel free
to let them know about this list.  It's all in the open and everyone can
voice their opinions.

> I've also had some comments from folks who really don't like the use of
> <listname>-bounces as the sender of email lists in version 2.1.  If we
> could rename this to something like <listname>-distribute it would help
> folks who are using broken MTU's that display the envelope sender.

I get that complaint sometimes too.  It irks me to have to worm around
broken MUAs, but I also don't like to get crushed by the 800lb gorillas.

> Also, we need to more fully automate the aliases creations for various
> MTA's.  I would be happy to work on this for MMv3.  It should be easy
> enough for folks to input their MTA into a variable in mm_cfg.py and
> then to code the aliases creation based on that information. For some
> MTA's this might mean modifying the exiting rights of aliases files...

What part of MM2 doesn't work here?  I think the current basic
architecture is sound, but maybe we could just use more input from other
MTA authors.  AFAIK, at least Postfix, Qmail, and Exim are fairly well
supported, and I think Sendmail works too.

> The big feature that all folks will be looking for is the ability to
> create same name lists on different virtual domains.

Yes, absolutely.  This is a requirement.

> A web-based Stat's page per list (and one for whole domains) would also
> be nice to see added as a built-in feature.

The key for MM3 right now is to make sure we gather and log relevant
stats.  Once we do that, we (or 3rd parties) can build the pretty gui's
to display this information.

> Built-in integration with HTDig would enable a lot of folks to stop
> rolling their own RPM's or installing from source (just to get the HTDig
> patches).

We're going to have to discuss uber-distros.  OT1H I'm not psyched about
including 3rd party applications that have a lifecycle of their own, but
OTOH, we'll probably end up doing some of that anyway.  I'm not sure
what the right thing is here.

> A link to the web-based FAQ, included with error dumps might also
> alleviate some users pain for common Mailman problems

Interesting idea.

> A web-based tool for editing/removing older archives for a list (a
> pipermail request). A lot of folks would like the ability to remove
> single messages from the arhives, as well as archived messages older
> than a specified date. I can help with this, as I've already written
> some stuff that does something similar (though I would have to re-do it
> in Python :-)

:)  Yep, this is another reason why I think we want some kind of message
store.  And possibly a dynamic archive interface (i.e. a process, not
from the file system directly).

> Better message threading within the archives (Another Pipermail
> request).
> Logging that displays the amount of system resources used by Mailman as
> it is running.


> I'm slammed with starting up a VoIP phone company in RTP, but I would
> still like to help out with the MMv3 effort, so let me know what I can
> do to bring value to this project.

Be involved in the early phases and when we get to coding, bite off a
big chunk that I don't want to do. :)


More information about the Mailman3-Dev mailing list