Next Previous Contents

13. Remote administration.

13.1 How can I remotely add moderators, subscriber aliases, etc?

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.

13.2 Moderating posts from a secondary account.

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.

13.3 Moderating subscription from a secondary account.

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).

13.4 Automatically approving posts or subscriptions.

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.

13.5 Allowing remote administrators to get a subscriber list.

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).

13.6 Allowing remote administrators to retrieve or search a subscription log.

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.

13.7 Allowing users to get a subscriber list.

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.

13.8 Changing the timeout for messages in the moderation queue.

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.

13.9 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(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.)

13.10 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

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 '/'.

13.11 Using different moderators for message and subscription moderation.

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.

13.12 Setting up moderated lists with the list owner as the ``super moderator'' able to add/remove moderators remotely.

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).

13.13 Customizing ezmlm administrative 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(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).

13.14 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 (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/.

13.15 Manually rejecting a message awaiting moderation.

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).


Next Previous Contents