On any list, the DIR/allow/ database can be manipulated remotely
via mail to list-allow-subscribe@listhost
, etc. The rules for
adding/removing/listing addresses to this database are the same as for the
main list. Thus, if a user on an open list wants to be able to post from
alias@al.host.com
s/he can send a message to
list-allow-subscribe-alias=al.host.com@listhost
and reply to the
confirmation request. Now, s/he can post from this address even on a
subscriber-only list and even though the address is not a real subscriber.
It can be confusing to some users that you use ``subscribe'' here, but you don't get any messages. If you explain to them that this is just another collection of addresses they will understand. You can also send the initial message on their behalf. If you are a remote admin, you can even complete the transaction adding the alias without subscriber participation.
Addresses can also be unsubscribed from the ``allow'' database. However, there is usually no good reason to do so.
If configured, the DIR/deny/ database can be manipulated, but
only by remote administrators, by mail to e.g.
list-deny-baduser=badhost@listhost
. Normal users cannot access
this database.
To remotely administrate the DIR/mod/ databases (i.e., without shell access), you need to set up a non-public, remotely administered list which ``resides'' within the DIR/mod. Please carefully consider the implications of making it possible to remotely add, remove, and list moderators. In many circumstances, this is dangerous.
After setting up your list with the specific functionality you need, use the following command for DIR/mod/:
% ezmlm-make -ePrIAl ~/list/mod ~/.qmail-list-mod joe-list-mod host
The '-l' flag is not necessary, but makes it easier to administrate your
moderator database by permitting the ``supermoderator'' to see
who is on the list.
The new list does not have a key. Using the key from the main list is inadvisable. Instead, create a dummy list, copy the key from this list to your ``moderator'' list:
% cp ~/DUMMY/key ~/DIR/mod/key
Erase the dummy list. Also, posts to this list should not be allowed. Erase
the ~/.qmail-list-mod and ~/DIR/mod/editor.
Then add the remote administrator of the ``moderator'' list:
% ezmlm-sub ~/list/mod/mod supermod@superhost
The ``supermoderator'' can now remotely administrate the moderators of the main list.
Request for moderation of posts can be forwarded to any address and acted on from that address. By default, 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 that is not listed in the moderator database. If such 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 subscription moderator to temporarily use a different address, s/he needs to forward all ``CONFIRM'' 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 allow moderator-initiated (un)subscribes without user intervention from the new address (of course, the list has to be configured for remote administration with DIR/remote).
Sometimes, 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. If you are worried, forward the messages to a (trusted) friend and ask him/her to appropriately reply to the requests.
Access to the subscriber list is sensitive. Thus, this option is disabled by default. The ezmlm-manage(1) ``-l'' command line switch enables this option, but will send a subscriber list only to a moderator's address. This allows a moderator to also initiate a subscriber list retrieval 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 Ezmlm-idx security 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(5) (see Customizing ezmlm-make operation).
This is restricted and works as the subscriber list, since it contains
information of equal sensitivity. To receive the entire log, mail
list-log@listhost
.
See
Howto get a subscription log for more details on the reply format.
As of ezmlm-idx-0.32, the subscription log also contains the
From: line contents from the user's subscribe confirmation. This usually
contains the user's name and can be helpful if the user cannot recall or
determine the subscription address. To make life easier for the remote admin,
ezmlm-idx-0.32 also supports searching the log, using exact matches for
alphanumerics and ``_'' as a wild card character. Thus, to find records
matching ``Keith John*'',
the remote admin can mail list-log.Keith_John
.
See
Howto get a subscription log for more
information.
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 (See
adding your own commands for more info.)
. The authors strongly urge against
this, since a common method for spammers to get valid
E-mail addresses from mailing lists is to exploit unrestricted -list commands.
A subscriber with questions
about who is on the list should contact the list-owner@host
. 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.
Put the time, in hours, into DIR/modtime. This value may not exceed the range of 24-120 h set at compile time by the defines in idx.h.
% 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(1) 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. (See ezmlm-check(1) and adding your own commands for examples.)
Set up a moderator dir:
% mkdir /path/moddir /path/moddir/subscribers
% touch /path/moddir/lock
% chown -R user /path/moddir
For alias:
# chown -R alias /path/moddir
For example:
% mkdir ~joe/mods ~joe/mods/subscribers
% touch ~joe/mods/lock
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).
For example:
% echo "/home/joe/mods" > ~joe/DIR/modsub
NOTE: The path must start with a '/'.
Proceed as in the previous point, but set up two different moddirs. Naturally, one of these can be DIR/mod/ (preferably the one for posts, to keep it cleaner). Then modify the appropriate files (DIR/modpost and DIR/modsub) to contain absolute paths to the correct moddir.
This is done by crating a list that has DIR/mod/ as it's main list directory, then adding the ``super moderator'' to DIR/mod/mod/ (see remotely adding moderators).
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(1) for an example).
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(5) (see Customizing ezmlm-make operation).
You can also configure the list to allow remote administrators to edit files in DIR/text/ via E-mail (see How text file editing works).
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 (change the ezmlm-send(1) path if you've installed in a non-default directory):
% cat DIR/mod/pending/filename \
% /usr/local/bin/ezmlm/ezmlm-send DIR
Alternatively, use ezmlm-accept(1). It checks the 'x' bit, ezmlm-send(1) return codes, removes the file, etc.
For example:
% ezmlm-accept ~joe/SOS ~joe/SOS/pending/*
will accept all messages in the queue of the list in ~joe/SOS/.
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(1) take care of it for you, once the message has timed out (number of hours settable within 24-240 in DIR/modtime; default 120).