| -Home - | --Security - | --Documentation - | --Mailing Lists - | -
| -Community - | --Help - | --Download - | --Developers - | -
| -Overview - |
| -Home - |
| -Security - |
| -Features - |
| -More Information - |
| -Wiki (exit) - |
| -Discussion Lists - |
| -SF Project Page - |
| -Rants, Papers, and Logos - |
| -Bugs and Patches - |
| -Mirrors - |
| -Related Links (exits) - |
| -Python - |
| -GNU - |
| -Barry Warsaw - |
| -Email Us - |
| -mailman-users@python.org - |
| - - |
- |
| - - |
| -© 1998-2006 -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: 2006-09-13 04:21:03 +0100 (Wed, 13 Sep 2006) $) -
-Here's the wish list for future versions of Mailman. Many new - features have been added to Mailman 2.1, and it is currently - undecided whether the next release will be 2.2 or 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) -