TODO

   1 Mailman - The GNU Mailing List Management System
   2 Copyright (C) 1998-2003 by the Free Software Foundation, Inc.
   3 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
   4
   5
   6 The Mailman Wishlist
   7 (Last Update: $Date: 2005-08-26 21:40:17 -0400 (Fri, 26 Aug 2005) $)
   8
   9     Here's the wish list for future versions of Mailman.  Many new
  10     features have been added to Mailman 2.1, and it is currently
  11     undecided whether the next release will be 2.2 or 3.0.
  12
  13     Please also see the Mailman design notes wiki at
  14
  15     http://www.zope.org/Members/bwarsaw/MailmanDesignNotes/FrontPage
  16
  17 Email Handling
  18     - Re-implement the bulk mailer to do DNS lookups and remote MTA
  19       delivery directly (optional).
  20     - For low-traffic sites, a queued message could trigger a qrunner
  21       process.  It would work until all mail was delivered, then sleep
  22       and exit if no new work arrived.
  23     - Strip any addresses of members who have nodupe turned on, from
  24       the Cc headers of the list copy of a message.
  25     - Separate processing for MIME and plaintext digests.  E.g. you
  26       might want to filter images out of plaintext but not MIME
  27       digests.
  28
  29 Documentation
  30     - A detailed feature list
  31     - A user's guide
  32     - A site-admin's guide
  33     - A list-admin's guide
  34     - More on-line documentation and UI help
  35     - A developer's guide w/ architecture and API information
  36     - manpages for the scripts in bin and cron
  37     - Integrate Christopher Kolar's documentation
  38
  39 General Web UI
  40     - NO DEAD ENDS and every web page is reachable.
  41     - All web UI must be configurable so that it more easily
  42       integrates into an existing site's design.  Probably means using
  43       a better template language/system like Zope's Presentation
  44       Templates, Quixote, or PHP.
  45     - Default UI should add a navigation sidebar to all web pages.
  46     - Web pages should never mention disabled features.
  47     - Allow a site admin and list admins to categorize lists, so that
  48       they can be better organized on the listinfo and admin overview
  49       pages.
  50
  51 List Administration
  52     - Allow the moderator to edit posts being held for approval (make
  53       it evident, either through a header or other means that the
  54       message was edited by the moderator).
  55     - Allow the admin to disable option settings by users
  56     - Allow admins to block nomail settings
  57     - Allow admins to control and set individual headers, adding,
  58       removing, or overriding those in the original message (sometimes
  59       very useful, but could be dangerous!)
  60     - New moderation choice: archive but don't send to list.
  61     - New moderation choice: annotate and send to author for
  62       resubmittal.  Or just be able to annotate the message for
  63       multiple moderator scenarios.
  64     - Better integration with moderated newsgroups (and allow some
  65       addresses to bypass even that moderation and be delivered to a
  66       secondary channel, like moderators@isc.org).
  67     - Allow a list to be marked `disabled' so things like the replybot
  68       still works, and the archives are still available, but mail
  69       posted to the list is always returned unsent.
  70     - Ability to `sideline' some messages in the moderation queue
  71     - Hook moderation up to a whitelist a la TMDA.  A non-member
  72       message gets held in a non-admindb queue, and the sender gets a
  73       confirmation message.  When they confirm, we moderate the
  74       message as normal, but if they don't we assume it's spam (after
  75       some period of time) and discard it.  The admin should be able
  76       to see all these super-quarantined messages with the flip of a
  77       button.
  78     - Add a moderation option to pass through any message which is a
  79       reply to a message previously distributed through the list, even
  80       if it comes from a non-member.  Treat that non-member as a
  81       member for the duration of the thread.  Use In-Reply-To,
  82       References and Message-ID to match these up.
  83     - When a held message is forwarded (for admin editing and approved
  84       resend) there should be a way to auto-discard the held message
  85       when the approved resend is received.
  86     - Have an option to sort the list of members by real name or email
  87       address.
  88     - Test a message for all hold criteria, record them all instead of
  89       just the first match, and do a SpamAssassin like scoring to
  90       decide whether the message should get held or not.
  91
  92 List Membership
  93     - Have one account per user per site, with multiple email
  94       addresses and fallbacks.  Allow them to subscribe whichever
  95       address they want to whichever list, with different options per
  96       subscription.
  97     - Allow the user to get BOTH normal and digested delivery (but I
  98       still don't understand why someone would want this)
  99     - More flexible digests: index digests (subject and authors only,
 100       with URLs to retrieve the article)
 101     - Timed vacations, allowing a user to postpone or discard email
 102       for a certain number of days or weeks.
 103     - Keep user-centric stats, such as the date the user was
 104       subscribed, the date of their last change to their account, the
 105       date they last sent a message through the list.  Perhaps also
 106       log each message they send through the list.
 107
 108 Site Administration
 109     - Allow the site admin to define list styles or themes, and list
 110       admins to choose one of the canned styles to apply to their
 111       list.
 112     - Allow the site admin to send an email message to all the list
 113       admins using a mechanism similar to the Urgent: header (possibly
 114       by addressing it to mailman@site.dom).
 115
 116 Other Usability Improvments
 117     - A better strategy is needed for sub-lists and super-lists,
 118       including dealing with the resulting password reminders and
 119       authorization to modify the sub & superlists.
 120     - Add a limit on the number of posts from any one individual
 121       within a period of time (1 post per day, 10 per week, etc).
 122       Also, limits on mailbacks, infos, etc.
 123
 124 Mailcmd interface
 125     - Provide an email interface to all administrative commands
 126     - Allow email unsubs from matching address to unsubscribe,
 127       possibly adding an "allow open unsubscribes" option to control
 128       this.  Also, adding a confirmation with click-thru confirmation
 129       to resubscribe.
 130     - For email subscribes, keep an audit of where requests are coming
 131       from, and send the original request headers in the confirmation
 132       message.  Helps track down subscribe bombs.
 133     - Investigate Majordomo2's email admin capabilities.
 134     - Support the `which' command.
 135
 136 Portability & architecture
 137     - Use a real transactional database for all information, and allow
 138       various bits of information to come from different sources (a
 139       relational database, ZODB, LDAP, etc)
 140     - Member profiles
 141     - Allow lists of the same name in two different virtual domains
 142     - Should be able to gather statistics, such as deliveries/day,
 143       performance, number of subscribers over time, etc.
 144     - Implement something like Roundup's nosy lists, maybe even
 145       integrate with Roundup.
 146     - Split Mailman into libraries so, e.g. the delivery part could be
 147       used by other projects.
 148
 149 Bounce handling
 150     - Add more patterns for bounce handling (never ending)
 151     - Send mail to people who are being removed without their knowledge
 152       (even though they're likely not to get it).
 153
 154 Pipermail + Archiving mechanism
 155     - Search engine for archives
 156     - Provide downloadable tar.gz's of the html archives
 157     - sort by date should go most-recent to oldest
 158     - allow list owner to edit archive messages
 159     - optional form front-end to public interfaces as a filter to
 160       address harvesters.
 161     - In general the whole Pipermail subsystem needs a good rewrite.
 162     - Write an API between Mailman and the archiver so that message
 163       footers can contain the URL to the archived message.
 164
 165 Code cleanup
 166     - Turn all remaining string exceptions into class exceptions
 167     - Unit and system test suite! (ongoing)
 168
 169
 170 \f
 171 Local Variables:
 172 mode: indented-text
 173 indent-tabs-mode: nil
 174 End: