File: FAQ.idx

package info (click to toggle)
ezmlm 0.53-3.1
links: PTS
area: non-free
in suites: potato
size: 2,472 kB
ctags: 1,514
sloc: ansic: 12,040; makefile: 1,224; sh: 1,217; perl: 743
file content (4731 lines) | stat: -rw-r--r-- 245,539 bytes
  EZFAQ 0.05 - ezmlm-idx and ezmlm FAQ
  Fred Lindberg, lindberg@id.wustl.edu & Fred B. Ringel,
  fredr@rivertown.net
  30-JUN-1998

  This document is a collection of frequently asked questions about
  ezmlm-idx. Where applicable, ezmlm itself is also covered. This FAQ
  presumes familiarity with Unix, and with the basic concepts of E-mail
  and mailing lists.  This FAQ is updated for ezmlm-0.53 and ezmlm-
  idx-0.31.
  ______________________________________________________________________

  Table of Contents:

  1.      General Information

  1.1.    Acknowledgements

  1.2.    What is this document?

  1.3.    Terminology

  1.4.    Where can I get all of the ezmlm-related programs?

  1.5.    Where can I find documentation for ezmlm and patches?

  1.6.    Where do I send comments on this document?

  2.      How to experiment with new versions of ezmlm-idx.

  3.      Quick start

  4.      Overview of mailing list management and mailing list managers

  5.      Overview of ezmlm function

  5.1.    The basic setup.

  5.2.    Inventions in ezmlm.

  5.3.    The qmail delivery mechanism.

  5.4.    What the different programs do.

  5.5.    What the different files in the list directory do.

  5.6.    The paper path for posts

  5.7.    The ezmlm path for moderation messages.

  5.8.    The ezmlm path for administrative messages.

  5.9.    The ezmlm path for bounces.

  5.10.   Messages to list-owner and list-digest-owner.

  5.11.   Structure of subscriber databases

  5.12.   Local case in E-mail addresses

  5.13.   Testing SENDER to insure posts are from list subscribers
  (i.e., testing against a subscriber database).

  5.14.   How cookies work

  5.15.   How moderator E-mail addresses are stored.

  5.16.   How subscription moderation works.

  5.17.   How remote administration works.

  5.18.   How message moderation works.

  5.19.   How messages are stored in the archive.

  5.20.   How the message index works.

  5.21.   How threading works

  5.22.   How digests work.

  5.23.   How sublists work.

  5.24.   How ezmlm-tstdig works.

  5.25.   How to service commands in the subject line.

  5.26.   How to support alternative command names.

  5.27.   How remote administrators can retrieve a subscriber list.

  5.28.   How text file editing works.

  5.29.   How subject line prefixes work.

  5.30.   How bounces are handled.

  5.31.   How the info and faq commands work.

  5.32.   How the global ezmlm list address works.

  6.      Automated ezmlm mailing list setup

  6.1.    Components

  6.2.    How ezmlm-make works.

  6.3.    How do I make customization simple for me/my users?

  6.4.    How ezmlm-both works.

  6.5.    How ezmlm-cron works.

  7.      Possible error conditions in ezmlm lists

  7.1.    What do I do if ezmlm doesn't work?

  7.2.    How do I report ezmlm bugs?

  7.3.    Where do I send suggestions for ezmlm-idx improvements?

  7.4.    Using ezmlm-check to find setup errors.

  7.5.    Posts are rejected: Sorry, no mailbox here by that name
  (#5.1.1).

  7.6.    Post are not sent to subscribers.

  7.7.    Subscribe fails: I do not accept messages at this address
  (#5.1.1).

  7.8.    ezmlm-make fails: usage: ezmlm-make ...

  7.9.    ezmlm-make fails: Unable to create ...

  7.10.   ezmlm-make fails: ... ezmlmrc does not exist

  7.11.   Index/get/thread requests fail quietly or with errors from
  ezmlm-manage.

  7.12.   Digest triggering requests fail.

  7.13.   Remote administration (un)subscribe confirm requests go to the
  user, not the moderator.

  7.14.   (Un)subscribers does not receive a (un)subscribe
  acknowledgement

  7.15.   Messages posted to a moderated list are sent out without
  moderation.

  7.16.   Messages posted to a moderated list do not result in
  moderation requests.

  7.17.   Moderation request replies do not result in the appropriate
  action.

  7.18.   Moderator comments with moderation request replies are not
  added to the post/sent to the poster.

  7.19.   Some headers are missing from messages in the digest.

  7.20.   My Mutt users cannot thread their digest messages.

  7.21.   Posts fail: Message already has Mailing-List (#5.7.2).

  7.22.   The last line of a

  7.23.   No CONFIRM requests are sent to moderators.

  7.24.   Deliveries fail ``temporary qmail-queue error''

  7.25.   How to deal with corrupted subscriber lists

  7.26.   Vacation program replies are treated as bounces by ezmlm

  7.27.   Digests do not come at regular hours

  7.28.   Preventing loops from misconfigured subscriber addresses.

  7.29.   A user can subscribe and receives warning and probe messages,
  but no messages from the list.

  8.      Customizing ezmlm-make operation via ezmlmrc

  8.1.    Using ezmlm-make to edit existing lists

  8.2.    What is ezmlmrc?

  8.3.    Changing defaults for

  8.4.    Changing default moderator directories.

  8.5.    Adapting ezmlm-make for virtual domains.

  8.6.    Why the ezmlm-make -c switch.

  8.7.    Setting up ezmlm-make for special situations.

  9.      Restricting message posting to the list

  9.1.    Requiring the list address in To:/Cc: headers.

  9.2.    Rejecting messages sent from other mailing lists.

  9.3.    Restricting posts based on the Subject line.

  9.4.    Restricting the size of posts.

  9.5.    Restricting posts based on MIME content-type.

  9.6.    Restricting posts to list subscribers.

  9.7.    Restricting posts to an arbitrary set of E-mail addresses
  (higher security option).

  9.8.    Completely restricting posts.

  9.9.    A general solution to restricting posts based on SENDER

  10.     Customizing outgoing messages

  10.1.   Adding a trailer to outgoing messages.

  10.2.   Adding a subject prefix to outgoing messages.

  10.3.   Adding a header to outgoing messages.

  10.4.   Adding a message number header.

  10.5.   Removing headers from outgoing messages.

  10.6.   Removing MIME parts from messages.

  10.7.   Limiting ``Received:'' headers in outgoing messages.

  10.8.   Setting ``Reply-To: list@host''.

  10.9.   Configuring the list so posts are not copied to the original
  sender.

  10.10.  Customizing ezmlm notification messages.

  10.11.  Specifying character set and content-transfer-encoding for
  outgoing ezmlm messages.

  11.     Customizing archive retrieval.

  11.1.   Specifying the format for retrieved messages.

  11.2.   Specifying the default format for digests and archive
  retrieval

  11.3.   Limiting the number of messages per -get/-index request.

  12.     Restricting archive retrieval.

  12.1.   Restricting archive access to subscribers.

  12.2.   Restricting available archive retrieval commands.

  12.3.   Restricting archive retrieval to moderators.

  12.4.   Allowing archive retrieval from a non-public list.

  12.5.   Disabling digest triggering by mail.

  13.     Customizing digests.

  13.1.   Setting up a digest list.

  13.2.   Why use cron-triggered digests and a digest code.

  13.3.   How to set up a digest code.

  13.4.   Generating daily digests.

  13.5.   Generating the first digest.

  13.6.   Generating digests after a certain time, number, or amount of
  messages.

  13.7.   Adding standard administrative information to digests.

  13.8.   Controlling the digest format.

  13.9.   Customizing bounce handling.

  14.     Remote administration.

  14.1.   How can I remotely add moderators, subscriber aliases, etc?

  14.2.   Moderating posts from a secondary account.

  14.3.   Moderating subscription from a secondary account.

  14.4.   Automatically approving posts or subscriptions.

  14.5.   Allowing moderators to get a subscriber list.

  14.6.   Allowing users to get a subscriber list.

  14.7.   Changing the timeout for messages in the moderation queue.

  14.8.   Finding out how many messages are waiting for moderation.

  14.9.   Using the same moderators for multiple lists.

  14.10.  Using different moderators for message and subscription
  moderation.

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

  14.12.  Customizing messages.

  14.13.  Manually approving a message awaiting moderation.

  14.14.  Manually rejecting a message awaiting moderation.

  15.     Sublists.

  15.1.   Sublists of ezmlm lists.

  15.2.   Sublists of non-ezmlm lists.

  16.     Migration to Ezmlm from other Mailing List Managers.

  16.1.   Basic Concepts.

  16.2.   Setting up ezmlm to respond to host-centric commands.

  16.2.1. Setting up the directory structure.

  16.2.2. Setting up the files.

  16.2.3. Setting up the

  16.3.   Commands of other mailinglist managers recognized by ezmlm.

  16.3.1. Listproc/Listserv.

  16.3.2. Majordomo.

  16.3.3. Smart-List.

  17.     Optimizing list performance.

  17.1.   Crond-generated digests for better performance.

  17.2.   Optimizing execution of ezmlm-warn(1).

  17.3.   Decreasing ezmlm-warn(1) time out to increase performance.

  17.4.   Use ezmlm without ezmlm-idx for maximum performance.

  17.5.   Not archiving to maximize performance.

  17.6.   Sublists to maximize performance.

  18.     Miscellaneous

  18.1.   How do I quickly change the properties of my list?

  18.2.   Open archived list with daily digests

  18.3.   Variations in moderation

  18.4.   Lists that allow remote admin, but not user initiated
  subscription or archive retrieval.

  18.5.   Lists that allow remote admin, user archive retrieval, but not
  user-initiated subscription.

  18.6.   Lists that restrict archive retrieval to subscribers.

  18.7.   Lists that do not allow archive retrieval at all.

  18.8.   Lists that do not allow archive retrieval and do not allow
  digest triggering per mail.

  18.9.   Lists that allow archive retrieval only to moderators, but
  allow user-initiated subscription.

  18.10.  Lists that do not require user confirmation for
  (un)subscription.

  18.11.  Lists that restrict archive retrieval.

  18.12.  Announcement lists for a small set of trusted posters

  18.13.  Announcement lists allowing moderated posts from anyone

  18.14.  Announcement lists with less security and more convenience.

  19.     Ezmlm-idx compile time options

  19.1.   Location of binaries.

  19.2.   Location of man pages.

  19.3.   Base directory of qmail-installation.

  19.4.   Short header texts, etc.

  19.5.   Arbitrary limits.

  19.6.   Command names.

  19.7.   Error messages.

  19.8.   Paths and other odd configuration items.

  20.     Multiple language support.

  20.1.   Command names.

  20.2.   Text files.

  20.3.   Multi-byte character code support

  21.     Subscriber notification of moderation events

  21.1.   General opinions

  21.2.   Users should know that the list is subscription moderated

  21.3.   Subscribers should know that posts are moderated

  21.4.   Senders of posts should be notified of rejections

  22.     Ezmlm-idx security

  22.1.   General assumptions

  22.2.   SENDER manipulation

  22.3.   ezmlm cookies

  22.4.   Lists without remote admin/subscription moderation

  22.5.   Message moderation

  22.6.   Subscription moderation

  22.7.   Remote administration

  22.8.   Remote editing of ezmlm text files.

  22.9.   Digest generation and archive retrieval

  22.10.  Convenience for security: the ezmlm-manage ``-S'' and ``-U''
  switches

  22.11.  Denial of service

  22.12.  Moderator anonymity

  22.13.  Confidentiality of subscriber E-mail addresses

  22.14.  Help message for moderators

  22.15.  Reporting security problems
  ______________________________________________________________________

  11..  GGeenneerraall IInnffoorrmmaattiioonn

  11..11..  AAcckknnoowwlleeddggeemmeennttss

  Many ezmlm users have contributed to improvements in ezmlm-idx. These
  are listed in the RREEAADDMMEE..iiddxx file in the ezmlm-idx distribution.
  Others have through questions and suggestions inspired parts in this
  FAQ, or pointed out errors or omissions. Thanks! Direct contributions
  are attributed to the respective authors in the text. Thanks again!

  11..22..  WWhhaatt iiss tthhiiss ddooccuummeenntt??

  This FAQ contains answers to many questions that arise while
  installing ezmlm, ezmlm-idx, and while setting up and managing ezmlm
  mailing lists.

  Many aspects of ezmlm are covered in several places in this FAQ. The
  early sections explain how ezmlm works. Later sections discuss how to
  deal with possible errors/problems. Subsequent sections discuss
  details of customization and list setup in a _H_O_W_T_O form. Finally,
  there are sections on information philosophy for moderated lists and
  on security aspects on ezmlm lists.

  This is an evolving document.  If you find any errors, or wish to
  comment, please do so to the authors.  This FAQ is currently aimed at
  system administrators and knowledgeable users, and heavily weighted
  towards questions specific to 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 ezmlm documentation which is identified here. If
  you have exhausted these resources, try the ezmlm and qmail mailing
  lists and their respective mailing list archives. 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.

  11..33..  TTeerrmmiinnoollooggyy

  This document uses a number of terms. Here are the meanings ascribed
  to them by the authors.

     DDIIRR
        The base directory of the list.

     SSEENNDDEERR
        The envelope sender of the message, as passed to ezmlm by qmail
        via the $SENDER environment variable.

     LLOOCCAALL
        The local part of the envelope recipient. For list-get-1@host,
        it is usually _l_i_s_t_-_g_e_t_-_1. If host is a virtual domain,
        controlled by _u_s_e_r_-_s_u_b, then local would be _u_s_e_r_-_s_u_b_-_l_i_s_t_-_g_e_t_-_1.

     mmooddddiirr
        Base directory for moderators.  Moderator E-mail addresses are
        stored in a hashed database in mmooddddiirr//ssuubbssccrriibbeerrss//. By default,
        ``moddir'' is DDIIRR//mmoodd//.

        To add or remove moderators:

          % ezmlm-sub DIR/moddir moderator@host.domain
          % ezmlm-unsub DIR/moddir moderator@host.domain

     ddoottddiirr

        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, _d_o_t_d_i_r
        is ~~aalliiaass// if ``root'' creates a list:

           # ezmlm-make ~alias/list ~alias/.qmail-list ...

     _d_o_t_d_i_r is where the ..eezzmmllmmrrcc file is expected when the ezmlm-
     make(1) ``-c'' switch is used (see ``Customizing ezmlm-make opera-
     tion'').

     eezzmmllmm bbiinnaarryy ddiirreeccttoorryy
        The directory where the ezmlm-binaries are normally stored, as
        defined at compile time in ccoonnff--bbiinn.  This is compiled into the
        programs and does not change just because you have moved the
        program.

     eezzmmllmm--ggeett((11))
        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.30
          % man ./ezmlm-get.1

     bbaasseeddiirr
        The list directory when referencing the list subscriber address
        database.  For E-mail addresses stored in a set of files within
        ddiirr//ssuubbssccrriibbeerrss//, the ``basedir'' is ``dir''.

     aaddddrreessss ddaattaabbaassee
        A collection of E-mail addresses stored in a set of files within
        the ``subscribers'' subdirectory of the basedir,
        DDIIRR//ssuubbssccrriibbeerrss//.

     mmeessssaaggee mmooddeerraattoorr
        An address to which moderation requests for posts to the list
        are sent. The moderation requests are formatted with
        ``From:''-``reject'' and a ``To:''-``accept'' default headers
        for moderator replies. A reply to the ``reject'' address leads
        to the rejection of the post. A reply to the ``accept'' address
        leads to the acceptance of the post. Any E-mail address can be a
        moderator E-mail address. Any number of moderator E-mail
        addresses can be used. If a post is sent from a moderator E-mail
        address, the moderation request is sent to that E-mail address
        only. If a post is sent from an E-mail address that is not a
        moderator, a moderation request is sent to all moderators.

        The first reply to the moderation request determines the fate of
        the message. Further requests for the action already taken are
        silently ignored, while a request for the contrary action
        results in an error message stating the actual fate of the
        message. Thus, if you want to ``accept'' the message and it has
        already been accepted, you receive no reply, but if you attempt
        to ``reject'' it, you will receive an error message stating that
        the message already has been accepted.

        Most lists are not message moderated. If they are, the owner is
        usually a ``message moderator'', sometimes together with a few
        other trusted users.

        For an announcement list, it is common to make all the
        ``official announcers'' ``message moderators''. This way, they
        can post securely and ``accept'' their own posts, while posts
        from other users will be sent to this set of ``official
        announcers'' for approval.

     ssuubbssccrriippttiioonn mmooddeerraattoorr
        An E-mail address where subscription moderation requests are
        sent. A subscription moderation request is sent after a user has
        confirmed her intention to subscribe. The subscription
        moderation request is sent to all moderators. As soon as a reply
        to this message is received, the user is subscribed and
        notified. Any E-mail address can be a subscription moderator and
        any number of subscription moderators can be used.

        Unsubscribe requests are never moderated (except when the ezmlm-
        manage(1) ``-U'' flag is used and the sender attempts to remove
        an address other than the one s/he is sending from). It is hard
        to imagine a legitimate mailing list that would want to prevent
        unsubscriptions.

     rreemmoottee aaddmmiinniissttrraattoorr
        When a remote administrator subscribes or unsubscribes a list
        member, the ``confirm'' request is sent back to the remote
        administrator, rather than to the subscriber's E-mail address.
        This allows the remote administrator to (un)subscribe any list
        member without the cooperation of the subscriber at that
        address. Any E-mail address can be a remote administrator and
        any number of E-mail addresses can be remote administrators.
        The set of E-mail addresses that are ``remote administrators''
        and ``subscription moderators'' are always the same. This set of
        E-mail addresses can be ``remote administrators'',
        ``subscription moderators'' or both.

        For most lists, the owner would be the ``remote administrator'',
        if s/he wishes to moderate messages, the owner would be the
        ``message moderator'' and if s/he wishes to moderate
        subscriptions the owner would also be the ``subscription
        moderator''.

        The list's ``message moderator(s)'' can be the same, but can
        also be set up to be completely different.

     CChhaannggiinngg lliisstt ````oowwnneerrsshhiipp''''
        Within this FAQ there are references to the need to check or
        change the list ``ownership.'' This is not a reference to the
        individual user who is the ``list-owner'', but a reference to
        the ownership of the files by your operating system which make
        up the list and reside in DDIIRR//.

        To change the ownership of DDIIRR// and everything within:

          % chown -R user DIR
          % chgrp -R group DIR

     Depending on your system/shell, it may be possible to combine these
     commands into either:

          % chown -R user.group DIR
          % chown -R user:group DIR

  11..44..  WWhheerree ccaann II ggeett aallll ooff tthhee eezzmmllmm--rreellaatteedd pprrooggrraammss??

  We have now registered ezmlm.org to make access to ezmlm-idx and
  related programs/documentation easier. www.ezmlm.org is currently an
  alias for Fred B. Ringel's www.rivertown.net/~ezmlm/ and ftp.ezmlm.org
  an alias for Fred Lindberg's ftp.id.wustl.edu.

     DDaann JJ.. BBeerrnnsstteeiinn''ss eezzmmllmm--00..5533

     +o  <ftp://koobera.math.uic.edu/pub/software/ezmlm-0.53.tar.gz>

     +o  <ftp://ftp.ezmlm.org/pub/qmail/ezmlm-0.53.tar.gz>

     +o  <ftp://ftp.ntnu.no/pub/unix/mail/qmail/ezmlm-0.53.tar.gz>

     +o  <ftp://ftp.pipex.net/mirrors/qmail/ezmlm-0.53.tar.gz>

     +o  <ftp://ftp.jp.qmail.org/qmail/ezmlm-0.53.tar.gz>

     +o  <ftp://ftp.rifkin.technion.ac.il/pub/qmail/ezmlm-0.53.tar.gz>

     +o  <ftp://ftp.mira.net.au/unix/mail/qmail/ezmlm-0.53.tar.gz>

     +o  <http://www.qmail.org/>

     eezzmmllmm--iiddxx--00..3311

     +o  <ftp://ftp.ezmlm.org/pub/patches/ezmlm-idx-0.31.tar.gz>

     +o  <ftp://gd.tuwien.ac.at/infosys/mail/qmail/ezmlm-patches/ezmlm-
        idx-0.31.tar.gz> ftp mirror in Austria.

     +o  <http://gd.tuwien.ac.at/infosys/mail/qmail/ezmlm-patches/ezmlm-
        idx-0.30.tar.gz> http access to the same mirror.

     +o  <ftp://ftp.win.or.jp/pub/network/mail/qmail/ezmlm-idx/ezmlm-
        idx-0.31.tar.gz> ftp mirror in Japan.

     TThhee llaatteesstt vveerrssiioonn ooff eezzmmllmm aanndd ppaattcchheess ttoo eezzmmllmm--iiddxx
        ezmlm-idx releases are numbered ``ezmlm-idx-0.xy[z]''.  Versions
        with the same ``x'' are backwards compatible. A change in ``x''
        signifies major changes, some of which _m_a_y require list changes
        (see README.idx). Addition of ``z'' are bug fixes only. Thus,
        ezmlm-idx-0.301 is ezmlm-idx-0.30 with known bugs fixed (but no
        other significant changes).  When available, patches are named
        ``filename-0.xy[z].diff'', where ``0.xy[z]'' corresponds to the
        release to which they apply.  When a number of bugs (or a
        significant bug) are found a bug-fix release is made
        incorporating all the patches for the previous version.

     +o  <ftp://ftp.ezmlm.org/pub/patches/>

     +o  <ftp://gd.tuwien.ac.at/infosys/mail/qmail/ezmlm-patches/> ftp
        mirror in Austria.

     +o  <http://gd.tuwien.ac.at/infosys/mail/qmail/ezmlm-patches/> http
        access to the same mirror.

     +o  <ftp://ftp.win.or.jp/pub/network/mail/qmail/ezmlm-idx/> ftp
        mirror in Japan.

     eezzmmllmmrrcc ffiilleess ffoorr ddiiffffeerreenntt llaanngguuaaggeess

     +o  <ftp://ftp.ezmlm.org/pub/patches/ezmlmrc/>

     +o  <ftp://gd.tuwien.ac.at/infosys/mail/qmail/ezmlm-
        patches/ezmlmrc/>

     +o  <http://gd.tuwien.ac.at/infosys/mail/qmail/ezmlm-
        patches/ezmlmrc/>

     +o  <ftp://ftp.win.or.jp/pub/network/mail/qmail/ezmlm-idx/ezmlmrc/>

     eezzmmllmm--iissssuubb--00..0055

     +o  <ftp://ftp.ezmlm.org/pub/patches/ezmlm-issub-0.05.tar.gz>.  An
        improved version of ezmlm-issub-0.05 is a part of ezmlm-idx.

     +o  Also via mirrors mentioned above.

     RRPPMMss aanndd SSRRPPMMSS ooff qqmmaaiill,, eezzmmllmm aanndd eezzmmllmm--iiddxx

     +o  <ftp://summersoft.fay.ar.us/pub/qmail/>

     +o  <ftp://ftp.ezmlm.org/pub/patches/>

     eezzmmllmm--sspplliitt--00..0011..ttaarr..ggzz oorr llaatteerr

     +o  <ftp://ftp.ezmlm.org/pub/patches/>.  Makes load splitting
        between hosts easier for large ezmlm lists.

     +o  Also via mirrors mentioned above.

     eezzmmllmm--ssuubbddbb--00..0011..ttaarr..ggzz oorr llaatteerr

     +o  <ftp://ftp.ezmlm.org/pub/patches/>.  A package of alternative
        subscriber database setups. Currently, only one which by using a
        different hash, allows users to be subscribed as e.g.  user-
        ext@host, and still post as user@host or user-ext2@host, when
        SENDER-based restrictions are placed on posts and archive
        retrieval. Experimental.

  11..55..  WWhheerree ccaann II ffiinndd ddooccuummeennttaattiioonn ffoorr eezzmmllmm aanndd ppaattcchheess??

     mmaann ppaaggeess
        All ezmlm component programs come with their own man pages.
        Thus, for info on _e_z_m_l_m_-_s_e_n_d, 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

     eezzmmllmm((55))
        General info on ezmlm and list directories is in eezzmmllmm..55:

          % man ezmlm

     or

          % cd ezmlm-0.53
          % man ./ezmlm.5

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

     TTeexxtt ffiilleess iinn tthhee ddiissttrriibbuuttiioonn
        ezmlm comes with a RREEAADDMMEE file with general instructions, an
        IINNSSTTAALLLL file with installation instructions, an UUPPGGRRAADDEE file for
        upgrading from a previous version and a CCHHAANNGGEESS file with
        information on changes from previous versions. ezmlm-idx comes
        with similar files suffixed with ``..iiddxx''. Most other patches or
        add-ons contain similar files and man pages and should contain
        identifying suffixes (.iss for ezmlm-issub, for example).  For a
        discussion of the authors' understanding of ezmlm security, see
        ``Ezmlm-idx security''.

     ````EEzzmmaann'''',, aann eezzmmllmm//iiddxx mmaannuuaall
        The ezmlm manual is a brief manual that is meant for list
        subscibers, list moderators and remote administrators, and as an
        introduction for list owners. It is useful even if you do not
        use ezmlm-idx. Features requiring ezmlm-idx are marked as such.
        The manual is available as a set of html files, as a text file,
        and in a ``letter'' and ``A4'' postscript version:

     +o  ezman for download <ftp://ftp.ezmlm.org/pub/patches/ezman/>

     +o  An on-line html version <http://www.ezmlm.org/>

     TThhiiss FFAAQQ
        This FAQ is built from a sgml source. It is available in the
        following formats:

     +o  A text file <ftp://ftp.ezmlm.org/pub/patches/ezfaq.txt.gz>

     +o  An on-line html version <http://www.ezmlm.org/>

     +o  Html for download
        <ftp://ftp.ezmlm.org/pub/patches/ezfaq.html.tar.gz>

     +o  A postscript (letter) version
        <ftp://ftp.ezmlm.org/pub/patches/ezfaq.ps.gz>

     +o  A postscript (A4) version
        <ftp://ftp.ezmlm.org/pub/patches/ezfaq.ps4.gz>

     +o  Via mirrors mentioned for the ezmlm-idx package.

     +o  A text version,FFAAQQ..iiddxx, included with the ezmlm-idx package.

     WWWWWW rreessoouurrcceess

        AAnn oonn--lliinnee vveerrssiioonn ooff tthhiiss FFAAQQ
           <http://www.ezmlm.org/>

        EEzzmmllmm sseettuupp gguuiiddee ((nnoott bbyy tthheessee aauutthhoorrss))
           <http://www.math.fu-berlin.de/~kesim/ezmlm/>

        GGeenneerraall qqmmaaiill aanndd eezzmmllmm iinnffoo

        +o  Dan J. Bernstein's qmail page
           <http://www.pobox.com/~djb/qmail.html>

        +o  Dan J. Bernstein's ezmlm page
           <http://www.pobox.com/~djb/ezmlm.html>

        +o  Russell Nelson's qmail page <http://www.qmail.org>

        +o  Mirrors of www.qmail.org <http://www.ISO.qmail.org>.
           Substitute your two-letter country abbreviation for ``ISO''.

        TThhee qqmmaaiill mmaaiilliinngg lliisstt aarrcchhiivvee
           <http://www.ornl.gov/cts/archives/mailing-lists/qmail/>

        TThhee eezzmmllmm mmaaiilliinngg lliisstt aarrcchhiivvee
           <http://sunsite.auc.dk/mhonarc-archives/ezmlm/>

     MMaaiilliinngg lliissttss
        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 E-mail addresses listed:

     +o  Dan Bernstein's ezmlm list: djb-ezmlm-
        subscribe@koobera.math.uic.edu

     +o  Dan Bernstein's qmail list: djb-qmail-
        subscribe@koobera.math.uic.edu

     +o  The Japanese ezmlm list: qmail-subscribe@jp.qmail.org

     +o  The Japanese qmail list: qmail-subscribe@jp.qmail.org

     +o  A ezmlm/idx digest list of djb-qmail: qmail-
        subscribe@id.wustl.edu

     +o  A ezmlm/idx sublist of djb-qmail (you can test ezmlm-idx
        commands): qmail@id.wustl.edu

  11..66..  WWhheerree ddoo II sseenndd ccoommmmeennttss oonn tthhiiss ddooccuummeenntt??

  To the authors via E-mail:

  +o  Fred Lindberg, lindberg@id.wustl.edu

  +o  Fred B. Ringel, fredr@rivertown.net

  22..  HHooww ttoo eexxppeerriimmeenntt wwiitthh nneeww vveerrssiioonnss ooff eezzmmllmm--iiddxx..

  ezmlm-idx>=0.23 writes DDIIRR//ccoonnffiigg in a standard format.  If ezmlm-
  make(1) is invoked with the ``-e'' switch and the ``DIR'' argument
  only, ezmlm-make(1) will read other arguments and ``digit'' switches
  (which are the switches that take arguments). Thus, with just:

               % ezmlm-make -ec letter_switches DIR

  you can rebuild the list, without affecting any archives, list state
  variables, etc. You will _l_o_s_e _a_n_y _m_a_n_u_a_l _c_u_s_t_o_m_i_z_a_t_i_o_n_s _t_o _y_o_u_r
  DDIIRR//tteexxtt// files.. TThhuuss,, yyoouu mmiigghhtt wwaanntt ttoo ssaavvee tthheemm ffiirrsstt,, bbeeffoorree
  iinnvvookkiinngg eezzmmllmm--mmaakkee((11)) wwiitthh tthhee ````--ee'''' sswwiittcchh..

  To test a new version of ezmlm-idx or to run several version, make the
  new version as per IINNSSTTAALLLL..iiddxx or UUPPGGRRAADDEE..iiddxx, setting ccoonnff--bbiinn to a
  new directory. You can use either the current directory or any other
  directory. If not using the current dir, you also have to:

          % make setup

  If you now edit the list using the new ezmlm-make program, the list
  will automatically be configured to use the new binaries. To change
  back to the ``default'' installation, just edit the list again, this
  time with the old ezmlm-make.

  If your system has an //eettcc//eezzmmllmmrrcc file, you may need to temporarily
  place the eezzmmllmmrrcc file for the ezmlm version you want to test in
  ddoottddiirr of the list and use the ezmlm-make(1) ``-c'' switch (see
  ``Terminology: dotdir'').

  33..  QQuuiicckk ssttaarrtt

  1. Unpack the ezmlm-0.53 distribution.

  2. Unpack the ezmlm-idx distribution.

  3. Move the ezmlm-idx files to the ezmlm-0.53 directory.

  4. Edit ccoonnff--bbiinn and ccoonnff--mmaann to reflect the target directories.

  5. build and install:

               % cd ezmlm-0.53
               % patch < idx.patch
               % make; make man
               % su
               # make setup

  6. Make a list and digest list

               % ezmlm-both ~/list ~/.qmail-list me-list host digcode me@host

  where ``me'' is your user name and ``host'' the host your list is on.

  Now, you are the owner, remote administrator, and subscriber of both
  list@host and the accompanying digest list list-digest@host. Only
  subscribers are allowed to access the archive and to post. To post to
  the list, mail to list@host. For a user to subscribe, s/he should mail
  to list-subscribe@host and for help to list-help@host.

  When a non-subscriber posts, you will be asked to approve, reject, or
  ignore the request. If you want to subscriber joe@joehost.dom, mail
  list-subscribe-joe=joehost.dom@host.

  Digests are generated about every two days, when 30 messages have
  arrived since the last digest, or when more than 64 kbytes of message
  body text has arrived. To manage the digest list, use the same
  commands as the main list, but replace ``list'' with ``list-digest''.

  For more info, read the man pages (start with ezmlm(5) and ezmlm-
  make(1)), this FAQ (FFAAQQ..iiddxx in the distribution), RREEAADDMMEE//RREEAADDMMEE..iiddxx,
  IINNSSTTAALLLL//IINNSSTTAALLLL..iiddxx, and UUPPGGRRAADDEE..iiddxx.

  44..  OOvveerrvviieeww ooff mmaaiilliinngg lliisstt mmaannaaggeemmeenntt aanndd mmaaiilliinngg lliisstt mmaannaaggeerrss

  (To be written.)

  55..  OOvveerrvviieeww ooff eezzmmllmm ffuunnccttiioonn

  55..11..  TThhee bbaassiicc sseettuupp..

  In designing ezmlm, _D_a_n _J_. _B_e_r_n_s_t_e_i_n has used the unix philosophy of
  small component programs with limited and well defined functions.
  Requests for specific functions can then be met by the addition of new
  programs.

  Thanks to the program execution mechanism Dan built into qmail, it is
  easy to execute several small programs per delivery in a defined
  sequence. It is also very easy to add shell scripts for further
  customization.

  55..22..  IInnvveennttiioonnss iinn eezzmmllmm..

  Dan J. Bernstein has written ezmlm in C. It is written for speed and
  reliability even in the face of power loss and NFS.  These features
  are augmented to a large extent by the ruggedness of the qmail (also
  by Dan) delivery mechanism (see qmail-command(8)).

  ezmlm uses some routines and techniques that still are not frequently
  seen in many mailing list managers. For example, subscriber E-mail
  addresses are stored in a hash so that searches require reading only,
  at most, 2% of the E-mail addresses.  ezmlm has a optional message
  archive, where messages are stored 100 per directory, again to allow
  more efficient storage and retrieval. Important files are written
  under a new name and, only when safely written, moved in place, to
  assure that errors do not occur.

  In addition, ezmlm has a number of new inventions. One of these is
  bounce detection, which generates an automatic warning containing
  information identifying the messages which have bounced, followed by a
  probe message to the E-mail addresses for which mail has bounced.  If
  the probe bounces, the address is unsubscribed. Thus, the system won't
  remove E-mail addresses due to temporary bounces: it takes 12 days
  after the first bounce before a warning is sent, and another 12 days
  of bounces after the warning bounce before the probe message is set.

  Another Dan J. Bernstein invention is the use of cryptographic cookies
  based on a timestamp, address, and action. These are used to assure
  that the user sending a request to subscribe or unsubscribe really
  controls the target address.  It is also used to prevent forgery of
  warning or probe messages to make it exceedingly difficult to use the
  bounce detection mechanism to unsubscribe another user.

  55..33..  TThhee qqmmaaiill ddeelliivveerryy mmeecchhaanniissmm..

  See qmail(7), qmail-local(8), qmail-command(8), envelopes(5), and dot-
  qmail(5).  Briefly, qmail having resolved the delivery address
  delivers it via the ..qqmmaaiill file that most completely matches the
  address. This file may be a link to another file, as is the case in
  ezmlm lists. qmail then delivers the message according to successive
  lines in this file forwarding it to an address, storing it, or piping
  it to a program. In the latter case, the program is expected to exit 0
  leading delivery to proceed to the next line in the ..qqmmaaiill file, or 99
  leading to success without delivery to succeeding lines. An exit code
  of 100 is a permanent error leading to an error message to the SENDER.
  An exit code of 111 is used for temporary errors, leading to re-
  delivery until successful or until the queue lifetime of the message
  has been exceeded.

  Delivery granularity is the ..qqmmaaiill file and re-deliveries start at the
  top. Thus, if the message fails temporarily at a later line, the
  delivery according to an earlier line will be repeated. Similarly,
  qmail may have made deliveries successfully according to most of the
  ..qqmmaaiill file and then fail permanently. The SENDER is informed that the
  delivery failed, but not about at which point.

  ezmlm takes advantage of these basic mechanisms to build a fast,
  efficient, and very configurable mailing list manager from a small set
  of independent programs.

  55..44..  WWhhaatt tthhee ddiiffffeerreenntt pprrooggrraammss ddoo..

  See ezmlm(5) and the man pages for the different programs (listed in
  ezmlm(5)).

  55..55..  WWhhaatt tthhee ddiiffffeerreenntt ffiilleess iinn tthhee lliisstt ddiirreeccttoorryy ddoo..

  See ezmlm(5).

  55..66..  TThhee ppaappeerr ppaatthh ffoorr ppoossttss

  Messages to the list are delivered to a ..qqmmaaiill file, usually ~~//..qqmmaaiill--
  lliissttnnaammee which is linked to DDIIRR//eeddiittoorr.  Here, the message is first
  delivered to ezmlm-reject(1) which can reject messages based on
  subject line contents, MIME content-type, and message body length. It
  also by default rejects all messages that do not have the list address
  in the ``To:'' or ``Cc:'' header. This eliminates most bulk spam. If
  the list is set up for restrictions based on envelope SENDER, the next
  delivery is to one or more instances of ezmlm-issubn(1).  If the
  messages passed this check, it is usually delivered to ezmlm-send(1)
  for distribution.  If the list is message moderated, it is instead
  delivered to ezmlm-store(1) which queues the message and sends out a
  moderation request.  ezmlm-gate(1) is used by some other setups. It
  will for message moderated lists invoke ezmlm-send(1) directly if the
  message is from a specific set of SENDERs, and in other cases ezmlm-
  store(1) to send the message out for moderation.

  If the list is configured for digests, DDIIRR//eeddiittoorr also contains an
  ezmlm-tstdig(1) line followed by an ezmlm-get(1) line. If ezmlm-
  tstdig(1) determines that the criteria are met for digest generation,
  it exits with an exit code of 0, causing the ezmlm-get(1) line to be
  executed leading to a digest mailing. Otherwise, ezmlm-tstdig(1) exits
  99, resulting in the remainder of the DDIIRR//eeddiittoorr file to be ignored
  too long. The digest is not related to the message being delivered,
  but the delivery is used to trigger execution of the relevant
  programs.

  In addition, DDIIRR//eeddiittoorr contains a number of house-keeping functions.
  These are invocations of ezmlm-warn(1) to send out bounce warnings and
  ezmlm-clean(1) to clean the moderation queue of messages that have
  been ignored. Again, these functions are not related to the specific
  message delivered, but the delivery itself is used as a convenient
  ``trigger'' for processing.

  55..77..  TThhee eezzmmllmm ppaatthh ffoorr mmooddeerraattiioonn mmeessssaaggeess..

  Replies to moderation requests are channeled to DDIIRR//mmooddeerraattoorr. This
  file contains an invocation of ezmlm-moderate(1) which invokes ezmlm-
  send(1) for accepted messages and sends out a rejection notice for
  rejected messages.  It also sends error messages if the message is not
  found or already accepted/rejected _c_o_n_t_r_a_r_y to the moderation message.
  Thus, if you accept a message already accepted, no error message is
  sent. ezmlm-clean(1) is also invoked from DDIIRR//mmooddeerraattoorr for house
  keeping.

  55..88..  TThhee eezzmmllmm ppaatthh ffoorr aaddmmiinniissttrraattiivvee mmeessssaaggeess..

  Administrative requests for both list and digest lists are captured by
  ~~//..qqmmaaiill--lliissttnnaammee--ddeeffaauulltt linked to DDIIRR//mmaannaaggeerr.  Here they are
  delivered first to ezmlm-get(1) which processed archive retrieval
  requests, exiting 99 after successful completion which causes the rest
  of the delivery lines to be ignored. If the request is not for ezmlm-
  get(1) it rapidly exits 0. This leads to invocation of ezmlm-manage(1)
  which handles subscriber database functions, help messages, and (if
  configured) editing of DDIIRR//tteexxtt// files. Again, ezmlm-warn(1) lines are
  included for bounce directory processing.

  If configured, an ezmlm-request(1) line is present. This program
  constructs valid ezmlm requests from command in the subject lines of
  messages sent to listname-request@host and exits 99. These requests
  are mailed and will then return to be processed by one of the other
  programs.

  55..99..  TThhee eezzmmllmm ppaatthh ffoorr bboouunncceess..

  Bounces to the list and list-digest are handled by DDIIRR//bboouunncceerr. The
  first delivery is to ezmlm-weed(1) which removes junk bounces. The
  second to ezmlm-return(1) which analyzes valid bounces storing the
  information in DDIIRR//bboouunnccee// for the list and DDIIRR//ddiiggeesstt//bboouunnccee// for the
  digest.  This is the information that ezmlm-warn(1) (invoked from
  DDIIRR//eeddiittoorr and DDIIRR//mmaannaaggeerr) uses and processes for automatic bounce
  handling.  ezmlm-return(1) will also unsubscribe a subscriber from
  whom a probe message has bounced.

  55..1100..  MMeessssaaggeess ttoo lliisstt--oowwnneerr aanndd lliisstt--ddiiggeesstt--oowwnneerr..

  These are processed by DDIIRR//oowwnneerr and delivered to DDIIRR//mmaaiillbbooxx by
  default. It is better to put the real owner address in this location.
  This can be done manually, via editing of eezzmmllmmrrcc, or via the ezmlm-
  make(1) -5 switch. Again, some house-keeping functions are also
  executed.

  55..1111..  SSttrruuccttuurree ooff ssuubbssccrriibbeerr ddaattaabbaasseess

  ezmlm subscriber E-mail addresses are stored within DDIIRR//ssuubbssccrriibbeerrss//
  as a hashed set of 53 files. The hash calculated from the address
  determines which of the 53 files and address is stored in. Thus, to
  find out if an address is a subscriber, ezmlm has to read at most
  about 2% of the E-mail addresses.  The hash function insures that E-
  mail addresses are reasonably evenly distributed among the 53 files.

  Addresses in the files in DDIIRR//ssuubbssccrriibbeerrss// are stored as strings
  starting with ``T'', followed by the address, followed by a zero byte.
  This is the same format as taken by qmail-queue(8) on file descriptor
  1.  Thus, subscriber lists can be directly copied to qmail without any
  further processing.
  55..1122..  LLooccaall ccaassee iinn EE--mmaaiill aaddddrreesssseess

  RFC822 states that the host part of an address must be case
  insensitive, but that case of the local part should be respected and
  the interpretation of it is the prerogative of the local machine.
  Thus, ezmlm preserves the case of the local part, but converts the
  host part to lower case. ezmlm proper also bases the hash on the case
  of the local part, so that USER@host and user@host are not (usually)
  stored in the same file.

  Locally, deliveries are most often case insensitive, i.e. mail to
  USER@host and user@host are delivered to the same mail box. A
  consequence of this is that many users use E-mail addresses with
  different case interchangeably.  The problem is that when USER@host is
  subscribed, ezmlm will not find that address in response to an
  unsubscribe request from user@host. This is even more problematic when
  E-mail addresses have been added by hand to e.g. moderator lists.

  ezmlm-idx>=0.22 changes address storage to make comparisons case
  insensitive and store E-mail addresses based on the hash of the all
  lower case address. Case is maintained for the local part. Thus, if
  USER@host is subscribed, mail is set to USER@host, but user@host is
  recognized as a subscriber and an unsubscribe request from user@host
  will remove USER@host from the subscriber list.

  To maintain backwards compatibility with old subscriber lists, a
  second lookup is made for partially upper case E-mail addresses in
  some cases. This will find USER@host subscribed with a case sensitive
  hash as well.

  If may be useful to move all old mixed case E-mail addresses to the
  ``new'' positions.  Without this, USER@host subscribed with the old
  system will be able to unsubscribe as USER@host, but not as user@host.
  After the repositioning, s/he will be successfully able to use any
  case in an unsubscribe request, e.g. UsEr@host. To do this:

       % ezmlm-list DIR | grep -G '[A-Z]' > tmp.tmp
       % xargs ezmlm-sub DIR < tmp.tmp

  This works, because subscribing an address, even if it already exists,
  will assure that it is stored with a case insensitive hash. On some
  systems, the grep ``-G'' switch need/should not be used.

  55..1133..  tteessttiinngg aaggaaiinnsstt aa ssuubbssccrriibbeerr ddaattaabbaassee))..  TTeessttiinngg SSEENNDDEERR ttoo
  iinnssuurree ppoossttss aarree ffrroomm lliisstt ssuubbssccrriibbeerrss ((ii..ee..,,

  This mode of operation is automatically set up if you specify the
  ezmlm-make(1) ``-u'' switch. Since there may be some addresses that
  should be allowed to post, but are not subscribers of list or list-
  digest, ezmlm-make(1) sets up an additional address database in
  DDIIRR//eexxttrraa//.  Use ezmlm-sub(1), ezmlm-unsub(1), and ezmlm-list(1) to
  manipulate these addresses. If the list is configured for remote
  administration (see ``How remote administration works''), you can
  add/remove addresses from the DDIIRR//eexxttrraa// database by mailing list-
  allow-subscribe@listhost and list-allow-unsubscribe@listhost,
  respectively. Other commands that access subscriber databases work in
  the same manner.

  To similarly restrict archive access, use the ezmlm-make(1) ``-g''
  switch.
  Since SENDER is under the control of a potential attacker, it is not
  secure to use tests of SENDER for anything important. However, when
  replies are always sent to SENDER (such as for archive access), a
  check of SENDER can prevent the sending of information to E-mail
  addresses not in the database.

  To test sender, use the program ezmlm-issubn(1). It will return 0
  (true for the shell, success for qmail deliveries) if SENDER is in at
  least one of a set of subscriber databases. If not, it will return 99
  (false for the shell: success, but skip remainder of ..qqmmaaiill file for
  qmail deliveries). The basedirs of the subscriber lists (i.e. the
  directories in which the ``subscriber'' dirs are located) are given as
  arguments.  ezmlm-issubn(1) can take any number of arguments.

  Thus, to permit an action if SENDER is a subscriber to the list in any
  of DDIIRR//, DDIIRR//ddiiggeesstt//, or DDIIRR//eexxttrraa// and exit silently, put the
  following into the relevant ..qqmmaaiill file:

       |/usr/bin/ezmlm-issubn DIR DIR/digest DIR/extra [...]
       |/path/action_program

  Restricting your list to posts from your subscribers is as easy as
  that. If your ezmlm binaries are in a different directory, you may
  have to modify the ezmlm-issubn(1) path.

  ezmlm-issubn(1) has a ``-n'' switch which ``negates/reverses'' the
  exit code.  To do an action if SENDER is _N_O_T a subscriber of any of
  the lists:

       |/usr/bin/ezmlm-issubn -n DIR/blacklist [dir2 ...]
       |/path/other_program

  To automatically configure the list with a blacklist address database
  in DDIIRR//bbllaacckklliisstt, use the ezmlm-make(1) ``-k'' switch. If the list is
  configured for remote administration (see ``How remote administration
  works'') and if you are a remote administrator, you can manipulate the
  ``blacklist'' database remotely by sending mail to list-deny-
  subscribe-user=userhost@listhost, etc.

  55..1144..  HHooww ccooookkiieess wwoorrkk

  Each ezmlm list has it's own ``key'' created by ezmlm-make at setup
  time.  This key is stored in DDIIRR//kkeeyy, and you can improve it by adding
  garbage of your own to it. However, changing the key will make all
  outstanding cookies invalid, so this should be done when the list is
  established.

  When ezmlm receives an action request, such as ``subscribe'', it
  constructs a cookie as a function of:

  +o  the request,

  +o  the time,

  +o  and the target address.

     The cookie and these items are then assembled into a address that
     is sent out as the ``Reply-To:'' address in the confirmation
     request sent to the subscriber. When the subscriber replies, ezmlm
     first checks if the timestamp is more than 1,000,000 seconds old
     (approx 11.6 days) and rejects the request if it is. Next, ezmlm
     recalculates the cookie from the items.  If the cookies match, the
     request is valid and will be completed. Depending on the
     circumstances, ezmlm generates an error message or a new cookie
     based on the current time and sends the target a new confirmation
     request.

  Dan has based these cookies on cryptographic functions that make it
  very unlikely that a change in any part of the cookie or the items
  will result in a valid combination. Thus, it is virtually impossible
  to forge a request even for someone who has a number of valid requests
  to analyze. Since the algorithm ezmlm uses is available, the security
  rests on the key (and the correctness of the algorithm). Anyone who
  knows the key for your lists can easily construct valid requests.

  As ezmlm-make(1) doesn't use a truly random process to generate the
  key, it is theoretically possible that someone with sufficient
  knowledge about your system can guess your key. In practice, this is
  very unlikely, and the safety of the system is orders of magnitude
  higher than that of other mechanisms that you may rely on in your list
  management and mail transport (exclusive of strong encryption, such as
  _P_G_P).

  55..1155..  HHooww mmooddeerraattoorr EE--mmaaiill aaddddrreesssseess aarree ssttoorreedd..

  Moderator E-mail addresses are stored just like ezmlm subscriber
  addresses, in a set of up to 53 files within the ssuubbssccrriibbeerrss
  subdirectory of the list's bbaasseeddiirr//.  For subscribers, the bbaasseeddiirr// is
  the list directory itself, i.e. DDIIRR//.  For moderators, the default is
  DDIIRR//mmoodd//, which can be overridden by placing a bbaasseeddiirr name (starting
  with a ``/'') in DDIIRR//mmooddssuubb, DDIIRR//rreemmoottee, or DDIIRR//mmooddppoosstt for
  subscription moderation, remote administration, and message
  moderation, respectively. This permits the use of one moderator
  database for multiple lists. _N_o_t_e_: _S_u_b_s_c_r_i_p_t_i_o_n _m_o_d_e_r_a_t_o_r_s _a_n_d _r_e_m_o_t_e
  _a_d_m_i_n_i_s_t_r_a_t_o_r_s _a_r_e _a_l_w_a_y_s _t_h_e _s_a_m_e _a_d_d_r_e_s_s_e_s_. _I_f _b_o_t_h DDIIRR//mmooddssuubb and
  DDIIRR//rreemmoottee contain paths, only the DDIIRR//mmooddssuubb path is used.

  55..1166..  HHooww ssuubbssccrriippttiioonn mmooddeerraattiioonn wwoorrkkss..

  Subscription moderation is a simple extension of the ezmlm subscribe
  mechanism. Once the user has confirmed the subscribe request, a new
  request is constructed with a _d_i_f_f_e_r_e_n_t _a_c_t_i_o_n _c_o_d_e. This is sent out
  to the moderator(s). When a moderator replies with a valid request and
  cookie combination, the user is subscribed. The user is then also
  welcomed to the list. Other moderators won't know that the request has
  already been approved. If other moderators reply to the request, no
  notification of the duplicate action is sent to the subscriber of the
  duplicate action. Ezmlm knows that this is a repeat request since the
  target address is already a subscriber.

  The moderators are not informed about the result, unless there was an
  error (subscribing a target that is already a subscriber is not
  considered an error). This cuts down the number of messages a
  moderator receives. Any list moderator knows (or _s_h_o_u_l_d know) the
  qmail/ezmlm/unix paradigm: _i_f _y_o_u_'_r_e _n_o_t _t_o_l_d _o_t_h_e_r_w_i_s_e_, _y_o_u_r _c_o_m_m_a_n_d
  _w_a_s _c_a_r_r_i_e_d _o_u_t _s_u_c_c_e_s_s_f_u_l_l_y.  This may be counterintuitive to those
  used to some other operating systems, but in our experience it doesn't
  take long to get used to the reliability and efficiency of
  U*ix/qmail/ezmlm.

  Subscription moderation is enabled by creating DDIIRR//mmooddssuubb and adding
  the subscription moderator to DDIIRR//mmoodd//:

       % ezmlm-sub DIR/mod moderator@host

  To use an alternative basedir for subscription moderators, place that
  directory name with a leading ``/'' in DDIIRR//mmooddssuubb.

  55..1177..  HHooww rreemmoottee aaddmmiinniissttrraattiioonn wwoorrkkss..

  The term ``remote administration'' is used to denote the ability of a
  list administrator to add or remove any E-mail address from the
  subscriber list without the cooperation of the user. Normally, when
  user@userhost sends a message to list-subscribe-
  other=otherhost@listhost to subscribe other@otherhost, the
  confirmation request goes to other@otherhost. However, if remote
  administration is enabled and user@userhost is a moderator, a
  confirmation request (with a different action code) is sent back to
  user@userhost instead. The reply from the administrator is suppressed
  in the welcome message sent to the new subscriber (other@otherhost).
  This protects the identity of the remote administrator.

  Remote administration is enabled by creating DDIIRR//rreemmoottee and adding the
  remote administrator E-mail address(es) to DDIIRR//mmoodd//:

       % ezmlm-sub DIR/mod remoteadm@host

  To use an alternative basedir for remote administrators, place that
  directory name with a leading ``/'' in DDIIRR//mmooddssuubb.  Remote administra-
  tors and subscription moderators databases always consist of the same
  E-mail addresses.  If both are enabled and one of DDIIRR//mmooddssuubb and
  DDIIRR//rreemmoottee contains an alternative basedir name, this basedir is used
  for both functions.  If both DDIIRR//mmooddssuubb and DDIIRR//rreemmoottee contain direc-
  tory names, the one in DDIIRR//mmooddssuubb is used for both functions.

  Remote administrators can add and remove addresses to the digest list,
  the ``allow'' list (user aliases for lists using SENDER restrictions
  on posting and archive access), and if used the ``deny'' list
  containing addresses that are denied posting rights to the list. The
  latter is easy to circumvent and intended to block errant mail robots,
  rather than human users.

  55..1188..  HHooww mmeessssaaggee mmooddeerraattiioonn wwoorrkkss..

  ezmlm-store(1), invoked in DDIIRR//eeddiittoorr, receives messages for message
  moderated lists. If DDIIRR//mmooddppoosstt does not exist, ezmlm-store(1) just
  calls ezmlm-send(1) and the message is posted to the list as if it
  were not moderated.  If DDIIRR//mmooddppoosstt exists, ezmlm-store(1) places the
  message in DDIIRR//mmoodd//ppeennddiinngg//.  It also sends a moderation request to
  all the moderators. Included with this request is a copy of the
  message.  The ``From:'' and ``Reply-To:'' E-mail addresses contain
  codes for ``reject'' and ``accept'', together with a unique message
  name (derived from the message timestamp and process id) and a cookie
  based on these items.  When a moderator replies, ezmlm-moderate(1) is
  invoked via DDIIRR//mmooddeerraattoorr.  ezmlm-moderate(1) (after verifying that
  the cookie is less that 11.6 days old), validates the request, and if
  the request is valid and the message is found in DDIIRR//mmoodd//ppeennddiinngg//, it
  carries out the requested action.

  If the request is ``reject'' the post is returned to SENDER with an
  explanation and an optional moderator comment. If the request is
  ``accept'' the message is posted to the list via ezmlm-send(1). As the
  request is processed, a stub for the message is created in
  DDIIRR//mmoodd//rreejjeecctteedd// or DDIIRR//mmoodd//aacccceepptteedd// for ``reject'' and ``accept''
  requests, respectively.

  If a valid reply is received but the message is no longer in
  DDIIRR//mmoodd//ppeennddiinngg//, ezmlm-moderate(1) looks for the corresponding stub
  in DDIIRR//mmoodd//rreejjeecctteedd// and DDIIRR//mmoodd//aacccceepptteedd//.  If the stub is found and
  the fate of the message was the one dictated by the new request, no
  further action is taken. If, however, no stub is found or the request
  and the actual message fate do not match, a notification is sent to
  the moderator. This scheme was chosen to impart a maximum of
  information with a minimum of messages. Also, it is the least
  demoralizing setup for multiple moderator lists, where it is important
  not to notify subsequent moderators that their work was in vain since
  the action of the first responding moderator has already resulted in
  processing of the message.

  If a message is not ``rejected'' or ``accepted'' it remains in
  DDIIRR//mmoodd//ppeennddiinngg// until it times out. Cleanup of both messages and
  stubs is accomplished by ezmlm-clean(1) which is invoked through both
  DDIIRR//eeddiittoorr and DDIIRR//mmooddeerraattoorr for message moderated lists. ezmlm-
  clean(1) looks at the timestamp used to generate the message/stub
  name. If it is older than 120 hours (configurable in a range of 24-240
  hours, by placing the value in DDIIRR//mmooddttiimmee) it is removed.  Unless
  suppressed with the ezmlm-clean(1) ``-R'' switch, the SENDER of the
  message is notified.

  By default, the E-mail addresses of message moderators are stored as a
  subscriber list with a basedir of DDIIRR//mmoodd//.  This can be changed to
  any other bbaasseeddiirr by placing the name of that directory with a leading
  ``/'' in DDIIRR//mmooddppoosstt.  Although the default basedirs for message
  moderation and subscription moderation/remote administration are the
  same, both the functions and actors are entirely independent.

  55..1199..  HHooww mmeessssaaggeess aarree ssttoorreedd iinn tthhee aarrcchhiivvee..

  The structure of the ezmlm list archive is described in the ezmlm(5)
  manual page.  Basically, the message is stored in DDIIRR//aarrcchhiivvee//nn//mm,
  where ``n'' is the message number divided by 100 and ``m'' the
  remainder (2 digits). The first message is stored in DDIIRR//aarrcchhiivvee//00//0011.

  55..2200..  HHooww tthhee mmeessssaaggee iinnddeexx wwoorrkkss..

  The ezmlm-idx(1) adds the option (default) of a message index to
  ezmlm.  The ``From:'' line, the subject, the author's E-mail address
  and name and the time of receipt are logged for each message as it is
  received. The subject is ``normalized'' by concatenating split lines
  and removing reply-indicators such as ``Re:''. A hash of the
  normalized subject with all white space removed is also stored.  The
  hash for any message within a thread is almost always the same and is
  used together with the order of receipt to connect a set of messages
  into a ``thread''.

  The message index is stored as DDIIRR//aarrcchhiivvee//nn//iinnddeexx, where ``n'' is the
  message number mod 100.  Thus, the directory DDIIRR//aarrcchhiivvee//5522// stores
  messages 5200 through 5299 and the file ``index'' which contains the
  index for those messages.

  The message index can be retrieved with the -index command (see ezmlm-
  get(1)). You can also retrieve a range of messages, a specific thread,
  or generate a message digest (see ezmlm-get(1)). Each of these
  commands can be disabled or restricted as desired by the list owner.

  The ezmlm-idx(1) can be used at any time to either reconstruct an
  existing index or create one an index for an existing list without
  one.

  55..2211..  HHooww tthhrreeaaddiinngg wwoorrkkss

  A ezmlm thread is just a message number-ordered set of messages with
  identical ``normalized'' subject entries. This is a very reliable
  method for threading messages. It does not rely on any variably
  present ``In-Reply-To:'' or ``References:'' headers. If the subject
  changes, the continuation becomes a separate thread very close to the
  original thread in a digest. ezmlm uses this mechanism to return
  message sets threaded and with a thread and author index, unless
  specifically told not to do so with the ``n'' format specifier.
  Naturally, lists set up without a message index (using the ezmlm-make
  ``-I'' switch) do not maintain thread information.

  55..2222..  HHooww ddiiggeessttss wwoorrkk..

  A ``digest'' is just an ordered collection of messages from a list,
  usually sent out regularly depending on the time and traffic volume
  since the last digest. Digest subscribers thus can read messages as
  ``threads'' once daily, rather than receiving a constant trickle of
  messages.

  As a major change in ezmlm-idx-0.30, the digest is no longer a totally
  separate ezmlm-list, but a part of the main list. This has security
  advantages, makes setup and administration easier, saves space, and
  allows a consistent way for subscribers of both ``list'' and ``list-
  digest'' to retrieve missed messages from a single archive.

  The digest of the list ``list'' is always called ``list-digest''. To
  set up a list with a digest, simply use the ezmlm-make(1) ``-d''
  switch. You subscribe to and unsubscribe from a digest the same way as
  for the main list, except that the request is sent to e.g. list-
  digest-subscribe@host rather than to list-subscribe@host.

  Any option such as remote admin or subscription moderation that is
  active for the list applies also to the digest list. Any restrictions
  in posts or archive retrieval set up for the list, automatically
  accept both subscribers of the main list and of the digest list.

  The changes in ezmlm-idx-0.30 allow all programs to service both list
  and list-digest functions.  All digest-specific files are stored in
  DDIIRR//ddiiggeesstt//.  Digest list subscriber addresses in
  DDIIRR//ddiiggeesstt//ssuubbssccrriibbeerrss// and digest list bounce information in
  DDIIRR//ddiiggeesstt//bboouunnccee//. Text files are shared between list and digest. To
  get the local part of the list or list-digest name in a context
  sensitive manner, use ``<#l#>'' (lower case ``L'') in the text file.
  _N_o_t_e_: _F_o_r _e_f_f_i_c_i_e_n_c_y_, _o_n_l_y _t_h_e _f_i_r_s_t _o_c_c_u_r_r_e_n_c_e _o_n _a _l_i_n_e _w_i_l_l _b_e
  _s_u_b_s_t_i_t_u_t_e_d_.

  In order to generate digest, the list needs to be archived and indexed
  (both default).  You can retrieve sets of messages from the message
  archive. Such sets are always returned to the SENDER of the request.
  ``Digests'' are a special form of such a set/request. First, there are
  no restrictions on the number of messages that can be in a digest
  (which is balanced by the requirement for a ``digest code'' that needs
  to be specified in order to create a digest based on a mailed
  request).  Second, special files (DDIIRR//ddiiggiissssuuee and DDIIRR//ddiiggnnuumm) keep
  track of the digest issue and the message number, amount, and time
  when the last digest was created.  Thus, the system is adapted to make
  it easy to create the regular collections of messages commonly
  referred to as ``digests''.

  Digest can be generated in several different ways:

     CCoommmmaanndd lliinnee
        ezmlm-get can be invoked on the command line, or via a script
        from e.g.  crond(8):

                  % ezmlm-get DIR < /dev/null

     If for some reason the digest should be disseminated via a separate
     list, the digest can be redirected to a ``target address'' with the
     ezmlm-get(1) ``-t'' switch. This may be useful if a non-standard
     digest list name is required. In this case, the list disseminating
     the digest must be set up as a sublist of the main list (see ``How
     sublists work'').

     ffrroomm DDIIRR//eeddiittoorr
        This is the default and does not require and additional setup.
        It works well with most lists. The only possible advantage is
        for very low traffic lists and for lists where it is important
        that a digest be sent out at a specific time (as DDIIRR//eeddiittoorr
        digests are triggered only when messages are received).

        In DDIIRR//eeddiittoorr, ezmlm-get(1) needs to be combined with ezmlm-
        tstdig(1) so that digests are generated only if certain criteria
        are met (in this case, more than 30 messages, 64 kbytes of
        message body or 48 hours since the latest digest). Add these
        lines after the ezmlm-send line in DDIIRR//eeddiittoorr:

                  |/usr/bin/ezmlm-tstdig -t48 -m30 -k64 DIR || exit 99
                  |/usr/bin/ezmlm-get diglist@host DIR || exit 0

     To set this up automatically when you create the list:

                  % ezmlm-make -d DIR dot local host [code]

     Again, the ezmlm-get(1) ``-t'' switch can be used for non-standard
     arrangements to redirect the digest.

     ffrroomm DDIIRR//mmaannaaggeerr
        Here ezmlm-get(1) is in it's normal place before ezmlm-
        manage(1), but a digest code is specified in the ezmlm-get(1)
        command line. To trigger digests requires a regular trigger
        messages generated from e.g. crond(8) (see below). ezmlm-make(1)
        sets up ezmlm-get(1) this way if a digest ``code'' is given as
        the 5th ezmlm-make(1) command line argument. However, you need
        to set up the trigger messages separately (see below):

                  % ezmlm-make DIR dot local host code

     To also test for message volume with this setup, generate trigger
     messages with the granularity you'd like, and add a ezmlm-tstdig(1)
     line to DDIIRR//mmaannaaggeerr. E.g., use a trigger message every 3 hours and
     the following ezmlm-tstdig(1) line before ezmlm-get(1):

                  |/usr/bin/ezmlm-tstdig -t24 -m30 -k64 DIR || exit 99

     In general, a cron-triggered digest is preferred for very large
     lists and for lists with very low traffic.  Again, the ezmlm-get(1)
     ``-t'' switch can be used for non-standard arrangements to redirect
     the digest.

     CCoommbbiinnaattiioonn sseettuuppss
        The default setup in the ezmlmrc file included in the
        distribution is the DDIIRR//eeddiittoorr triggered setup described above.
        If you in addition use ezmlm-cron(1) or crond(8) directly to
        generate trigger messages to list-dig.code@host, you can get
        regular digests (via the trigger messages and DDIIRR//mmaannaaggeerr), with
        extra digest sent when traffic is unusually high (via the ezmlm-
        tstdig/ezmlm-get limits set in DDIIRR//eeddiittoorr).  This works best
        when the time argument on the ezmlm-tstdig(1) command line is
        the same as the trigger message interval, and the other ezmlm-
        tstdig(1) parameters are set so that they are only rarely
        exceeded within the normal digest interval.

  55..2233..  HHooww ssuubblliissttss wwoorrkk..

  ezmlm uses the concept of sublists.  Sublists are regular ezmlm lists,
  except that they only accept messages from their parent list, which is
  placed in the file DDIIRR//ssuubblliisstt.

  sublists are used to split the load of a large mailing list among
  several hosts. All you need to do to set up a local sublist of e.g.
  the djb-qmail@koobera.math.uic.edu list is to create a ezmlm list, and
  put ``djb-qmail@koobera.math.uic.edu'' into DDIIRR//ssuubblliisstt of you list,
  and subscribe the sublist to the main qmail list. Now anyone can
  subscribe to your local list which handles its own bounces, subscribe
  requests, etc.  The load on the main list is only the single message
  to your local list.  The ezmlm-split package is an attempt to automate
  the distribution of subscriber requests when a list is distributed via
  a set of sublists (see ``ezmlm-split'').

  Sublists will not add their own mailing list header and they will not
  add a subject prefix. Normally, sublists will use their own message
  number, rather than that used by the main list.  With ezmlm-idx>=0.23,
  sublists that are not archived and not indexed, will instead use the
  main list message number. This way, bounce messages from the sublist
  can refer the subscriber to the main list archive. This is not done
  for indexed/archived sublists for security reasons (an attacker could
  overwrite messages in the sublist archive).

  With ezmlm-idx>=0.31, there is support for using ezmlm as a sublist of
  a mailing list run by another mailing list manager. To set this up,
  set up a normal ezmlm sublist, then edit DDIIRR//eeddiittoorr so that the _e_z_m_l_m_-
  _s_e_n_d line contains the command line option ``--hh _X_-_L_i_s_t_p_r_o_c_e_s_s_o_r_-
  _V_e_r_s_i_o_n_:'' (before DDIIRR). As the header text, you need to use a header
  that the main list manager adds to messages. Now your sublist will
  accept only messages from the main list requiring that they come from
  that list _a_n_d contain the header specified.

  ezmlm-idx>=0.31 also has added protection against subscription of the
  ezmlm list to mailing lists run by other list managers. If the _e_z_m_l_m_-
  _r_e_j_e_c_t line in DDIIRR//eeddiittoorr has ``-h'' and ``DDIIRR'' on it, ezmlm-
  reject(1) will read DDIIRR//hheeaaddeerrrreejjeecctt and reject messages that have any
  header specified in that file. See the ezmlm-reject(1) man page for
  suitable headers.

  55..2244..  HHooww eezzmmllmm--ttssttddiigg wwoorrkkss..

  ezmlm-tstdig(1) looks at DDIIRR//nnuumm and DDIIRR//ddiiggnnuumm to determine how many
  messages and how much traffic (in terms of bytes of message body) has
  arrived to the list since the latest digest. It also determines how
  much time has passed since the last digest was generated. If any of
  the criteria specified by command line switches exists, ezmlm-
  tstdig(1) exits 0, causing the invocation of the next line in the
  .qmail file. If not, ezmlm-tstdig(1) exits 99 causing qmail to skip
  the rest of the .qmail file. ezmlm-tstdig(1) looks at LOCAL to
  determine if it is invoked in the command line, in DDIIRR//eeddiittoorr, or in
  DDIIRR//mmaannaaggeerr. In the latter two cases, ezmlm-tstdig(1) verifies that
  the list local address is correct. If invoked in DDIIRR//mmaannaaggeerr, ezmlm-
  tstdig(1) exits 0 for all action requests except list-dig, so that is
  does not interfere with the normal functions of ezmlm-get(1) and
  ezmlm-manage(1).

  55..2255..  HHooww ttoo sseerrvviiccee ccoommmmaannddss iinn tthhee ssuubbjjeecctt lliinnee..

  Commands on the ``Subject:'' line should not be encouraged, since this
  does not take advantage of the flexibility of the qmail delivery
  mechanism and list setup. However, when migrating from other mailing
  list managers which use this method to issue list commands,
  configuring ezmlm to respond to such commands may be useful. In
  addition, some software manufacturers sell MUAs and mail gateways that
  are unable to correctly transport RFC822-compliant Internet mail with
  certain characters in the local part of the address.

  ezmlm-request(1) is usually invoked in DDIIRR//mmaannaaggeerr before ezmlm-get(1)
  and ezmlm-manage(1). It ignores all requests that are not for the
  list-request address. For requests to the list-request@host address,
  ezmlm-request(1) parses the ``Subject:'' line. If a ezmlm command
  address starting with the contents of DDIIRR//iinnllooccaall (e.g. list-get45) is
  on the command line, ezmlm-request(1) generates the corresponding full
  ezmlm request message. If the subject does not start with the contents
  of DDIIRR//iinnllooccaall, ezmlm-request(1) prefixes the line with the contents
  of DDIIRR//oouuttllooccaall, thereby building a complete ezmlm command. If a host
  name is specified, it must match the contents of DDIIRR//iinnhhoosstt and it
  will be replaced by the contents of DDIIRR//oouutthhoosstt which is also added if
  no host name (``@'') is found on the subject line.

  Thus, a subject of ``subscribe'' to list-request@host will be auto-
  magically rewritten as a message to list-subscribe@host.  Similarly,
  any ezmlm command or ``Reply-To:'' address can be pasted into the
  subject field and sent to list-request@host.  ezmlm-request(1) does
  not validate the command name, but invalid commands result in a
  ``help'' message in reply via ezmlm-manage(1). This allows ezmlm-
  request(1) to also service custom commands, like list-faq@host that
  you may have created for your list.

  If the ``Subject:'' is empty or does not start with a letter, ezmlm-
  request(1) will attempt to interpret the first message body line
  starting with a letter in the first position.

  When ezmlm-request(1) has successfully processed a ''request''
  command, it exits 99 to skip the rest of DDIIRR//mmaannaaggeerr.

  To set up a list to include ezmlm-request processing, use the ezmlm-
  make(1) ``-q'' switch.

  55..2266..  HHooww ttoo ssuuppppoorrtt aalltteerrnnaattiivvee ccoommmmaanndd nnaammeess..

  ezmlm-idx>=0.23 allows alternate names for all user commands. This can
  be used to e.g. make a message to _l_i_s_t_-_r_e_m_o_v_e_@_h_o_s_t to result in an
  ``unsubscribe'' action. This may help migration from other mailing
  list managers and in non-English environments. The use of aliases
  allows ezmlm to respond to new command names, while always responding
  correctly to the standard commands. If ezmlm-request(1) is used it
  will automatically be able to deal with any commands you set up for
  the list, within ezmlm or as separate programs.  See ``Multiple
  language support'' on how to set up command aliases.

  55..2277..  HHooww rreemmoottee aaddmmiinniissttrraattoorrss ccaann rreettrriieevvee aa ssuubbssccrriibbeerr lliisstt..

  A user with shell access can always manipulate subscriber lists with
  ezmlm-sub(1), ezmlm-unsub(1), and ezmlm-list(1) for the lists s/he
  owns.

  Sometimes a remote administrator requires a list of subscriber E-mail
  addresses. At the same time, the list should be kept out of the hands
  of spammers and all unauthorized entities. By default, ezmlm does not
  allow remote subscriber list retrieval.  You can enable the ``-list''
  command for remote retrieval of a subscriber list by using the ezmlm-
  make(1) ``-l'' switch or by adding the ``-l'' switch to the ezmlm-
  manage(1) line in DIR/manager. With this switch, ezmlm will permit
  retrieval of a subscriber list, but only to remote administrators.
  Subscribers cannot get the list membership, and any outsider would
  have to be able to read a remote administrator's mail to get the list.
  _N_o_t_e_: _T_h_i_s _o_p_t_i_o_n _i_s _n_o_t _f_u_n_c_t_i_o_n_a_l _u_n_l_e_s_s _t_h_e _l_i_s_t _i_s _c_o_n_f_i_g_u_r_e_d _f_o_r
  _r_e_m_o_t_e _a_d_m_i_n_i_s_t_r_a_t_i_o_n_, _i_._e_. _t_h_e _e_z_m_l_m_-_m_a_k_e_(_1_) _`_`_-_r_l_'_' _s_w_i_t_c_h_e_s _n_e_e_d _t_o
  _b_o_t_h _b_e _u_s_e_d_.

  The list returned is unsorted for efficiency reasons. You can easily
  sort it or use your mail reader to find a specific entry. The number
  of subscribers is shown at the bottom of the list. To get the number
  of subscribers from the command line, use:

               % ezmlm-list DIR | wc -l

  55..2288..  HHooww tteexxtt ffiillee eeddiittiinngg wwoorrkkss..

  If a list is set up with the ezmlm-make(1) ``-n'' switch, or the
  ``-e'' switch is added to the ezmlm-manage(1) line in DDIIRR//mmaannaaggeerr,
  ezmlm allows remote administrators to edit the text files that make up
  most of the ezmlm responses.  Of course, this will work only if remote
  administration is enabled for the list. Replies are sent only if the
  target address is a remote administrator.  Thus, ezmlm does not rely
  on SENDER (easily forged) but on the notion that only the recipient
  receives the message.  This is a reasonable assumption for remote
  administrators that receive mail on the local system.

  With this switch, ezmlm replies to the -edit command with a list of
  the files in DDIIRR//tteexxtt//.  Only files where editing seems reasonable are
  included in the list. The remote administrator can edit any file in
  DDIIRR//tteexxtt// by sending e-mail containing the new text to -edit.file
  where ``file'' is the name of the file replaced (edited). The file
  must exist and the name consist of only lower case letters and '-'.
  Any '-' (hyphen) must be substituted by a '_' (underscore). For remote
  administrator convenience, the substitution has been made in the list
  of files sent in reply to the -edit command.

  In reply to this command, ezmlm sends a message with the file and
  editing instructions. A ``cookie'' based on the date, file name, and
  contents of the file is added to the ``Reply-To:'' address. The cookie
  becomes invalid as soon as the file has been changed, or after 27
  hours, whichever is shorter.  Also, the cookie cannot be used to edit
  any other file, even if the other file has exactly the same contents.
  If you sent an edit request, and decide not to edit the file, you can
  simply delete the message.

  To apply standard changes to all your text files it is easier to edit
  ~~//..eezzmmllmmrrcc. To reset the list's text files back to their default
  contents (as specified by eezzmmllmmrrcc), use the ezmlm-make(1) ``-e''
  switch together with any other switches used to set up the list.

  55..2299..  HHooww ssuubbjjeecctt lliinnee pprreeffiixxeess wwoorrkk..

  First of all, it is against a number of RFCs to modify the
  ``Subject:'' header of messages. However, it is frequently requested
  by users who have seen it on other list managers. Second, it is many
  times worse to have a prefix that changes from message to message,
  such as a prefix with the message number.  However, a number of lists,
  especially in Japan, use this feature and in its absence these lists
  might be unable to take advantage of ezmlm. Thus, while we recommend
  against using a prefix, ezmlm-idx supports it.

  To add a subject prefix, just put the text into ddiirr//pprreeffiixx. The only
  format that makes any sense is ``list:'' or ``(list)'' or such. This
  is configured if the ezmlm-make(1) ``-x'' switch is used.

  The message number prefix is activated by putting e.g. ``(list-#)''
  into DDIIRR//pprreeffiixx. ``#'' is replaced by the message number. ezmlm
  refuses to make more drastic changes in the subject of a message. As a
  consequence, the message number prefix is added only when the subject
  does not already contain a prefix. Thus, replies will have the message
  number of the original message. Doing anything else and still
  supporting RFC2047-encoded subjects in the archive threading (much
  more important) would require decoding the subject, removing/editing
  the prefix, and re-encoding the subject. This is far too invasive.

  The entire thread can always be retrieved by sending a message to
  list-thread-x where ``x'' is the message number in the prefix of any
  message in the thread.

  55..3300..  HHooww bboouunncceess aarree hhaannddlleedd..

  Ezmlm messages are sent with a return-path that directs bounces to
  DDIIRR//bboouunncceerr and also via ``VERP'' contain information about the
  intended recipient. Thus, programs run from DDIIRR//bboouunncceerr know the
  subscriber for whom the message bounced. ezmlm-weed(1) is used to weed
  out non-informative bounces.  For others ezmlm-return(1) decides if
  the address is a subscriber.  If so, it saves the first bounce message
  and a list of bounced-message numbers. ezmlm-warn(1) executed from
  e.g. DDIIRR//eeddiittoorr goes through these bounce files. If it finds any that
  are older than 1000000 seconds (about 11.6 days) it sends a warning
  message to the subscriber. If this warning message bounces, ezmlm-
  return(1) sets up a "warning flag" for the subscriber. If ezmlm-
  warn(1) finds a warning flag older than 11.6 days, it sends a "probe"
  to the subscriber.  If ezmlm-return(1) receives a bounced probe, the
  subscriber is automatically unsubscribed.

  The ezmlm-warn(1) ``-t'' switch can be used to change the time-out (in
  days).  The ezmlm-warn(1) ``-d'' switch causes processing of ``list-
  digest'' bounces rather than ``list'' bounces. ezmlm-weed(1) and
  ezmlm-return(1) can handle bounces for either list.

  ezmlm-warn(1) also removes any files in the bounce directory that are
  older than 3 times the bounce time-out.

  55..3311..  HHooww tthhee iinnffoo aanndd ffaaqq ccoommmmaannddss wwoorrkk..

  The _-_i_n_f_o and _-_f_a_q commands simply reply with the contents of the
  DDIIRR//tteexxtt//iinnffoo and DDIIRR//tteexxtt//ffaaqq files. Edit these files directly or
  remotely (see ``How to remotely edit dir/text files'').  The
  DDIIRR//tteexxtt//iinnffoo file should start with a single line that is meaningful
  as is and describes the list. This will be used in later versions to
  allow automatic assembly of the global ``list-of-lists'' (see ``How to
  set up a global list address like majordomo@host or listserv@host'').

  55..3322..  HHooww tthhee gglloobbaall eezzmmllmm lliisstt aaddddrreessss wwoorrkkss..

  ezmlm-request(1) can be used to set up a global address, such as
  ezmlm@host which allows the user to see and interact with a number of
  different mailing lists. This is especially useful when your users are
  used to other mailing list managers, such as ``majordomo'' or
  ``listproc''. ezmlm-request(1) is set up to answer requests to the
  address (see ``How to set up a global list address like majordomo@host
  or listserv@host'').  There, it interprets the first line of the
  message body as a command. It will reply directly to ``lists'' and
  ``which'' commands. All other commands will be used to construct
  messages to the respective lists. Where other mailing list managers
  use synonyms of ezmlm commands, ezmlm-request(1) recognizes these and
  translates them to the corresponding ezmlm commands.  ezmlm-request(1)
  will build commands also of unrecognized commands. Thus, if you create
  new commands for a list, ezmlm-request(1) will automatically support
  them.

  If the user does not specify the complete list address, ezmlm-
  request(1) will attempt to complete the name. See the ezmlm-reject(1)
  man page for more info.

  Sometimes, it is desirable to have a host- or user-wide address that
  can list available mailing lists

  66..  AAuuttoommaatteedd eezzmmllmm mmaaiilliinngg lliisstt sseettuupp

  66..11..  CCoommppoonneennttss

  ezmlm lists allow almost infinite customization. The component build,
  together with the qmail delivery mechanism makes it possible to create
  any variant of list function imaginable. However, this complexity
  makes it somewhat daunting to the average user wanting to set up a
  mailing list. ezmlm-make(1) allows automated list setup, while
  permitting a large amount of configurability. ezmlm-both(1) is a shell
  script included with the distribution to demonstrate the ease with
  which complicated list setups can be achieved by regular users on a
  system. ezmlm-both(1) uses ezmlm-make(1) to establish a quite complex,
  but practical, list and digest set up. ezmlm-both(1) can be utilized
  in conjunction with ezmlm-cron(1) by a system's users to allow digest
  generation at regular intervals.  ezmlm-cron(1) is a restrictive
  interface to crond(8) which allows users to set up digest triggering
  messages on a variety of configurable schedules.

  At first glance, ezmlm-make(1) has many complicated options. However,
  these can be applied iteratively through the ezmlm-make(1) edit
  mechanism. Also, they are intended to be relatively complete so that
  execution of ezmlm-make(1) by e.g. a GUI can be used to safely set up
  and edit any list.

  66..22..  HHooww eezzmmllmm--mmaakkee wwoorrkkss..

  ezmlm-make(1) reads its command line arguments and switches, then
  creates the list directory. If the ``-e'' edit switch is not
  specified, ezmlm-make(1) will fail if the directory already exists.
  The directory argument must be an absolute path starting with a slash.
  The dot-qmail file argument, if specified, must also be absolute.

  ezmlm-make(1) next reads ezmlmrc located in the //eettcc// directory with a
  default install. If not found, the file in the ezmlm binary directory
  will be used. The second ezmlm-make command line argument specify the
  root name of the .qmail files. If the ezmlm-make(1) ``-c'' switch is
  used, ezmlm-make(1) will look in that directory for a ..eezzmmllmmrrcc file
  and use it instead. If this file does not exist, ezmlm-make(1) will
  print a warning and use the previously discussed ezmlmrc files in the
  same order. You can also use ``-C _e_z_m_l_m_r_c_._a_l_t'' to use _e_z_m_l_m_r_c_._a_l_t as
  the ezmlmrc file. Again, ezmlm-make(1) will fall back to the others
  with a warning, if the specified ezmlmrc file is not found.

  When not run in ``-e edit'' mode, ezmlm-make(1) first creates the list
  directory.  It also creates DDIIRR//kkeeyy containing the key used for cookie
  generation.

  The ezmlmrc file consists of a number of file names relative to the
  list directory, followed by conditional flags (see ezmlm-make(1) and
  the beginning of ezmlmrc for details). If all the conditional flags
  (controlled by the corresponding command line switches) are true, the
  lines that follow are entered into the named file. There are also tags
  to erase files.  Tags in the format <#X#> (where ``X'' is any number,
  except ``1'' and ``2'') are replaced by the corresponding ezmlm-
  make(1) switch argument. The ezmlm-make(1) command line arguments and
  the ezmlm binary path can be similarly substituted into the text.
  Thus, ezmlmrc controls (within reason) the entire operation of ezmlm-
  make(1). ezmlmrc is also set up so that no messages or file containing
  list state information are lost. Therefore, ezmlm-make(1) can be used
  to safely edit existing lists.

  ezmlm-make(1) will create the file DDIIRR//ccoonnffiigg. This files saves all
  the flags that were set at the last execution of ezmlm-make, as well
  as all the switch and command line arguments. When editing a list,
  only ``DIR'' and the non-default letter switches need to be specified.
  Other command line arguments and the ``digit switch'' arguments are
  read from DDIIRR//ccoonnffiigg.  To remove a digit switch, simply use it with
  two single quotes as the argument.

  You can also easily determine how a list was set up by looking at
  DDIIRR//ccoonnffiigg.

  66..33..  HHooww ddoo II mmaakkee ccuussttoommiizzaattiioonn ssiimmppllee ffoorr mmee//mmyy uusseerrss??

  All non-default switches, ezmlm-issubn(1) setups, etc, can be made
  standard for new lists by customizing the ezmlm-make(1) configuration
  file named ``eezzmmllmmrrcc''.  A default eezzmmllmmrrcc is installed in the ezmlm
  binary directory. If installed, a system-wide customized ezmlmrc file
  in //eettcc//eezzmmllmmrrcc (or symlinked from there) overrides this.  Installing
  a ~~//..eezzmmllmmrrcc file in a user dotdir and using the ezmlm-make(1) ``-c''
  switch allows further per user customization (see ``Customizing ezmlm-
  make operation'').

  66..44..  HHooww eezzmmllmm--bbootthh wwoorrkkss..

  ezmlm-both(1) is a short shell script that uses ezmlm-make(1) to
  create a ``list'' in the directory ``DIR'' specified. Digests are
  enabled, and created approximately every 48 hours. Posting and archive
  access is restricted to subscribers. An extra address database
  (``DDIIRR//eexxttrraa//'') is set up to allow posts from non-subscriber E-mail
  addresses of your choice.

  If a owner address is specified on the ezmlm-both(1) command line, the
  lists are set up for remote administration as well, with the owner
  established as the remote administrator. This address is also set up
  to receive mail to list-owner and list-digest-owner, and is subscribed
  to both lists. In addition, rejected posts from non-subscribers are
  sent to the address for moderation.  It is your choice to accept these
  messages or reject them. You can also simply ignore them, which will
  let them expire without notifying the SENDER. This way, no posts are
  automatically rejected because they are made by a SENDER which is not
  a subscriber or who is posting from a non-subscriber address, but are
  treated as if the list were message moderated. (Posts from subscribers
  are automatically posted) If you like, you can add the addresses from
  such posts to the DDIIRR//eexxttrraa// database.  Once there, posts from those
  SENDERs will be accepted automatically.

  _A_l_l _t_h_i_s _i_s _a_c_c_o_m_p_l_i_s_h_e_d _w_i_t_h _a _s_i_n_g_l_e _c_o_m_m_a_n_d_!

  Of course, SENDERs can be forged and are not a secure way to
  discriminate amongst posts. Still, they keep spam and most
  undesirables off the list. ezmlm has many options for setting up
  securely moderated lists, as described elsewhere in this FAQ.

  66..55..  HHooww eezzmmllmm--ccrroonn wwoorrkkss..

  ezmlm-cron(1) is a very restrictive interface to crond(8). It can be
  used to create digest trigger messages. If a list is set up with a
  digest code (see ezmlm-make(1) and ezmlm-get(1)) ezmlm will generate a
  digest from the list joe-sos@host sent to to subscribers of joe-sos-
  digest@dighost when receiving a message to joe-sos-dig-code@host where
  ``code'' is the digest code. ezmlm-cron(1) can be used to generate
  such messages at regular intervals.  The file eezzccrroonnrrcc is set up by
  the sysadmin and controls what trigger messages specific users may set
  up via ezmlm-cron(1).

  If you have cron access, create ~~//eezzccrroonnrrcc and simply put your host
  name on the first line and ``user:::'' (where ``user'' is replaced by
  your user name) on the second line. Alternatively, the system
  administrator has set up ezmlm-cron(1) as a user with crond(8) access.
  Usually, the ezcronrc of that use will have an entry like
  ``user:user-:host:10'' allowing ``user'' to create trigger messages
  for up to 10 lists with names starting with ``user-'' and on the host
  ``host''.

  To list the ezcronrc line controlling your use of ezmlm-cron(1):

               % ezmlm-cron -c

  To list all entries that you've created:

               % ezmlm-cron -l

  To add an entry to trigger digests from list@host every morning at
  0230:

               % ezmlm-cron -t 02:30 -i24 list@host code

  A new entry for the same list overwrites an old entry.

  To delete the entry above:

               % ezmlm-cron -d list@host

  or use ezmlm-cron to trigger messages at a different time:

               % ezmlm-cron -t 16:16 -i24 list@host code

  77..  PPoossssiibbllee eerrrroorr ccoonnddiittiioonnss iinn eezzmmllmm lliissttss

  77..11..  WWhhaatt ddoo II ddoo iiff eezzmmllmm ddooeessnn''tt wwoorrkk??

  Try to determine where the problem occurs and how to reproduce it:

  +o  Do messages to ezmlm return an error message to the sender or not?

  +o  What is/are the error message(s)?

  +o  What does ezmlm log into the mail log?

  +o  Are you using a setup with virtual domains? If so, have you
     adjusted DDIIRR//iinnllooccaall (see ``Adapting ezmlm-make for virtual
     domains'')?

  +o  Are posts sent out to the subscribers?

  +o  Are there subscribers?

  %  ezmlm-list DIR

  +o  Are there moderators?

       % ezmlm-list moddir

  where ``moddir'' is the contents of DDIIRR//rreemmoottee (for remote admin
  lists), of DDIIRR//mmooddssuubb (for subscription moderated lists) or DDIIRR//mmoodd--
  ppoosstt (for message moderation), if and only if the contents start with
  a forward slash. The default in all cases is DDIIRR//mmoodd//. If both
  DDIIRR//mmooddssuubb and DDIIRR//rreemmoottee contain directory names, the one in DDIIRR//mmoodd--
  ssuubb is used for both subscription moderation and remote admin.

  +o  Are the ownerships of all files correct, i.e. read/writable for the
     owner?

       % chown -R user DIR

  For lists under alias:

       % chown -R alias DIR

  If you use custom moderator databases, those directories and all their
  contents must also be readable for the user under which the list oper-
  ates (i.e. the user qmail changes to during the delivery).

  +o  Read the qmail log and capture relevant parts.

  +o  Did you customize the package at all? If so, try the default
     settings which are known to work.

  +o  Did you customize eezzmmllmmrrcc? Try to use the default copy (skip the -c
     switch).

  +o  Did your customization of ..eezzmmllmmrrcc fail to have an effect?
     Remember to use the -c switch. The ..eezzmmllmmrrcc file used is the one in
     ``dotdir'', i.e. the directory where the ..qqmmaaiill files go, usually,
     but NOT necessarily, the one in your home directory.

  +o  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.

  +o  Make sure to take notes of how the list was created (which flags
     you used, etc.).

  +o  use ezmlm-check(1) (see ``Using ezmlm-check to find setup
     errors'').  and compare the variables identified by ezmlm-check to
     DDIIRR//iinnllooccaall, etc. If you don't get a reply from ezmlm-check, then
     message was not delivered properly. Check your qmail setup.

  +o  Try to find your problem or a question/item close to it in the FAQ.

  +o  If this didn't resolve the problem, post to the ezmlm 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.

  77..22..  HHooww ddoo II rreeppoorrtt eezzmmllmm bbuuggss??

  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 it can be
  reproduced by third parties. Include relevant sections of mail log,
  and information about any error messages returned. If you ran into a
  problem and resolved it on your own, 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 mailing list or the authors.

  77..33..  WWhheerree ddoo II sseenndd ssuuggggeessttiioonnss ffoorr eezzmmllmm--iiddxx iimmpprroovveemmeennttss??

  E-mail to lindberg@id.wustl.edu, ideally with a context diff.  For
  ezmlm proper, djb-ezmlm@koobera.math.uic.edu may be better.

  77..44..  UUssiinngg eezzmmllmm--cchheecckk ttoo ffiinndd sseettuupp eerrrroorrss..

  ezmlm-check(1) is included in the ezmlm-idx distribution. ezmlm-
  check(1) is an evolving shell script which when put into a ..qqmmaaiill file
  of a mailing list will return information about the environment
  variables passed by qmail to ezmlm as well as the list setup. It also
  attempts to check for common error conditions, such as HOST and
  DDIIRR//iinnhhoosstt mismatch, missing files, etc. To use ezmlm-check(1), place
  a line:

       |/usr/bin/ezmlm-check 'DIR'

  where ``DIR'' is the list directory, as the first line in DDIIRR//eeddiittoorr
  (for mail to list), DDIIRR//mmaannaaggeerr (for mail to list-subscribe, list-
  help, etc), DDIIRR//mmooddeerraattoorr (for mail to list-accept, list-reject).
  ezmlm-check(1) will send its output to SENDER. The rest of the ..qqmmaaiill
  file will be ignored.  If you use a non-standard ezmlm binary direc-
  tory, change the ezmlm-check(1) path accordingly.

  ezmlm-check(1) in combination with mail logs and ezmlm error messages
  should make it easy to diagnose setup problems. When done, don't
  forget to remove the ezmlm-check(1) line. It is not security-proofed
  against SENDER manipulation and with it in place, the list won't work.

  ezmlm-check(1) does not check all aspects of list generation, but
  catches all common errors when lists are created with ezmlm-make(1),
  an many other errors as well. The ezmlm-check(1) reply is also very
  valuable for support via E-mail.

  77..55..  PPoossttss aarree rreejjeecctteedd:: SSoorrrryy,, nnoo mmaaiillbbooxx hheerree bbyy tthhaatt nnaammee
  ((##55..11..11))..

  qmail tried 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 (..//qqmmaaiill--lliisstt, ..//qqmmaaiill--lliisstt--ddeeffaauulltt, etc) in
  the home directory of user.  Check to see if these exist and the list
  files have the proper permissions and ownerships. Make sure that they
  are symlinked to DDIIRR//eeddiittoorr, DDIIRR//mmaannaaggeerr, etc. If used, make sure
  //vvaarr//qqmmaaiill//uusseerrss//aassssiiggnn is properly set up to deliver the mail to the
  right user. Double check your general qmail setup too. This error may
  not be an ezmlm error, but a qmail one.

  A common reason is that you have a virtual domain ``vdom.org''
  controlled by the user _v_u_s_e_r.  If you want to set up the list
  homes@vdom.org, the ``local'' on the ezmlm-make(1) command line should
  be ``homes'', not ``vuser-homes''. If you used the latter, you will
  get a ``Sorry, no mailbox ...'' error for your subscription
  confirmations and a ``help'' message in reply to list posts (see
  ``Adapting ezmlm-make for virtual domains'').

  77..66..  PPoosstt aarree nnoott sseenntt ttoo ssuubbssccrriibbeerrss..

     NNoonn--mmooddeerraatteedd lliissttss

        1. Read the qmail log. Is your message delivered to the list?
           You can also:

             % cat DIR/num

        2. Send a message to the list.

        3. See if it was received/processed:

             % cat DIR/num

        If the number was incremented, the message went to the list, and
        was successfully sent out in the opinion of ezmlm-send(1)
        (ezmlm-send(1) doesn't mind if there are no subscribers).

     MMeessssaaggee mmooddeerraatteedd lliissttss

        1. Check number of queued messages awaiting moderation:

        % ls -l DIR/mod/pending

        2. Send a message to the list.

        3. Check if another message was added to the queue:

             % ls -l DIR/mod/pending

        A new file should have appeared. If this file has the owner exe-
        cute bit set, it was successfully processed by ezmlm-store(1).
        If this is true, but no moderation request was sent, then con-
        tinue with ``Messages posted to the list do not result in moder-
        ation requests''. If there is no new file, the message did not
        reach ezmlm-store(1), or ezmlm-store(1) failed early. In both
        cases, the mail log should tell you more.

        If the message is there, but the owner execute bit is not set,
        ezmlm-store(1) failed.  Check the mail log. Possible reasons
        include a failure to find the ezmlm-send(1) binary or DDIIRR//mmssgg--
        ssiizzee is specified and the message body size is outside of the
        allowed range (again, this is accompanied by an error message
        and mail log entry).

     GGeenneerraall

        1. If the message was not received/processed, there should be an
           error message in the mail log.

        2. Fix temporary and permanent errors with the help of qmail and
           ezmlm documentation.

        3. If there is no log entry at all, then the mail went to
           another host. Check your qmail setup.

        4. 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 to the list), the most common error is
           that there are no subscribers.  In this case, ezmlm-send(1)
           sends a message from list-help@host, and logs success, but no
           recipients are logged. To qmail, it is perfectly acceptable
           to send a message without recipients, so no error message is
           logged.

        5. Check subscribers:

                     % ezmlm-list DIR

        6. Assure that ownerships are correct on the list directories:

                     % chown -R user DIR

        For lists owned by the ``alias'' user (in ~alias):

                     % chown -R alias DIR

        7. Most other problems should be easily corrected with the help
           of the qmail log.

  77..77..  SSuubbssccrriibbee ffaaiillss:: II ddoo nnoott aacccceepptt mmeessssaaggeess aatt tthhiiss aaddddrreessss
  ((##55..11..11))..

  This error occurs because the local part of the recipient address (as
  passed in the environment variable ``LOCAL''; e.g. user-list-
  subscribe) does not start with the contents of DDIIRR//iinnllooccaall (e.g. user-
  list).  The most common cause of this problem is that ezmlm-make(1)
  was used without customization to set up a list controlled via a
  virtual domain, or that ezmlm-make was used with incorrect command
  line arguments. If ``djb'' is an alias for the user ``donny'', a list
  set up as djb-list@host will reject subscription requests to donny-
  list-subscribe@host, even though the will be delivered to the same
  address as a djb-list-subscribe@host request.

  If the list name is ``list'' and the user controlling the virtual
  domain ``domain.dom'' is ``user'', run ezmlm-make(1) with list name
  ``list'' and host ``domain.dom'', then edit DDIIRR//iinnllooccaall to be ``user-
  list'' rather than ``list''. Alternatively, create a local ..eezzmmllmmrrcc
  file for that virtual domain, and edit the DDIIRR//iinnllooccaall setup (see
  ``Customizing ezmlm-make operation'').

  Another potential source of the problem are mistyped ezmlm-make
  arguments, such as the host name.  It is also possible that address
  rewriting leaves the recipient host name (as passed in the environment
  variable ``HOST'') different from the name specified in DDIIRR//iinnhhoosstt.

  In general, these problems are easy to diagnose with the ezmlm-
  check(1) script (See ``Using ezmlm-check to find setup errors'').

  77..88..  eezzmmllmm--mmaakkee ffaaiillss:: uussaaggee:: eezzmmllmm--mmaakkee ......

  The command line you specified is incomplete. Usually, a command line
  argument has been omitted or a switch was placed after the other
  arguments rather than before.

  The same error is issued when you attempt to invoke ezmlm-make(1) with
  only the ``DIR'' argument without using the ``-e'' switch. Other
  command line arguments can be omitted only when editing lists created
  or previously edited with ezmlm-make from ezmlm-idx>=0.23.

  77..99..  eezzmmllmm--mmaakkee ffaaiillss:: UUnnaabbllee ttoo ccrreeaattee ......

  This error occurs when ezmlm-make is used to set up a list, and it
  tries to create a directory or a ..qqmmaaiill--lliisstt link that already exists.
  Usually, this occurs because the list already exists. If you are
  creating a new list, first erase remnants of any old test lists by
  deleting the list directory and the link files: _N_O_T_E_: _D_O _N_O_T _U_S_E _T_H_E_S_E
  _C_O_M_M_A_N_D_S _W_I_T_H_O_U_T _U_N_D_E_R_S_T_A_N_D_I_N_G _T_H_E_M_.  You may erase more than you
  intended!

  % rm -rf DIR
  % rm -rf ~/.qmail-list ~/.qmail-list-*

  If you want to save some files (such as in DDIIRR//tteexxtt//), make backup
  copies first, run ezmlm-make, then copy the backups to DDIIRR//tteexxtt//. Of
  course, it is usually easier to create a custom and than use that for
  all your lists.

  To use ezmlm-make(1) to modify an existing list, without changing the
  subscriber or moderator lists or the message archive, use the ezmlm-
  make ``-e'' switch. NOTE: any customization that you've made that is
  not specified by the eezzmmllmmrrcc file used will be overwritten. For
  instance, if you manually added checks to DDIIRR//eeddiittoorr, a pointer to a
  custom moderator database in e.g.  DDIIRR//mmooddssuubb, or made a change to a
  DDIIRR//tteexxtt// file (such as adding a ``welcome'' message to DDIIRR//tteexxtt//ssuubb--
  ookk) these changes will be lost.  To retain such changes (especially
  ones that are common for several of your lists), place them in a local
  ~~//..eezzmmllmmrrcc file instead. You can either make such changes the default
  for your lists, or you can configure ~~//..eezzmmllmmrrcc so that they are added
  only if a specific ezmlm-make switch is used.  (see ``Customizing
  ezmlm-make operation'').

  77..1100..  eezzmmllmm--mmaakkee ffaaiillss:: ...... eezzmmllmmrrcc ddooeess nnoott eexxiisstt

  There is no readable ezmlmrc file in //eettcc// or the ezmlm binary
  directory. If you have ..eezzmmllmmrrcc in ``dotdir'' (see ``Terminology:
  dotdir'') use the ezmlm-make(1) ``-c'' switch (see ``Customizing
  ezmlm-make operation'').

  77..1111..  IInnddeexx//ggeett//tthhrreeaadd rreeqquueessttss ffaaiill qquuiieettllyy oorr wwiitthh eerrrroorrss ffrroomm
  eezzmmllmm--mmaannaaggee..

  Make sure this is an indexed list and has an ``ezmlm-get'' line first
  in DDIIRR//mmaannaaggeerr. If not, your commands are fed directly to ezmlm-
  manage(1). 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 followed by ``-'' and arguments. Thus, list-gugu-54@host
  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.

  77..1122..  DDiiggeesstt ttrriiggggeerriinngg rreeqquueessttss ffaaiill..

  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.

  77..1133..  RReemmoottee aaddmmiinniissttrraattiioonn ((uunn))ssuubbssccrriibbee ccoonnffiirrmm rreeqquueessttss ggoo ttoo tthhee
  uusseerr,, nnoott tthhee mmooddeerraattoorr..

  Either the list is not set up for remote administration (i.e.
  DDIIRR//rreemmoottee 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(1) 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
  DDIIRR//rreemmoottee. If you are using a non-default moderator db location, make
  sure that the moddir name is in DDIIRR//rreemmoottee (for remote admin only) or
  DDIIRR//mmooddssuubb (if there is subscription moderation as well). In both
  cases, the contents will be ignored unless they start with a ``/''.

  77..1144..  ((UUnn))ssuubbssccrriibbeerrss ddooeess nnoott rreecceeiivvee aa ((uunn))ssuubbssccrriibbee aacckknnoowwlleeddggee--
  mmeenntt

  With normal ezmlm lists, a subscriber confirming a subscription or a
  non-subscriber confirming a unsubscribe request results in a message
  to the target address. This message is suppressed when the list is set
  up for subscription and/or remote administration. This is done so that
  confirmations from multiple moderators do not result in multiple
  messages to the target address. The target address is always notified
  if the subscriber status of the address changes (from non-subscriber
  to subscriber or vice versa).

  77..1155..  MMeessssaaggeess ppoosstteedd ttoo aa mmooddeerraatteedd lliisstt aarree sseenntt oouutt wwiitthhoouutt mmooddeerr--
  aattiioonn..

  The list is not set up as a moderated list. Check DDIIRR//eeddiittoorr.  If
  should contain a ezmlm-store(1) line after the ezmlm-reject line if it
  is a moderated list. No ezmlm-send(1) line should be in DDIIRR//eeddiittoorr.
  If there is, the list is not moderated. Also, DDIIRR//mmooddppoosstt must exist.
  If it does not, ezmlm-store(1) will post the messages directly (via
  ezmlm-send(1)) without sending them out for moderation first. This
  makes it easy to temporarily remove message moderation by simply
  removing DDIIRR//mmooddppoosstt, but may be confusing if the user is unaware of
  this ezmlm-store(1) feature.

  77..1166..  MMeessssaaggeess ppoosstteedd ttoo aa mmooddeerraatteedd lliisstt ddoo nnoott rreessuulltt iinn mmooddeerraattiioonn
  rreeqquueessttss..

  +o  Check that ~~//..qqmmaaiill--lliisstt is a link to DDIIRR//eeddiittoorr.

  +o  Check that DDIIRR//eeddiittoorr contains ezmlm-store(1) and not ezmlm-
     send(1).  If this is not the case, the list is not message
     moderated.

  +o  Check for the presence of DDIIRR//mmooddppoosstt. If this file is missing, the
     list is not moderated, even if DDIIRR//eeddiittoorr is set up with ezmlm-
     store(1).

  +o  Check qmail logs for error conditions during post delivery and
     correct these. If the messages are delivered correctly, verify that
     ezmlm-store(1) generated the moderation requests to the moderators.

  +o  Check to see that there are indeed moderators:

       % ezmlm-list moddir

  where ``moddir'' is the contents of DDIIRR//mmooddppoosstt if they start with a
  ``/'', otherwise those of DDIIRR//rreemmoottee (same ``/'' requirement), and
  DDIIRR//mmoodd// by default.

  +o  Check file ownerships.

     Another common problem is directory ownerships, especially for
     lists under ~alias. To correct this error, issue the following
     command while in the ~alias directory (User the user/group of the
     list owner; for ~alias lists user=alias, group=qmail):

       % chown -R user DIR

  77..1177..  MMooddeerraattiioonn rreeqquueesstt rreepplliieess ddoo nnoott rreessuulltt iinn tthhee aapppprroopprriiaattee
  aaccttiioonn..

  +o  Check that the address in the moderation request is correct.

  +o  Check that the ~~//..qqmmaaiill--lliisstt--aacccceepptt--ddeeffaauulltt and ~~..//qqmmaaiill--lliisstt--
     rreejjeecctt--ddeeffaauulltt links exists and point to DDIIRR//mmooddeerraattoorr.

  +o  Check that DDIIRR//mmooddeerraattoorr invokes ezmlm-moderate(1), and that there
     is a copy of ezmlm-send(1) in the ezmlm binary directory.

  +o  Check the qmail log to see that the replies were delivered to this
     address.

  +o  Check directory ownerships. For lists under alias:

       % chown -R alias DIR

  _N_O_T_E_: This needs to be done every time you add/remove moderators as
  ``root''. For user-controlled lists (i.e. you are ``user'' when run-
  ning e.g. ezmlm-sub(1)) this is not a problem.

  If setting up lists for _a_l_i_a_s, you can avoid many problems by setting
  them up as ``alias'', i.e. use ``su alias'' not ``su''.

  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.

  +o  Check the qmail logs: After the delivery of the moderation request,
     ezmlm-send(1) should run to send messages to all the list
     subscribers.

  +o  Make sure there are list subscribers:

       % ezmlm-list DIR

  Most error conditions, incorrect request cookies, etc, should result
  in informative error messages in the mail log.

  77..1188..  MMooddeerraattoorr ccoommmmeennttss wwiitthh mmooddeerraattiioonn rreeqquueesstt rreepplliieess aarree nnoott
  aaddddeedd ttoo tthhee ppoosstt//sseenntt ttoo tthhee ppoosstteerr..

  Moderator comments are where the moderator chooses to ``reject'' the
  message and inform the person posting which his/her message was
  inappropriate.  However, if a moderator wants to comment on accepted
  posts, the moderator may only do so via a follow-up post to the list.
  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(ed)'' posts need to be enclosed
  between two lines (yes, the end marker is required), having ``%%%''
  starting on one of the first 5 positions of the line. If there are
  characters before the marker, these will be removed from any comment
  line that starts with the same characters (e.g. the characters before
  ``comment2'' in the example below will be removed):

  %%%
  comment
  %%%

  or:

  > %%%
  comment
  > comment2
  > %%%

  but not:

  %%
  COMMENT
  %%

  and not:

  %%% this is my comment %%%

  or

  ezmlm said>%%%
  comment
  ezmlm said>%%%

  77..1199..  SSoommee hheeaaddeerrss aarree mmiissssiinngg ffrroomm mmeessssaaggeess iinn tthhee ddiiggeesstt..

  By default, only a subset of message headers are sent out in any
  digest and archive retrieval requests. First, headers in
  DDIIRR//hheeaaddeerrrreemmoovvee are stripped. Most non-essential headers are excluded
  when the default archive retrieval format (``m'') is used.  Use the
  ``v'' or ``n'' format (see ezmlm-get(1)) to get all message headers
  that are in the archive.
  77..2200..  MMyy MMuutttt uusseerrss ccaannnnoott tthhrreeaadd tthheeiirr ddiiggeesstt mmeessssaaggeess..

  The digest by default removed non-essential headers like ``In-Reply-
  To:'' from messages. Modern MUAs, like _M_u_t_t can split out messages
  from a digest and then thread them based on such headers. To include
  these and all other headers in the digest messages, use the ``v'' or
  ``n'' format as described on the ezmlm-get(1) man page. Normally, the
  threading done by ezmlm is sufficient and the default format preferred
  to reduce message and digest size.

  77..2211..  PPoossttss ffaaiill:: MMeessssaaggee aallrreeaaddyy hhaass MMaaiilliinngg--LLiisstt ((##55..77..22))..

  The list you are trying to post to is used as a sublist (a list fed
  with messages from another (ezmlm) list), but not properly set up as a
  sublist. Put  the name of the parent list (``origlist@orighost'')
  which exactly matches the SENDER of the original (or parent) list into
  DDIIRR//ssuubblliisstt.  Check the ownership of DDIIRR//ssuubblliisstt, to make sure that
  the user controlling the list can read it.

  Alternatively, use the ezmlm-make(1) ``-0 origlist@orighost'' switch
  (see ``Customizing ezmlm-make operation'').

  77..2222..  TThhee llaasstt lliinnee ooff aa DDIIRR//tteexxtt// file is ignored.

  Only complete lines ending with ``newline'' are copied. The last line
  in the DDIIRR//tteexxtt// file most likely lacks a terminal ``newline''.

  77..2233..  NNoo CCOONNFFIIRRMM rreeqquueessttss aarree sseenntt ttoo mmooddeerraattoorrss..

  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 note saying so) or
  the list is subscription

  moderated by no moderators have been added (ezmlm-manage(1) 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 ``DDIIRR//mmoodd//''.

  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 ownerships for the moderator db:

       % chown -R user moddir

  For ~alias:

        # chown -R alias 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.

  77..2244..  DDeelliivveerriieess ffaaiill ````tteemmppoorraarryy qqmmaaiill--qquueeuuee eerrrroorr''''

  Usually, this is due to a corrupted qmail queue (should affect all
  mail) or a corrupted ezmlm subscriber database (See ``How to deal with
  corrupted subscriber lists'').

  77..2255..  HHooww ttoo ddeeaall wwiitthh ccoorrrruupptteedd ssuubbssccrriibbeerr lliissttss

  Dan has made ezmlm very robust, but a subscriber list can still become
  corrupted due to e.g. disk errors. Usually, this will lead to a
  ``temporary qmail-queue error'' because an address does not conform to
  the standard format. Occasionally, two E-mail addresses are fused,
  e.g.  ``addr1@hostTaddr2@host''.  To diagnose and fix this type of
  error, disable deliveries (easiest is to ``chmod 0 DIR/lock''), back
  up the contents of DDIIRR//ssuubbssccrriibbeerrss//, then:

       % ezmlm-list DIR > tmp.tmp

               ( edit tmp.tmp to fix any problems )

       % rm -rf DIR/subscribers/*
       % xargs ezmlm-sub DIR < tmp.tmp

  This will list all E-mail addresses, allow you to edit them, then re-
  subscribe them.  Don't forget to re-enable deliveries.

  77..2266..  VVaaccaattiioonn pprrooggrraamm rreepplliieess aarree ttrreeaatteedd aass bboouunncceess bbyy eezzmmllmm

  Standard vacation programs do not reply to messages that contain a
  ``Precedence: bulk'' header. ezmlm-idx>=0.23 sets up lists with this
  header in DDIIRR//hheeaaddeerraadddd. For older lists, use ``ezmlm-make -e'' to
  update them, or just add a ``Precedence: bulk'' line to DDIIRR//hheeaaddeerraadddd.

  77..2277..  DDiiggeessttss ddoo nnoott ccoommee aatt rreegguullaarr hhoouurrss

  In the default setup, ezmlm-tstdig(1) determines if a new digest is
  due every time a message arrives to the list. Thus, even though ezmlm-
  tstdig is set to produce digests 48 hours after the previous digest,
  the digest will not be generated until a message arrives. If you'd
  like digests at a specific time each day, use cron or the ezmlm-cron
  cron interface:

               % ezmlm-cron -t 08:00 -i24 list@host digcode

  77..2288..  PPrreevveennttiinngg llooooppss ffrroomm mmiissccoonnffiigguurreedd ssuubbssccrriibbeerr aaddddrreesssseess..

  Occasionally, a subscriber address is misconfigured and automatically
  sends a message back to the list. Sometimes, the subscriber's setup
  has removed headers that ezmlm uses for loop detection or the
  generated messages has nothing in common with the sendout. To block
  such mail at the list, include the ezmlm-make(1) ``-k'' (kill) switch
  and add the offending address to DDIIRR//bbllaacckklliisstt// with

               % ezmlm-sub DIR/blacklist badadr@badhost

  ezmlm-unsub(1) and ezmlm-list(1) can be used similarly to remove or
  list the addresses. If your list is configured for remote administra-
  tion (see ``How remote administration works''), and you are a remote
  administrator, you can add the address by sending mail to list-deny-
  badadr=badhost@listhost. Other subscriber database commands work as
  well for list-deny.

  In other instances, a configuration error somewhere close to the
  subscriber creates a local mail loop throwing off messages to you.
  They are often bounces that are sent to the list address or to ``list-
  help'' due to configuration errors. Rather than accepting these, or
  the often resulting double bounces to ``postmaster'', just add a
  ``|/path/ezmlm-weed'' line first to DDIIRR//eeddiittoorr or DDIIRR//mmaannaaggeerr. This
  discards the bounce messages generated by the looping systems. ezmlm-
  weed(1) is also useful in other settings where excessive numbers of
  error messages are sent to the wrong address.

  77..2299..  AA uusseerr ccaann ssuubbssccrriibbee aanndd rreecceeiivveess wwaarrnniinngg aanndd pprroobbee mmeessssaaggeess,,
  bbuutt nnoo mmeessssaaggeess ffrroomm tthhee lliisstt..

  ezmlm lists (ezmlm-idx>=0.31) remove ``Received:'' headers from
  incoming messages by default. This can be prevented with the ezmlm-
  send(1) ``-r'' switch.  When the headers are propagated, especially
  sublist message may have many (15-20 or more), ``Received:'' headers.
  If there is a poorly configured sendmail host with a ``hopcount'' set
  too low, it will bounce these messages, incorrectly believing that the
  many ``Received:'' headers are due to a mail loop.  The reason that
  administrative from the list do not bounce is that they have fewer
  ``Received:'' headers, since they originate from the sublist.

  The message with all headers including the removed ``Received:''
  headers can be retrieved from the list archive with the _-_g_e_t_v command.
  The top incoming ``Received:'' header is added by qmail at the receipt
  to the list (or last sublist) host. This header is not removed, to
  allow the recipient to determine when the message reached the list.

  88..  CCuussttoommiizziinngg eezzmmllmm--mmaakkee ooppeerraattiioonn vviiaa eezzmmllmmrrcc

  88..11..  UUssiinngg eezzmmllmm--mmaakkee ttoo eeddiitt eexxiissttiinngg lliissttss

  With ezmlm-make(1) (from ezmlm-idx >=0.21) you can use the ``-e''
  switch to edit existing lists.  Invoke the ezmlm-make(1) command just
  as you would to create the list anew, but change the switches to
  reflect the desired change, and add the ``-e'' switch. ezmlm-make will
  accept preexisting directories and overwrite or remove files to change
  the setup.  The message counter (DDIIRR//nnuumm), digest counters (DDIIRR//ddiiggnnuumm
  and DDIIRR//ddiiggiissssuuee), the key (DDIIRR//kkeeyy) and the message archive will not
  be affected.

  If the list has been created or previously edited with ezmlm-make(1)
  from ezmlm-idx>=0.23, the list remembers (via DDIIRR//ccoonnffiigg) the
  arguments and the switches taking arguments (``digit'' switches). All
  you have to specify is the ``letter'' switches, ``digit'' switches you
  wish to change, and the list directory.

  _N_O_T_E_: ezmlm-make(1) ``-e'' will OVERWRITE any manual customizations
  you have made to the list after creating it! To make general
  customizations, please change eezzmmllmmrrcc (see ``What is ezmlmrc?''  or
  read on) instead and use the ``-c'' switch as well. DO NOT use this
  option to change production lists without testing it on other lists
  first.  Also, for some changes, removing or adding a flag is
  sufficient (see ``How do I quickly change properties of my list'').

  88..22..  WWhhaatt iiss eezzmmllmmrrcc??

  ezmlm-make(1) has a number of default switches that through eezzmmllmmrrcc
  have defined functions. These allow creation of many standard lists.

  In addition, ezmlm-make(1) operation is fully customizable via
  modification of the template file, ezmlmrc or .ezmlmrc. A default
  ezmlmrc is installed in the ezmlm binary directory.  The system
  administrator can install a system-wide default eezzmmllmmrrcc file in
  //eettcc//eezzmmllmmrrcc (or symlinked from there) which overrides the file in the
  ezmlm binary directory. If the ezmlm-make(1) ``-c'' (custom) switch is
  used, ezmlm-make(1) will look for ..eezzmmllmmrrcc in the ``dotdir'', i.e. the
  directory in which the ..qqmmaaiill--lliisstt links are placed. This is usually a
  set directory for a given user/virtual domain (usually, the home
  directory for the user controlling the lists).

  eezzmmllmmrrcc controls everything except creation of the list directory
  itself and the key used for cookie generation. The syntax of eezzmmllmmrrcc
  is documented in ezmlm-make(1) and in the ezmlmrc file installed in
  the ezmlm binary directory. ezmlm-make limits its effects to within
  the list ``dot'' and ``DIR'' directories. In the ``dotdir'', only
  links to within ``DIR'' can be created.

  88..33..  CChhaannggiinngg ddeeffaauullttss ffoorr DDIIRR//tteexxtt// files.

  Copy the ezmlmrc file from the ezmlm bin directory to ..eezzmmllmmrrcc in your
  ..qqmmaaiill file base directory (usually your home directory):

       % cp /usr/bin/ezmlmrc ~/.ezmlmrc

  The base eezzmmllmmrrcc file lives in the ezmlm binary directory, which may
  differ from ``//uussrr//llooccaall//bbiinn//eezzmmllmm//eezzmmllmmrrcc'' if you do not have a
  default setup.  If your system administrator has placed a ezmlmrc file
  into the //eettcc directory, start with that one instead, as it is likely
  to already contain some useful local customization and comments.

  Now edit ~~//..eezzmmllmmrrcc. Find the tag corresponding to the text file you
  want to change, e.g. ``</text/mod-request/>'', and modify it
  appropriately. Some tags have conditional flags, so that succeeding
  text is copied only if specific switches are on/off. Thus, text
  succeeding ``</text/file#rms/>'' is copied into DDIIRR//tteexxtt//ffiillee if and
  only if the ezmlm-make(1) ``-rms'' switches are all used. For more
  info, see documentation in eezzmmllmmrrcc and the ezmlm-make(1) man page. To
  invoke a custom ..eezzmmllmmrrcc file, use the ezmlm-make(1) ``-c'' (custom)
  switch.

  88..44..  CChhaannggiinngg ddeeffaauulltt mmooddeerraattoorr ddiirreeccttoorriieess..

  See above. Edit the ..eezzmmllmmrrcc file to add a directory name to e.g.
  ``</modsub/#s>''. Also, you need to create that directory, and the
  subscribers subdirectory under it. NOTE: DDIIRR//mmoodd// is still required as
  the base directory for the message moderation queue.

  88..55..  AAddaappttiinngg eezzmmllmm--mmaakkee ffoorr vviirrttuuaall ddoommaaiinnss..

  The problem with virtual domains is that ezmlm-make(1) by default puts
  the list name in DDIIRR//iinnllooccaall. However, if the domain host1.dom.com is
  controlled by the user ``virt'', then the local part of the address
  for the list list@host.dom.com will be ``virt-list'', not ``list''.
  This is easily accommodated by putting a ..eezzmmllmmrrcc file in ~~vviirrtt//, and
  for ``</inlocal/>''; enter ``virt-<#L#>'' instead of ``<#L#>''.  Now,
  all lists created under ~~//vviirrtt will be automatically set up correctly.

  Similarly, if host1.dom.com is controlled by virt-dom1 and
  host2.dom.com by ``virt-dom2'', inlocal for list list@host1.dom.com
  should be ``virt-dom1-list'' and for list@host2.dom.com should be
  ``virt-dom2-list''. To accommodate this, put ``virt-<#1#>-<#L#>'' in
  ``</inlocal/>''.

  Running:

       % ezmlm-make -c ~virt/LIST ~virt/.qmail-dom1-list \
                  list host1.dom.com

  will produce a LLIISSTT//iinnllooccaall of virt-dom1-list by substituting the
  first part between two ``-'' (dom1) for ``<#1#>''. Two levels of
  dashes are accommodated, i.e. ``<#2#>'' will be replaced by the second
  part between two ``-'' (in this case empty (_S_i_c_!)).  For more info,
  see ezmlm-make(1) and comments in eezzmmllmmrrcc.
  88..66..  WWhhyy tthhee eezzmmllmm--mmaakkee --cc sswwiittcchh..

  ezmlm-make(1) does not use the ddoottddiirr//..eezzmmllmmrrcc file by default for
  security reasons. If you as root create a list with a ``dotdir'' of
  ~~uusseerr// your execution of ezmlm-make is controlled by a eezzmmllmmrrcc file
  under the control of ``user''. This should be safe, since ezmlm-
  make(1) limits its actions to the list directory. However, we believe
  it to be good practice not to make this the default in the first
  version, before a number of knowledgeable people have checked it out
  for security holes.

  88..77..  SSeettttiinngg uupp eezzmmllmm--mmaakkee ffoorr ssppeecciiaall ssiittuuaattiioonnss..

  Ezmlm-make is very flexible. There are only three sets of special
  command line switches: ``-vV'' for version info, ``-cC'' controlling
  the use of a custom file ..eezzmmllmmrrcc in the ``dot'' directory, and
  ``-eE'' for edit mode (i.e. reconfiguration of existing list setups).
  All other switches are soft, i.e. controlled through eezzmmllmmrrcc.  Many
  switches, have special meanings via eezzmmllmmrrcc and are documented in the
  man page. Any other switches can be used for customization (_N_O_T_E_: _w_e
  _m_a_y _u_s_e _s_w_i_t_c_h_e_s _o_t_h_e_r _t_h_a_n _`_`_-_x_y_z_'_' _f_o_r _s_p_e_c_i_f_i_c _p_u_r_p_o_s_e_s _i_n _f_u_t_u_r_e
  _v_e_r_s_i_o_n_s_.)  The ``-xyz'' switches will always be available for your
  use, with the ``-x'' switch being configured for some demo/special
  features in the distributed eezzmmllmmrrcc.  You can use them for anything
  you like. They are by default off=false. The complement of these
  switches is ``-XYZ'' (by default on=true). You can use these to cause
  specific changes in the list setup if a given switch is used. For an
  example, see the ``-x'' switch as used and documented in the default
  eezzmmllmmrrcc file.

  Switches ``-a-z'' and ``-A-Z'' take no arguments. They have to be
  specified anew at every ezmlm-make(1) invocation. Switches ``-0'' and
  and ``-3-9'' take arguments. These arguments are read from DDIIRR//ccoonnffiigg
  (if available), and when editing an existing list, you need to specify
  only the ``digit'' switches you want to change. Use two single quotes
  without intervening characters to remove an existing ``digit'' switch.

  99..  RReessttrriiccttiinngg mmeessssaaggee ppoossttiinngg ttoo tthhee lliisstt

  99..11..  RReeqquuiirriinngg tthhee lliisstt aaddddrreessss iinn TToo:://CCcc:: hheeaaddeerrss..

  SPAM or junkmail is usually sent by mailing a single message to a
  large number of (unwilling) recipients. As such, it usually does not
  contain the E-mail address of all recipients (remember, junk mailers
  pay for these address lists). By rejecting messages that do not have
  the list address in the To: or Cc: header(s) a large fraction of spam
  to the list can be filtered out.

  This filter function is activated by default, but will work only if
  you specify the list directory on the ezmlm-reject(1) command line. To
  disable this restriction, remove the ``DIR'' arguement from the ezmlm-
  reject(1) command line, or add the ``-T'' switch.

  By default, this error is logged, and an error message is sent to the
  sender.  Since virtually all the failures will be SPAM and virtually
  all spam has a faked SENDER, most of these error messages will go to
  the postmaster.  Thus, you may want to use the ezmlm-reject ``-q''
  switch (quiet) to suppress the sender notification.

  99..22..  RReejjeeccttiinngg mmeessssaaggeess sseenntt ffrroomm ootthheerr mmaaiilliinngg lliissttss..

  ezmlm automatically detects are rejects messages that are sent from
  other ezmlm mailing lists. Some other mailing list managers do not use
  a rigorous mechanisms to verify subscribers. Thus, it is possible to
  subscribe an ezmlm list address to such a mailing list. You can easily
  block such a list by adding the address to the ``deny'' if you use the
  ezmlm-make(1) ``-k'' option. However, you can also configure ezmlm-
  reject(1) to reject messages based on specific headers placed into
  DDIIRR//hheeaaddeerrrreejjeecctt. A set of headers which will catch mailing list
  managers known to us are listed in the ezmlm-reject(1) man page. To
  activate this option, you must specify the ``-h'' switch and DDIIRR on
  the ezmlm-reject(1) line in DDIIRR//eeddiittoorr. Naturally, you can make this
  the default by editing ezmlmrc (See ``Customizing ezmlm-make
  operation'').

  99..33..  RReessttrriiccttiinngg ppoossttss bbaasseedd oonn tthhee SSuubbjjeecctt lliinnee..

  ezmlm-reject(1) is by default configured to reject posts with empty
  subject (``-s'' switch) or with a subject that consists of only an
  administrative command word (``-c'' switch), such as ``subscribe''. To
  remove these restrictions, use the ezmlm-reject(1) ``-S'' and ``-C''
  switch, respectively.

  99..44..  RReessttrriiccttiinngg tthhee ssiizzee ooff ppoossttss..

  If the ``DIR'' argument is specified on the ezmlm-reject(1) line in
  DDIIRR//eeddiittoorr and DDIIRR//mmssggssiizzee exists and contains a number (in bytes)
  greater than ``0'', then any posts with a body larger than the number
  specified is rejected. The maximum message size can optionally be
  followed by ``:'' and a minimum message body size in bytes.  For
  moderated lists, messages that are too large are rejected and not sent
  to the moderators. This feature can be used to prevent the posting an
  entire digest to the list by setting DDIIRR//mmssggssiizzee slightly below the
  message size set in your ezmlm-tstdig(1) innovation (if any). A
  minimum size can catch a few administrative request sent to the main
  list, but is otherwise not that useful. To always configure your lists
  with a message size restriction, add to eezzmmllmmrrcc:

               </msgsize/>
               max:min

  99..55..  RReessttrriiccttiinngg ppoossttss bbaasseedd oonn MMIIMMEE ccoonntteenntt--ttyyppee..

  ezmlm-reject(1) will look for DDIIRR//mmssggssiizzee, DDIIRR//mmiimmeerreejjeecctt, and
  DDIIRR//mmiimmeerreemmoovvee if the ``DIR'' argument is specified (``DIR'' can be
  left out to conserve resources on lists that do not use these
  features). _N_o_t_e_: _T_h_e _`_`_D_I_R_'_' _a_r_g_u_m_e_n_t _i_s _a_l_s_o _r_e_q_u_i_r_e_d _f_o_r _t_h_e _t_h_e
  _T_o_:_/_C_c_: _l_i_s_t_a_d_d_r_e_s_s _r_e_s_t_r_i_c_t_i_o_n _(_s_e_e _`_`_R_e_q_u_i_r_i_n_g _t_h_e _l_i_s_t _a_d_d_r_e_s_s _i_n
  _T_o_:_/_C_c_: _h_e_a_d_e_r_s_'_'_)_.  If the message contains MIME parts that are of a
  content-type listed in DDIIRR//mmiimmeerreejjeecctt they are rejected. If the
  message is a simple MIME message of a content-type listed in either
  DDIIRR//mmiimmeerreejjeecctt or DDIIRR//mmiimmeerreemmoovvee it is also rejected.

  There is currently no ezmlm-make(1) switch for DDIIRR//mmiimmeerreejjeecctt, but it
  can easily be configured by editing eezzmmllmmrrcc. The ezmlm-make ``-x''
  switch configures DDIIRR//mmiimmeerreemmoovvee (see ``mimeremove'') for a list of
  content-types).  Messages consisting solely of these content-types
  (rare) will be rejected, and the corresponding MIME parts of composite
  messages will be removed.

  99..66..  RReessttrriiccttiinngg ppoossttss ttoo lliisstt ssuubbssccrriibbeerrss..

  Use message moderation. As an alternative, implement a check against
  SENDER by using ezmlm-issubn(1). 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/bin/ezmlm-issubn 'DIR' 'DIR/digest' 'DIR/extra' ||
       ( echo "Sorry, you are not allowed to post to this list.";
       exit 100 )

  _A_L_L _O_N _O_N_E _L_I_N_E to DDIIRR//eeddiittoorr before the ezmlm-send(1) line. ``DIR''
  is the main list directory. If your ezmlm binaries live in a different
  directory, change the ezmlm-issubn path accordingly.  _N_O_T_E: The local
  part of e-mail addresses are case sensitive.  ezmlm respects that.

  See ``Customizing ezmlm-make operation'' if you want your lists to
  have some of these features by default or set by specific ezmlm-
  make(1) switches. The ezmlm-make(1) ``-u'' switch by default sets up
  restrictions this way.

  If you do not want to allow digest subscribers to post, remove
  DDIIRR//ddiiggeesstt// from the ezmlm-issubn command line. To allow posts from an
  address that is not a subscriber, simply add it to the addresses in
  DDIIRR//eexxttrraa//:

               % ezmlm-sub DIR/extra address@host

  The ``extra'' database can be manipulated remotely by sending mail to
  list-allow-subscribe@listhost, list-allow-unsubscribe@listhost, etc.
  If configured for the list, the ``-list'' command for remote adminis-
  trators will work for the ``extra'' database as well.

  Please note that this setup is not secure, as it is easy to modify the
  envelope SENDER. For more secure options, see ``Restricting posts to
  an arbitrary set of E-mail addresses (higher security option)''.

  99..77..  RReessttrriiccttiinngg ppoossttss ttoo aann aarrbbiittrraarryy sseett ooff EE--mmaaiill aaddddrreesssseess
  ((hhiigghheerr sseeccuurriittyy ooppttiioonn))..

  The easiest way to achieve this is to simply set up a message
  moderated list, and add all the e-mail addresses 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-issubn(1) 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.

  99..88..  CCoommpplleetteellyy rreessttrriiccttiinngg ppoossttss..

  To completely prevent posting (for instance a message-of-the-day
  list), set up a normal list, and just remove ~~//..qqmmaaiill--lliisstt and
  DDIIRR//eeddiittoorr altogether. Make posts from the shell, or from shell
  scripts or crond, by simply piping a (complete) message to ezmlm-
  send(1):

       % /usr/bin/ezmlm-send DIR < message

  _N_O_T_E: This can be done by any user with write access to DDIIRR//lloocckk, so
  make sure your file modes are set correctly.  The ezmlm-send(1) path
  may need to be changed to match your ezmlm binary directory. It's also
  a good idea to not allow others to read your list directory and
  DDIIRR//ssuubbssccrriibbeerrssii// and other address lists.

  99..99..  AA ggeenneerraall ssoolluuttiioonn ttoo rreessttrriiccttiinngg ppoossttss bbaasseedd oonn SSEENNDDEERR

  As discussed above, the security afforded by SENDER checks is minimal,
  but nevertheless sufficient to keep out most spam and garbage.
  However, some subscribers post from e-mail addresses other than their
  subscription address, and users tend to become unfriendly when their
  posts are denied even though they are subscribers. This is a general
  solution to this problem which has minimal overhead for the list owner
  and is essentially completely transparent to the subscriber.

  Set up the list with ezmlm-gate(1) in DDIIRR//eeddiittoorr in place of the
  ezmlm-send(1) line.  To the ezmlm-gate(1) command line add the list
  directory twice, then a digest directory DDIIRR//ddiiggeesstt// (if it exists),
  then DDIIRR//eexxttrraa//.  Create DDIIRR//mmooddppoosstt. Add the list owner as a message
  moderator.

  With this setup, any message from a SENDER that is a subscriber of the
  main list, the digest list or added to DDIIRR//eexxttrraa//, will be posted
  directly, others will be sent to the list owner for approval. If the
  list wants to automatically approve posts from that address in future
  (e.g. it is an alias for a subscriber) s/he just adds it to the
  database in DDIIRR//eexxttrraa//.  If the owner wants to approve this post, but
  not necessarily future posts from that address, s/he just accepts the
  message. To reject the message with a comment is equally easy. If the
  owner wished to have the option to silently ignore posts (and not have
  the SENDER notified that the post timed out), just add the ezmlm-
  clean(1) ``-R'' switch in DDIIRR//eeddiittoorr and DDIIRR//mmooddeerraattoorr.

  In this way, the normal subscriber is always happy and the ``behind
  the scenes'' work of the owner is minimalized.

  ezmlm-make creates lists with this setup if you specify the ``-u''
  switch in addition to the ``-m'' switch:

               % ezmlm-make -mu ~/list ~/.qmail-list joe-list host code

  If you omit the ``-m'' switch, the setup will reject posts from non-
  subscribers that are not in the ``extra'' database.  ezmlm-both(1)
  uses a set of similar ezmlm-make(1) invocations to create a list with
  digest, optionally making you a remote admin, list owner, and
  subscriber to both lists.

  1100..  CCuussttoommiizziinngg oouuttggooiinngg mmeessssaaggeess

  1100..11..  AAddddiinngg aa ttrraaiilleerr ttoo oouuttggooiinngg mmeessssaaggeess..

  Put the text in DDIIRR//tteexxtt//ttrraaiilleerr. The text is NOT copied to the
  archived version of the message. This works also for sublists.

  1100..22..  AAddddiinngg aa ssuubbjjeecctt pprreeffiixx ttoo oouuttggooiinngg mmeessssaaggeess..

  Put the exact text in DDIIRR//pprreeffiixx. You can include the message number
  assigned to the post in the list archive by adding the ``#'' character
  in the text in DDIIRR//pprreeffiixx (example: put ``listname-#'' in DDIIRR//pprreeffiixx).
  ezmlm does not modify the subject other than by prefixing it with the
  prefix.  ezmlm knows about RFC2047 encoded subject and can detect a
  prefix within an encoded word. However, ezmlm will not modify the
  subject itself. It will add a prefix only of none has been added
  before. A consequence of this is that a message will have the message
  number prefix of the first message in the thread rather than a prefix
  with the number of the message itself. The entire thread can always be
  retrieved with a message to list-thread-x@host, where ``x'' is the
  number in the prefix.

  We recommend against using the prefix feature and strongly against the
  message number prefix. If you use it, make sure you understand the
  drawbacks, of message modification and subjects that change between
  message and reply.  ezmlm can deal with this, but other programs may
  not be able to.

  Sublists ignore DDIIRR//pprreeffiixx.

  If you add a prefix, especially if you previously added it by other
  means (procmail, etc.), use ezmlm-idx to re-index the archive. Due to
  the way ezmlm-get(1) does threading from the subject, it works best if
  you use exactly the same prefix as you did before.

  1100..33..  AAddddiinngg aa hheeaaddeerr ttoo oouuttggooiinngg mmeessssaaggeess..

  Put the exact header text as a line in DDIIRR//hheeaaddeerraadddd.  Thus, if you'd
  like a ``Precedence: bulk'' header added to outgoing messages, put a
  line ``Precedence: bulk'' into DDIIRR//hheeaaddeerraadddd. You can also modify
  ezmlmrc to add this to all lists created or edited with ezmlm-make(1)
  (see ``Customizing ezmlm-make operation'').

  1100..44..  AAddddiinngg aa mmeessssaaggee nnuummbbeerr hheeaaddeerr..

  If you create DDIIRR//sseeqquueennccee, 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
  DDIIRR//sseeqquueennccee on the sublist, not the main list. To get consistent
  message numbering in digests, digest have the message number of the
  first message in the digest.

  ezmlm-idx tries to make message numbering problems with sublists a
  little easier: sublists use the incoming message number, but only when
  the sublist is not archived and not indexed. This restriction is
  necessary for security reasons. Otherwise, an attacker could wreak
  havoc in the local message archive by sending messages with faked
  message numbers in the SENDER.

  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.

  1100..55..  RReemmoovviinngg hheeaaddeerrss ffrroomm oouuttggooiinngg mmeessssaaggeess..

  Put the header up to, but excluding the ``:'' in DDIIRR//hheeaaddeerrrreemmoovvee.

  1100..66..  RReemmoovviinngg MMIIMMEE ppaarrttss ffrroomm mmeessssaaggeess..

  ezmlm-idx>=0.30 can strip parts from composite mime messages based on
  content type. Just put the appropriate content-types such as
  ``text/ms-word'' or ``text/html'' into DDIIRR//mmiimmeerreemmoovvee. This is
  automatically configured when using the ezmlm-make(1) ``-x'' switch.

  1100..77..  LLiimmiittiinngg ````RReecceeiivveedd::'''' hheeaaddeerrss iinn oouuttggooiinngg mmeessssaaggeess..

  sendmail still is being used on the majority of mail hubs. Sendmail
  has very primitive loop detection, bouncing messages based on
  excessive ``hopcount''.  The ``hopcount'' is determined by counting
  ``Received:'' headers. ezmlm by default propagates ``Received:''
  headers to facilitate message tracking. Thus, messages, especially
  from a sublist, can have a number of ``Received:'' headers that
  exceeds the ``hopcount'' set on poorly configured sendmail hosts.
  Subscription confirmation requests, warning, and probe messages have
  fewer ``Received:'' headers. Thus, a user may be able to receive
  these, but not (some of the) list messages. Of course, the best is to
  correct the configuration on the bouncing host, but this is often
  under the control of neither list owner nor user.

  To compensate for this problem, ezmlm-send(1) of ezmlm-idx->=0.31 by
  default removes all ``Received:'' headers except the top one.  They
  are still written to the archive, an can be retrieved from there using
  the ``-getv'' command.  To cause ezmlm-send(1) to pass on all the
  ``Received:'' headers, use the ezmlm-send(1) ``-r'' switch.

  1100..88..  SSeettttiinngg ````RReeppllyy--TToo:: lliisstt@@hhoosstt''''..

  This is not recommended, since it leads to dissemination via the list
  of messages returned from bad auto-responders and MTAs. Also, it may
  lead to public 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
  DDIIRR//hheeaaddeerrrreemmoovvee, and ``Reply-To: list@host.dom'' into DDIIRR//hheeaaddeerraadddd.

  1100..99..  CCoonnffiigguurriinngg tthhee lliisstt ssoo ppoossttss aarree nnoott ccooppiieedd ttoo tthhee oorriiggiinnaall
  sseennddeerr..

  For most mailing lists, you want all subscribers, including the sender
  of a particular message, to get all messages. This way, the sender
  sees that the message reached the list. For small lists, such as a
  project group, it may be annoying for the members to receive their own
  posts.

  ezmlm-send(1) can be configured to exclude the sender from the
  recipient E-mail addresses if configured with the ``-C'' switch. To
  add this switch, edit the ezmlm-send(1) line of DDIIRR//eeddiittoorr.  This is
  slightly less efficient, since ezmlm-send(1) has to parse all
  subscriber E-mail addresses. With small lists the overhead is
  negligible. This kind of setup is useful if you use ezmlm to run
  communication for a small collaborative group where it is obvious that
  everyone receives all the messages. This way, ezmlm works more like a
  traditional ``alias'' except that it is secure, efficient, and can be
  maintained without administrator intervention or shell access.

  1100..1100..  CCuussttoommiizziinngg eezzmmllmm nnoottiiffiiccaattiioonn mmeessssaaggeess..

  Most of ezmlm's more commonly used messages are stored in DDIIRR//tteexxtt//.
  These messages can be edited manually for a list once it is set up, or
  on a global basis via modification of eezzmmllmmrrcc.  The messages may also
  be edited remotely after the list is established by creating the list
  using the ezmlm-make(1) ``-e'' (edit) feature (see ``Customizing
  ezmlm-make operation'').  _N_O_T_E_: Any customization done with remote
  editing or by manually editing list files will be undone by ezmlm-
  make(1) ``-e''. For general changes, edit a custom eezzmmllmmrrcc file. This
  way, ezmlm-make -ec can be used to preserve them.

  The most useful messages are DDIIRR//tteexxtt//ssuubb--ookk for new subscriber
  information (such as the traditional ``welcome'' message, or a list
  charter or list posting rules/guidelines); DDIIRR//tteexxtt//uunnssuubb--nnoopp is
  useful for messages to frustrated users unsuccessful in their
  unsubscribe attempts; DDIIRR//tteexxtt//hheellpp for general help information in
  reply to list-help@host or unrecognized commands, DDIIRR//tteexxtt//bboottttoomm for
  inclusion at the bottom of virtually all ezmlm messages; DDIIRR//tteexxtt//mmoodd--
  hheellpp for moderator information; DDIIRR//tteexxtt//ttrraaiilleerr for a (few) line(s)
  at the bottom of each post; DDIIRR//tteexxtt//ddiiggeesstt for information in the
  ``Administrivia'' section of digests.

  By using the ezmlm-make(1) ``-n'' switch or by manually adding the
  ezmlm-manage(1) ``-e'' switch, you can allow a list remote
  administrator to edit the files in DDIIRR//tteexxtt// remotely via E-mail.

  1100..1111..  SSppeecciiffyyiinngg cchhaarraacctteerr sseett aanndd ccoonntteenntt--ttrraannssffeerr--eennccooddiinngg ffoorr
  oouuttggooiinngg eezzmmllmm mmeessssaaggeess..

  All ezmlm replies, except errors handled directly by qmail, can be
  sent in any character set and optionally with quoted-printable or
  base64 content-transfer-encoding. DDIIRR//tteexxtt// files are always 8-bit
  files, but even though qmail has no problems with 8-bit mail, other
  MTAs and MUAs do.  Problems due to this can be avoided by assuring
  that outgoing ezmlm messages are 7bit by using the appropriate
  content-transfer-encoding.

  To specify a character set, put the name in DDIIRR//cchhaarrsseett (default: us-
  ascii). To specify quoted-printable or base64 content-transfer-
  encoding, add ``:Q'' or ``:B'' after the character set name in
  DDIIRR//cchhaarrsseett.

  1111..  CCuussttoommiizziinngg aarrcchhiivvee rreettrriieevvaall..

  1111..11..  SSppeecciiffyyiinngg tthhee ffoorrmmaatt ffoorr rreettrriieevveedd mmeessssaaggeess..

  Add a format (f) specifier after the archive retrieval command:

       list-getf@host

  where ``f'' is ``r'' for RFC1153 format, ``m'' (mime; default) for
  MIME multipart/digest with subset of ordered headers, and ``v'' (vir-
  gin) MIME multipart/digest, i.e. with all headers retained from the
  archive, and ``n'' (native) the same as ``v'' except that no threading
  is performed and messages are returned in numerical order.  Under some
  circumstances, it may be preferable to have a digest in ``multi-
  part/mixed''.  The ``x'' (mixed) format is identical to ``m'' except
  for this header.

  For ezmlm-cron(1), just suffix the format code to the digest code.

  1111..22..  SSppeecciiffyyiinngg tthhee ddeeffaauulltt ffoorrmmaatt ffoorr ddiiggeessttss aanndd aarrcchhiivvee rreettrriieevvaall

  The ezmlm-get(1) ``-f'' switch can be used to change the default
  format (MIME with removal of less relevant headers) to other formats.
  The format specifiers are the same as for individual archive
  retrievals (see ``Specifying the format for retrieved messages'').

  1111..33..  LLiimmiittiinngg tthhee nnuummbbeerr ooff mmeessssaaggeess ppeerr --ggeett//--iinnddeexx rreeqquueesstt..

  By default, a single -get request returns a maximum of 100 messages,
  and a single -index request 2000 subjects entries (20 files of 100
  subjects entries each). This can be changed by editing MAXGET, and
  MAXINDEX in iiddxx..hh and recompiling. Remember to edit tteexxtt//bboottttoomm,
  tteexxtt//bboouunnccee, and eezzmmllmmrrcc to reflect these changes so that your users
  won't get confused.

  1122..  RReessttrriiccttiinngg aarrcchhiivvee rreettrriieevvaall..

  1122..11..  RReessttrriiccttiinngg aarrcchhiivvee aacccceessss ttoo ssuubbssccrriibbeerrss..

  If you use ezmlm-get(1), archive retrieval can be restricted by using
  the ``-s'' switch. This allows access only to addresses that are
  subscribers of the list, or of the digest list, or that are present in
  an extra address database stored in DDIIRR//eexxttrraa//. Addresses can be added
  remotely by mailing list-allow-useralias=userhost@listhost. Other
  commands, such as ``subscribe'' work as expected.

  Since ezmlm-get always sends the reply to SENDER, this assures that
  only subscribers 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 E-mail addresses.  The
  DDIIRR//eexxttrraa// database can be used to manually add addresses that should
  be given archive access, but are not subscribers. This may be an
  address of a subscriber who posts from an address other than his or
  her subscription address.

  1122..22..  RReessttrriiccttiinngg aavvaaiillaabbllee aarrcchhiivvee rreettrriieevvaall ccoommmmaannddss..

  If you want to disable all archive retrieval except digest creation,
  simply add the ``-C'' command line switch to the ezmlm-get(1) line in
  DDIIRR//mmaannaaggeerr. If you don't want digest creation via trigger messages
  and DDIIRR//mmaannaaggeerr, but use other means to created digests, you can
  remove the ezmlm-get(1) line from DDIIRR//mmaannaaggeerr.

  1122..33..  RReessttrriiccttiinngg aarrcchhiivvee rreettrriieevvaall ttoo mmooddeerraattoorrss..

  If DDIIRR//ppuubblliicc does not exist, ezmlm-manage(1) and ezmlm-get(1) modify
  their behavior. They disallow user requests, but for remote
  administration lists, honor moderator requests.  Thus, for a remote
  admin list without DDIIRR//ppuubblliicc, only subscription moderators or remote
  administrators can receive archive retrievals and only remote
  administrators can subscribe and unsubscribe user addresses.

  If you'd like this restriction of archive retrieval with maintained
  user-initiated ezmlm-manage(1) (subscription) functions, use the
  ezmlm-get(1) ``-P'' (not public) switch, and retain DDIIRR//ppuubblliicc.

  1122..44..  AAlllloowwiinngg aarrcchhiivvee rreettrriieevvaall ffrroomm aa nnoonn--ppuubblliicc lliisstt..

  A non-public list lacks DDIIRR//ppuubblliicc. ezmlm-manage will honor neither
  user requests for (un) subscription, nor for archive retrieval. The
  restriction on archive retrieval can be removed with the ezmlm-get(1)
  ``-p'' (public) switch.

  1122..55..  DDiissaabblliinngg ddiiggeesstt ttrriiggggeerriinngg bbyy mmaaiill..

  Since anyone who knows your digest code can trigger digests, it may be
  desirable to disable this option. Just set up the list without the
  ezmlm-make ``digestcode'' argument, or remove it from the ezmlm-get(1)
  command line by editing DDIIRR//mmaannaaggeerr.  Instead, use digest generation
  from DDIIRR//eeddiittoorr as set up with the ezmlm-make(1) ``-d'' switch.

  1133..  CCuussttoommiizziinngg ddiiggeessttss..

  1133..11..  SSeettttiinngg uupp aa ddiiggeesstt lliisstt..

  The script ezmlm-both(1) sets up a list and a digest list
  simultaneously.  You can customize more options if you ``manually''
  create the lists with ezmlm-make(1).  However, ezmlm-both(1) uses
  reasonable defaults and is very easy to use:

               % ezmlm-both ~joe/list ~/joe/.qmail-list joe-list host code

  This sets up joe-list@host and joe-list-digest@host with automatic
  digest creation, restriction of posts to subscribers of either list or
  addressed in ~~jjooee//lliisstt//eexxttrraa// (see ezmlm-both(1)) and similarly
  restricts archive access.

               % ezmlm-both ~joe/list ~/joe/.qmail-list joe-list host code joe@host

  Sets up the list in a similar manner, but in addition joe@host is a
  remote administrator for both lists (can add/remove any address
  remotely) and posts that otherwise would be rejected are sent to
  joe@host for approval (Joe can ignore the requests, or approve the
  message, or approve the message and add the SENDER to the E-mail
  addresses in ~~ jjooee//lliisstt//eexxttrraa//.  This can be done from the shell with:

               % ezmlm-sub DIR/extra user@userhost

  or remotely, by mailing list-allow-subscribe-user=userhost@host.

  joe@host is also set up as the owner for both lists (receives mail for
  list-owner@host and list-digest-owner@host).

  To set up a simpler version of list and digest list (no SENDER
  restrictions) manually:

       % ezmlm-make -d DIR dot listname host gaga

  where ``gaga'' is the digest code needed only if you want to trigger
  digest via mail sent to the list at specific times, rather than the
  default that will create a digest when sufficient time has passed or
  sufficient new mail has arrived (see ezmlm-tstdig(1)).

  Or for example:

       % ezmlm-make -d ~joe/SOS ~joe/.qmail-sos joe-sos id.com gaga

  The digest is not archived or indexed. There usually is no need to
  archive digests, which are themselves created from the main list
  archive.  To make it easier for list-digest subscribers, bounce warn-
  ing messages refer to message numbers in the main archive, rather than
  to digest numbers.  If you want the digests to be archived, set up an
  archived sublist and subscribe it to the digest (for the above list,
  such a sublist should have ``joe-sos-digest@id.com'' in DDIIRR//ssuubblliisstt).

  As usual, for lists under ``alias'', remember to set ownerships
  correctly:

          % chown -R alias DIR

  For the above example (if you're not ``joe''):

               % chown -R joe ~/SOS

  1133..22..  WWhhyy uussee ccrroonn--ttrriiggggeerreedd ddiiggeessttss aanndd aa ddiiggeesstt ccooddee..

  A digest code is necessary if you want to be able to trigger digests
  by sending mail to ezmlm. You do not need this for a minimalist digest
  setup, where digests are triggered by messages to the list. However,
  it is required when instead you'd like to create digests at a specific
  time interval.  Occasionally, such as around a holiday, list traffic
  may slow down almost completely. Messages may have accumulated since
  the last digest, but this is not tested since no new messages arrive.
  With a cron controlled digest, these messages get put into digests
  when the next digest trigger message is set. Your users may also
  prefer a digest that it made exactly at 0600, rather that one that
  arrives about one day after the previous one.

  The digest code enables ezmlm-get(1) to send digests, and at the same
  time protects your list against unauthorized access. Without this
  protection, anyone could retrieve all the messages from your archive
  with the associated ability to use your system resources. An outsider
  can still do this if s/he knows your digest code. Therefore, keep it
  secret and in files that only you can read (crontab files, mail logs,
  DDIIRR//mmaannaaggeerr, and DDIIRR//ccoonnffiigg).  You can also completely disable this
  mode of digest triggering and use other means of generating digests
  (see below).

  1133..33..  HHooww ttoo sseett uupp aa ddiiggeesstt ccooddee..

  To set up a digest code, either set up a list via ezmlm-make(1) (the
  digest code is the 5th optional command line argument), or add the
  digest code as the second optional command line argument to the ezmlm-
  get(1) command line in DDIIRR//mmaannaaggeerr. 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(1) command line, ezmlm-get
  will not honor digest requests when invoked in DDIIRR//mmaannaaggeerr.  If the
  digest request does not have the correct digest code, and error will
  be returned, rather than a digest.

  There are other ways of invoking ezmlm-get(1) that do not require a
  digest code (see ``How digests work'').

  1133..44..  GGeenneerraattiinngg ddaaiillyy ddiiggeessttss..

  The easiest way to generate trigger messages is to use ezmlm-cron(1).
  For this, you either need cron access, or a system administrator who
  has set up ezmlm-cron(1) to allow you to use it without cron access.
  This involves granting a specific user cron access and then setting up
  ezmlm-cron(1) to run as that user.

  To use ezmlm-cron to generate triggers to list@host for digests every
  morning at 5 am:

       % ezmlm-cron -t 05:00 -i24 list@host digestcode

  Other ezmlm-cron(1) options let you list the trigger settings that
  belong to you and the configuration file line that controls which
  triggers you may generate (see ezmlm-cron(1)).

  As an alternative, you can use cron directly to send mail to:

       list-dig.digestcode@host

  to generate a digest from list@host to the subscribers of list-
  digest@digesthost.

  If the timing of the digest is not essential, use ezmlm-make(1) with
  the ``-d'' switch to configure digest generation when sufficient
  activity has passed, optionally with the ``-4'' switch to specify the
  command line arguments for ezmlm-tstdig(1).

  If you have shell access to the host running the list, you can also
  use the procedure described under ``Disabling digest triggering by
  mail''.

  1133..55..  GGeenneerraattiinngg tthhee ffiirrsstt ddiiggeesstt..

  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 DDIIRR//ddiiggnnuumm.

  If you want the next digest to start at message 456, you can always
  edit DDIIRR//ddiiggnnuumm to contain '455'. If you want the next digest to be
  named issue 678, put '677' into DDIIRR//ddiiggiissssuuee.

  1133..66..  GGeenneerraattiinngg ddiiggeessttss aafftteerr aa cceerrttaaiinn ttiimmee,, nnuummbbeerr,, oorr aammoouunntt ooff
  mmeessssaaggeess..

  ezmlm-send(1) and ezmlm-get(1) in ezmlm-idx>=0.22 keep track of not
  only message number, but also the amount of ``message body'' text
  posted to the list since the latest digest, as well as the time of the
  latest digest. This is automatic.  There is no need to modify old
  lists for this to occur. DDIIRR//nnuumm now contains the message number
  followed by ':' and a cumulative amount of ``message body traffic''
  (in ``records'' of 256 bytes) that has been sent by ezmlm-send(1).
  ezmlm-get(1) transfers this information to DDIIRR//ddiiggnnuumm and adds a ':'
  as well as a time stamp when successfully generating a digest.

  ezmlm-tstdig is configured automatically in DDIIRR//eeddiittoorr is you use
  ezmlm-make with the ``-3'' switch (see ezmlm-make(1) and ezmlm-
  tstdig(1)). This is also used by ezmlm-both(1) which sets up a
  commonly requested advanced combination of list and list-digest with a
  single command.

  1133..77..  AAddddiinngg ssttaannddaarrdd aaddmmiinniissttrraattiivvee iinnffoorrmmaattiioonn ttoo ddiiggeessttss..

  The text in DDIIRR//tteexxtt//ddiiggeesstt is copied into  the ``Administrivia''
  section of the digest.  This information can be customized on a
  system-wide basis by editing //eettcc//eezzmmllmmrrcc, on a user-wide basis by
  editing ~~//..eezzmmllmmrrcc, or for the list by directly editing the
  DDIIRR//tteexxtt//ddiiggeesstt file, or by a remote administrator by editing the file
  via e-mail, if the list has been set up using the ezmlm-make(1)
  ``-nr'' switches (see ``How text file editing works'').

  1133..88..  CCoonnttrroolllliinngg tthhee ddiiggeesstt ffoorrmmaatt..

  You can control the default format that ezmlm-get(1) uses for its
  output by using the ``-f x'' switch. For individual digests triggered
  by mail or other archive access, add a format specifier after the
  digestcode:

       list-dig.codef@host

  For example:

       joe-sos-dig.gagax@id.com

  where ``x'' is ``r'' for RFC1153 format, ``m'' (default) for MIME mul-
  tipart/digest with a subset of headers, ``v'' for virgin MIME multi-
  part/digest, i.e. with all headers retained from the archive, ``n''
  produces format similar to ``v'', without threading and with messages
  in numerical order. The ``x'' format is identical to the default ``m''
  format, but the digest content-type is ``multipart/alternative''
  rather than ``multipart/digest''. This helps with a pine bug if you
  are using quoted-printable/base64 encoding of ezmlm messages.

  With ezmlm-cron(1), add the format specifier to the end of the digest
  code argument.

  1133..99..  CCuussttoommiizziinngg bboouunnccee hhaannddlliinngg..

  The time out for bounce messages is normally 11.6 days. This means
  that a bad address will take longer that 3 weeks to be removed.
  Usually, this delay is desirable. After all, it is much worse to
  remove a subscriber just because the address had temporary problems
  that to send a few extra messages and receive a few extra bounces.

  However, for large lists, bounce handling can consume a considerable
  amount of resources. To decrease the load, remove all ezmlm-warn(1)
  lines from the DDIIRR//eeddiittoorr, and DDIIRR//mmaannaaggeerr files. Instead, execute:

       /path/ezmlm-warn DIR
       /path/ezmlm-warn -d DIR

  daily during off-peak hours via a cron script. The second line can be
  omitted if you are not using the digest capability of the list.

  In addition, you may want to reduce the time out for bounces from 11.6
  to a lower number of days, e.g. 5. To do so, add ``-t 5'' to the
  ezmlm-warn(1) command line.

  If you start with a list from a list manager that does not have bounce
  handling, chances are that you have many bad addresses in your list.
  You can always execute:

       /path/ezmlm-warn -t0 DIR
       /path/ezmlm-warn -d -t0 DIR

  to move bounce handling one step forward per execution. Users whose
  mail has bounced will be sent a warning. Users for whom the warning
  message has bounced will be sent a probe.

  1144..  RReemmoottee aaddmmiinniissttrraattiioonn..

  1144..11..  HHooww ccaann II rreemmootteellyy aadddd mmooddeerraattoorrss,, ssuubbssccrriibbeerr aalliiaasseess,, eettcc??

  On any list, the DDIIRR//eexxttrraa// 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.

  If configured, the DDIIRR//bbllaacckklliisstt// database can be manipulated, but
  only by remote administrators, by mail to e.g.  list-deny-
  baduser=badhost@listhost.

  To remotely administrate the DDIIRR//mmoodd// databases (i.e., without shell
  access), you need to set up a non-public, remotely administered list
  which ``resides'' within the DDIIRR//mmoodd. _P_l_e_a_s_e _c_a_r_e_f_u_l_l_y _c_o_n_s_i_d_e_r _t_h_e
  _i_m_p_l_i_c_a_t_i_o_n_s _o_f _m_a_k_i_n_g _i_t _p_o_s_s_i_b_l_e _t_o _r_e_m_o_t_e_l_y _a_d_d_, _r_e_m_o_v_e_, _a_n_d _l_i_s_t
  _m_o_d_e_r_a_t_o_r_s_. _I_n _m_a_n_y _c_i_r_c_u_m_s_t_a_n_c_e_s_, _t_h_i_s _i_s _d_a_n_g_e_r_o_u_s_.

  After setting up your list with the specific functionality you need,
  use the following command for DDIIRR//mmoodd//:

               % 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 ~~//..qqmmaaiill--lliisstt--mmoodd and ~~//DDIIRR//mmoodd//eeddiittoorr.  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.

  1144..22..  MMooddeerraattiinngg ppoossttss ffrroomm aa sseeccoonnddaarryy aaccccoouunntt..

  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.

  1144..33..  MMooddeerraattiinngg ssuubbssccrriippttiioonn ffrroomm aa sseeccoonnddaarryy aaccccoouunntt..

  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 DDIIRR//rreemmoottee).

  1144..44..  AAuuttoommaattiiccaallllyy aapppprroovviinngg ppoossttss oorr ssuubbssccrriippttiioonnss..

  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.
  1144..55..  AAlllloowwiinngg mmooddeerraattoorrss ttoo ggeett aa ssuubbssccrriibbeerr lliisstt..

  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 eezzmmllmmrrcc (see ``Customizing
  ezmlm-make operation'').

  1144..66..  AAlllloowwiinngg uusseerrss ttoo ggeett aa ssuubbssccrriibbeerr lliisstt..

  If you want any user to be able to get a subscriber list, you can set
  up a separate link to DDIIRR//lliisstt and then put in a script using ezmlm-
  list. 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.

  1144..77..  CChhaannggiinngg tthhee ttiimmeeoouutt ffoorr mmeessssaaggeess iinn tthhee mmooddeerraattiioonn qquueeuuee..

  Put the time, in hours, into DDIIRR//mmooddttiimmee. This value may not exceed
  the range of 24-120 h set at compile time by the defines in iiddxx..hh.

  1144..88..  FFiinnddiinngg oouutt hhooww mmaannyy mmeessssaaggeess aarree wwaaiittiinngg ffoorr mmooddeerraattiioonn..

       % 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. lliisstt--cchhkkqquueeuuee@@hhoosstt.  See ezmlm-check(1) for an
  example.

  1144..99..  UUssiinngg tthhee ssaammee mmooddeerraattoorrss ffoorr mmuullttiippllee lliissttss..

  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 //ppaatthh//mmooddddiirr into DDIIRR//mmooddssuubb (for moderation
  of subscribes), DDIIRR//rreemmoottee (for remote admin if DDIIRR//mmooddssuubb does not
  exist), and DDIIRR//mmooddppoosstt (for moderation of messages).

  For example:

       % echo "/home/joe/mods" > ~joe/DIR/modsub

  _N_O_T_E_: The path must start with a '/'.

  1144..1100..  UUssiinngg ddiiffffeerreenntt mmooddeerraattoorrss ffoorr mmeessssaaggee aanndd ssuubbssccrriippttiioonn mmooddeerr--
  aattiioonn..

  Proceed as in the previous point, but set up two different moddirs.
  Naturally, one of these can be DDIIRR//mmoodd// (preferably the one for posts,
  to keep it cleaner). Then modify the appropriate files (DDIIRR//mmooddppoosstt
  and DDIIRR//mmooddssuubb) to contain absolute paths to the correct moddir.

  1144..1111..  tthhee ````ssuuppeerr mmooddeerraattoorr'''' aabbllee ttoo aadddd//rreemmoovvee mmooddeerraattoorrss
  rreemmootteellyy..  SSeettttiinngg uupp mmooddeerraatteedd lliissttss wwiitthh tthhee lliisstt oowwnneerr aass

  This is done by crating a list that has DDIIRR//mmoodd// as it's main list
  directory, then adding the ``super moderator'' to DDIIRR//mmoodd//mmoodd// (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).

  1144..1122..  CCuussttoommiizziinngg mmeessssaaggeess..

  Subject lines, and other ezmlm output for moderation are controlled by
  defines in iiddxx..hh and by files in DDIIRR//tteexxtt. To customize these, change
  iiddxx..hh and recompile or for DDIIRR//tteexxtt files, edit eezzmmllmmrrcc (see
  ``Customizing ezmlm-make operation'').

  You can also configure the list to allow remote administrators to edit
  files in DDIIRR//tteexxtt// via E-mail (see ``How text file editing works'').

  1144..1133..  MMaannuuaallllyy aapppprroovviinngg aa mmeessssaaggee aawwaaiittiinngg mmooddeerraattiioonn..

  All you have to do is to pipe the corresponding message to ``ezmlm-
  send DIR''. Messages awaiting moderation are kept in DDIIRR//mmoodd//ppeennddiinngg//.
  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/bin/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 ~~jjooee//SSOOSS//.

  1144..1144..  MMaannuuaallllyy rreejjeeccttiinngg aa mmeessssaaggee aawwaaiittiinngg mmooddeerraattiioonn..

  Simply deleting the file from DDIIRR//mmoodd//ppeennddiinngg// 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 DDIIRR//mmooddttiimmee; default 120).

  1155..  SSuubblliissttss..

  A sublist is a list that receives its input from another mailing list,
  rather than from users directly. The sublist is just a regular
  subscriber of the main list. A sublist in e.g. Tasmania is very useful
  since only one message is sent from the main list and then the
  sublists servers all subscribers in Tasmania. Bounces and all
  administration is handled locally. The local sublist can have a
  digest, even though the main list may not.  (See ``How sublists work''
  for more info on how sublists work).

  1155..11..  SSuubblliissttss ooff eezzmmllmm lliissttss..

  To set up a sublist to an ezmlm list, just use the ezmlm-make ``-5
  mainlist@mainhost'' switch. This will configure your list as a sublist
  to the mainlist@mainhost mailing list.

  1155..22..  SSuubblliissttss ooff nnoonn--eezzmmllmm lliissttss..

  To set up a sublist to an ezmlm list, just use the ezmlm-make ``-5
  mainlist@mainhost'' switch. This will configure your list as a sublist
  to the mainlist@mainhost mailing list. Since the main list may not use
  the ``Mailing-List'' header, you must identify another header that the
  main list adds to all messages. See the ezmlm-reject(1) man page for
  examples. Next, edit DDIIRR//eeddiittoorr of your sublist and add a ``-h
  _L_i_s_t_p_r_o_c_e_s_s_o_r_-_V_e_r_s_i_o_n_:'' option to the ezmlm-send(1) line, but
  replacing ``_L_i_s_t_p_r_o_c_e_s_s_o_r_-_V_e_r_s_i_o_n_:'' with your mainlist header.

  Now your list will accept only messages from mainlist@mainhost and
  with the header specified.

  1166..  MMiiggrraattiioonn ttoo EEzzmmllmm ffrroomm ootthheerr MMaaiilliinngg LLiisstt MMaannaaggeerrss..

  This section describes differences and similarities between ezmlm and
  other mailing list managers. It also details functions of ezmlm-idx
  that allow you to configure ezmlm to respond to commands utilized by
  such other mailing list managers so the sommand syntax will be
  familiar to such users.  Contributions to complete this sections are
  welcome.

  1166..11..  BBaassiicc CCoonncceeppttss..

  Ezmlm is different from other mailing list managers in that it is
  _l_i_s_t_-_c_e_n_t_r_i_c rather than _h_o_s_t_-_c_e_n_t_r_i_c. With a _l_i_s_t_-_c_e_n_t_r_i_c interface,
  you address the list directly with administrative commands. With
  ezmlm, the command is embedded in the list address thus becoming part
  of it (i.e., the ``command address''.)  With smartlist, again you
  address the list, but send all administrative commands to the list-
  request address. Ezmlm lists can support this if you use the ezmlm-
  make(1) ``-q'' switch to configure ezmlm-request(1) in DDIIRR//mmaannaaggeerr.

  Other mailing list managers are _h_o_s_t_-_c_e_n_t_r_i_c, i.e.  administrative
  commands for any list on that particular host are addressed to a
  central address such as majordomo@host, listserv@host, or
  listproc@host. Then the user is required to place the command in
  either the subject header or more commonly in the body text of the
  message. The listname has to be included with the command. [_N_o_t_e_: The
  above concept is not universally applicable to all host-centric
  mailing lists.  While intended to to used in a host-centric manner,
  many such mailing list managers also support listname-request@host
  addressing. See the applicable list manger documentation for details.
  Coverage of this aspect of other mailing list manager functionality is
  beyond the scope of this FAQ.]  To make the migration to ezmlm easier,
  support for a _h_o_s_t_-_c_e_n_t_r_i_c style mailing list manger is available.
  This is based on the use of ezmlm-request(1) with the ``-f
  ccoonnffiigg__ffiillee'' switch.

  1166..22..  SSeettttiinngg uupp eezzmmllmm ttoo rreessppoonndd ttoo hhoosstt--cceennttrriicc ccoommmmaannddss..

  The eezzddoommoo..ttaarr..ggzz file included in the ezmlm-idx>=0.31 distribution
  contains the basic files needed to set up ezmlm to respond to host-
  centric command syntax. See the following section for the format and
  utilization of such syntax for the major non-ezmlm mailing list
  managers available today.  This section will set up majordomo@host as
  the example. The setup for other command addresses, such as listproc
  or listserv are the same, except the contents of DDIIRR//iinnllooccaall and
  DDIIRR//oouuttllooccaall need to be changed appropriately.

  1166..22..11..  SSeettttiinngg uupp tthhee ddiirreeccttoorryy ssttrruuccttuurree..

  The author's preference is to use the name of the mailing list manager
  ezmlm is masquerading as as the name of its directory. Thus, a
  directory should be made in your ``alias'' users home directory
  (usually //vvaarr//qqmmaaiill//aalliiaass//). Easiest is to:

               % su
               # su alias
               # cd ~alias
               # tar zxvf ..../ezdomo.tar.gz

  The eezzddoommoo// directory should be owned by user ``alias'', group
  ``qmail'', with permissions 700. It should contain the files from the
  eezzddoommoo..ttaarr..ggzz file and will look like this when in place:

        ezdomo/:
       -rw-r--r-- 1 alias  qmail  644 Jun 15 21:04 config
       -rw-r--r-- 1 alias  qmail   45 May 26 20:02 headerremove
       -rw-r--r-- 1 alias  qmail    9 May 26 20:20 inlocal
       -rw-r--r-- 1 alias  qmail   20 May 26 20:21 outhost
       -rw-r--r-- 1 alias  qmail    9 May 26 20:21 outlocal

        ezdomo/text:
       -rw-r--r-- 1 alias  qmail  619 Jun  1 22:13 bottom
       -rw-r--r-- 1 alias  qmail 1811 Jun 15 21:02 help
       -rw-r--r-- 1 alias  qmail  306 Jun  7 15:08 top

  1166..22..22..  SSeettttiinngg uupp tthhee ffiilleess..

  Other than the ccoonnffiigg__ffiillee, which requires some work, the setup of the
  balance of the files is quite straightforward.  eezzddoommoo//iinnllooccaall,
  eezzddoommoo//iinnhhoosstt, eezzddoommoo//oouuttllooccaall, and eezzddoommoo//oouutthhoosstt need to be
  adjusted, usually to the name you've chosen for the interface, (e.g.
  ``majordomo'') and your host name, for **llooccaall and **hhoosstt, respectively.

  If you use a character set other than US-ASCII, put it's name,
  optionally followed by ``:'' and the desired content-transfer-encoding
  character (``Q'' for quoted-printable and ``B'' for base64) into
  eezzddoommoo//cchhaarrsseett.

  If the ``majordomo'' were being set up for a virtual domain, the setup
  is virtually the same except (1) the directory structure would reside
  under the user controlling the virtual domain, (2) the eezzddoommoo//iinnllooccaall
  file would have the user's name prepended to ``majordomo'', e.g.
  ``user-majordomo'' and (3) the **hhoosstt files would contain the name of
  the virtual domain.

  The eezzddoommoo//ccoonnffiigg__ffiillee contains a list of mailing lists which the
  ``majordomo'' (in this case) can provide information about in the
  following syntax:

         list@host:listdir:description

  To allow the use of the ``lists'' command but not the ``which'' com-
  mand, you would simply omit the ``listdir'' for that line:

         list@host::description

  For the ``which'' command to work, the DDIIRR//, which contains the
  subscriber database, must be readable by the user under which mail is
  delivered. This means that ``which'' is usually limited to lists owned
  by the user or virtual domain under which the ``ezdomo'' interface is
  set up.

  1166..22..33..  SSeettttiinngg uupp tthhee ..qqmmaaiill file.

  The final step in setting up a fully functional majordomo@host which
  is serviced by ezmlm is setting up the ..qqmmaaiill file.  Here the file
  which needs to be established in the ``alias'' user's home directory
  is the file .qmail-majordomo. It must contain the following:

         |/usr/bin/ezmlm/ezmlm-request -f '/var/qmail/alias/ezdomo/config'
         '/var/qmail/alias/ezdomo'

  _(_a_l_l _o_n _o_n_e _l_i_n_e_). This file thus contains a reference to ezmlm-
  request(1), which recognizes and rewrites the commands sent to major-
  domo@host (you may have to adjust your path from that above to point
  to your ezmlm binary directory), using the configuration file
  //vvaarr//qqmmaaiill//aalliiaass//eezzddoommoo//ccoonnffiigg

  1166..33..  CCoommmmaannddss ooff ootthheerr mmaaiilliinngglliisstt mmaannaaggeerrss rreeccooggnniizzeedd bbyy eezzmmllmm..

  1166..33..11..  LLiissttpprroocc//LLiissttsseerrvv..

  When set up as above, substituting ``listproc'' or ``listserv'' for
  ``majordomo'' as appropriate, ezmlm will recognize and respond to the
  following commands placed in the body of the e-mail with the syntax
  below.  NNoottee:: eezzmmllmm wwiillll oonnllyy rreessppoonndd ttoo oonnee ccoommmmaanndd ppeerr mmeessssaaggee..

  ssyynnttaaxx:: ccoommmmaanndd lliissttnnaammee [[ssuubbssccrriibbee@@hhoosstt]]

     SSuuppppoorrtteedd ccoommmmaannddss
        subscribe, sub, unsubscribe, unsub, list, help, review.

     AAddddiittiioonnaall ssuuppppoorrtteedd ccoommmmaannddss
        All ezmlm commands, such as ``thread'', ``index'' and ``get'' as
        well as the list owner's commands.

  This interfaced makes information available via command messages to
  the appropriate mailing list.  Thus, ``list'' and ``review'' will send
  a subscriber list only to remote administrators and only if
  specifically allowed by the list owner.

  1166..33..22..  MMaajjoorrddoommoo..

  ssyynnttaaxx:: ccoommmmaanndd lliissttnnaammee [[ssuubbssccrriibbeerr aaddddrreessss]]

     SSuuppppoorrtteedd ccoommmmaannddss
        lists, subscribe, unsubscribe, help, which, who.

     AAddddiittiioonnaall ssuuppppoorrtteedd ccoommmmaannddss
        All ezmlm user and ezmlm owner commands.

  This interfaced makes information available via command messages to
  the appropriate mailing list.  Thus, ``who'' will send a subscriber
  list only to remote administrators and only if specifically allowed by
  the list owner.

  1166..33..33..  SSmmaarrtt--LLiisstt..

  Unlike ``listproc/listserv'' or ``majordomo'', ``smart-list'' does not
  provide ``host-centric'' services. Rather, commands are addressed to
  listname-request@host and the command placed on the ``Subject:'' line:

         To: listname-request@host
         Subject: command [subscriber address]

  The body of the message is ignored.

     SSuuppppoorrtteedd ccoommmmaannddss
        subscribe, unsubscribe.

     AAddddiittiioonnaall SSuuppppoorrtteedd CCoommmmaannddss
        All ezmlm user and ezmlm owner commands.

  1177..  OOppttiimmiizziinngg lliisstt ppeerrffoorrmmaannccee..

  Ezmlm-idx is designed to make it as easy as possible to set up mailing
  lists.  The default setup works well for small and medium-sized lists.
  For large lists, the lists can be made more efficient with a few
  simple changes.

  1177..11..  CCrroonndd--ggeenneerraatteedd ddiiggeessttss ffoorr bbeetttteerr ppeerrffoorrmmaannccee..

  With the default setup, ezmlm-tstdig(1) in ddiirr//eeddiittoorr tests if a
  digest should be sent out. On lists with a lot of traffic this is
  inefficient.  Also, you may want digests to be delivered as a specific
  time. To do this, use ezmlm-cron(1) or crond(8) to execute ezmlm-
  get(1) directly, as described elsewhere.  See ``Disabling digest
  triggering by mail'' for more info on running ezmlm-get from crond(8).

  1177..22..  OOppttiimmiizziinngg eexxeeccuuttiioonn ooff eezzmmllmm--wwaarrnn((11))..

  ezmlm-warn(1) is executed once per message and once per administrative
  request. The program searches through the bounce directory to find
  bounces that are old enough to warrant _w_a_r_n_i_n_g or _p_r_o_b_e messages.
  This may take a lot of time if there are many bounces. It is more
  efficient to remove all the ezmlm-warn(1) lines from ddiirr//eeddiittoorr and
  ddiirr//mmaannaaggeerr and instead execute ezmlm-warn(1) via crond(8) at off-peak
  times. OIHO opinion, this is best done once per day at times when the
  mail system is least busy. Running it every 12 h or every 6 h, leads
  to smaller amount of mail per run, but the directory parsing is done
  two or four times, rather than once per day. (See ``Customizing bounce
  handling'' for more info on how to set this up.

  1177..33..  DDeeccrreeaassiinngg eezzmmllmm--wwaarrnn((11)) ttiimmee oouutt ttoo iinnccrreeaassee ppeerrffoorrmmaannccee..

  With ezmlm-idx, you may alter the ezmlm-warn(1) timeout to a number of
  seconds with the ``-t seconds'' switch.  The default is 1,000,000
  seconds or about 11.6 days. This is the time from the first bounce
  until ezmlm-warn(1) sends a warning message and the time from the
  warning message bounce until ezmlm-warn(1) sends a probe (which if
  bounced leads to removal of the address from the subscriber list).  If
  you have a digest list, remember to execute ezmlm-warn(1) with the
  ``-d'' switch as well.

  Decreasing the default to e.g. 500,000 will cut in half the average
  number of files in the bounce directory and the number of messages
  sent at each crond(8)-directed invocation of ezmlm-warn(1). The trade-
  off is that worst case, a subscriber may be unsubscribed if his/her
  mail path is defective for more than twice the timeout. Removing a
  subscriber after 10 days seems reasonable on a busy list. Do this by
  adding the ``-t'' switch to all the ezmlm-warn(1) invocations. This
  timeout should be larger than the interval between ezmlm-warn(1)
  invocation.

  If you have a digest list, remember to execute ezmlm-warn(1) with the
  ``-d'' switch as well. However, if the number of digest bounces is
  relatively small, you can use the default for this.

  To be aggressive, use ``ezmlm-warn -t0''. This will minimize the time
  your lists spends servicing bounces, but will for some errors lead to
  subscribers to be also lead to subscribers being removed if messages
  to them bounce for two consecutive ezmlm-warn(1) runs.

  1177..44..  UUssee eezzmmllmm wwiitthhoouutt eezzmmllmm--iiddxx ffoorr mmaaxxiimmuumm ppeerrffoorrmmaannccee..

  ezmlm-idx adds a number of functions to ezmlm. It indexes the archive,
  and adds an index entry for each message, it can remove MIME parts, it
  can add a subject prefix and message trailer, decode rfc2047-encoded
  subjects, etc.  Although designed to impact minimally on performance,
  these options when used take time. Even when they are not used, time
  is spent looking for e.g. the prefix. However, the performance penalty
  is small, as the absolutely dominating cost of a mailing list is the
  work qmail does to deliver the messages to subscribers.
  Still, if you want maximal performance and do not need the features
  added by ezmlm-idx, it is better to use ezmlm alone.

  You could also to ezmlm-0.53 add an individual program patched by
  ezmlm-idx.  For instance, you can use the patched ezmlm-warn(1) to get
  access to the ``-t'' switch, even if all the other programs are
  ezmlm-0.53 only.

  1177..55..  NNoott aarrcchhiivviinngg ttoo mmaaxxiimmiizzee ppeerrffoorrmmaannccee..

  An archived list needs to write the message to the archive. If you
  don't need an archive, don't archive. However, the archive is very
  useful to allow users to catch up on messages that they didn't receive
  due to delivery problems.

  1177..66..  SSuubblliissttss ttoo mmaaxxiimmiizzee ppeerrffoorrmmaannccee..

  Consider splitting your list into sublists, ideally geographically.
  The main list deals only with a subset of subscribers (or only the
  sublists), and each sublist deals with a subset of subscribers,
  bounces, etc. This is the most rational way to scale ezmlm to large
  lists (see ``How sublists work'' for more info on how sublists work
  and ``Sublists'' on how to set up sublists).

  1188..  MMiisscceellllaanneeoouuss

  1188..11..  HHooww ddoo II qquuiicckkllyy cchhaannggee tthhee pprrooppeerrttiieess ooff mmyy lliisstt??

  ezmlm-make (idx >=0.21) has a -e switch for ``edit''. If you have a
  standard list setup (i.e. one created by ezmlm-0.53+/-idx, or ezmlm-
  make with an arbitrary config file, BUT without manual changes), you
  can use the same ezmlm-make arguments WITH the ``-e'' switch and with
  other switches changed to your desired setup. In this mode, ezmlm-make
  will not complain about already existing directories, overwrite
  existing files (without touching message counters and the archive) and
  remove any flags (DDIIRR//rreemmoottee, DDIIRR//mmooddppoosstt, DDIIRR//mmooddssuubb) that are not
  consistent with the new setup.

  If the list was created or has been previously edited with ezmlm-
  make(1) from ezmlm-idx>=0.23, the ezmlm-make(1) arguments are stored
  in DDIIRR//ccoonnffiigg. To edit the list, all you need to do it to specify the
  ezmlm-make ``-e'' switch, all ``letter'' switches that you wish to _u_s_e
  (i.e. no memory), all ``digit'' switches with arguments that you wish
  to _c_h_a_n_g_e (i.e. memory), and the list directory:

               % ezmlm-make -e[c] letter_switches DIR

  NOTE: Any manual changes will be overwritten. Your custom ..eezzmmllmmrrcc
  will be used ONLY if you specify the ``-c'' switch, and remember to
  run ``ezmlm-idx DIR'' if you went from a non-indexed to an indexed
  setup. Remember to make backup copies of such manual changes (such as
  ``welcome'' messages put in your DDIIRR//tteexxtt//ssuubb--ookk ffiillee.)

  If your current setup has message moderation and you wish to
  (temporarily) make it an open list, remove DDIIRR//mmooddppoosstt.

  If your current setup has subscription moderation and you wish to
  (temporarily) make subscription open, remove DDIIRR//mmooddssuubb.
  If your current setup has remote admin, and you switch to
  (temporarily) disable this feature, remove DDIIRR//mmooddssuubb.

  If your current setup lacks remote admin and subscription moderation,
  you need to:

       % mkdir DIR/mod DIR/mod/subscribers
       % touch DIR/modsub
       % touch DIR/remote

  If your current setup has subscription moderation or remote admin, and
  you want to add remote admin or subscription moderation, just create
  the appropriate file (DDIIRR//rreemmoottee or DDIIRR//mmooddssuubb), since the moderator
  database already exists.

  In many cases, it is easier to use the ezmlm-make(1) ``-e'' switch,
  since this will adjust all the DDIIRR//tteexxtt// files as well.  Beware,
  however, that this will overwrite any direct manual customization done
  with means other than editing eezzmmllmmrrcc (see ``Customizing ezmlm-make
  operation'').

  1188..22..  OOppeenn aarrcchhiivveedd lliisstt wwiitthh ddaaiillyy ddiiggeessttss

  This is the default setup. The main list generates digests in response
  to a mailed request or when a message arrives and the amount of
  messages since the last digest exceeds set limits (see ezmlm-
  tstdig(1)).  Alternatively, ezmlm-get(1) can be invoked from the
  command line. In both cases, the generated digest message is
  disseminated to the subscribers stored in DDIIRR//ddiiggeesstt//ssuubbssccrriibbeerrss//,
  i.e. the subscriber database with the base directory DDIIRR//ddiiggeesstt//.

  +o  See ``setting up a digest list'' on how to set up the lists.

  +o  See ``Generating daily digests'' on how to trigger daily digests
     via e-mail.

  +o  See ``Generating digests after a certain time, number, or amount of
     messages'' on how to generate digests directly, dependent on a
     number of criteria.

  1188..33..  VVaarriiaattiioonnss iinn mmooddeerraattiioonn

  You can set up lists with combinations of message moderation,
  subscription moderation, and remote administration, easiest by
  combining ezmlm-make(1) ``-m'' ,``-s'', and ``-r'' switches. You can
  use a non-default moderator db, by specifying a directory starting
  with a slash in DDIIRR//mmooddssuubb or DDIIRR//rreemmoottee (for remote admin and
  subscription moderation - always the same db for both functions) or in
  DDIIRR//mmooddppoosstt for message moderation. You can point several lists to the
  same moderator db, thus using the same moderators for several lists.
  _N_O_T_E_: 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(1) 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'').

  1188..44..  LLiissttss tthhaatt aallllooww rreemmoottee aaddmmiinn,, bbuutt nnoott uusseerr iinniittiiaatteedd ssuubbssccrriipp--
  ttiioonn oorr aarrcchhiivvee rreettrriieevvaall..

  Create a regular remote admin list, but remove DDIIRR//ppuubblliicc.  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 message posting to the list'').

  1188..55..  LLiissttss tthhaatt aallllooww rreemmoottee aaddmmiinn,, uusseerr aarrcchhiivvee rreettrriieevvaall,, bbuutt nnoott
  uusseerr--iinniittiiaatteedd ssuubbssccrriippttiioonn..

  Create a regular remote admin list, remove DDIIRR//ppuubblliicc, and add the
  ``-p'' public switch to the ezmlm-get(1) command line in DDIIRR//mmaannaaggeerr.
  This overrides the normal DDIIRR//ppuubblliicc effect on ezmlm-get(1) 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 ~~//..qqmmaaiill--lliissttnnaammee--hheellpp to DDIIRR//hheellpp,
  and invoke a script that copies help info from there. See ezmlm-
  check(1) for an example.

  1188..66..  LLiissttss tthhaatt rreessttrriicctt aarrcchhiivvee rreettrriieevvaall ttoo ssuubbssccrriibbeerrss..

  Use a standard list, but add the ezmlm-get(1) ``-s'' command line
  switch in DDIIRR//mmaannaaggeerr. Only subscribers can receive archive excerpts.
  Digests work as usual.

  1188..77..  LLiissttss tthhaatt ddoo nnoott aallllooww aarrcchhiivvee rreettrriieevvaall aatt aallll..

  Use a standard list, but add the ``-C'' switch to both the ezmlm-
  get(1) and ezmlm-manage(1) command lines in DDIIRR//mmaannaaggeerr. No archive
  retrieval commands will be honored. Digest can be created as usual
  (See ``Restricting archive retrieval'').

  1188..88..  LLiissttss tthhaatt ddoo nnoott aallllooww aarrcchhiivvee rreettrriieevvaall aanndd ddoo nnoott aallllooww
  ddiiggeesstt ttrriiggggeerriinngg ppeerr mmaaiill..

  For maximal archive security, set up a normal indexed and archived
  list, then remove the ezmlm-get(1) line from DDIIRR//mmaannaaggeerr and add the
  ``-C'' switch to the ezmlm-manage(1) command line. You can still
  create digests by direct invocation of ezmlm-get(1) from a script or
  crontab entry.  (See ``Disabling digest triggering by mail'').

  1188..99..  LLiissttss tthhaatt aallllooww aarrcchhiivvee rreettrriieevvaall oonnllyy ttoo mmooddeerraattoorrss,, bbuutt
  aallllooww uusseerr--iinniittiiaatteedd ssuubbssccrriippttiioonn..

  Create a normal remote admin (+ subscription moderated) list, and add
  the ``-P'' (not public) switch to the ezmlm-get(1) command line in
  DDIIRR//mmaannaaggeerr. Subscription will not be affected, but ezmlm-get(1) will
  send archive excerpts only to moderators.  Digests are unaffected.

  1188..1100..  LLiissttss tthhaatt ddoo nnoott rreeqquuiirree uusseerr ccoonnffiirrmmaattiioonn ffoorr ((uunn))ssuubbssccrriipp--
  ttiioonn..

  The need for a user handshake can be eliminated by the ezmlm-manage(1)
  ``-S'' (subscribe) and/or ``-U'' (unsubscribe) switches. Alone, this
  is very insecure. However, there may be some use for it in local lists
  with subscription moderation, or alone for notifications where ease of
  use is more important than preventing users from (un)subscribing
  others. If the list has subscription moderation or remote
  administration, any user subscribe or unsubscribe request is forwarded
  to the moderators if the SENDER and target address do not match, even
  if the ``-U/-S'' switches are specified. This is put in place to make
  a ``-U/-S'' list similar to other list managers, not for security
  (it's not secure, since a malicious outsider can easily fake the
  SENDER address). Unsubscribe confirmations are sent also to the target
  in this case, to avoid situations where the user needs moderator
  ``permission'' to get off the list.

  1188..1111..  LLiissttss tthhaatt rreessttrriicctt aarrcchhiivvee rreettrriieevvaall..

  Use the ezmlm-make(1) ``-g'' switch to get a low-security convenient
  option base on SENDER checks or for a more secure version see
  ``Restricting ... (higher security option)''.

  1188..1122..  AAnnnnoouunncceemmeenntt lliissttss ffoorr aa ssmmaallll sseett ooff ttrruusstteedd ppoosstteerrss

  Set up the list with ezmlm-store(1) ``-P'' and add the ``trusted E-
  mail addresses'' to DDIIRR//mmoodd// with

       % ezmlm-sub DIR/mod address@host

  A post from a ``trusted address'' is sent back to that address for
  approval, assuring that the user at that address really sent the post.
  Posts from other e-mail addresses are rejected.

  1188..1133..  AAnnnnoouunncceemmeenntt lliissttss aalllloowwiinngg mmooddeerraatteedd ppoossttss ffrroomm aannyyoonnee

  This is useful in many circumstances. A list announcing new programs
  for a system, where both the main developers and other users may have
  contributed programs.

  Set up the list with ezmlm-store(1) and the main developers as
  moderators. When any of these posts, that user alone is asked to
  confirm. Posts from other E-mail addresses are sent to all
  moderators/developers.  To use a different set of E-mail addresses as
  ``trusted e-mail addresses'' and moderators for other posts, use the
  ezmlm-store(1) ``-S'' switch and make a separate address database for
  the ``trusted E-mail addresses''.  Put the name of the basedir for the
  ``trusted e-mail addresses'' database in DDIIRR//mmooddppoosstt (needs leading
  ``/''), and add the post moderator(s) to DDIIRR//mmoodd// using ezmlm-sub(1)
  as shown above.

  1188..1144..  AAnnnnoouunncceemmeenntt lliissttss wwiitthh lleessss sseeccuurriittyy aanndd mmoorree ccoonnvveenniieennccee..

  A general solution for SENDER checking is to configure list with
  ezmlm-gate(1).  ezmlm-gate(1) takes as arguments any number of
  basedirs for subscriber lists. Posts from SENDERs that are found are
  posted. For others ezmlm-store(1) is invoked. If DDIIRR//mmooddppoosstt exists,
  ezmlm-store(1) will send out other messages for moderation.  To bounce
  such messages, create DDIIRR//mmooddppoosstt, and use the ezmlm-gate(1) ``-P''
  switch (will be passed on to ezmlm-store(1) to bounce any posts not
  from a moderator).

  By default, ezmlm-gate(1) accepts messages from subscribers. However,
  this is overridden if any ``basedirs'' are put on the ezmlm-gate(1)
  command line. Common would be to create a address list and put its
  ``basedir'' on the ezmlm-gate(1) command line. Trusted E-mail
  addresses can then be added with:

       % ezmlm-sub basedir trusted@host

  As this relies on SENDER checks it is less secure than the ezmlm-store
  based confirmation-requiring setup.

  1199..  EEzzmmllmm--iiddxx ccoommppiillee ttiimmee ooppttiioonnss

  1199..11..  LLooccaattiioonn ooff bbiinnaarriieess..

  This is configured via ccoonnff--bbiinn as for other ezmlm programs.  The
  default is //uussrr//llooccaall//bbiinn//eezzmmllmm.

  1199..22..  LLooccaattiioonn ooff mmaann ppaaggeess..

  This is configured via ccoonnff--mmaann as for other ezmlm programs.  The
  default is //uussrr//llooccaall//mmaann.

  1199..33..  BBaassee ddiirreeccttoorryy ooff qqmmaaiill--iinnssttaallllaattiioonn..

  This is configured via ccoonnff--qqmmaaiill as for other ezmlm programs.  The
  default is //vvaarr//qqmmaaiill.

  1199..44..  SShhoorrtt hheeaaddeerr tteexxttss,, eettcc..

  Ezmlm-idx text (short lines, such as ``Administrivia'' for digests),
  command names, etc, are defined in iiddxx..hh, used at compile time. You
  can change them by changing the defines in this file.

  1199..55..  AArrbbiittrraarryy lliimmiittss..

  iiddxx..hh contains defines for some ezmlm-idx arbitrary limits, such as
  the maximum number of messages per ``-get'' request. They can be
  changed here.

  1199..66..  CCoommmmaanndd nnaammeess..

  There is support for one alias per user command for
  internationalization.  (See ``Multiple language support''.)

  1199..77..  EErrrroorr mmeessssaaggeess..

  All ezmlm-idx error messages are defines in eerrrrttxxtt..hh, used at compile
  time. These can be changed for special situations, but we would advise
  against doing so. If you do for some reason produce such a translated
  file, we would appreciate if you sent a copy to the authors. NOTE:
  These do not affect error messages from programs that are not part of
  the ezmlm-idx package, nor of some subroutines used by ezmlm-idx
  programs (getconf_line.c comes to mind).

  Hopefully, the error messages for all parts will be synchronized in
  later versions of ezmlm, and possibly handled from a run-time
  changeable separate file (maybe as a .cdb database).

  1199..88..  PPaatthhss aanndd ootthheerr oodddd ccoonnffiigguurraattiioonn iitteemmss..

  idx.h also has defines for //eettcc//eezzmmllmmrrcc, default formats for
  moderation enclosures, default character set, default digest format,
  etc. Since most of these items are easily changed at run time, there
  is usually no need to change the compiled-in defaults. If you do need
  to, this is where they are.

  2200..  MMuullttiippllee llaanngguuaaggee ssuuppppoorrtt..

  2200..11..  CCoommmmaanndd nnaammeess..

  ezmlm commands can have aliases for use in translations for non-
  English use.  Due to the use of commands in mail e-mail addresses, the
  character set is limited by RFC822 to us-ascii. To enable the command
  aliases, remove the comment marks around the INTL_CMDS define in
  idx.h. Also, remove the comments from the define corresponding to one
  language (currently, only LANG_FR - French) available.

  The INTL_CMDS define results in the compilation of all ezmlm programs
  with support for alias commands for those commands listed in the INTL
  section (all that are used directly by users). All aliases MUST be
  defined, but should be the normal English commands. The language-
  specific sections undefine and redefine the commands for which
  alternative names should be used. This allows use of e.g.
  ``inscription'' as an alias in addition to the standard ``subscribe''.

  2200..22..  TTeexxtt ffiilleess..

  Most ezmlm responses are made from text files in DDIIRR//tteexxtt//. These are
  created from the template file ``ezmlmrc''. Thanks to Frank Denis, and
  Masashi Fujita, Wanderlei Antonio Cavassin, Sergiusz Pawlowicz, Frank
  Tegtmeyer, Torben Fjerdingstad, and Sebastian Andersson, French,
  Japanese, Portugese (var. Brazil), Polish, German, Danish, and Swedish
  versions are available. Just:

               % cp ezmlmrc ezmlmrc.jp
               % cp ezmlmrc.jp ezmlmrc

  before

               # make setup

  or just copy eezzmmllmmrrcc..jjpp to //eettcc//eezzmmllmmrrcc, where it will override the
  copy installed in the ezmlm binary directory.  If you have made an
  eezzmmllmmrrcc version for another language, please make it public domain and
  E-mail it as an attachment to lindberg@id.wustl.edu. It will then be
  put into the eezzmmllmmrrcc directory of the distribution site. Please take
  advantage of the ``Content-transfer-encoding'' capability of ezmlm-
  idx>=0.30, if needed, as this avoids problems when messages are sent
  via non-8-bit MUAs.

  Other ezmlm responses, such as words in subject lines, are defines in
  iiddxx..hh and can be changed there. Error messages should ideally not be
  altered. However, it may make sense to change a few of them which are
  used as messages to e.g. remote administrators. The defines for all
  error messages are in eerrrrttxxtt..hh.

  2200..33..  MMuullttii--bbyyttee cchhaarraacctteerr ccooddee ssuuppppoorrtt

  ezmlm, as far as we know, places no restrictions on character sets.
  The configurable default character set allows you to use other
  character sets for out going ezmlm messages. ezmlm-make does not _p_e_r
  _s_e support other character sets. However, any single-byte character
  set is supported, as long as the us-ascii character sequence ``</''
  does not occur anywhere as the first characters of the line, and the
  character sequence ``<#x#>'' (where ``x'' is any number, or A, B, C,
  D, F, H, L, R, T) does not occur anywhere is text (if it does, it
  risks being substituted). Also, any occurrence or ``<#A#>'' and
  ``<#R#>'' that is the first on any text line will be substituted by
  ezmlm-manage and ezmlm-store. Any occurrence of ``!A'' and ``!R'' as
  the first characters on a line will be substituted by ezmlm-manage and
  ezmlm-store.

  For multi-byte character codes, the same restrictions apply.  Thus,
  ``</'' at the start of a line will confuse ezmlm-make, and any
  ``<#x#>'' sequence within the text risks substitution. In practice,
  both of these should be very rare and easily avoidable when setting up
  an ezmlmrc.

  2211..  SSuubbssccrriibbeerr nnoottiiffiiccaattiioonn ooff mmooddeerraattiioonn eevveennttss

  2211..11..  GGeenneerraall ooppiinniioonnss

  This is a collection of the authors opinions and an explanation of
  ezmlm-idx moderation design, which you may or may not agree with.

  2211..22..  UUsseerrss sshhoouulldd kknnooww tthhaatt tthhee lliisstt iiss ssuubbssccrriippttiioonn mmooddeerraatteedd

  List subscribers should be informed that subscriptions to the list are
  controlled by a moderator.  ezmlm-idx in its default setup handles
  this notification during and after the subscribe handshake. Most of
  this can be disabled by manipulation of the DDIIRR//tteexxtt// files.

  2211..33..  SSuubbssccrriibbeerrss sshhoouulldd kknnooww tthhaatt ppoossttss aarree mmooddeerraatteedd

  List subscribers should be informed that posts to the list are
  moderated. ezmlm-idx does this by adding the ``Delivered-To: moderator
  for ...'' header, but IOHO, the list owner should make the fact of
  list moderation plain in introductory messages, or other means, to the
  list subscribers.

  2211..44..  SSeennddeerrss ooff ppoossttss sshhoouulldd bbee nnoottiiffiieedd ooff rreejjeeccttiioonnss

  With normal use of ezmlm-idx, the sender of a rejected post is
  notified that the post has been rejected and if the moderators chooses
  to comment, the sender receives this comment, usually describing why
  the post was rejected.  This ezmlm behavior cannot be disabled at run
  time.

  If post are neither accepted or rejected, they time out. ezmlm-
  clean(1) notifies the sender when this happens. This behavior can be
  disabled with the ezmlm-clean(1) ``-R'' (not return) switch, which has
  to be placed on the command line of all invocations of ezmlm-clean(1)
  (normally in DDIIRR//eeddiittoorr and DDIIRR//mmooddeerraattoorr).  If you for some reason do
  not wish to inform the sender of your editorial decision, you can use
  this switch and let undesirable posts time out, rather than actively
  rejecting them. IOHO, it is better to be "above board" and use the
  normal notification mechanisms, together with active rejection and
  informative rejection comments.

  The ezmlm-make(1) ``-u'' switch uses moderation in a slightly
  different way. Here, posts are restricted to subscribers, but posts
  from non-subscribers are sent to the moderator(s) rather that being
  ignored. This to help the subscriber that posts from an alias of the
  subscribed address, or the occasional non-subscriber. In this case it
  is perfectly acceptable to just ignore non-accepted posts. Thus, using
  the ezmlm-make(1) ``-u'' switch configures the ezmlm-clean(1)
  invocations with the ``-R'' switch.

  2222..  EEzzmmllmm--iiddxx sseeccuurriittyy

  2222..11..  GGeenneerraall aassssuummppttiioonnss

  This document discusses security aspects of ezmlm-idx addition to the
  ezmlm-0.53 mailing list manager. This is the authors' understanding of
  security aspects of ezmlm-idx functions and not to be taken as a
  warranty. If you find any errors in this document or the ezmlm-idx
  package in general, please inform the authors.

  In general, ezmlm with or without the ezmlm-idx package is more secure
  and less resource hungry than most other mailing list managers. Better
  security than afforded by ezmlm +/- ezmlm-idx would require encryption
  or PGP/digital signatures. Such an addition would make it difficult,
  if not impossible, to run the mailing list from a standard MUA. The
  ezmlm-idx package adds a number of functions and options, which under
  some conditions may decrease security. The purpose of this document is
  to discuss security aspects of using/enabling these different
  functions.

  2222..22..  SSEENNDDEERR mmaanniippuullaattiioonn

  We assume that the cost of manipulating/falsifying the SENDER address
  of a message is zero. Thus, any mechanism relying on SENDER alone is
  presumptively insecure. However, such a mechanism may help in case of
  simple mailer or user errors. We also assume that the "cookies" used
  by ezmlm are secure, i.e.  that it is very hard for someone to
  generate a valid cookie for a given address. SENDER is used to
  identify a moderator for remote administration of subscriptions. The
  result of the action or the confirmation request are sent back to that
  moderator address.  Thus, providing a false SENDER is useless, unless
  the attacker can also read that moderator's mail.

  2222..33..  eezzmmllmm ccooookkiieess

  Since ezmlm doesn't rely on the SENDER, the security lies entirely
  within the action-time-cookie-address combination.  Anyone obtaining a
  valid "combination" can do whatever the combination is meant to do,
  but nothing else. Also, the cookie times out 1000000 seconds
  (approximately 11.6 days) after it was issued. Since the
  "combinations" are specific for a particular action and address, they
  can only be reused for that particular purpose, and within 11.6 days.
  Ezmlm (un)subscriptions for a given address are usually pointless to
  repeat. Message moderation "combinations" are useless after they've
  been used, since the message is no longer in the moderation queue.

  2222..44..  LLiissttss wwiitthhoouutt rreemmoottee aaddmmiinn//ssuubbssccrriippttiioonn mmooddeerraattiioonn

  Maliciously (un)subscribing an address with ezmlm-0.53 requires that
  the attacker is able to read mail sent to the subscription address.

  With the ezmlm-idx add-on, a non-moderated list works exactly the same
  way. Ezmlm-idx introduces the moderator for moderated and remote admin
  lists. For any moderator functions, an attacker needs to be able to
  read mail sent to a moderator's address. If s/he can do this, the
  attacker can affect anything the moderator is allowed to do (since
  falsifying SENDER is trivial). To minimize risks, give moderators only
  the power they need, do not use more moderators than necessary, and
  use moderators whose mail is hard to intercept (on the same
  machine/same internal/secure network or by encryption via e.g. ssh).

  2222..55..  MMeessssaaggee mmooddeerraattiioonn

  A basic message moderated list keeps ezmlm subscriber security, but
  interpolates the moderator(s) between the address of the list and the
  list itself. An attacker able to read moderator mail can accept/reject
  a post, if s/he can do it before a regular moderator has taken action.
  The potential for abuse can be minimized by using few and local
  moderators. Mail logs are needed to trace which moderator address was
  misused.

  2222..66..  SSuubbssccrriippttiioonn mmooddeerraattiioonn

  A basic subscription moderated list retains ezmlm subscriber security,
  but adds a moderator handshake. An attacker would need to be able to
  both read mail to the subscriber address and to at least one
  moderator.

  2222..77..  RReemmoottee aaddmmiinniissttrraattiioonn

  A remote admin (-r) list adds the ability of the moderator to
  (un)subscribe any address. The price of this is that an attacker able
  to read moderator mail can (un)subscribe any address. The moderator
  handshake message will be delivered to the abused moderator address,
  which will alert that moderator and reveal the compromise. Another
  basic assumption is that action-date-cookie-address combinations are
  only sent to the target address or a moderator and that moderator
  action "combinations" are never sent to non-moderators.

  2222..88..  RReemmoottee eeddiittiinngg ooff eezzmmllmm tteexxtt ffiilleess..

  ezmlm-manage(1) can allow remote administrators to edit files in
  DDIIRR//tteexxtt.  First, this option is disabled by default. Second, the
  ``-edit'' command is accepted only when the target (the recipient) is
  a remote administrator.  Third, only existing files within DDIIRR//tteexxtt
  are editable.  It is not possible to create files.

  ezmlm replies to a valid request with an informative message and the
  contents of the file. In addition, the ``Reply-To:'' address contains
  a cookie based on the file name and contents, as well as the current
  time.  Anyone possessing this cookie can save a new version of the
  text file. As with other ezmlm security, the security of this process
  depends on only the remote administrator receiving remote
  administrator mail. If this is not sufficiently secure for you, do not
  enable this option. As always, an increase in accessibility results
  results in a decrease in security.

  Cookies for editing expire in approximately 27 hours. Also, as soon as
  a file is changed, the cookie is invalidated since the file contents
  change.  This also means that an outstanding edit request cannot be
  completed if the files has been updated in the interim.

  A potential attacker obtaining a valid cookie has a window of
  opportunity while you edit the file, or for at most 27 hours. S/he can
  overwrite and existing text file with potentially offensive material.
  Usually, this can be achieved more easily by posting to the list. S/he
  can also potentially fill your disk with a large amount of data (up to
  two times 10240 bytes (limited by MAXEDIT in iiddxx..hh)) and could put
  part of this data onto messages leaving the list. Again, this is much
  more easily achieved by e.g. sending the equivalently sized message to
  your list.

  2222..99..  DDiiggeesstt ggeenneerraattiioonn aanndd aarrcchhiivvee rreettrriieevvaall

  The archive retrieval functions added by ezmlm-idx are digests
  (protected by a "code") and other functions. Anyone who knows the
  digest code (through reading mail logs, reading DDIIRR//mmaannaaggeerr of the
  list, or reading any scripts used to send digest triggering messages)
  can trigger a digest. Protect these locations accordingly!  For
  default lists with digests triggered from DDIIRR//eeddiittoorr via ezmlm-
  tstdig(1) and ezmlm-get(1), you do not need the digest code and can
  thus disable the possibility to trigger digest by mail.  For other
  functions, the output is sent to SENDER and can be restricted to
  subscribers (the ``-s'' switch). ezmlm-get(1) functions (apart from
  digest) can be entirely disabled with the i``-C'' switch, or
  restricted to moderators with the ``-P'' switch or by removing
  DDIIRR//ppuubblliicc. Other sections of this document discuss several other
  options. All switches are documented in the man pages.

  The moderator support functions added by the ezmlm-idx package
  (extended help and subscriber list) are sent only to a moderator
  address, i.e. an attacker again needs to be able to read moderator
  mail to read the output. The help info (DDIIRR//tteexxtt//mmoodd--hheellpp) should not
  contain secrets. The ``-list'' function is normally disabled, but can
  be enabled with the ezmlm-manage -l switch to aid the remote
  administrator(s).

  2222..1100..  CCoonnvveenniieennccee ffoorr sseeccuurriittyy:: tthhee eezzmmllmm--mmaannaaggee ````--SS'''' aanndd ````--UU''''
  sswwiittcchheess

  ezmlm-manage(1) functions can be made more convenient, at the expense
  of security. There have been many requests for these options, so they
  have been added, although we recommend against using them:

  The ezmlm-manage(1) ``-S'' switch eliminates the subscriber handshake
  from subscribe requests. Thus, it is no longer necessary for the
  subscriber to confirm the subscription. This is not secure, but may be
  convenient for some moderated lists.  Use only with extreme caution.
  The ezmlm-manage(1) ``-U'' switch similarly eliminates subscriber
  confirmation from unsubscribe requests. Again, this is insecure and
  useful only under special circumstances. If the list has any
  moderators (remote or modsub), requests to (un)subscribe an address
  other than sender are still routed to a moderator. This is similar to
  how some other lists work. Naturally, this is insecure because it
  relies on SENDER.  Unsubscribe requests are always non-moderated,
  since, IOHO, it seems un-ethical to force a subscriber to remain on a
  list. Where an unsubscribe confirm request is sent out it is (also)
  sent to the target, except when the request was initiated by a
  moderator on a list with remote administration (DDIIRR//rreemmoottee exists).
  The (un)subscription target is always informed about completed
  (un)subscribe request, whether initiated by that address, another
  address, or by a moderator. Thus, attempts of a user or moderator to
  subscribe an address will be brought to the attention of the user
  receiving mail at that address.

  2222..1111..  DDeenniiaall ooff sseerrvviiccee

  ezmlm-get(1) archive retrieval functions can be used to deplete system
  resources. However, this can also be done by posting messages to
  lists, mail bombing, etc. If you are worried about this, you can use a
  combination of ezmlm-manage/ezmlm-get ``-C'', ``-s'', and ``-P''
  switches, removal of DDIIRR//ppuubblliicc, and removal of the mail-triggered
  digest function (by removing the digest code from the ezmlm-get(1)
  command line) to decrease availability of these functions (see man
  pages). Digest can also be triggered by direct execution of ezmlm-get
  from within a script (See ``Disabling digests triggered by mail'') or
  from DDIIRR//eeddiittoorr as in the default setup with the ezmlm-make(1) ``-d''
  switch.

  2222..1122..  MMooddeerraattoorr aannoonnyymmiittyy

  Anyone getting messages from the list can see the ``Delivered-To:
  Moderator for ...'' header and realize that the list is moderated.  In
  the authors opinion, this is fair and appropriate. If this bothers
  you, edit the source of eezzmmllmm--ssttoorree..cc.

  While the fact that the list is moderated will be disclosed by the
  headers, the moderator(s)' identity will not be disclosed by the
  header. Moderators are anonymous to anyone who cannot directly read
  the mail log, the moderator list, or monitor your outgoing and
  incoming mail. Anyone intercepting the acting moderators' mail or able
  to read the mail log can determine who took a particular action.

  Moderator E-mail addresses are not (to our knowledge) disclosed by any
  ezmlm mechanism. Thus, the poster does not know who rejected/accepted
  the message. Other moderators can find out that the message was
  accepted (by seeing it on the list or by themselves committing to a
  reject/accept reply) or rejected (by being informed by the poster or
  by themselves committing to a reject/accept reply). If no moderator
  takes any action for a given time (120 h - configurable to anything
  24-240 h via DDIIRR//mmooddttiimmee - and the parameters are likewise
  configurable at compile time via iiddxx..hh) the message times out, an act
  for which no particular moderator can be held accountable.

  Subscription requests are acted upon only if a moderator completes the
  transaction by approving the requests. Requests can not be directly
  disapproved, but the associated cookie becomes invalid after
  approximately 11.6 days. Neither the subscriber nor the other
  moderators know which moderator accepted the subscription request.
  Requests to unsubscribe from the list are never moderated or otherwise
  controlled, except by requiring confirmation from the subscriber
  (normal unsubscribe) or the moderator that initiated the request
  (remote administration). If several moderators approve the same
  subscribe request, the user gets multiple notifications.

  The triggering message (the moderation approval or the moderator's
  completion of the subscription request) are not returned or logged.
  This protects moderator anonymity, but makes it harder to track down
  the offender in case of abuse. Only a good mail log will help. IOHO,
  abuse of these mechanisms requires considerably more effort that it is
  worth to (un)subscribe someone to a list.  Also, IOHO, moderator
  anonymity is more important. If this increased difficulty in tracking
  down abusive behavior bothers you, don't use the remote administration
  and moderated subscription features.

  2222..1133..  CCoonnffiiddeennttiiaalliittyy ooff ssuubbssccrriibbeerr EE--mmaaiill aaddddrreesssseess

  The optional ``-list'' command enabled by the ``-l'' ezmlm-manage(1)
  command line switch returns a subscriber list to the moderator. Again,
  anyone who can intercept a moderators' mail can fake SENDER and use
  this command to obtain a subscriber list. The use of local moderators
  minimize the risk. If the risk of subscriber disclosure is not worth
  this convenience, do not enable this feature.

  2222..1144..  HHeellpp mmeessssaaggee ffoorr mmooddeerraattoorrss

  ezmlm-manage sends DDIIRR//tteexxtt//mmoodd--hheellpp, rather than DDIIRR//tteexxtt//hheellpp in
  reply to messages to list-help@host if the target address is a
  moderator.  DDIIRR//tteexxtt//mmoodd--hheellpp should not contain secrets or other
  confidential information.

  2222..1155..  RReeppoorrttiinngg sseeccuurriittyy pprroobblleemmss

  Please send private E-mail about any security problems with the ezmlm-
  idx additions to Fred Lindberg, lindberg@id.wustl.edu.  For ezmlm,
  please send them via private E-mail to Dan J. Bernstein, the author of
  ezmlm proper.