diff options
Diffstat (limited to '')
| -rw-r--r-- | admin/www/todo.ht | 190 | ||||
| -rw-r--r-- | admin/www/todo.html | 353 |
2 files changed, 0 insertions, 543 deletions
diff --git a/admin/www/todo.ht b/admin/www/todo.ht deleted file mode 100644 index dae35982..00000000 --- a/admin/www/todo.ht +++ /dev/null @@ -1,190 +0,0 @@ -Title: The Mailman Wishlist - - <p> -<h3> The Mailman Wishlist -</h3> - <p> -<h3> (Last Update: $Date: 2005-12-29 11:01:09 +0000 (Thu, 29 Dec 2005) $) -</h3> -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 -<p> -<h3> Email Handling -</h3> -<ul> - <li> Re-implement the bulk mailer to do DNS lookups and remote MTA delivery directly (optional). - - <li> 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. - - <li> Strip any addresses of members who have nodupe turned on, from the Cc headers of the list copy of a message. - - <li> Separate processing for MIME and plaintext digests. E.g. you might want to filter images out of plaintext but not MIME - digests. - -</ul> -<h3> Documentation -</h3> -<ul> - <li> A detailed feature list - <li> A user's guide - <li> A site-admin's guide - <li> A list-admin's guide - <li> More on-line documentation and UI help - <li> A developer's guide w/ architecture and API information - <li> manpages for the scripts in bin and cron - <li> Integrate Christopher Kolar's documentation -</ul> -<h3> General Web UI -</h3> -<ul> - <li> NO DEAD ENDS and every web page is reachable. - <li> 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. - - <li> Default UI should add a navigation sidebar to all web pages. - <li> Web pages should never mention disabled features. - <li> Allow a site admin and list admins to categorize lists, so that they can be better organized on the listinfo and admin overview - pages. - -</ul> -<h3> List Administration -</h3> -<ul> - <li> 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). - - <li> Allow the admin to disable option settings by users - <li> Allow admins to block nomail settings - <li> Allow admins to control and set individual headers, adding, removing, or overriding those in the original message (sometimes - very useful, but could be dangerous!) - - <li> New moderation choice: archive but don't send to list. - <li> New moderation choice: annotate and send to author for resubmittal. Or just be able to annotate the message for - multiple moderator scenarios. - - <li> 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). - - <li> 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. - - <li> Ability to `sideline' some messages in the moderation queue - <li> 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. - - <li> 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. - - <li> 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. - - <li> Have an option to sort the list of members by real name or email address. - - <li> 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. - -</ul> -<h3> List Membership -</h3> -<ul> - <li> 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. - - <li> Allow the user to get BOTH normal and digested delivery (but I still don't understand why someone would want this) - - <li> More flexible digests: index digests (subject and authors only, with URLs to retrieve the article) - - <li> Timed vacations, allowing a user to postpone or discard email for a certain number of days or weeks. - - <li> 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. - -</ul> -<h3> Site Administration -</h3> -<ul> - <li> 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. - - <li> 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). - -</ul> -<h3> Other Usability Improvments -</h3> -<ul> - <li> 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. - - <li> 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. - -</ul> -<h3> Mailcmd interface -</h3> -<ul> - <li> Provide an email interface to all administrative commands - <li> 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. - - <li> 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. - - <li> Investigate Majordomo2's email admin capabilities. - <li> Support the `which' command. -</ul> -<h3> Portability & architecture -</h3> -<ul> - <li> 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) - - <li> Member profiles - <li> Allow lists of the same name in two different virtual domains - <li> Should be able to gather statistics, such as deliveries/day, performance, number of subscribers over time, etc. - - <li> Implement something like Roundup's nosy lists, maybe even integrate with Roundup. - - <li> Split Mailman into libraries so, e.g. the delivery part could be used by other projects. - -</ul> -<h3> Bounce handling -</h3> -<ul> - <li> Add more patterns for bounce handling (never ending) - <li> Send mail to people who are being removed without their knowledge (even though they're likely not to get it). - -</ul> -<h3> Pipermail + Archiving mechanism -</h3> -<ul> - <li> Search engine for archives - <li> Provide downloadable tar.gz's of the html archives - <li> sort by date should go most-recent to oldest - <li> allow list owner to edit archive messages - <li> optional form front-end to public interfaces as a filter to address harvesters. - - <li> In general the whole Pipermail subsystem needs a good rewrite. - <li> Write an API between Mailman and the archiver so that message footers can contain the URL to the archived message. - -</ul> -<h3> Code cleanup -</h3> -<ul> - <li> Turn all remaining string exceptions into class exceptions - <li> Unit and system test suite! (ongoing) -</ul> diff --git a/admin/www/todo.html b/admin/www/todo.html deleted file mode 100644 index 8b1e9748..00000000 --- a/admin/www/todo.html +++ /dev/null @@ -1,353 +0,0 @@ -<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" - "http://www.w3.org/TR/html4/loose.dtd" > -<html> -<!-- THIS PAGE IS AUTOMATICALLY GENERATED. DO NOT EDIT. --> -<!-- Tue Sep 12 23:12:44 2006 --> -<!-- USING HT2HTML 2.0 --> -<!-- SEE http://ht2html.sf.net --> -<!-- User-specified headers: -Title: The Mailman Wishlist - ---> - -<head> -<title>The Mailman Wishlist</title> -<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" > -<meta name="generator" content="HT2HTML/2.0" > -<style type="text/css"> -body { margin: 0px; } -</style> -</head> -<body bgcolor="#ffffff" text="#000000" - marginwidth="0" marginheight="0" - link="#0000bb" vlink="#551a8b" - alink="#ff0000"> -<!-- start of page table --> -<table width="100%" border="0" cellspacing="0" cellpadding="0"> -<!-- start of banner row --> -<tr> -<!-- start of corner cells --> -<td width="150" valign="middle" bgcolor="white" class="corner"> - -<center> - <a href="./index.html"> - <img border=0 src="./images/logo-70.jpg"></a></center> </td> -<td width="15" bgcolor="#eecfa1"> </td><!--spacer--> -<!-- end of corner cells --> -<!-- start of banner --> -<td width="90%" bgcolor="#eecfa1" class="banner"> -<!-- start of site links table --> -<table width="100%" border="0" - CELLSPACING=0 CELLPADDING=0 - bgcolor="#ffffff"> -<tr> - <td bgcolor="#eecfa1"> -<a href="./index.html">Home</a> - </td> - <td bgcolor="#eecfa1"> -<a href="./security.html">Security</a> - </td> - <td bgcolor="#eecfa1"> -<a href="./docs.html">Documentation</a> - </td> - <td bgcolor="#eecfa1"> -<a href="./lists.html">Mailing Lists</a> - </td> -</tr><tr> - <td bgcolor="#eecfa1"> -<a href="http://wiki.list.org/x/DQ">Community</a> - </td> - <td bgcolor="#eecfa1"> -<a href="./help.html">Help</a> - </td> - <td bgcolor="#eecfa1"> -<a href="./download.html">Download</a> - </td> - <td bgcolor="#eecfa1"> -<a href="./devs.html">Developers</a> - </td> -</tr> -</table><!-- end of site links table --> - -</td><!-- end of banner --> -</tr><!-- end of banner row --> -<tr><!-- start of sidebar/body row --> -<!-- start of sidebar cells --> -<td width="150" valign="top" bgcolor="#eecfa1" class="sidebar"> -<!-- start of sidebar table --> -<table width="100%" border="0" cellspacing="0" cellpadding="3" - bgcolor="#ffffff"> -<tr><td bgcolor="#36648b"><b><font color="#ffffff"> -Overview -</font></b></td></tr> -<tr><td bgcolor="#eecfa1"> -<a href="index.html">Home</a></li> -</td></tr> -<tr><td bgcolor="#eecfa1"> -<a href="security.html">Security</li> -</td></tr> -<tr><td bgcolor="#eecfa1"> -<a href="features.html">Features</a></li> -</td></tr> -<tr><td bgcolor="#eecfa1"> </td></tr> -<tr><td bgcolor="#36648b"><b><font color="#ffffff"> -More Information -</font></b></td></tr> -<tr><td bgcolor="#eecfa1"> -<a href="http://wiki.list.org">Wiki</a> <i>(exit)</i></li> -</td></tr> -<tr><td bgcolor="#eecfa1"> -<a href="lists.html">Discussion Lists</a></li> -</td></tr> -<tr><td bgcolor="#eecfa1"> -<a href="http://sf.net/projects/mailman">SF Project Page</a> -</td></tr> -<tr><td bgcolor="#eecfa1"> -<a href="otherstuff.html">Rants, Papers, and Logos</a></li> -</td></tr> -<tr><td bgcolor="#eecfa1"> -<a href="bugs.html">Bugs and Patches</a></li> -</td></tr> -<tr><td bgcolor="#eecfa1"> -<a href="mirrors.html">Mirrors</a></li> -</td></tr> -<tr><td bgcolor="#eecfa1"> </td></tr> -<tr><td bgcolor="#36648b"><b><font color="#ffffff"> -Related Links <i>(exits)</i> -</font></b></td></tr> -<tr><td bgcolor="#eecfa1"> -<a href="http://www.python.org/">Python</a></li> -</td></tr> -<tr><td bgcolor="#eecfa1"> -<a href="http://www.gnu.org/">GNU</a></li> -</td></tr> -<tr><td bgcolor="#eecfa1"> -<a href="http://barry.warsaw.us/">Barry Warsaw</a></li> -</td></tr> -<tr><td bgcolor="#eecfa1"> </td></tr> -<tr><td bgcolor="#36648b"><b><font color="#ffffff"> -Email Us -</font></b></td></tr> -<tr><td bgcolor="#eecfa1"> -<a href="mailto:mailman-users@python.org">mailman-users@python.org</a> -</td></tr> -<tr><td bgcolor="#eecfa1"> - -</td></tr> -<tr><td bgcolor="#eecfa1"> -<a href="http://www.python.org/"><img border=0 - src="./images/PythonPoweredSmall.png" - ></a> <a href="http://sourceforge.net"><img - src="http://sourceforge.net/sflogo.php?group_id=103" - width="88" height="31" border="0" - alt="SourceForge Logo"></a> -</td></tr> -<tr><td bgcolor="#eecfa1"> - -</td></tr> -<tr><td bgcolor="#eecfa1"> -© 1998-2006 -Free Software Foundation, Inc. Verbatim copying and distribution of this -entire article is permitted in any medium, provided this notice is preserved. - -</td></tr> -</table><!-- end of sidebar table --> - -</td> -<td width="15"> </td><!--spacer--> -<!-- end of sidebar cell --> -<!-- start of body cell --> -<td valign="top" width="90%" class="body"><br> - <p> -<h3> The Mailman Wishlist -</h3> - <p> -<h3> (Last Update: $Date: 2006-09-13 04:21:03 +0100 (Wed, 13 Sep 2006) $) -</h3> -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 -<p> -<h3> Email Handling -</h3> -<ul> - <li> Re-implement the bulk mailer to do DNS lookups and remote MTA delivery directly (optional). - - <li> 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. - - <li> Strip any addresses of members who have nodupe turned on, from the Cc headers of the list copy of a message. - - <li> Separate processing for MIME and plaintext digests. E.g. you might want to filter images out of plaintext but not MIME - digests. - -</ul> -<h3> Documentation -</h3> -<ul> - <li> A detailed feature list - <li> A user's guide - <li> A site-admin's guide - <li> A list-admin's guide - <li> More on-line documentation and UI help - <li> A developer's guide w/ architecture and API information - <li> manpages for the scripts in bin and cron - <li> Integrate Christopher Kolar's documentation -</ul> -<h3> General Web UI -</h3> -<ul> - <li> NO DEAD ENDS and every web page is reachable. - <li> 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. - - <li> Default UI should add a navigation sidebar to all web pages. - <li> Web pages should never mention disabled features. - <li> Allow a site admin and list admins to categorize lists, so that they can be better organized on the listinfo and admin overview - pages. - -</ul> -<h3> List Administration -</h3> -<ul> - <li> 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). - - <li> Allow the admin to disable option settings by users - <li> Allow admins to block nomail settings - <li> Allow admins to control and set individual headers, adding, removing, or overriding those in the original message (sometimes - very useful, but could be dangerous!) - - <li> New moderation choice: archive but don't send to list. - <li> New moderation choice: annotate and send to author for resubmittal. Or just be able to annotate the message for - multiple moderator scenarios. - - <li> 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). - - <li> 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. - - <li> Ability to `sideline' some messages in the moderation queue - <li> 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. - - <li> 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. - - <li> 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. - - <li> Have an option to sort the list of members by real name or email address. - - <li> 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. - -</ul> -<h3> List Membership -</h3> -<ul> - <li> 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. - - <li> Allow the user to get BOTH normal and digested delivery (but I still don't understand why someone would want this) - - <li> More flexible digests: index digests (subject and authors only, with URLs to retrieve the article) - - <li> Timed vacations, allowing a user to postpone or discard email for a certain number of days or weeks. - - <li> 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. - -</ul> -<h3> Site Administration -</h3> -<ul> - <li> 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. - - <li> 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). - -</ul> -<h3> Other Usability Improvments -</h3> -<ul> - <li> 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. - - <li> 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. - -</ul> -<h3> Mailcmd interface -</h3> -<ul> - <li> Provide an email interface to all administrative commands - <li> 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. - - <li> 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. - - <li> Investigate Majordomo2's email admin capabilities. - <li> Support the `which' command. -</ul> -<h3> Portability & architecture -</h3> -<ul> - <li> 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) - - <li> Member profiles - <li> Allow lists of the same name in two different virtual domains - <li> Should be able to gather statistics, such as deliveries/day, performance, number of subscribers over time, etc. - - <li> Implement something like Roundup's nosy lists, maybe even integrate with Roundup. - - <li> Split Mailman into libraries so, e.g. the delivery part could be used by other projects. - -</ul> -<h3> Bounce handling -</h3> -<ul> - <li> Add more patterns for bounce handling (never ending) - <li> Send mail to people who are being removed without their knowledge (even though they're likely not to get it). - -</ul> -<h3> Pipermail + Archiving mechanism -</h3> -<ul> - <li> Search engine for archives - <li> Provide downloadable tar.gz's of the html archives - <li> sort by date should go most-recent to oldest - <li> allow list owner to edit archive messages - <li> optional form front-end to public interfaces as a filter to address harvesters. - - <li> In general the whole Pipermail subsystem needs a good rewrite. - <li> Write an API between Mailman and the archiver so that message footers can contain the URL to the archived message. - -</ul> -<h3> Code cleanup -</h3> -<ul> - <li> Turn all remaining string exceptions into class exceptions - <li> Unit and system test suite! (ongoing) -</ul> - -</td><!-- end of body cell --> -</tr><!-- end of sidebar/body row --> -</table><!-- end of page table --> -</body></html> |