sort by date should go most-recent to oldest
@@ -968,138 +185,6 @@ Title: The Mailman Wishlist
Code cleanup
- - 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
-
-
- 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.
-
-
- 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
-
- 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.
-
-
- 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.
-
-
- 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.
-
-
- 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).
-
-
- 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.
-
-
- 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.
-
- 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.
-
-
- 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).
-
-
- 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.
-
- Turn all remaining string exceptions into class exceptions
- Unit and system test suite! (ongoing)
diff --git a/admin/www/todo.html b/admin/www/todo.html
index b2ee939b3..b84604b69 100644
--- a/admin/www/todo.html
+++ b/admin/www/todo.html
@@ -1,7 +1,7 @@
-
+
- The Mailman Wishlist
-
-
- (Last Update: $Date: 2002-11-19 07:11:17 +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
-
-
- - 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
-
-
- 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
-
-
- - 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
-
-
- 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.
-
-
- 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
-
-
- - 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
-
-
- 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.
-
-
- 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
-
- 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
-
-
- - 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
-
-
- 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.
-
-
- 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
-
- 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.
-
-
- 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
-
-
- - 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
-
-
- 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.
-
-
- 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
-
- 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.
-
-
- 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.
-
-
- 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
-
-
- - 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
-
-
- 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.
-
-
- 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
-
- 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.
-
-
- 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.
-
-
- 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.
-
-
- 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
-
-
- - 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
-
-
- 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.
-
-
- 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
-
- 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.
-
-
- 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.
-
-
- 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.
-
-
- 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).
-
-
- 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
-
-
- - 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
-
-
- 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.
-
-
- 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
-
- 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.
-
-
- 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.
-
-
- 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.
-
-
- 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).
-
-
- 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.
-
-
- 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
-
-
- - 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
-
-
- 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.
-
-
- 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
-
- 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.
-
-
- 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.
-
-
- 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.
-
-
- 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).
-
-
- 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.
-
-
- 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.
-
- 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
-
-
- - 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
-
-
- 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.
-
-
- 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
-
- 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.
-
-
- 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.
-
-
- 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.
-
-
- 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).
-
-
- 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.
-
-
- 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.
-
- 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.
-
-
- 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
+
+ The Mailman Wishlist
-
- - Here's the wish list for future versions of Mailman. Many new
+
+ (Last Update: $Date: 2002-12-09 13:34:43 +0000 (Mon, 09 Dec 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
@@ -1006,6 +183,10 @@ Email Us
- 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
@@ -1014,6 +195,10 @@ Email Us
- 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
@@ -1024,6 +209,10 @@ Email Us
- 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).
@@ -1063,6 +252,10 @@ Email Us
- 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.
@@ -1077,18 +270,30 @@ Email Us
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
@@ -1099,6 +304,10 @@ Email Us
- 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)
@@ -1110,9 +319,17 @@ Email Us
- 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
@@ -1126,138 +343,6 @@ Email Us
Code cleanup
- - 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
-
-
- 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.
-
-
- 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
-
- 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.
-
-
- 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.
-
-
- 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.
-
-
- 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).
-
-
- 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.
-
-
- 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.
-
- 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.
-
-
- 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).
-
-
- 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.
-
- Turn all remaining string exceptions into class exceptions
- Unit and system test suite! (ongoing)
diff --git a/admin/www/users.html b/admin/www/users.html
index a12d81875..ab1f028a7 100644
--- a/admin/www/users.html
+++ b/admin/www/users.html
@@ -1,7 +1,7 @@
-
+
--
cgit v1.3.1
| 
