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

[Tom Limoncelli]

chuq: this is really useful research!  Thanks!


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

A better example might be members at hockeyfanz.com (-:


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

This is actually a negative thing for me.  I want them to go to
different people.  In fact, I want bounces to just go to /dev/null :-)


> 13) integrated bounce processing system.

I run a number of mailing lists for people in the telecom world and they
all seem to use mail systems with odd and/or broken bounce mechanisms. 
The regular expressions don't catch much of their bounces.  I would much
rather see support for VERP support, which I assume will be added as
soon as postfix supports VERP.  I'd be willing to work with someone to
add this support to mailman, by the way.


Negatives:

> 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.

I think this is a major problem, and since it is so easy to fix I hope
it can be integrated before 2.x reaches non-beta status.


> 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.

I default users to MIME digests for this reason.  Things work pretty
well.  I only switch someone to plain digests if they use a broken
mailer.


> 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... )

I think this is a major issue.  I'd love to see it detach all
attachments, store them in a directory somewhere, and replace them with
URLs to the stored files.


> 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...)

I agree.


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

I feel the same way!


> 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.

--tal