summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorbwarsaw2001-06-25 21:27:44 +0000
committerbwarsaw2001-06-25 21:27:44 +0000
commit724e919d72ca0a227c96d37bf82d3df58e066114 (patch)
tree386aa742d07e2a6d39ba38e57c35e8c6da35e960
parentebb3f1e5f6848ca00a3750d4dbe62ef57b9c74b2 (diff)
downloadmailman-724e919d72ca0a227c96d37bf82d3df58e066114.tar.gz
mailman-724e919d72ca0a227c96d37bf82d3df58e066114.tar.zst
mailman-724e919d72ca0a227c96d37bf82d3df58e066114.zip
Updates from the FAQ and TODO files.
Also, add Tollef Fog Heen to list of acknowledgements.
Diffstat
-rw-r--r--admin/www/faq.ht20
-rw-r--r--admin/www/faq.html22
-rw-r--r--admin/www/index.ht3
-rw-r--r--admin/www/index.html9
-rw-r--r--admin/www/todo.ht27
-rw-r--r--admin/www/todo.html29
6 files changed, 53 insertions, 57 deletions
diff --git a/admin/www/faq.ht b/admin/www/faq.ht
index f2aedd759..817e515dd 100644
--- a/admin/www/faq.ht
+++ b/admin/www/faq.ht
@@ -27,6 +27,26 @@ Title: Mailman Frequently Asked Questions
end-users. Mailman is compliant with RFC 2369, which is where
these headers are defined. See the file README.USERAGENT for hints
on what to tell your end users.
+<p> <b> Q. Can I put the user's address in the footer that Mailman adds to
+ each message?
+
+</b><br> A. No. The reason is that, for efficiency, Mailman batches together
+ message delivery for many users at once. Putting the user's
+ address in the footer would require Mailman to craft a unique
+ message for each recipient, and this would likely unacceptably bog
+ down your system.
+<p> Some MTAs may provide may provide the ability to accomplish this,
+ using a technique akin to VERP (variable envelope return path).
+ You'll need to investigate the configuration options of your MTA
+ for details.
+<p> <b> Q. My users hate HTML in their email and for security reasons, I want
+ to strip out all MIME attachments. How can I do this?
+
+</b><br> A. Mailman 2.1 will probably have this feature built-in, but for now
+ you can use add-on tools such as demime or stripmime. More
+ information on these tools can be found at:
+<p> (Stripmime) <a href="http://www.phred.org/~alex/stripmime.html.">http://www.phred.org/~alex/stripmime.html.</a>
+ (Demime) <a href="http://scifi.squawk.com/demime.html.">http://scifi.squawk.com/demime.html.</a>
<p> <b> Q. What if I get "document contains no data" from the web server, or
mail isn't getting delivered, or I see "Premature end of script
headers" or "Mailman CGI error!!!"
diff --git a/admin/www/faq.html b/admin/www/faq.html
index 69e4d52bf..cdaac6a6f 100644
--- a/admin/www/faq.html
+++ b/admin/www/faq.html
@@ -1,6 +1,6 @@
<HTML>
<!-- THIS PAGE IS AUTOMATICALLY GENERATED. DO NOT EDIT. -->
-<!-- Wed May 16 22:31:39 2001 -->
+<!-- Mon Jun 25 17:26:20 2001 -->
<!-- USING HT2HTML 1.1 -->
<!-- SEE http://www.wooz.org/barry/software/pyware.html -->
<!-- User-specified headers:
@@ -173,6 +173,26 @@ Email Us
end-users. Mailman is compliant with RFC 2369, which is where
these headers are defined. See the file README.USERAGENT for hints
on what to tell your end users.
+<p> <b> Q. Can I put the user's address in the footer that Mailman adds to
+ each message?
+
+</b><br> A. No. The reason is that, for efficiency, Mailman batches together
+ message delivery for many users at once. Putting the user's
+ address in the footer would require Mailman to craft a unique
+ message for each recipient, and this would likely unacceptably bog
+ down your system.
+<p> Some MTAs may provide may provide the ability to accomplish this,
+ using a technique akin to VERP (variable envelope return path).
+ You'll need to investigate the configuration options of your MTA
+ for details.
+<p> <b> Q. My users hate HTML in their email and for security reasons, I want
+ to strip out all MIME attachments. How can I do this?
+
+</b><br> A. Mailman 2.1 will probably have this feature built-in, but for now
+ you can use add-on tools such as demime or stripmime. More
+ information on these tools can be found at:
+<p> (Stripmime) <a href="http://www.phred.org/~alex/stripmime.html.">http://www.phred.org/~alex/stripmime.html.</a>
+ (Demime) <a href="http://scifi.squawk.com/demime.html.">http://scifi.squawk.com/demime.html.</a>
<p> <b> Q. What if I get "document contains no data" from the web server, or
mail isn't getting delivered, or I see "Premature end of script
headers" or "Mailman CGI error!!!"
diff --git a/admin/www/index.ht b/admin/www/index.ht
index 95fb77b1c..09e87173e 100644
--- a/admin/www/index.ht
+++ b/admin/www/index.ht
@@ -61,7 +61,8 @@ Metheringham, Dan Mick, Jim Tittsler, Ricardo Kustner, Bernhard
Reiter, Thomas Wouters, Jeff Berliner, Ted Cabeen, Michael Yount, Ron
Jarrell, Chris Snell, David Champion, Darrell Fuhriman, Owen Taylor,
Fil, Noam Zeilberger, Mark MERLIN, John A. Martin, Erik Forsberg,
-Tanner Lovelace, Les Niles, Mike Noyes, Tokio Kikuchi, Vizi Szilard.
+Tanner Lovelace, Les Niles, Mike Noyes, Tokio Kikuchi, Vizi Szilard,
+Tollef Fog Heen.
<em>We have a extensive wish list and welcome anyone else who would
like to contribute!</em>
diff --git a/admin/www/index.html b/admin/www/index.html
index 0043cd404..fab73794c 100644
--- a/admin/www/index.html
+++ b/admin/www/index.html
@@ -1,6 +1,6 @@
<HTML>
<!-- THIS PAGE IS AUTOMATICALLY GENERATED. DO NOT EDIT. -->
-<!-- Fri May 25 14:17:23 2001 -->
+<!-- Mon Jun 25 17:26:20 2001 -->
<!-- USING HT2HTML 1.1 -->
<!-- SEE http://www.wooz.org/barry/software/pyware.html -->
<!-- User-specified headers:
@@ -154,7 +154,7 @@ Exits
<A HREF="http://www.list.org/">List.Org&nbsp;mirror</A>
</TD></TR>
<TR><TD BGCOLOR="#99997c">
-<A HREF="http://www.wooz.org/barry/">Barry Warsaw</A>
+<A HREF="http://barry.wooz.org/">Barry Warsaw</A>
</TD></TR>
<TR><TD BGCOLOR="#99997c">&nbsp;
<TR><TD BGCOLOR="#663300"><B><FONT COLOR="#ffffff">
@@ -226,7 +226,7 @@ is the current stable GNU release.
<p>Mailman is brought to you by the <em>Mailman Cabal</em>, currently
composed of the following core developers:
-<a href="http://www.wooz.org/barry/">Barry Warsaw</a>, Harald
+<a href="http://barry.wooz.org/">Barry Warsaw</a>, Harald
Meland, Ken Manheimer, Scott Cotton, and John Viega. Mailman was
originally written by John Viega.
@@ -240,7 +240,8 @@ Metheringham, Dan Mick, Jim Tittsler, Ricardo Kustner, Bernhard
Reiter, Thomas Wouters, Jeff Berliner, Ted Cabeen, Michael Yount, Ron
Jarrell, Chris Snell, David Champion, Darrell Fuhriman, Owen Taylor,
Fil, Noam Zeilberger, Mark MERLIN, John A. Martin, Erik Forsberg,
-Tanner Lovelace, Les Niles, Mike Noyes, Tokio Kikuchi, Vizi Szilard.
+Tanner Lovelace, Les Niles, Mike Noyes, Tokio Kikuchi, Vizi Szilard,
+Tollef Fog Heen.
<em>We have a extensive wish list and welcome anyone else who would
like to contribute!</em>
diff --git a/admin/www/todo.ht b/admin/www/todo.ht
index d62a2e311..abf75cd1b 100644
--- a/admin/www/todo.ht
+++ b/admin/www/todo.ht
@@ -2,14 +2,12 @@ Title: The Mailman Wishlist
<h3> The Mailman Wishlist
</h3>
- You should consider this list of items a good basis for the requirements for Mailman 3.0. It essentially contains a dream list of all the things that are too painful or destabilizing for the 2.x series. <p>
+ Here's the wish list for future versions of Mailman. Many new features have been added to Mailman 2.1 (still in alpha as of this writing 25-Jun-2001), so what's left will probably end up in a Mailman 3.0. <p>
<h3> Email Handling
</h3>
<ul>
<li> Use VERP or DSN for address tracing, perhaps tied to the monthly password reminders, or VERPing the occasional regular message.
- <li> Re-implement bulk mailer the Right Way: an asynchat/asyncore server to do DNS lookups and remote MTA delivery directly (optional).
- <li> Plain text digests should conform to RFC 1153.
- <li> If a message has MIME parts and the header/footer is going to be added, the message should be transformed into a mulitpart/mixed with the header and footer added as text/plain parts.
+ <li> Re-implement bulk mailer the Right Way: an asynchat/asyncore server to do DNS lookups and remote MTA delivery directly (optional).
</ul>
<h3> Documentation
</h3>
@@ -29,54 +27,41 @@ Title: The Mailman Wishlist
<li> NO DEAD ENDS
<li> All web UI must be configurable so that it more easily integrates into an existing site's design. Probably means using a template language/system like Quixote or PHP.
<li> Default UI should add a navigation sidebar to all web pages.
- <li> A heirarchy of page designs and information: e.g. the most specialized of the following wins: site, virtual host, list, language, user.
<li> Web pages should never mention turned-off features.
</ul>
<h3> List Administration
</h3>
<ul>
- <li> Separate list admin role from list moderator role
<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 "urgent" postings to all members by the list admin which bypasses normal digest delivery.
- <li> A button that will bundled and deliver a digest Right Now.
<li> Allow the list-admin to require approvals for unsubs
<li> Allow the admin to disable option settings by users
<li> Ability to set defaults for the various user settings from the "Membership Management" page.
<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> Member management page should display case-preserved email addresses (but still sort case-insensitively).
- <li> Member management page should work better for humongous lists, both in terms of performance, and in usability
- <li> Searching for members/addresses with regular expressions from both the command line and web interface.
<li> New moderation choice: archive but don't send to list.
<li> New moderation choice: annotate and send to author for resubmittal.
<li> Make it easier for an admin who manages multiple lists to handling pending requests sitting on all those lists.
<li> Ability to ban specific troublesome users (from posting, subscribing, etc). Posts from banned users would be discarded.
<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> Ability to set the next digest volume and issue number from the web
<li> Add an option to include Reply-To: header in the membership test for a members-only list posting
</ul>
<h3> List Membership
</h3>
<ul>
- <li> Editing your user options should put you back to the edit-options page
<li> Allow the user to be excluded from postings if they're getting them in the to: or cc: headers. Be smarter about filtering out duplicate deliveries.
<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> Allow users to subscribe without selecting a password and have Mailman create a password for them.
<li> Timed vacations, allowing a user to postpone or discard email for a certain number of days or weeks.
</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> Full creation, deletion, renaming, etc. of lists through the web (and email?), including fixing aliases file updates.
<li> add_members should have a switch to disable admin notifications
</ul>
<h3> Other Usability Improvments
</h3>
<ul>
- <li> Allow individuals to turn off password reminders
- <li> Confirmations should be both email and web based, and be used for both subscription and unsubscription (configurable by the list admin).
<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. Majordomo2 is reported to have some good features in this regard.
<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).
<li> Don't use the first public mailing list as the `originator' of password reminders.
@@ -86,7 +71,6 @@ Title: The Mailman Wishlist
<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 hit-reply to resubscribe
- <li> Add -join and -remove addresses for easy subscription, unsubscription
<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.
@@ -96,14 +80,12 @@ Title: The Mailman Wishlist
<ul>
<li> Replace cron stuff with our own scheduling mechanism.
<li> Get rid of the one-shot process model altogether in favor of a multithreaded monolithic architecture.
- <li> Better support for distributed processing
<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> Keep a members Real Name with their email address
<li> Member profiles
<li> Do a serious and thorough security audit
<li> Allow lists of the same name in two different virtual domains
<li> More sophisticated attachment handling: strip and discard attachments, post attachments (e.g. via WebDAV) and rewrite to include URLs, etc. Should be admin configurable based on MIME type. Check out Bill Bumgarner's work on this.
- <li> Should include a --with-username=NAME option to configure (and not require it be literally "mailman").
<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.
@@ -127,16 +109,11 @@ Title: The Mailman Wishlist
<li> allow list owner to edit archive messages
<li> archive link should do *something* reasonable before the first message has been posted to the list.
<li> optional form front-end to public interfaces as a filter to address harvesters.
- <li> clobber_date should support third option: only munge the date if the Date: field is unreasonable (far in the future or far in the past).
<li> In general the whole Pipermail subsystem needs a good rewrite.
</ul>
<h3> Code cleanup
</h3>
<ul>
- <li> Use all the new wizzy Python 2.0 features
- <li> Use the re module where regexp and regsub are used (not many left)
- <li> Refine any remaining unqualified exception guards to specify target exceptions, when appropriate.
<li> Turn all remaining string exceptions into class exceptions
- <li> Remove dead code.
<li> Unit and system test suite!
</ul>
diff --git a/admin/www/todo.html b/admin/www/todo.html
index c372172c5..43d6c0b29 100644
--- a/admin/www/todo.html
+++ b/admin/www/todo.html
@@ -1,6 +1,6 @@
<HTML>
<!-- THIS PAGE IS AUTOMATICALLY GENERATED. DO NOT EDIT. -->
-<!-- Wed May 16 22:31:40 2001 -->
+<!-- Mon Jun 25 17:26:20 2001 -->
<!-- USING HT2HTML 1.1 -->
<!-- SEE http://www.wooz.org/barry/software/pyware.html -->
<!-- User-specified headers:
@@ -148,14 +148,12 @@ Email Us
<TD VALIGN=TOP WIDTH="90%"><BR>
<h3> The Mailman Wishlist
</h3>
- You should consider this list of items a good basis for the requirements for Mailman 3.0. It essentially contains a dream list of all the things that are too painful or destabilizing for the 2.x series. <p>
+ Here's the wish list for future versions of Mailman. Many new features have been added to Mailman 2.1 (still in alpha as of this writing 25-Jun-2001), so what's left will probably end up in a Mailman 3.0. <p>
<h3> Email Handling
</h3>
<ul>
<li> Use VERP or DSN for address tracing, perhaps tied to the monthly password reminders, or VERPing the occasional regular message.
- <li> Re-implement bulk mailer the Right Way: an asynchat/asyncore server to do DNS lookups and remote MTA delivery directly (optional).
- <li> Plain text digests should conform to RFC 1153.
- <li> If a message has MIME parts and the header/footer is going to be added, the message should be transformed into a mulitpart/mixed with the header and footer added as text/plain parts.
+ <li> Re-implement bulk mailer the Right Way: an asynchat/asyncore server to do DNS lookups and remote MTA delivery directly (optional).
</ul>
<h3> Documentation
</h3>
@@ -175,54 +173,41 @@ Email Us
<li> NO DEAD ENDS
<li> All web UI must be configurable so that it more easily integrates into an existing site's design. Probably means using a template language/system like Quixote or PHP.
<li> Default UI should add a navigation sidebar to all web pages.
- <li> A heirarchy of page designs and information: e.g. the most specialized of the following wins: site, virtual host, list, language, user.
<li> Web pages should never mention turned-off features.
</ul>
<h3> List Administration
</h3>
<ul>
- <li> Separate list admin role from list moderator role
<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 "urgent" postings to all members by the list admin which bypasses normal digest delivery.
- <li> A button that will bundled and deliver a digest Right Now.
<li> Allow the list-admin to require approvals for unsubs
<li> Allow the admin to disable option settings by users
<li> Ability to set defaults for the various user settings from the "Membership Management" page.
<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> Member management page should display case-preserved email addresses (but still sort case-insensitively).
- <li> Member management page should work better for humongous lists, both in terms of performance, and in usability
- <li> Searching for members/addresses with regular expressions from both the command line and web interface.
<li> New moderation choice: archive but don't send to list.
<li> New moderation choice: annotate and send to author for resubmittal.
<li> Make it easier for an admin who manages multiple lists to handling pending requests sitting on all those lists.
<li> Ability to ban specific troublesome users (from posting, subscribing, etc). Posts from banned users would be discarded.
<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> Ability to set the next digest volume and issue number from the web
<li> Add an option to include Reply-To: header in the membership test for a members-only list posting
</ul>
<h3> List Membership
</h3>
<ul>
- <li> Editing your user options should put you back to the edit-options page
<li> Allow the user to be excluded from postings if they're getting them in the to: or cc: headers. Be smarter about filtering out duplicate deliveries.
<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> Allow users to subscribe without selecting a password and have Mailman create a password for them.
<li> Timed vacations, allowing a user to postpone or discard email for a certain number of days or weeks.
</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> Full creation, deletion, renaming, etc. of lists through the web (and email?), including fixing aliases file updates.
<li> add_members should have a switch to disable admin notifications
</ul>
<h3> Other Usability Improvments
</h3>
<ul>
- <li> Allow individuals to turn off password reminders
- <li> Confirmations should be both email and web based, and be used for both subscription and unsubscription (configurable by the list admin).
<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. Majordomo2 is reported to have some good features in this regard.
<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).
<li> Don't use the first public mailing list as the `originator' of password reminders.
@@ -232,7 +217,6 @@ Email Us
<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 hit-reply to resubscribe
- <li> Add -join and -remove addresses for easy subscription, unsubscription
<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.
@@ -242,14 +226,12 @@ Email Us
<ul>
<li> Replace cron stuff with our own scheduling mechanism.
<li> Get rid of the one-shot process model altogether in favor of a multithreaded monolithic architecture.
- <li> Better support for distributed processing
<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> Keep a members Real Name with their email address
<li> Member profiles
<li> Do a serious and thorough security audit
<li> Allow lists of the same name in two different virtual domains
<li> More sophisticated attachment handling: strip and discard attachments, post attachments (e.g. via WebDAV) and rewrite to include URLs, etc. Should be admin configurable based on MIME type. Check out Bill Bumgarner's work on this.
- <li> Should include a --with-username=NAME option to configure (and not require it be literally "mailman").
<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.
@@ -273,17 +255,12 @@ Email Us
<li> allow list owner to edit archive messages
<li> archive link should do *something* reasonable before the first message has been posted to the list.
<li> optional form front-end to public interfaces as a filter to address harvesters.
- <li> clobber_date should support third option: only munge the date if the Date: field is unreasonable (far in the future or far in the past).
<li> In general the whole Pipermail subsystem needs a good rewrite.
</ul>
<h3> Code cleanup
</h3>
<ul>
- <li> Use all the new wizzy Python 2.0 features
- <li> Use the re module where regexp and regsub are used (not many left)
- <li> Refine any remaining unqualified exception guards to specify target exceptions, when appropriate.
<li> Turn all remaining string exceptions into class exceptions
- <li> Remove dead code.
<li> Unit and system test suite!
</ul>
generated by cgit v1.2.3-70-g09d2 (git 2.51.2) at 2025-11-09 23:20:16 +0000