| +Home + | ++Documentation + | ++Mailing lists + | +
| +Help + | ++Download + | ++Developers + | +
| +Overview + |
| +Home + |
| +Features + |
| +Logos and Papers + |
| +Mailman in Use + |
| +Previous Releases + |
| +Bugs and Patches + |
| +Mirrors + |
| + |
| +Email Us + |
| +mailman-users@python.org + |
| + + |
+ |
| + + |
| +© 1998-2002 +Free Software Foundation, Inc. Verbatim copying and distribution of this +entire article is permitted in any medium, provided this notice is preserved. + + |
+
+
The Mailman Wishlist +
++
(Last Update: $Date: 2002-12-27 03:36:46 +0000 (Fri, 27 Dec 2002) $) +
+Here's the wish list for future versions of Mailman. Many new + features have been added to Mailman 2.1, 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 +
+-
+
- Re-implement the bulk mailer to do DNS lookups and remote MTA delivery directly (optional). + +
- For low-traffic sites, a queued message could trigger a qrunner process. It would work until all mail was delivered, then sleep + and exit if no new work arrived. + +
- Strip any addresses of members who have nodupe turned on, from the Cc headers of the list copy of a message. + +
- Separate processing for MIME and plaintext digests. E.g. you might want to filter images out of plaintext but not MIME + digests. + +
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 better 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. +
- Allow a site admin and list admins to categorize lists, so that they can be better organized on the listinfo and admin overview + pages. + +
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 admin to disable option settings by users +
- Allow admins to block nomail settings +
- 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. Or just be able to annotate the message for + multiple moderator scenarios. + +
- Better integration with moderated newsgroups (and allow some addresses to bypass even that moderation and be delivered to a + secondary channel, like moderators@isc.org). + +
- Allow a list to be marked `disabled' so things like the replybot still works, and the archives are still available, but mail + posted to the list is always returned unsent. + +
- Ability to `sideline' some messages in the moderation queue +
- Hook moderation up to a whitelist a la TMDA. A non-member message gets held in a non-admindb queue, and the sender gets a + confirmation message. When they confirm, we moderate the + message as normal, but if they don't we assume it's spam (after + some period of time) and discard it. The admin should be able + to see all these super-quarantined messages with the flip of a + button. + +
- Add a moderation option to pass through any message which is a reply to a message previously distributed through the list, even + if it comes from a non-member. Treat that non-member as a + member for the duration of the thread. Use In-Reply-To, + References and Message-ID to match these up. + +
- When a held message is forwarded (for admin editing and approved resend) there should be a way to auto-discard the held message + when the approved resend is received. + +
- Have an option to sort the list of members by real name or email address. + +
- Test a message for all hold criteria, record them all instead of just the first match, and do a SpamAssassin like scoring to + decide whether the message should get held or not. + +
List Membership +
+-
+
- 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. + +
- Keep user-centric stats, such as the date the user was subscribed, the date of their last change to their account, the + date they last sent a message through the list. Perhaps also + log each message they send through the list. + +
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. + +
- Allow the site admin to send an email message to all the list admins using a mechanism similar to the Urgent: header (possibly + by addressing it to mailman@site.dom). + +
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. + +
- 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). + Also, limits on mailbacks, infos, etc. + +
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 +
+-
+
- 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 +
- Allow lists of the same name in two different virtual domains +
- 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 +
+-
+
- Add more patterns for bounce handling (never ending) +
- Send mail to people who are being removed without their knowledge (even though they're likely not to get it). + +
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 +
- optional form front-end to public interfaces as a filter to address harvesters. + +
- In general the whole Pipermail subsystem needs a good rewrite. +
- Write an API between Mailman and the archiver so that message footers can contain the URL to the archived message. + +
Code cleanup +
+-
+
- Turn all remaining string exceptions into class exceptions +
- Unit and system test suite! (ongoing) +