[prev in list] [next in list] [prev in thread] [next in thread]
List: reiserfs-devel
Subject: (reiserfs) Getting past messages on reiserfs (reiserfs is ezmlm, which does a
From: Hans Reiser <reiser () idiom ! com>
Date: 1999-02-28 21:01:25
[Download RAW message or body]
6.3 Generating digests of a specific range of messages.
Send mail to list-dig.code.num1_num2. A digest of messages
num1 through num2 will be returned. The digest issue will be
set to num1 and the internal digest message and digest issue
counters will not be affected.
http://www.bath.ac.uk/~ccsmrh/docs/ezmlm/FAQ.idx
--
Don't be locked out of the source, and doomed to life in the slow lane.
Dump NT! Get Linux (http://www.kernel.org) plus ReiserFS
(http://devlinux.org/namesys). If you sell an OS or
internet appliance, buy a port of ReiserFS!
Speed matters. Trees are fast. Go faster!
["FAQ.idx" (text/plain)]
$Id: FAQ.idx,v 1.12 1997/10/29 00:30:12 lindberg Exp $
$Name: ezmlm-idx-020 $
(c) 1997, Fred Lindberg, lindberg@id.wustl.edu
Fred B. Ringel, fredr@rivertown.net
Use under GPL
EZMLM-IDX FREQUENTLY ASKED QUESTIONS
====================================
0. General Questions
----------------------
0.0 What is this document?
0.1 Where do I send comments on this document?
0.2 Where can I get all of the ezmlm-related programs?
0.3 Where can I find documentation for ezmlm and patches?
0.4 What do I do if ezmlm doesn't work?
0.5 How do I report ezmlm bugs?
0.6 Where do I send suggestions for ezmlm improvements?
0.7 How do I make customization simple for me/my users?
1. Common error conditions in ezmlm lists
-------------------------------------------
1.1 Post are rejected: Sorry, no mailbox here by that name.
(#5.1.1).
1.2 Post are not sent to subscribers.
1.3 Subscribe fails with: I do not accept messages at this
address (#5.1.1).
1.4 ezmlm-make fails: Unable to create ...
1.5 ezmlm-make fails: .../ezmlmrc does not exist
1.6 ezmlm-make fails: /etc/ezmlmrc & ... does not exist
1.7 Index/get/thread requests fail quietly or with errors from
ezmlm-manage.
1.8 Digest requests fail.
1.9 Remote administration (un)subscribe CONFIRM requests go to
the user, not the moderator.
1.10 Messages posted to a moderated list are sent out without
moderation.
1.11 Messages posted to a moderated list do not result in
moderation requests.
1.12 Moderation request replies do not result in the appropriate
action.
1.13 Moderator comments with moderation request replies are not
added to the post/sent to the poster.
1.14 Some headers are missing from messages in the digest.
1.15 Post fail with "Message already contains my mailing-list
header".
1.16 Digests are rejected by the digest lists with "Message is
not from my parent list".
1.17 The last line in DIR/text files is ignored.
1.18 No CONFIRM requests are sent to moderators.
2. Customizing outgoing messages
----------------------------------
2.1 Adding a trailer to outgoing messages.
2.2 Adding a subject prefix to outgoing messages.
2.3 Adding a header to outgoing messages.
2.4 Adding a message number header.
2.5 Removing headers from outgoing messages.
2.6 Setting 'Reply-To: list@host'.
3. Restricting messages
-------------------------
3.1 Restricting the size of posts.
3.2 Restricting posts to list subscribers.
3.3 Restricting posts to list and digest subscribers.
3.4 Restricting posts to an arbitrary set of addresses (low
security option).
3.5 Restricting posts to an arbitrary set of addresses (higher
security option).
3.6 Completely restricting posts.
4. Customizing archive retrieval
----------------------------------
4.1 Specifying the format for retrieved messages.
4.2 Limiting the number of messages per -get/-index request.
5. Restricting archive retrieval
----------------------------------
5.1 Restricting archive access to subscribers.
5.2 Restricting archive access to subscribers of list or digest.
5.3 Restricting available archive retrieval commands.
5.4 Restricting archive retrieval to moderators.
5.5 Allowing archive retrieval from a non-public list.
5.6 Restricting archive retrieval to an arbitrary set of
addresses.
6. Customizing digests
------------------------
6.1 Setting up a digest code.
6.2 Setting up a digest list.
6.3 Generating digests of a specific range of messages.
6.4 Generating the first digest.
6.5 Generating daily digests.
6.6 Generating digests after a certain cumulative size of
messages.
6.7 Generating digests after a certain number of messages.
6.8 Adding standard administrative information to digests.
6.9 Adding specific administrative information to a digest.
6.10 Controlling digest format.
7. Restricting digest generation
----------------------------------
7.1 Disallowing digest triggering by mail.
8. Customizing message and subscription moderation
----------------------------------------------------
8.1 A list with moderation of posts (p) and subs (s).
8.2 A list with moderation of posts (p) only.
8.3 A list with moderation of subscription (s) only.
8.4 A list with remote (r) admin only.
8.5 Moderating posts from a secondary account.
8.6 Moderating subscription from a secondary account.
8.7 Automatically approving posts or subscriptions.
8.8 Allowing moderators to get a subscriber list.
8.8 Changing the timeout for messages in the moderation queue.
8.10 Finding out how many messages are waiting for moderation.
8.11 Using the same moderators for multiple lists.
8.12 Using different moderators for message and subscription
moderation.
8.13 Setting up moderated lists with the list owner as the
"supermoderator" able to add/remove moderators remotely.
8.14 Customizing messages.
8.15 Manually approving messages awaiting moderation.
8.16 Manually rejecting a message.
9. Setting up lists with specific subsets of functions
--------------------------------------------------------
9.1 Variations in moderation.
9.2 Lists that allow remote admin, but not user-initiated
subscription or archive retrieval.
9.3 Lists that allow remote admin, user archive retrieval, but
not user-initiated subscription.
9.4 Lists that restrict archive retrieval to subscribers.
9.5 Lists that do not allow archive retrieval at all.
9.6 Lists that do not allow archive retrieval and do not allow
digest triggering by mail.
9.7 List that allow archive retrieval only to moderators, but do
allow user-initiated subscriptions.
9.8 Lists that do not require user confirmation for
(un)subscription.
9.9 Lists that restrict archive retrieval to a specific group of
addresses.
9.10 Lists that restrict archive retrieval to subscribers of the
list and a second (digest) list.
9.11 Lists that restrict posts to a set of addresses.
9.12 Lists that more securely restrict posts to a set of
addresses.
10. Customizing ezmlm-make operation
-------------------------------------
10.0 Customizing ezmlm-make for your system/a user.
10.1 Changing defaults for DIR/text files.
10.2 Changing default moderator directories.
10.3 Adapting ezmlm-make for virtual domains.
10.4 Why the ezmlm-make -c switch?
10.5 Setting up ezmlm-make for special situations.
11. ezmlm-idx compile-time options
-----------------------------------
11.1 Location of binaries.
11.2 Location of man pages.
11.3 Programs and documentation not automatically installed.
11.4 Short header texts, etc.
11.5 Arbitrary limits.
11.6 Command names.
11.7 Error messages.
11.8 Paths and other odd configuration items.
12. Two-byte character code support
------------------------------------
===========================================================
0. General questions
----------------------
0.0 What is this document?
This FAQ contains answers to many questions that arise while
installing ezmlm, ezmlm-idx, and setting up mailing lists.
This is the first version of an evolving document. If you find
any errors or wish to comment please do so to the authors.
This FAQ is currently for system administrators and
knowledgeable users, and heavily weighted towards questions
specific for use of the ezmlm-idx add-on.
If you have problems with the ezmlm-idx package, please start
by reading the 'man' pages which come with each program, then
this document and other referenced ezmlm documentation which
is identified here. If you have exhausted the resources
described in this document, try the ezmlm and qmail mailing
lists and the qmail mailing list archive. If you have solved a
problem not in the documentation, write it up as a proposed
section of a FAQ and send it to the authors. This way, it can
be added to the next version of this FAQ.
This document uses a number of terms:
DIR - the base directory of the list
digDIR - the base directory of a digest list
SENDER - the envelope sender of the message, as passed to
ezmlm by qmail via the $SENDER environment variable.
LOCAL - The local part of the envelope recipient. For
list-get-1@host, it is usually list-get-1. If host
is a virtual domain, controlled by user-sub, then
local would be user-sub-list-get-1.
moddir - base directory for moderators. To add or remove
moderators:
% ezmlm-sub moddir moderator@host.domain
% ezmlm-unsub moddir moderator@host.domain
Moderator addresses are stored in a hashed database
in moddir/subscribers. By default, 'moddir' is
DIR/mod.
dotdir - the second argument of ezmlm-make is the main
.qmail file for the list. dotdir is the directory in
which this 'dot file' resides, i.e. the directory
part of the 'dot' argument. This is usually the home
directory of the user controlling the list (but NOT
necessarily of the one creating the list). Thus, if
'root' creates a list:
# ezmlm-make ~alias/LIST ~alias/.qmail-list ...
the dotdir is '~alias/'. This directory is where the
.ezmlmrc file is expected when the ezmlm-make -c
switch is used (see "Customizing ezmlm-make
operation").
ezmlm binary directory
- The directory where the ezmlm-binaries are
normally stored, as defined at compile time by conf-
bin. This is compiled into the programs and does not
automatically change just because the program has
moved.
ezmlm-get.1 - This is a reference to the ezmlm-get.1 man page.
Access it with one of the following:
% man ezmlm-get
% man 1 ezmlm-get
or if you have not yet installed ezmlm-idx:
% cd ezmlm-idx-0.12
% man ./ezmlm-get.1
To change the ownership of DIR and everything within:
% chown -R user DIR
% chgrp -R group DIR
Depending on your system/shell, it may be possible to combine
these two into one of:
% chown -R user.group DIR
% chown -R user:group DIR
0.1 Where do I send comments on this document?
To the authors per E-mail:
Fred Lindberg: lindberg@id.wustl.edu
Fred B. Ringel: fredr@rivertown.net
0.2 Where can I get all of the ezmlm-related programs?
A. ezmlm-0.53:
i) Dan's Bernstein's FTP site (Dan is the author of ezmlm):
ftp://koobera.math.uic.edu/pub/software/ezmlm-0.53.tar.gz
ii) Mirrors:
ftp://ftp.id.wustl.edu/pub/qmail/ezmlm-0.53.tar.gz
ftp://ftp.ntnu.no/pub/unix/mail/qmail/ezmlm-0.53.tar.gz
ftp://ftp.pipex.net/mirrors/qmail/ezmlm-0.53.tar.gz
ftp://ftp.hpcl.titech.ac.jp/qmail/ezmlm-0.53.tar.gz
ftp://ftp.rifkin.technion.ac.il/pub/qmail/ezmlm-0.53.tar.gz
ftp://ftp.mira.net.au/unix/mail/qmail/ezmlm-0.53.tar.gz
http://www.qmail.org/
B. ezmlm-idx-0.20:
ftp://ftp.id.wustl.edu/pub/patches/ezmlm-idx-0.20.tar.gz
C. ezmlm-issub-0.03:
ftp://ftp.id.wustl.edu/pub/patches/ezmlm-issub-0.03.tar.gz
0.3 Where can I find documentation for ezmlm and patches?
A. All ezmlm component programs come with their own man pages.
Thus, for info on ezmlm-send, type:
% man ezmlm-send
or if you have unpacked ezmlm, but not made it or installed
it:
% cd ezmlm-0.53
% man ./ezmlm-send.1
B. General info on ezmlm and list directories is in ezmlm.5:
% man ezmlm
or
% cd ezmlm-0.53
% man ./ezmlm.5
NOTE: Installation of the ezmlm-idx package updates some
existing man pages to reflect changes made by the patch (e.g.
ezmlm-send.1, ezmlm.5).
C. ezmlm comes with a README file with general instructions,
an INSTALL file with installation instructions, an UPGRADE
file for upgrading from a previous version and a CHANGES file
with information on changes from previous versions. ezmlm-idx
comes with similar files suffixed with '.idx'. Most other
patches or add-ons contain similar files and man pages and
should contain identifying suffixes (.iss for ezmlm-issub, for
example). In addition, the file TEST.idx is a testing
protocol, which may be helpful in debugging list setups, as it
lists expected ezmlm responses under most circumstances.
SECURITY.idx discusses security aspects of the ezmlm-idx add-
on.
D. This FAQ.
E. WWW resources:
Ezmlm setup guide:
http://www.berlin.de/~kesim/ezmlm/
General qmail/ezmlm info:
http://www.qmail.org
The qmail mailing list archive:
http://www.ornl.gov/cts/archives/mailing-lists/qmail/
The ezmlm mailing list archive:
http://sunsite.auc.dk/mhonarc-archives/ezmlm/
F. Mailing lists:
Please read other documentation and mailing list archives
before posting questions to the lists. It's also useful to
'lurk' on the list for a few days, (i.e. to subscribe and
read without posting) before asking your questions on the
list.
To subscribe, send mail to the addresses listed:
ezmlm: djb-ezmlm-subscribe@koobera.math.uic.edu
qmail: djb-qmail-subscribe@koobera.math.uic.edu
0.4 What do I do if ezmlm doesn't work?
Try to determine where the problem occurs and how to reproduce
it:
-Do messages to ezmlm return an error message to the sender or
not?
-What is/are the error message(s)?
-What does ezmlm log into the mail log?
-Are you using a setup with virtual domains? If so, have you
adjusted DIR/inlocal (see "Adapting ezmlm-make for virtual
domains")?
-Are posts sent out to the subscribers?
-Are there subscribers?
% ezmlm-list DIR
-Are there moderators?
% ezmlm-list moddir
where 'moddir' is the contents of DIR/remote (for remote admin
lists), of DIR/modsub (for subscription moderated lists) or
DIR/modpost (for message moderation), if and only if the
contents start with a forward slash. Default in all cases is
DIR/mod. If both DIR/modsub and DIR/remote contain directory
names, the one in DIR/modsub is used for both subscription
moderation and remote admin.
-Are the permissions of all files correct, i.e. read/writable
for the owner?
% chown -R user DIR
% chgrp -R group DIR
For lists under alias:
% chown -R alias DIR
% chgrp -R qmail DIR
If you use custom moderator databases, those directories and
all their contents must also be readable to the user under
which the list operates (i.e. the user qmail changes to during
the delivery).
-Read the qmail log and capture relevant parts.
-Did you customize the package at all? If so, try the default
settings which are known to work.
-Did you customize ezmlmrc? Try to use the default copy (skip
the -c switch).
-Did your customization of .ezmlmrc fail to have an effect?
Remember to use the -c switch. The .ezmlmrc file used is the
one in the 'dot directory', i.e. the directory where the
.qmail files go, NOT necessarily the one in your home
directory.
-Make sure you followed the instructions in man pages and
other documentation. Most of the problems are due to not
closely following the instructions. Try again with a new test
list.
-Make sure to take notes of how the list was created (which
flags you used, etc.).
-use ezmlm-env (see ezmlm-get.1) to check the command line
variables passed to ezmlm, and compare these to DIR/inlocal,
etc. If you don't get a reply from ezmlm-env, the message is
not delivered properly. Check your qmail setup.
Try to find your problem or a question/item close to it in the
FAQ.
If this didn't do it, post to the mailing list, describing how
you set up the list, your general setup (especially the
relevant control files for a virtual domain), what works and
what doesn't and what results from different actions (log
entries, error messages).
If you have solved a problem that you believe might be more
general, please send a description of the problem and its
solution to the authors, ideally as a FAQ item.
0.5 How do I report ezmlm bugs?
If you have found a bug in the ezmlm-idx additions, please
send a bug report by E-mail to lindberg@id.wustl.edu. Describe
the error, your setup, and your system in sufficient detail so
that I can figure out what's wrong. Include relevant sections
of mail log, and information about any error messages
returned. Ideally, include a fix as a context diff against the
distribution.
If you have found a bug in ezmlm proper, please send a similar
bug report to djb@koobera.math.uic.edu or djb-
ezmlm@koobera.math.uic.edu. If you're unsure where the bug is,
you can start with lindberg@id.wustl.edu.
If you have problems and questions, please refer to the
documentation, then to mailing list archives, then e-mail the
ezmlm list or the authors.
0.6 Where do I send suggestions for ezmlm improvements?
E-mail to lindberg@id.wustl.edu, ideally with a context diff.
For ezmlm proper, djb-ezmlm@koobera.math.uic.edu may be
better.
0.7 How do I make customization simple for me/my users?
All non-default switches, ezmlm-issub setups, etc, can be made
standard for new lists by using the ezmlm-make ezmlmrc file
for customization. A default ezmlmrc is installed in the ezmlm
binary directory. A system-wide customized one if installed as
/etc/ezmlmrc overrides this. Installing a ~/.ezmlmrc file in a
user dot-dir and using the ezmlm-make -c switch allows further
customization (see "Customizing ezmlm-make operation").
1. Common error conditions in ezmlm lists
-------------------------------------------
1.1 Post are rejected: Sorry, no mailbox here by that name
(#5.1.1).
Qmail on the host tries to deliver the mail, but there is no
mailbox with that name. For list user-list on a simple setup,
ezmlm-make should have created a set of files ./qmail-list,
./qmail-list-default, etc, in the home directory of user.
Check to see of these exist and the list files have the proper
permissions and ownerships, and that they are links to
DIR/editor, DIR/manager, etc. If used, make sure qmail,
including /var/qmail/user/assign, is properly set up.
1.2 Post are not sent to subscribers.
Read the qmail log. Is your message delivered to the list? You
can also:
% cat DIR/num
send a message to the list
% cat DIR/num
If the number has been incremented, the message went to the
list, and was successfully sent out in the opinion of ezmlm-
send (ezmlm-send doesn't mind if there are no subscribers).
For message moderated lists, do:
% ls -l DIR/mod/pending
send a message to the list, then:
% ls -l DIR/mod/pending
A new file should have appeared. If this file has the owner
'x' execute bit set, it was successfully processed by ezmlm-
store. If this is so, but no moderation request was sent, then
continue with "Messages posted to the list do not result in
moderation requests". If there is no new file, the message did
not reach ezmlm-store, or ezmlm-store failed early, which
should have resulted in an entry in the mail log. If it is
there, but the owner 'x' bit is not set, ezmlm-store failed.
Check the mail log. Common reasons would be a failure to find
the ezmlm-send binary in the same directory as ezmlm-store and
DIR/msgsize being set or the message body exceeding that size.
If the message was not received/processed, there should be an
error message in the mail log. Fix temporary and permanent
errors with the help of qmail (usually) and ezmlm
documentation. If there is no log entry at all, then the mail
went to another host. Check your qmail setup.
If mail was delivered to the list, but not forwarded to the
subscribers (check the qmail log - there should be an entry
for a new delivery during the delivery of the message to the
list), the most common error is that there are no subscribers.
Ezmlm-send sends a message from list-help@host, then logs
success without ever logging any recipients.
Check subscribers:
% ezmlm-list DIR
Assure that permissions are correct on the list directories:
% chown -R user DIR
% chgrp -R user DIR
For lists owned by the 'alias' user (in ~alias):
% chown -R alias DIR
% chgrp -R qmail DIR
Most other problems should be easily corrected with the help
of the qmail log.
1.3 Subscribe fails with: "I do not accept messages at this
address (#5.1.1)".
This is because LOCAL of the delivery (e.g. user-list-
subscribe) does not start with the contents of DIR/inlocal.
The most common cause of this problem is that ezmlm-make was
used without customization to set up a list controlled via a
virtual domain.
If the list name is 'list' and the user controlling the
virtual domain 'domain.dom' is 'user', run ezmlm-make with
list name 'list' and host 'domain.dom', then edit DIR/inlocal
to be 'user-list' rather than 'list. Alternatively, create a
local .ezmlmrc file for that virtual domain, and edit the
DIR/inlocal setup (see "Customizing ezmlm-make operation").
1.4 ezmlm-make fails: Unable to create ...
DIR or .qmail files already exist. ezmlm-make fails if any
directories or links are preexisting. Erase all of them first
(NOTE: DO NOT USE THESE COMMANDS WITHOUT UNDERSTANDING THEM.
The second will e.g. erase all .qmail links files associated
with a putative list-digest list as well!):
% rm -rf DIR
% rm -rf ~/.qmail-list ~/.qmail-list-*
If you want to save some files (such as in DIR/text), make
backup copies first, run ezmlm-make, then copy the backups to
DIR/text. Of course, it is usually easier to create a custom
.ezmlmrc, and than use that for all your lists.
1.5 ezmlm-make fails: .../ezmlmrc does not exist
You have specified the ezmlm-make -c switch, but there is no
readable .ezmlmrc file in dotdir. (See "Customizing ezmlm-make
operation").
1.6 ezmlm-make fails: /etc/ezmlmrc & ... does not exist
ezmlm-make normally looks for ezmlmrc in /etc and in the ezmlm
binary directory, but was unable to find it. Make sure that
there is user-readable ezmlmrc file in either place or use the
-c switch to use .ezmlmrc in dotdir. A unmodified copy should
be found in the ezmlm binary directory. If /etc/ezmlmrc
exists, it is a copy that has been adapted to the local site.
.ezmlmrc is customized for a particular mail recipient (See
"Customizing ezmlm-make operation").
1.7 Index/get/thread requests fail quietly or with errors from
ezmlm-manage.
Make sure this is an indexed list with an ezmlm-get line first
in DIR/manager. If not, your commands are fed directly to
ezmlm-manage. If they contain '-', ezmlm-manage interprets the
rest as an address to which it sends the error message.
Usually, this results in a 'trash address' mail log entry and
a bounce, which is why you don't see any error message. The
same happens if you send non-existing commands. Thus,
list-gugu-54 results in an ezmlm-manage error, resulting in
help text being sent to '54@localhost' ... When testing, try
using syntax with a '.', not a '-', after the action command,
e.g. list-get.54_60@host. This will assure that error messages
get back to you.
1.8 Digest requests fail.
If you get an error message, it tells you why the request
failed. If you do not, see the previous item. Try using syntax
without '-' after the 'dig' command. Also, requests that would
result in an empty digest are silently ignored, but the reason
why no digest was created is logged to the mail log. This is
done so that cron scripts generating daily digest will just
fail silently, rather than generating an error (revealing
digest code, etc) to the digest list.
1.9 Remote administration (un)subscribe CONFIRM requests go to
the user, not the moderator.
Either the list is not set up for remote admin (i.e.
DIR/remote does not exist), or the moderator is sending the
request from an address that is not in the moderator database
(e.g. from Fred@host.dom, when fred@host.dom is in the
moderator db, but Fred@host.dom is not). ezmlm-manage has no
way of knowing that the SENDER is a moderator and treats the
request as coming from a regular user, i.e. it sends a
confirmation request to the target address. Correct the SENDER
address, the address in the moderator db, or create
DIR/remote. If you are using a non-default moderator db
location, make sure that the moddir name is in DIR/remote (for
remote admin only) or DIR/modsub (if there is subscription
moderation as well). In both cases, the contents will be
ignored unless they start with a '/'.
1.10 Messages posted to a moderated list are sent out without
moderation.
The list is not moderated. Check DIR/editor. If should contain
a 'ezmlm-store' line after the ezmlm-reject line if it is a
moderated list. No 'ezmlm-send' line should be in DIR/editor.
If there is, the lists is not moderated.
1.11 Messages posted to a moderated list do not result in
moderation requests.
-Check that ~/.qmail-list is a link to DIR/editor.
-Check DIR/editor for an ezmlm-store, not an ezmlm-send entry.
If this is not the case, the list is not message moderated.
-Check qmail logs for error conditions during post delivery
and correct these. If the messages are delivered correctly,
verify that ezmlm-store (via ezmlm-send) generated the
moderation requests to the moderators.
Check to see that there are indeed moderators:
% ezmlm-list moddir
where 'moddir' is the contents of DIR/modpost if they start
with a '/', otherwise those of DIR/remote (same '/'
requirement), and DIR/mod by default.
Another common problem is directory permissions, especially
for lists under ~alias. To correct this error, issue the
following command (User the user/group of the list owner; for
~alias lists user=alias, group=qmail):
% chown -R user DIR
% chgrp -R group DIR
1.12 Moderation request replies do not result in the appropriate
action.
-Check that the address in the moderation request is correct.
-Check that the ~/.qmail-list-accept-default and
~./qmail-list-reject-default links exists and point to
DIR/moderator.
-Check that DIR/moderator invokes ezmlm-moderate, and that
there is a copy of ezmlm-send in the ezmlm binary directory.
-Check the qmail log to see that the replies were delivered to
this address.
-Check permissions. For lists under alias:
% chown -R alias DIR
% chgrp -R qmail DIR
This needs to be done every time you add/remove moderators as
'root'. For user-controlled lists (i.e. you are 'user' when
running e.g. ezmlm-sub) this is not a problem.
If setting up lists for a user controlling a virtual domain,
you can avoid many problems by assuming that uid ('su user')
before making any changes.
Check the qmail logs: After the delivery of the moderation
request, ezmlm-send should run to send messages to all the
list subscribers. Make sure there are list subscribers:
% ezmlm-list DIR
Most error conditions, incorrect request cookies, etc, should
result in informative error messages.
1.13 Moderator comments with moderation request replies are not
added to the post/sent to the poster.
Moderator comments are ignored for 'reject'. If you want to
comment on accepted posts, do so via a follow-up post. This is
to avoid anonymously tagged-on text to posts. If a moderator
has something to say to the list, they should (and can only)
do so in regular posts.
Moderator comments for 'reject' need to be enclosed between
two lines (yes, the end marker is required), having '%' in
position 2 and 3, like:
123
%%%
comment
%%%
or:
123
>%%%
comment
>%%%
but not:
123
%%
COMMENT
%%
and not:
%%% this is my comment %%%
ezmlm-mod-0.11 used the '#' character instead of '%' here.
This still works exactly as before. The change was made to
allow '#' as a comment character in ezmlmrc. Thus, you don't
need to change anything in old lists (or retrain moderators).
1.14 Some headers are missing from messages in the digest.
By default, only a subset of message headers are sent out in
any digest and archive retrieval requests. First, headers in
DIR/headerremove are stripped. Then, most non-essential
headers are excluded in the default archive retrieval format.
Use the 'v' format (see ezmlm-get.1) to get all message
headers that are in the archive.
1.15 Post fail with "Message already contains my mailing-list
header".
The list you are trying to post to is used as a sublist (fed
with messages from another [ezmlm] list), but not properly set
up as a sublist. Put 'origlist@orighost' which exactly matches
the SENDER of the original list into DIR/sublist. Check the
ownership of DIR/sublist, to make sure that the user
controlling the list can read it.
1.16 Digests are rejected by the digest lists with "Message is
not from my parent list".
The list is set up as a sublist, but posts to the list are not
from the parent list, or not from any mailing list. Depending
on the actions/result you desire, for the former, correct the
contents of DIR/sublist. For the latter, remove DIR/sublist.
1.17 The last line of DIR/text file sis ignored.
Only complete lines ending with '\n' are copied. Your last
line most likely lacks a terminal '\n'.
1.18 No CONFIRM requests are sent to moderators.
Assuming that the user initiated the subscribe request, got a
'confirm' request, and replied correctly, there are two
possible causes for the problem: Either the list is not
subscription moderated (in this case the user is subscribed
and received a not saying so) or the list is subscription
moderated by no moderators have been added (ezmlm-manage sends
out the request and doesn't mind that there are no
recipients).
Check that the list is subscription moderated:
% cat DIR/modsub
If this fails the list is not subscription moderated. If it
succeeds with a directory name with a leading '/', this is
your 'moddir'. If not:
% cat DIR/remote
If this succeeds with a directory name with a leading '/',
this is your moddir, otherwise the moddir is 'DIR/mod'.
Check for moderators:
% ezmlm-list moddir
If there are none, this is your problem. If there are some,
check the mail log to see what happened when the CONFIRM
requests was supposed to have gone out. Assure correct
permissions for the moderator db:
% chown -R user moddir; chgrp -R group moddir
For ~alias:
# chown -R alias moddir; chgrp -R qmail moddir.
Another possible problem is that you are trying to use the
remote admin feature to subscribe a user, but you get no
CONFIRM request. Usually, this is due to your SENDER address
not being in the moderator database (NOTE: Case sensitive
local part, per rfc822!). The CONFIRM request went to the
target address instead, since as far as ezmlm is concerned,
you are a regular user.
2. Customizing outgoing messages
----------------------------------
2.1 Adding a trailer to outgoing messages.
Put the text in DIR/text/trailer. The text is NOT copied to
the archived version of the message. This works also for
sublists.
2.2 Adding a subject prefix to outgoing messages.
Put the exact text in DIR/prefix. When this option is active,
ezmlm-send does its best to remove reply indicators, etc, to
keep the subject index clean. One consequence of this is that
ezmlm attempts to "normalize" the subjects of posts, e.g. 'Re:
prefix Re: prefix This is it -Reply' becomes 'Re: prefix This
is it'. Sublists ignore DIR/prefix.
If you add a prefix, especially if you used to add it by other
means (procmail, etc.), use ezmlm-idx to reindex the archive.
2.3 Adding a header to outgoing messages.
Put the exact header text as a line in DIR/headeradd.
2.4 Adding a message number header.
If you create DIR/sequence, the first line of that file will
be added to every outgoing post, followed by a space and the
message number. NOTE: This is the local message number. If you
have a central archive, and sublists, it makes most sense to
use this only for the main list, although it is technically
possible to add this header from sublists as well.
On the other hand, bounced messages are identified by their
local message numbers, i.e. when ezmlm sends you a message
about which messages bounced, it refers to the message number
of the sublist. To be consistent with these numbers, and a
local sublist archive, use DIR/sequence on the sublist, not
the main list. To get consistent message numbering in digests,
you could generate a digest at each sublist location. You
could also issue headers for each list clearly identifying
them, e.g. 'X-Seq: mainlist@host message number' and 'X-Seq:
sublist@subhost message number'.
A sequence header may be useful for users whose systems don't
pass on the 'Return-to:' header to the MUA. Headers of this
type should start with 'X-', but ezmlm-send doesn't check
this.
2.5 Removing headers from outgoing messages.
Put the header up to, but excluding the ':' in
DIR/headerremove.
2.6 Setting 'Reply-To: list@host'.
This is not recommended, since it leads to dissemination via
the list of messages returned from bad autoresponders and
MTAs. Also, it may lead to replies to the list where personal
replies were intended. In addition, the original 'Reply-To:'
header is lost. If you do want to add a reply-to list header,
put 'reply-to' into DIR/headerremove, and 'Reply-To:
list@host.dom' into DIR/headeradd.
3. Restricting messages
-------------------------
3.1 Restricting the size of posts.
If DIR/msgsize exists and contains a number (in bytes) greater
than '0', any posts with a body larger than the number
specified is rejected. For moderated lists, messages that are
too large are rejected without being sent to the moderators.
3.2 Restricting posts to list subscribers.
Use message moderation. As an alternative, implement a check
against SENDER by using ezmlm-issub. This has two problems:
First, it is easily defeated by faking SENDER. Second, it
prevents posts from legitimate subscribers that are subscribed
under a different address than the one they send from.
Nevertheless, it may be useful in some situations. Add:
|/usr/local/bin/ezmlm/ezmlm-issub 'DIR' "$SENDER" ||
( echo "$SENDER is not allowed. Contact me@somewhere";
exit 100 )
ALL ON ONE LINE to DIR/editor before the ezmlm-send line.
NOTE: The local part of E-mail addresses is case sensitive.
ezmlm respects that.
See "Customizing ezmlm-make operation" if you want your lists
to have some of these features by default or in response to
specific ezmlm-make switches.
3.3 Restricting posts to subscribers of list and digest.
With the same caveats as above, add:
|/usr/local/bin/ezmlm/ezmlm-issub 'DIR' "$SENDER" ||
/usr/local/bin/ezmlm/ezmlm-issub 'digDIR' "$SENDER" ||
( echo "$SENDER is not allowed. Contact me@somewhere";
exit 100 )
ALL ON ONE LINE to DIR/editor before the ezmlm-send line.
3.4 Restricting posts to an arbitrary set of addresses (low
security option).
Set up a address database in a directory 'addrdir':
% mkdir addrdir; mkdir addrdir/subscribers
% ezmlm-sub addrdir address1@host1 address2@host2 ...
Set up ezmlm-issub, just as for "Restricting posts to list
subscribers", but instead of 'DIR' put 'addrdir'. Now only
posts with a SENDER that is in the database will be accepted.
This is not secure, since it is easy to fake SENDER, but will
prevent e.g. most spam from appearing on the list.
3.5 Restricting posts to an arbitrary set of addresses (higher
security option).
The easiest way to achieve this is to simply set up a message
moderated list, and add all the addresses in the set to the
moderator db. Use a custom location, if you want a different
set of moderators for subscription moderation/remote admin. If
a "moderator" posts, only s/he will get a confirmation
request. If anybody else posts, the post will be sent to all
moderators.
To directly bounce posts from SENDERs not in the database, use
the ezmlm-store -P [not public] switch. This is more secure
than a simple ezmlm-issub construct, since faking SENDER to a
moderator address will result in a confirmation request to
that moderator (which s/he will reject/ignore), rather than a
direct post. The draw-back is that each post has to be
confirmed, but with the speed of ezmlm the request will arrive
immediately after the post is made, so the overhead should be
minimal. The best choice depends on your particular needs in
the trade-off between security and convenience.
Setting a list up in this way with only the owner's address
gives you a pretty safe owner-only list.
3.6 Completely restricting posts.
To completely prevent posting (for instance a message-of-the-
day list), set up a normal list, and just remove ~/.qmail-list
and DIR/editor altogether. Make posts from the shell, or from
shell scripts or crond, by simply piping a (complete) message
to ezmlm-send:
% cat message |/usr/local/bin/ezmlm/ezmlm-send DIR
Note: This can be done by any user with write access to
DIR/lock, so make sure your file modes are set correctly.
4. Customizing archive retrieval
----------------------------------
4.1 Specifying the format for retrieved messages.
Add a format (f) specifier after the archive retrieval
command:
list-getf@host
where 'f' is 'r' for rfc1153 format, 'm' (default) for MIME
multipart/digest with subset of ordered headers, and 'v' for
virgin MIME multipart/digest, i.e. with all headers retained
from the archive.
4.2 Limiting the number of messages per -get/-index request
By default, a single -get request returns a maximum of 50
messages, and a single -index request 2000 subjects (20 files
of 100 subjects). This can be changed by editing MAXGET, and
MAXINDEX in idx.h and recompiling. Remember to edit
text/bottom, text/bounce, and ezmlmrc to reflect these changes
so that your users won't get too confused.
5. Restricting archive retrieval
----------------------------------
5.1 Restricting archive access to subscribers.
If you use ezmlm-get, archive retrieval can be restricted to
subscribers with the '-s' switch. Since ezmlm-get always sends
the reply to SENDER, this assures that only subscriber
addresses can get archive excerpts. Since SENDER is easily
faked, anyone can still request archive info (and drain system
resources), but replies go only to subscriber addresses.
5.2 Restricting archive access to subscribers of list or
archive.
To allow both list subscribers and digest list subscribers to
access the main list archive, but nobody else, you need to set
up a separate file 'DIR/get' for ezmlm-get functions, and make
your users always use a '-' after the command, i.e.
list-thread-54, not list-thread.54 (change text/bottom and
ezmlmrc to make users aware of the syntax!). You also need to
use -dig-code, not dig.code. This is necessary, since you
still want new users to be able to use the subscribe function
of ezmlm-manage.
Set up /DIR/get (the first 3 lines here all on one line!):
|/usr/local/bin/ezmlm/ezmlm-issub 'DIR' "$SENDER" ||
/usr/local/bin/ezmlm/ezmlm-issub 'digDIR' "$SENDER" ||
( echo "$SENDER is not allowed. Contact me@somewhere";
exit 100 )
|/usr/local/bin/ezmlm/ezmlm-get 'DIR'
Set up /DIR/digest:
|/usr/local/bin/ezmlm/ezmlm-get -C 'DIR' code
Then link qmail files for all the commands to this file:
% ln -s /DIR/get ~/.qmail-get
% ln -s /DIR/get ~/.qmail-index
% ln -s /DIR/get ~/.qmail-thread
% ln -s /DIR/digest ~/.qmail-dig
And then remove the ezmlm-get line from DIR/manager. To
disallow certain commands, just leave out the corresponding
link.
If you have shell access to the host that runs the list, you
can eliminate DIR/digest and the corresponding link and
instead trigger digests directly from a shell script (see
"Disabling digests triggered by mail").
The ezmlm-manage get function allows VERP-style redirects. If
ezmlm-get is used in DIR/manager, -get requests should never
reach ezmlm-manage. Otherwise, the ezmlm-manage -get command
can be disabled with the -C switch.
5.3 Restricting available archive retrieval commands.
If you want to disable all archive retrieval except digest
creation, simply add the '-C' command line switch to the
ezmlm-get line in DIR/manager.
Otherwise, see above. Proceed in the same way, but in DIR/get,
set up:
|/usr/local/bin/ezmlm/ezmlm-get 'DIR'
Then put in only the links for the commands you want to allow.
Don't forget to set up 'dig' and DIR/digest as above if you
want to be able to generate digests by mail.
5.4 Restricting archive retrieval to moderators.
If DIR/public does not exist, ezmlm-manage and ezmlm-get
modify their behavior to disallow user requests, but for
remote admin lists, moderator requests will still be honored.
Thus, for a remote admin list without DIR/public, only
subscription/remote admin moderators can receive archive
retrievals. If you'd like this restriction of archive
retrieval with maintained user-initiatable ezmlm-manage
(subscription) functions, use the ezmlm-get -P [not public]
switch.
5.5 Allowing archive retrieval from a non-public list.
A non-public list lacks DIR/public. ezmlm-manage will not
honor user requests for (un) subscription, nor for archive
retrieval. The restriction on archive retrieval can be removed
with the ezmlm-get -p [public] switch.
5.6 Restricting archive retrieval to an arbitrary set of
addresses.
Create a base directory 'addrdir' for an address database, and
a 'subscribers' subdirectory of it and use ezmlm-sub to add
addresses:
% mkdir addrdir; mkdir addrdir/subscribers
% ezmlm-sub addrdir address1@host1 address2@host2 ...
Then, modify the setup for "Restricting archive access to
subscribers of list or digest" by using only one ezmlm-issub
construct and 'addrdir' as the ezmlm-issub DIR argument.
6. Customizing digests
------------------------
6.1 Setting up a digest code.
Either set up a list via ezmlm-make (the digest code is the
4th [optional] command line argument), or add the digest code
as the second [optional] command line argument to the
ezmlm-get command line in DIR/manager. The digest code should
contain only characters valid in the local part of e-mail
addresses (alphanumeric to be safe) and is case-insensitive.
If there is no digest code on the ezmlm-get command line,
ezmlm-get will not honor digest requests. If the digest
request does not have the correct digest code, and error will
be returned, rather than a digest.
6.2 Setting up a digest list.
Make the list:
% ezmlm-make DIR dot listname host gaga
where 'gaga' is the digest code.
Make the digest list:
% ezmlm-make -IA digDIR diglistdot diglistname host
% echo "listname@host" > digDIR/sublist
% echo "Reply-To: listname@host" >> digDIR/headeradd
This list is not archived or indexed, as there usually is not
need to archive digests, which are themselves created from the
main list archive. If you want the digests to be archived (so
that users that have missed digests can catch up), omit the
'IA' switches. However, it is easier to instruct them to 'get'
the missing messages from the main archive.
As usual, for lists under ~alias, remember to set permissions
correctly:
% chown -R alias DIR
% chgrp -R qmail DIR
% chown -R alias DIGDIR
% chgrp -R qmail DIGDIR
As an alternative, use the supplied ezmlm-both script (see
ezmlm-both.1).
ezmlm-make (as is) does not properly set DIR/inlocal when
lists are created under a user that controls a virtual domain.
If the user 'user' controls virtual the virtual domain, edit
DIR/inlocal to contain user-listname rather than listname, and
digDIR/inlocal to user-diglistname rather than diglistname.
The symptom of this being incorrect is that user subscribe,
archive retrieval, and digest requests fail for that list with
"I do not accept messages at this address ...". ezmlm-make can
now be easily configured for each user to set up all future
lists correctly. This involves placing a custom .ezmlmrc in
the home directory of that user and using the ezmlm-make -c
command line switch (see "Customizing ezmlm-make operation").
6.3 Generating digests of a specific range of messages.
Send mail to list-dig.code.num1_num2. A digest of messages
num1 through num2 will be returned. The digest issue will be
set to num1 and the internal digest message and digest issue
counters will not be affected.
6.4 Generating the first digest.
If you want the first digest to start with issue 1 and the
first message in your archive, no special action is required.
If you want the first digest to start at message 123 and you
have shell access, put '122' into DIR/dignum. If you do not
have shell access, send mail to list-dig.code.123. DIR/dignum
and DIR/digissue will be updated (DIR/dignum set to the last
message in the digest sent, and DIR/digissue incremented).
If you want the next digest to start at message 456, you can
always edit DIR/dignum to contain '455'. If you want the next
digest to be named issue 678, put '677' into DIR/digissue.
6.5 Generating daily digests.
% man ezmlm
Describes how to set up a cron script that does this. If you
have not installed ezmlm-idx, copy the files to the ezmlm-0.53
directory, apply the patch (see INSTALL.idx), then:
% cd ezmlm-0.53
% man ./ezmlm.5
If you have shell access to the host running the list, you can
also use the procedure described under "Disabling digest
triggering by mail".
6.6 Generating digests after a certain cumulative amount of
messages.
Make a cron job that regularly executes the following script.
The script tests the size of the archive and generates a
digest request if the size has increased more than the limit
since the last digest. It should be executed considerably more
frequently (e.g. 5x) than you expect to generate digests.
#!/bin/sh
# Script to check accumulated messages in a mailing list.
# invoke as: ifsize DIR
# where 'DIR' is the main list directory
#
# If there is more that $SIZE kb of new mail
# (usage is > $FILE + $SIZE),
# issue a digest and update the archive size in $FILE.
# This also counts index files, but that's only about
# 0.03 kb/message
###################### CONFIGURE ######################
# Size in kb at which digest is triggered
SIZE=32
# Name of file that keeps track of usage at last digest
FILE="$1/prev"
#######################################################
# Space currently used by archive
USAGE=`/usr/bin/du -csk "$1/archive" \
|/usr/bin/head -1|/usr/bin/cut -f1`
if [ "$1." = "." ];
then
echo "usage ifsize DIR"
exit 100
fi
if [ -f $FILE ];
then
PREV=`/bin/cat "$FILE"`
else
PREV=0
fi
DIGEST=$[ $USAGE - $PREV > $SIZE ]
# If size is exceeded, send mail to create a digest
# and save usage to
# file.
if [ $DIGEST != 0 ] ;
then
######################### CONFIGURE ########################
echo "send mail to do a digest"
############################################################
echo "$USAGE" > "$FILE"
fi
exit 0
6.7 Generating digests after a certain number of messages.
As above, but compare DIR/num and DIR/dignum in the list
directory in a similar manner. The former is the latest
message, the latter the last message in the previous digest.
You do not need to update DIR/dignum, since ezmlm-get does
that upon successful queuing of the digest.
6.8 Adding standard administrative information to digests.
DIR/text/digest is copied into "administrivia" after any
specific comment.
6.9 Adding specific administrative information to a digest.
The body of the -dig request up to the first line beginning
with '-' is copied into the "Administrivia" section of the
digest.
6.10 Controlling digest format.
Add a format specifier (f) after the digestcode:
list-dig.codef@host
where 'f' is 'r' for rfc1153 format, 'm' (default) for MIME
multipart/digest with a subset of headers, and 'v' for virgin
MIME multipart/digest, i.e. with all headers retained from the
archive.
7. Restricting digest generation
----------------------------------
7.1 Disabling digest triggering by mail
Since anyone who knows your digest code can trigger digests,
it may be desirable to disable this option. To do so, set up
DIR/manager and DIR/get as under "Restricting available
archive retrieval commands", but do not set up DIR/digest or
link ~./qmail-list-dig.
You can still generate digest by running ezmlm-get from the
shell or a script. For this, you have to set up the following
environment variables:
HOST - has to match the lists inhost
LOCAL - The list local name as in DIR/inlocal (e.g. user-
list) followed by the desired action, e.g. 'user-
list-dig.code'
SENDER - The address to receive the digest, e.g. list-
digest@host.
Now you can generate a digest, simply by feeding an empty
message to ezmlm-get. The digest code can be simple, since it
has no impact on security. Anyone can do this, if they have
write access to DIR/lock. Make sure your DIR permissions are
set appropriately.
Using linux bash, the script could be:
#!/bin/sh
# HOST must match DIR/inhost
HOST='host.domain'
# LOCAL must be list-..., where 'list' matches DIR/inlocal
LOCAL='user-list-dig.d'
# digest code is 'd'. Could be anything.
SENDER='user-list-digest@host.domain'
export HOST LOCAL SENDER
/usr/local/bin/ezmlm/ezmlm-get DIR d < /dev/null
It can be made better by testing the exit status of ezmlm-get
(99 [!] - success, 100 permanent error, 111 temporary error.
Again: ezmlm-get exits 99, not 0 on success!). Obviously, any
ezmlm-get function can be triggered in a similar manner.
8. Customizing moderation of posts and (un)subscription
---------------------------------------------------------
8.1 A list with moderation of posts (p) and subs (s).
% ezmlm-make -ms ~/DIR ~/.qmail-list me-list host.dom digcode
8.2 A list with moderation of posts (p) only.
% ezmlm-make -m ~/DIR ~/.qmail-list me-list host.dom digcode
8.3 A list with moderation of subscription (s) only.
% ezmlm-make -s ~/DIR ~/.qmail-list me-list host.dom digcode
8.4 A list with remote (r) admin only.
% ezmlm-make -r ~/DIR ~/.qmail-list me-list host.dom digcode
To also have subscription moderation, add the -s switch. To
also get message moderation, add the '-m' switch. The only
thing remote admin (-r) adds is that moderation-initiated
(un)subscribe requests are sent back to the moderator for
confirmation, rather than to the target address. Thus, even
for lists that do not have remote admin, you (a regular user)
can help address@adrhost.dom to subscribe, by sending mail to
'list-subscribe-address=adrhost.dom@listhost', and instructing
the user at that address to just reply to the message.
8.5 Moderating posts from a secondary account.
Post MODERATE requests can be forwarded anywhere and acted on
from there. All post moderation requests have subjects
starting with 'MODERATE for'. To get the right list, look at
the 'Mailing-list:' header.
8.6 Moderating subscription from a secondary account.
Request for moderation of posts can be forwarded to any
address and acted on from that address. All post moderation
requests have subjects starting with 'MODERATE for ' followed
by the list name.
Requests for moderator approval of user subscribe requests can
be forwarded to any address and acted on from that address.
All subscription moderation requests have subjects starting
with 'CONFIRM' [or 'CONFIRM subscribe to listname', since
'CONFIRM unsubscribe from listname' is sent to the moderator
only in reply to a moderator-initiated request on a list with
remote admin].
Remote administration (initiation by the moderator of
(un)subscribe requests on behalf of a user) CANNOT be
initiated from an account not listed in the moderator
database. If attempts are made, these will be treated as
regular requests, resulting in a confirm request to the user
(which includes a copy of the initial request, revealing the
moderator's address to the user). The user reply to a confirm
request will on a non-moderated list result in the addition of
the user address to the subscriber list, and in a moderated
list a CONFIRM request to all the moderators. Replies to
unsubscribe confirm requests always result in the removal of
the address, without moderator intervention (except in some
cases when the ezmlm-manage -U switch is used (see below)).
With this caveat, moderation and remote administration can be
done from a secondary address.
For the moderator to temporarily use a different address, s/he
needs to forward all CONFIRM and MODERATE messages to the new
address. For a permanent move, it is better to remove the old
moderator address and add the new SENDER address to make
moderator-initiated (un)subscribes without user intervention
possible.
8.7 Automatically approving posts or subscriptions.
Some times, it may be desirable for the moderator to
automatically approve all moderation requests. This may be
appropriate for a single moderator of a "civilized" list when
away for the week.
Set up your client to auto-reply to the 'Reply-To:' address
for all messages with subjects 'CONFIRM subscribe to listname'
or 'MODERATE for listname'. Beware that this can be used by
malicious people to trick your account to send mail anywhere.
In practice, this should not be a problem in most situations.
If you are worried, forward the messages to a (trusted) friend
and ask him/her to appropriately reply to the requests.
8.8 Allowing moderators to get a subscriber list.
Access to the subscriber list is sensitive. Thus, this option
is disabled by default. The -l ezmlm-manage command line
switch enables this option, but will send a subscriber list
only to a moderator's address. This allows a moderator to
retrieve a subscriber list also from a secondary account (i.e.
one to which the moderator's mail is delivered, but for which
SENDER is not a moderator). The latter option does not
decrease security, as it is trivial to fake SENDER (see the
separate document "SECURITY.idx" for a discussion of ezmlm-idx
security aspects).
For maximum subscriber list security, do not enable this
feature. To enable this feature by default, just modify
ezmlmrc (see "Customizing ezmlm-make operation").
If you want any user to be able to get a subscriber list, you
can set up a separate link to DIR/list and then put in a
script using ezmlm-list. The authors strongly urge against
this, since it is a common method for spammers to get valid
addresses from mailing lists. A subscriber with questions
about who is on the list should contact the list-owner. A
subscriber wishing to confirm that they are still on the list
can just send a message to 'list-subscribe@listhost', and
reply to the confirm request. The following message will be a
'ezmlm response' if the user was already a subscriber, and a
'WELCOME to listname' if s/he was not. Also, the wording of
the messages is different.
8.9 Changing the timeout for messages in the moderation queue.
Put the time in hours into DIR/modtime. It is forced into the
range 24-120 h by defines in idx.h.
8.10 Finding out how many messages are waiting for moderation.
% ls -l DIR/mod/pending
and count lines with the owner execute bit set (rwx------).
Others are remnants from failed ezmlm-store runs (ignore -
ezmlm-clean will remove them).
There is currently no way to see this remotely, although you
could easily install a script mailing the 'ls' output in
response to a message to e.g. list-chkqueue@host.
8.11 Using the same moderators for multiple lists.
Set up a moderator dir:
% mkdir /path/moddir /path/moddir/subscribers
% touch /path/moddir/lock
% chown -R user /path/moddir
% chgrp -R group /path/moddir
For alias:
# chown -R alias /path/moddir
# chgrp -R qmail /path/moddir
Then for the lists, put /path/moddir into DIR/modsub (for
moderation of subscribes), DIR/remote (for remote admin if
DIR/modsub does not exist), and DIR/modpost (for moderation of
messages).
NOTE: The path must start with a '/'.
8.12 Using different moderators for message and subscription
moderation.
Proceed as in the previous point, but set up two different
moddir. Naturally, one of these can be DIR/mod (preferably the
one for posts, to keep it cleaner). Then modify the
appropriate DIR files to contain absolute paths to the correct
moddir.
8.13 Setting up moderated lists with the list owner as the
"supermoderator" able to add/remove moderators remotely.
-Set up the main list (in DIR) with all the features you want
for normal messages and moderation.
-Set up a second list 'moderators' in SUPERDIR which is non-
indexed non-archived (to conserve resources), remote admin,
message moderated, and non-public (only the remote admin can
(un)subscribe users.
-Add the owner/"supermoderator" as the moderator of the second
list.
-Edit DIR/modsub, DIR/modpost, DIR/remote for the main list
(if they exist) and enter into them the path to the list
directory of the second list (/path/SUPERDIR).
This makes the subscribers of the moderators list the
moderators of the main list. "supermoderator" can
(un)subscriber moderators at will, but nobody else can. Posts
to the moderators list go to the "supermoderator" for
approval. If you don't need this communication channel, just
remove SUPERDIR/editor and the link to it. If you want
"supermoderator" to be the only poster to the moderators list,
add the ezmlm-store -P switch to the list in SUPERDIR.
If this is a common setup for you, you can write a simple
script creating both lists (plus a digest list, if desired)
with one simple action (see ezmlm-both and ezmlm-both.1 for an
example).
8.14 Customizing messages.
Subject lines, and other ezmlm output for moderation are
controlled by defines in idx.h and by files in DIR/text. To
customize these, change idx.h and recompile or for DIR/text
files, edit ezmlmrc (See "Customizing ezmlm-make operation").
8.15 Manually approving a message awaiting moderation.
All you have to do is to pipe the corresponding message to
'ezmlm-send DIR'. Messages awaiting moderation are kept in
DIR/mod/pending. To find a particular file, grep the contents.
Thus, to find a file from 'user@host.dom', try:
% grep 'user@host\.dom' DIR/mod/pending/*
[Depending on your setup, you may not have to escape ('\') the
period.] Check the files for the owner execute ('x') bit. It
is set on all messages queued successfully. Ignore other
files!
To then accept the message:
% cat DIR/mod/pending/filename \
% /usr/local/bin/ezmlm/ezmlm-send DIR
Alternatively, use the 'ezmlm-accept' script supplied in the
distribution. It checks the 'x' bit, ezmlm-send return codes,
removes the file, etc (see ezmlm-accept.1).
8.16 Manually rejecting a message.
Simply deleting the file from DIR/mod/pending will do it. If
you want to notify the sender, just send him/her an E-mail.
There is an easy way to get ezmlm-idx programs to do it for
you: just wait and let ezmlm-clean take care of it for you,
once the message has timed out (number of hours settable
within 24-240 in DIR/modtime; default 120).
9. Setting up lists with specific subsets of functionality
-------------------------------------------------------------
9.1 Variations in moderation
You can set up lists with combinations of message moderation,
subscription moderation, and remote administration, easiest by
combining ezmlm-make -m ,-s, and -r switches. You can use a
non-default moderator db, by specifying a directory starting
with a slash in DIR/modsub or DIR/remote (for remote admin and
subscription moderation - always the same db for both
functions) or in DIR/modpost for message moderation. You can
point several lists to the same moderator db, thus using the
same moderators for several lists. NOTE: The user controlling
the list must have read/write access to the files
(specifically, must be able to write the lock file).
Some of these setups are not trivial. However, you can make
them trivial by modifying ezmlmrc so that ezmlm-make can set
up the desired lists by default or when the user uses e.g. the
'-y' or '-z' switches (see "Customizing ezmlm-make
operation").
9.2 Lists that allow remote admin, but not user initiated
subscription or archive retrieval.
Create a regular remote admin list, but remove DIR/public.
This allows moderators to (un)subscribe users and have archive
access, but rejects all user requests. Posts work as usual.
Naturally, this can be combined with message moderation or
ezmlm-issub SENDER checks (see "Restricting messages").
9.3 Lists that allow remote admin, user archive retrieval, but
not user-initiated archive subscription.
Create a regular remote admin list, remove DIR/public, and add
the '-p' [public] switch to the ezmlm-get command line in
DIR/manager. This overrides the normal DIR/public effect on
ezmlm-get and archive retrieval, allowing full archive access
to anyone, but rejecting user -help and subscription commands.
It is assumed that the users know archive retrieval commands
without help. If you want to provide specific help, just link
~/.qmail-listname-help to DIR/help, and invoke a script that
copies help info from there. See 'ezmlm-env' and 'ezmlm-env.1'
in the source directory for an example.
9.4 Lists that restrict archive retrieval to subscribers.
Use a standard list, but add the ezmlm-get '-s' command line
switch in DIR/manager. Only subscribers can receive archive
excerpts. Digests work as usual.
9.5 Lists that do not allow archive retrieval at all.
Use a standard list, but add the '-C' switch to both the
ezmlm-get and ezmlm-manage command lines in DIR/manager. No
archive retrieval commands will be honored. Digest can be
created as usual (See "restricting archive retrieval").
9.6 Lists that do not allow archive retrieval and do not allow
digest triggering per mail.
For maximal archive security, set up a normal indexed and
archived list, then remove the ezmlm-get line from DIR/manager
and add the '-C' switch to the ezmlm-manage command line. You
can still create digests by direct invocation of ezmlm-get
from a script or crontab entry. (See "Disallowing digest
triggering by mail").
9.7 Lists that allow archive retrieval only to moderators, but
allow user-initiated subscription.
Create a normal remote admin (+ subscription moderated) list,
and add the '-P' [not public] switch to the ezmlm-get command
line in DIR/manager. Subscription will not be affected, but
ezmlm-get will send archive excerpts only to moderators.
Digests are unaffected.
9.8 Lists that do not require user confirmation for
(un)subscription.
The need for a user handshake can be removed by the ezmlm-
manage -S (subscribe) and/or -U (unsub
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic