diff options
Diffstat (limited to 'admin/www/todo.html')
| -rw-r--r-- | admin/www/todo.html | 323 |
1 files changed, 323 insertions, 0 deletions
diff --git a/admin/www/todo.html b/admin/www/todo.html new file mode 100644 index 00000000..f681af12 --- /dev/null +++ b/admin/www/todo.html @@ -0,0 +1,323 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> +<html> +<!-- THIS PAGE IS AUTOMATICALLY GENERATED. DO NOT EDIT. --> +<!-- Thu Dec 26 22:30:25 2002 --> +<!-- 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="./docs.html">Documentation</a> + </td> + <td bgcolor="#eecfa1"> +<a href="./lists.html">Mailing lists</a> + </td> +</tr><tr> + <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> +</td></tr> +<tr><td bgcolor="#eecfa1"> +<a href="features.html">Features</a> +</td></tr> +<tr><td bgcolor="#eecfa1"> +<a href="otherstuff.html">Logos and Papers</a> +</td></tr> +<tr><td bgcolor="#eecfa1"> +<a href="inthenews.html">Mailman in Use</a> +</td></tr> +<tr><td bgcolor="#eecfa1"> +<a href="prev.html">Previous Releases</a> +</td></tr> +<tr><td bgcolor="#eecfa1"> +<a href="bugs.html">Bugs and Patches</a> +</td></tr> +<tr><td bgcolor="#eecfa1"> +<a href="mirrors.html">Mirrors</a> +</td></tr> +<tr><td bgcolor="#eecfa1"> +<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-2002 +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: 2002-12-27 03:36:46 +0000 (Fri, 27 Dec 2002) $) +</h3> +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 +<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> |