Updates

1 files changed, 9 insertions, 31 deletions

diff --git a/TODO b/TODO
index b509e93b8..4c8166909 100644
--- a/TODO
+++ b/TODO
@@ -6,19 +6,16 @@ Copyright (C) 1998,1999,2000,2001,2002 by the Free Software Foundation, Inc.
 The Mailman Wishlist
 
     Here's the wish list for future versions of Mailman.  Many new
-    features have been added to Mailman 2.1 (still in alpha as of this
-    writing 21-Jan-2002), so what's left will probably end up in a
-    Mailman 3.0.
+    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
+    http://www.zope.org/Members/bwarsaw/MailmanDesignNotes/FrontPage
 
 Email Handling
-    - Re-implement bulk mailer the Right Way: an asynchat/asyncore
-      server to do DNS lookups and remote MTA delivery directly
-      (optional).
-    - allow customizable notices on moderated member helds and discards
+    - Re-implement the bulk mailer to do DNS lookups and remote MTA
+      delivery directly (optional).
 
 Documentation
     - A detailed feature list
@@ -34,8 +31,8 @@ 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 template language/system like Zope's Presentation Templates,
-      Quixote, or PHP.
+      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.
 
@@ -44,8 +41,6 @@ List Administration
       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
-    - Ability to set defaults for the various user settings from the
-      "Membership Management" page.
     - Allow admins to control and set individual headers, adding,
       removing, or overriding those in the original message (sometimes
       very useful, but could be dangerous!)
@@ -54,13 +49,8 @@ List Administration
     - 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).
-    - Add an option to include Reply-To: header in the membership test
-      for a members-only list posting
 
 List Membership
-    - Allow the user to be excluded from postings if they're getting
-      them in the to: or cc: headers.  Be smarter about filtering out
-      duplicate deliveries.
     - 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
@@ -71,9 +61,6 @@ List Membership
       with URLs to retrieve the article)
     - Timed vacations, allowing a user to postpone or discard email
       for a certain number of days or weeks.
-    - Mailing list invitations; i.e. a middle ground between "mass
-      subscribe" and informally mailing a bunch of folks to tell them
-      about the list.
     - 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
@@ -90,8 +77,7 @@ Site Administration
 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.  Majordomo2 is
-      reported to have some good features in this regard.
+      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.
@@ -113,12 +99,7 @@ Portability & architecture
       various bits of information to come from different sources (a
       relational database, ZODB, LDAP, etc)
     - Member profiles
-    - Do a serious and thorough security audit (ongoing)
     - Allow lists of the same name in two different virtual domains
-    - More sophisticated attachment handling: strip and discard
-      attachments, post attachments (e.g. via WebDAV) and rewrite to
-      include URLs, etc.  Should be admin configurable based on MIME
-      type.  Check out Bill Bumgarner's work on this.
     - 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
@@ -130,22 +111,19 @@ 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).
-    - Delete bounce disabled address after some period of retry
 
 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
-    - archive link should do *something* reasonable before the first
-      message has been posted to the list.
     - 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!
+    - Unit and system test suite! (ongoing)