|
|
|
The Mailman Wishlist
Here's the wish list for future versions of Mailman. Many new
features have been added to Mailman 2.1 (still in alpha as of this
writing 11-Jul-2001), so what's left will probably end up in a
Mailman 3.0.
Please also see the Mailman design notes wiki at
http://www.zope.org/Members/bwarsaw/MailmanDesignNotes/FrontPage
Email Handling
- Use VERP or DSN for address tracing, perhaps tied to the monthly password reminders, or VERPing the occasional regular message.
- Re-implement bulk mailer the Right Way: an asynchat/asyncore server to do DNS lookups and remote MTA delivery directly
(optional).
Documentation
- A detailed feature list
- A user's guide
- A site-admin's guide
- A list-admin's guide
- More on-line documentation and UI help
- A developer's guide w/ architecture and API information
- manpages for the scripts in bin and cron
- Integrate Christopher Kolar's documentation
General Web UI
- NO DEAD ENDS and every web page is reachable.
- All web UI must be configurable so that it more easily integrates into an existing site's design. Probably means using
a template language/system like Zope's Presentation Templates,
Quixote, or PHP.
- Default UI should add a navigation sidebar to all web pages.
- Web pages should never mention disabled features.
List Administration
- Allow the moderator to edit posts being held for approval (make it evident, either through a header or other means that the
message was edited by the moderator).
- Allow the list-admin to require approvals for unsubs
- Allow the admin to disable option settings by users
- Ability to set defaults for the various user settings from the "Membership Management" page.
- Allow admins to control and set individual headers, adding, removing, or overriding those in the original message (sometimes
very useful, but could be dangerous!)
- New moderation choice: archive but don't send to list.
- New moderation choice: annotate and send to author for resubmittal.
- Make it easier for an admin who manages multiple lists to handling pending requests sitting on all those lists.
- Ability to ban specific troublesome users (from posting, subscribing, etc). Posts from banned users would be discarded.
- Better integration with moderated newsgroups (and allow some addresses to bypass even that moderation and be delivered to a
secondary channel, like [EMAIL PROTECTED]).
- Add an option to include Reply-To: header in the membership test for a members-only list posting
List Membership
- Allow the user to be excluded from postings if they're getting them in the to: or cc: headers. Be smarter about filtering out
duplicate deliveries.
- Have one account per user per site, with multiple email addresses and fallbacks. Allow them to subscribe whichever
address they want to whichever list, with different options per
subscription.
- Allow the user to get BOTH normal and digested delivery (but I still don't understand why someone would want this)
- More flexible digests: index digests (subject and authors only, with URLs to retrieve the article)
- Timed vacations, allowing a user to postpone or discard email for a certain number of days or weeks.
Site Administration
- Allow the site admin to define list styles or themes, and list admins to choose one of the canned styles to apply to their
list.
Other Usability Improvments
- A better strategy is needed for sub-lists and super-lists, including dealing with the resulting password reminders and
authorization to modify the sub & superlists. Majordomo2 is
reported to have some good features in this regard.
- Add a limit on the number of posts from any one individual within a period of time (1 post per day, 10 per week, etc).
- Don't use the first public mailing list as the `originator' of password reminders.
Mailcmd interface
- Provide an email interface to all administrative commands
- Allow email unsubs from matching address to unsubscribe, possibly adding an "allow open unsubscribes" option to control
this. Also, adding a confirmation with click-thru confirmation
to resubscribe.
- For email subscribes, keep an audit of where requests are coming from, and send the original request headers in the confirmation
message. Helps track down subscribe bombs.
- Investigate Majordomo2's email admin capabilities.
- Support the `which' command.
Portability & architecture
- Support the `which' command.
- Use a real transactional database for all information, and allow various bits of information to come from different sources (a
relational database, ZODB, LDAP, etc)
- Member profiles
- Do a serious and thorough security audit (ongoing)
- Allow lists of the same name in two different virtual domains
- More sophisticated attachment handling: strip and discard attachments, post attachments (e.g. via WebDAV) and rewrite to
include URLs, etc. Should be admin configurable based on MIME
type. Check out Bill Bumgarner's work on this.
- Should be able to gather statistics, such as deliveries/day, performance, number of subscribers over time, etc.
- Implement something like Roundup's nosy lists, maybe even integrate with Roundup.
- Split Mailman into libraries so, e.g. the delivery part could be used by other projects.
Bounce handling
- Make a distinction between disabled addresses due to bouncing and a user's explicit disabling of an address
- Add more patterns for bounce handling (never ending)
- Occasionally remove stale bounce entries
- Send mail to people who are being removed without their knowledge (even though they're likely not to get it).
- Reminders to disabled addresses. The idea is that if an addr is disabled due to bouncing, we should send out periodic reminders.
We may want to do this for explicitly disabled addrs too, but
perhaps with a different schedule.
- Delete bounce disabled address after some period of retry
Pipermail + Archiving mechanism
- Search engine for archives
- Provide downloadable tar.gz's of the html archives
- sort by date should go most-recent to oldest
- allow list owner to edit archive messages
- archive link should do *something* reasonable before the first message has been posted to the list.
- optional form front-end to public interfaces as a filter to address harvesters.
- In general the whole Pipermail subsystem needs a good rewrite.
Code cleanup
- Turn all remaining string exceptions into class exceptions
- Unit and system test suite!
|
