diff options
Diffstat (limited to 'TODO')
| -rw-r--r-- | TODO | 174 |
1 files changed, 174 insertions, 0 deletions
@@ -0,0 +1,174 @@ +Mailman - The GNU Mailing List Management System +Copyright (C) 1998,1999,2000,2001,2002 by the Free Software Foundation, Inc. +59 Temple Place - Suite 330, Boston, MA 02111-1307, USA + + +The Mailman Wishlist +(Last Update: $Date: 2002-11-19 06:50:54 +0000 (Tue, 19 Nov 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) + + + +Local Variables: +mode: indented-text +indent-tabs-mode: nil +End: |