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

    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).

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.

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 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.
    - 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).

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.

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: