From a3a7b94b04974c40bca54caece474e8506d53822 Mon Sep 17 00:00:00 2001 From: bwarsaw <> Date: Tue, 14 Dec 2004 14:14:32 +0000 Subject: updating the content for this guide --- admin/www/mailman-admin/node7.html | 200 ++++++++++++++++++++----------------- 1 file changed, 109 insertions(+), 91 deletions(-) (limited to 'admin/www/mailman-admin/node7.html') diff --git a/admin/www/mailman-admin/node7.html b/admin/www/mailman-admin/node7.html index 6f4839e8..90d38d0e 100644 --- a/admin/www/mailman-admin/node7.html +++ b/admin/www/mailman-admin/node7.html @@ -1,126 +1,144 @@
--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. +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.
-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. +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.
-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. +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.
-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.
+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.
-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.
+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.
+