1
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
2
"http://www.w3.org/TR/html4/loose.dtd" >
4
<!-- THIS PAGE IS AUTOMATICALLY GENERATED. DO NOT EDIT. -->
5
<!-- Tue Sep 12 23:12:44 2006 -->
6
<!-- USING HT2HTML 2.0 -->
7
<!-- SEE http://ht2html.sf.net -->
8
<!-- User-specified headers:
9
Title: The Mailman Wishlist
14
<title>The Mailman Wishlist</title>
15
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" >
16
<meta name="generator" content="HT2HTML/2.0" >
17
<style type="text/css">
21
<body bgcolor="#ffffff" text="#000000"
22
marginwidth="0" marginheight="0"
23
link="#0000bb" vlink="#551a8b"
25
<!-- start of page table -->
26
<table width="100%" border="0" cellspacing="0" cellpadding="0">
27
<!-- start of banner row -->
29
<!-- start of corner cells -->
30
<td width="150" valign="middle" bgcolor="white" class="corner">
33
<a href="./index.html">
34
<img border=0 src="./images/logo-70.jpg"></a></center> </td>
35
<td width="15" bgcolor="#eecfa1"> </td><!--spacer-->
36
<!-- end of corner cells -->
37
<!-- start of banner -->
38
<td width="90%" bgcolor="#eecfa1" class="banner">
39
<!-- start of site links table -->
40
<table width="100%" border="0"
41
CELLSPACING=0 CELLPADDING=0
44
<td bgcolor="#eecfa1">
45
<a href="./index.html">Home</a>
47
<td bgcolor="#eecfa1">
48
<a href="./security.html">Security</a>
50
<td bgcolor="#eecfa1">
51
<a href="./docs.html">Documentation</a>
53
<td bgcolor="#eecfa1">
54
<a href="./lists.html">Mailing Lists</a>
57
<td bgcolor="#eecfa1">
58
<a href="http://wiki.list.org/x/DQ">Community</a>
60
<td bgcolor="#eecfa1">
61
<a href="./help.html">Help</a>
63
<td bgcolor="#eecfa1">
64
<a href="./download.html">Download</a>
66
<td bgcolor="#eecfa1">
67
<a href="./devs.html">Developers</a>
70
</table><!-- end of site links table -->
72
</td><!-- end of banner -->
73
</tr><!-- end of banner row -->
74
<tr><!-- start of sidebar/body row -->
75
<!-- start of sidebar cells -->
76
<td width="150" valign="top" bgcolor="#eecfa1" class="sidebar">
77
<!-- start of sidebar table -->
78
<table width="100%" border="0" cellspacing="0" cellpadding="3"
80
<tr><td bgcolor="#36648b"><b><font color="#ffffff">
83
<tr><td bgcolor="#eecfa1">
84
<a href="index.html">Home</a></li>
86
<tr><td bgcolor="#eecfa1">
87
<a href="security.html">Security</li>
89
<tr><td bgcolor="#eecfa1">
90
<a href="features.html">Features</a></li>
92
<tr><td bgcolor="#eecfa1"> </td></tr>
93
<tr><td bgcolor="#36648b"><b><font color="#ffffff">
96
<tr><td bgcolor="#eecfa1">
97
<a href="http://wiki.list.org">Wiki</a> <i>(exit)</i></li>
99
<tr><td bgcolor="#eecfa1">
100
<a href="lists.html">Discussion Lists</a></li>
102
<tr><td bgcolor="#eecfa1">
103
<a href="http://sf.net/projects/mailman">SF Project Page</a>
105
<tr><td bgcolor="#eecfa1">
106
<a href="otherstuff.html">Rants, Papers, and Logos</a></li>
108
<tr><td bgcolor="#eecfa1">
109
<a href="bugs.html">Bugs and Patches</a></li>
111
<tr><td bgcolor="#eecfa1">
112
<a href="mirrors.html">Mirrors</a></li>
114
<tr><td bgcolor="#eecfa1"> </td></tr>
115
<tr><td bgcolor="#36648b"><b><font color="#ffffff">
116
Related Links <i>(exits)</i>
117
</font></b></td></tr>
118
<tr><td bgcolor="#eecfa1">
119
<a href="http://www.python.org/">Python</a></li>
121
<tr><td bgcolor="#eecfa1">
122
<a href="http://www.gnu.org/">GNU</a></li>
124
<tr><td bgcolor="#eecfa1">
125
<a href="http://barry.warsaw.us/">Barry Warsaw</a></li>
127
<tr><td bgcolor="#eecfa1"> </td></tr>
128
<tr><td bgcolor="#36648b"><b><font color="#ffffff">
130
</font></b></td></tr>
131
<tr><td bgcolor="#eecfa1">
132
<a href="mailto:mailman-users@python.org">mailman-users@python.org</a>
134
<tr><td bgcolor="#eecfa1">
137
<tr><td bgcolor="#eecfa1">
138
<a href="http://www.python.org/"><img border=0
139
src="./images/PythonPoweredSmall.png"
140
></a> <a href="http://sourceforge.net"><img
141
src="http://sourceforge.net/sflogo.php?group_id=103"
142
width="88" height="31" border="0"
143
alt="SourceForge Logo"></a>
145
<tr><td bgcolor="#eecfa1">
148
<tr><td bgcolor="#eecfa1">
150
Free Software Foundation, Inc. Verbatim copying and distribution of this
151
entire article is permitted in any medium, provided this notice is preserved.
154
</table><!-- end of sidebar table -->
157
<td width="15"> </td><!--spacer-->
158
<!-- end of sidebar cell -->
159
<!-- start of body cell -->
160
<td valign="top" width="90%" class="body"><br>
162
<h3> The Mailman Wishlist
165
<h3> (Last Update: $Date: 2006-09-12 23:21:03 -0400 (Tue, 12 Sep 2006) $)
167
Here's the wish list for future versions of Mailman. Many new
168
features have been added to Mailman 2.1, and it is currently
169
undecided whether the next release will be 2.2 or 3.0.
170
Please also see the Mailman design notes wiki at
171
http://www.zope.org/Members/bwarsaw/MailmanDesignNotes/FrontPage
176
<li> Re-implement the bulk mailer to do DNS lookups and remote MTA delivery directly (optional).
178
<li> For low-traffic sites, a queued message could trigger a qrunner process. It would work until all mail was delivered, then sleep
179
and exit if no new work arrived.
181
<li> Strip any addresses of members who have nodupe turned on, from the Cc headers of the list copy of a message.
183
<li> Separate processing for MIME and plaintext digests. E.g. you might want to filter images out of plaintext but not MIME
190
<li> A detailed feature list
192
<li> A site-admin's guide
193
<li> A list-admin's guide
194
<li> More on-line documentation and UI help
195
<li> A developer's guide w/ architecture and API information
196
<li> manpages for the scripts in bin and cron
197
<li> Integrate Christopher Kolar's documentation
202
<li> NO DEAD ENDS and every web page is reachable.
203
<li> All web UI must be configurable so that it more easily integrates into an existing site's design. Probably means using
204
a better template language/system like Zope's Presentation
205
Templates, Quixote, or PHP.
207
<li> Default UI should add a navigation sidebar to all web pages.
208
<li> Web pages should never mention disabled features.
209
<li> Allow a site admin and list admins to categorize lists, so that they can be better organized on the listinfo and admin overview
213
<h3> List Administration
216
<li> Allow the moderator to edit posts being held for approval (make it evident, either through a header or other means that the
217
message was edited by the moderator).
219
<li> Allow the admin to disable option settings by users
220
<li> Allow admins to block nomail settings
221
<li> Allow admins to control and set individual headers, adding, removing, or overriding those in the original message (sometimes
222
very useful, but could be dangerous!)
224
<li> New moderation choice: archive but don't send to list.
225
<li> New moderation choice: annotate and send to author for resubmittal. Or just be able to annotate the message for
226
multiple moderator scenarios.
228
<li> Better integration with moderated newsgroups (and allow some addresses to bypass even that moderation and be delivered to a
229
secondary channel, like moderators@isc.org).
231
<li> Allow a list to be marked `disabled' so things like the replybot still works, and the archives are still available, but mail
232
posted to the list is always returned unsent.
234
<li> Ability to `sideline' some messages in the moderation queue
235
<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
236
confirmation message. When they confirm, we moderate the
237
message as normal, but if they don't we assume it's spam (after
238
some period of time) and discard it. The admin should be able
239
to see all these super-quarantined messages with the flip of a
242
<li> Add a moderation option to pass through any message which is a reply to a message previously distributed through the list, even
243
if it comes from a non-member. Treat that non-member as a
244
member for the duration of the thread. Use In-Reply-To,
245
References and Message-ID to match these up.
247
<li> When a held message is forwarded (for admin editing and approved resend) there should be a way to auto-discard the held message
248
when the approved resend is received.
250
<li> Have an option to sort the list of members by real name or email address.
252
<li> Test a message for all hold criteria, record them all instead of just the first match, and do a SpamAssassin like scoring to
253
decide whether the message should get held or not.
259
<li> Have one account per user per site, with multiple email addresses and fallbacks. Allow them to subscribe whichever
260
address they want to whichever list, with different options per
263
<li> Allow the user to get BOTH normal and digested delivery (but I still don't understand why someone would want this)
265
<li> More flexible digests: index digests (subject and authors only, with URLs to retrieve the article)
267
<li> Timed vacations, allowing a user to postpone or discard email for a certain number of days or weeks.
269
<li> Keep user-centric stats, such as the date the user was subscribed, the date of their last change to their account, the
270
date they last sent a message through the list. Perhaps also
271
log each message they send through the list.
274
<h3> Site Administration
277
<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
280
<li> Allow the site admin to send an email message to all the list admins using a mechanism similar to the Urgent: header (possibly
281
by addressing it to mailman@site.dom).
284
<h3> Other Usability Improvments
287
<li> A better strategy is needed for sub-lists and super-lists, including dealing with the resulting password reminders and
288
authorization to modify the sub & superlists.
290
<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).
291
Also, limits on mailbacks, infos, etc.
294
<h3> Mailcmd interface
297
<li> Provide an email interface to all administrative commands
298
<li> Allow email unsubs from matching address to unsubscribe, possibly adding an "allow open unsubscribes" option to control
299
this. Also, adding a confirmation with click-thru confirmation
302
<li> For email subscribes, keep an audit of where requests are coming from, and send the original request headers in the confirmation
303
message. Helps track down subscribe bombs.
305
<li> Investigate Majordomo2's email admin capabilities.
306
<li> Support the `which' command.
308
<h3> Portability & architecture
311
<li> Use a real transactional database for all information, and allow various bits of information to come from different sources (a
312
relational database, ZODB, LDAP, etc)
315
<li> Allow lists of the same name in two different virtual domains
316
<li> Should be able to gather statistics, such as deliveries/day, performance, number of subscribers over time, etc.
318
<li> Implement something like Roundup's nosy lists, maybe even integrate with Roundup.
320
<li> Split Mailman into libraries so, e.g. the delivery part could be used by other projects.
326
<li> Add more patterns for bounce handling (never ending)
327
<li> Send mail to people who are being removed without their knowledge (even though they're likely not to get it).
330
<h3> Pipermail + Archiving mechanism
333
<li> Search engine for archives
334
<li> Provide downloadable tar.gz's of the html archives
335
<li> sort by date should go most-recent to oldest
336
<li> allow list owner to edit archive messages
337
<li> optional form front-end to public interfaces as a filter to address harvesters.
339
<li> In general the whole Pipermail subsystem needs a good rewrite.
340
<li> Write an API between Mailman and the archiver so that message footers can contain the URL to the archived message.
346
<li> Turn all remaining string exceptions into class exceptions
347
<li> Unit and system test suite! (ongoing)
350
</td><!-- end of body cell -->
351
</tr><!-- end of sidebar/body row -->
352
</table><!-- end of page table -->
added
removed
admin/www/todo.html
