[Mailman-Users] Some notes on mailman...

[Chuq Von Rospach]

Hope folks find this useful. I've been evaluating list systems for 
the last, oh, god knows how long, looking to see how to bring my list 
systems up to date and replacing my existing (and heavily, heavily 
hacked) majordomo systems.

This is the evaluation I've just written to send to my list admins 
and other people I need to convince/educate about this upgrade, 
outlining what I see as the improvements from MJ, as well as the 
strengths and weaknesses of Mailman (based on 2.0b2).

If any of this is wrong, please feel free to let me know. and if any 
of this is unclear, I'll be happy to try to explain further.

chuq
----

Key functionality change list for Majordomo -> Mailman 2.0b2

Here is a list of key functionality changes and new features that we 
will acquire migrating to MailMan, as well the weaknesses or missing 
features I've identified.

Changes/improvements:

1) MIME support -- allows posting of mime-based messages, including 
attachments, multipart/alternative and HTML/styled text.

2) Integrated web-based subscription interface -- allows a user to 
subscribe and modify subscriptions via the web with a system 
integrated into the list server (my current system is a bag grafted 
onto the side of the computer...).

3) Nomail (vacation) mode (turn off mail w/o unsubscribing), allowing 
users to turn off deliveries without unsubscribing and losing all of 
their subscription option settings.

4) MIME-digests as well as plain digests.

5) consolidated subscriber interface for a user, allowing them to 
look at all of their subscriptions and manage them from a single web 
page.

6) integrated web-based archives, and automated downloadable text 
versions of archives.

7) support for virtual domains (fred at hockeyfanz.com, babble at chuqui.com...)

8) moderator and admin messages go to the list owners for processing 
(and approvals via the admin web site).

9) better moderator/posting/spam protection for lists.

10) owner/moderators have more control over their lists via admin web site.

11) ability to define trolls who require moderation, without making 
the list moderated.

12) owner/moderator gets emailed any time a message requiring 
approval is received.

13) integrated bounce processing system.

14) significantly simplified list creation and management (especially 
since pretty much everything is now integrated...)

15) supports List-ID proposed standard 
<http://www.within.com/~chandhok/ietf/listid.shtml>.

16) much better mail loop detection and nuking.


Weaknesses/bugs/missing features:

1) No way to limit MIME content other than file size: opens us to 
some potential problems such as viruses or "active" attachments. 
Priority: high. Resolution: can be handled with a scripted front end 
(as I do with majordomo today), or by patching the code to add a trap 
into moderator approval using the existing mechanism. Workaround: 
leaving the message size limit ~20K limits the ability to pass around 
anything meaningfully nasty. I would really like to be able to limit 
the types of data passed via MIME, however, to known/safe data types.

2) No way to force plain-text only. This is a MIME-capable server. 
Priority: low (basically, text-only is dead. This will upset a small 
minority of users, but it's true. The question is how to best manage 
MIME content, not to reject it. If we have a case that requires 
plain-text, there are de-mime scripts that can front-end the server 
address and strip a MIME message to the text part.

3) no centralized "majordomo@" type subscription account. Each list 
has its own subscription/admin address. Priority: low. and this 
enables easy virtual hosting. Frankly, just not a big issue any more, 
since ther's a mass migration to web interfaces anyway, and this is 
simply a documentation issue....

3) no -subscribe or -unsubscribe address. Priority: low. Majordomo 
didn't do that, either, it was all my custom scripting. I can add 
that in again.

4) Does not support list-XXX headers (RFC 2369). Priority: medium. 
Workaround: can probably be added to system.

5) web archives have no search engine (on the project TODO list). 
Priority: medium. Workaround: continue the existing system storing 
digests on a public site, indexed with htDig.

6) plain digests don't hande MIME stuff too cleanly. Priority: 
medium. Workaround: none (the answer is probably to add the ability 
to de-MIME to the MLM, and then allow yet another option to all of 
this, a no-MIME option. So users can choose message/digest, 
MIME/plain in either mode, and plain implies messages get de-mimed 
before delivery.

7) archives don't cleanly integrate MIME stuff. Priority: medium. 
workaround: none (the answer is probably to have the web archives 
recognize enhanced content, store copies of attachments so they're 
available by HTTP, integrate HTML into the archive, and -- and, well, 
easier said than done. But the "right" thing is to present data as it 
was sent out, which means decoding and processing all of this in 
appropriate ways... )

8) documentation and code issues: it's beta. It has features that 
aren't there yet, and documentation is incomplete and needs cleanup. 
Priority: low. workaround: Not a big deal, except for (1) above. 
Everything else I care about is either already far ahead of what we 
have or not that significant.

9) web site customization: needs web-based templatization. Priority: 
low. (optimally, every bloody thing can be changed via a web 
interface, so once it's installed, yo never need to visit the code 
base or MLM directory in a shell ever again. Easier said than done...)

10) doesn't VERP, or encode subscribed address into the message 
(ought to be available for header/footer, encoded into envelope, 
and/or X-sent-to: address, and if reply-to is not set to list, used 
as the "To:" address instead of the list...)

11) the user "conceal address" stuff is confusing. By default, list 
addresses are not publically available (as selected in the privacy 
options page in the admin web site) -- but the default for the user 
is to make it public. For users who understand what this means, this 
is going to create concern and confusion. The user-visible "conceal" 
value should track the list value. Or better yet,  use two values: 
non-visible (which overrides the list default if the list is open) 
and list-default (trust the list admin), with the default being 
list-default. That way, at least, it's clear what's happening. And 
for any user set to "list-default", if that default changes to open, 
they should be sent an email telling them, and explaining how to 
change it if they wish.

12) there is no way for the installation admin to "lock" values so 
the list admins and moderators can't change them. For instance, 
things like reply-to, headers or footers, etc, may need to be 
standardized in some installations. The system doesn't allow for 
site-wide standards to be created and enforced by the site admin -- 
you need to enable a list admin's ability to manage their list, but 
the site-admin needs to be the ultimate authority on what the list 
admin can and can't tweak. In some installations, list admins aren't 
going to be allowed access to the admin pages for this reason...


The only weaknesses I see to the system are:

1) no configurable way to manage MIME content: given the recent 
ILOVEYOU virus, this ought to be a key, top priority. Allowing 
MIME/plain delivery as well as installation- and list-based 
restrictions on MIME content are crucial to protect users and the 
list. By default (IMHO), only "safe", non-active content should be 
allowed through a MLM, and anything else rejected or held for 
approval. Opening to MIME is good. Opening to MIME without 
restriction (other than file size) isn't. Also, an option to hold for 
approval or auto-reject this stuff (with explanation) would be nice.

2) It's in Python: but I guess it's time to learn a new programming language...

3) lack of RFC2369 support, and lack of -subscribe and -unsubscribe 
addresses. I'm surprised that List-ID is in the code, but 2369 isn't. 
It needs to be.

Overall evaluation:

A huge step forward from the current system. Beta code seems very 
stable -- and the glitches can be lived with. Easily integrates about 
95% of the custom hacking I've written around majordomo over the 
years, and allows me to give a lot more power and capability to the 
list owners without me having to manually go in and tweak stuff for 
them. Adds MIME-digests and MIME/HTML capabilities, which will honk 
off some users, but MIME and HTML are rapidly mainstreaming into 
discussion systems, and more and more users have huge problems trying 
to send non-MIME messages (at the least, some way to de-MIME stuff is 
necessary, and I think full MIME support is leading edge in mailing 
lists, but far from bleeding edge.)

Having worked with it for about a week and run it through it's paces, 
I feel that the system is capable of going production with 2.0b2, 
giving us the upgrade we desperately need -- and as the development 
continues to 2.0 release, it'll continue to improve and refine. I'm 
therefore committing to standardizing on mailman as the server to 
replace my majordomo systems.
-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui at plaidworks.com)
Apple Mail List Gnome (mailto:chuq at apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"