From 3a258ad5cdd98c5705af6c02ba91993b3d382adc Mon Sep 17 00:00:00 2001 From: Barry Warsaw Date: Wed, 5 Dec 2007 17:23:41 -0500 Subject: Because the admin directory is no longer included, the www directory isn't either, and that's where the generated docs used to live. So now, make this directory include the generated docs, removing the old IPC7 and LISA-98 directories, and the .tex source files. These latter are moved to the admin repository. --- doc/mailman-admin/WARNINGS | 3 + doc/mailman-admin/about.html | 112 ++++++++++++ doc/mailman-admin/blank.png | Bin 0 -> 1031 bytes doc/mailman-admin/contents.html | 126 ++++++++++++++ doc/mailman-admin/contents.png | Bin 0 -> 649 bytes doc/mailman-admin/front.html | 114 +++++++++++++ doc/mailman-admin/index.dat | 0 doc/mailman-admin/index.html | 130 ++++++++++++++ doc/mailman-admin/index.png | Bin 0 -> 529 bytes doc/mailman-admin/internals.pl | 18 ++ doc/mailman-admin/intlabels.pl | 3 + doc/mailman-admin/labels.pl | 25 +++ doc/mailman-admin/mailman-admin.css | 243 ++++++++++++++++++++++++++ doc/mailman-admin/mailman-admin.html | 130 ++++++++++++++ doc/mailman-admin/modules.png | Bin 0 -> 598 bytes doc/mailman-admin/next.png | Bin 0 -> 511 bytes doc/mailman-admin/node10.html | 199 ++++++++++++++++++++++ doc/mailman-admin/node11.html | 200 ++++++++++++++++++++++ doc/mailman-admin/node12.html | 100 +++++++++++ doc/mailman-admin/node13.html | 184 ++++++++++++++++++++ doc/mailman-admin/node14.html | 207 +++++++++++++++++++++++ doc/mailman-admin/node15.html | 120 +++++++++++++ doc/mailman-admin/node16.html | 156 +++++++++++++++++ doc/mailman-admin/node17.html | 108 ++++++++++++ doc/mailman-admin/node18.html | 318 +++++++++++++++++++++++++++++++++++ doc/mailman-admin/node19.html | 226 +++++++++++++++++++++++++ doc/mailman-admin/node20.html | 179 ++++++++++++++++++++ doc/mailman-admin/node21.html | 204 ++++++++++++++++++++++ doc/mailman-admin/node22.html | 215 +++++++++++++++++++++++ doc/mailman-admin/node23.html | 133 +++++++++++++++ doc/mailman-admin/node24.html | 131 +++++++++++++++ doc/mailman-admin/node25.html | 196 +++++++++++++++++++++ doc/mailman-admin/node26.html | 137 +++++++++++++++ doc/mailman-admin/node27.html | 101 +++++++++++ doc/mailman-admin/node28.html | 94 +++++++++++ doc/mailman-admin/node29.html | 94 +++++++++++ doc/mailman-admin/node3.html | 129 ++++++++++++++ doc/mailman-admin/node30.html | 95 +++++++++++ doc/mailman-admin/node31.html | 94 +++++++++++ doc/mailman-admin/node32.html | 94 +++++++++++ doc/mailman-admin/node33.html | 94 +++++++++++ doc/mailman-admin/node34.html | 98 +++++++++++ doc/mailman-admin/node35.html | 113 +++++++++++++ doc/mailman-admin/node4.html | 160 ++++++++++++++++++ doc/mailman-admin/node5.html | 126 ++++++++++++++ doc/mailman-admin/node6.html | 135 +++++++++++++++ doc/mailman-admin/node7.html | 147 ++++++++++++++++ doc/mailman-admin/node8.html | 177 +++++++++++++++++++ doc/mailman-admin/node9.html | 117 +++++++++++++ doc/mailman-admin/previous.png | Bin 0 -> 511 bytes doc/mailman-admin/pyfav.png | Bin 0 -> 240 bytes doc/mailman-admin/up.png | Bin 0 -> 577 bytes 52 files changed, 5785 insertions(+) create mode 100644 doc/mailman-admin/WARNINGS create mode 100644 doc/mailman-admin/about.html create mode 100644 doc/mailman-admin/blank.png create mode 100644 doc/mailman-admin/contents.html create mode 100644 doc/mailman-admin/contents.png create mode 100644 doc/mailman-admin/front.html create mode 100644 doc/mailman-admin/index.dat create mode 100644 doc/mailman-admin/index.html create mode 100644 doc/mailman-admin/index.png create mode 100644 doc/mailman-admin/internals.pl create mode 100644 doc/mailman-admin/intlabels.pl create mode 100644 doc/mailman-admin/labels.pl create mode 100644 doc/mailman-admin/mailman-admin.css create mode 100644 doc/mailman-admin/mailman-admin.html create mode 100644 doc/mailman-admin/modules.png create mode 100644 doc/mailman-admin/next.png create mode 100644 doc/mailman-admin/node10.html create mode 100644 doc/mailman-admin/node11.html create mode 100644 doc/mailman-admin/node12.html create mode 100644 doc/mailman-admin/node13.html create mode 100644 doc/mailman-admin/node14.html create mode 100644 doc/mailman-admin/node15.html create mode 100644 doc/mailman-admin/node16.html create mode 100644 doc/mailman-admin/node17.html create mode 100644 doc/mailman-admin/node18.html create mode 100644 doc/mailman-admin/node19.html create mode 100644 doc/mailman-admin/node20.html create mode 100644 doc/mailman-admin/node21.html create mode 100644 doc/mailman-admin/node22.html create mode 100644 doc/mailman-admin/node23.html create mode 100644 doc/mailman-admin/node24.html create mode 100644 doc/mailman-admin/node25.html create mode 100644 doc/mailman-admin/node26.html create mode 100644 doc/mailman-admin/node27.html create mode 100644 doc/mailman-admin/node28.html create mode 100644 doc/mailman-admin/node29.html create mode 100644 doc/mailman-admin/node3.html create mode 100644 doc/mailman-admin/node30.html create mode 100644 doc/mailman-admin/node31.html create mode 100644 doc/mailman-admin/node32.html create mode 100644 doc/mailman-admin/node33.html create mode 100644 doc/mailman-admin/node34.html create mode 100644 doc/mailman-admin/node35.html create mode 100644 doc/mailman-admin/node4.html create mode 100644 doc/mailman-admin/node5.html create mode 100644 doc/mailman-admin/node6.html create mode 100644 doc/mailman-admin/node7.html create mode 100644 doc/mailman-admin/node8.html create mode 100644 doc/mailman-admin/node9.html create mode 100644 doc/mailman-admin/previous.png create mode 100644 doc/mailman-admin/pyfav.png create mode 100644 doc/mailman-admin/up.png (limited to 'doc/mailman-admin') diff --git a/doc/mailman-admin/WARNINGS b/doc/mailman-admin/WARNINGS new file mode 100644 index 00000000..355383a0 --- /dev/null +++ b/doc/mailman-admin/WARNINGS @@ -0,0 +1,3 @@ +couldn't convert character (circ into available encodings + + ...set $ACCENT_IMAGES to get an image diff --git a/doc/mailman-admin/about.html b/doc/mailman-admin/about.html new file mode 100644 index 00000000..153099b2 --- /dev/null +++ b/doc/mailman-admin/about.html @@ -0,0 +1,112 @@ + + + + + + + + + + + + +About this document ... + + +
+
+ + + + + + + + + +
Up one LevelNext PageGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +GNU Mailman - List +
+
+
+ + +

+About this document ... +

+ GNU Mailman - List Administration Manual, +December 5, 2007, Release 2.1 +

This document was generated using the + LaTeX2HTML translator. +

+ +

+ LaTeX2HTML is Copyright © + 1993, 1994, 1995, 1996, 1997, Nikos + Drakos, Computer Based Learning Unit, University of + Leeds, and Copyright © 1997, 1998, Ross + Moore, Mathematics Department, Macquarie University, + Sydney. +

+ +

The application of + LaTeX2HTML to the Python + documentation has been heavily tailored by Fred L. Drake, + Jr. Original navigation icons were contributed by Christopher + Petrilli. +

+ +
+
+

+ + + + + + + + + +
Up one LevelNext PageGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +GNU Mailman - List +
+
+
+Release 2.1, documentation updated on December 5, 2007. +
+ + + + diff --git a/doc/mailman-admin/blank.png b/doc/mailman-admin/blank.png new file mode 100644 index 00000000..2af5639b Binary files /dev/null and b/doc/mailman-admin/blank.png differ diff --git a/doc/mailman-admin/contents.html b/doc/mailman-admin/contents.html new file mode 100644 index 00000000..24113e68 --- /dev/null +++ b/doc/mailman-admin/contents.html @@ -0,0 +1,126 @@ + + + + + + + + + + + + + + +Contents + + +
+
+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration Manual
+
+Previous: + +Up: +GNU Mailman - List +Next: + +
+
+
+ +

+Contents +

+ + + + +

+ +

+
+

+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration Manual
+
+Previous: + +Up: +GNU Mailman - List +Next: + +
+
+
+Release 2.1, documentation updated on December 5, 2007. +
+ + + + diff --git a/doc/mailman-admin/contents.png b/doc/mailman-admin/contents.png new file mode 100644 index 00000000..3429be0c Binary files /dev/null and b/doc/mailman-admin/contents.png differ diff --git a/doc/mailman-admin/front.html b/doc/mailman-admin/front.html new file mode 100644 index 00000000..b0977103 --- /dev/null +++ b/doc/mailman-admin/front.html @@ -0,0 +1,114 @@ + + + + + + + + + + + + + + +Front Matter + + +
+
+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +GNU Mailman - List +Next: + +
+
+
+ + +

+
+Front Matter +

+ +

+ +

Abstract:

+
+ +This document describes the list administrator's interface for GNU +Mailman 2.1. It contains information a list owner would need to +configure their list, either through the web interface or through +email. It also covers the moderator's interface for approving held +messages and subscription notices, and the web interface for creating +new mailing lists. In general, it does not cover the command line +interface to Mailman, installing Mailman, or interacting with Mailman +from the point of view of the user. That information is covered in +other manuals. +
+

+ +

+ +

+
+

+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +GNU Mailman - List +Next: + +
+
+
+Release 2.1, documentation updated on December 5, 2007. +
+ + + + diff --git a/doc/mailman-admin/index.dat b/doc/mailman-admin/index.dat new file mode 100644 index 00000000..e69de29b diff --git a/doc/mailman-admin/index.html b/doc/mailman-admin/index.html new file mode 100644 index 00000000..d79769ad --- /dev/null +++ b/doc/mailman-admin/index.html @@ -0,0 +1,130 @@ + + + + + + + + + + + +GNU Mailman - List Administration Manual + + +
+
+ + + + + + + + + +
Previous PageUp one LevelGNU Mailman - List Administration ManualContents
+
+Next: + +
+
+
+ + +
+
+

GNU Mailman - List Administration Manual

+

Barry A. Warsaw

+

Release 2.1
+December 5, 2007

+

+
+
+ +

+ +


+
+ + + + + +
+ +
+
+

+ + + + + + + + + +
Previous PageUp one LevelGNU Mailman - List Administration ManualContents
+
+Next: + +
+
+
+Release 2.1, documentation updated on December 5, 2007. +
+ + + + diff --git a/doc/mailman-admin/index.png b/doc/mailman-admin/index.png new file mode 100644 index 00000000..cd918afe Binary files /dev/null and b/doc/mailman-admin/index.png differ diff --git a/doc/mailman-admin/internals.pl b/doc/mailman-admin/internals.pl new file mode 100644 index 00000000..8ef71735 --- /dev/null +++ b/doc/mailman-admin/internals.pl @@ -0,0 +1,18 @@ +# LaTeX2HTML 2002-2-1 (1.71) +# Associate internals original text with physical files. + + +$key = q/front/; +$ref_files{$key} = "$dir".q|node1.html|; +$noresave{$key} = "$nosave"; + +$key = q/contents/; +$ref_files{$key} = "$dir".q|node2.html|; +$noresave{$key} = "$nosave"; + +$key = q/about/; +$ref_files{$key} = "$dir".q|node36.html|; +$noresave{$key} = "$nosave"; + +1; + diff --git a/doc/mailman-admin/intlabels.pl b/doc/mailman-admin/intlabels.pl new file mode 100644 index 00000000..44814752 --- /dev/null +++ b/doc/mailman-admin/intlabels.pl @@ -0,0 +1,3 @@ +%internal_labels = (); +1; # hack in case there are no entries + diff --git a/doc/mailman-admin/labels.pl b/doc/mailman-admin/labels.pl new file mode 100644 index 00000000..70f0223d --- /dev/null +++ b/doc/mailman-admin/labels.pl @@ -0,0 +1,25 @@ +# LaTeX2HTML 2002-2-1 (1.71) +# Associate labels original text with physical files. + + +$key = q/front/; +$external_labels{$key} = "$URL/" . q|node1.html|; +$noresave{$key} = "$nosave"; + +$key = q/contents/; +$external_labels{$key} = "$URL/" . q|node2.html|; +$noresave{$key} = "$nosave"; + +$key = q/about/; +$external_labels{$key} = "$URL/" . q|node36.html|; +$noresave{$key} = "$nosave"; + +1; + + +# LaTeX2HTML 2002-2-1 (1.71) +# labels from external_latex_labels array. + + +1; + diff --git a/doc/mailman-admin/mailman-admin.css b/doc/mailman-admin/mailman-admin.css new file mode 100644 index 00000000..06a613c2 --- /dev/null +++ b/doc/mailman-admin/mailman-admin.css @@ -0,0 +1,243 @@ +/* + * The first part of this is the standard CSS generated by LaTeX2HTML, + * with the "empty" declarations removed. + */ + +/* Century Schoolbook font is very similar to Computer Modern Math: cmmi */ +.math { font-family: "Century Schoolbook", serif; } +.math i { font-family: "Century Schoolbook", serif; + font-weight: bold } +.boldmath { font-family: "Century Schoolbook", serif; + font-weight: bold } + +/* + * Implement both fixed-size and relative sizes. + * + * I think these can be safely removed, as it doesn't appear that + * LaTeX2HTML ever generates these, even though these are carried + * over from the LaTeX2HTML stylesheet. + */ +small.xtiny { font-size : xx-small; } +small.tiny { font-size : x-small; } +small.scriptsize { font-size : smaller; } +small.footnotesize { font-size : small; } +big.xlarge { font-size : large; } +big.xxlarge { font-size : x-large; } +big.huge { font-size : larger; } +big.xhuge { font-size : xx-large; } + +/* + * Document-specific styles come next; + * these are added for the Python documentation. + * + * Note that the size specifications for the H* elements are because + * Netscape on Solaris otherwise doesn't get it right; they all end up + * the normal text size. + */ + +body { color: #000000; + background-color: #ffffff; } + +a:link:active { color: #ff0000; } +a:link:hover { background-color: #bbeeff; } +a:visited:hover { background-color: #bbeeff; } +a:visited { color: #551a8b; } +a:link { color: #0000bb; } + +h1, h2, h3, h4, h5, h6 { font-family: avantgarde, sans-serif; + font-weight: bold; } +h1 { font-size: 180%; } +h2 { font-size: 150%; } +h3, h4 { font-size: 120%; } + +/* These are section titles used in navigation links, so make sure we + * match the section header font here, even it not the weight. + */ +.sectref { font-family: avantgarde, sans-serif; } +/* And the label before the titles in navigation: */ +.navlabel { font-size: 85%; } + + +/* LaTeX2HTML insists on inserting
elements into headers which + * are marked with \label. This little bit of CSS magic ensures that + * these elements don't cause spurious whitespace to be added. + */ +h1>br, h2>br, h3>br, +h4>br, h5>br, h6>br { display: none; } + +code, tt { font-family: "lucida typewriter", lucidatypewriter, + monospace; } +var { font-family: times, serif; + font-style: italic; + font-weight: normal; } + +.Unix { font-variant: small-caps; } + +.typelabel { font-family: lucida, sans-serif; } + +.navigation td { background-color: #99ccff; + font-weight: bold; + font-family: avantgarde, sans-serif; + font-size: 110%; } + +div.warning { background-color: #fffaf0; + border: thin solid black; + padding: 1em; + margin-left: 2em; + margin-right: 2em; } + +div.warning .label { font-family: sans-serif; + font-size: 110%; + margin-right: 0.5em; } + +div.note { background-color: #fffaf0; + border: thin solid black; + padding: 1em; + margin-left: 2em; + margin-right: 2em; } + +div.note .label { margin-right: 0.5em; + font-family: sans-serif; } + +address { font-size: 80%; } +.release-info { font-style: italic; + font-size: 80%; } + +.titlegraphic { vertical-align: top; } + +.verbatim pre { color: #00008b; + font-family: "lucida typewriter", lucidatypewriter, + monospace; + font-size: 90%; } +.verbatim { margin-left: 2em; } +.verbatim .footer { padding: 0.05in; + font-size: 85%; + background-color: #99ccff; + margin-right: 0.5in; } + +.grammar { background-color: #99ccff; + margin-right: 0.5in; + padding: 0.05in; } +.grammar-footer { padding: 0.05in; + font-size: 85%; } +.grammartoken { font-family: "lucida typewriter", lucidatypewriter, + monospace; } + +.productions { background-color: #bbeeff; } +.productions a:active { color: #ff0000; } +.productions a:link:hover { background-color: #99ccff; } +.productions a:visited:hover { background-color: #99ccff; } +.productions a:visited { color: #551a8b; } +.productions a:link { color: #0000bb; } +.productions table { vertical-align: baseline; + empty-cells: show; } +.productions > table td, +.productions > table th { padding: 2px; } +.productions > table td:first-child, +.productions > table td:last-child { + font-family: "lucida typewriter", + lucidatypewriter, + monospace; + } +/* same as the second selector above, but expressed differently for Opera */ +.productions > table td:first-child + td + td { + font-family: "lucida typewriter", + lucidatypewriter, + monospace; + vertical-align: baseline; + } +.productions > table td:first-child + td { + padding-left: 1em; + padding-right: 1em; + } +.productions > table tr { vertical-align: baseline; } + +.email { font-family: avantgarde, sans-serif; } +.mailheader { font-family: avantgarde, sans-serif; } +.mimetype { font-family: avantgarde, sans-serif; } +.newsgroup { font-family: avantgarde, sans-serif; } +.url { font-family: avantgarde, sans-serif; } +.file { font-family: avantgarde, sans-serif; } +.guilabel { font-family: avantgarde, sans-serif; } + +.realtable { border-collapse: collapse; + border-color: black; + border-style: solid; + border-width: 0px 0px 2px 0px; + empty-cells: show; + margin-left: auto; + margin-right: auto; + padding-left: 0.4em; + padding-right: 0.4em; + } +.realtable tbody { vertical-align: baseline; } +.realtable tfoot { display: table-footer-group; } +.realtable thead { background-color: #99ccff; + border-width: 0px 0px 2px 1px; + display: table-header-group; + font-family: avantgarde, sans-serif; + font-weight: bold; + vertical-align: baseline; + } +.realtable thead :first-child { + border-width: 0px 0px 2px 0px; + } +.realtable thead th { border-width: 0px 0px 2px 1px } +.realtable td, +.realtable th { border-color: black; + border-style: solid; + border-width: 0px 0px 1px 1px; + padding-left: 0.4em; + padding-right: 0.4em; + } +.realtable td:first-child, +.realtable th:first-child { + border-left-width: 0px; + vertical-align: baseline; + } +.center { text-align: center; } +.left { text-align: left; } +.right { text-align: right; } + +.refcount-info { font-style: italic; } +.refcount-info .value { font-weight: bold; + color: #006600; } + +/* + * Some decoration for the "See also:" blocks, in part inspired by some of + * the styling on Lars Marius Garshol's XSA pages. + * (The blue in the navigation bars is #99CCFF.) + */ +.seealso { background-color: #fffaf0; + border: thin solid black; + padding: 0pt 1em 4pt 1em; } + +.seealso > .heading { font-size: 110%; + font-weight: bold; } + +/* + * Class 'availability' is used for module availability statements at + * the top of modules. + */ +.availability .platform { font-weight: bold; } + + +/* + * Additional styles for the distutils package. + */ +.du-command { font-family: monospace; } +.du-option { font-family: avantgarde, sans-serif; } +.du-filevar { font-family: avantgarde, sans-serif; + font-style: italic; } +.du-xxx:before { content: "** "; + font-weight: bold; } +.du-xxx:after { content: " **"; + font-weight: bold; } + + +/* + * Some specialization for printed output. + */ +@media print { + .online-navigation { display: none; } + } diff --git a/doc/mailman-admin/mailman-admin.html b/doc/mailman-admin/mailman-admin.html new file mode 100644 index 00000000..d79769ad --- /dev/null +++ b/doc/mailman-admin/mailman-admin.html @@ -0,0 +1,130 @@ + + + + + + + + + + + +GNU Mailman - List Administration Manual + + +
+
+ + + + + + + + + +
Previous PageUp one LevelGNU Mailman - List Administration ManualContents
+
+Next: + +
+
+
+ + +
+
+

GNU Mailman - List Administration Manual

+

Barry A. Warsaw

+

Release 2.1
+December 5, 2007

+

+
+
+ +

+ +


+
+ + + + + +
+ +
+
+

+ + + + + + + + + +
Previous PageUp one LevelGNU Mailman - List Administration ManualContents
+
+Next: + +
+
+
+Release 2.1, documentation updated on December 5, 2007. +
+ + + + diff --git a/doc/mailman-admin/modules.png b/doc/mailman-admin/modules.png new file mode 100644 index 00000000..8fa8b755 Binary files /dev/null and b/doc/mailman-admin/modules.png differ diff --git a/doc/mailman-admin/next.png b/doc/mailman-admin/next.png new file mode 100644 index 00000000..cfe5e51c Binary files /dev/null and b/doc/mailman-admin/next.png differ diff --git a/doc/mailman-admin/node10.html b/doc/mailman-admin/node10.html new file mode 100644 index 00000000..29a6bb8d --- /dev/null +++ b/doc/mailman-admin/node10.html @@ -0,0 +1,199 @@ + + + + + + + + + + + + + + +2.1.1 General list personality + + +
+
+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2.1 The General Options +Next: + +
+
+
+ + +

+2.1.1 General list personality +

+ +

+These variables, grouped under the general list personality section, +control some public information about the mailing list. + +

+

+
real_name
+
Every mailing list has both a posting name and a real + name. The posting name shows up in urls and in email addresses, + e.g. the mylist in mylist@example.com. The posting + name is always presented in lower case, with alphanumeric + characters and no spaces. The list's real name is used in some + public information and email responses, such as in the general + list overview. The real name can differ from the posting name by + case only. For example, if the posting name is mylist, the + real name can be Posting. + +

+

+
owner
+
This variable contains a list of email addresses, one address per + line, of the list owners. These addresses are used whenever the + list owners need to be contacted, either by the system or by end + users. Often, these addresses are used in combination with the + moderator addresses (see below). + +

+

+
moderator
+
This variable contains a list of email addresses, one address per + line, of the list moderators. These addresses are often used in + combination with the owner addresses. For example, when + you email mylist-owner@example.com, both the owner and + moderator addresses will receive a copy of the message. + +

+

+
description
+
In the general list overview page, which shows you every available + mailing list, each list is displayed with a short description. + The contents of this variable is that description. Note that in + emails from the mailing list, this description is also used in the + comment section of the To: address. This text should + be relatively short and no longer than one line. + +

+

+
info
+
This variable contains a longer description of the mailing list. + It is included at the top of the list's information page, and it + can contain HTML. However, blank lines will be automatically + converted into paragraph breaks. Preview your HTML though, + because unclosed or invalid HTML can prevent display of parts of + the list information page. + +

+

+
subject_prefix
+
This is a string that will be prepended to the + Subject: header of any message posted to the list. + For example, if a message is posted to the list with a + Subject: like: + +

+

+    Subject: This is a message
+
+ +

+and the subject_prefix is [My List] (note the + trailing space!), then the message will be received like so: + +

+

+    Subject: [My List] This is a message
+
+ +

+If you leave subject_prefix empty, no prefix will be added + to the Subject:. Mailman is careful not to add a + prefix when the header already has one, as is the case in replies + for example. The prefix can also contain characters in the list's + preferred language. In this case, because of vagarities of the + email standards, you may or may not want to add a trailing space. + +

+

+
anonymous_list
+
This variable allows you to turn on some simple anonymizing + features of Mailman. When you set this option to Yes, + Mailman will remove or replace the From:, + Sender:, and Reply-To: fields of any + message posted to the list. + +

+Note that this option is simply an aid for anonymization, it + doesn't guarantee it. For example, a poster's identity could be + evident in their signature, or in other mail headers, or even in + the style of the content of the message. There's little Mailman + can do about this kind of identity leakage. +

+
+ +

+ +

+
+

+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2.1 The General Options +Next: + +
+
+
+Release 2.1, documentation updated on December 5, 2007. +
+ + + + diff --git a/doc/mailman-admin/node11.html b/doc/mailman-admin/node11.html new file mode 100644 index 00000000..665d5bfd --- /dev/null +++ b/doc/mailman-admin/node11.html @@ -0,0 +1,200 @@ + + + + + + + + + + + + + + +2.1.2 Reply-To header munging + + +
+
+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2.1 The General Options +Next: + +
+
+
+ + +

+2.1.2 Reply-To header munging +

+ +

+This section controls what happens to the Reply-To: +headers of messages posted through your list. + +

+Beware! Reply-To: munging is considered a religious issue +and the policies you set here can ignite some of the most heated +off-topic flame wars on your mailing lists. We'll try to stay as +agnostic as possible, but our biases may still peak through. + +

+Reply-To: is a header that is commonly used to redirect +replies to messages. Exactly what happens when your uses reply to +such a message depends on the mail readers your users use, and what +functions they provide. Usually, there is both a ``reply to sender'' +button and a ``reply to all'' button. If people use these buttons +correctly, you will probably never need to munge +Reply-To:, so the default values should be fine. + +

+Since an informed decision is always best, here are links to two +articles that discuss the opposing viewpoints in great detail: + +

+ +

+ +

+The three options in this section work together to provide enough +flexibility to do whatever Reply-To: munging you might +(misguidingly :) feel you need to do. + +

+

+
first_strip_reply_to
+
This variable controls whether any Reply-To: header + already present in the posted message should get removed before + any other munging occurs. Stripping this header will be done + regardless of whether or not Mailman will add its own + Reply-To: header to the message. + +

+If this option is set to No, then any existing + Reply-To: header will be retained in the posted + message. If Mailman adds its own header, it will contain + addresses which are the union of the original header and the + Mailman added addresses. The mail standards specify that a + message may only have one Reply-To: header, but that + that header may contain multiple addresses. + +

+

+
reply_goes_to_list
+
This variable controls whether Mailman will add its own + Reply-To: header, and if so, what the value of that + header will be (not counting original header stripping - see + above). + +

+When you set this variable to Poster, no additional + Reply-To: header will be added by Mailman. This + setting is strongly recommended. + +

+When you set this variable to This list, a + Reply-To: header pointing back to your list's posting + address will be added. + +

+When you set this variable to Explicit address, the value + of the variable reply_to_address (see below) will be + added. Note that this is one situation where + Reply-To: munging may have a legitimate purpose. Say + you have two lists at your site, an announce list and a discussion + list. The announce list might allow postings only from a small + number of approved users; the general list membership probably + can't post to this list. But you want to allow comments on + announcements to be posted to the general discussion list by any + list member. In this case, you can set the Reply-To: + header for the announce list to point to the discussion list's + posting address. + +

+

+
reply_to_address
+
This is the address that will be added in the + Reply-To: header if reply_goes_to_list is set + to Explicit address. + +

+

+
+ +

+ +

+
+

+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2.1 The General Options +Next: + +
+
+
+Release 2.1, documentation updated on December 5, 2007. +
+ + + + diff --git a/doc/mailman-admin/node12.html b/doc/mailman-admin/node12.html new file mode 100644 index 00000000..1f4a69cc --- /dev/null +++ b/doc/mailman-admin/node12.html @@ -0,0 +1,100 @@ + + + + + + + + + + + + + + +2.1.3 Umbrella list settings + + +
+
+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2.1 The General Options +Next: + +
+
+
+ + +

+2.1.3 Umbrella list settings +

+ +

+TBD. Note that umbrella lists are deprecated and will be replace with +a better mechanism for Mailman 3.0. + +

+ +

+
+

+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2.1 The General Options +Next: + +
+
+
+Release 2.1, documentation updated on December 5, 2007. +
+ + + + diff --git a/doc/mailman-admin/node13.html b/doc/mailman-admin/node13.html new file mode 100644 index 00000000..bbf848ce --- /dev/null +++ b/doc/mailman-admin/node13.html @@ -0,0 +1,184 @@ + + + + + + + + + + + + + + +2.1.4 Notifications + + +
+
+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2.1 The General Options +Next: + +
+
+
+ + +

+2.1.4 Notifications +

+ +

+Mailman sends notifications to the list administrators or list members +under a number of different circumstances. Most of these +notifications can be configured in this section, but see the Bounce +Processing and Auto-responder categories for other notifications that +Mailman can send. + +

+

+
send_reminders
+
By default Mailman sends all list members a monthly password + reminder. This notice serves two purposes. First, it reminds + people about all the lists they may be subscribed to on this + domain, including the lists where their subscription may be + disabled. Second, it reminds people about their passwords for + these lists, as well as the url for their personal options pages, + so that they can more easily configure their subscription options. + +

+Some people get annoyed with these monthly reminders, and they can + disable the reminders via their subscription options page. For + some lists, the monthly reminders aren't appropriate for any of + the members, so you can disable them list-wide by setting the + send_reminders variable to No. + +

+

+
welcome_msg
+
When new members are subscribed to the list, either by their own + action, or the action of a list administrator, a welcome message + can be sent to them. The welcome message contains some common + boilerplate information, such as the name of the list, + instructions for posting to the list, and the member's + subscription password. You can add additional information to the + welcome message by typing the text into the welcome_msg + text box. Note that because this text is sent as part of an + email, it should not contain HTML. + +

+

+
send_welcome_msg
+
This flag controls whether or not the welcome message is sent to + new subscribers. + +

+

+
goodbye_msg
+
Like the welcome_msg, a ``goodbye'' message can be sent to + members when they unsubscribe from the list. Unlike the welcome + message, there's no boilerplate for the goodbye message. Enter + the entire goodbye message you'd like unsubscribing members to + receive into the goodbye_msg text box. + +

+

+
send_goodbye_msg
+
This flag controls whether or not the goodbye message is sent to + unsubscribing members. + +

+

+
admin_immed_notify
+
List moderators get notifications of pending administrative + actions, such as subscription or unsubscription requests that + require moderator approval, or posted messages that are being held + for moderator approval. List moderators will always get a daily + summary of such pending requests, but they can also get immediate + notifications when such a request is made. The + admin_immed_notify variable controls whether these + immediate notifications are sent or not. It's generally a good + idea to leave this set to Yes. + +

+

+
admin_notify_mchanges
+
This variable controls whether the list administrators should get + notifications when members join or leave the list. + +

+

+
respond_to_post_requests
+
This variable controls whether the original sender of a posting + gets a notice when their message is held for moderator approval. + +

+

+
+ +

+ +

+
+

+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2.1 The General Options +Next: + +
+
+
+Release 2.1, documentation updated on December 5, 2007. +
+ + + + diff --git a/doc/mailman-admin/node14.html b/doc/mailman-admin/node14.html new file mode 100644 index 00000000..99e91f28 --- /dev/null +++ b/doc/mailman-admin/node14.html @@ -0,0 +1,207 @@ + + + + + + + + + + + + + +2.1.5 Additional settings + + +
+
+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2.1 The General Options +Next: + +
+
+
+ + +

+2.1.5 Additional settings +

+ +

+This section contains some miscellaneous settings for your mailing +list. + +

+

+
emergency
+
When this option is enabled, all list traffic is emergency + moderated, i.e. held for moderation. Turn this option on when + your list is experiencing a flamewar and you want a cooling off + period. + +

+

+
new_member_options
+
Each member has a set of subscription options which they can use + to control how they receive messages and otherwise interact with + the list. While the members can change these settings by logging + into their personal options page, you might want to set the + default for a number of the member options. You can do that with + this variable, but see also the other categories for other member + defaults you can set. + +

+This variable presents a set of checkboxes which control the + defaults for some of the member options. Conceal the + member's address specifies whether or not the address is + displayed in the list roster. Acknowledge the member's + posting controls whether or not Mailman sends an acknowledgement + to a member when they post a message to the list. Do not + send a copy of a member's own post specifies whether a member + posting to the list will get a copy of their own posting. + Filter out duplicate messages to list members (if possible) + specifies whether members who are explicitly listed as a recipient + of a message (e.g. via the Cc: header) will also get a + copy from Mailman. + +

+Of course, members can always override these defaults by making + changes on their membership options page. + +

+

+
administrivia
+
This option specifies whether Mailman will search posted messages + for admimistrivia, in other words, email commands which + usually should be posted to the -request address for the + list. Setting this to Yes helps prevent such things as + unsubscribe messages getting erroneously posted to the list. + +

+If a message seems to contain administrivia, it is held for + moderator approval. + +

+

+
max_message_size
+
This option specifies a maximum message size, in kilobytes, over + which the message will be held for moderator approval. + +

+

+
host_name
+
This option specifies the host name part of email addresses used + by this list. For example, this is the example.com part of + the posting address mylist@example.com. + +

+It's generally not a good idea to change this value, since its + default value is specified when the mailing list is created. + Changing this to an incorrect value could make it difficult to + contact your mailing list. Also not that the url used to visit + the list's pages is not configurable through the web interface. + This is because if you messed it up, you'd have to have the site + administrator fix it. + +

+

+
include_rfc2369_headers
+
RFC 2369 is an internet standard that describes a bunch of + headers that mailing list managers should add to messages to make + it easier for people to interact with the list. Mail reading + programs which support this standard may provide buttons for easy + access to the list's archives, or for subscribing and + unsubscribing to the list. It's generally a good idea to enable + these headers as it provides for an improved user experience. + These headers are often called the List-* headers. + +

+However, not all mail readers are standards compliant yet, and if + you have a large number of members who are using non-compliant + mail readers, they may be annoyed at these headers. You should + first try to educate your members as to why these headers exist, + and how to hide them in their mail clients. As a last resort you + can disable these headers, but this is not recommended. + +

+

+
include_list_post_header
+
The List-Post: header is one of the headers + recommended by RFC 2369. However for some announce-only mailing + lists, only a very select group of people are allowed to post to + the list; the general membership is usually not allowed to post to + such lists. For lists of this nature, the List-Post: + header is misleading. Select No to disable the inclusion + of this header. (This does not affect the inclusion of the other + List-* headers.) +
+
+ +

+ +

+
+

+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2.1 The General Options +Next: + +
+
+
+Release 2.1, documentation updated on December 5, 2007. +
+ + + + diff --git a/doc/mailman-admin/node15.html b/doc/mailman-admin/node15.html new file mode 100644 index 00000000..db700d93 --- /dev/null +++ b/doc/mailman-admin/node15.html @@ -0,0 +1,120 @@ + + + + + + + + + + + + + + +2.2 The Passwords Category + + +
+
+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2 The List Configuration +Next: + +
+
+
+ + +

+2.2 The Passwords Category +

+As mentioned above, there are two primary administrative roles for +mailing lists. In this category you can specify the password for +these roles. + +

+The list owner has total control over the configuration of their +mailing list (within some bounds as specified by the site +administrator). Note that on this page, for historical reasons, the +list owner role is described here as the list administrator. +You can set the list owner's password by entering it in the password +field on the left. You must type it twice for confirmation. Note +that if you forget this password, the only way for you to get back +into your list's administrative pages is to ask the site administrator +to reset it for you (there's no password reminders for list owners). + +

+If you want to delegate list moderation to someone else, you can enter +a different moderator password in the field on the right (typed twice +for confirmation). Note that if you aren't going to delegate +moderation, and the same people are going to both configure the list +and moderate postings to the list, don't enter anything into the +moderator password fields. If you do enter a separate moderator +password, be sure to fill in the moderator variable in the +General options category page. + +

+ +

+
+

+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2 The List Configuration +Next: + +
+
+
+Release 2.1, documentation updated on December 5, 2007. +
+ + + + diff --git a/doc/mailman-admin/node16.html b/doc/mailman-admin/node16.html new file mode 100644 index 00000000..fe00410f --- /dev/null +++ b/doc/mailman-admin/node16.html @@ -0,0 +1,156 @@ + + + + + + + + + + + + + + +2.3 The Language Options Category + + +
+
+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2 The List Configuration +Next: + +
+
+
+ + +

+2.3 The Language Options Category +

+Mailman is multilingual and internationalized, meaning you can set up +your list so that members can interact with it in any of a number of +natural languages. Of course, Mailman won't translate list +postings. :) + +

+However, if your site administrator has enabled its support, you can +set your list up to support any of about two dozen languages, such as +German, Italian, Japanese, or Spanish. Your list members can then +choose any of your supported languages as their preferred +language for interacting with the list. Such things as their member +options page will be displayed in this language. Each mailing list +also has its own preferred language which is the language the +list supports if no other language context is known. + +

+These variables control the language settings for your mailing list: + +

+

+
preferred_language
+
This is the list's preferred language, which is the language that + the list administrative pages will be displayed in. Also any + messages sent to the list owners by Mailman will be sent in this + language. This option is presented as a drop-down list containing + the language enabled in the available_languages variable. + +

+

+
available_languages
+
This set of checkboxes contains all the natural languages that + your site administrator has made available to your mailing lists. + Select any language that you'd either like your members to be able + to view the list in, or that you'd like to be able to use in your + list's preferred_language variable. + +

+

+
encode_ascii_prefixes
+
If your mailing list's preferred language uses a non-ASCII + character set and the subject_prefix contains non-ASCII + characters, the prefix will always be encoded according to the + relevant standards. However, if your subject prefix contains only + ASCII characters, you may want to set this option to Never + to disable prefix encoding. This can make the subject headers + slightly more readable for users with mail readers that don't + properly handle non-ASCII encodings. + +

+Note however, that if your mailing list receives both encoded and + unencoded subject headers, you might want to choose As + needed. Using this setting, Mailman will not encode ASCII + prefixes when the rest of the header contains only ASCII + characters, but if the original header contains non-ASCII + characters, it will encode the prefix. This avoids an ambiguity + in the standards which could cause some mail readers to display + extra, or missing spaces between the prefix and the original + header. +

+
+ +

+ +

+
+

+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2 The List Configuration +Next: + +
+
+
+Release 2.1, documentation updated on December 5, 2007. +
+ + + + diff --git a/doc/mailman-admin/node17.html b/doc/mailman-admin/node17.html new file mode 100644 index 00000000..df0e7232 --- /dev/null +++ b/doc/mailman-admin/node17.html @@ -0,0 +1,108 @@ + + + + + + + + + + + + + + +2.4 The Membership Management Category + + +
+
+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2 The List Configuration +Next: + +
+
+
+ + +

+2.4 The Membership Management Category +

+ +

+The Membership Management category is unlike the other +administrative categories. It doesn't contain configuration variables +or list settings. Instead, it presents a number of pages that allow +you to manage the membership of you list. This includes pages for +subscribing and unsubscribing members, and for searching for members, +and for changing various member-specific settings. + +

+More details on membership management are described in the Membership +Management section. + +

+ +

+
+

+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2 The List Configuration +Next: + +
+
+
+Release 2.1, documentation updated on December 5, 2007. +
+ + + + diff --git a/doc/mailman-admin/node18.html b/doc/mailman-admin/node18.html new file mode 100644 index 00000000..69795786 --- /dev/null +++ b/doc/mailman-admin/node18.html @@ -0,0 +1,318 @@ + + + + + + + + + + + + + + +2.5 The Non-digest Options Category + + +
+
+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2 The List Configuration +Next: + +
+
+
+ + +

+2.5 The Non-digest Options Category +

+ +

+Mailman delivers messages to users via two modes. List members can +elect to receive postings in bundles call digests one or a few +times a day, or they can receive messages immediately whenever the +message is posted to the list. This latter delivery mode is also +called non-digest delivery. There are two administrative +categories available for separately controlling digest and non-digest +delivery. You can even disable one or the other forms of delivery +(but not both). + +

+Both kinds of delivery can have list-specific headers and footers +added to them which can contain other useful information you want your +list members to see. For example, you can include instructions for +unsubscribing, or a url to the lists digest, or any other information. + +

+Non-digest deliveries can also be personalized which means +certain parts of the message can contain information tailored to the +member receiving the message. For example, the To: header +will contain the address of the member when deliveries are +personalized. Footers and headers can contain personalized +information as well, such as a link to the individual user's options +page. + +

+In addition, personalized messages will contain extra information that +Mailman can use to unambiguously track bounces from members. +Ordinarily, Mailman does some pattern recognition on bounce messages +to determine list members whose addresses are no longer valid, but +because of the vagaries of mail systems, and the countless forwards +people can put in place, it's often the case that bounce messages +don't contain any useful information in them. Personalized messages +avoid this problem by encoding information in certain headers that +unambiguously identify the recipient of a message. If that message +bounces, Mailman will know exactly which member it was intended for. + +

+Note that because personalization requires extra system resources, it +must be enabled by the site administrator before you can choose it. + +

+Here are the variables which control non-digest delivery: + +

+

+
nondigestable
+
This option controls whether members can receive immediate + delivery or not. If not, they will be forced to receive messages + in digests. You can't disable non-digest delivery if digests are + already disabled. + +

+

+
personalize
+
This option turns on message personalization. + +

+

+
msg_header
+
This text box lets you enter information that will be included in + the header of every non-digest message sent through the + list. + +

+See below for more information on what can go in the headers and + footers. If you leave this text box empty, no header will be + added. + +

+

+
msg_footer
+
Just like with the header, you can add a footer to every message. + The same rules apply to footers as apply to headers. +
+
+ +

+Headers and footers can contain any text you want. For non-English +lists, the headers and footers can contain any character in the +character set of the list's preferred language. The headers and +footers can also contain substitution variables which Mailman +will fill in with information taken from the mailing list. These +substitutions are in Python string interpolation format, where +something like %(list_name)s is substituted with he name of +the mailing list. Note that the trailing "s" is +required2. + +

+For example, a footer containing the following text: + +

+

+This is the \%(list_name)s mailing list
+Description: \%(description)s
+
+ +

+might get attached to postings like so: + +

+

+This is the Example mailing list
+Description: An example of Mailman mailing lists
+
+ +

+Here is the list of substitution variables available for your headers +and footers: + +

+

+
real_name
+
This is the value of the real_name configuration variable + in the General options category. + +

+

+
list_name
+
This is the canonical name of the mailing list. In other words + it's the posting address of the list3. + +

+

+
host_name
+
This is the domain name part of the email address for this list. + +

+

+
web_page_url
+
This is the base url for contacting the list via the web. It can + be appended with listinfo/%(list_name)s to yield the + general list information page for the mailing list. + +

+

+
description
+
The brief description of the mailing list. + +

+

+
info
+
This is the full description of the mailing list. + +

+

+
cgiext
+
This is the extension added to CGI scripts. It might be the empty + string, .cgi, or something else depending on how your site + is configured. +
+
+ +

+Note that real_name, host_name, description, and +info substitution variables take their values from the list +configuration variables of the same name. + +

+When personalization is enabled, the following substitution variables +are also available: + +

+

+
user_address
+
The address of the recipient of the message, coerced to lower case. + +

+

+
user_delivered_to
+
The case-preserved address that the user subscribed to the mailing + list with4. + +

+

+
user_password
+
The user's password, in clear text. + +

+

+
user_name
+
The user's full name. + +

+

+
user_optionsurl
+
The url to the user's personal options page. +
+
+ +

+

Footnotes

+
+
... +required2
+
The site administrator can configure lists to use a +simpler interpolation format, where $list_name or +${list_name} would be substituted with the mailing list's +name. Ask your site administrator if the've configured your list this +way. + +
+
... list3
+
For backward + compatibility, the variable _internal_name is + equivalent. + +
+
... with4
+
Usually it makes no difference which of + user_address and user_delivered_to is used, but it's + important to remember that they can be different. When they're + different, Mailman always uses the lower case address as the key + to the member's subscription information, but it always delivers + messages to the case-preserved version. + +
+
+
+
+

+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2 The List Configuration +Next: + +
+
+
+Release 2.1, documentation updated on December 5, 2007. +
+ + + + diff --git a/doc/mailman-admin/node19.html b/doc/mailman-admin/node19.html new file mode 100644 index 00000000..75a5f53e --- /dev/null +++ b/doc/mailman-admin/node19.html @@ -0,0 +1,226 @@ + + + + + + + + + + + + + + +2.6 The Digest Options Category + + +
+
+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2 The List Configuration +Next: + +
+
+
+ + +

+2.6 The Digest Options Category +

+ +

+Digest delivery is a way to bundle many articles together into one +package, which can be delivered once per day (if there were any posted +articles), or whenever the package is bigger than a specified limit. +Some users may prefer this style of delivery for higher traffic lists +since they will receive fewer messages. + +

+Mailman supports two standard digest formats, and if digests are +enabled, users can select which of the two formats they receive. One +is MIME digests, where each message is an attachment inside a +multipart/digest. This format also contains a summary +table of contents, and of course the an optional header and footer, +and it retains most of the headers of the original messages. + +

+The second type is called ``plaintext'' digests because they are +readable in mail readers that don't support MIME. Actually, they +adhere to the RFC 1153 digest standard. The retain some, but not +all of the original messages, but can also include a summary and +headers and footers. + +

+Like non-digest delivery, you can enable or disable digest delivery, +but you cannot disable both types of delivery. You can specify +different headers and footers for digest and non-digest deliveries. +You cannot personalize digest deliveries. + +

+As list administrator, you may want to send an urgent message to all +list members, bypassing the normal digest bundling. To do this, send +the message with a Urgent: header, where the value of the +header is the list administrator's password. Non-digest members will +receive the message like normal, but digest members will receive the +message immediately5. + +

+Here are the variables which control digest delivery: + +

+

+
digestable
+
The option controls whether members can receive digest deliveries + or not. If not, they will be forced to receive immediate + deliveries. You can't disable digests if non-digests are already + disabled. + +

+

+
digest_is_default
+
Controls which style of delivery is the default for new members. + You can choose Regular (non-digest) or Digest + delivery. + +

+

+
mime_is_default_digest
+
If a member is allowed to choose digests, this variable controls + which is the default digest style they will receive. Plain + digests are RFC 1153 format as described above. + +

+

+
digest_size_threshold
+
Normally, digest members get at least one message per day, if + there have been any messages posted to the list. However, for + high volume lists, you may want to send out digests when the size + has reached a certain threshold, otherwise, the one digest they + receive could be huge. This variable controls the size threshold + by specifying the maximum digest size in kilobytes. Note that + this threshold isn't exact. Set this variable to zero to specify + that there is no size threshold, in which case no more than one + digest will be sent out per day. + +

+

+
digest_send_periodic
+
This variable actually controls whether or not a digest is sent + daily when the size threshold has not yet been met. If set to + No, then digests will only be sent when they are bigger + than digest_size_threshold. + +

+

+
digest_header
+
This text box lets you enter information that will be included in + the header of every digest message sent through the list. The + same information can go in this header as can go in the + msg_header, except for the personalization variables. + +

+

+
digest_footer
+
Just like with the header, you can add a footer to every message. + The same rules apply to digest footers as apply to digest headers. + +

+

+
digest_volume_frequency
+
Each digest is numbered with a volume and an issue. This variable + controls how often a new digest volume is sent. When the digest + volume number is incremented, the issue number is reset to 1. + +

+

+
_new_volume
+
This is an action variable, which forces an increment of the + volume number as soon as you submit the form. + +

+

+
_send_digest_now
+
This is another action variable. Select Yes, submit the + form, and the current digest is packaged up and sent to digest + members, regardless of size (well, there has to be at least one + message in the digest). +
+
+ +

+

Footnotes

+
+
... immediately5
+
They'll also receive the message in the +digest. + +
+
+
+
+

+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2 The List Configuration +Next: + +
+
+
+Release 2.1, documentation updated on December 5, 2007. +
+ + + + diff --git a/doc/mailman-admin/node20.html b/doc/mailman-admin/node20.html new file mode 100644 index 00000000..5205808d --- /dev/null +++ b/doc/mailman-admin/node20.html @@ -0,0 +1,179 @@ + + + + + + + + + + + + + + +2.7 The Privacy Options Category + + +
+
+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2 The List Configuration +Next: + +
+
+
+ + +

+2.7 The Privacy Options Category +

+ +

+The Privacy category lets you control how much of the list's +information is public, as well as who can send messages to your list. +It also contains some spam detection filters. Note that this section +is not used to control whether your list's archives are public or +private; for that, use the category. + +

+There are four sub-categories: + +

+ +

+The sender, recipient, and spam filtering rules are part of the +general list moderation features of Mailman. When a message is posted +to the list, it is matched against a number of criteria, the outcome +of which determines whether the message is reflected to the membership +or not. In general, the outcome is one of four states: + +

+ +

+ +

+Many of the fields in this section are text boxes accepting addresses, +one per line. Unless otherwise noted, these also accept regular +expressions which will be matched against an address, if the line +begins with a (caret) character. + +

+ +


+
+ +Subsections + + + +
+ +
+
+

+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2 The List Configuration +Next: + +
+
+
+Release 2.1, documentation updated on December 5, 2007. +
+ + + + diff --git a/doc/mailman-admin/node21.html b/doc/mailman-admin/node21.html new file mode 100644 index 00000000..0db2153a --- /dev/null +++ b/doc/mailman-admin/node21.html @@ -0,0 +1,204 @@ + + + + + + + + + + + + + + +2.7.1 Subscription rules + + +
+
+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2.7 The Privacy Options +Next: + +
+
+
+ + +

+2.7.1 Subscription rules +

+ +

+This subcategory controls the rules for exposing the existance of this +list, and for what new members must do in order to subscribe to the +list. + +

+

+
advertised
+
This option controls whether this list will show up in the list + overview for the site. Normally, an overview contains the name + and short description of every mailing list in the virtual + domain. By setting this variable to No, it will not show + up in this overview, nor will it show up in the administrative + overview. The only way then to find the list is to guess (or + know!) its name. + +

+

+
subscribe_policy
+
This option controls the steps that a new member must take to join + the list. The available options may differ based on some defaults + that the site administrator chooses. They are: + +

+ +

    +
  • None - No verification is done on the subscribing + member. This is also called open subscriptions and is + generally disabled by default. The site administrator must + allow list admins to choose this option; if not, this option + will not be presented to you. + +

    +

    • +
  • Confirm - An email confirmation step is required before the + address is added to the list. When a member requests + subscription, either via the web page or by sending a + message to yourlist-join@example.com, Mailman + will send a confirmation message to the requesting address. + This mail-back confirmation contains a unique identifier, + which the requester can present to Mailman in order to + confirm their subscription. This can be done either by + replying to the mail-back, or by visiting the url in the + mail-back message. The url points to a page that lets the + user either discard or confirm their request. + +

    +

    • +
  • Require approval - All subscription requests are held for + approval of the list moderator. No mail-back confirmation + is sent, but the list admins will recieve a message + indicating that approval is pending. + +

    +

    • +
  • Confirm and approve - Here, a mail-back notice must first + be confirmed by the requester. Once confirmed, the list + moderator must then approve the request. This is the most + secure method for users to subscribe since it both verifies + the requesting address, and forces the list moderators to + approve the request. + +

    +

    • +
+ +

+

+
unsubscribe_policy
+
Specifies whether the list moderator's approval is required for + unsubscription requests. No is highly recommended, since + it is exceedingly impolite to not allow people to leave a mailing + list whenever they want (i.e. opt-out). Yes is useful in + some specialized contexts; e.g. you may not want to allow + employees to unsubscribe from the company newsletter. + +

+

+
ban_list
+
This contains a list of addresses (or regular expressiosn), one + per line, that are banned from ever subscribing to your mailing + list. If a match occurs during the subscription process, the + request will be automatically rejected, and the requester will get + a rejection notice. You can use this to permanently ban + troublesome posters to a members-only list. + +

+

+
private_roster
+
This specifies who is allowed to view the roster of member + addresses. If you choose Anyone, then the list membership + is completely public. You can limit exposure of the roster to + just list members, or just to the list administrators. In the + former case, a user must enter a valid member's address and + password before they can view the roster. In the latter case, a + list administrator's password must be enter; if a matching admin + password is entered, address field is ignored. + +

+

+
obscure_addresses
+
Controls whether some simple obfuscation of addresses is used when + member addresses are included on web pages. This should reduce + the opportunity for email address harvesting by spammers, although + it probably doesn't eliminate it. +
+
+ +

+ +

+
+

+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2.7 The Privacy Options +Next: + +
+
+
+Release 2.1, documentation updated on December 5, 2007. +
+ + + + diff --git a/doc/mailman-admin/node22.html b/doc/mailman-admin/node22.html new file mode 100644 index 00000000..62bbe43f --- /dev/null +++ b/doc/mailman-admin/node22.html @@ -0,0 +1,215 @@ + + + + + + + + + + + + + + +2.7.2 Sender filters + + +
+
+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2.7 The Privacy Options +Next: + +
+
+
+ + +

+2.7.2 Sender filters +

+ +

+When a message is posted to the list, a series of moderation criteria are +applied to determine the disposition of the message. This section +contains the modeation controls for postings from both members and +non-members. + +

+

+
default_member_moderation
+
Member postings are held for moderation if their moderation + flag is turned on. Note that only the list administrators can + change the value of a member's moderation flag. + +

+You can control whether new members get their moderation flag + turned on or off by default when they subscribe to the list. By + turning this flag off by default, postings by members will be + allowed without further intervention (barring other restrictions + such as size or implicit recipient lists - see below). By + turning the flag on, you can quarantine new member postings to + make sure that they meet your criteria for netiquette, topicality, + etc. Once you determine that the new member understands the + community's posting rules, you can turn off their moderation flag + and let their postings go through unstopped. + +

+E-newsletter style lists can also be set up by using the + moderation flag. By setting the member_moderation_action + to Reject, and by turning off the moderation flag for just + the few approved senders, your list will operate in essentially a + one-way direction. Note that you'd also need to reject or discard + postings from non-members. + +

+

+
member_moderation_action
+
This is the action to take for postings from a member who's + moderation flag is set. For typical discussion lists, you'll + likely set this to Hold so that the list moderator will get + a chance to manually approve, reject, or discard the message. For + e-newsletter and announcement lists, you might want to set this to + Reject or Discard. + +

+Note that when a moderated member posts to your list, and the + member_moderation_action is set to Hold, the message + will appear on the administrative requests page. When you dispose + of the message, you will be given an opportunity to clear the + moderation flag at the same time. If you're quarantining new + posts, this makes it very convenient to both approve a new + member's post and de-moderate them at the same time. + +

+

+
member_moderation_notice
+
When a member's moderation flag is turned on and + member_moderation_action is Reject, this variable + contains the text sent in the rejection notice. +
+
+ +

+The next batch of variables controls what happens when non-members +post messages to the list. Each of these accepts one email address +per line; regular expressions are allowed if the line starts with the +(caret) character. These address lists are always consulted in the +order in which they're presented on this page (i.e. accepts first, +followed by holds, rejections, and discards). + +

+

+
accept_these_nonmembers
+
Postings from non-members whose addresses match this list are + accepted, barring other list restrictions due to size, implicit + recipients, etc. You might want to add alternative addresses of + approved posters to this list. + +

+

+
hold_these_nonmembers
+
Postings from non-members whose addresses match this list are + held for moderator approval. + +

+

+
reject_these_nonmembers
+
Postings from non-members whose addresses match this list are + rejected, i.e. bounced back to the original sender. There + currently is no way to add additional text to the rejection + message. + +

+

+
discard_these_nonmembers
+
Postings from non-members whose addresses match this list are + discarded, with no bounce back message. You might want to add the + addresses of known spammers to this list. + +

+

+
generic_nonmember_action
+
This variable controls what happens to non-member posts when the + address of the sender doesn't match any of the above four lists. + If you set this to Hold, the posting will appear on the + administrative requests page, and you will be given an opportunity + to add the non-member to one of the above four lists at the same + time you dispose of the held message. + +

+

+
forward_auto_discards
+
When messages from non-members are discarded, either because the + sender address matched discard_these_nonmembers, or because + generic_nonmember_action is Discard, you can choose + whether such messages are forwarded to the lsit administrators or + not. +
+
+ +

+ +

+
+

+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2.7 The Privacy Options +Next: + +
+
+
+Release 2.1, documentation updated on December 5, 2007. +
+ + + + diff --git a/doc/mailman-admin/node23.html b/doc/mailman-admin/node23.html new file mode 100644 index 00000000..eb6ab6c1 --- /dev/null +++ b/doc/mailman-admin/node23.html @@ -0,0 +1,133 @@ + + + + + + + + + + + + + + +2.7.3 Recipient Filters + + +
+
+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2.7 The Privacy Options +Next: + +
+
+
+ + +

+2.7.3 Recipient Filters +

+ +

+The variables in this section control various filters based on the +recipient of the message. + +

+

+
require_explicit_destination
+
This controls whether the mailing list posting address must be + explicitly named in the To: or Cc: + recipient lists. The main reason why it wouldn't is if the + message was blind-carbon-copied (i.e. Bcc:'d) to the + list. Spammers like to do this, but sometimes legitimate messages + are forwarded to the list this way. + +

+If the list is not explicitly addressed and this setting is turned + on, the message will be held for moderator approval. + +

+

+
acceptable_aliases
+
This is the list of alternative addresses that are acceptable as a + list posting address when require_explicit_destination is + enabled. This is useful for when there aliases for the main + posting address (e.g. help@example.com may be an alias for + help-list@example.com). + +

+

+
max_num_recipients
+
This is the maximum number of explicit recipients that are allowed + on the posted message. Spammers sometimes send messages with lots + of explicit recipients, so setting this number to a reasonable + value may cut down on spam. +
+
+ +

+ +

+
+

+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2.7 The Privacy Options +Next: + +
+
+
+Release 2.1, documentation updated on December 5, 2007. +
+ + + + diff --git a/doc/mailman-admin/node24.html b/doc/mailman-admin/node24.html new file mode 100644 index 00000000..49951ddf --- /dev/null +++ b/doc/mailman-admin/node24.html @@ -0,0 +1,131 @@ + + + + + + + + + + + + + +2.7.4 Spam Filters + + +
+
+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2.7 The Privacy Options +Next: + +
+
+
+ + +

+2.7.4 Spam Filters +

+ +

+This section provides some adjuncts to spam fighting tools; it +doesn't replace dedicated anti-spam tools such as SpamAssassin or +Spambayes. + +

+

+
bounce_matching_headers
+
This variable contains header regular expressions, one per line, + and if any of a message's headers matches one of these patterns, + it will be held for moderation. The format is a colon separated + header and value, where the header is case insensitive and the + value is any valid Python regular expression. Lines that start + with # are ignored. + +

+This variable can be used to catch known spammers by writing + regexps that match against To: or Cc: + lines, or known-bad Message-ID:s. Perhaps more useful + though are patterns that match headers added by spam detection + tools higher up in the tool chain. For example, you might + configure SpamAssassin to add an X-Spam-Score: header + with between zero and 5 stars depending on the spam score. Then + you can add a line to this variable like: + +

+

+    X-Spam-Score: [*]{3,5}
+
+ +

+This line will match from 3 to 5 stars in the value of this + field. +

+
+ +

+ +

+
+

+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2.7 The Privacy Options +Next: + +
+
+
+Release 2.1, documentation updated on December 5, 2007. +
+ + + + diff --git a/doc/mailman-admin/node25.html b/doc/mailman-admin/node25.html new file mode 100644 index 00000000..48a42e3a --- /dev/null +++ b/doc/mailman-admin/node25.html @@ -0,0 +1,196 @@ + + + + + + + + + + + + + + +2.8 The Bounce Processing Category + + +
+
+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2 The List Configuration +Next: + +
+
+
+ + +

+2.8 The Bounce Processing Category +

+ +

+These policies control the automatic bounce processing system in +Mailman. Here's an overview of how it works: + +

+When a bounce is received, Mailman tries to extract two pieces of +information from the message: the address of the member the message +was intended for, and the severity of the problem causing the bounce. +The severity can be either hard for fatal errors, or +soft for transient errors. When in doubt, a hard severity is +used. + +

+If no member address can be extracted from the bounce, then the bounce +message is usually discarded. Every member has a bounce score, +initialized at zero, and every time we encounter a bounce from a +member we increment that member's score. Hard bounces increment by 1 +while soft bounces increment by 0.5. We only increment the bounce +score once per day, so even if we receive ten hard bounces from a +member per day, their score will increase by only 1 for that day. + +

+When a member's bounce score is greater than the bounce score +threshold (see below), the member's subscription is disabled. Once +disabled, the member will not receive any postings from the list until +their membership is explicitly re-enabled, either by the list +administrator or the user. However, they will receive occasional +reminders that their membership has been disabled, and these reminders +will include information about how to re-enable their membership. You +can control both the number of reminders the member will receive and +the frequency with which these reminders are sent. + +

+There is one other important configuration variable; after a certain +period of time - during which no bounces from the member are received +- the bounce information is considered stale and discarded. Thus by +adjusting this value, and the score threshold, you can control how +quickly bouncing members are disabled. You should tune both of these +to the frequency and traffic volume of your list. + +

+

+
bounce_processing
+
Specifies whether or not this list should do automatic bounce + processing. + +

+

+
bounce_score_threshold
+
This is the bounce score above which a member's subscription will + be automatically disabled. When the subscription is re-enabled, + their bounce score will be reset to zero. This value can be a + floating point number. + +

+

+
bounce_info_stale_after
+
Thenumber of days after which a member's bounce information is + considered stale. If no new bounces have been received in the + interrim, the bounce score is reset to zero. This value must be + an integer. + +

+

+
bounce_you_are_disabled_warnings
+
The number of notices a disabled member will receive before their + address is removed from the mailing list's roster. Set this to 0 + to immediately remove an address from the list once their bounce + score exceeds the threshold. This value must be an integer. + +

+

+
bounce_you_are_disabled_warnings_interval
+
The number of days between each disabled notification. + +

+

+
bounce_unrecognized_goes_to_list_owner
+
This variable controls whether unrecognized bounces are discarded, + or forwarded on the list administrator. The bounce detector isn't + perfect, although personalization can make it much more accurate. + The list owner may want to receive unrecognized bounces so that + they can manually disable or remove such members. + +

+

+
bounce_notify_owner_on_disable
+
This option controls whether or not the list owner is notified + when a member's subscription is automatically disabled due to + their bounce threshold being reached. + +

+

+
bounce_notify_owner_on_removal
+
This option controls whether or not the list owner is notified + when a member is removed from the list after their disabled + notifications have been exhausted. +
+
+ +

+ +

+
+

+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2 The List Configuration +Next: + +
+
+
+Release 2.1, documentation updated on December 5, 2007. +
+ + + + diff --git a/doc/mailman-admin/node26.html b/doc/mailman-admin/node26.html new file mode 100644 index 00000000..1cb22484 --- /dev/null +++ b/doc/mailman-admin/node26.html @@ -0,0 +1,137 @@ + + + + + + + + + + + + + + +2.9 The Archiving Options Category + + +
+
+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2 The List Configuration +Next: + +
+
+
+ + +

+2.9 The Archiving Options Category +

+ +

+Mailman comes with a built-in web-based archiver called +Pipermail, although it can be configured to use external, +third party archivers. + +

+

+
archive
+
This option tells Mailman whether to archive messages it receives + or not, regardless of whether Pipermail or a third party archiver + is used. Turn this off if you don't want to archive messages. + +

+Note that senders can control whether their own posts are + archived, on an individual per-message basis. If the posted + message has a X-No-Archive: header (regardless of + value), or a X-Archive: header with a value of + No (case insensitive), then the message will not be + archived, although it will be treated as normal in all other + ways. + +

+

+
archive_private
+
Controls whether Pipermail archives are private or public. + Private archives require a valid member address and password, or a + list administrator password in order to access them. This + option has no effect when a third party archiver is used. + +

+

+
archive_volume_frequency
+
Controls how Pipermail splits messages in the archive. The most + common option is Monthly meaning a new archive volume is + started every month. Very high volume lists may want a shorter + frequency (e.g. Weekly or Daily) where as lower + volume lists may want a longer frequency (e.g. Yearly). + This option has no effect when a third party archiver is used. +
+
+ +

+ +

+
+

+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2 The List Configuration +Next: + +
+
+
+Release 2.1, documentation updated on December 5, 2007. +
+ + + + diff --git a/doc/mailman-admin/node27.html b/doc/mailman-admin/node27.html new file mode 100644 index 00000000..6388de8e --- /dev/null +++ b/doc/mailman-admin/node27.html @@ -0,0 +1,101 @@ + + + + + + + + + + + + + + +2.10 The Mail/News Gateway Category + + +
+
+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2 The List Configuration +Next: + +
+
+
+ + +

+2.10 The Mail/News Gateway Category +

+ +

+Mailman has a sophisticated mail-to-news gateway feature. It can +independently gate messages from news to mail and vice versa, and can +even be used to manage moderated newsgroups. + +

+ +

+
+

+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2 The List Configuration +Next: + +
+
+
+Release 2.1, documentation updated on December 5, 2007. +
+ + + + diff --git a/doc/mailman-admin/node28.html b/doc/mailman-admin/node28.html new file mode 100644 index 00000000..1b6bce1e --- /dev/null +++ b/doc/mailman-admin/node28.html @@ -0,0 +1,94 @@ + + + + + + + + + + + + + + +2.11 The Auto-responder Category + + +
+
+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2 The List Configuration +Next: + +
+
+
+ + +

+2.11 The Auto-responder Category +

+ +
+
+

+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2 The List Configuration +Next: + +
+
+
+Release 2.1, documentation updated on December 5, 2007. +
+ + + + diff --git a/doc/mailman-admin/node29.html b/doc/mailman-admin/node29.html new file mode 100644 index 00000000..7fecbdf0 --- /dev/null +++ b/doc/mailman-admin/node29.html @@ -0,0 +1,94 @@ + + + + + + + + + + + + + + +2.12 The Content Filtering Category + + +
+
+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2 The List Configuration +Next: + +
+
+
+ + +

+2.12 The Content Filtering Category +

+ +
+
+

+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2 The List Configuration +Next: + +
+
+
+Release 2.1, documentation updated on December 5, 2007. +
+ + + + diff --git a/doc/mailman-admin/node3.html b/doc/mailman-admin/node3.html new file mode 100644 index 00000000..e813a33f --- /dev/null +++ b/doc/mailman-admin/node3.html @@ -0,0 +1,129 @@ + + + + + + + + + + + + + + +1 Introduction to GNU Mailman + + +
+
+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +Contents +Next: + +
+
+
+ + +

+1 Introduction to GNU Mailman +

+ +

+GNU Mailman is software that lets you manage electronic mailing lists. +It supports a wide range of mailing list types, such as general +discussion lists and announce-only lists. Mailman has extensive +features for controlling the privacy of your lists, distributing your +list as personalized postings or digests, gatewaying postings to and +from Usenet, and providing automatic bounce detection. Mailman +provides a built-in archiver, multiple natural languages, as well as +advanced content and topic filtering. + +

+Mailman provides several interfaces to its functionality. Most list +administrators will primarily use the web interface to customize their +lists. There is also a limited email command interface to the +administrative functions, as well as a command line interface if you +have shell access on the Mailman server. This document does not cover +the command line interface; see the GNU Mailman site administrator's +manual for more details. + +

+ +


+
+ +Subsections + + + +
+ +
+
+

+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +Contents +Next: + +
+
+
+Release 2.1, documentation updated on December 5, 2007. +
+ + + + diff --git a/doc/mailman-admin/node30.html b/doc/mailman-admin/node30.html new file mode 100644 index 00000000..07c65bb5 --- /dev/null +++ b/doc/mailman-admin/node30.html @@ -0,0 +1,95 @@ + + + + + + + + + + + + + +2.13 The Topics Category + + +
+
+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2 The List Configuration +Next: + +
+
+
+ + +

+2.13 The Topics Category +

+ +

+ +

+
+

+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2 The List Configuration +Next: + +
+
+
+Release 2.1, documentation updated on December 5, 2007. +
+ + + + diff --git a/doc/mailman-admin/node31.html b/doc/mailman-admin/node31.html new file mode 100644 index 00000000..52d177a2 --- /dev/null +++ b/doc/mailman-admin/node31.html @@ -0,0 +1,94 @@ + + + + + + + + + + + + + + +3 Membership Management + + +
+
+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +Contents +Next: + +
+
+
+ + +

+3 Membership Management +

+ +
+
+

+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +Contents +Next: + +
+
+
+Release 2.1, documentation updated on December 5, 2007. +
+ + + + diff --git a/doc/mailman-admin/node32.html b/doc/mailman-admin/node32.html new file mode 100644 index 00000000..27f20051 --- /dev/null +++ b/doc/mailman-admin/node32.html @@ -0,0 +1,94 @@ + + + + + + + + + + + + + + +4 Tending to Pending Moderator Requests + + +
+
+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +Contents +Next: + +
+
+
+ + +

+4 Tending to Pending Moderator Requests +

+ +
+
+

+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +Contents +Next: + +
+
+
+Release 2.1, documentation updated on December 5, 2007. +
+ + + + diff --git a/doc/mailman-admin/node33.html b/doc/mailman-admin/node33.html new file mode 100644 index 00000000..335cb405 --- /dev/null +++ b/doc/mailman-admin/node33.html @@ -0,0 +1,94 @@ + + + + + + + + + + + + + + +5 Editing the Public HTML Pages + + +
+
+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +Contents +Next: + +
+
+
+ + +

+5 Editing the Public HTML Pages +

+ +
+
+

+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +Contents +Next: + +
+
+
+Release 2.1, documentation updated on December 5, 2007. +
+ + + + diff --git a/doc/mailman-admin/node34.html b/doc/mailman-admin/node34.html new file mode 100644 index 00000000..fe7aec18 --- /dev/null +++ b/doc/mailman-admin/node34.html @@ -0,0 +1,98 @@ + + + + + + + + + + + + + + +6 Deleting the Mailing List + + +
+
+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +Contents +Next: + +
+
+
+ + +

+6 Deleting the Mailing List +

+ +

+ +

+ +

+
+

+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +Contents +Next: + +
+
+
+Release 2.1, documentation updated on December 5, 2007. +
+ + + + diff --git a/doc/mailman-admin/node35.html b/doc/mailman-admin/node35.html new file mode 100644 index 00000000..0d64431c --- /dev/null +++ b/doc/mailman-admin/node35.html @@ -0,0 +1,113 @@ + + + + + + + + + + + + + +1 This is an Appendix + + +
+
+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +Contents +Next: + +
+
+
+ + +

+1 This is an Appendix +

+ +

+To create an appendix in a Python HOWTO document, use markup like +this: + +

+

+\appendix
+
+\section{This is an Appendix}
+
+To create an appendix in a Python HOWTO document, ....
+
+
+\section{This is another}
+
+Just add another \section{}, but don't say \appendix again.
+
+ +

+ +

+
+

+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +Contents +Next: + +
+
+
+Release 2.1, documentation updated on December 5, 2007. +
+ + + + diff --git a/doc/mailman-admin/node4.html b/doc/mailman-admin/node4.html new file mode 100644 index 00000000..538cd6b8 --- /dev/null +++ b/doc/mailman-admin/node4.html @@ -0,0 +1,160 @@ + + + + + + + + + + + + + + +1.1 A List's Email Addresses + + +
+
+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +1 Introduction to GNU +Next: + +
+
+
+ + +

+1.1 A List's Email Addresses +

+ +

+Every mailing list has a set of email addresses that messages can be +sent to. There's always one address for posting messages to the list, +one address that bounces will be sent to, and addresses for processing +email commands. For example, for a mailing list called +mylist@example.com, you'd find these addresses: + +

+ +

+ +

+There's also an -admin address which also reaches the list +administrators, but this address only exists for compatibility with +older versions of Mailman. + +

+ +

+
+

+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +1 Introduction to GNU +Next: + +
+
+
+Release 2.1, documentation updated on December 5, 2007. +
+ + + + diff --git a/doc/mailman-admin/node5.html b/doc/mailman-admin/node5.html new file mode 100644 index 00000000..489d4a23 --- /dev/null +++ b/doc/mailman-admin/node5.html @@ -0,0 +1,126 @@ + + + + + + + + + + + + + + +1.2 Administrative Roles + + +
+
+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +1 Introduction to GNU +Next: + +
+
+
+ + +

+1.2 Administrative Roles +

+ +

+There are two primary administrative roles for each mailing list, a +list owner and a list moderator. A list owner is allowed to change +various settings of the list, such as the privacy and archiving +policies, the content filtering settings, etc. The list owner is also +allowed to subscribe or invite members, unsubscribe members, and +change any member's subscription options. + +

+The list moderator on the other hand, is only allowed to approve or +reject postings and subscription requests. The list moderator can +also do things like clear a member's moderation flag, or add an +address to a list of approved non-member posters. + +

+Normally, the list owner and list moderator are the same person. In +fact, the list owner can always do all the tasks a list moderator can +do. Access to both the owner's configuration pages, and the +moderation pages are protected by the same password. However, if the +list owner wants to delegate posting and subscription approval +authority to other people, a separate list moderator password can be +set, giving moderators access to the approval pages, but not the +configuration pages. In this setup, list owners can still moderate +the list, of course. + +

+In the sections that follow, we'll often use the terms list owner and +list administrator interchangably, meaning both roles. When +necessary, we'll distinguish the list moderator explicitly. + +

+ +

+
+

+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +1 Introduction to GNU +Next: + +
+
+
+Release 2.1, documentation updated on December 5, 2007. +
+ + + + diff --git a/doc/mailman-admin/node6.html b/doc/mailman-admin/node6.html new file mode 100644 index 00000000..eca800af --- /dev/null +++ b/doc/mailman-admin/node6.html @@ -0,0 +1,135 @@ + + + + + + + + + + + + + + +1.3 A List's Web Pages + + +
+
+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +1 Introduction to GNU +Next: + +
+
+
+ + +

+1.3 A List's Web Pages +

+ +

+Every mailing list is also accessible by a number of web pages. Note +that the exact urls is configurable by the site administrator, so they +may be different than what's described below. We'll describe the most +common default configuration, but check with your site administrator +or hosting service for details. + +

+Mailman provides a set of web pages that list members use to get +information about the list, or manage their membership options. There +are also list archive pages, for browsing an online web-based archive +of the list traffic. These are described in more detail in the GNU +Mailman user's manual. + +

+Mailman also provides a set of pages for configuring an individual +list, as well as a set of pages for disposing of posting and +subscription requests. + +

+For a mailing list called mylist hosted at the domain +lists.example.com, you would typically access the administrative +pages by going to http://lists.example.com/mailman/admin/mylist. +The first time you visit this page, you will be presented with a login +page, asking for the list owner's password. When you enter the +password, Mailman will store a session cookie in your browser, so you +don't have to re-authenticate for every action you want to take. This +cookie is stored only until you exit your browser. + +

+To access the administrative requests page, you'd visit +http://lists.example.com/mailman/admindb/mylist (note the +admindb url as opposed to the admin url). Again, the +first time you visit this page, you'll be presented with a login page, +on which you can enter either the list moderator password or the list +owner password. Again, a session cookie is dropped in your browser. +Note also that if you've previously logged in as the list owner, you +do not need to re-login to access the administrative requests page. + +

+ +

+
+

+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +1 Introduction to GNU +Next: + +
+
+
+Release 2.1, documentation updated on December 5, 2007. +
+ + + + diff --git a/doc/mailman-admin/node7.html b/doc/mailman-admin/node7.html new file mode 100644 index 00000000..8f41bc68 --- /dev/null +++ b/doc/mailman-admin/node7.html @@ -0,0 +1,147 @@ + + + + + + + + + + + + + +1.4 Basic Architectural Overview + + +
+
+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +1 Introduction to GNU +Next: + +
+
+
+ + +

+1.4 Basic Architectural Overview +

+ +

+This section will outline the basic architecture of GNU Mailman, such +as how messages are processed by the sytem. Without going into lots +of detail, this information will help you understand how the +configuration options control Mailman's functionality. + +

+When mail enters the system from your mail server, it is dropped into +one of several Mailman queues depending on the address the +message was sent to. For example, if your system has a mailing list +named mylist and your domain is example.com, people can +post messages to your list by sending them to +mylist@example.com. These messages will be dropped into the +incoming queue, which is also colloquially called the +moderate-and-munge queue. The incoming queue is where most of +the approval process occurs, and it's also where the message is +prepared for sending out to the list membership. + +

+There are separate queues for the built-in archiver, the bounce +processor, the email command processor, as well as the outgoing email +and news queues. There's also a queue for messages generated by the +Mailman system. Each of these queues typically has one queue +runner (or ``qrunner'') that processes messages in the queue. The +qrunners are idle when there are no messages to process. + +

+Every message in the queues are represented by two files, a message +file and a metadata file. Both of these files share the same base +name, which is a combination of a unique hash and the Unix time that +the message was received. The metadata file has a suffix of +.db and the message file has a suffix of either .msg if +stored in plain text, or .pck if stored in a more efficient +internal representation1. + +

+As a message moves through the incoming queue, it performs various +checks on the message, such as whether it matches one of the +moderation criteria, or contains disallowed MIME types. Once a +message is approved for sending to the list membership, the message is +prepared for sending by deleting, adding, or changing message headers, +adding footers, etc. Messages in the incoming queue may also be +stored for appending to digests. + +

+

Footnotes

+
+
... representation1
+
Specifically, a Python pickle + +
+
+
+
+

+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +1 Introduction to GNU +Next: + +
+
+
+Release 2.1, documentation updated on December 5, 2007. +
+ + + + diff --git a/doc/mailman-admin/node8.html b/doc/mailman-admin/node8.html new file mode 100644 index 00000000..3a7fc7c8 --- /dev/null +++ b/doc/mailman-admin/node8.html @@ -0,0 +1,177 @@ + + + + + + + + + + + + + + +2 The List Configuration Pages + + +
+
+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +Contents +Next: + +
+
+
+ + +

+2 The List Configuration Pages +

+ +

+After logging into the list configuration pages, you'll see the +configuration options for the list, grouped in categories. All the +administrative pages have some common elements. In the upper section, +you'll see two columns labeled ``Configuration Categories''. Some +categories have sub-categories which are only visible when you click +on the category link. The first page you see after logging in will be +the ``General Options'' category. The specific option settings for +each category are described below. + +

+On the right side of the top section, you'll see a column labeled +``Other Administrative Activities''. Here you'll find some other +things you can do to your list, as well as convenient links to the +list information page and the list archives. Note the big ``Logout'' +link; use this if you're finished configuring your list and don't want +to leave the session cookie active in your browser. + +

+Below this common header, you'll find a list of this category's +configuration variables, arranged in two columns. In the left column +is a brief description of the option, which also contains a +``details'' link. For many of the variables, more details are +available describing the semantics of the various available settings, +or information on the interaction between this setting and other list +options. Clicking on the details link brings up a page which contains +only the information for that option, as well as a button for +submitting your setting, and a link back to the category page. + +

+On the right side of the two-column section, you'll see the variable's +current value. Some variables may present a limited set of values, +via radio button or check box arrays. Other variables may present +text entry boxes of one or multiple lines. Most variables control +settings for the operation of the list, but others perform immediate +actions (these are clearly labeled). + +

+At the bottom of the page, you'll find a ``Submit'' button and a +footer with some more useful links and a few logos. Hitting the +submit button commits your list settings, after they've been +validated. Any invalid values will be ignored and an error message +will be displayed at the top of the resulting page. The results page +will always be the category page that you submitted. + +

+ +


+
+ +Subsections + + + +
+ +
+
+

+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +Contents +Next: + +
+
+
+Release 2.1, documentation updated on December 5, 2007. +
+ + + + diff --git a/doc/mailman-admin/node9.html b/doc/mailman-admin/node9.html new file mode 100644 index 00000000..6203bde9 --- /dev/null +++ b/doc/mailman-admin/node9.html @@ -0,0 +1,117 @@ + + + + + + + + + + + + + + +2.1 The General Options Category + + +
+
+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2 The List Configuration +Next: + +
+
+
+ + +

+2.1 The General Options Category +

+ +

+The General Options category is where you can set a variety of +variables that affect basic behavior and public information. In the +descriptions that follow, the variable name is given first, along with +an overview and a description of what that variable controls. + +

+ +


+
+ +Subsections + + + +
+ +
+
+

+ + + + + + + + + +
Up one LevelGNU Mailman - List Administration ManualContents
+
+Previous: + +Up: +2 The List Configuration +Next: + +
+
+
+Release 2.1, documentation updated on December 5, 2007. +
+ + + + diff --git a/doc/mailman-admin/previous.png b/doc/mailman-admin/previous.png new file mode 100644 index 00000000..497def42 Binary files /dev/null and b/doc/mailman-admin/previous.png differ diff --git a/doc/mailman-admin/pyfav.png b/doc/mailman-admin/pyfav.png new file mode 100644 index 00000000..d2d8669d Binary files /dev/null and b/doc/mailman-admin/pyfav.png differ diff --git a/doc/mailman-admin/up.png b/doc/mailman-admin/up.png new file mode 100644 index 00000000..a90e0284 Binary files /dev/null and b/doc/mailman-admin/up.png differ -- cgit v1.2.3