From 34d6ece8a454e5d1d027ed106ba039a0a88db36d Mon Sep 17 00:00:00 2001 From: bwarsaw <> Date: Sun, 17 Sep 2006 18:16:07 +0000 Subject: Copy the mm21 admin directory out of the mm21 branch. We'll svn external the latter to get that back into the release, but I really don't want to maintain multiple copies of the web pages. --- admin/www/mailman-admin/node18.html | 317 ------------------------------------ 1 file changed, 317 deletions(-) delete mode 100644 admin/www/mailman-admin/node18.html (limited to 'admin/www/mailman-admin/node18.html') diff --git a/admin/www/mailman-admin/node18.html b/admin/www/mailman-admin/node18.html deleted file mode 100644 index 7eb98306..00000000 --- a/admin/www/mailman-admin/node18.html +++ /dev/null @@ -1,317 +0,0 @@ - - - - - - - - - - - - - -2.5 The Non-digest Options Category - - - - - -

-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. - -
-
- - - - - -- cgit v1.2.3