[Mailman-Users] Some notes on mailman...
tal at research.bell-labs.com
Thu May 18 08:04:43 CEST 2000
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.
> 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
> 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...)
> 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.
More information about the Mailman-Users