Mailman - The GNU Mailing List Management System
Copyright (C) 1998-2003 by the Free Software Foundation, Inc.
59 Temple Place - Suite 330, Boston, MA 02111-1307, USA


The Mailman Wishlist
(Last Update: $Date: 2003/09/28 17:24:16 $)

    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)



Local Variables:
mode: indented-text
indent-tabs-mode: nil
End:
