+ EZFAQ 0.40 - ezmlm-idx and ezmlm FAQ
+ Fred Lindberg, lindberg@id.wustl.edu & Fred B. Ringel,
+ fredr@rivertown.net
+ 22-NOV-1999
+
+ 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.40.
+ ______________________________________________________________________
+
+ Table of Contents
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 1. General Information
+
+ 1.1 Acknowledgements
+ 1.2 What is this document?
+ 1.3 Terminology
+ 1.4 What is the difference between ezmlm and ezmlm-idx?
+ 1.5 Where can I get all of the ezmlm-related programs?
+ 1.6 Where can I find documentation for ezmlm and patches?
+ 1.7 Where do I send comments on this document?
+ 1.8 How to experiment with new versions of ezmlm-idx.
+
+ 2. Quick start
+
+ 3. Overview of mailing list management and mailing list managers
+
+ 4. Overview of ezmlm function
+
+ 4.1 The basic setup.
+ 4.2 Inventions in ezmlm.
+ 4.3 The qmail delivery mechanism.
+ 4.4 What the different programs do.
+ 4.5 What the different files in the list directory do.
+ 4.6 The paper path for posts.
+ 4.7 The ezmlm path for moderation messages.
+ 4.8 The ezmlm path for administrative messages.
+ 4.9 The ezmlm path for bounces.
+ 4.10 Messages to list-owner and list-digest-owner.
+ 4.11 Structure of subscriber databases.
+ 4.12 Local case in E-mail addresses.
+ 4.13 Testing SENDER to allow posts only from list subscribers.
+ 4.14 How cookies work.
+ 4.15 How moderator E-mail addresses are stored.
+ 4.16 How subscription moderation works.
+ 4.17 How remote administration works.
+ 4.18 How message moderation works.
+ 4.19 How QMQP support works
+ 4.20 How messages are stored in the archive.
+ 4.21 How the message index works.
+ 4.22 How threading works.
+ 4.23 How digests work.
+ 4.24 How WWW archive access works.
+ 4.25 How ezmlm-tstdig works.
+ 4.26 How sublists work.
+ 4.27 How sublisting can be made transparent to the user.
+ 4.28 How to service commands in the subject line.
+ 4.29 How to support alternative command names.
+ 4.30 How to add your own commands.
+ 4.31 How remote administrators can retrieve a subscriber list
+ 4.32 How remote administrators can determine the number of subscribers
+ 4.33 How remote admins can see if an address is a subscriber or not
+ 4.34 How remote administrators can search the subscription log
+ 4.35 How text file editing works.
+ 4.36 How subject line prefixes work.
+ 4.37 How bounces are handled.
+ 4.38 How the info and faq commands work.
+ 4.39 How the global ezmlm list address works.
+ 4.40 How ezmlm-cron works.
+ 4.41 How ezmlm-make works.
+ 4.42 What names can I use for my lists?
+ 4.43 Lists in virtual domains
+ 4.44 How do I make customization simple for me/my users?
+
+ 5. ezmlm support for SQL databases.
+
+ 5.1 Why use an SQL database with ezmlm?
+ 5.2 Why not to use an SQL database with ezmlm.
+ 5.3 Tables used for (My)SQL support.
+ 5.3.1 Address tables.
+ 5.3.2 Subscriber log tables.
+ 5.3.3 Message logging tables.
+ 5.4 How to set up a simple list with SQL support.
+ 5.4.1 Helper programs for SQL-enabled lists.
+ 5.5 Manually manipulating the subscribers of a SQL-enabled list.
+ 5.6 Converting to and from and SQL database.
+ 5.7 Optimizing MySQL for ezmlm.
+ 5.7.1 Address SELECTs, additions, removals.
+ 5.8 Maintenance of the MySQL database.
+
+ 6. Possible error conditions in ezmlm lists.
+
+ 6.1 What do I do if ezmlm doesn't work?
+ 6.2 How do I report ezmlm bugs?
+ 6.3 Where do I send suggestions for ezmlm-idx improvements?
+ 6.4 Using ezmlm-test to check the ezmlm(-idx) programs.
+ 6.5 Using ezmlm-check to find setup errors.
+ 6.6 Posts are rejected: Sorry, no mailbox here by that name (#5.1.1).
+ 6.7 Post are not sent to subscribers.
+ 6.8 ezmlm-make fails: usage: ezmlm-make ...
+ 6.9 ezmlm-make fails: Unable to create ...
+ 6.10 ezmlm-make fails: ... ezmlmrc does not exist
+ 6.11 Index/get/thread requests fail quietly or with errors from ezmlm-manage.
+ 6.12 Digest triggering requests fail.
+ 6.13 Remote administration (un)subscribe confirm requests go to the user, not the moderator.
+ 6.14 (Un)subscribers does not receive a (un)subscribe acknowledgement
+ 6.15 Messages posted to a moderated list are sent out without moderation.
+ 6.16 Messages posted to a moderated list do not result in moderation requests.
+ 6.17 Moderation request replies do not result in the appropriate action.
+ 6.18 Moderator comments with moderation request replies are not added to the post/sent to the poster.
+ 6.19 Some headers are missing from messages in the digest.
+ 6.20 Some Received: headers are missing from messages.
+ 6.21 My Mutt users cannot thread their digest messages.
+ 6.22 Posts fail: Message already has Mailing-List (#5.7.2).
+ 6.23 The last line of a
+ 6.24 No CONFIRM requests are sent to moderators.
+ 6.25 Deliveries fail ``temporary qmail-queue error''
+ 6.26 How to deal with corrupted subscriber lists
+ 6.27 Vacation program replies are treated as bounces by ezmlm.
+ 6.28 Digests do not come at regular hours.
+ 6.29 Preventing loops from misconfigured subscriber addresses.
+ 6.30 A user can subscribe and receives warning and probe messages, but no messages from the list.
+
+ 7. Customizing ezmlm-make operation via ezmlmrc
+
+ 7.1 Using ezmlm-make to edit existing lists.
+ 7.2 What is ezmlmrc?
+ 7.3 Changing defaults for
+ 7.4 Changing default moderator directories.
+ 7.5 Adapting ezmlm-make for virtual domains.
+ 7.6 Setting up ezmlm-make for special situations.
+
+ 8. Restricting message posting to the list.
+
+ 8.1 Requiring the list address in To:/Cc: headers.
+ 8.2 Rejecting messages sent from other mailing lists.
+ 8.3 Restricting posts based on the Subject line.
+ 8.4 Restricting the size of posts.
+ 8.5 Restricting posts based on MIME content-type.
+ 8.6 Restricting posts to list subscribers.
+ 8.7 Restricting posts to an arbitrary set of E-mail addresses (higher security option).
+ 8.8 Completely restricting posts.
+ 8.9 A general solution to restricting posts based on SENDER.
+
+ 9. Customizing outgoing messages.
+
+ 9.1 Adding a trailer to outgoing messages.
+ 9.2 Adding a subject prefix to outgoing messages.
+ 9.3 Adding a header to outgoing messages.
+ 9.4 Adding a message number header.
+ 9.5 Removing headers from outgoing messages.
+ 9.6 Removing MIME parts from messages.
+ 9.7 Limiting ``Received:'' headers in outgoing messages.
+ 9.8 Setting ``Reply-To: list@host''.
+ 9.9 Configuring the list so posts are not copied to the original sender.
+ 9.10 Customizing ezmlm notification messages.
+ 9.11 Specifying character set and content-transfer-encoding for outgoing ezmlm messages.
+
+ 10. Customizing archive retrieval.
+
+ 10.1 Specifying the format for retrieved messages.
+ 10.2 Specifying the default format for digests and archive retrieval.
+ 10.3 Limiting the number of messages per -get/-index request.
+
+ 11. Restricting archive retrieval.
+
+ 11.1 Restricting archive access to subscribers.
+ 11.2 Restricting available archive retrieval commands.
+ 11.3 Restricting archive retrieval to moderators.
+ 11.4 Allowing archive retrieval from a non-public list.
+
+ 12. Customizing digests.
+
+ 12.1 Setting up a digest list.
+ 12.2 Generating daily digests.
+ 12.3 Generating the first digest.
+ 12.4 Adding standard administrative information to digests.
+ 12.5 Controlling the digest format.
+ 12.6 Customizing bounce handling.
+
+ 13. Remote administration.
+
+ 13.1 How can I remotely add moderators, subscriber aliases, etc?
+ 13.2 Moderating posts from a secondary account.
+ 13.3 Moderating subscription from a secondary account.
+ 13.4 Automatically approving posts or subscriptions.
+ 13.5 Allowing remote administrators to get a subscriber list.
+ 13.6 Allowing remote administrators to retrieve or search a subscription log.
+ 13.7 Allowing users to get a subscriber list.
+ 13.8 Changing the timeout for messages in the moderation queue.
+ 13.9 Finding out how many messages are waiting for moderation.
+ 13.10 Using the same moderators for multiple lists.
+ 13.11 Using different moderators for message and subscription moderation.
+ 13.12 Setting up moderated lists with the list owner as the ``super moderator'' able to add/remove moderators remotely.
+ 13.13 Customizing ezmlm administrative messages.
+ 13.14 Manually approving a message awaiting moderation.
+ 13.15 Manually rejecting a message awaiting moderation.
+
+ 14. Sublists.
+
+ 14.1 Sublists of ezmlm lists.
+ 14.2 Sublists of non-ezmlm lists.
+ 14.3 How to set up a cluster of list and sublists with standard databases.
+
+ 15. Migration to Ezmlm from other Mailing List Managers.
+
+ 15.1 Basic Concepts.
+ 15.2 Setting up ezmlm to respond to host-centric commands.
+ 15.3 Commands of other mailinglist managers recognized by ezmlm.
+ 15.3.1 Listproc/Listserv.
+ 15.3.2 Majordomo.
+ 15.3.3 Smartlist.
+
+ 16. Optimizing list performance.
+
+ 16.1 Crond-generated digests for better performance.
+ 16.2 Optimizing execution of ezmlm-warn(1).
+ 16.3 Decreasing ezmlm-warn time out to increase performance.
+ 16.4 Use ezmlm without ezmlm-idx for maximum performance.
+ 16.5 Not archiving to maximize performance.
+ 16.6 Sublists to maximize performance.
+
+ 17. Miscellaneous.
+
+ 17.1 How do I quickly change the properties of my list?
+ 17.2 Open archived list with daily digests.
+ 17.3 Variations in moderation
+ 17.4 Lists that allow remote admin, but not user initiated subscription or archive retrieval.
+ 17.5 Lists that allow remote admin, user archive retrieval, but not user-initiated subscription.
+ 17.6 Lists that restrict archive retrieval to subscribers.
+ 17.7 Lists that do not allow archive retrieval at all.
+ 17.8 Lists that do not allow archive retrieval and do not allow digest triggering per mail.
+ 17.9 Lists that allow archive retrieval only to moderators, but allow user-initiated subscription.
+ 17.10 Lists that do not require user confirmation for (un)subscription.
+ 17.11 Announcement lists for a small set of trusted posters
+ 17.12 Announcement lists allowing moderated posts from anyone.
+ 17.13 Announcement lists with less security and more convenience.
+
+ 18. Ezmlm-idx compile time options.
+
+ 18.1 Location of binaries.
+ 18.2 Location of man pages.
+ 18.3 Base directory of qmail-installation.
+ 18.4 Short header texts, etc.
+ 18.5 Arbitrary limits.
+ 18.6 Command names.
+ 18.7 Error messages.
+ 18.8 Paths and other odd configuration items.
+
+ 19. Multiple language support.
+
+ 19.1 Command names.
+ 19.2 Text files.
+ 19.3 Multi-byte character code support.
+
+ 20. Subscriber notification of moderation events.
+
+ 20.1 General opinions.
+ 20.2 Users should know that the list is subscription moderated.
+ 20.3 Subscribers should know that posts are moderated.
+ 20.4 Senders of posts should be notified of rejections.
+
+ 21. Ezmlm-idx security.
+
+ 21.1 General assumptions.
+ 21.2 SENDER manipulation.
+ 21.3 ezmlm cookies.
+ 21.4 Lists without remote admin/subscription moderation.
+ 21.5 Message moderation.
+ 21.6 Subscription moderation.
+ 21.7 Remote administration.
+ 21.8 Remote editing of ezmlm text files.
+ 21.9 Digest generation and archive retrieval.
+ 21.10 Convenience for security: the ezmlm-manage ``-S'' and ``-U'' switches.
+ 21.11 Denial of service.
+ 21.12 Moderator anonymity.
+ 21.13 Confidentiality of subscriber E-mail addresses.
+ 21.14 Help message for moderators.
+ 21.15 Sublists.
+ 21.16 SQL databases.
+ 21.17 Reporting security problems.
+
+
+ ______________________________________________________________________
+
+ 1\b1.\b. G\bGe\ben\bne\ber\bra\bal\bl I\bIn\bnf\bfo\bor\brm\bma\bat\bti\bio\bon\bn
+
+
+ 1\b1.\b.1\b1.\b. A\bAc\bck\bkn\bno\bow\bwl\ble\bed\bdg\bge\bem\bme\ben\bnt\bts\bs
+
+ Many ezmlm users have contributed to improvements in ezmlm-idx. These
+ are listed in the R\bRE\bEA\bAD\bDM\bME\bE.\b.i\bid\bdx\bx 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!
+
+
+ 1\b1.\b.2\b2.\b. W\bWh\bha\bat\bt i\bis\bs t\bth\bhi\bis\bs d\bdo\boc\bcu\bum\bme\ben\bnt\bt?\b?
+
+ This FAQ contains answers to many questions that arise while
+ installing ezmlm, ezmlm-idx, and while setting up and managing ezmlm
+ mailing lists. See ``'' for a brief summary of what is ezmlm and what
+ is ezmlm-idx.
+
+ 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 _\bH_\bO_\bW_\bT_\bO 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.
+
+
+ 1\b1.\b.3\b3.\b. T\bTe\ber\brm\bmi\bin\bno\bol\blo\bog\bgy\by
+
+ This document uses a number of terms. Here are the meanings ascribed
+ to them by the authors.
+
+ D\bDI\bIR\bR
+ The base directory of the list.
+
+
+ S\bSE\bEN\bND\bDE\bER\bR
+ The envelope sender of the message, as passed to ezmlm by qmail
+ via the $SENDER environment variable.
+
+
+ L\bLO\bOC\bCA\bAL\bL
+ The local part of the envelope recipient. For list-get-1@host,
+ it is usually _\bl_\bi_\bs_\bt_\b-_\bg_\be_\bt_\b-_\b1. If host is a virtual domain,
+ controlled by _\bu_\bs_\be_\br_\b-_\bs_\bu_\bb, then local would be _\bu_\bs_\be_\br_\b-_\bs_\bu_\bb_\b-_\bl_\bi_\bs_\bt_\b-_\bg_\be_\bt_\b-_\b1.
+
+
+ m\bmo\bod\bdd\bdi\bir\br
+ Base directory for moderators. Moderator E-mail addresses are
+ stored in a hashed database in m\bmo\bod\bdd\bdi\bir\br/\b/s\bsu\bub\bbs\bsc\bcr\bri\bib\bbe\ber\brs\bs/\b/. By default,
+ ``moddir'' is D\bDI\bIR\bR/\b/m\bmo\bod\bd/\b/.
+
+ To add or remove moderators:
+
+
+ % ezmlm-sub DIR/moddir moderator@host.domain
+ % ezmlm-unsub DIR/moddir moderator@host.domain
+
+
+
+
+
+ d\bdo\bot\btd\bdi\bir\br
+
+ 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, _\bd_\bo_\bt_\bd_\bi_\br
+ is ~\b~a\bal\bli\bia\bas\bs/\b/ if ``root'' creates a list:
+
+
+ # ezmlm-make ~alias/list ~alias/.qmail-list ...
+
+
+
+
+ _\bd_\bo_\bt_\bd_\bi_\br is where the .\b.e\bez\bzm\bml\blm\bmr\brc\bc file is expected when the ezmlm-
+ make(1) ``-c'' switch is used (see ``Customizing ezmlm-make opera-
+ tion'').
+
+
+ e\bez\bzm\bml\blm\bm b\bbi\bin\bna\bar\bry\by d\bdi\bir\bre\bec\bct\bto\bor\bry\by
+ The directory where the ezmlm-binaries are normally stored, as
+ defined at compile time in c\bco\bon\bnf\bf-\b-b\bbi\bin\bn. This is compiled into the
+ programs and does not change just because you have moved the
+ program.
+
+
+ e\bez\bzm\bml\blm\bm-\b-g\bge\bet\bt(\b(1\b1)\b)
+ 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 (replace ``xxx'' with
+ the version number):
+
+
+ % cd ezmlm-idx-0.xxx
+ % man ./ezmlm-get.1
+
+
+
+ b\bba\bas\bse\bed\bdi\bir\br
+ The list directory when referencing the list subscriber address
+ database. For E-mail addresses stored in a set of files within
+ D\bDI\bIR\bR/\b/s\bsu\bub\bbs\bsc\bcr\bri\bib\bbe\ber\brs\bs/\b/, the ``basedir'' is ``DIR''.
+
+
+ a\bad\bdd\bdr\bre\bes\bss\bs d\bda\bat\bta\bab\bba\bas\bse\be
+ A collection of E-mail addresses stored in a set of files within
+ the ``subscribers'' subdirectory of the basedir,
+ D\bDI\bIR\bR/\b/s\bsu\bub\bbs\bsc\bcr\bri\bib\bbe\ber\brs\bs/\b/.
+
+
+ m\bme\bes\bss\bsa\bag\bge\be m\bmo\bod\bde\ber\bra\bat\bto\bor\br
+ 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.
+
+
+ s\bsu\bub\bbs\bsc\bcr\bri\bip\bpt\bti\bio\bon\bn m\bmo\bod\bde\ber\bra\bat\bto\bor\br
+ 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.
+
+
+ r\bre\bem\bmo\bot\bte\be a\bad\bdm\bmi\bin\bni\bis\bst\btr\bra\bat\bto\bor\br
+ 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.
+
+
+ C\bCh\bha\ban\bng\bgi\bin\bng\bg l\bli\bis\bst\bt `\b``\b`o\bow\bwn\bne\ber\brs\bsh\bhi\bip\bp'\b''\b'
+ 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 D\bDI\bIR\bR/\b/.
+
+ To change the ownership of D\bDI\bIR\bR/\b/ 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
+
+
+
+
+
+ 1\b1.\b.4\b4.\b. W\bWh\bha\bat\bt i\bis\bs t\bth\bhe\be d\bdi\bif\bff\bfe\ber\bre\ben\bnc\bce\be b\bbe\bet\btw\bwe\bee\ben\bn e\bez\bzm\bml\blm\bm a\ban\bnd\bd e\bez\bzm\bml\blm\bm-\b-i\bid\bdx\bx?\b?
+
+ ezmlm-0.53 is a qmail-based mailing list manager written by Dan J.
+ Bernstein. It has all the basic functionality of a mailing list
+ manager, such as subscriber address management including automated
+ bounce handling as well as message distribution and archiving.
+
+ ezmlm-idx is an add-on to ezmlm. It adds multi-message threaded
+ message retrieval from the archive, digests, message and subscription
+ moderation, and a number of remote administration function. It
+ modifies the configuration program ezmlm-make(1) so that it uses a
+ text file template rather than compiled-in texts in list creation. In
+ this manner, ezmlm-idx allows easy setup of lists in different
+ languages and customization of default list setup. ezmlm-idx also adds
+ MIME handling, and other support to streamline use with languages
+ other than English. As an ezmlm add-on, ezmlm-idx does not work
+ without ezmlm and tries to be compatible with ezmlm as much as
+ possible. ezmlm-idx also modifies the ezmlm subscriber database to be
+ case insensitive to avoid many unsubscribe problems.
+
+ New in ezmlm-idx-0.40 are better support for announcement lists,
+ support for QMQP to offload message distribution onto external hosts,
+ simplified optional SQL database use (MySQL or PostgreSQL), more
+ flexibility in determining which messages should be moderated, a WWW
+ interface to the list archives, and many small improvements.
+
+ ezmlm-idx-0.32 adds improved handling of very large lists with
+ optimized bounce handling, ezmlm-split(1) for forwarding (un)subscribe
+ requests to sublists to allow sublisting transparent to the
+ subscriber, and SQL support to allow sublisting with improved message
+ authentication and monitoring of list function, as well as dynamic
+ addition/removal/reconfiguration of sublists. Also, subscriber
+ ``From:'' lines are logged with support for finding a subscription
+ address from a name. The qmail DEFAULT variable is used, if present.
+ Together, these additions eliminate the most common problems making
+ ezmlm use and administration even easier.
+
+ This document is a FAQ for ezmlm-idx. However, many of the basic items
+ that are discussed also apply to ezmlm per se. Referring to the two
+ paragraphs above, it should be relatively easy to figure out which
+ features require ezmlm-idx.
+
+
+ 1\b1.\b.5\b5.\b. W\bWh\bhe\ber\bre\be c\bca\ban\bn I\bI g\bge\bet\bt a\bal\bll\bl o\bof\bf t\bth\bhe\be e\bez\bzm\bml\blm\bm-\b-r\bre\bel\bla\bat\bte\bed\bd p\bpr\bro\bog\bgr\bra\bam\bms\bs?\b?
+
+ 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.
+
+
+ D\bDa\ban\bn J\bJ.\b. B\bBe\ber\brn\bns\bst\bte\bei\bin\bn'\b's\bs e\bez\bzm\bml\blm\bm-\b-0\b0.\b.5\b53\b3
+
+ +\bo <ftp://cr.yp.to/pub/software/ezmlm-0.53.tar.gz>
+
+ +\bo <ftp://ftp.ezmlm.org/pub/qmail/ezmlm-0.53.tar.gz>
+
+ +\bo <ftp://ftp.ntnu.no/pub/unix/mail/qmail/ezmlm-0.53.tar.gz>
+
+ +\bo <ftp://ftp.pipex.net/mirrors/qmail/ezmlm-0.53.tar.gz>
+
+ +\bo <ftp://ftp.jp.qmail.org/qmail/ezmlm-0.53.tar.gz>
+
+ +\bo <ftp://ftp.rifkin.technion.ac.il/pub/qmail/ezmlm-0.53.tar.gz>
+
+ +\bo <ftp://ftp.mira.net.au/unix/mail/qmail/ezmlm-0.53.tar.gz>
+
+ +\bo <http://www.qmail.org/>
+
+ T\bTh\bhe\be l\bla\bat\bte\bes\bst\bt v\bve\ber\brs\bsi\bio\bon\bn o\bof\bf e\bez\bzm\bml\blm\bm-\b-i\bid\bdx\bx
+ 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 _\bm_\ba_\by require list changes
+ (see UPGRADE.idx). However, backwards compatibility with
+ ezmlm-0.53 list will be maintained. Thus, this is an issue only
+ if you are already using an older version of ezmlm-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.
+
+ To get the latest features, look for the highest number (``e.g.
+ ezmlm-idx-0.40''). Any bugs in versions with new features are
+ expected to be limited to the new features.
+
+ To get the most solid version, get the highest 3-digit number,
+ i.e. a bug fix. If you already run a version in that series and
+ a new bug fix is released, see CHANGES.idx to determine if it is
+ worthwhile to upgrade. Most bugs so far have been relevant only
+ when using lists in very unusual ways or with rarely used
+ options.
+
+
+ +\bo <ftp://ftp.ezmlm.org/pub/patches/>
+
+ +\bo <ftp://gd.tuwien.ac.at/infosys/mail/qmail/ezmlm-patches/> ftp
+ mirror in Austria.
+
+ +\bo <http://gd.tuwien.ac.at/infosys/mail/qmail/ezmlm-patches/> http
+ access to the same mirror.
+
+ +\bo <ftp://ftp.win.or.jp/pub/network/mail/qmail/ezmlm-idx/> ftp
+ mirror in Japan.
+
+ e\bez\bzm\bml\blm\bmr\brc\bc(\b(5\b5)\b) f\bfi\bil\ble\bes\bs f\bfo\bor\br d\bdi\bif\bff\bfe\ber\bre\ben\bnt\bt l\bla\ban\bng\bgu\bua\bag\bge\bes\bs
+ The latest versions at the time of release of a package are
+ included in that package. Thus, this directory will have a file
+ labeled with the current ezmlm-idx version number only if it has
+ been updated later than the package. ezmlmrc(5) files are
+ updated and new ones are added all the time, also with bug fix
+ releases. Therefore, always look at the latest package. Please
+ note that ezmlmrc may change significantly between versions.
+ Thus, do not expect the ezmlm-idx-0.324 ezmlmrc.es to work with
+ ezmlm-idx-0.40.
+
+ ezmlmrc(5) files contain some release-specific configurations.
+ Do not use a later file (other than from bug fix releases) with
+ an earlier version of the programs. It is usually OK to use a
+ version from an earlier package (see UPGRADE.idx), but some new
+ functionality may nor be available.
+
+ To contribute an ezmlmrc(5) file in a new language, start with
+ the en_US version from the latest package, and send the gzipped
+ file to lindberg@id.wustl.edu. Please leave comments intact and
+ in English and do not change the order of items in the file.
+ This will facilitate maintenance.
+
+
+ +\bo <ftp://ftp.ezmlm.org/pub/patches/ezmlmrc/>
+
+ +\bo <ftp://gd.tuwien.ac.at/infosys/mail/qmail/ezmlm-
+ patches/ezmlmrc/>
+
+ +\bo <http://gd.tuwien.ac.at/infosys/mail/qmail/ezmlm-
+ patches/ezmlmrc/>
+
+ +\bo <ftp://ftp.win.or.jp/pub/network/mail/qmail/ezmlm-idx/ezmlmrc/>
+
+ e\bez\bzm\bml\blm\bm-\b-i\bis\bss\bsu\bub\bb-\b-0\b0.\b.0\b05\b5
+
+ +\bo <ftp://ftp.ezmlm.org/pub/patches/ezmlm-issub-0.05.tar.gz>. Use
+ ezmlm-issub only if you do not use ezmlm-idx. The same
+ functionality is available in ezmlm-idx and the packages are not
+ compatible.
+
+ +\bo Also via mirrors mentioned above.
+
+
+ R\bRP\bPM\bMs\bs a\ban\bnd\bd S\bSR\bRP\bPM\bMS\bS o\bof\bf q\bqm\bma\bai\bil\bl,\b, e\bez\bzm\bml\blm\bm a\ban\bnd\bd e\bez\bzm\bml\blm\bm-\b-i\bid\bdx\bx
+
+ +\bo <ftp://ftp.ezmlm.org/pub/patches/>
+
+ +\bo <ftp://summersoft.fay.ar.us/pub/qmail/>
+
+
+ 1\b1.\b.6\b6.\b. W\bWh\bhe\ber\bre\be c\bca\ban\bn I\bI f\bfi\bin\bnd\bd d\bdo\boc\bcu\bum\bme\ben\bnt\bta\bat\bti\bio\bon\bn f\bfo\bor\br e\bez\bzm\bml\blm\bm a\ban\bnd\bd p\bpa\bat\btc\bch\bhe\bes\bs?\b?
+
+
+ m\bma\ban\bn p\bpa\bag\bge\bes\bs
+ All ezmlm component programs come with their own man pages.
+ Thus, for info on _\be_\bz_\bm_\bl_\bm_\b-_\bs_\be_\bn_\bd, 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
+
+
+
+
+
+ e\bez\bzm\bml\blm\bm(\b(5\b5)\b)
+ General info on ezmlm and list directories is in e\bez\bzm\bml\blm\bm.\b.5\b5:
+
+
+
+ % man ezmlm
+
+
+
+
+ or
+
+
+
+ % cd ezmlm-0.53
+ % man ./ezmlm.5
+
+
+
+
+ _\bN_\bO_\bT_\bE_\b: 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)).
+
+
+ T\bTe\bex\bxt\bt f\bfi\bil\ble\bes\bs i\bin\bn t\bth\bhe\be d\bdi\bis\bst\btr\bri\bib\bbu\but\bti\bio\bon\bn
+ ezmlm comes with a R\bRE\bEA\bAD\bDM\bME\bE file with general instructions, an
+ I\bIN\bNS\bST\bTA\bAL\bLL\bL file with installation instructions, an U\bUP\bPG\bGR\bRA\bAD\bDE\bE file for
+ upgrading from a previous version and a C\bCH\bHA\bAN\bNG\bGE\bES\bS file with
+ information on changes from previous versions. ezmlm-idx comes
+ with similar files suffixed with ``.\b.i\bid\bdx\bx''. 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''.
+
+
+ `\b``\b`E\bEz\bzm\bma\ban\bn'\b''\b',\b, a\ban\bn e\bez\bzm\bml\blm\bm/\b/i\bid\bdx\bx m\bma\ban\bnu\bua\bal\bl
+ The ezmlm manual is a brief manual that is meant for list
+ subscribers, 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:
+
+ +\bo ezman for download <ftp://ftp.ezmlm.org/pub/patches/ezman/>
+
+ +\bo An on-line html version <http://www.ezmlm.org/ezman>
+
+
+ T\bTh\bhi\bis\bs F\bFA\bAQ\bQ
+ This FAQ is built from a sgml source. It is available in the
+ following formats:
+
+ +\bo A text file <ftp://ftp.ezmlm.org/pub/patches/ezfaq.txt.gz>
+
+ +\bo An on-line html version <http://www.ezmlm.org/>
+
+ +\bo Html for download
+ <ftp://ftp.ezmlm.org/pub/patches/ezfaq.html.tar.gz>
+
+ +\bo A postscript (letter) version
+ <ftp://ftp.ezmlm.org/pub/patches/ezfaq.ps.gz>
+
+ +\bo A postscript (A4) version
+ <ftp://ftp.ezmlm.org/pub/patches/ezfaq.ps4.gz>
+
+ +\bo Via mirrors mentioned for the ezmlm-idx package.
+
+ +\bo An up-to-date text version,F\bFA\bAQ\bQ.\b.i\bid\bdx\bx, included with the ezmlm-idx
+ package.
+
+
+ W\bWW\bWW\bW r\bre\bes\bso\bou\bur\brc\bce\bes\bs
+
+ A\bAn\bn o\bon\bn-\b-l\bli\bin\bne\be v\bve\ber\brs\bsi\bio\bon\bn o\bof\bf t\bth\bhi\bis\bs F\bFA\bAQ\bQ
+ <http://www.ezmlm.org/>The main site with an up-to-date
+ mirror list. <http://www.de.ezmlm.org/>German mirror.
+ <http://www.pl.ezmlm.org/www.ezmlm.org/>Polish mirror.
+ <http://www.jp.ezmlm.org/>Japanese mirror.
+ <http://www.pt.ezmlm.org/>Portuguese mirror.
+ <http://www.at.ezmlm.org/>Austrian mirror.
+ <http://www.ca.ezmlm.org/ezmlm/>Canadian mirror.
+
+ G\bGe\ben\bne\ber\bra\bal\bl q\bqm\bma\bai\bil\bl a\ban\bnd\bd e\bez\bzm\bml\blm\bm i\bin\bnf\bfo\bo
+
+ +\bo Dan J. Bernstein's qmail page
+ <http://www.pobox.com/~djb/qmail.html>
+
+ +\bo Dan J. Bernstein's ezmlm page
+ <http://www.pobox.com/~djb/ezmlm.html>
+
+ +\bo Russell Nelson's qmail page <http://www.qmail.org>
+
+ +\bo Mirrors of www.qmail.org <http://www.ISO.qmail.org>.
+ Substitute your two-letter country abbreviation for ``ISO''.
+
+ T\bTh\bhe\be q\bqm\bma\bai\bil\bl m\bma\bai\bil\bli\bin\bng\bg l\bli\bis\bst\bt a\bar\brc\bch\bhi\biv\bve\be
+
+
+ +\bo <http://www.ornl.gov/cts/archives/mailing-lists/qmail/>
+
+ T\bTh\bhe\be e\bez\bzm\bml\blm\bm m\bma\bai\bil\bli\bin\bng\bg l\bli\bis\bst\bt a\bar\brc\bch\bhi\biv\bve\be
+
+ +\bo <http://sunsite.auc.dk/mhonarc-archives/ezmlm/>
+ <http://www.ezmlm.org/archive/> This archive of the ezmlm
+ list is searchable from 11/97-present. ezmlm-cgi(1) is used
+ to allow direct access to the sublist archive.
+
+ M\bMa\bai\bil\bli\bin\bng\bg l\bli\bis\bst\bts\bs
+ 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:
+
+ +\bo Dan Bernstein's ezmlm list: ezmlm-subscribe@list.cr.yp.to
+
+ +\bo A digest version of the ezmlm list fredr-ezmlm-digest-
+ subscribe@rivertown.net
+
+ +\bo Dan Bernstein's qmail list: qmail-subscribe@list.cr.yp.to
+
+ +\bo The Japanese ezmlm list: ezmlm-subscribe@jp.qmail.org
+
+ +\bo The Japanese qmail list: qmail-subscribe@jp.qmail.org
+
+ +\bo A ezmlm/idx digest list of djb-qmail: qmail-digest-
+ subscribe@id.wustl.edu
+
+ +\bo A ezmlm/idx sublist of djb-qmail (you can test ezmlm-idx
+ commands): qmail-index@id.wustl.edu
+
+
+ 1\b1.\b.7\b7.\b. W\bWh\bhe\ber\bre\be d\bdo\bo I\bI s\bse\ben\bnd\bd c\bco\bom\bmm\bme\ben\bnt\bts\bs o\bon\bn t\bth\bhi\bis\bs d\bdo\boc\bcu\bum\bme\ben\bnt\bt?\b?
+
+ To the authors via E-mail:
+
+ +\bo Fred Lindberg, lindberg@id.wustl.edu
+
+ +\bo Fred B. Ringel, fredr@rivertown.net
+
+
+ 1\b1.\b.8\b8.\b. H\bHo\bow\bw t\bto\bo e\bex\bxp\bpe\ber\bri\bim\bme\ben\bnt\bt w\bwi\bit\bth\bh n\bne\bew\bw v\bve\ber\brs\bsi\bio\bon\bns\bs o\bof\bf e\bez\bzm\bml\blm\bm-\b-i\bid\bdx\bx.\b.
+
+ ezmlm-idx>=0.23 writes D\bDI\bIR\bR/\b/c\bco\bon\bnf\bfi\big\bg in a standard format. If ezmlm-
+ make(1) is invoked with the ``-e'' or ``-+'' switch and the ``DIR''
+ argument only, ezmlm-make(1) will read other arguments from this file.
+ The difference between the switches is that with ``-e'' the options
+ used are the ones specified on the command line, whereas with ``-+''
+ they are the ones currently active for the list, as overridden by any
+ command line options. Thus, with just:
+
+
+ % ezmlm-make -+ DIR
+
+
+
+
+ you can rebuild the list, without affecting any archives, list state
+ variables, etc. You will _\bl_\bo_\bs_\be _\bm_\ba_\bn_\bu_\ba_\bl _\bc_\bu_\bs_\bt_\bo_\bm_\bi_\bz_\ba_\bt_\bi_\bo_\bn_\bs _\bt_\bo _\bs_\bo_\bm_\be _\bo_\bf _\by_\bo_\bu_\br
+ _\bf_\bi_\bl_\be_\bs. However, text files and D\bDI\bIR\bR/\b/h\bhe\bea\bad\bde\ber\bra\bad\bdd\bd are protected against
+ being overwritten, so that your manual customizations of these files
+ are retained. To override this protection, simply specify the used
+ edit switch twice, e.g. ``-ee'' and ``-++'', respectively. This is a
+ feature introduced in ezmlm-idx-0.40.
+
+ To test a new version of ezmlm-idx or to run several version, make the
+ new version as per I\bIN\bNS\bST\bTA\bAL\bLL\bL.\b.i\bid\bdx\bx (if you haven't used ezmlm-idx before)
+ or U\bUP\bPG\bGR\bRA\bAD\bDE\bE.\b.i\bid\bdx\bx (if you've got a previous version of ezmlm-idx
+ installed), setting c\bco\bon\bnf\bf-\b-b\bbi\bin\bn 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(1).
+
+ If your system has an /\b/e\bet\btc\bc/\b/e\bez\bzm\bml\blm\bmr\brc\bc file, you may need to temporarily
+ place the e\bez\bzm\bml\blm\bmr\brc\bc(\b(5\b5)\b) file for the ezmlm version you want to test in
+ d\bdo\bot\btd\bdi\bir\br of the list and use the ezmlm-make(1) ``-c'' switch (see
+ ``Terminology: dotdir'').
+
+ ezmlm-idx>=0.314 comes with ezmlm-test(1), a program that tests most
+ functions of ezmlm+idx and can be used before installation.
+
+
+ 2\b2.\b. Q\bQu\bui\bic\bck\bk s\bst\bta\bar\brt\bt
+
+
+ 1. Create a use ``eztest'' for testing. If you use another name, add
+ the switch ``-u another_name'' to the ezmlm-test(1) line below.
+ (The space between the switch and the argument is required.)
+
+ 2. Unpack the ezmlm-0.53 distribution.
+
+ 3. Unpack the ezmlm-idx distribution.
+
+ 4. Move the ezmlm-idx files to the ezmlm-0.53 directory.
+
+ 5. Edit c\bco\bon\bnf\bf-\b-b\bbi\bin\bn and c\bco\bon\bnf\bf-\b-m\bma\ban\bn to reflect the target directories.
+
+ 6. build and install:
+
+
+ % cd ezmlm-0.53
+ % patch < idx.patch
+ % make; make man
+ % su
+ # su eztest
+ % ./ezmlm-test
+ % exit
+ # make setup
+ # exit
+
+
+
+
+ 7. Make a list and digest list
+
+
+
+
+
+ % ezmlm-make -rdugm -5 me@host ~/list ~/.qmail-list me-list host
+ % ezmlm-sub ~/list me@host
+ % ezmlm-sub ~/list/digest me@host
+ % ezmlm-sub ~/list/mod 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 has arrived. To manage the digest list, use the same commands as
+ the main list, but replace ``list'' with ``list-digest''.
+
+ The sender restriction on posting used in this setup works, but is not
+ secure. For more info, read the man pages (start with ezmlm(5) and
+ ezmlm-make(1)), this FAQ (F\bFA\bAQ\bQ.\b.i\bid\bdx\bx in the distribution),
+ R\bRE\bEA\bAD\bDM\bME\bE/\b/R\bRE\bEA\bAD\bDM\bME\bE.\b.i\bid\bdx\bx, I\bIN\bNS\bST\bTA\bAL\bLL\bL/\b/I\bIN\bNS\bST\bTA\bAL\bLL\bL.\b.i\bid\bdx\bx, and U\bUP\bPG\bGR\bRA\bAD\bDE\bE.\b.i\bid\bdx\bx.
+
+
+ 3\b3.\b. O\bOv\bve\ber\brv\bvi\bie\bew\bw o\bof\bf m\bma\bai\bil\bli\bin\bng\bg l\bli\bis\bst\bt m\bma\ban\bna\bag\bge\bem\bme\ben\bnt\bt a\ban\bnd\bd m\bma\bai\bil\bli\bin\bng\bg l\bli\bis\bst\bt m\bma\ban\bna\bag\bge\ber\brs\bs
+
+ (To be written. Until then, please consult the
+ <http://www.ezmlm.org/ezman/> manual for ezmlm and ezmlm-idx related
+ material.)
+
+
+ 4\b4.\b. O\bOv\bve\ber\brv\bvi\bie\bew\bw o\bof\bf e\bez\bzm\bml\blm\bm f\bfu\bun\bnc\bct\bti\bio\bon\bn
+
+
+ 4\b4.\b.1\b1.\b. T\bTh\bhe\be b\bba\bas\bsi\bic\bc s\bse\bet\btu\bup\bp.\b.
+
+ In designing ezmlm, _\bD_\ba_\bn _\bJ_\b. _\bB_\be_\br_\bn_\bs_\bt_\be_\bi_\bn 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.
+
+
+ 4\b4.\b.2\b2.\b. I\bIn\bnv\bve\ben\bnt\bti\bio\bon\bns\bs i\bin\bn e\bez\bzm\bml\blm\bm.\b.
+
+ 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 crashes do not leave the list in an undefined state.
+
+ 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 subvert
+ the bounce detection mechanism to unsubscribe another user.
+
+
+ 4\b4.\b.3\b3.\b. T\bTh\bhe\be q\bqm\bma\bai\bil\bl d\bde\bel\bli\biv\bve\ber\bry\by m\bme\bec\bch\bha\ban\bni\bis\bsm\bm.\b.
+
+ 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 .\b.q\bqm\bma\bai\bil\bl 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 .\b.q\bqm\bma\bai\bil\bl 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 .\b.q\bqm\bma\bai\bil\bl 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
+ .\b.q\bqm\bma\bai\bil\bl 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 set of
+ small independent programs.
+
+
+ 4\b4.\b.4\b4.\b. W\bWh\bha\bat\bt t\bth\bhe\be d\bdi\bif\bff\bfe\ber\bre\ben\bnt\bt p\bpr\bro\bog\bgr\bra\bam\bms\bs d\bdo\bo.\b.
+
+ See ezmlm(5) and the man pages for the different programs (listed in
+ ezmlm(5)).
+
+
+ 4\b4.\b.5\b5.\b. W\bWh\bha\bat\bt t\bth\bhe\be d\bdi\bif\bff\bfe\ber\bre\ben\bnt\bt f\bfi\bil\ble\bes\bs i\bin\bn t\bth\bhe\be l\bli\bis\bst\bt d\bdi\bir\bre\bec\bct\bto\bor\bry\by d\bdo\bo.\b.
+
+ See ezmlm(5).
+
+
+ 4\b4.\b.6\b6.\b. T\bTh\bhe\be p\bpa\bap\bpe\ber\br p\bpa\bat\bth\bh f\bfo\bor\br p\bpo\bos\bst\bts\bs.\b.
+
+ Messages to the list are delivered to a .\b.q\bqm\bma\bai\bil\bl file, usually ~\b~/\b/.\b.q\bqm\bma\bai\bil\bl-\b-
+ l\bli\bis\bst\btn\bna\bam\bme\be which is linked to D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br. 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.
+
+ You can specify a separate .\b.q\bqm\bma\bai\bil\bl-like file for ezmlm-gate(1). The
+ lines will be executed and the return codes determine if the message
+ is rejected, sent to the list, or sent to the moderator. See man page
+ for details.
+
+ If the list is configured for digests, D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br 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 D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br 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, D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br contains a number of house-keeping functions.
+ These are invocations of ezmlm-warn(1) to send out bounce warnings and
+ and (if the list is moderated) 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.
+
+
+ 4\b4.\b.7\b7.\b. T\bTh\bhe\be e\bez\bzm\bml\blm\bm p\bpa\bat\bth\bh f\bfo\bor\br m\bmo\bod\bde\ber\bra\bat\bti\bio\bon\bn m\bme\bes\bss\bsa\bag\bge\bes\bs.\b.
+
+ Replies to moderation requests are channeled to D\bDI\bIR\bR/\b/m\bmo\bod\bde\ber\bra\bat\bto\bor\br. 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 _\bc_\bo_\bn_\bt_\br_\ba_\br_\by to the moderation message.
+ Thus, if you accept a message already accepted, no error message is
+ sent. ezmlm-clean(1) is also invoked from D\bDI\bIR\bR/\b/m\bmo\bod\bde\ber\bra\bat\bto\bor\br for house
+ keeping.
+
+
+ 4\b4.\b.8\b8.\b. T\bTh\bhe\be e\bez\bzm\bml\blm\bm p\bpa\bat\bth\bh f\bfo\bor\br a\bad\bdm\bmi\bin\bni\bis\bst\btr\bra\bat\bti\biv\bve\be m\bme\bes\bss\bsa\bag\bge\bes\bs.\b.
+
+ Administrative requests for both list and digest lists are captured by
+ ~\b~/\b/.\b.q\bqm\bma\bai\bil\bl-\b-l\bli\bis\bst\btn\bna\bam\bme\be-\b-d\bde\bef\bfa\bau\bul\blt\bt linked to D\bDI\bIR\bR/\b/m\bma\ban\bna\bag\bge\ber\br. 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 D\bDI\bIR\bR/\b/t\bte\bex\bxt\bt/\b/ 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.
+
+ 4\b4.\b.9\b9.\b. T\bTh\bhe\be e\bez\bzm\bml\blm\bm p\bpa\bat\bth\bh f\bfo\bor\br b\bbo\bou\bun\bnc\bce\bes\bs.\b.
+
+ Bounces to the list are handled by D\bDI\bIR\bR/\b/b\bbo\bou\bun\bnc\bce\ber\br. For the digest list
+ this is D\bDI\bIR\bR/\b/d\bdi\big\bge\bes\bst\bt/\b/b\bbo\bou\bun\bnc\bce\ber\br. The two were combined in previous
+ versions, which is still supported. As this leads to problems with
+ list names ending in ``digest'', the functions are separate with lists
+ set up or edited with ezmlm-idx>=0.32. The bounce is first delivery is
+ to ezmlm-weed(1) which removes delivery delay notification and other
+ junk. The second to ezmlm-return(1) which analyzes valid bounces
+ storing the information in D\bDI\bIR\bR/\b/b\bbo\bou\bun\bnc\bce\be/\b/ for the list and
+ D\bDI\bIR\bR/\b/d\bdi\big\bge\bes\bst\bt/\b/b\bbo\bou\bun\bnc\bce\be/\b/ for the digest. This is the information that
+ ezmlm-warn(1) (invoked from D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br and D\bDI\bIR\bR/\b/m\bma\ban\bna\bag\bge\ber\br) uses and
+ processes for automatic bounce handling. ezmlm-return(1) will also
+ unsubscribe a subscriber from whom a probe message has bounced.
+
+
+ 4\b4.\b.1\b10\b0.\b. M\bMe\bes\bss\bsa\bag\bge\bes\bs t\bto\bo l\bli\bis\bst\bt-\b-o\bow\bwn\bne\ber\br a\ban\bnd\bd l\bli\bis\bst\bt-\b-d\bdi\big\bge\bes\bst\bt-\b-o\bow\bwn\bne\ber\br.\b.
+
+ These are processed by D\bDI\bIR\bR/\b/o\bow\bwn\bne\ber\br and delivered to D\bDI\bIR\bR/\b/m\bma\bai\bil\blb\bbo\box\bx by
+ default. It is better to put the real owner address in this location.
+ This can be done manually, via editing of e\bez\bzm\bml\blm\bmr\brc\bc(\b(5\b5)\b), or via the
+ ezmlm-make(1) -5 switch. Again, some house-keeping functions are also
+ executed.
+
+
+ 4\b4.\b.1\b11\b1.\b. S\bSt\btr\bru\buc\bct\btu\bur\bre\be o\bof\bf s\bsu\bub\bbs\bsc\bcr\bri\bib\bbe\ber\br d\bda\bat\bta\bab\bba\bas\bse\bes\bs.\b.
+
+ ezmlm subscriber E-mail addresses are stored within D\bDI\bIR\bR/\b/s\bsu\bub\bbs\bsc\bcr\bri\bib\bbe\ber\brs\bs/\b/
+ 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 D\bDI\bIR\bR/\b/s\bsu\bub\bbs\bsc\bcr\bri\bib\bbe\ber\brs\bs/\b/ 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.
+
+ With ezmlm-idx>=0.32 you can use an SQL server for the subscriber
+ databases. Please see the SQL section (``ezmlm support for SQL
+ datbases'').
+
+
+ 4\b4.\b.1\b12\b2.\b. L\bLo\boc\bca\bal\bl c\bca\bas\bse\be i\bin\bn E\bE-\b-m\bma\bai\bil\bl a\bad\bdd\bdr\bre\bes\bss\bse\bes\bs.\b.
+
+ rfc822 states that the host part of an address is case insensitive,
+ but that case of the local part should be respected and the
+ interpretation of it is the prerogative of the machine where the
+ mailbox exists. 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.
+
+
+ 4\b4.\b.1\b13\b3.\b. T\bTe\bes\bst\bti\bin\bng\bg S\bSE\bEN\bND\bDE\bER\bR t\bto\bo a\bal\bll\blo\bow\bw p\bpo\bos\bst\bts\bs o\bon\bnl\bly\by f\bfr\bro\bom\bm l\bli\bis\bst\bt s\bsu\bub\bbs\bsc\bcr\bri\bib\bbe\ber\brs\bs.\b.
+
+ 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
+ D\bDI\bIR\bR/\b/a\bal\bll\blo\bow\bw/\b/. 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 D\bDI\bIR\bR/\b/a\bal\bll\blo\bow\bw/\b/ 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 .\b.q\bqm\bma\bai\bil\bl 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 D\bDI\bIR\bR/\b/, D\bDI\bIR\bR/\b/d\bdi\big\bge\bes\bst\bt/\b/, or D\bDI\bIR\bR/\b/a\bal\bll\blo\bow\bw/\b/ and exit silently, put the
+ following into the relevant .\b.q\bqm\bma\bai\bil\bl file:
+
+
+
+
+ |/usr/local/bin/ezmlm/ezmlm-issubn DIR DIR/digest DIR/allow [...]
+ |/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 _\bN_\bO_\bT a subscriber of any of
+ the lists:
+
+
+
+ |/usr/local/bin/ezmlm/ezmlm-issubn -n DIR/deny [dir2 ...]
+ |/path/other_program
+
+
+
+
+ To automatically configure the list with a blacklist address database
+ in D\bDI\bIR\bR/\b/d\bde\ben\bny\by, 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
+ ``deny'' database remotely by sending mail to list-deny-subscribe-
+ user=userhost@listhost, etc.
+
+
+ 4\b4.\b.1\b14\b4.\b. H\bHo\bow\bw c\bco\boo\bok\bki\bie\bes\bs w\bwo\bor\brk\bk.\b.
+
+ Each ezmlm list has it's own ``key'' created by ezmlm-make at setup
+ time. This key is stored in D\bDI\bIR\bR/\b/k\bke\bey\by, 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:
+
+ +\bo the request,
+
+ +\bo the time,
+
+ +\bo 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
+ _\bP_\bG_\bP).
+
+
+ 4\b4.\b.1\b15\b5.\b. H\bHo\bow\bw m\bmo\bod\bde\ber\bra\bat\bto\bor\br E\bE-\b-m\bma\bai\bil\bl a\bad\bdd\bdr\bre\bes\bss\bse\bes\bs a\bar\bre\be s\bst\bto\bor\bre\bed\bd.\b.
+
+ Moderator E-mail addresses are stored just like ezmlm subscriber
+ addresses, in a set of up to 53 files within the s\bsu\bub\bbs\bsc\bcr\bri\bib\bbe\ber\brs\bs
+ subdirectory of the list's b\bba\bas\bse\bed\bdi\bir\br/\b/. For subscribers, the b\bba\bas\bse\bed\bdi\bir\br/\b/ is
+ the list directory itself, i.e. D\bDI\bIR\bR/\b/. For moderators, the default is
+ D\bDI\bIR\bR/\b/m\bmo\bod\bd/\b/, which can be overridden by placing a b\bba\bas\bse\bed\bdi\bir\br name (starting
+ with a ``/'') in D\bDI\bIR\bR/\b/m\bmo\bod\bds\bsu\bub\bb, D\bDI\bIR\bR/\b/r\bre\bem\bmo\bot\bte\be, or D\bDI\bIR\bR/\b/m\bmo\bod\bdp\bpo\bos\bst\bt for
+ subscription moderation, remote administration, and message
+ moderation, respectively. This permits the use of one moderator
+ database for multiple lists. _\bN_\bo_\bt_\be_\b: _\bS_\bu_\bb_\bs_\bc_\br_\bi_\bp_\bt_\bi_\bo_\bn _\bm_\bo_\bd_\be_\br_\ba_\bt_\bo_\br_\bs _\ba_\bn_\bd _\br_\be_\bm_\bo_\bt_\be
+ _\ba_\bd_\bm_\bi_\bn_\bi_\bs_\bt_\br_\ba_\bt_\bo_\br_\bs _\ba_\br_\be _\ba_\bl_\bw_\ba_\by_\bs _\bt_\bh_\be _\bs_\ba_\bm_\be _\ba_\bd_\bd_\br_\be_\bs_\bs_\be_\bs_\b. _\bI_\bf _\bb_\bo_\bt_\bh D\bDI\bIR\bR/\b/m\bmo\bod\bds\bsu\bub\bb and
+ D\bDI\bIR\bR/\b/r\bre\bem\bmo\bot\bte\be contain paths, only the D\bDI\bIR\bR/\b/m\bmo\bod\bds\bsu\bub\bb path is used.
+
+
+ 4\b4.\b.1\b16\b6.\b. H\bHo\bow\bw s\bsu\bub\bbs\bsc\bcr\bri\bip\bpt\bti\bio\bon\bn m\bmo\bod\bde\ber\bra\bat\bti\bio\bon\bn w\bwo\bor\brk\bks\bs.\b.
+
+ 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 _\bd_\bi_\bf_\bf_\be_\br_\be_\bn_\bt _\ba_\bc_\bt_\bi_\bo_\bn _\bc_\bo_\bd_\be. 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 _\bs_\bh_\bo_\bu_\bl_\bd know) the
+ qmail/ezmlm/unix paradigm: _\bi_\bf _\by_\bo_\bu_\b'_\br_\be _\bn_\bo_\bt _\bt_\bo_\bl_\bd _\bo_\bt_\bh_\be_\br_\bw_\bi_\bs_\be_\b, _\by_\bo_\bu_\br _\bc_\bo_\bm_\bm_\ba_\bn_\bd
+ _\bw_\ba_\bs _\bc_\ba_\br_\br_\bi_\be_\bd _\bo_\bu_\bt _\bs_\bu_\bc_\bc_\be_\bs_\bs_\bf_\bu_\bl_\bl_\by. 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 D\bDI\bIR\bR/\b/m\bmo\bod\bds\bsu\bub\bb and adding
+ the subscription moderator to D\bDI\bIR\bR/\b/m\bmo\bod\bd/\b/:
+
+
+ % ezmlm-sub DIR/mod moderator@host
+
+
+
+
+ To use an alternative basedir for subscription moderators, place that
+ directory name with a leading ``/'' in D\bDI\bIR\bR/\b/m\bmo\bod\bds\bsu\bub\bb.
+
+
+ 4\b4.\b.1\b17\b7.\b. H\bHo\bow\bw r\bre\bem\bmo\bot\bte\be a\bad\bdm\bmi\bin\bni\bis\bst\btr\bra\bat\bti\bio\bon\bn w\bwo\bor\brk\bks\bs.\b.
+
+ The term ``remote administration'' is used to denote the ability of a
+ list administrator by E-mail 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 D\bDI\bIR\bR/\b/r\bre\bem\bmo\bot\bte\be and adding the
+ remote administrator E-mail address(es) to D\bDI\bIR\bR/\b/m\bmo\bod\bd/\b/:
+
+
+ % ezmlm-sub DIR/mod remoteadm@host
+
+
+
+
+ To use an alternative basedir for remote administrators, place that
+ directory name with a leading ``/'' in D\bDI\bIR\bR/\b/m\bmo\bod\bds\bsu\bub\bb. Remote administra-
+ tors and subscription moderators databases always consist of the same
+ E-mail addresses. If both are enabled and one of D\bDI\bIR\bR/\b/m\bmo\bod\bds\bsu\bub\bb and
+ D\bDI\bIR\bR/\b/r\bre\bem\bmo\bot\bte\be contains an alternative basedir name, this basedir is used
+ for both functions. If both D\bDI\bIR\bR/\b/m\bmo\bod\bds\bsu\bub\bb and D\bDI\bIR\bR/\b/r\bre\bem\bmo\bot\bte\be contain direc-
+ tory names, the one in D\bDI\bIR\bR/\b/m\bmo\bod\bds\bsu\bub\bb 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.
+
+
+ 4\b4.\b.1\b18\b8.\b. H\bHo\bow\bw m\bme\bes\bss\bsa\bag\bge\be m\bmo\bod\bde\ber\bra\bat\bti\bio\bon\bn w\bwo\bor\brk\bks\bs.\b.
+
+ ezmlm-store(1), invoked in D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br, receives messages for message
+ moderated lists. If D\bDI\bIR\bR/\b/m\bmo\bod\bdp\bpo\bos\bst\bt 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 D\bDI\bIR\bR/\b/m\bmo\bod\bdp\bpo\bos\bst\bt exists, ezmlm-store(1) places the
+ message in D\bDI\bIR\bR/\b/m\bmo\bod\bd/\b/p\bpe\ben\bnd\bdi\bin\bng\bg/\b/. 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 D\bDI\bIR\bR/\b/m\bmo\bod\bde\ber\bra\bat\bto\bor\br. ezmlm-moderate(1) validates the request,
+ and if the request is valid and the message is found in
+ D\bDI\bIR\bR/\b/m\bmo\bod\bd/\b/p\bpe\ben\bnd\bdi\bin\bng\bg/\b/, 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
+ D\bDI\bIR\bR/\b/m\bmo\bod\bd/\b/r\bre\bej\bje\bec\bct\bte\bed\bd/\b/ or D\bDI\bIR\bR/\b/m\bmo\bod\bd/\b/a\bac\bcc\bce\bep\bpt\bte\bed\bd/\b/ for ``reject'' and ``accept''
+ requests, respectively.
+
+ If a valid reply is received but the message is no longer in
+ D\bDI\bIR\bR/\b/m\bmo\bod\bd/\b/p\bpe\ben\bnd\bdi\bin\bng\bg/\b/, ezmlm-moderate(1) looks for the corresponding stub
+ in D\bDI\bIR\bR/\b/m\bmo\bod\bd/\b/r\bre\bej\bje\bec\bct\bte\bed\bd/\b/ and D\bDI\bIR\bR/\b/m\bmo\bod\bd/\b/a\bac\bcc\bce\bep\bpt\bte\bed\bd/\b/. 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
+ D\bDI\bIR\bR/\b/m\bmo\bod\bd/\b/p\bpe\ben\bnd\bdi\bin\bng\bg/\b/ until it times out. Cleanup of both messages and
+ stubs is accomplished by ezmlm-clean(1) which is invoked through both
+ D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br and D\bDI\bIR\bR/\b/m\bmo\bod\bde\ber\bra\bat\bto\bor\br 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 D\bDI\bIR\bR/\b/m\bmo\bod\bdt\bti\bim\bme\be) 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 D\bDI\bIR\bR/\b/m\bmo\bod\bd/\b/. This can be changed to
+ any other b\bba\bas\bse\bed\bdi\bir\br by placing the name of that directory with a leading
+ ``/'' in D\bDI\bIR\bR/\b/m\bmo\bod\bdp\bpo\bos\bst\bt. Although the default basedirs for message
+ moderation and subscription moderation/remote administration are the
+ same, both the functions and actors are entirely independent.
+
+
+ 4\b4.\b.1\b19\b9.\b. H\bHo\bow\bw Q\bQM\bMQ\bQP\bP s\bsu\bup\bpp\bpo\bor\brt\bt w\bwo\bor\brk\bks\bs
+
+ qmail processes messages on a first-come-first-served basis. This
+ means that when it receives a post to 100,000 subscribers, it will try
+ all the recipients before processing the next message. Often, it is
+ desirable to offload this work to an external host so that the main
+ list host remains responsive to e.g. ``subscribe'' and archive access
+ commands, as well as to other mail is it is not a dedicated mail host.
+
+ ezmlm-idx allows the main distribution work to be offloaded to an
+ external server via the QMQP protocol. Configure qmail-qmqpc(1) on the
+ list host, and qmail-qmqpd(1) on the mail host (see qmail docs for
+ details), then create the file D\bDI\bIR\bR/\b/q\bqm\bmq\bqp\bps\bse\ber\brv\bve\ber\brs\bs/\b/0\b0. The list housed in
+ D\bDI\bIR\bR will now use the QMQP server for posts, by the local qmail for
+ other messages. If you apply the qmail-qmqpc.tar.gz patch (included in
+ the ezmlm-idx distribution), you can specify the QMQP server IP
+ addresses, one per line, in D\bDI\bIR\bR/\b/q\bqm\bmq\bqp\bps\bse\ber\brv\bve\ber\brs\bs/\b/0\b0, just as you normally
+ would in /\b/v\bva\bar\br/\b/q\bqm\bma\bai\bil\bl/\b/c\bco\bon\bnt\btr\bro\bol\bl/\b/q\bqm\bmq\bqp\bps\bse\ber\brv\bve\ber\brs\bs. If the first server cannot
+ be contacted, the installation will try the second, and so on. The
+ advantage of controlling the servers locally is that you can specify
+ different servers for different lists. A good idea is to set up also
+ the list host as a QMQP server and use that as the last IP address.
+ This way, the list host will be used if the main QMQP server cannot be
+ contacted. Of course, ezmlm does not loose messages, but rather lets
+ qmail redeliver the post if no QMQP server is available.
+
+
+ 4\b4.\b.2\b20\b0.\b. H\bHo\bow\bw m\bme\bes\bss\bsa\bag\bge\bes\bs a\bar\bre\be s\bst\bto\bor\bre\bed\bd i\bin\bn t\bth\bhe\be a\bar\brc\bch\bhi\biv\bve\be.\b.
+
+ The structure of the ezmlm list archive is described in the ezmlm(5)
+ manual page. Basically, the message is stored in D\bDI\bIR\bR/\b/a\bar\brc\bch\bhi\biv\bve\be/\b/n\bn/\b/m\bm,
+ where ``n'' is the message number divided by 100 and ``m'' the
+ remainder (2 digits). The first message is stored in D\bDI\bIR\bR/\b/a\bar\brc\bch\bhi\biv\bve\be/\b/0\b0/\b/0\b01\b1.
+
+
+ 4\b4.\b.2\b21\b1.\b. H\bHo\bow\bw t\bth\bhe\be m\bme\bes\bss\bsa\bag\bge\be i\bin\bnd\bde\bex\bx w\bwo\bor\brk\bks\bs.\b.
+
+ 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''. A hash is needed due to the inconsistent handling
+ by MUAs of white space in rfc2047-encoded subject headers.
+
+ The message index is stored as D\bDI\bIR\bR/\b/a\bar\brc\bch\bhi\biv\bve\be/\b/n\bn/\b/i\bin\bnd\bde\bex\bx, where ``n'' is the
+ message number mod 100. Thus, the directory D\bDI\bIR\bR/\b/a\bar\brc\bch\bhi\biv\bve\be/\b/5\b52\b2/\b/ 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 message archive.
+ without one.
+
+
+ 4\b4.\b.2\b22\b2.\b. H\bHo\bow\bw t\bth\bhr\bre\bea\bad\bdi\bin\bng\bg w\bwo\bor\brk\bks\bs.\b.
+
+ 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.
+
+
+ 4\b4.\b.2\b23\b3.\b. H\bHo\bow\bw d\bdi\big\bge\bes\bst\bts\bs w\bwo\bor\brk\bk.\b.
+
+ 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
+ D\bDI\bIR\bR/\b/d\bdi\big\bge\bes\bst\bt/\b/. Digest list subscriber addresses in
+ D\bDI\bIR\bR/\b/d\bdi\big\bge\bes\bst\bt/\b/s\bsu\bub\bbs\bsc\bcr\bri\bib\bbe\ber\brs\bs/\b/ and digest list bounce information in
+ D\bDI\bIR\bR/\b/d\bdi\big\bge\bes\bst\bt/\b/b\bbo\bou\bun\bnc\bce\be/\b/. 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.
+
+
+ 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 (D\bDI\bIR\bR/\b/d\bdi\big\bgi\bis\bss\bsu\bue\be and D\bDI\bIR\bR/\b/d\bdi\big\bgn\bnu\bum\bm) 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:
+
+ C\bCo\bom\bmm\bma\ban\bnd\bd l\bli\bin\bne\be
+ ezmlm-get can be invoked on the command line, or via a script
+ from e.g. crond(8):
+
+
+ % ezmlm-get DIR
+
+
+
+
+ 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'').
+
+
+ f\bfr\bro\bom\bm D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br
+ 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 D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br
+ digests are triggered only when messages are received).
+
+ In D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br, 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 D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br:
+
+
+ |/usr/local/bin/ezmlm/ezmlm-tstdig -t48 -m30 -k64 DIR || exit 99
+ |/usr/local/bin/ezmlm/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. The ezmlm-make(1) ``-4''
+ switch can be used to specify alternative ezmlm-tstdig(1) parame-
+ ters.
+
+ f\bfr\bro\bom\bm D\bDI\bIR\bR/\b/m\bma\ban\bna\bag\bge\ber\br
+ This is useful only if you want digests at specific times, and
+ you do not have access to crond(8) on the list host. ezmlm-
+ get(1) is in it's normal place in D\bDI\bIR\bR/\b/m\bma\ban\bna\bag\bge\ber\br 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), but this can
+ be done from _any_ host, not only the list host. 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 D\bDI\bIR\bR/\b/m\bma\ban\bna\bag\bge\ber\br. E.g., use a trigger message every 3 hours and
+ the following ezmlm-tstdig(1) line before ezmlm-get(1):
+
+
+ |/usr/local/bin/ezmlm/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. For most lists, the digesting from D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br works
+ very well, and does not require any extra setup work.
+
+ C\bCo\bom\bmb\bbi\bin\bna\bat\bti\bio\bon\bn s\bse\bet\btu\bup\bps\bs
+ The default setup in the ezmlmrc(5) file included in the
+ distribution is the D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br 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 D\bDI\bIR\bR/\b/m\bma\ban\bna\bag\bge\ber\br), with
+ extra digest sent when traffic is unusually high (via the ezmlm-
+ tstdig/ezmlm-get limits set in D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br). 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.
+
+
+ 4\b4.\b.2\b24\b4.\b. H\bHo\bow\bw W\bWW\bWW\bW a\bar\brc\bch\bhi\biv\bve\be a\bac\bcc\bce\bes\bss\bs w\bwo\bor\brk\bks\bs.\b.
+
+ If the list is set up with ezmlm-make -i, ezmlm-archive(1) will be
+ invoked from D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br. This program creates indices for threads,
+ subjects, and authors under D\bDI\bIR\bR/\b/a\bar\brc\bch\bhi\biv\bve\be from the i\bin\bnd\bde\bex\bx files. ezmlm-
+ cgi(1) is set up per user or globally (see man page) and told about
+ different lists via the /\b/e\bet\btc\bc/\b/e\bez\bzm\bml\blm\bm/\b/e\bez\bzc\bcg\bgi\bir\brc\bc file. ezmlm-cgi(1) presents
+ and used the index created by ezmlm-archive(1) and converts these and
+ the messages to html on-the-fly. To be as efficient as possible,
+ ezmlm-cgi(1) outputs only basic html. However, style sheets are
+ supported and can be used to customize formatting without modification
+ of ezmlm-cgi(1). Extra buttons can be added via the config file. See
+ man page for details.
+
+
+
+
+ 4\b4.\b.2\b25\b5.\b. H\bHo\bow\bw e\bez\bzm\bml\blm\bm-\b-t\bts\bst\btd\bdi\big\bg w\bwo\bor\brk\bks\bs.\b.
+
+ ezmlm-tstdig(1) looks at D\bDI\bIR\bR/\b/n\bnu\bum\bm and D\bDI\bIR\bR/\b/d\bdi\big\bgn\bnu\bum\bm 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 D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br, or in
+ D\bDI\bIR\bR/\b/m\bma\ban\bna\bag\bge\ber\br. In the latter two cases, ezmlm-tstdig(1) verifies that
+ the list local address is correct. If invoked in D\bDI\bIR\bR/\b/m\bma\ban\bna\bag\bge\ber\br, 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). ezmlm-tstdig(1) uses D\bDI\bIR\bR/\b/t\bts\bst\btd\bdi\big\bg as a flag to avoid
+ problems caused by starting the program when another copy is already
+ running.
+
+ ezmlm-make(1) automatically configures ezmlm-tstdig(1) with the
+ parameters ``-t48 -m30 -k64'', which can be overridden with the ``-3''
+ switch.
+
+
+ 4\b4.\b.2\b26\b6.\b. H\bHo\bow\bw s\bsu\bub\bbl\bli\bis\bst\bts\bs w\bwo\bor\brk\bk.\b.
+
+ 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 D\bDI\bIR\bR/\b/s\bsu\bub\bbl\bli\bis\bst\bt.
+
+ 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 qmail@list.cr.yp.to list is to create a ezmlm list, and put
+ ``qmail@list.cr.yp.to'' into D\bDI\bIR\bR/\b/s\bsu\bub\bbl\bli\bis\bst\bt 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.
+
+ 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 D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br so that the _\be_\bz_\bm_\bl_\bm_\b-
+ _\bs_\be_\bn_\bd line contains the command line option ``-\b-h\bh _\bX_\b-_\bL_\bi_\bs_\bt_\bp_\br_\bo_\bc_\be_\bs_\bs_\bo_\br_\b-
+ _\bV_\be_\br_\bs_\bi_\bo_\bn_\b:'' (before D\bDI\bIR\bR). 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 _\ba_\bn_\bd contain the header specified.
+
+ ezmlm-idx>=0.313 also has added protection against the malicious
+ subscription of the ezmlm list to mailing lists run by other list
+ managers. If the ezmlm-reject(1) line in D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br has ``-h'' and
+ ``D\bDI\bIR\bR'' on it, ezmlm-reject(1) will read D\bDI\bIR\bR/\b/h\bhe\bea\bad\bde\ber\brr\bre\bej\bje\bec\bct\bt and reject
+ messages that have any header specified in that file. See the ezmlm-
+ reject(1) man page for suitable headers.
+
+
+
+ 4\b4.\b.2\b27\b7.\b. H\bHo\bow\bw s\bsu\bub\bbl\bli\bis\bst\bti\bin\bng\bg c\bca\ban\bn b\bbe\be m\bma\bad\bde\be t\btr\bra\ban\bns\bsp\bpa\bar\bre\ben\bnt\bt t\bto\bo t\bth\bhe\be u\bus\bse\ber\br.\b.
+
+ Often you create a local sublist of a list that you do not control.
+ Local users know to subscribe to your local list. However,
+ occasionally, you want to run your own list as a main list and a
+ series of sublists per geographic site, or split onto several hosts if
+ the list is too large to be handled by a single computer. You may also
+ want to split the load of a ``well known'' list host that is getting
+ overwhelmed with traffic. ezmlm supports sublists, but here the fact
+ that the user has to interact with the correct sublist is a problem.
+ What if the user doesn't remember which sublist s/he is subscribed to?
+ What if you change the name of a sublist host or move a sublist to a
+ different host?
+
+ ezmlm-idx&-0.32 adds ezmlm-split(1), which allows sublisting
+ transparent to the user. This program is invoked before ezmlm-
+ manage(1) in D\bDI\bIR\bR/\b/m\bma\ban\bna\bag\bge\ber\br. If it detects a subscribe or unsubscribe
+ command, it will forward the command to the appropriate sublist based
+ on a ``split file'' D\bDI\bIR\bR/\b/s\bsp\bpl\bli\bit\bt. This file contains entries, one per
+ line, of the format:
+
+
+ domain:lo:hi:sublistname@sublisthost
+ edu:::othersub@otherhost
+ :1:26:third@thirdhost
+
+
+
+
+ For each address, a hash in the range 0-52 is calculated. The
+ ``domain'' is the last two parts of the host name, reversed. Thus, for
+ id.wustl.edu it would be ``edu.wustl''. The domain is considered to
+ match if the characters in the split file match. It is advisable to
+ use only the last part of the domain for compatibility with the SQL
+ version version (see section ``ezmlm support for SQL datbases'').
+
+ Thus, any address *@*.domain with a hash between ``lo'' and ``hi''
+ inclusive would match the first line and be forwarded to
+ sublistname@sublisthost. *@*.edu (independent of hash) would match
+ the second line and be forwarded to othersub@otherhost. Of remaining
+ requests, a request for any target address with a hash between 1 and
+ 26 would be forwarded to the sublist third@thirdhost. Remaining
+ requests would be passed on to the local list.
+
+ The domain is useful for ``geographic'' splitting, and the hash for
+ load splitting (within a domain). The user interacts only with the
+ main list, and does not need to know from which sublist s/he is
+ serviced.
+
+ ezmlm-idx sublists use the message number of the main list message if
+ they are not indexed. This allows sublists to in bounce messages refer
+ the subscriber to the main list archive. Use ezmlm-make(1) in
+ conjunction with ezmlmsubrc(5) to set up the sublists. See man pages
+ for further details.
+
+ Since the addresses are stored locally, the system is very fast and
+ robust, but it is difficult to add new sublists. ezmlm-split(1) -D
+ supports parsing addresses on stdin and splitting them to stdout (see
+ man page). Thus, if you divide the domain of some sublist(s) onto a
+ net set of sublists, you can use ezmlm-list(1) to collect the
+ addresses, ezmlm-split -D with the new split file to split them, then
+ after clearing the local subscriber databases use ezmlm-sub(1) to add
+ the correct addresses to each new sublist. The section on SQL support
+ describes an alternative way of managing sublists (see section ``ezmlm
+ support for SQL datbases'').
+
+ 4\b4.\b.2\b28\b8.\b. H\bHo\bow\bw t\bto\bo s\bse\ber\brv\bvi\bic\bce\be c\bco\bom\bmm\bma\ban\bnd\bds\bs i\bin\bn t\bth\bhe\be s\bsu\bub\bbj\bje\bec\bct\bt l\bli\bin\bne\be.\b.
+
+ Rfc2142 (standards track) says that for each mailing list list@host,
+ there MUST be an administrative address list-request@host. This is not
+ the default for ezmlm, but can be added with ezmlm-make(1) ``-q'',
+ which adds a ezmlm-request(1) line before the ezmlm-manage(1) line in
+ D\bDI\bIR\bR/\b/m\bma\ban\bna\bag\bge\ber\br. This address is used to manage commands in the
+ ``Subject:'' line, by translating them into appropriate ezmlm command
+ messages.
+
+ 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) services the list-request@host address per rfc2142
+ (standards track). It is usually invoked in D\bDI\bIR\bR/\b/m\bma\ban\bna\bag\bge\ber\br 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 D\bDI\bIR\bR/\b/o\bou\but\btl\blo\boc\bca\bal\bl (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 D\bDI\bIR\bR/\b/o\bou\but\btl\blo\boc\bca\bal\bl, ezmlm-request(1) prefixes the
+ line with the contents of D\bDI\bIR\bR/\b/o\bou\but\btl\blo\boc\bca\bal\bl, thereby building a complete
+ ezmlm command. If a host name is specified, it must match the contents
+ of D\bDI\bIR\bR/\b/o\bou\but\bth\bho\bos\bst\bt, i.e. ezmlm-request(1) in this function will only
+ generate command messages for the local list.
+
+ Thus, a subject of ``subscribe'' to list-request@host will be auto-
+ magically rewritten as a message to list-subscribe-
+ userlocal=userhost@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 that
+ starts 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 D\bDI\bIR\bR/\b/m\bma\ban\bna\bag\bge\ber\br.
+
+ To set up a list to include ezmlm-request processing, use the ezmlm-
+ make(1) ``-q'' switch. The default is to not do this.
+
+
+ 4\b4.\b.2\b29\b9.\b. H\bHo\bow\bw t\bto\bo s\bsu\bup\bpp\bpo\bor\brt\bt a\bal\blt\bte\ber\brn\bna\bat\bti\biv\bve\be c\bco\bom\bmm\bma\ban\bnd\bd n\bna\bam\bme\bes\bs.\b.
+
+ ezmlm-idx>=0.23 allows alternate names for all user commands. This can
+ be used to e.g. make a message to list-remove@host 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.
+
+
+
+
+ 4\b4.\b.3\b30\b0.\b. H\bHo\bow\bw t\bto\bo a\bad\bdd\bd y\byo\bou\bur\br o\bow\bwn\bn c\bco\bom\bmm\bma\ban\bnd\bds\bs.\b.
+
+ The qmail/ezmlm mechanism makes it very easy to add your own commands.
+ You can add them to D\bDI\bIR\bR/\b/m\bma\ban\bna\bag\bge\ber\br, but this requires great care in terms
+ of ordering and exit codes. Easier is to set them up separately with a
+ .\b.q\bqm\bma\bai\bil\bl-\b-l\bli\bis\bst\bt-\b-c\bco\bom\bmm\bma\ban\bnd\bd file.
+
+ Let's assume you want to allow anyone to determine how many
+ subscribers are subscribed to your list with the command list-
+ count@host. Just create a program to do the work:
+
+
+ #!/bin/sh
+ DTLINE='Delivered-To: list-count@host processor'
+ grep "$DTLINE" > /dev/null &&
+ { echo "This message is looping"; exit 100; }
+ {
+ echo "$DTLINE"
+ cat <<EOF
+ From: list-help@host
+ To: $SENDER
+ Subject: list@host subscriber count
+
+ Current number of subscribers:
+ EOF
+ ezmlm-list ~/DIR | wc -l
+ } | /var/qmail/qmail-inject -f list-return- "$SENDER"
+ exit 0
+
+
+
+
+ Then, create D\bDI\bIR\bR/\b/c\bco\bou\bun\bnt\bt containing ``|/path/program'' and then do ``ln
+ -sf DIR/count ~/.qmail-list-count''. Now, the command will pass the
+ message to ``program''. The first thing ``program'' looks for is its
+ delivered-to line to detect looping. If not found, it goes on to print
+ this header, followed by some minimal text and the subscriber number.
+ This can of course be made prettier with ezmlm-list error checking,
+ and maybe in perl, but shows how easy it is to extend ezmlm. All
+ thanks to the DJB/qmail delivery mechanism.
+
+
+ 4\b4.\b.3\b31\b1.\b. H\bHo\bow\bw r\bre\bem\bmo\bot\bte\be a\bad\bdm\bmi\bin\bni\bis\bst\btr\bra\bat\bto\bor\brs\bs c\bca\ban\bn r\bre\bet\btr\bri\bie\bev\bve\be a\ba s\bsu\bub\bbs\bsc\bcr\bri\bib\bbe\ber\br l\bli\bis\bst\bt
+
+ 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.
+ _\bN_\bo_\bt_\be_\b: _\bT_\bh_\bi_\bs _\bo_\bp_\bt_\bi_\bo_\bn _\bi_\bs _\bn_\bo_\bt _\bf_\bu_\bn_\bc_\bt_\bi_\bo_\bn_\ba_\bl _\bu_\bn_\bl_\be_\bs_\bs _\bt_\bh_\be _\bl_\bi_\bs_\bt _\bi_\bs _\bc_\bo_\bn_\bf_\bi_\bg_\bu_\br_\be_\bd _\bf_\bo_\br
+ _\br_\be_\bm_\bo_\bt_\be _\ba_\bd_\bm_\bi_\bn_\bi_\bs_\bt_\br_\ba_\bt_\bi_\bo_\bn_\b, _\bi_\b._\be_\b. _\bt_\bh_\be _\be_\bz_\bm_\bl_\bm_\b-_\bm_\ba_\bk_\be_\b(_\b1_\b) _\b`_\b`_\b-_\br_\bl_\b'_\b' _\bs_\bw_\bi_\bt_\bc_\bh_\be_\bs _\bn_\be_\be_\bd _\bt_\bo
+ _\bb_\bo_\bt_\bh _\bb_\be _\bu_\bs_\be_\bd_\b.
+
+ 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
+
+
+
+
+
+ 4\b4.\b.3\b32\b2.\b. H\bHo\bow\bw r\bre\bem\bmo\bot\bte\be a\bad\bdm\bmi\bin\bni\bis\bst\btr\bra\bat\bto\bor\brs\bs c\bca\ban\bn d\bde\bet\bte\ber\brm\bmi\bin\bne\be t\bth\bhe\be n\bnu\bum\bmb\bbe\ber\br o\bof\bf s\bsu\bub\bb-\b-
+ s\bsc\bcr\bri\bib\bbe\ber\brs\bs
+
+ For the list aaa@example.com, send a message to aaa-listn@example.com.
+ This is preferable to the ``-list'' command for very large lists.
+
+
+ 4\b4.\b.3\b33\b3.\b. H\bHo\bow\bw r\bre\bem\bmo\bot\bte\be a\bad\bdm\bmi\bin\bns\bs c\bca\ban\bn s\bse\bee\be i\bif\bf a\ban\bn a\bad\bdd\bdr\bre\bes\bss\bs i\bis\bs a\ba s\bsu\bub\bbs\bsc\bcr\bri\bib\bbe\ber\br o\bor\br n\bno\bot\bt
+
+ For the list aaa@example.com, and subscriber user@host.cn send a
+ message to aaa-query=host.cn@example.com. Users can do this as well,
+ but in that case the reply is sent to the target address
+ (user@host.cn) and not to the SENDER to protect the subscriber
+ addresses.
+
+
+ 4\b4.\b.3\b34\b4.\b. H\bHo\bow\bw r\bre\bem\bmo\bot\bte\be a\bad\bdm\bmi\bin\bni\bis\bst\btr\bra\bat\bto\bor\brs\bs c\bca\ban\bn s\bse\bea\bar\brc\bch\bh t\bth\bhe\be s\bsu\bub\bbs\bsc\bcr\bri\bip\bpt\bti\bio\bon\bn l\blo\bog\bg
+
+ The same conditions that enable remote administrators to retrieve a
+ subscriber list (see ``'') also enable the remote admin to retrieve
+ the subscription log, i.e. the log of changes made to the subscriber
+ list. The command is list-log@host. The entries are of the form ``date
+ timestamp dir event address comment''. ``dir'' is ``+'' for addition
+ of an address, ``-'' for removal, ``event'' is empty for normal
+ (un)subscribe ``manual'' for changes made with ezmlm-(un)sub, and
+ ``probe'' for removals via bounce handling. ``address'' is the
+ subscription address, and ``comment'' is empty or the subscribers
+ ``From:'' line. The log can be used to look at recent
+ additions/removals and to try to track down a subscriber address from
+ e.g. the name on the ``From:'' line. The log is written on a best-
+ effort basis. In contrast to the subscriber database, entries in the
+ log may be lost at a system crash.
+
+ The remote administrator can do a case-insensitive search through the
+ log with the command list-log.xxx@host, where ``xxx'' is any sequence
+ of letters/numbers that must occur on a line in order for that line to
+ be included in the reply. A ``_'' is a wild card and should be used
+ for special characters as well. Thus, to search for any entry with a
+ host name of host* mail list-log._host and to find entries for ``Keith
+ John...'' etc, use list-log.keith_john.
+
+ For SQL-enabled lists, this command searches the ``list_slog'' table.
+
+
+ 4\b4.\b.3\b35\b5.\b. H\bHo\bow\bw t\bte\bex\bxt\bt f\bfi\bil\ble\be e\bed\bdi\bit\bti\bin\bng\bg w\bwo\bor\brk\bks\bs.\b.
+
+ If a list is set up with the ezmlm-make(1) ``-n'' switch, or if the
+ ``-e'' switch is added to the ezmlm-manage(1) line in D\bDI\bIR\bR/\b/m\bma\ban\bna\bag\bge\ber\br,
+ 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 D\bDI\bIR\bR/\b/t\bte\bex\bxt\bt/\b/. Only files where editing seems reasonable are
+ included in the list. The remote administrator can edit any file in
+ D\bDI\bIR\bR/\b/t\bte\bex\bxt\bt/\b/ 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
+ ~\b~/\b/.\b.e\bez\bzm\bml\blm\bmr\brc\bc. To reset the list's text files back to their default
+ contents (as specified by e\bez\bzm\bml\blm\bmr\brc\bc(\b(5\b5)\b)), use the ezmlm-make(1) ``-ee''
+ switch together with any other switches used to set up the list, or
+ the ``-++'' switch and any switches that you whish to change from the
+ current configuration.
+
+
+ 4\b4.\b.3\b36\b6.\b. H\bHo\bow\bw s\bsu\bub\bbj\bje\bec\bct\bt l\bli\bin\bne\be p\bpr\bre\bef\bfi\bix\bxe\bes\bs w\bwo\bor\brk\bk.\b.
+
+ 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 D\bDI\bIR\bR/\b/p\bpr\bre\bef\bfi\bix\bx. The only
+ format that makes any sense is ``list:'' or ``(list)'' or such.
+
+ The message number prefix is activated by putting e.g. ``(list-#)''
+ into D\bDI\bIR\bR/\b/p\bpr\bre\bef\bfi\bix\bx. ``#'' 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.
+
+
+ 4\b4.\b.3\b37\b7.\b. H\bHo\bow\bw b\bbo\bou\bun\bnc\bce\bes\bs a\bar\bre\be h\bha\ban\bnd\bdl\ble\bed\bd.\b.
+
+ Ezmlm messages are sent with an envelope sender (``Return-Path'') that
+ directs bounces to D\bDI\bIR\bR/\b/b\bbo\bou\bun\bnc\bce\ber\br and also via ``VERP'' contain
+ information about the intended recipient. Thus, programs run from
+ D\bDI\bIR\bR/\b/b\bbo\bou\bun\bnc\bce\ber\br know the subscriber for whom the message bounced. ezmlm-
+ weed(1) is used to weed out delivery delay notification and other
+ junk. 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. D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br
+ goes through these bounce files. If it finds any that are older than
+ 1,000,000 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.
+
+ ezmlm-warn(1) is normally run from D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br. This can take quite a
+ lot of resources, if there are a large number of bouncing addresses
+ (>>1000) on a busy list, since by default all bounces are stored in a
+ single directory and ezmlm-warn(1) examines all of them with each
+ invocation. ezmlm-idx->=0.32 changes bounce handling to improve
+ performance for large lists. Bounces are stored in subdirectories of
+ D\bDI\bIR\bR/\b/b\bbo\bou\bun\bnc\bce\be/\b/d\bd/\b/, one per 10,000 seconds. The corresponding address
+ hashes are stored in 16 subdirectories of D\bDI\bIR\bR/\b/b\bbo\bou\bun\bnc\bce\be/\b/h\bh/\b/. Instead of
+ looking at all bounces, ezmlm-warn(1) processes only the bounces in
+ D\bDI\bIR\bR/\b/b\bbo\bou\bun\bnc\bce\be/\b/d\bd/\b/ subdirectories that are ``due''. In addition, ezmlm-
+ warn(1) uses D\bDI\bIR\bR/\b/b\bbo\bou\bun\bnc\bce\be/\b/l\bla\bas\bst\btd\bd as a simple lockout, to assure that it
+ will do work only at most once every 5.5 hours. (Times are scaled to
+ the ezmlm-warn(1) ``-t'' argument if used.) Together, these changes
+ assure that bounce handling will scale well in the default
+ configuration, even for very large lists.
+
+
+ 4\b4.\b.3\b38\b8.\b. H\bHo\bow\bw t\bth\bhe\be i\bin\bnf\bfo\bo a\ban\bnd\bd f\bfa\baq\bq c\bco\bom\bmm\bma\ban\bnd\bds\bs w\bwo\bor\brk\bk.\b.
+
+ The _\b-_\bi_\bn_\bf_\bo and _\b-_\bf_\ba_\bq commands simply reply with the contents of the
+ D\bDI\bIR\bR/\b/t\bte\bex\bxt\bt/\b/i\bin\bnf\bfo\bo and D\bDI\bIR\bR/\b/t\bte\bex\bxt\bt/\b/f\bfa\baq\bq files. Edit these files directly or
+ remotely (see ``How to remotely edit dir/text files''). The
+ D\bDI\bIR\bR/\b/t\bte\bex\bxt\bt/\b/i\bin\bnf\bfo\bo 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'').
+
+
+ 4\b4.\b.3\b39\b9.\b. H\bHo\bow\bw t\bth\bhe\be g\bgl\blo\bob\bba\bal\bl e\bez\bzm\bml\blm\bm l\bli\bis\bst\bt a\bad\bdd\bdr\bre\bes\bss\bs w\bwo\bor\brk\bks\bs.\b.
+
+ Sometimes, it is desirable to have a host- or user-wide address that
+ can list available mailing lists.
+
+ 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.
+
+
+ 4\b4.\b.4\b40\b0.\b. H\bHo\bow\bw e\bez\bzm\bml\blm\bm-\b-c\bcr\bro\bon\bn w\bwo\bor\brk\bks\bs.\b.
+
+ If you are a user and have crond(8) access, if you do not need to get
+ digests at specific times, or if you are a system administrator
+ setting up lists, there is no reason for you to use ezmlm-cron(1). If
+ you are a system administrator not allowing users crond(8) access or a
+ user that needs digests at specific times, but without crond(8)
+ access, read on.
+
+ ezmlm-cron(1) is a very restrictive interface to crond(8). ezmlm-
+ cron(1) 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
+ e\bez\bzc\bcr\bro\bon\bnr\brc\bc is set up by the sysadmin and controls what trigger messages
+ specific users may set up via ezmlm-cron(1).
+
+ 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
+
+
+
+ 4\b4.\b.4\b41\b1.\b. H\bHo\bow\bw e\bez\bzm\bml\blm\bm-\b-m\bma\bak\bke\be w\bwo\bor\brk\bks\bs.\b.
+
+ 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.
+
+ 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.
+
+ ezmlm-make(1) reads its command line arguments and switches, then
+ creates the list directory. If the ``-e'' edit or ``-+'' sticky edit
+ switches are 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(5) located in the /\b/e\bet\btc\bc/\b/ 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
+ .\b.e\bez\bzm\bml\blm\bmr\brc\bc file and use it instead. If this file does not exist, ezmlm-
+ make(1) will print a warning and use the previously discussed
+ ezmlmrc(5) files in the same order. You can also use ``-C
+ _\be_\bz_\bm_\bl_\bm_\br_\bc_\b._\ba_\bl_\bt'' to use _\be_\bz_\bm_\bl_\bm_\br_\bc_\b._\ba_\bl_\bt as the ezmlmrc(5) file. Again, ezmlm-
+ make(1) will fall back to the others with a warning, if the specified
+ ezmlmrc(5) file is not found.
+
+ When not run in ``-e edit'' or ``-+'' sticky edit modes, ezmlm-make(1)
+ first creates the list directory. It also as the last step of its
+ action creates D\bDI\bIR\bR/\b/k\bke\bey\by containing the key used for cookie generation.
+
+ The ezmlmrc(5) file consists of a number of file names relative to the
+ list directory, followed by conditional flags (see ezmlm-make(1) and
+ ezmlmrc(5) 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(5) controls (within reason) the entire operation of ezmlm-
+ make(1). ezmlmrc(5) 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. The only caveat is that the
+ list state is undefined while editing is in progress. Thus, it is
+ advisable to prevent mail delivery by setting the ``sticky'' bit on
+ the user's home directory while editing lists.
+
+ ezmlm-make(1) will create the file D\bDI\bIR\bR/\b/c\bco\bon\bnf\bfi\big\bg. 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 D\bDI\bIR\bR/\b/c\bco\bon\bnf\bfi\big\bg. 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
+ D\bDI\bIR\bR/\b/c\bco\bon\bnf\bfi\big\bg.
+
+ _\bN_\bo_\bt_\be_\b: D\bDI\bIR\bR/\b/t\bte\bex\bxt\bt/\b/ files will be created but not overwritten when using
+ the ``-e'' or ``-+'' edit switches. This is to preserve manual
+ customizations. To overwrite these and reset the files to the content
+ specified by e\bez\bzm\bml\blm\bmr\brc\bc, use ``-ee'' or ``-++''.
+
+ _\bN_\bo_\bt_\be_\b: As of ezmlm-idx-0.40 the ezmlm-make(1) ``-c'' and ``-C file''
+ switches are sticky when using ``-+'' or ``-++'', so you do not need
+ to specify them. This feature is disabled if ezmlm-make(1) is run as
+ root.
+
+
+ 4\b4.\b.4\b42\b2.\b. W\bWh\bha\bat\bt n\bna\bam\bme\bes\bs c\bca\ban\bn I\bI u\bus\bse\be f\bfo\bor\br m\bmy\by l\bli\bis\bst\bts\bs?\b?
+
+ Rather than restrict you to a single E-mail address (user@host), qmail
+ in the default setup gives you control over an infinite number of
+ addresses user-*@host. Of course, you (normally) have no way of
+ controlling elsewhere@host since that could lead to overlap between
+ users' ``e-mail address space''. As a consequence, all you mailing
+ lists have to be named user-xx@host where ``user'' is your user name
+ and ``xx'' is anything. You cannot create e.g. mylist@host, only user-
+ mylist@host. To create the list user-list@host do:
+
+
+ % ezmlm-make ~/list ~/.qmail-list user-list host
+
+
+
+
+ Notice that ``user'' is n\bno\bot\bt part of the .\b.q\bqm\bma\bai\bil\bl file name.
+
+ There are two way to create lists with names not starting with your
+ user name: First, qmail can be set up so that you control a virtual
+ domain (see below). Second, the system administrator can set up lists
+ with arbitrary names within the ~\b~a\bal\bli\bia\bas\bs/\b/ directory.
+
+
+ 4\b4.\b.4\b43\b3.\b. L\bLi\bis\bst\bts\bs i\bin\bn v\bvi\bir\brt\btu\bua\bal\bl d\bdo\bom\bma\bai\bin\bns\bs
+
+ If you use qmail>=1.02 and ezmlm-idx>=0.32, lists under virtual
+ domains work just like other lists and require no adjustments. You can
+ choose any local name for the list and the ezmlm-make(1) argument
+ ``local'' is that name; ``host'' is the name of the virtual domain.
+
+
+ 4\b4.\b.4\b44\b4.\b. H\bHo\bow\bw d\bdo\bo I\bI m\bma\bak\bke\be c\bcu\bus\bst\bto\bom\bmi\biz\bza\bat\bti\bio\bon\bn s\bsi\bim\bmp\bpl\ble\be f\bfo\bor\br m\bme\be/\b/m\bmy\by u\bus\bse\ber\brs\bs?\b?
+
+ 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 ``e\bez\bzm\bml\blm\bmr\brc\bc''. A default e\bez\bzm\bml\blm\bmr\brc\bc(\b(5\b5)\b) is installed in the
+ ezmlm binary directory. If installed, a system-wide customized ezmlmrc
+ file in /\b/e\bet\btc\bc/\b/e\bez\bzm\bml\blm\bmr\brc\bc (or symlinked from there) overrides this.
+ Installing a ~\b~/\b/.\b.e\bez\bzm\bml\blm\bmr\brc\bc file in a user d\bdo\bot\btd\bdi\bir\br and using the ezmlm-
+ make(1) ``-c'' switch allows further per user customization (see
+ ``Customizing ezmlm-make operation'').
+
+
+ 5\b5.\b. e\bez\bzm\bml\blm\bm s\bsu\bup\bpp\bpo\bor\brt\bt f\bfo\bor\br S\bSQ\bQL\bL d\bda\bat\bta\bab\bba\bas\bse\bes\bs.\b.
+
+
+ 5\b5.\b.1\b1.\b. W\bWh\bhy\by u\bus\bse\be a\ban\bn S\bSQ\bQL\bL d\bda\bat\bta\bab\bba\bas\bse\be w\bwi\bit\bth\bh e\bez\bzm\bml\blm\bm?\b?
+
+ The main advantages are that you are using an address database system
+ that can easily be accessed from any number of other programs via
+ ODBC, perl, java, PHP, ... You can easily hook up ezmlm with your
+ customer database, etc. ezmlm programs compiled with SQL support (and
+ when available also those compiled with support for other SQL servers)
+ are entirely backwards compatible. You can mix SQL dbs with normal
+ ezmlm dbs, and convert lists between them.
+
+
+ 5\b5.\b.2\b2.\b. W\bWh\bhy\by n\bno\bot\bt t\bto\bo u\bus\bse\be a\ban\bn S\bSQ\bQL\bL d\bda\bat\bta\bab\bba\bas\bse\be w\bwi\bit\bth\bh e\bez\bzm\bml\blm\bm.\b.
+
+ The main disadvantages of the SQL version are that you need to be
+ familiar with the SQL server, the binaries are quite a bit larger, and
+ you are trusting your addresses to a large database program, rather
+ than a small and easily audited set of ezmlm programs. Also, the SQL
+ server becomes a single point of failure.
+
+ Ezmlm with SQL support continues to rely on qmail stability. If
+ connection fails, ezmlm aborts with a temporary error causing
+ redelivery at a later time point.
+
+
+ 5\b5.\b.3\b3.\b. T\bTa\bab\bbl\ble\bes\bs u\bus\bse\bed\bd f\bfo\bor\br (\b(M\bMy\by)\b)S\bSQ\bQL\bL s\bsu\bup\bpp\bpo\bor\brt\bt.\b.
+
+ The basic philosophy is that the database can be on any host (if you
+ use SENDER restrictions, connectivity to the main host is more
+ important than to the sublists), and you choose the database and
+ ``table root'' names. The default database is ``ezmlm'' and the
+ default table root is ``list''. Each list has a separate table root.
+ Any number of lists can share a database.
+
+ The main list address table is named with the table root only, others
+ have that name with various suffixes. In the following ``list'' is
+ used as the table root.
+
+
+ 5\b5.\b.3\b3.\b.1\b1.\b. A\bAd\bdd\bdr\bre\bes\bss\bs t\bta\bab\bbl\ble\bes\bs.\b.
+
+
+ l\bli\bis\bst\bt
+ List subscriber addresses.
+
+ l\bli\bis\bst\bt_\b_d\bdi\big\bge\bes\bst\bt
+ Digest list subscriber addresses.
+
+ l\bli\bis\bst\bt_\b_a\bal\bll\blo\bow\bw
+ List subscriber alias addresses. Used only if SENDER
+ restrictions are used for the list. This is configured in the
+ default SQL list setup, but a local (ezmlm-style non-SQL)
+ database could also be used.
+
+ l\bli\bis\bst\bt_\b_d\bde\ben\bny\by
+ List deny addresses. This table is created, but the default
+ configuration, if it uses the ``deny'' addresses at all, will do
+ so with a local database.
+
+ l\bli\bis\bst\bt_\b_m\bmo\bod\bd
+ Moderator addresses. Created for completeness, but not used in
+ the default configuration. If moderators are used, the addresses
+ are stored in a local database.
+
+
+ 5\b5.\b.3\b3.\b.2\b2.\b. S\bSu\bub\bbs\bsc\bcr\bri\bib\bbe\ber\br l\blo\bog\bg t\bta\bab\bbl\ble\bes\bs.\b.
+
+ For each of the above tables, there is a ``*_slog'' table that
+ contains one row per transaction against the corresponding address
+ table. The entries contain a time stamp, the subscription address; a
+ direction indicator (``-'' for removals, ``+'' for additions); a type
+ indicator (blank for ezmlm-manage, ``m'' for ``manual'', ``p'' for
+ ``probe, i.e. bounce handling; and the subscriber ``From:'' line
+ contents (only additions and only when made by ezmlm-manage or by
+ ``ezmlm-sub(1) -n'').
+
+
+ 5\b5.\b.3\b3.\b.3\b3.\b. M\bMe\bes\bss\bsa\bag\bge\be l\blo\bog\bgg\bgi\bin\bng\bg t\bta\bab\bbl\ble\bes\bs.\b.
+
+ For both the list and the digest list, there are a pair of tables that
+ log messages:
+
+
+ l\bli\bis\bst\bt_\b_c\bco\boo\bok\bki\bie\be
+ The main list stores the message number and a pseudo-random
+ cookie in this table when it processes the message. The cookie
+ is derived from the secret D\bDI\bIR\bR/\b/k\bke\bey\by, the message sender and the
+ message number. Thus, it is non-repeating and virtually
+ impossible to guess beforehand. Sublists will check that the
+ cookie sent with the message is the same as the one received
+ with the message.
+
+ The digest list is created similarly, except that it is ezmlm-
+ get(1) that originates the message and creates the cookie. This
+ is done in ``list_digest_cookie''.
+
+
+ l\bli\bis\bst\bt_\b_m\bml\blo\bog\bg
+ Both the main list and the sublists make entries in this table.
+ Each entry consists of a time stamp, a message number, a list
+ number, and a code. The code is 0 for message arrival, 1 for
+ ``finished processing'', 2 for ``receipt received'' and -1 for
+ bounce. The lists will refuse to process messages that do not
+ have the correct cookie, or if the message already has an entry
+ with a code of greater than 0. To inject a message at the
+ sublist, an attacker would have to inject a message with the
+ correct code before the list has processed the ``real'' message,
+ or subvert the SQL server. In practice, this is very hard to do,
+ unless the attacker has broken security at the database server
+ or a sublist. This authentication mechanism is intended to make
+ it safe to sublist moderated lists. It also blocks any message
+ duplication between main list and sublist from being propagated
+ to the subscribers.
+
+ The codes 2 for ``receipt received'' and -1 for bounce are
+ entered by ezmlm-receipt(1) at the main list. This program is
+ configured instead of ezmlm-return(1) if the main list was set
+ up with ``ezmlm-make -w6''. ezmlm-receipt(1) checks the cookie
+ of messages addresses to mainlocal-return-receipt@mainhost and
+ if correct enters the ``receipt received'' code. This address is
+ normally in the subscriber database with a hash of 98, so that
+ each list sends a message to the address _\ba_\bf_\bt_\be_\br all subscriber
+ addresses.
+
+ Bounces of sublist messages should not lead to removal of the
+ sublist from the database. ezmlm-receipt(1) will instead log the
+ bounce to the ``list_mlog'' table. It will also store up to 50
+ bounces in the bounce directory. This helps error detection and
+ diagnosis. After the first 50 bounces, no more bounces are
+ stored, until you manually remove the old ones. This is to
+ prevent filling up your hard disk in case a configuration error
+ causes a deluge of bounces.
+
+ The digest list is treated in the same manner. Here, the tables
+ is ``list_digest_mlog'' and the feedback address is mainlocal-
+ digest-return-receipt@mainhost.
+
+
+
+
+ 5\b5.\b.4\b4.\b. H\bHo\bow\bw t\bto\bo s\bse\bet\bt u\bup\bp a\ba s\bsi\bim\bmp\bpl\ble\be l\bli\bis\bst\bt w\bwi\bit\bth\bh S\bSQ\bQL\bL s\bsu\bup\bpp\bpo\bor\brt\bt.\b.
+
+ To use SQL database support, you have to compile the programs with SQL
+ support. Currently, only MySQL support is available. See I\bIN\bNS\bST\bTA\bAL\bLL\bL.\b.i\bid\bdx\bx
+ in the package on how to do this.
+
+ The programs with SQL support will work exactly like the normal
+ programs for standard lists. However, if the file s\bsq\bql\bl exists in the
+ basedir, it turns on the SQL mode and it is expected to contain SQL
+ server connect info in the format
+
+ ``host:port:user:password:database:table''
+
+
+ Here, ``Host'' is the SQL database server host, ``port'' can be left
+ blank to use the default port, ``user'' and ``password'' are connec-
+ tion credentials for a user you need to define and grant access to the
+ database. ``Table'' is the name of the address table (``list'' in the
+ examples above and ``list_digest'' for the corresponding digest list).
+ For list clusters, ``:sublist'' is suffixed to this info and it is the
+ name/address of the sublist.
+
+ For each address database, you also need to create the address table
+ as well as the ``*_slog'' subscription log table. In addition, you
+ should create a ``*_cookie'' and ``*_mlog'' table for message logging.
+ This is all it takes to start using an SQL database.
+
+
+ 5\b5.\b.4\b4.\b.1\b1.\b. H\bHe\bel\blp\bpe\ber\br p\bpr\bro\bog\bgr\bra\bam\bms\bs f\bfo\bor\br S\bSQ\bQL\bL-\b-e\ben\bna\bab\bbl\ble\bed\bd l\bli\bis\bst\bts\bs.\b.
+
+ Two programs are supplied in the distribution to make it easier to
+ create the database user and tables. Also, ezmlm-make(1) has support
+ for setting up SQL-enabled lists.
+
+
+ C\bCr\bre\bea\bat\bti\bin\bng\bg t\bth\bhe\be t\bta\bab\bbl\ble\bes\bs
+ ezmlm-mktab(1) will create the necessary tables:
+
+
+ % ezmlm-mktab -d table
+
+
+
+
+ Pipe this into the SQL client with the appropriate administrator
+ credentials needed to create tables (see MySQL documentation, e.g.
+ <http://www.tcx.se/>).
+
+ For most lists, the only addresses that are stored in the SQL
+ database are the subscribers of list and digest, and the ``allow''
+ aliases. It is NOT normally advisable to store moderator addresses
+ there, since they are needed only at the main list and secrecy is
+ more important. ``Deny'' addresses are few and again only needed at
+ the main list. ``Allow'' are put in the SQL database when using the
+ default ezmlmrc file only to make all relevant addresses
+ manipulatable via the SQL server. The other tables are created, in
+ case they are wanted (the cost for having them as empty table is
+ zero). The basedir/sql file is the decision point. If it exists, an
+ SQL table is used; if not a local ezmlm db is used.
+
+
+ C\bCr\bre\bea\bat\bti\bin\bng\bg a\ba u\bus\bse\ber\br e\ben\bnt\btr\bry\by
+ Create a user that has full access to the database from the list
+ host. How to do this depends on the RDBMS.
+
+
+ C\bCr\bre\bea\bat\bti\bin\bng\bg t\bth\bhe\be l\bli\bis\bst\bt
+ ezmlm-make(1) supports SQL-enabled lists with the ``-6'' switch:
+
+
+ % ezmlm-make other_switches -6 'host:port:user:pw:db:table' \
+ dir dot local host
+
+
+
+
+ Will create an SQL-enabled list that uses the SQL server for the
+ main list subscribers, digest list subscribers (if configured) and
+ ``allow'' poster alias addresses (if configured).
+
+
+ 5\b5.\b.5\b5.\b. M\bMa\ban\bnu\bua\bal\bll\bly\by m\bma\ban\bni\bip\bpu\bul\bla\bat\bti\bin\bng\bg t\bth\bhe\be s\bsu\bub\bbs\bsc\bcr\bri\bib\bbe\ber\brs\bs o\bof\bf a\ba S\bSQ\bQL\bL-\b-e\ben\bna\bab\bbl\ble\bed\bd l\bli\bis\bst\bt.\b.
+
+ ezmlm-sub(1), ezmlm-unsub(1), and ezmlm-list(1) work as you would
+ expect also with a SQL-enabled list. ezmlm-list(1) may be minimally
+ slower (depending on network speed) if the SQL server is not local.
+ ezmlm-sub(1) and ezmlm-unsub(1) will be faster, but this is noticeable
+ only with very large subscriber lists and addition/removal of large
+ numbers of addresses (more than several thousands).
+
+
+ 5\b5.\b.6\b6.\b. C\bCo\bon\bnv\bve\ber\brt\bti\bin\bng\bg t\bto\bo a\ban\bnd\bd f\bfr\bro\bom\bm a\ban\bnd\bd S\bSQ\bQL\bL d\bda\bat\bta\bab\bba\bas\bse\be.\b.
+
+ Just like other programs, ezmlm-list(1), ezmlm-sub(1), and ezmlm-
+ unsub(1) will work with normal address databases in the absence of
+ D\bDI\bIR\bR/\b/s\bsq\bql\bl. However, they also have a ``-M'' switch to force this
+ behavior even in the presence of D\bDI\bIR\bR/\b/s\bsq\bql\bl. This is used to convert an
+ address database from the standard type to the SQL type:
+
+
+ % ezmlm-list -M dir | xargs ezmlm-sub dir
+
+
+
+
+ or from the SQL version to the standard type:
+
+
+ % ezmlm-list dir | xargs ezmlm-sub -M dir
+
+
+
+
+ To synchronize the two, remove one and then update it with ezmlm-
+ sub(1) from the other. Alternatively, sort the ezmlm-list(1) output
+ for both, use diff and sed/awk to get separate files of the differ-
+ ences, and use ezmlm-sub(1) and ezmlm-unsub(1) to apply the differ-
+ ences to the appropriate database.
+
+ This type of conversion can serve as a convenient means to convert a
+ list from one type to another, to back up databases, and to move
+ subscriber addresses from a standard list to a SQL table for other
+ purposes, or from a SQL database to a standard mailing list (you may
+ need to use addresses from a SQL table, without wanting your lists to
+ be dependent on an SQL server for day to day operation).
+
+ _\bN_\bo_\bt_\be_\b: This inter-conversion requires the D\bDI\bIR\bR/\b/s\bsq\bql\bl file. If you do not
+ run the list against an SQL server, you need to disable deliveries
+ before you temporarily create this file. Otherwise, the list will run
+ against the SQL database during the time D\bDI\bIR\bR/\b/s\bsq\bql\bl exists.
+
+
+ 5\b5.\b.7\b7.\b. O\bOp\bpt\bti\bim\bmi\biz\bzi\bin\bng\bg M\bMy\byS\bSQ\bQL\bL f\bfo\bor\br e\bez\bzm\bml\blm\bm.\b.
+
+
+ 5\b5.\b.7\b7.\b.1\b1.\b. A\bAd\bdd\bdr\bre\bes\bss\bs S\bSE\bEL\bLE\bEC\bCT\bTs\bs,\b, a\bad\bdd\bdi\bit\bti\bio\bon\bns\bs,\b, r\bre\bem\bmo\bov\bva\bal\bls\bs.\b.
+
+ ezmlm-idx-0.40 simplifies the SQL support and queries over ezmlm-
+ idx-0.32 at the cost of dropping distributed sublist support. We have
+ figured out a simpler way to support the latter, which hopefully will
+ be incorporated into ezmlm in the future (written under contract).
+
+ With the simplification, the queries are very straight forward, and
+ tuning is indicated only under extreme circumstances (very many very
+ large and busy lists or constant addition/removal of many addresses).
+
+
+ 5\b5.\b.8\b8.\b. M\bMa\bai\bin\bnt\bte\ben\bna\ban\bnc\bce\be o\bof\bf t\bth\bhe\be M\bMy\byS\bSQ\bQL\bL d\bda\bat\bta\bab\bba\bas\bse\be.\b.
+
+ Weekly to monthly error checks on MySQL tables is recommended. Best is
+ to use:
+
+
+ # isamchk -s -O readbuffer=2M */*.ISM
+
+
+
+
+ Other options allow automatic correction of errors, but are dangerous
+ if tables are accessed while isamchk is running.
+
+ Other isamchk options allow recovery of space after frequent
+ insert/delete of addresses (can also be done with ``OPTIMIZE TABLE''),
+ key optimization, etc. See the MySQL documentation (
+ <http://www.tcx.se>) for more info.
+
+
+ 6\b6.\b. P\bPo\bos\bss\bsi\bib\bbl\ble\be e\ber\brr\bro\bor\br c\bco\bon\bnd\bdi\bit\bti\bio\bon\bns\bs i\bin\bn e\bez\bzm\bml\blm\bm l\bli\bis\bst\bts\bs.\b.
+
+
+ 6\b6.\b.1\b1.\b. W\bWh\bha\bat\bt d\bdo\bo I\bI d\bdo\bo i\bif\bf e\bez\bzm\bml\blm\bm d\bdo\boe\bes\bsn\bn'\b't\bt w\bwo\bor\brk\bk?\b?
+
+ Try to determine where the problem occurs and how to reproduce it:
+
+ +\bo Do messages to ezmlm return an error message to the sender or not?
+
+ +\bo What is/are the error message(s)?
+
+ +\bo What does ezmlm log into the mail log?
+
+ +\bo Are you using a setup with virtual domains, and qmail<1.02 or
+ ezmlm-idx<0.31? If so, have you adjusted D\bDI\bIR\bR/\b/i\bin\bnl\blo\boc\bca\bal\bl (see
+ ``Adapting ezmlm-make for virtual domains'')?
+
+ +\bo Are posts sent out to the subscribers?
+
+ +\bo Are there subscribers?
+
+
+ % ezmlm-list DIR
+
+
+
+
+ +\bo Are there moderators?
+
+
+
+ % ezmlm-list moddir
+
+
+
+
+ where ``moddir'' is the contents of D\bDI\bIR\bR/\b/r\bre\bem\bmo\bot\bte\be (for remote admin
+ lists), of D\bDI\bIR\bR/\b/m\bmo\bod\bds\bsu\bub\bb (for subscription moderated lists) or D\bDI\bIR\bR/\b/m\bmo\bod\bd-\b-
+ p\bpo\bos\bst\bt (for message moderation), if and only if the contents start with
+ a forward slash. The default in all cases is D\bDI\bIR\bR/\b/m\bmo\bod\bd/\b/. If both
+ D\bDI\bIR\bR/\b/m\bmo\bod\bds\bsu\bub\bb and D\bDI\bIR\bR/\b/r\bre\bem\bmo\bot\bte\be contain directory names, the one in D\bDI\bIR\bR/\b/m\bmo\bod\bd-\b-
+ s\bsu\bub\bb is used for both subscription moderation and remote admin.
+
+ +\bo 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).
+
+ +\bo Read the qmail log and capture relevant parts.
+
+ +\bo Did you customize the package at all? If so, try the default
+ settings which are known to work.
+
+ +\bo Did you customize e\bez\bzm\bml\blm\bmr\brc\bc(\b(5\b5)\b)? Try to use the default copy (skip the
+ -c switch).
+
+ +\bo Did your customization of .\b.e\bez\bzm\bml\blm\bmr\brc\bc fail to have an effect?
+ Remember to use the -c switch. The .\b.e\bez\bzm\bml\blm\bmr\brc\bc file used is the one in
+ ``dotdir'', i.e. the directory where the .\b.q\bqm\bma\bai\bil\bl files go, usually,
+ but NOT necessarily, the one in your home directory.
+
+ +\bo 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.
+
+ +\bo Make sure to take notes of how the list was created (which flags
+ you used, etc.).
+
+ +\bo use ezmlm-check(1) (see ``Using ezmlm-check to find setup
+ errors''). and compare the variables identified by ezmlm-check to
+ D\bDI\bIR\bR/\b/i\bin\bnl\blo\boc\bca\bal\bl, etc. If you don't get a reply from ezmlm-check, then
+ message was not delivered properly. Check your qmail setup.
+
+ +\bo Try to find your problem or a question/item close to it in the FAQ.
+
+ +\bo 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.
+
+
+ 6\b6.\b.2\b2.\b. H\bHo\bow\bw d\bdo\bo I\bI r\bre\bep\bpo\bor\brt\bt e\bez\bzm\bml\blm\bm b\bbu\bug\bgs\bs?\b?
+
+ 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 (unlikely), please send a
+ similar bug report to djb@cr.yp.to or djb-ezmlm@cr.yp.to. 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.
+
+
+ 6\b6.\b.3\b3.\b. W\bWh\bhe\ber\bre\be d\bdo\bo I\bI s\bse\ben\bnd\bd s\bsu\bug\bgg\bge\bes\bst\bti\bio\bon\bns\bs f\bfo\bor\br e\bez\bzm\bml\blm\bm-\b-i\bid\bdx\bx i\bim\bmp\bpr\bro\bov\bve\bem\bme\ben\bnt\bts\bs?\b?
+
+ E-mail to lindberg@id.wustl.edu, ideally with a context diff. For
+ ezmlm proper, ezmlm@list.cr.yp.to may be better.
+
+
+ 6\b6.\b.4\b4.\b. U\bUs\bsi\bin\bng\bg e\bez\bzm\bml\blm\bm-\b-t\bte\bes\bst\bt t\bto\bo c\bch\bhe\bec\bck\bk t\bth\bhe\be e\bez\bzm\bml\blm\bm(\b(-\b-i\bid\bdx\bx)\b) p\bpr\bro\bog\bgr\bra\bam\bms\bs.\b.
+
+ ezmlm-test(1) tests the different ezmlm(-idx) programs. It is useful
+ to test your installation. If this program succeeds, it is not likely
+ that you have problems due to platform-specific ezmlm(-idx) bugs. If
+ ezmlm-test(1) fails, this is the place to start. The program is good
+ at finding problems but not that easy to use to determine the cause.
+ Start by finding the place where it fails, recreate the conditions
+ (add ``exit 0'' just before the point of failure and set the
+ environment variables as set by the script), then try to run the
+ command manually. ~\b~/\b/_\b__\b_T\bTS\bST\bTD\bDI\bIR\bR_\b__\b_e\ber\brr\br may contain a relevant error
+ message. For further help, E-mail lindberg@id.wustl.edu.
+
+
+ 6\b6.\b.5\b5.\b. U\bUs\bsi\bin\bng\bg e\bez\bzm\bml\blm\bm-\b-c\bch\bhe\bec\bck\bk t\bto\bo f\bfi\bin\bnd\bd s\bse\bet\btu\bup\bp e\ber\brr\bro\bor\brs\bs.\b.
+
+ ezmlm-check(1) is included in the ezmlm-idx distribution. ezmlm-
+ check(1) is an evolving shell script which when put into a .\b.q\bqm\bma\bai\bil\bl 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
+ D\bDI\bIR\bR/\b/i\bin\bnh\bho\bos\bst\bt mismatch, missing files, etc. To use ezmlm-check(1), place
+ a line:
+
+
+ |/usr/local/bin/ezmlm/ezmlm-check 'DIR'
+
+
+
+
+ where ``DIR'' is the list directory, as the first line in D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br
+ (for mail to list), D\bDI\bIR\bR/\b/m\bma\ban\bna\bag\bge\ber\br (for mail to list-subscribe, list-
+ help, etc), D\bDI\bIR\bR/\b/m\bmo\bod\bde\ber\bra\bat\bto\bor\br (for mail to list-accept, list-reject).
+ ezmlm-check(1) will send its output to SENDER. The rest of the .\b.q\bqm\bma\bai\bil\bl
+ 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.
+
+
+ 6\b6.\b.6\b6.\b. P\bPo\bos\bst\bts\bs a\bar\bre\be r\bre\bej\bje\bec\bct\bte\bed\bd:\b: S\bSo\bor\brr\bry\by,\b, n\bno\bo m\bma\bai\bil\blb\bbo\box\bx h\bhe\ber\bre\be b\bby\by t\bth\bha\bat\bt n\bna\bam\bme\be
+ (\b(#\b#5\b5.\b.1\b1.\b.1\b1)\b).\b.
+
+ qmail tried to deliver the mail, but there is no mailbox with that
+ name. ezmlm-make(1) was used with incorrect arguments, often in
+ conjunction with a virtual domain setup. If the list is in a virtual
+ domain, the ``host'' argument for ezmlm-make(1) should be the virtual
+ domain, not the real host name. See ``What names can I use for my
+ mailing lists?'' and ``Lists in virtual domains'' for more info.
+
+ Other possibilities are that your qmail setup is incorrect. For a
+ virtual domain controlled by user ``virt'', create ~\b~v\bvi\bir\brt\bt/\b/.\b.q\bqm\bma\bai\bil\bl-\b-t\bte\bes\bst\bt
+ containing ``|/bin/echo "It worked"; exit 100''. Now send mail to
+ test@virtual.dom. If delivery works, you should get an error message
+ ``It worked'' back. If you get anything else, you need to adjust your
+ qmail setup. Similarly, for a normal user, create ~\b~u\bus\bse\ber\br/\b/.\b.q\bqm\bma\bai\bil\bl-\b-t\bte\bes\bst\bt
+ and mail user-test@host to test that you control extension addresses.
+ If this fails, contact your system administrator or adjust your qmail
+ setup.
+
+ If these tests worked, but your list still does not, you most likely
+ supplied an incorrect ``dot'' argument for ezmlm-manage(1). It should
+ be ~\b~v\bvi\bir\brt\bt/\b/.\b.q\bqm\bma\bai\bil\bl-\b-t\bte\bes\bst\bt for the list test@virtual.dom and ~\b~u\bus\bse\ber\br/\b/.\b.q\bqm\bma\bai\bil\bl-\b-
+ t\bte\bes\bst\bt for the list user-test@host.
+
+
+ 6\b6.\b.7\b7.\b. P\bPo\bos\bst\bt a\bar\bre\be n\bno\bot\bt s\bse\ben\bnt\bt t\bto\bo s\bsu\bub\bbs\bsc\bcr\bri\bib\bbe\ber\brs\bs.\b.
+
+
+ N\bNo\bon\bn-\b-m\bmo\bod\bde\ber\bra\bat\bte\bed\bd l\bli\bis\bst\bts\bs
+
+ 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, so
+ check that there really are both moderators and subscribers.
+ These are added with ezmlm-sub(1). You can not just put
+ addresses into a text file!).
+
+
+ M\bMe\bes\bss\bsa\bag\bge\be m\bmo\bod\bde\ber\bra\bat\bte\bed\bd l\bli\bis\bst\bts\bs
+
+ 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 D\bDI\bIR\bR/\b/m\bms\bsg\bg-\b-
+ s\bsi\biz\bze\be 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).
+
+
+ G\bGe\ben\bne\ber\bra\bal\bl
+
+ 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), t\bth\bhe\be m\bmo\bos\bst\bt c\bco\bom\bmm\bmo\bon\bn e\ber\brr\bro\bor\br i\bis\bs
+ t\bth\bha\bat\bt t\bth\bhe\ber\bre\be a\bar\bre\be n\bno\bo s\bsu\bub\bbs\bsc\bcr\bri\bib\bbe\ber\brs\bs.\b. 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.
+
+
+ 6\b6.\b.8\b8.\b. e\bez\bzm\bml\blm\bm-\b-m\bma\bak\bke\be f\bfa\bai\bil\bls\bs:\b: u\bus\bsa\bag\bge\be:\b: e\bez\bzm\bml\blm\bm-\b-m\bma\bak\bke\be .\b..\b..\b.
+
+ 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'' or ``-+'' switch.
+ Other command line arguments can be omitted only when editing lists
+ created or previously edited with ezmlm-make from ezmlm-idx>=0.23.
+
+ Some special situations use ezmlm-make(1) as a general script
+ processor, e.g. the setting up of sublists with ezmlmsubrc(5) and of
+ a global interface with ezmlmglrc(5). Here, there is no ``memory'' so
+ all arguments have to be specified, even when using the ``-e'' or
+ ``-+'' switches.
+
+
+ 6\b6.\b.9\b9.\b. e\bez\bzm\bml\blm\bm-\b-m\bma\bak\bke\be f\bfa\bai\bil\bls\bs:\b: U\bUn\bna\bab\bbl\ble\be t\bto\bo c\bcr\bre\bea\bat\bte\be .\b..\b..\b.
+
+ This error occurs when ezmlm-make is used to set up a list, and it
+ tries to create a directory or a .\b.q\bqm\bma\bai\bil\bl-\b-l\bli\bis\bst\bt 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: _\bN_\bO_\bT_\bE_\b: _\bD_\bO _\bN_\bO_\bT _\bU_\bS_\bE _\bT_\bH_\bE_\bS_\bE
+ _\bC_\bO_\bM_\bM_\bA_\bN_\bD_\bS _\bW_\bI_\bT_\bH_\bO_\bU_\bT _\bU_\bN_\bD_\bE_\bR_\bS_\bT_\bA_\bN_\bD_\bI_\bN_\bG _\bT_\bH_\bE_\bM_\b. 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 D\bDI\bIR\bR/\b/t\bte\bex\bxt\bt/\b/), make backup
+ copies first, run ezmlm-make, then copy the backups to D\bDI\bIR\bR/\b/t\bte\bex\bxt\bt/\b/. Of
+ course, it is usually easier to create a custom .\b.e\bez\bzm\bml\blm\bmr\brc\bc, 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. With this, you need to re-specify all desired
+ switches. If instead you use ``-+'' you need to specify only switches
+ that are changed/new. NOTE: any customization that you've made to
+ program files like D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br will be overwritten. For instance, if
+ you manually added checks to D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br or added a pointer to a custom
+ moderator database in e.g. D\bDI\bIR\bR/\b/m\bmo\bod\bds\bsu\bub\bb these changes will be lost. To
+ retain such changes (especially ones that are common for several of
+ your lists), place them in a local ~\b~/\b/.\b.e\bez\bzm\bml\blm\bmr\brc\bc file instead. You can
+ either make such changes the default for your lists, or you can
+ configure ~\b~/\b/.\b.e\bez\bzm\bml\blm\bmr\brc\bc so that they are added only if a specific ezmlm-
+ make switch is used. (see ``Customizing ezmlm-make operation'').
+
+
+ 6\b6.\b.1\b10\b0.\b. e\bez\bzm\bml\blm\bm-\b-m\bma\bak\bke\be f\bfa\bai\bil\bls\bs:\b: .\b..\b..\b. e\bez\bzm\bml\blm\bmr\brc\bc d\bdo\boe\bes\bs n\bno\bot\bt e\bex\bxi\bis\bst\bt
+
+ There is no readable ezmlmrc(5) file in /\b/e\bet\btc\bc/\b/e\bez\bzm\bml\blm\bm nor in the ezmlm
+ binary directory. If you have .\b.e\bez\bzm\bml\blm\bmr\brc\bc in ``dotdir'' (see
+ ``Terminology: dotdir'') use the ezmlm-make(1) ``-c'' switch (see
+ ``Customizing ezmlm-make operation''). _\bN_\bo_\bt_\be_\b: The default location for
+ a global edited e\bez\bzm\bml\blm\bmr\brc\bc file is /\b/e\bet\btc\bc/\b/e\bez\bzm\bml\blm\bm/\b/e\bez\bzm\bml\blm\bmr\brc\bc as of ezmlm-
+ idx-0.40.
+
+
+ 6\b6.\b.1\b11\b1.\b. I\bIn\bnd\bde\bex\bx/\b/g\bge\bet\bt/\b/t\bth\bhr\bre\bea\bad\bd r\bre\beq\bqu\bue\bes\bst\bts\bs f\bfa\bai\bil\bl q\bqu\bui\bie\bet\btl\bly\by o\bor\br w\bwi\bit\bth\bh e\ber\brr\bro\bor\brs\bs f\bfr\bro\bom\bm
+ e\bez\bzm\bml\blm\bm-\b-m\bma\ban\bna\bag\bge\be.\b.
+
+ Make sure this is an indexed list and has an ``ezmlm-get'' line first
+ in D\bDI\bIR\bR/\b/m\bma\ban\bna\bag\bge\ber\br. 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.
+
+
+ 6\b6.\b.1\b12\b2.\b. D\bDi\big\bge\bes\bst\bt t\btr\bri\big\bgg\bge\ber\bri\bin\bng\bg r\bre\beq\bqu\bue\bes\bst\bts\bs f\bfa\bai\bil\bl.\b.
+
+ (Digest triggering by mail is a relic from older versions. Use the
+ standard setup with ezmlm-tstdig(1) as by ezmlm-make(1) ``-d'', or run
+ ezmlm-get(1) directly from the command line via crond(8).)
+
+ 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, for what isn't really one.
+
+
+ 6\b6.\b.1\b13\b3.\b. R\bRe\bem\bmo\bot\bte\be a\bad\bdm\bmi\bin\bni\bis\bst\btr\bra\bat\bti\bio\bon\bn (\b(u\bun\bn)\b)s\bsu\bub\bbs\bsc\bcr\bri\bib\bbe\be c\bco\bon\bnf\bfi\bir\brm\bm r\bre\beq\bqu\bue\bes\bst\bts\bs g\bgo\bo t\bto\bo t\bth\bhe\be
+ u\bus\bse\ber\br,\b, n\bno\bot\bt t\bth\bhe\be m\bmo\bod\bde\ber\bra\bat\bto\bor\br.\b.
+
+ Either the list is not set up for remote administration (i.e.
+ D\bDI\bIR\bR/\b/r\bre\bem\bmo\bot\bte\be 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
+ D\bDI\bIR\bR/\b/r\bre\bem\bmo\bot\bte\be. If you are using a non-default moderator db location, make
+ sure that the moddir name is in D\bDI\bIR\bR/\b/r\bre\bem\bmo\bot\bte\be (for remote admin only) or
+ D\bDI\bIR\bR/\b/m\bmo\bod\bds\bsu\bub\bb (if there is subscription moderation as well). In both
+ cases, the contents will be ignored unless they start with a ``/''.
+
+
+ 6\b6.\b.1\b14\b4.\b. (\b(U\bUn\bn)\b)s\bsu\bub\bbs\bsc\bcr\bri\bib\bbe\ber\brs\bs d\bdo\boe\bes\bs n\bno\bot\bt r\bre\bec\bce\bei\biv\bve\be a\ba (\b(u\bun\bn)\b)s\bsu\bub\bbs\bsc\bcr\bri\bib\bbe\be a\bac\bck\bkn\bno\bow\bwl\ble\bed\bdg\bge\be-\b-
+ m\bme\ben\bnt\bt
+
+ 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, 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).
+
+
+ 6\b6.\b.1\b15\b5.\b. M\bMe\bes\bss\bsa\bag\bge\bes\bs p\bpo\bos\bst\bte\bed\bd t\bto\bo a\ba m\bmo\bod\bde\ber\bra\bat\bte\bed\bd l\bli\bis\bst\bt a\bar\bre\be s\bse\ben\bnt\bt o\bou\but\bt w\bwi\bit\bth\bho\bou\but\bt m\bmo\bod\bde\ber\br-\b-
+ a\bat\bti\bio\bon\bn.\b.
+
+ The list is not set up as a moderated list. Check D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br. 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 D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br.
+ If there is, the list is not moderated. Also, D\bDI\bIR\bR/\b/m\bmo\bod\bdp\bpo\bos\bst\bt 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 D\bDI\bIR\bR/\b/m\bmo\bod\bdp\bpo\bos\bst\bt, but may be confusing if the user is unaware of
+ this ezmlm-store(1) feature.
+
+
+ 6\b6.\b.1\b16\b6.\b. M\bMe\bes\bss\bsa\bag\bge\bes\bs p\bpo\bos\bst\bte\bed\bd t\bto\bo a\ba m\bmo\bod\bde\ber\bra\bat\bte\bed\bd l\bli\bis\bst\bt d\bdo\bo n\bno\bot\bt r\bre\bes\bsu\bul\blt\bt i\bin\bn m\bmo\bod\bde\ber\bra\bat\bti\bio\bon\bn
+ r\bre\beq\bqu\bue\bes\bst\bts\bs.\b.
+
+
+ +\bo Check that ~\b~/\b/.\b.q\bqm\bma\bai\bil\bl-\b-l\bli\bis\bst\bt is a link to D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br.
+
+ +\bo Check that D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br contains ezmlm-store(1) and not ezmlm-
+ send(1). If this is not the case, the list is not message
+ moderated.
+
+ +\bo Check for the presence of D\bDI\bIR\bR/\b/m\bmo\bod\bdp\bpo\bos\bst\bt. If this file is missing, the
+ list is not moderated, even if D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br is set up with ezmlm-
+ store(1).
+
+ +\bo 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.
+
+ +\bo Check to see that there are indeed moderators:
+
+
+
+ % ezmlm-list moddir
+
+
+
+
+ where ``moddir'' is the contents of D\bDI\bIR\bR/\b/m\bmo\bod\bdp\bpo\bos\bst\bt if they start with a
+ ``/'', otherwise those of D\bDI\bIR\bR/\b/r\bre\bem\bmo\bot\bte\be (same ``/'' requirement), and
+ D\bDI\bIR\bR/\b/m\bmo\bod\bd/\b/ by default.
+
+
+ +\bo 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
+
+
+
+
+
+ 6\b6.\b.1\b17\b7.\b. M\bMo\bod\bde\ber\bra\bat\bti\bio\bon\bn r\bre\beq\bqu\bue\bes\bst\bt r\bre\bep\bpl\bli\bie\bes\bs d\bdo\bo n\bno\bot\bt r\bre\bes\bsu\bul\blt\bt i\bin\bn t\bth\bhe\be a\bap\bpp\bpr\bro\bop\bpr\bri\bia\bat\bte\be
+ a\bac\bct\bti\bio\bon\bn.\b.
+
+
+ +\bo Check that the address in the moderation request is correct.
+
+ +\bo Check that the ~\b~/\b/.\b.q\bqm\bma\bai\bil\bl-\b-l\bli\bis\bst\bt-\b-a\bac\bcc\bce\bep\bpt\bt-\b-d\bde\bef\bfa\bau\bul\blt\bt and ~\b~.\b./\b/q\bqm\bma\bai\bil\bl-\b-l\bli\bis\bst\bt-\b-
+ r\bre\bej\bje\bec\bct\bt-\b-d\bde\bef\bfa\bau\bul\blt\bt links exists and point to D\bDI\bIR\bR/\b/m\bmo\bod\bde\ber\bra\bat\bto\bor\br.
+
+ +\bo Check that D\bDI\bIR\bR/\b/m\bmo\bod\bde\ber\bra\bat\bto\bor\br invokes ezmlm-moderate(1), and that there
+ is a copy of ezmlm-send(1) in the ezmlm binary directory.
+
+ +\bo Check the qmail log to see that the replies were delivered to this
+ address.
+
+ +\bo Check directory ownerships. For lists under alias:
+
+
+
+ % chown -R alias DIR
+
+
+
+
+ _\bN_\bO_\bT_\bE_\b: 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 _\ba_\bl_\bi_\ba_\bs, 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.
+
+ +\bo Check the qmail logs: After the delivery of the moderation request,
+ ezmlm-send(1) should run to send messages to all the list
+ subscribers.
+
+ +\bo 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.
+
+
+ 6\b6.\b.1\b18\b8.\b. M\bMo\bod\bde\ber\bra\bat\bto\bor\br c\bco\bom\bmm\bme\ben\bnt\bts\bs w\bwi\bit\bth\bh m\bmo\bod\bde\ber\bra\bat\bti\bio\bon\bn r\bre\beq\bqu\bue\bes\bst\bt r\bre\bep\bpl\bli\bie\bes\bs a\bar\bre\be n\bno\bot\bt
+ a\bad\bdd\bde\bed\bd t\bto\bo t\bth\bhe\be p\bpo\bos\bst\bt/\b/s\bse\ben\bnt\bt t\bto\bo t\bth\bhe\be p\bpo\bos\bst\bte\ber\br.\b.
+
+ 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 a\bac\bcc\bce\bep\bpt\bte\bed\bd
+ 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. If you want to edit posts before sending them to the
+ list, set up a moderated list with you as the only moderator. Into
+ D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br before the ezmlm-store(1) line, put a condredirect(1) line
+ that redirects all messages with a SENDER other than you to your
+ address. You can edit the contents ands repost, the message will pass
+ condredirect(1), and hit ezmlm-store(1). You will be asked to confirm
+ (needed to assure that nobody else can post directly) and when you do,
+ the messages is posted.
+
+ 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>%%%
+
+
+
+
+ 6\b6.\b.1\b19\b9.\b. S\bSo\bom\bme\be h\bhe\bea\bad\bde\ber\brs\bs a\bar\bre\be m\bmi\bis\bss\bsi\bin\bng\bg f\bfr\bro\bom\bm m\bme\bes\bss\bsa\bag\bge\bes\bs i\bin\bn t\bth\bhe\be d\bdi\big\bge\bes\bst\bt.\b.
+
+ By default, only a subset of message headers are sent out in any
+ digest and archive retrieval requests. First, headers in
+ D\bDI\bIR\bR/\b/h\bhe\bea\bad\bde\ber\brr\bre\bem\bmo\bov\bve\be 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.
+
+
+ 6\b6.\b.2\b20\b0.\b. S\bSo\bom\bme\be R\bRe\bec\bce\bei\biv\bve\bed\bd:\b: h\bhe\bea\bad\bde\ber\brs\bs a\bar\bre\be m\bmi\bis\bss\bsi\bin\bng\bg f\bfr\bro\bom\bm m\bme\bes\bss\bsa\bag\bge\bes\bs.\b.
+
+ ezmlm-idx>=0.313 removes all but the latest ``Received:'' header from
+ messages sent to the list. This is done since messages, especially
+ sent via sublists, may have so many ``Received:'' headers that MTAs
+ with primitive ``loop detection'' erroneously reject them. The
+ subscriber can subscribe, since those messages have fewer such
+ headers, and will receive warning and probe messages, but never see
+ any posts.
+
+ To see all headers of a message for diagnostic purposes, mail
+ mainlist-getv.num@mainhost, where ``num'' is the message number. All
+ ``Received:'' headers are stored in the archive copy of the message.
+
+ To disable ``Received:'' header pruning, use the ezmlm-send(1) ``-r''
+ switch.
+
+
+ 6\b6.\b.2\b21\b1.\b. M\bMy\by M\bMu\but\btt\bt u\bus\bse\ber\brs\bs c\bca\ban\bnn\bno\bot\bt t\bth\bhr\bre\bea\bad\bd t\bth\bhe\bei\bir\br d\bdi\big\bge\bes\bst\bt m\bme\bes\bss\bsa\bag\bge\bes\bs.\b.
+
+ The digest by default removed non-essential headers like ``In-Reply-
+ To:'' from messages. Modern MUAs, like _\bM_\bu_\bt_\bt 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, often by 25% or more.
+
+
+ 6\b6.\b.2\b22\b2.\b. P\bPo\bos\bst\bts\bs f\bfa\bai\bil\bl:\b: M\bMe\bes\bss\bsa\bag\bge\be a\bal\blr\bre\bea\bad\bdy\by h\bha\bas\bs M\bMa\bai\bil\bli\bin\bng\bg-\b-L\bLi\bis\bst\bt (\b(#\b#5\b5.\b.7\b7.\b.2\b2)\b).\b.
+
+ 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
+ D\bDI\bIR\bR/\b/s\bsu\bub\bbl\bli\bis\bst\bt. Check the ownership of D\bDI\bIR\bR/\b/s\bsu\bub\bbl\bli\bis\bst\bt, 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'').
+
+
+ 6\b6.\b.2\b23\b3.\b. T\bTh\bhe\be l\bla\bas\bst\bt l\bli\bin\bne\be o\bof\bf a\ba D\bDI\bIR\bR/\b/t\bte\bex\bxt\bt/\b/ f\bfi\bil\ble\be i\bis\bs i\big\bgn\bno\bor\bre\bed\bd.\b.
+
+ Only complete lines ending with ``newline'' are copied. The last line
+ in the D\bDI\bIR\bR/\b/t\bte\bex\bxt\bt/\b/ file most likely lacks a terminal ``newline''.
+
+
+ 6\b6.\b.2\b24\b4.\b. N\bNo\bo C\bCO\bON\bNF\bFI\bIR\bRM\bM r\bre\beq\bqu\bue\bes\bst\bts\bs a\bar\bre\be s\bse\ben\bnt\bt t\bto\bo m\bmo\bod\bde\ber\bra\bat\bto\bor\brs\bs.\b.
+
+ 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 but 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 ``D\bDI\bIR\bR/\b/m\bmo\bod\bd/\b/''.
+
+ 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. The CONFIRM request went to the target address instead,
+ since as far as ezmlm is concerned, you are a regular user.
+
+
+ 6\b6.\b.2\b25\b5.\b. D\bDe\bel\bli\biv\bve\ber\bri\bie\bes\bs f\bfa\bai\bil\bl `\b``\b`t\bte\bem\bmp\bpo\bor\bra\bar\bry\by q\bqm\bma\bai\bil\bl-\b-q\bqu\bue\beu\bue\be e\ber\brr\bro\bor\br'\b''\b'
+
+ 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''). ezmlm-idx>=0.40 has more informative
+ qmail error messages.
+
+
+
+
+
+ 6\b6.\b.2\b26\b6.\b. H\bHo\bow\bw t\bto\bo d\bde\bea\bal\bl w\bwi\bit\bth\bh c\bco\bor\brr\bru\bup\bpt\bte\bed\bd s\bsu\bub\bbs\bsc\bcr\bri\bib\bbe\ber\br l\bli\bis\bst\bts\bs
+
+ 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 D\bDI\bIR\bR/\b/s\bsu\bub\bbs\bsc\bcr\bri\bib\bbe\ber\brs\bs/\b/, then:
+
+
+
+ % ezmlm-list DIR > tmp.tmp
+
+ ( edit tmp.tmp to fix any problems )
+
+ % rm -rf DIR/subscribers/*
+ % 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.
+
+
+ 6\b6.\b.2\b27\b7.\b. V\bVa\bac\bca\bat\bti\bio\bon\bn p\bpr\bro\bog\bgr\bra\bam\bm r\bre\bep\bpl\bli\bie\bes\bs a\bar\bre\be t\btr\bre\bea\bat\bte\bed\bd a\bas\bs b\bbo\bou\bun\bnc\bce\bes\bs b\bby\by e\bez\bzm\bml\blm\bm.\b.
+
+ 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 D\bDI\bIR\bR/\b/h\bhe\bea\bad\bde\ber\bra\bad\bdd\bd. For older lists, use ``ezmlm-make -+'' or
+ ``ezmlm-make -e'' to update them, or just add a ``Precedence: bulk''
+ line to D\bDI\bIR\bR/\b/h\bhe\bea\bad\bde\ber\bra\bad\bdd\bd.
+
+
+ 6\b6.\b.2\b28\b8.\b. D\bDi\big\bge\bes\bst\bts\bs d\bdo\bo n\bno\bot\bt c\bco\bom\bme\be a\bat\bt r\bre\beg\bgu\bul\bla\bar\br h\bho\bou\bur\brs\bs.\b.
+
+ 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 crond(8) and crontab(1)
+ to daily run:
+
+
+ % ezmlm-get DIR
+
+
+
+
+
+ 6\b6.\b.2\b29\b9.\b. P\bPr\bre\bev\bve\ben\bnt\bti\bin\bng\bg l\blo\boo\bop\bps\bs f\bfr\bro\bom\bm m\bmi\bis\bsc\bco\bon\bnf\bfi\big\bgu\bur\bre\bed\bd s\bsu\bub\bbs\bsc\bcr\bri\bib\bbe\ber\br a\bad\bdd\bdr\bre\bes\bss\bse\bes\bs.\b.
+
+ 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 send-out. To block
+ such mail at the list, include the ezmlm-make(1) ``-k'' (kill) switch
+ and add the offending address to D\bDI\bIR\bR/\b/d\bde\ben\bny\by/\b/ with
+
+
+ % ezmlm-sub DIR/deny 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 D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br or D\bDI\bIR\bR/\b/m\bma\ban\bna\bag\bge\ber\br. 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.
+
+
+ 6\b6.\b.3\b30\b0.\b. A\bA u\bus\bse\ber\br c\bca\ban\bn s\bsu\bub\bbs\bsc\bcr\bri\bib\bbe\be a\ban\bnd\bd r\bre\bec\bce\bei\biv\bve\bes\bs w\bwa\bar\brn\bni\bin\bng\bg a\ban\bnd\bd p\bpr\bro\bob\bbe\be m\bme\bes\bss\bsa\bag\bge\bes\bs,\b,
+ b\bbu\but\bt n\bno\bo m\bme\bes\bss\bsa\bag\bge\bes\bs f\bfr\bro\bom\bm t\bth\bhe\be l\bli\bis\bst\bt.\b.
+
+ 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 _\b-_\bg_\be_\bt_\bv 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.
+
+
+ 7\b7.\b. C\bCu\bus\bst\bto\bom\bmi\biz\bzi\bin\bng\bg e\bez\bzm\bml\blm\bm-\b-m\bma\bak\bke\be o\bop\bpe\ber\bra\bat\bti\bio\bon\bn v\bvi\bia\ba e\bez\bzm\bml\blm\bmr\brc\bc
+
+
+ 7\b7.\b.1\b1.\b. U\bUs\bsi\bin\bng\bg e\bez\bzm\bml\blm\bm-\b-m\bma\bak\bke\be t\bto\bo e\bed\bdi\bit\bt e\bex\bxi\bis\bst\bti\bin\bng\bg l\bli\bis\bst\bts\bs.\b.
+
+ 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 (D\bDI\bIR\bR/\b/n\bnu\bum\bm), digest counters (D\bDI\bIR\bR/\b/d\bdi\big\bgn\bnu\bum\bm
+ and D\bDI\bIR\bR/\b/d\bdi\big\bgi\bis\bss\bsu\bue\be), the key (D\bDI\bIR\bR/\b/k\bke\bey\by) 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 D\bDI\bIR\bR/\b/c\bco\bon\bnf\bfi\big\bg) the
+ arguments and the switches. All you have to do is to use the ezmlm-
+ make(1) ``-+'' switch and specify options you wish to change, or use
+ the ``-e'' switch and specify all non-default options you'd like to
+ use.
+
+ _\bN_\bO_\bT_\bE_\b: ezmlm-make(1) ``-e'' and ``-+'' will OVERWRITE any manual
+ customizations you have made to the program files, but not text files
+ and D\bDI\bIR\bR/\b/h\bhe\bea\bad\bde\ber\bra\bad\bdd\bd, D\bDI\bIR\bR/\b/h\bhe\bea\bad\bde\ber\brr\bre\bem\bmo\bov\bve\be, etc. To reset all such files
+ (such as when changing list name), use ``-ee'' or ``-++''.
+
+ To make general customizations, please change e\bez\bzm\bml\blm\bmr\brc\bc(\b(5\b5)\b) (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'').
+
+
+ 7\b7.\b.2\b2.\b. W\bWh\bha\bat\bt i\bis\bs e\bez\bzm\bml\blm\bmr\brc\bc?\b?
+
+ ezmlm-make(1) has a number of default switches that through e\bez\bzm\bml\blm\bmr\brc\bc(\b(5\b5)\b)
+ 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(5) or .ezmlmrc. A default
+ ezmlmrc(5) is installed in the ezmlm binary directory. The system
+ administrator can install a system-wide default e\bez\bzm\bml\blm\bmr\brc\bc(\b(5\b5)\b) file in
+ /\b/e\bet\btc\bc/\b/e\bez\bzm\bml\blm\bmr\brc\bc (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 .\b.e\bez\bzm\bml\blm\bmr\brc\bc in the ``dotdir'', i.e. the
+ directory in which the .\b.q\bqm\bma\bai\bil\bl-\b-l\bli\bis\bst\bt 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).
+
+ e\bez\bzm\bml\blm\bmr\brc\bc(\b(5\b5)\b) controls everything except creation of the list directory
+ itself and the key used for cookie generation. The syntax of
+ e\bez\bzm\bml\blm\bmr\brc\bc(\b(5\b5)\b) is documented in ezmlm-make(1), the ezmlmrc(5) man page,
+ and in the ezmlmrc(5) 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.
+
+
+ 7\b7.\b.3\b3.\b. C\bCh\bha\ban\bng\bgi\bin\bng\bg d\bde\bef\bfa\bau\bul\blt\bts\bs f\bfo\bor\br D\bDI\bIR\bR/\b/t\bte\bex\bxt\bt/\b/ f\bfi\bil\ble\bes\bs.\b.
+
+ Copy the ezmlmrc(5) file from the ezmlm bin directory to .\b.e\bez\bzm\bml\blm\bmr\brc\bc in
+ your .\b.q\bqm\bma\bai\bil\bl file base directory (usually your home directory):
+
+
+ % cp /usr/local/bin/ezmlm/ezmlmrc ~/.ezmlmrc
+
+
+
+
+ The base e\bez\bzm\bml\blm\bmr\brc\bc(\b(5\b5)\b) file lives in the ezmlm binary directory, which
+ may differ from ``/\b/u\bus\bsr\br/\b/l\blo\boc\bca\bal\bl/\b/b\bbi\bin\bn/\b/e\bez\bzm\bml\blm\bm/\b/e\bez\bzm\bml\blm\bmr\brc\bc'' if you do not have a
+ default setup. If your system administrator has placed a ezmlmrc(5)
+ file into the /\b/e\bet\btc\bc directory, start with that one instead, as it is
+ likely to already contain some useful local customization and
+ comments.
+
+ Now edit ~\b~/\b/.\b.e\bez\bzm\bml\blm\bmr\brc\bc. 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 D\bDI\bIR\bR/\b/t\bte\bex\bxt\bt/\b/f\bfi\bil\ble\be if and
+ only if the ezmlm-make(1) ``-rms'' switches are all used. For more
+ info, see documentation in e\bez\bzm\bml\blm\bmr\brc\bc(\b(5\b5)\b) and the ezmlm-make(1) man page.
+ To invoke a custom .\b.e\bez\bzm\bml\blm\bmr\brc\bc file, use the ezmlm-make(1) ``-c''
+ (custom) switch.
+
+
+ 7\b7.\b.4\b4.\b. C\bCh\bha\ban\bng\bgi\bin\bng\bg d\bde\bef\bfa\bau\bul\blt\bt m\bmo\bod\bde\ber\bra\bat\bto\bor\br d\bdi\bir\bre\bec\bct\bto\bor\bri\bie\bes\bs.\b.
+
+ See above. Edit the .\b.e\bez\bzm\bml\blm\bmr\brc\bc 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: D\bDI\bIR\bR/\b/m\bmo\bod\bd/\b/ is still required as
+ the base directory for the message moderation queue.
+ 7\b7.\b.5\b5.\b. A\bAd\bda\bap\bpt\bti\bin\bng\bg e\bez\bzm\bml\blm\bm-\b-m\bma\bak\bke\be f\bfo\bor\br v\bvi\bir\brt\btu\bua\bal\bl d\bdo\bom\bma\bai\bin\bns\bs.\b.
+
+ This is not necessary if you use qmail>=1.02 and ezmlm-idx>=0.32.
+
+ The problem with virtual domains is that ezmlm-make(1) by default puts
+ the list name in D\bDI\bIR\bR/\b/i\bin\bnl\blo\boc\bca\bal\bl. 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 .\b.e\bez\bzm\bml\blm\bmr\brc\bc file in ~\b~v\bvi\bir\brt\bt/\b/. In
+ the ``</inlocal/>'' section of this file, enter ``virt-<#L#>'' instead
+ of ``<#L#>''. Now, all lists created under ~\b~v\bvi\bir\brt\bt 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 L\bLI\bIS\bST\bT/\b/i\bin\bnl\blo\boc\bca\bal\bl 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 (_\bS_\bi_\bc_\b!)). For more info,
+ see ezmlm-make(1) and comments in e\bez\bzm\bml\blm\bmr\brc\bc.
+
+
+ 7\b7.\b.6\b6.\b. S\bSe\bet\btt\bti\bin\bng\bg u\bup\bp e\bez\bzm\bml\blm\bm-\b-m\bma\bak\bke\be f\bfo\bor\br s\bsp\bpe\bec\bci\bia\bal\bl s\bsi\bit\btu\bua\bat\bti\bio\bon\bns\bs.\b.
+
+ 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 .\b.e\bez\bzm\bml\blm\bmr\brc\bc 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 e\bez\bzm\bml\blm\bmr\brc\bc(\b(5\b5)\b). Many
+ switches, have special meanings via e\bez\bzm\bml\blm\bmr\brc\bc(\b(5\b5)\b) and are documented in
+ the man page. Any other switches can be used for customization (_\bN_\bO_\bT_\bE_\b:
+ _\bw_\be _\bm_\ba_\by _\bu_\bs_\be _\bs_\bw_\bi_\bt_\bc_\bh_\be_\bs _\bo_\bt_\bh_\be_\br _\bt_\bh_\ba_\bn _\b`_\b`_\b-_\bx_\by_\bz_\b'_\b' _\bf_\bo_\br _\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\bu_\br_\bp_\bo_\bs_\be_\bs _\bi_\bn
+ _\bf_\bu_\bt_\bu_\br_\be _\bv_\be_\br_\bs_\bi_\bo_\bn_\bs_\b.) The ``-xyz'' switches will always be available for
+ your use, with the ``-x'' switch being configured for some
+ demo/special features in the distributed e\bez\bzm\bml\blm\bmr\brc\bc(\b(5\b5)\b). 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 e\bez\bzm\bml\blm\bmr\brc\bc(\b(5\b5)\b) file. The switches ``-aip'' are set by default to
+ be backwards compatible with ezmlm-0.53. Other switches are ``off'' by
+ default.
+
+ Switches ``-a-z'' and ``-A-Z'' take no arguments. Switches ``-0'' and
+ and ``-3-9'' take arguments. When the ezmlm-make(1) ``-+'' switch is
+ used, the current settings for all these switches are read from the
+ list's D\bDI\bIR\bR/\b/c\bco\bon\bnf\bfi\big\bg (if available).
+
+
+ 8\b8.\b. R\bRe\bes\bst\btr\bri\bic\bct\bti\bin\bng\bg m\bme\bes\bss\bsa\bag\bge\be p\bpo\bos\bst\bti\bin\bng\bg t\bto\bo t\bth\bhe\be l\bli\bis\bst\bt.\b.
+
+
+
+ 8\b8.\b.1\b1.\b. R\bRe\beq\bqu\bui\bir\bri\bin\bng\bg t\bth\bhe\be l\bli\bis\bst\bt a\bad\bdd\bdr\bre\bes\bss\bs i\bin\bn T\bTo\bo:\b:/\b/C\bCc\bc:\b: h\bhe\bea\bad\bde\ber\brs\bs.\b.
+
+ SPAM or junk mail 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'' argument 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.
+
+
+ 8\b8.\b.2\b2.\b. R\bRe\bej\bje\bec\bct\bti\bin\bng\bg m\bme\bes\bss\bsa\bag\bge\bes\bs s\bse\ben\bnt\bt f\bfr\bro\bom\bm o\bot\bth\bhe\ber\br m\bma\bai\bil\bli\bin\bng\bg l\bli\bis\bst\bts\bs.\b.
+
+ 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
+ D\bDI\bIR\bR/\b/h\bhe\bea\bad\bde\ber\brr\bre\bej\bje\bec\bct\bt. 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 D\bDI\bIR\bR on
+ the ezmlm-reject(1) line in D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br. Naturally, you can make this
+ the default by editing ezmlmrc(5) (See ``Customizing ezmlm-make
+ operation'').
+
+
+ 8\b8.\b.3\b3.\b. R\bRe\bes\bst\btr\bri\bic\bct\bti\bin\bng\bg p\bpo\bos\bst\bts\bs b\bba\bas\bse\bed\bd o\bon\bn t\bth\bhe\be S\bSu\bub\bbj\bje\bec\bct\bt l\bli\bin\bne\be.\b.
+
+ 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. You can also into D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br before the ezmlm-
+ send(1) line add:
+
+
+ | grep -i 'subject:' | grep -if DIR/bad_words >/dev/null && \
+ {echo "bad words found"; exit 100; }
+
+
+
+
+ to reject messages that have a line matching ``Subject:'' followed by
+ any bad word listed in D\bDI\bIR\bR/\b/b\bba\bad\bd_\b_w\bwo\bor\brd\bds\bs.
+
+
+ 8\b8.\b.4\b4.\b. R\bRe\bes\bst\btr\bri\bic\bct\bti\bin\bng\bg t\bth\bhe\be s\bsi\biz\bze\be o\bof\bf p\bpo\bos\bst\bts\bs.\b.
+
+ If the ``DIR'' argument is specified on the ezmlm-reject(1) line in
+ D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br and D\bDI\bIR\bR/\b/m\bms\bsg\bgs\bsi\biz\bze\be 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 D\bDI\bIR\bR/\b/m\bms\bsg\bgs\bsi\biz\bze\be 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 e\bez\bzm\bml\blm\bmr\brc\bc(\b(5\b5)\b):
+
+
+ </msgsize/>
+ max:min
+
+
+
+
+ The ezmlm-make(1) ``-x'' switch adds this with 40000:2.
+
+
+ 8\b8.\b.5\b5.\b. R\bRe\bes\bst\btr\bri\bic\bct\bti\bin\bng\bg p\bpo\bos\bst\bts\bs b\bba\bas\bse\bed\bd o\bon\bn M\bMI\bIM\bME\bE c\bco\bon\bnt\bte\ben\bnt\bt-\b-t\bty\byp\bpe\be.\b.
+
+ ezmlm-reject(1) will look for D\bDI\bIR\bR/\b/m\bms\bsg\bgs\bsi\biz\bze\be, D\bDI\bIR\bR/\b/m\bmi\bim\bme\ber\bre\bej\bje\bec\bct\bt, and
+ D\bDI\bIR\bR/\b/m\bmi\bim\bme\ber\bre\bem\bmo\bov\bve\be if the ``DIR'' argument is specified (``DIR'' can be
+ left out to conserve resources on lists that do not use these
+ features). _\bN_\bo_\bt_\be_\b: _\bT_\bh_\be _\b`_\b`_\bD_\bI_\bR_\b'_\b' _\ba_\br_\bg_\bu_\bm_\be_\bn_\bt _\bi_\bs _\ba_\bl_\bs_\bo _\br_\be_\bq_\bu_\bi_\br_\be_\bd _\bf_\bo_\br _\bt_\bh_\be _\bt_\bh_\be
+ _\bT_\bo_\b:_\b/_\bC_\bc_\b: _\bl_\bi_\bs_\bt _\ba_\bd_\bd_\br_\be_\bs_\bs _\br_\be_\bs_\bt_\br_\bi_\bc_\bt_\bi_\bo_\bn _\b(_\bs_\be_\be _\b`_\b`_\bR_\be_\bq_\bu_\bi_\br_\bi_\bn_\bg _\bt_\bh_\be _\bl_\bi_\bs_\bt _\ba_\bd_\bd_\br_\be_\bs_\bs _\bi_\bn
+ _\bT_\bo_\b:_\b/_\bC_\bc_\b: _\bh_\be_\ba_\bd_\be_\br_\bs_\b'_\b'_\b)_\b. If the message contains MIME parts that are of a
+ content-type listed in D\bDI\bIR\bR/\b/m\bmi\bim\bme\ber\bre\bej\bje\bec\bct\bt they are rejected. If the
+ message is a simple MIME message of a content-type listed in either
+ D\bDI\bIR\bR/\b/m\bmi\bim\bme\ber\bre\bej\bje\bec\bct\bt or D\bDI\bIR\bR/\b/m\bmi\bim\bme\ber\bre\bem\bmo\bov\bve\be it is also rejected.
+
+ There is currently no ezmlm-make(1) switch for D\bDI\bIR\bR/\b/m\bmi\bim\bme\ber\bre\bej\bje\bec\bct\bt, but it
+ can easily be configured by editing e\bez\bzm\bml\blm\bmr\brc\bc(\b(5\b5)\b). The ezmlm-make ``-x''
+ switch configures D\bDI\bIR\bR/\b/m\bmi\bim\bme\ber\bre\bem\bmo\bov\bve\be (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.
+
+
+ 8\b8.\b.6\b6.\b. R\bRe\bes\bst\btr\bri\bic\bct\bti\bin\bng\bg p\bpo\bos\bst\bts\bs t\bto\bo l\bli\bis\bst\bt s\bsu\bub\bbs\bsc\bcr\bri\bib\bbe\ber\brs\bs.\b.
+
+ Use message moderation. As an alternative, implement a check against
+ SENDER by using ezmlm-issubn(1). The latter is easily defeated by
+ faking SENDER. Also, it prevents posts from legitimate subscribers
+ that are subscribed under a different address than the one they send
+ from. Nevertheless, it may be useful in some situations. Add:
+
+
+
+ |/usr/local/bin/ezmlm/ezmlm-issubn 'DIR' 'DIR/digest' 'DIR/allow' ||
+ { echo "Sorry, you are not allowed to post to this list.";
+ exit 100; }
+
+
+
+
+ _\bA_\bL_\bL _\bO_\bN _\bO_\bN_\bE _\bL_\bI_\bN_\bE to D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br 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(1) path accordingly. If you would
+ like denied posts to be dropped silently rather than bounced, change
+ the exit code to 99.
+
+ 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
+ D\bDI\bIR\bR/\b/d\bdi\big\bge\bes\bst\bt/\b/ from the ezmlm-issubn command line. To allow posts from an
+ address that is not a subscriber, simply add it to the addresses in
+ D\bDI\bIR\bR/\b/a\bal\bll\blo\bow\bw/\b/:
+
+
+ % ezmlm-sub DIR/allow address@host
+
+
+
+
+ The ``allow'' 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 ``allow'' 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)''.
+
+
+
+ 8\b8.\b.7\b7.\b. R\bRe\bes\bst\btr\bri\bic\bct\bti\bin\bng\bg p\bpo\bos\bst\bts\bs t\bto\bo a\ban\bn a\bar\brb\bbi\bit\btr\bra\bar\bry\by s\bse\bet\bt o\bof\bf E\bE-\b-m\bma\bai\bil\bl a\bad\bdd\bdr\bre\bes\bss\bse\bes\bs
+ (\b(h\bhi\big\bgh\bhe\ber\br s\bse\bec\bcu\bur\bri\bit\bty\by o\bop\bpt\bti\bio\bon\bn)\b).\b.
+
+ 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 is The best choice depends on your particular needs in
+ the trade-off between security and convenience.
+
+ ``ezmlm-make -om'' will set up such a moderated list with ``ezmlm-
+ store -P''. This is the most useful setup for an announcement list.
+
+
+ Setting a list up in this way with only the owner's address gives you
+ a pretty safe owner-only list.
+
+
+ 8\b8.\b.8\b8.\b. C\bCo\bom\bmp\bpl\ble\bet\bte\bel\bly\by r\bre\bes\bst\btr\bri\bic\bct\bti\bin\bng\bg p\bpo\bos\bst\bts\bs.\b.
+
+ To completely prevent posting (for instance a message-of-the-day
+ list), set up a normal list, and just remove ~\b~/\b/.\b.q\bqm\bma\bai\bil\bl-\b-l\bli\bis\bst\bt and
+ D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br altogether. Make posts from the shell, or from shell
+ scripts or crond, by simply piping a (complete) message to ezmlm-
+ send(1):
+
+
+
+ % /usr/local/bin/ezmlm/ezmlm-send DIR < message
+
+
+
+
+ _\bN_\bO_\bT_\bE: This can be done by any user with write access to files within
+ the list directory, 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 D\bDI\bIR\bR/\b/s\bsu\bub\bbs\bsc\bcr\bri\bib\bbe\ber\brs\bs/\b/ and other address lists.
+
+
+ 8\b8.\b.9\b9.\b. A\bA g\bge\ben\bne\ber\bra\bal\bl s\bso\bol\blu\but\bti\bio\bon\bn t\bto\bo r\bre\bes\bst\btr\bri\bic\bct\bti\bin\bng\bg p\bpo\bos\bst\bts\bs b\bba\bas\bse\bed\bd o\bon\bn S\bSE\bEN\bND\bDE\bER\bR.\b.
+
+ 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 D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br in place of the
+ ezmlm-send(1) line. To the ezmlm-gate(1) command line add the list
+ directory twice, then a digest directory D\bDI\bIR\bR/\b/d\bdi\big\bge\bes\bst\bt/\b/ (if it exists),
+ then D\bDI\bIR\bR/\b/a\bal\bll\blo\bow\bw/\b/. Create D\bDI\bIR\bR/\b/m\bmo\bod\bdp\bpo\bos\bst\bt. 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 D\bDI\bIR\bR/\b/a\bal\bll\blo\bow\bw/\b/, 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 D\bDI\bIR\bR/\b/a\bal\bll\blo\bow\bw/\b/. 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 D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br and D\bDI\bIR\bR/\b/m\bmo\bod\bde\ber\bra\bat\bto\bor\br.
+
+ 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
+
+
+
+
+ If you omit the ``-m'' switch, the setup will reject posts from non-
+ subscribers that are not in the ``allow'' 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.
+
+
+ 9\b9.\b. C\bCu\bus\bst\bto\bom\bmi\biz\bzi\bin\bng\bg o\bou\but\btg\bgo\boi\bin\bng\bg m\bme\bes\bss\bsa\bag\bge\bes\bs.\b.
+
+
+ 9\b9.\b.1\b1.\b. A\bAd\bdd\bdi\bin\bng\bg a\ba t\btr\bra\bai\bil\ble\ber\br t\bto\bo o\bou\but\btg\bgo\boi\bin\bng\bg m\bme\bes\bss\bsa\bag\bge\bes\bs.\b.
+
+ Put the text in D\bDI\bIR\bR/\b/t\bte\bex\bxt\bt/\b/t\btr\bra\bai\bil\ble\ber\br. The text is NOT copied to the
+ archived version of the message. This works also for sublists. Tags
+ ``<#h#>'', ``<#l#>'', and ``<#n#>'' are replaced by the list host,
+ local name, and current message number, respectively.
+
+
+ 9\b9.\b.2\b2.\b. A\bAd\bdd\bdi\bin\bng\bg a\ba s\bsu\bub\bbj\bje\bec\bct\bt p\bpr\bre\bef\bfi\bix\bx t\bto\bo o\bou\but\btg\bgo\boi\bin\bng\bg m\bme\bes\bss\bsa\bag\bge\bes\bs.\b.
+
+ Put the exact text in D\bDI\bIR\bR/\b/p\bpr\bre\bef\bfi\bix\bx. You can include the message number
+ assigned to the post in the list archive by adding the ``#'' character
+ in the text in D\bDI\bIR\bR/\b/p\bpr\bre\bef\bfi\bix\bx (example: put ``lsqb;listname-#rsqb;'' in
+ D\bDI\bIR\bR/\b/p\bpr\bre\bef\bfi\bix\bx). 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 D\bDI\bIR\bR/\b/p\bpr\bre\bef\bfi\bix\bx.
+
+ 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.
+
+
+ 9\b9.\b.3\b3.\b. A\bAd\bdd\bdi\bin\bng\bg a\ba h\bhe\bea\bad\bde\ber\br t\bto\bo o\bou\but\btg\bgo\boi\bin\bng\bg m\bme\bes\bss\bsa\bag\bge\bes\bs.\b.
+
+ Put the exact header text as a line in D\bDI\bIR\bR/\b/h\bhe\bea\bad\bde\ber\bra\bad\bdd\bd. Thus, if you'd
+ like a ``Precedence: bulk'' header added to outgoing messages, put a
+ line ``Precedence: bulk'' into D\bDI\bIR\bR/\b/h\bhe\bea\bad\bde\ber\bra\bad\bdd\bd. This particular header
+ is already added via the default ezmlmrc(5). Any modifications you
+ wish to be active for all future lists should be made via modification
+ of ezmlmrc(5) (see ``Customizing ezmlm-make operation''). As of
+ ezmlm-idx-0.32, the following tags can be used in D\bDI\bIR\bR/\b/h\bhe\bea\bad\bde\ber\bra\bad\bdd\bd, and
+ will be substituted: <#n#> for the current message number, <#l#> for
+ the local part of the list (this will be the digest list for digests),
+ <#h#> for the host part of the list name. These substitutions are done
+ at the time of message delivery, in contrast to the ``capital letter''
+ tags substituted by ezmlm-make(1) when the list is set up.
+
+
+ 9\b9.\b.4\b4.\b. A\bAd\bdd\bdi\bin\bng\bg a\ba m\bme\bes\bss\bsa\bag\bge\be n\bnu\bum\bmb\bbe\ber\br h\bhe\bea\bad\bde\ber\br.\b.
+
+ Don't! A sequence header may be useful for users whose systems don't
+ pass on the ``Return-to:'' header to the MUA.
+
+ Use D\bDI\bIR\bR/\b/h\bhe\bea\bad\bde\ber\bra\bad\bdd\bd with a header of the type ``X-Sequence: <#n#>''.
+
+ 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 D\bDI\bIR\bR/\b/s\bse\beq\bqu\bue\ben\bnc\bce\be 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.
+
+ 9\b9.\b.5\b5.\b. R\bRe\bem\bmo\bov\bvi\bin\bng\bg h\bhe\bea\bad\bde\ber\brs\bs f\bfr\bro\bom\bm o\bou\but\btg\bgo\boi\bin\bng\bg m\bme\bes\bss\bsa\bag\bge\bes\bs.\b.
+
+ Put the header up to, but excluding the ``:'' in D\bDI\bIR\bR/\b/h\bhe\bea\bad\bde\ber\brr\bre\bem\bmo\bov\bve\be.
+
+
+ 9\b9.\b.6\b6.\b. R\bRe\bem\bmo\bov\bvi\bin\bng\bg M\bMI\bIM\bME\bE p\bpa\bar\brt\bts\bs f\bfr\bro\bom\bm m\bme\bes\bss\bsa\bag\bge\bes\bs.\b.
+
+ 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 D\bDI\bIR\bR/\b/m\bmi\bim\bme\ber\bre\bem\bmo\bov\bve\be. This is
+ automatically configured when using the ezmlm-make(1) ``-x'' switch.
+
+
+ 9\b9.\b.7\b7.\b. L\bLi\bim\bmi\bit\bti\bin\bng\bg `\b``\b`R\bRe\bec\bce\bei\biv\bve\bed\bd:\b:'\b''\b' h\bhe\bea\bad\bde\ber\brs\bs i\bin\bn o\bou\but\btg\bgo\boi\bin\bng\bg m\bme\bes\bss\bsa\bag\bge\bes\bs.\b.
+
+ 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.313 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.
+
+
+ 9\b9.\b.8\b8.\b. S\bSe\bet\btt\bti\bin\bng\bg `\b``\b`R\bRe\bep\bpl\bly\by-\b-T\bTo\bo:\b: l\bli\bis\bst\bt@\b@h\bho\bos\bst\bt'\b''\b'.\b.
+
+ 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
+ D\bDI\bIR\bR/\b/h\bhe\bea\bad\bde\ber\brr\bre\bem\bmo\bov\bve\be, and ``Reply-To: list@host.dom'' into D\bDI\bIR\bR/\b/h\bhe\bea\bad\bde\ber\bra\bad\bdd\bd.
+
+
+ 9\b9.\b.9\b9.\b. C\bCo\bon\bnf\bfi\big\bgu\bur\bri\bin\bng\bg t\bth\bhe\be l\bli\bis\bst\bt s\bso\bo p\bpo\bos\bst\bts\bs a\bar\bre\be n\bno\bot\bt c\bco\bop\bpi\bie\bed\bd t\bto\bo t\bth\bhe\be o\bor\bri\big\bgi\bin\bna\bal\bl
+ s\bse\ben\bnd\bde\ber\br.\b.
+
+ 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 D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br.
+
+
+ 9\b9.\b.1\b10\b0.\b. C\bCu\bus\bst\bto\bom\bmi\biz\bzi\bin\bng\bg e\bez\bzm\bml\blm\bm n\bno\bot\bti\bif\bfi\bic\bca\bat\bti\bio\bon\bn m\bme\bes\bss\bsa\bag\bge\bes\bs.\b.
+
+ Most of ezmlm's more commonly used messages are stored in D\bDI\bIR\bR/\b/t\bte\bex\bxt\bt/\b/.
+ These messages can be edited manually for a list once it is set up, or
+ on a global basis via modification of e\bez\bzm\bml\blm\bmr\brc\bc(\b(5\b5)\b). The messages may
+ also be edited via E-mail by remote administrators (remote admin must
+ also be enabled - ezmlm-make switch ``-r'') after the list is
+ established by creating the list using the ezmlm-make(1) ``-n'' (new
+ text files) (see ``How text file editing works'' and see ``Customizing
+ ezmlm-make operation'').
+
+ The most useful messages are D\bDI\bIR\bR/\b/t\bte\bex\bxt\bt/\b/s\bsu\bub\bb-\b-o\bok\bk (and for subscription
+ moderated lists D\bDI\bIR\bR/\b/t\bte\bex\bxt\bt/\b/m\bmo\bod\bd-\b-s\bsu\bub\bb) for new subscriber information (such
+ as the traditional ``welcome'' message, or a list charter or list
+ posting rules/guidelines); D\bDI\bIR\bR/\b/t\bte\bex\bxt\bt/\b/u\bun\bns\bsu\bub\bb-\b-n\bno\bop\bp is useful for messages
+ to frustrated users unsuccessful in their unsubscribe attempts;
+ D\bDI\bIR\bR/\b/t\bte\bex\bxt\bt/\b/h\bhe\bel\blp\bp for general help information in reply to list-help@host
+ or unrecognized commands, D\bDI\bIR\bR/\b/t\bte\bex\bxt\bt/\b/b\bbo\bot\btt\bto\bom\bm for inclusion at the bottom
+ of virtually all ezmlm messages; D\bDI\bIR\bR/\b/t\bte\bex\bxt\bt/\b/m\bmo\bod\bd-\b-h\bhe\bel\blp\bp for moderator
+ information; D\bDI\bIR\bR/\b/t\bte\bex\bxt\bt/\b/t\btr\bra\bai\bil\ble\ber\br for a (few) line(s) at the bottom of
+ each post; D\bDI\bIR\bR/\b/t\bte\bex\bxt\bt/\b/d\bdi\big\bge\bes\bst\bt for information in the ``Administrivia''
+ section of digests.
+
+
+ 9\b9.\b.1\b11\b1.\b. S\bSp\bpe\bec\bci\bif\bfy\byi\bin\bng\bg c\bch\bha\bar\bra\bac\bct\bte\ber\br s\bse\bet\bt a\ban\bnd\bd c\bco\bon\bnt\bte\ben\bnt\bt-\b-t\btr\bra\ban\bns\bsf\bfe\ber\br-\b-e\ben\bnc\bco\bod\bdi\bin\bng\bg f\bfo\bor\br o\bou\but\bt-\b-
+ g\bgo\boi\bin\bng\bg e\bez\bzm\bml\blm\bm m\bme\bes\bss\bsa\bag\bge\bes\bs.\b.
+
+ 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. D\bDI\bIR\bR/\b/t\bte\bex\bxt\bt/\b/ 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 D\bDI\bIR\bR/\b/c\bch\bha\bar\brs\bse\bet\bt (default: us-
+ ascii). To specify quoted-printable or base64 content-transfer-
+ encoding, add ``:Q'' or ``:B'' after the character set name in
+ D\bDI\bIR\bR/\b/c\bch\bha\bar\brs\bse\bet\bt.
+
+
+ 1\b10\b0.\b. C\bCu\bus\bst\bto\bom\bmi\biz\bzi\bin\bng\bg a\bar\brc\bch\bhi\biv\bve\be r\bre\bet\btr\bri\bie\bev\bva\bal\bl.\b.
+
+
+ 1\b10\b0.\b.1\b1.\b. S\bSp\bpe\bec\bci\bif\bfy\byi\bin\bng\bg t\bth\bhe\be f\bfo\bor\brm\bma\bat\bt f\bfo\bor\br r\bre\bet\btr\bri\bie\bev\bve\bed\bd m\bme\bes\bss\bsa\bag\bge\bes\bs.\b.
+
+ 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.
+
+
+ 1\b10\b0.\b.2\b2.\b. S\bSp\bpe\bec\bci\bif\bfy\byi\bin\bng\bg t\bth\bhe\be d\bde\bef\bfa\bau\bul\blt\bt f\bfo\bor\brm\bma\bat\bt f\bfo\bor\br d\bdi\big\bge\bes\bst\bts\bs a\ban\bnd\bd a\bar\brc\bch\bhi\biv\bve\be
+ r\bre\bet\btr\bri\bie\bev\bva\bal\bl.\b.
+
+ 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'').
+
+
+ 1\b10\b0.\b.3\b3.\b. L\bLi\bim\bmi\bit\bti\bin\bng\bg t\bth\bhe\be n\bnu\bum\bmb\bbe\ber\br o\bof\bf m\bme\bes\bss\bsa\bag\bge\bes\bs p\bpe\ber\br -\b-g\bge\bet\bt/\b/-\b-i\bin\bnd\bde\bex\bx r\bre\beq\bqu\bue\bes\bst\bt.\b.
+
+ 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 i\bid\bdx\bx.\b.h\bh and recompiling. Remember to edit t\bte\bex\bxt\bt/\b/b\bbo\bot\btt\bto\bom\bm,
+ t\bte\bex\bxt\bt/\b/b\bbo\bou\bun\bnc\bce\be, and e\bez\bzm\bml\blm\bmr\brc\bc(\b(5\b5)\b) to reflect these changes so that your
+ users won't get confused.
+
+
+ 1\b11\b1.\b. R\bRe\bes\bst\btr\bri\bic\bct\bti\bin\bng\bg a\bar\brc\bch\bhi\biv\bve\be r\bre\bet\btr\bri\bie\bev\bva\bal\bl.\b.
+
+
+ 1\b11\b1.\b.1\b1.\b. R\bRe\bes\bst\btr\bri\bic\bct\bti\bin\bng\bg a\bar\brc\bch\bhi\biv\bve\be a\bac\bcc\bce\bes\bss\bs t\bto\bo s\bsu\bub\bbs\bsc\bcr\bri\bib\bbe\ber\brs\bs.\b.
+
+ If you use ezmlm-get(1), archive retrieval can be restricted by using
+ the ezmlm-make(1) ``-g'' (guard archive) switch. This in turn sets
+ ezmlm-get(1) up with its ``-s'' switch, allowing 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 D\bDI\bIR\bR/\b/a\bal\bll\blo\bow\bw/\b/.
+ Addresses can be added remotely by mailing list-allow-
+ useralias=userhost@listhost. Other commands, such as ``subscribe''
+ work as expected. As you can see, the different programs have many
+ options and ezmlm-make(1) organizes most of them into the most useful
+ sets to make it easier. Don't hesitate to look at the ezmlmrc(5) man
+ page and man pages for individual commands. There are many useful
+ options to more finely tune your lists to your taste. Via modification
+ of ezmlmrc(5) you can make your favorite options the default!
+
+ 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
+ D\bDI\bIR\bR/\b/a\bal\bll\blo\bow\bw/\b/ 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.
+
+
+ 1\b11\b1.\b.2\b2.\b. R\bRe\bes\bst\btr\bri\bic\bct\bti\bin\bng\bg a\bav\bva\bai\bil\bla\bab\bbl\ble\be a\bar\brc\bch\bhi\biv\bve\be r\bre\bet\btr\bri\bie\bev\bva\bal\bl c\bco\bom\bmm\bma\ban\bnd\bds\bs.\b.
+
+ 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
+ D\bDI\bIR\bR/\b/m\bma\ban\bna\bag\bge\ber\br. If you don't want digest creation via trigger messages
+ and D\bDI\bIR\bR/\b/m\bma\ban\bna\bag\bge\ber\br, but use other means to created digests, you can
+ remove the ezmlm-get(1) line from D\bDI\bIR\bR/\b/m\bma\ban\bna\bag\bge\ber\br.
+
+
+ 1\b11\b1.\b.3\b3.\b. R\bRe\bes\bst\btr\bri\bic\bct\bti\bin\bng\bg a\bar\brc\bch\bhi\biv\bve\be r\bre\bet\btr\bri\bie\bev\bva\bal\bl t\bto\bo m\bmo\bod\bde\ber\bra\bat\bto\bor\brs\bs.\b.
+
+ If D\bDI\bIR\bR/\b/p\bpu\bub\bbl\bli\bic\bc 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 D\bDI\bIR\bR/\b/p\bpu\bub\bbl\bli\bic\bc, 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 D\bDI\bIR\bR/\b/p\bpu\bub\bbl\bli\bic\bc. Also, look
+ at the ezmlm-make ``-b'' switch.
+
+
+ 1\b11\b1.\b.4\b4.\b. A\bAl\bll\blo\bow\bwi\bin\bng\bg a\bar\brc\bch\bhi\biv\bve\be r\bre\bet\btr\bri\bie\bev\bva\bal\bl f\bfr\bro\bom\bm a\ba n\bno\bon\bn-\b-p\bpu\bub\bbl\bli\bic\bc l\bli\bis\bst\bt.\b.
+
+ A non-public list lacks D\bDI\bIR\bR/\b/p\bpu\bub\bbl\bli\bic\bc. ezmlm-manage(1) will reject user
+ requests for (un) subscription and for archive retrieval. The
+ restriction on archive retrieval can be removed with the ezmlm-get(1)
+ ``-p'' (public) switch.
+
+
+ 1\b12\b2.\b. C\bCu\bus\bst\bto\bom\bmi\biz\bzi\bin\bng\bg d\bdi\big\bge\bes\bst\bts\bs.\b.
+
+
+ 1\b12\b2.\b.1\b1.\b. S\bSe\bet\btt\bti\bin\bng\bg u\bup\bp a\ba d\bdi\big\bge\bes\bst\bt l\bli\bis\bst\bt.\b.
+
+ Digests are integrated with normal ezmlm lists if you use ezmlm-
+ idx>=0.30. Just add the ezmlm-make(1) ``-d'' switch to your list
+ setup. To add digests to an existing list created with ezmlm-idx>=0.23
+ use:
+
+
+ % ezmlm-make -+d DIR
+
+
+
+
+ For ezmlm-0.53 or older lists, you just need to re-specify also other
+ switches and the other ezmlm-make(1) arguments.
+
+
+ 1\b12\b2.\b.2\b2.\b. G\bGe\ben\bne\ber\bra\bat\bti\bin\bng\bg d\bda\bai\bil\bly\by d\bdi\big\bge\bes\bst\bts\bs.\b.
+
+ The easiest way to generate trigger messages is to use crond(8) and
+ execute ezmlm-get(1) daily. To do this, create the list with:
+
+
+ ezmlm-make -d dir dot local host
+
+
+
+
+ and add a line to your crontab file:
+
+
+ 30 04 * * * ezmlm-get dir
+
+
+
+
+ and execute crontab(1). This will generate a digest each day at 04:30
+ am. In addition, a digest will be generated at any time when the lat-
+ est post makes it more than 30 messages or more than 64 kbytes of mes-
+ sage body since the latest digest. If you do not want these extra
+ digests, edit D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br and remove the ezmlm-tstdig(1) and ezmlm-
+ get(1) lines.
+
+ If you do not need the digests to go out at a particular time, use the
+ standard setup, but edit D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br to put ``-t 24'' on the ezmlm-
+ tstdig(1) line instead of the default ``-t 48'' for 48 hours. This is
+ even easier. You can modify all parameters by editing e\bez\bzm\bml\blm\bmr\brc\bc or by
+ using the ezmlm-make(1) ``-4'' argument when creating/editing the
+ list. This is described in the ezmlm-make(1) man page, and the options
+ etc, are described in the ezmlm-tstdig(1) man page.
+
+
+
+
+
+ 1\b12\b2.\b.3\b3.\b. G\bGe\ben\bne\ber\bra\bat\bti\bin\bng\bg t\bth\bhe\be f\bfi\bir\brs\bst\bt d\bdi\big\bge\bes\bst\bt.\b.
+
+ 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 D\bDI\bIR\bR/\b/d\bdi\big\bgn\bnu\bum\bm.
+
+ If you want the next digest to start at message 456, you can always
+ edit D\bDI\bIR\bR/\b/d\bdi\big\bgn\bnu\bum\bm to contain '455'. If you want the next digest to be
+ named issue 678, put '677' into D\bDI\bIR\bR/\b/d\bdi\big\bgi\bis\bss\bsu\bue\be.
+
+
+ 1\b12\b2.\b.4\b4.\b. A\bAd\bdd\bdi\bin\bng\bg s\bst\bta\ban\bnd\bda\bar\brd\bd a\bad\bdm\bmi\bin\bni\bis\bst\btr\bra\bat\bti\biv\bve\be i\bin\bnf\bfo\bor\brm\bma\bat\bti\bio\bon\bn t\bto\bo d\bdi\big\bge\bes\bst\bts\bs.\b.
+
+ The text in D\bDI\bIR\bR/\b/t\bte\bex\bxt\bt/\b/d\bdi\big\bge\bes\bst\bt is copied into the ``Administrivia''
+ section of the digest. This information can be customized on a
+ system-wide basis by editing /\b/e\bet\btc\bc/\b/e\bez\bzm\bml\blm\bmr\brc\bc, on a user-wide basis by
+ editing ~\b~/\b/.\b.e\bez\bzm\bml\blm\bmr\brc\bc, or for the list by directly editing the
+ D\bDI\bIR\bR/\b/t\bte\bex\bxt\bt/\b/d\bdi\big\bge\bes\bst\bt 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'').
+
+
+ 1\b12\b2.\b.5\b5.\b. C\bCo\bon\bnt\btr\bro\bol\bll\bli\bin\bng\bg t\bth\bhe\be d\bdi\big\bge\bes\bst\bt f\bfo\bor\brm\bma\bat\bt.\b.
+
+ 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 digests triggered directly from crond(8), just use the ``-f''
+ format specifier:
+
+
+ ezmlm-get -fx DIR
+
+
+
+
+ The same switch can also be used for standard digest triggering from
+ D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br. Just add the ``-fx'' switch to the ezmlm-get(1) command
+ line there. Edit ~\b~/\b/e\bez\bzm\bml\blm\bmr\brc\bc to assure that such customizations will be
+ used for future list creations/edits.
+
+
+ 1\b12\b2.\b.6\b6.\b. C\bCu\bus\bst\bto\bom\bmi\biz\bzi\bin\bng\bg b\bbo\bou\bun\bnc\bce\be h\bha\ban\bnd\bdl\bli\bin\bng\bg.\b.
+
+ 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 D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br, and D\bDI\bIR\bR/\b/m\bma\ban\bna\bag\bge\ber\br 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.
+
+ This should not be necessary for ezmlm-idx>=0.32. That version adds
+ much more efficient bounce handling, making this type of modification
+ usable only for extremely large lists with many bad addresses (unusual
+ for ezmlm lists) and for hosts that are working near the limit of
+ their capacity (where shifting some qmail load to off-peak hours is
+ worth the effort).
+
+ 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.
+
+
+ 1\b13\b3.\b. R\bRe\bem\bmo\bot\bte\be a\bad\bdm\bmi\bin\bni\bis\bst\btr\bra\bat\bti\bio\bon\bn.\b.
+
+
+ 1\b13\b3.\b.1\b1.\b. H\bHo\bow\bw c\bca\ban\bn I\bI r\bre\bem\bmo\bot\bte\bel\bly\by a\bad\bdd\bd m\bmo\bod\bde\ber\bra\bat\bto\bor\brs\bs,\b, s\bsu\bub\bbs\bsc\bcr\bri\bib\bbe\ber\br a\bal\bli\bia\bas\bse\bes\bs,\b, e\bet\btc\bc?\b?
+
+ On any list, the D\bDI\bIR\bR/\b/a\bal\bll\blo\bow\bw/\b/ database can be manipulated remotely via
+ mail to list-allow-subscribe@listhost, etc. The rules for
+ adding/removing/listing addresses to this database are the same as for
+ the main list. Thus, if a user on an open list wants to be able to
+ post from alias@al.host.com s/he can send a message to list-allow-
+ subscribe-alias=al.host.com@listhost and reply to the confirmation
+ request. Now, s/he can post from this address even on a subscriber-
+ only list and even though the address is not a real subscriber.
+
+ It can be confusing to some users that you use ``subscribe'' here, but
+ you don't get any messages. If you explain to them that this is just
+ another collection of addresses they will understand. You can also
+ send the initial message on their behalf. If you are a remote admin,
+ you can even complete the transaction adding the alias without
+ subscriber participation.
+
+ Addresses can also be unsubscribed from the ``allow'' database.
+ However, there is usually no good reason to do so.
+
+ If configured, the D\bDI\bIR\bR/\b/d\bde\ben\bny\by/\b/ database can be manipulated, but only by
+ remote administrators, by mail to e.g. list-deny-
+ baduser=badhost@listhost. Normal users cannot access this database.
+
+ To remotely administrate the D\bDI\bIR\bR/\b/m\bmo\bod\bd/\b/ databases (i.e., without shell
+ access), you need to set up a non-public, remotely administered list
+ which ``resides'' within the D\bDI\bIR\bR/\b/m\bmo\bod\bd. _\bP_\bl_\be_\ba_\bs_\be _\bc_\ba_\br_\be_\bf_\bu_\bl_\bl_\by _\bc_\bo_\bn_\bs_\bi_\bd_\be_\br _\bt_\bh_\be
+ _\bi_\bm_\bp_\bl_\bi_\bc_\ba_\bt_\bi_\bo_\bn_\bs _\bo_\bf _\bm_\ba_\bk_\bi_\bn_\bg _\bi_\bt _\bp_\bo_\bs_\bs_\bi_\bb_\bl_\be _\bt_\bo _\br_\be_\bm_\bo_\bt_\be_\bl_\by _\ba_\bd_\bd_\b, _\br_\be_\bm_\bo_\bv_\be_\b, _\ba_\bn_\bd _\bl_\bi_\bs_\bt
+ _\bm_\bo_\bd_\be_\br_\ba_\bt_\bo_\br_\bs_\b. _\bI_\bn _\bm_\ba_\bn_\by _\bc_\bi_\br_\bc_\bu_\bm_\bs_\bt_\ba_\bn_\bc_\be_\bs_\b, _\bt_\bh_\bi_\bs _\bi_\bs _\bd_\ba_\bn_\bg_\be_\br_\bo_\bu_\bs_\b.
+
+ After setting up your list with the specific functionality you need,
+ use the following command for D\bDI\bIR\bR/\b/m\bmo\bod\bd/\b/:
+
+
+ % 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 ~\b~/\b/.\b.q\bqm\bma\bai\bil\bl-\b-l\bli\bis\bst\bt-\b-m\bmo\bod\bd and ~\b~/\b/D\bDI\bIR\bR/\b/m\bmo\bod\bd/\b/e\bed\bdi\bit\bto\bor\br. 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.
+
+
+ 1\b13\b3.\b.2\b2.\b. M\bMo\bod\bde\ber\bra\bat\bti\bin\bng\bg p\bpo\bos\bst\bts\bs f\bfr\bro\bom\bm a\ba s\bse\bec\bco\bon\bnd\bda\bar\bry\by a\bac\bcc\bco\bou\bun\bnt\bt.\b.
+
+ 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.
+
+ 1\b13\b3.\b.3\b3.\b. M\bMo\bod\bde\ber\bra\bat\bti\bin\bng\bg s\bsu\bub\bbs\bsc\bcr\bri\bip\bpt\bti\bio\bon\bn f\bfr\bro\bom\bm a\ba s\bse\bec\bco\bon\bnd\bda\bar\bry\by a\bac\bcc\bco\bou\bun\bnt\bt.\b.
+
+ 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 D\bDI\bIR\bR/\b/r\bre\bem\bmo\bot\bte\be).
+
+
+ 1\b13\b3.\b.4\b4.\b. A\bAu\but\bto\bom\bma\bat\bti\bic\bca\bal\bll\bly\by a\bap\bpp\bpr\bro\bov\bvi\bin\bng\bg p\bpo\bos\bst\bts\bs o\bor\br s\bsu\bub\bbs\bsc\bcr\bri\bip\bpt\bti\bio\bon\bns\bs.\b.
+
+ 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.
+
+
+ 1\b13\b3.\b.5\b5.\b. A\bAl\bll\blo\bow\bwi\bin\bng\bg r\bre\bem\bmo\bot\bte\be a\bad\bdm\bmi\bin\bni\bis\bst\btr\bra\bat\bto\bor\brs\bs t\bto\bo g\bge\bet\bt a\ba s\bsu\bub\bbs\bsc\bcr\bri\bib\bbe\ber\br l\bli\bis\bst\bt.\b.
+
+ 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 e\bez\bzm\bml\blm\bmr\brc\bc(\b(5\b5)\b) (see
+ ``Customizing ezmlm-make operation'').
+
+
+
+
+
+ 1\b13\b3.\b.6\b6.\b. A\bAl\bll\blo\bow\bwi\bin\bng\bg r\bre\bem\bmo\bot\bte\be a\bad\bdm\bmi\bin\bni\bis\bst\btr\bra\bat\bto\bor\brs\bs t\bto\bo r\bre\bet\btr\bri\bie\bev\bve\be o\bor\br s\bse\bea\bar\brc\bch\bh a\ba s\bsu\bub\bb-\b-
+ s\bsc\bcr\bri\bip\bpt\bti\bio\bon\bn l\blo\bog\bg.\b.
+
+ This is restricted and works as the subscriber list, since it contains
+ information of equal sensitivity. To receive the entire log, mail
+ list-log@listhost. See ``Howto get a subscription log'' for more
+ details on the reply format. As of ezmlm-idx-0.32, the subscription
+ log also contains the From: line contents from the user's subscribe
+ confirmation. This usually contains the user's name and can be helpful
+ if the user cannot recall or determine the subscription address. To
+ make life easier for the remote admin, ezmlm-idx-0.32 also supports
+ searching the log, using exact matches for alphanumerics and ``_'' as
+ a wild card character. Thus, to find records matching ``Keith John*'',
+ the remote admin can mail list-log.Keith_John. See ``Howto get a
+ subscription log'' for more information.
+
+
+ 1\b13\b3.\b.7\b7.\b. A\bAl\bll\blo\bow\bwi\bin\bng\bg u\bus\bse\ber\brs\bs t\bto\bo g\bge\bet\bt a\ba s\bsu\bub\bbs\bsc\bcr\bri\bib\bbe\ber\br l\bli\bis\bst\bt.\b.
+
+ If you want any user to be able to get a subscriber list, you can set
+ up a separate link to D\bDI\bIR\bR/\b/l\bli\bis\bst\bt and then put in a script using ezmlm-
+ list (See ``adding your own commands'' for more info.) . The authors
+ strongly urge against this, since a common method for spammers to get
+ valid E-mail addresses from mailing lists is to exploit unrestricted
+ -list commands. A subscriber with questions about who is on the list
+ should contact the list-owner@host. A subscriber wishing to confirm
+ that they are still on the list can just send a message to list-
+ subscribe@listhost, and reply to the confirm request. The following
+ message will be a ``ezmlm response'' if the user was already a
+ subscriber, and a ``WELCOME to listname'' if s/he was not.
+
+
+ 1\b13\b3.\b.8\b8.\b. C\bCh\bha\ban\bng\bgi\bin\bng\bg t\bth\bhe\be t\bti\bim\bme\beo\bou\but\bt f\bfo\bor\br m\bme\bes\bss\bsa\bag\bge\bes\bs i\bin\bn t\bth\bhe\be m\bmo\bod\bde\ber\bra\bat\bti\bio\bon\bn q\bqu\bue\beu\bue\be.\b.
+
+ Put the time, in hours, into D\bDI\bIR\bR/\b/m\bmo\bod\bdt\bti\bim\bme\be. This value may not exceed
+ the range of 24-120 h set at compile time by the defines in i\bid\bdx\bx.\b.h\bh.
+
+
+ 1\b13\b3.\b.9\b9.\b. F\bFi\bin\bnd\bdi\bin\bng\bg o\bou\but\bt h\bho\bow\bw m\bma\ban\bny\by m\bme\bes\bss\bsa\bag\bge\bes\bs a\bar\bre\be w\bwa\bai\bit\bti\bin\bng\bg f\bfo\bor\br m\bmo\bod\bde\ber\bra\bat\bti\bio\bon\bn.\b.
+
+
+
+ % 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. l\bli\bis\bst\bt-\b-c\bch\bhk\bkq\bqu\bue\beu\bue\be@\b@h\bho\bos\bst\bt. (See ezmlm-check(1) and ``adding
+ your own commands'' for examples.)
+
+
+ 1\b13\b3.\b.1\b10\b0.\b. U\bUs\bsi\bin\bng\bg t\bth\bhe\be s\bsa\bam\bme\be m\bmo\bod\bde\ber\bra\bat\bto\bor\brs\bs f\bfo\bor\br m\bmu\bul\blt\bti\bip\bpl\ble\be l\bli\bis\bst\bts\bs.\b.
+
+ 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 /\b/p\bpa\bat\bth\bh/\b/m\bmo\bod\bdd\bdi\bir\br into D\bDI\bIR\bR/\b/m\bmo\bod\bds\bsu\bub\bb (for moderation
+ of subscribes), D\bDI\bIR\bR/\b/r\bre\bem\bmo\bot\bte\be (for remote admin if D\bDI\bIR\bR/\b/m\bmo\bod\bds\bsu\bub\bb does not
+ exist), and D\bDI\bIR\bR/\b/m\bmo\bod\bdp\bpo\bos\bst\bt (for moderation of messages).
+
+ For example:
+
+
+
+ % echo "/home/joe/mods" > ~joe/DIR/modsub
+
+
+
+
+ _\bN_\bO_\bT_\bE_\b: The path must start with a '/'.
+
+
+ 1\b13\b3.\b.1\b11\b1.\b. U\bUs\bsi\bin\bng\bg d\bdi\bif\bff\bfe\ber\bre\ben\bnt\bt m\bmo\bod\bde\ber\bra\bat\bto\bor\brs\bs f\bfo\bor\br m\bme\bes\bss\bsa\bag\bge\be a\ban\bnd\bd s\bsu\bub\bbs\bsc\bcr\bri\bip\bpt\bti\bio\bon\bn m\bmo\bod\bde\ber\br-\b-
+ a\bat\bti\bio\bon\bn.\b.
+
+ Proceed as in the previous point, but set up two different moddirs.
+ Naturally, one of these can be D\bDI\bIR\bR/\b/m\bmo\bod\bd/\b/ (preferably the one for posts,
+ to keep it cleaner). Then modify the appropriate files (D\bDI\bIR\bR/\b/m\bmo\bod\bdp\bpo\bos\bst\bt
+ and D\bDI\bIR\bR/\b/m\bmo\bod\bds\bsu\bub\bb) to contain absolute paths to the correct moddir.
+
+
+ 1\b13\b3.\b.1\b12\b2.\b. t\bth\bhe\be `\b``\b`s\bsu\bup\bpe\ber\br m\bmo\bod\bde\ber\bra\bat\bto\bor\br'\b''\b' a\bab\bbl\ble\be t\bto\bo a\bad\bdd\bd/\b/r\bre\bem\bmo\bov\bve\be m\bmo\bod\bde\ber\bra\bat\bto\bor\brs\bs
+ r\bre\bem\bmo\bot\bte\bel\bly\by.\b. S\bSe\bet\btt\bti\bin\bng\bg u\bup\bp m\bmo\bod\bde\ber\bra\bat\bte\bed\bd l\bli\bis\bst\bts\bs w\bwi\bit\bth\bh t\bth\bhe\be l\bli\bis\bst\bt o\bow\bwn\bne\ber\br a\bas\bs
+
+ This is done by crating a list that has D\bDI\bIR\bR/\b/m\bmo\bod\bd/\b/ as it's main list
+ directory, then adding the ``super moderator'' to D\bDI\bIR\bR/\b/m\bmo\bod\bd/\b/m\bmo\bod\bd/\b/ (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).
+
+
+
+
+
+ 1\b13\b3.\b.1\b13\b3.\b. C\bCu\bus\bst\bto\bom\bmi\biz\bzi\bin\bng\bg e\bez\bzm\bml\blm\bm a\bad\bdm\bmi\bin\bni\bis\bst\btr\bra\bat\bti\biv\bve\be m\bme\bes\bss\bsa\bag\bge\bes\bs.\b.
+
+ Subject lines, and other ezmlm output for moderation are controlled by
+ defines in i\bid\bdx\bx.\b.h\bh and by files in D\bDI\bIR\bR/\b/t\bte\bex\bxt\bt. To customize these, change
+ i\bid\bdx\bx.\b.h\bh and recompile or for D\bDI\bIR\bR/\b/t\bte\bex\bxt\bt files, edit e\bez\bzm\bml\blm\bmr\brc\bc(\b(5\b5)\b) (see
+ ``Customizing ezmlm-make operation'').
+
+ You can also configure the list to allow remote administrators to edit
+ files in D\bDI\bIR\bR/\b/t\bte\bex\bxt\bt/\b/ via E-mail (see ``How text file editing works'').
+
+
+ 1\b13\b3.\b.1\b14\b4.\b. M\bMa\ban\bnu\bua\bal\bll\bly\by a\bap\bpp\bpr\bro\bov\bvi\bin\bng\bg a\ba m\bme\bes\bss\bsa\bag\bge\be a\baw\bwa\bai\bit\bti\bin\bng\bg m\bmo\bod\bde\ber\bra\bat\bti\bio\bon\bn.\b.
+
+ All you have to do is to pipe the corresponding message to ``ezmlm-
+ send DIR''. Messages awaiting moderation are kept in D\bDI\bIR\bR/\b/m\bmo\bod\bd/\b/p\bpe\ben\bnd\bdi\bin\bng\bg/\b/.
+ To find a particular file, grep the contents. Thus, to find a file
+ from user@host.dom, try:
+
+
+
+ % grep 'user@host\.dom' DIR/mod/pending/*
+
+
+
+
+ (Depending on your setup, you may not have to escape the period.)
+ Check the files for the owner execute (``x'') bit. It is set on all
+ messages queued successfully. Ignore other files!
+
+ To then accept the message (change the ezmlm-send(1) path if you've
+ installed in a non-default directory):
+
+
+
+ % cat DIR/mod/pending/filename \
+ % /usr/local/bin/ezmlm/ezmlm-send DIR
+
+
+
+
+ Alternatively, use ezmlm-accept(1). It checks the 'x' bit, ezmlm-
+ send(1) return codes, removes the file, etc.
+
+ For example:
+
+
+
+ % ezmlm-accept ~joe/SOS ~joe/SOS/pending/*
+
+
+
+
+ will accept all messages in the queue of the list in ~\b~j\bjo\boe\be/\b/S\bSO\bOS\bS/\b/.
+
+
+ 1\b13\b3.\b.1\b15\b5.\b. M\bMa\ban\bnu\bua\bal\bll\bly\by r\bre\bej\bje\bec\bct\bti\bin\bng\bg a\ba m\bme\bes\bss\bsa\bag\bge\be a\baw\bwa\bai\bit\bti\bin\bng\bg m\bmo\bod\bde\ber\bra\bat\bti\bio\bon\bn.\b.
+
+ Simply deleting the file from D\bDI\bIR\bR/\b/m\bmo\bod\bd/\b/p\bpe\ben\bnd\bdi\bin\bng\bg/\b/ 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 D\bDI\bIR\bR/\b/m\bmo\bod\bdt\bti\bim\bme\be; default 120).
+
+
+
+
+ 1\b14\b4.\b. S\bSu\bub\bbl\bli\bis\bst\bts\bs.\b.
+
+ 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).
+
+
+ 1\b14\b4.\b.1\b1.\b. S\bSu\bub\bbl\bli\bis\bst\bts\bs o\bof\bf e\bez\bzm\bml\blm\bm l\bli\bis\bst\bts\bs.\b.
+
+ 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.
+
+
+ 1\b14\b4.\b.2\b2.\b. S\bSu\bub\bbl\bli\bis\bst\bts\bs o\bof\bf n\bno\bon\bn-\b-e\bez\bzm\bml\blm\bm l\bli\bis\bst\bts\bs.\b.
+
+ 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 D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br of your sublist and add a ``-h
+ _\bL_\bi_\bs_\bt_\bp_\br_\bo_\bc_\be_\bs_\bs_\bo_\br_\b-_\bV_\be_\br_\bs_\bi_\bo_\bn_\b:'' option to the ezmlm-send(1) line, but
+ replacing ``_\bL_\bi_\bs_\bt_\bp_\br_\bo_\bc_\be_\bs_\bs_\bo_\br_\b-_\bV_\be_\br_\bs_\bi_\bo_\bn_\b:'' with your mainlist header.
+
+ Now your list will accept only messages from mainlist@mainhost and
+ with the header specified.
+
+
+ 1\b14\b4.\b.3\b3.\b. H\bHo\bow\bw t\bto\bo s\bse\bet\bt u\bup\bp a\ba c\bcl\blu\bus\bst\bte\ber\br o\bof\bf l\bli\bis\bst\bt a\ban\bnd\bd s\bsu\bub\bbl\bli\bis\bst\bts\bs w\bwi\bit\bth\bh s\bst\bta\ban\bnd\bda\bar\brd\bd
+ d\bda\bat\bta\bab\bba\bas\bse\bes\bs.\b.
+
+ ezmlm-0.53 allows sublists. The difference between a sublist and a
+ main list is that the sublist requires that the SENDER of the message
+ is the main list and that the message has a ``Mailing-List:'' header.
+ Sublist messages have their own subscriber database and subscription
+ mechanism, and use their own message number. This is very convenient
+ if you want to create a private sublist. Since the subscribers have
+ to interact with the appropriate sublist, it is difficult to
+ administrate if you want to use it to distribute the load of a very
+ large list, since users will have to address administrative requests
+ such as unsubscribe to the correct sublist. Also, bounce messages
+ refer to the sublist archive with sublist message numbers.
+
+ ezmlm-idx modifies this in several ways: First, the message number of
+ the incoming message is used also for the outgoing message so that
+ subscribers see the same message number no matter which sublist they
+ get it from. For security reasons, this is enabled only if the sublist
+ is NOT ARCHIVED. With this feature, bounce messages can refer the user
+ to the main list archive instead, obviating multiple archives.
+
+ Second, ezmlm-split(1) can be used to forward administrative requests
+ sent to the main list, to the appropriate sublist. Thus, subscribers
+ interact only with the main list, and do not need to know which
+ sublist that servers them. With bounce and administrative messages
+ referring them to the main list, subscribers will usually be unaware
+ of the sublisting.
+
+ To set this up:
+
+
+ +\bo
+
+ c\bcr\bre\bea\bat\bte\be t\bth\bhe\be m\bma\bai\bin\bn l\bli\bis\bst\bt
+
+
+ ezmlm-make dir dot local host
+
+
+
+
+ +\bo
+
+ a\bad\bdd\bd a\ban\bn e\bez\bzm\bml\blm\bm-\b-s\bsp\bpl\bli\bit\bt(\b(1\b1)\b) i\bin\bnv\bvo\boc\bca\bat\bti\bio\bon\bn
+ Before the ezmlm-manage(1) line in D\bDI\bIR\bR/\b/m\bma\ban\bna\bag\bge\ber\br add:
+
+
+ |/path/ezmlm-split dir
+
+
+
+
+ +\bo
+
+ d\bde\bec\bci\bid\bde\be h\bho\bow\bw t\bto\bo s\bsp\bpl\bli\bit\bt t\bth\bhe\be l\blo\boa\bad\bd
+ The main list sends to sublists and to any addresses not covered
+ by the split table. You can split the load by domain
+ (``geographically''), and any domain (including '') can be
+ subdivided by ``hash'' by using different parts of the 0-52
+ range. Of course, you can also use hash alone. The request will
+ go to the first row that matches, so although overlaps are not
+ advisable (in case you later want to add sublists of switch to
+ an SQL server-based system (see ``'')), they have no negative
+ effects. The domain for ezmlm-split can be the last TWO parts,
+ i.e. ``edu.wustl'' to handle all *.wustl.edu subscribers. This
+ is useful, but remember that the SQL version supports only one
+ level.
+
+ An example:
+
+
+ domain:hash_lo:hash_hi:sublistname
+ edu:0:52:sub1@here.edu
+ com:0:26:sub2@there.net
+ com:27:52:sub3@some.com
+ :0:13:sub4@what.org
+ :14:39:sub5@what.org
+
+
+
+
+ As you can see, the entire ``edu'' domain is handled by
+ sub1@here.edu. The ``com'' domain is about evenly split between
+ sub2@there.net and sub3@some.com. Everything else is split so that
+ approximately 1/4 goes to sub4@what.org, 1/2 to sub5@what.org and
+ the rest falls through, i.e. is handled by the main list.
+
+ Why are there 2 sublists on the same host? This is in preparation
+ of adding a host. It easy to just move the entire sub5@what.org
+ list to a new host. All we have to do it to set up the new list,
+ copy over the subscribers, and change the name in the split table
+ entry.
+
+ To split the split the sub5@what.org load onto 2 lists requires a
+ little more work. First, create a dummy split table in a directory
+ ``temp'':
+
+ :14:26:new1@new.net
+ :27:39:new1@other.net
+
+
+
+
+ Next, split the subscribers of sub5@what.org into these 2 groups,
+ as detailed in the ezmlm-split(1) man page. Create the two new
+ lists, add the respective subscribers, and replace the
+ sub5@what.org line with the two lines above.
+
+ To add a totally new domain, e.g. jp:0:52:sub6@niko.jp requires
+ collection or subscribers from all lists that currently handle
+ these subscribers, (the ones with blank domain in the example), re-
+ splitting them, and adjusting the subscribers. Easiest here is to
+ just unsubscribe the sub6@niko.jp subscribers to be from the other
+ list with ezmlm-sub(1). Since that program will silently ignore
+ any addresses that are not on the respective list, it will work
+ fine.
+
+ +\bo
+
+ C\bCr\bre\bea\bat\bte\be t\bth\bhe\be s\bsu\bub\bbl\bli\bis\bst\bts\bs
+ Use ezmlmsubrc which sets up a minimal non-archived sublist with
+ bounce texts pointing to the main list:
+
+
+
+ % ezmlm-make -Cezmlmsubrc -3mainlocal -4mainhost \
+ DIR dot sub1local sub1host
+
+
+
+
+ +\bo
+
+ s\bsu\bub\bbs\bsc\bcr\bri\bib\bbe\be t\bth\bhe\be r\bre\bes\bsp\bpe\bec\bct\bti\biv\bve\be s\bsu\bub\bbl\bli\bis\bst\bts\bs t\bto\bo t\bth\bhe\be m\bma\bai\bin\bn l\bli\bis\bst\bt
+ If you forget, the sublist will not get any messages to
+ distribute. Add these addresses with ezmlm-sub(1) as subscribers
+ to the main list.
+
+ A strong point of this system is that it is relatively simple and that
+ only a fraction of the addresses are available to any given sublist.
+ Thus, compromised security at a sublist threatens only the addresses
+ and functions handled by that sublist.
+
+ As you can see, this works quite well, but it's not trivial to change
+ the setup. If you modify it while the list is running, some
+ subscribers may get duplicate messages or miss messages. Therefore,
+ you should disable deliveries to the main list before the final step
+ of the changes (removal of subscribers from old lists and adding new
+ lists as subscribers to the main list). For most lists, this should
+ work flawlessly, and some minimal planning and extra lines in
+ ``split'' can markedly facilitate future expansion.
+
+ Another weak point is the authentication of messages between list and
+ sublist. The requirements the sublist places on the message can be
+ easily faked. This allows injection of messages at the sublist level
+ as a way to circumvent moderation or other access control.
+
+ An associated disadvantage is that not even the main list has access
+ to all the addresses. Thus, SENDER checks for archive access
+ (relatively secure) and posts (relatively insecure) cannot directly be
+ used. Also, sublist cooperation is required to determine the number of
+ subscribers, or to access subscriber addresses for a purpose other
+ than distribution of list messages.
+ 1\b15\b5.\b. M\bMi\big\bgr\bra\bat\bti\bio\bon\bn t\bto\bo E\bEz\bzm\bml\blm\bm f\bfr\bro\bom\bm o\bot\bth\bhe\ber\br M\bMa\bai\bil\bli\bin\bng\bg L\bLi\bis\bst\bt M\bMa\ban\bna\bag\bge\ber\brs\bs.\b.
+
+ 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 command syntax will be
+ familiar to such users. Contributions to complete this sections are
+ welcome.
+
+
+ 1\b15\b5.\b.1\b1.\b. B\bBa\bas\bsi\bic\bc C\bCo\bon\bnc\bce\bep\bpt\bts\bs.\b.
+
+ Ezmlm is different from other mailing list managers in that it is
+ _\bl_\bi_\bs_\bt_\b-_\bc_\be_\bn_\bt_\br_\bi_\bc rather than _\bh_\bo_\bs_\bt_\b-_\bc_\be_\bn_\bt_\br_\bi_\bc. With a _\bl_\bi_\bs_\bt_\b-_\bc_\be_\bn_\bt_\br_\bi_\bc 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 D\bDI\bIR\bR/\b/m\bma\ban\bna\bag\bge\ber\br.
+
+ Other mailing list managers are _\bh_\bo_\bs_\bt_\b-_\bc_\be_\bn_\bt_\br_\bi_\bc, 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. [_\bN_\bo_\bt_\be_\b: 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 _\bh_\bo_\bs_\bt_\b-_\bc_\be_\bn_\bt_\br_\bi_\bc style mailing list manger is available.
+ This is based on the use of ezmlm-request(1) with the ``-f
+ c\bco\bon\bnf\bfi\big\bg_\b_f\bfi\bil\ble\be'' switch.
+
+
+ 1\b15\b5.\b.2\b2.\b. S\bSe\bet\btt\bti\bin\bng\bg u\bup\bp e\bez\bzm\bml\blm\bm t\bto\bo r\bre\bes\bsp\bpo\bon\bnd\bd t\bto\bo h\bho\bos\bst\bt-\b-c\bce\ben\bnt\btr\bri\bic\bc c\bco\bom\bmm\bma\ban\bnd\bds\bs.\b.
+
+ ezmlm-request(1) can be used a a ``majordomo/listserv-emulator''. You
+ can create the necessary accessory files manually. However, ezmlm-
+ idx>=0.32 contains ezmlmglrc(5) which makes is very easy for you:
+
+
+ % su
+ # su alias
+ # ezmlm-make -C/usr/local/bin/ezmlmglrc dir dot local host
+
+
+
+
+ where ``local'' may be e.g. ``majordomo''. Even easier is to set it up
+ under a virtual domain ``host'' controlled by a user ``user''. Just
+ put ``user'' in place of ``alias'' in the example.
+
+ 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
+ e\bez\bzd\bdo\bom\bmo\bo/\b/c\bch\bha\bar\brs\bse\bet\bt.
+
+ All that remains is to set up D\bDI\bIR\bR/\b/e\bez\bzd\bdo\bom\bmo\bo.\b.c\bcf\bf with information on the
+ lists (local and/or remote) that you want to make accessible via this
+ interface. Another script, ezmlm-glconf(1) can help you with this for
+ your local lists. To configure for all your lists:
+
+ ezmlm-glmake ~/ > ~/dir/ezdomo.cf
+
+
+
+
+ See man page for details. Alternatively, do it manually:
+
+ The D\bDI\bIR\bR/\b/e\bez\bzd\bdo\bom\bmo\bo.\b.c\bcf\bf 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 show a list in ``lists'', but not include it in a ``which'' search,
+ simply omit the ``listdir'' for that line:
+
+
+ list@host::description
+
+
+
+
+ For the ``which'' command to work, the D\bDI\bIR\bR/\b/, 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.
+
+
+ 1\b15\b5.\b.3\b3.\b. C\bCo\bom\bmm\bma\ban\bnd\bds\bs o\bof\bf o\bot\bth\bhe\ber\br m\bma\bai\bil\bli\bin\bng\bgl\bli\bis\bst\bt m\bma\ban\bna\bag\bge\ber\brs\bs r\bre\bec\bco\bog\bgn\bni\biz\bze\bed\bd b\bby\by e\bez\bzm\bml\blm\bm.\b.
+
+
+ 1\b15\b5.\b.3\b3.\b.1\b1.\b. L\bLi\bis\bst\btp\bpr\bro\boc\bc/\b/L\bLi\bis\bst\bts\bse\ber\brv\bv.\b.
+
+ 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. N\bNo\bot\bte\be:\b: e\bez\bzm\bml\blm\bm w\bwi\bil\bll\bl o\bon\bnl\bly\by r\bre\bes\bsp\bpo\bon\bnd\bd t\bto\bo o\bon\bne\be c\bco\bom\bmm\bma\ban\bnd\bd p\bpe\ber\br m\bme\bes\bss\bsa\bag\bge\be.\b.
+
+ s\bsy\byn\bnt\bta\bax\bx:\b: c\bco\bom\bmm\bma\ban\bnd\bd l\bli\bis\bst\btn\bna\bam\bme\be [\b[s\bsu\bub\bbs\bsc\bcr\bri\bib\bbe\ber\br@\b@h\bho\bos\bst\bt]\b]
+
+
+ S\bSu\bup\bpp\bpo\bor\brt\bte\bed\bd c\bco\bom\bmm\bma\ban\bnd\bds\bs
+ subscribe, sub, unsubscribe, unsub, list, help, review.
+
+ A\bAd\bdd\bdi\bit\bti\bio\bon\bna\bal\bl s\bsu\bup\bpp\bpo\bor\brt\bte\bed\bd c\bco\bom\bmm\bma\ban\bnd\bds\bs
+ 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.
+
+
+ 1\b15\b5.\b.3\b3.\b.2\b2.\b. M\bMa\baj\bjo\bor\brd\bdo\bom\bmo\bo.\b.
+
+ s\bsy\byn\bnt\bta\bax\bx:\b: c\bco\bom\bmm\bma\ban\bnd\bd l\bli\bis\bst\btn\bna\bam\bme\be [\b[s\bsu\bub\bbs\bsc\bcr\bri\bib\bbe\ber\br@\b@h\bho\bos\bst\bt]\b]
+
+
+ S\bSu\bup\bpp\bpo\bor\brt\bte\bed\bd c\bco\bom\bmm\bma\ban\bnd\bds\bs
+ lists, subscribe, unsubscribe, help, which, who.
+ A\bAd\bdd\bdi\bit\bti\bio\bon\bna\bal\bl s\bsu\bup\bpp\bpo\bor\brt\bte\bed\bd c\bco\bom\bmm\bma\ban\bnd\bds\bs
+ 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.
+
+
+ 1\b15\b5.\b.3\b3.\b.3\b3.\b. S\bSm\bma\bar\brt\btl\bli\bis\bst\bt.\b.
+
+ 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@host]
+
+
+
+
+ The body of the message is normally ignored. If the subject is empty,
+ the first body line that starts with a letter is interpreted.
+
+
+ S\bSu\bup\bpp\bpo\bor\brt\bte\bed\bd c\bco\bom\bmm\bma\ban\bnd\bds\bs
+ subscribe, unsubscribe.
+
+ A\bAd\bdd\bdi\bit\bti\bio\bon\bna\bal\bl S\bSu\bup\bpp\bpo\bor\brt\bte\bed\bd C\bCo\bom\bmm\bma\ban\bnd\bds\bs
+ All ezmlm user and ezmlm owner commands.
+
+
+ 1\b16\b6.\b. O\bOp\bpt\bti\bim\bmi\biz\bzi\bin\bng\bg l\bli\bis\bst\bt p\bpe\ber\brf\bfo\bor\brm\bma\ban\bnc\bce\be.\b.
+
+ 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.
+
+
+ 1\b16\b6.\b.1\b1.\b. C\bCr\bro\bon\bnd\bd-\b-g\bge\ben\bne\ber\bra\bat\bte\bed\bd d\bdi\big\bge\bes\bst\bts\bs f\bfo\bor\br b\bbe\bet\btt\bte\ber\br p\bpe\ber\brf\bfo\bor\brm\bma\ban\bnc\bce\be.\b.
+
+ With the default setup, ezmlm-tstdig(1) in D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br 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 crond(8) to execute ezmlm-get(1) directly, as
+ described elsewhere.
+
+
+ 1\b16\b6.\b.2\b2.\b. O\bOp\bpt\bti\bim\bmi\biz\bzi\bin\bng\bg e\bex\bxe\bec\bcu\but\bti\bio\bon\bn o\bof\bf e\bez\bzm\bml\blm\bm-\b-w\bwa\bar\brn\bn(\b(1\b1)\b).\b.
+
+ ezmlm-idx>=0.32 comes with much improved bounce handling. Modification
+ as described below should be considered only when you expect thousands
+ of bouncing addresses (virtually never). The description remains, for
+ users of ezmlm-0.53 or earlier versions of ezmlm-idx. For users of
+ ezmlm-0.53 alone, we recommend a patch (
+ <ftp://ftp.id.wustl.edu/pub/patches/ezmlm-return.diff> which fixes a
+ bug in ezmlm-0.53 bounce handling. The patch is superseded by ezmlm-
+ idx.
+
+ To redistribute the load of bounce warning and probe addresses to off-
+ peak hours, you may want to set up the list without ezmlm-warn(1) by
+ using the ezmlm-make ``-w'' switch, and instead execute ``ezmlm-warn
+ DIR'' via crond(8). You also need to run ``ezmlm-warn -d DIR'' for
+ digest bounces if your list is configured with digests. Normal ezmlm
+ list with ezmlm-idx>=0.32 will have an insignificant bounce load,
+ except if you bulk add addresses, e.g. from a MLM without bounce
+ handling. In the latter case, the load will be higher for the first
+ 2-4 weeks, then decrease drastically. If you feel you need to run
+ ezmlm-warn(1) from crond(8), you should seriously consider sublisting
+ your lists.
+
+ _\bN_\bo_\bt_\be_\b: the ezmlm-make(1) ``-w'' switch has a special meaning if used at
+ the same time as enabling SQL-support (``-6''; see man pages).
+
+
+ 1\b16\b6.\b.3\b3.\b. D\bDe\bec\bcr\bre\bea\bas\bsi\bin\bng\bg e\bez\bzm\bml\blm\bm-\b-w\bwa\bar\brn\bn t\bti\bim\bme\be o\bou\but\bt t\bto\bo i\bin\bnc\bcr\bre\bea\bas\bse\be p\bpe\ber\brf\bfo\bor\brm\bma\ban\bnc\bce\be.\b.
+
+ 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. 5 days 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.
+
+ 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. This is useful
+ to rapidly clean up a low quality address collection.
+
+
+ 1\b16\b6.\b.4\b4.\b. U\bUs\bse\be e\bez\bzm\bml\blm\bm w\bwi\bit\bth\bho\bou\but\bt e\bez\bzm\bml\blm\bm-\b-i\bid\bdx\bx f\bfo\bor\br m\bma\bax\bxi\bim\bmu\bum\bm p\bpe\ber\brf\bfo\bor\brm\bma\ban\bnc\bce\be.\b.
+
+ 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.
+
+ In bench marking, we have not found a significant difference in
+ performance between ezmlm-0.53 and ezmlm-0.53+ezmlm-idx-0.32 when
+ ezmlm-idx features are not used. Thus, a non-indexed list with ezmlm-
+ idx-0.32 performs the same as the corresponding ezmlm-0.53 list.
+ Adding an index adds the overhead of another safe write (the index
+ file). Use of other features adds very marginally to execution time.
+ For virtually all lists, the ezmlm execution time is negligible
+ compared to the resources needed by qmail to disseminate the message
+ to the subscribers.
+
+
+ 1\b16\b6.\b.5\b5.\b. N\bNo\bot\bt a\bar\brc\bch\bhi\biv\bvi\bin\bng\bg t\bto\bo m\bma\bax\bxi\bim\bmi\biz\bze\be p\bpe\ber\brf\bfo\bor\brm\bma\ban\bnc\bce\be.\b.
+
+ 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.
+
+
+ 1\b16\b6.\b.6\b6.\b. S\bSu\bub\bbl\bli\bis\bst\bts\bs t\bto\bo m\bma\bax\bxi\bim\bmi\biz\bze\be p\bpe\ber\brf\bfo\bor\brm\bma\ban\bnc\bce\be.\b.
+
+ 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).
+
+
+ 1\b17\b7.\b. M\bMi\bis\bsc\bce\bel\bll\bla\ban\bne\beo\bou\bus\bs.\b.
+
+
+ 1\b17\b7.\b.1\b1.\b. H\bHo\bow\bw d\bdo\bo I\bI q\bqu\bui\bic\bck\bkl\bly\by c\bch\bha\ban\bng\bge\be t\bth\bhe\be p\bpr\bro\bop\bpe\ber\brt\bti\bie\bes\bs o\bof\bf m\bmy\by l\bli\bis\bst\bt?\b?
+
+
+
+ ezmlm-make -+ [changed_switches] dir
+
+
+
+
+ ezmlm-make(1) stores configuration info in D\bDI\bIR\bR/\b/c\bco\bon\bnf\bfi\big\bg and uses that
+ info as the default when you use the ``-+'' switch. If the list was
+ created with a very old version or ezmlm-0.53 ezmlm-make(1) you have
+ to restate all arguments the first time you edit the list.
+
+ The ``-e'' switch works the same, without stickiness for switches.
+
+ A message arriving during reconfiguration may be handled incorrectly.
+ The prudent user will set the sticky bit on the home directory to
+ prevent delivery, then clear it after the list has been changed.
+
+
+ 1\b17\b7.\b.2\b2.\b. O\bOp\bpe\ben\bn a\bar\brc\bch\bhi\biv\bve\bed\bd l\bli\bis\bst\bt w\bwi\bit\bth\bh d\bda\bai\bil\bly\by d\bdi\big\bge\bes\bst\bts\bs.\b.
+
+ 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 D\bDI\bIR\bR/\b/d\bdi\big\bge\bes\bst\bt/\b/s\bsu\bub\bbs\bsc\bcr\bri\bib\bbe\ber\brs\bs/\b/,
+ i.e. the subscriber database with the base directory D\bDI\bIR\bR/\b/d\bdi\big\bge\bes\bst\bt/\b/.
+
+ +\bo See ``setting up a digest list'' on how to set up the lists.
+
+
+ 1\b17\b7.\b.3\b3.\b. V\bVa\bar\bri\bia\bat\bti\bio\bon\bns\bs i\bin\bn m\bmo\bod\bde\ber\bra\bat\bti\bio\bon\bn
+
+ 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 D\bDI\bIR\bR/\b/m\bmo\bod\bds\bsu\bub\bb or D\bDI\bIR\bR/\b/r\bre\bem\bmo\bot\bte\be (for remote admin and
+ subscription moderation - always the same db for both functions) or in
+ D\bDI\bIR\bR/\b/m\bmo\bod\bdp\bpo\bos\bst\bt for message moderation. You can point several lists to the
+ same moderator db, thus using the same moderators for several lists.
+ _\bN_\bO_\bT_\bE_\b: 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(5) 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'').
+
+
+ 1\b17\b7.\b.4\b4.\b. L\bLi\bis\bst\bts\bs t\bth\bha\bat\bt a\bal\bll\blo\bow\bw r\bre\bem\bmo\bot\bte\be a\bad\bdm\bmi\bin\bn,\b, b\bbu\but\bt n\bno\bot\bt u\bus\bse\ber\br i\bin\bni\bit\bti\bia\bat\bte\bed\bd s\bsu\bub\bbs\bsc\bcr\bri\bip\bp-\b-
+ t\bti\bio\bon\bn o\bor\br a\bar\brc\bch\bhi\biv\bve\be r\bre\bet\btr\bri\bie\bev\bva\bal\bl.\b.
+
+ Create a regular remote admin list, but remove D\bDI\bIR\bR/\b/p\bpu\bub\bbl\bli\bic\bc. 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'').
+
+
+ 1\b17\b7.\b.5\b5.\b. L\bLi\bis\bst\bts\bs t\bth\bha\bat\bt a\bal\bll\blo\bow\bw r\bre\bem\bmo\bot\bte\be a\bad\bdm\bmi\bin\bn,\b, u\bus\bse\ber\br a\bar\brc\bch\bhi\biv\bve\be r\bre\bet\btr\bri\bie\bev\bva\bal\bl,\b, b\bbu\but\bt n\bno\bot\bt
+ u\bus\bse\ber\br-\b-i\bin\bni\bit\bti\bia\bat\bte\bed\bd s\bsu\bub\bbs\bsc\bcr\bri\bip\bpt\bti\bio\bon\bn.\b.
+
+ Create a regular remote admin list, remove D\bDI\bIR\bR/\b/p\bpu\bub\bbl\bli\bic\bc, and add the
+ ``-p'' [public] switch to the ezmlm-get(1) command line in
+ D\bDI\bIR\bR/\b/m\bma\ban\bna\bag\bge\ber\br. This overrides the normal D\bDI\bIR\bR/\b/p\bpu\bub\bbl\bli\bic\bc 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 ~\b~/\b/.\b.q\bqm\bma\bai\bil\bl-\b-l\bli\bis\bst\btn\bna\bam\bme\be-\b-h\bhe\bel\blp\bp to
+ D\bDI\bIR\bR/\b/h\bhe\bel\blp\bp, and invoke a script that copies help info from there. See
+ ezmlm-check(1) for an example.
+
+
+ 1\b17\b7.\b.6\b6.\b. L\bLi\bis\bst\bts\bs t\bth\bha\bat\bt r\bre\bes\bst\btr\bri\bic\bct\bt a\bar\brc\bch\bhi\biv\bve\be r\bre\bet\btr\bri\bie\bev\bva\bal\bl t\bto\bo s\bsu\bub\bbs\bsc\bcr\bri\bib\bbe\ber\brs\bs.\b.
+
+ Use a standard list, but add the ezmlm-get(1) ``-s'' command line
+ switch in D\bDI\bIR\bR/\b/m\bma\ban\bna\bag\bge\ber\br. Only subscribers can receive archive excerpts.
+ Digests work as usual. This can be set up using the ezmlm-make(1)
+ ``-g'' switch.
+
+
+ 1\b17\b7.\b.7\b7.\b. L\bLi\bis\bst\bts\bs t\bth\bha\bat\bt d\bdo\bo n\bno\bot\bt a\bal\bll\blo\bow\bw a\bar\brc\bch\bhi\biv\bve\be r\bre\bet\btr\bri\bie\bev\bva\bal\bl a\bat\bt a\bal\bll\bl.\b.
+
+ Use a standard list, but add the ``-C'' switch to both the ezmlm-
+ get(1) and ezmlm-manage(1) command lines in D\bDI\bIR\bR/\b/m\bma\ban\bna\bag\bge\ber\br. No archive
+ retrieval commands will be honored. Digest can be created as usual
+ (See ``Restricting archive retrieval'').
+
+
+ 1\b17\b7.\b.8\b8.\b. L\bLi\bis\bst\bts\bs t\bth\bha\bat\bt d\bdo\bo n\bno\bot\bt a\bal\bll\blo\bow\bw a\bar\brc\bch\bhi\biv\bve\be r\bre\bet\btr\bri\bie\bev\bva\bal\bl a\ban\bnd\bd d\bdo\bo n\bno\bot\bt a\bal\bll\blo\bow\bw
+ d\bdi\big\bge\bes\bst\bt t\btr\bri\big\bgg\bge\ber\bri\bin\bng\bg p\bpe\ber\br m\bma\bai\bil\bl.\b.
+
+ For maximal archive security, set up a normal indexed and archived
+ list, then remove the ezmlm-get(1) line from D\bDI\bIR\bR/\b/m\bma\ban\bna\bag\bge\ber\br 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.
+
+
+ 1\b17\b7.\b.9\b9.\b. L\bLi\bis\bst\bts\bs t\bth\bha\bat\bt a\bal\bll\blo\bow\bw a\bar\brc\bch\bhi\biv\bve\be r\bre\bet\btr\bri\bie\bev\bva\bal\bl o\bon\bnl\bly\by t\bto\bo m\bmo\bod\bde\ber\bra\bat\bto\bor\brs\bs,\b, b\bbu\but\bt
+ a\bal\bll\blo\bow\bw u\bus\bse\ber\br-\b-i\bin\bni\bit\bti\bia\bat\bte\bed\bd s\bsu\bub\bbs\bsc\bcr\bri\bip\bpt\bti\bio\bon\bn.\b.
+
+ Create a normal remote admin (+ subscription moderated) list, and add
+ the ``-P'' (not public) switch to the ezmlm-get(1) command line in
+ D\bDI\bIR\bR/\b/m\bma\ban\bna\bag\bge\ber\br. Subscription will not be affected, but ezmlm-get(1) will
+ send archive excerpts only to moderators. Digests are unaffected.
+
+
+ 1\b17\b7.\b.1\b10\b0.\b. L\bLi\bis\bst\bts\bs t\bth\bha\bat\bt d\bdo\bo n\bno\bot\bt r\bre\beq\bqu\bui\bir\bre\be u\bus\bse\ber\br c\bco\bon\bnf\bfi\bir\brm\bma\bat\bti\bio\bon\bn f\bfo\bor\br (\b(u\bun\bn)\b)s\bsu\bub\bbs\bsc\bcr\bri\bip\bp-\b-
+ t\bti\bio\bon\bn.\b.
+
+
+ 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.
+
+
+ 1\b17\b7.\b.1\b11\b1.\b. A\bAn\bnn\bno\bou\bun\bnc\bce\bem\bme\ben\bnt\bt l\bli\bis\bst\bts\bs f\bfo\bor\br a\ba s\bsm\bma\bal\bll\bl s\bse\bet\bt o\bof\bf t\btr\bru\bus\bst\bte\bed\bd p\bpo\bos\bst\bte\ber\brs\bs
+
+ Set up the list with ezmlm-make ``-om'' and add the ``trusted E-mail
+ addresses'' to D\bDI\bIR\bR/\b/m\bmo\bod\bd/\b/ 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.
+
+
+ 1\b17\b7.\b.1\b12\b2.\b. A\bAn\bnn\bno\bou\bun\bnc\bce\bem\bme\ben\bnt\bt l\bli\bis\bst\bts\bs a\bal\bll\blo\bow\bwi\bin\bng\bg m\bmo\bod\bde\ber\bra\bat\bte\bed\bd p\bpo\bos\bst\bts\bs f\bfr\bro\bom\bm a\ban\bny\byo\bon\bne\be.\b.
+
+ 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-make ``-m'' 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 D\bDI\bIR\bR/\b/m\bmo\bod\bdp\bpo\bos\bst\bt (needs leading
+ ``/''), and add the post moderator(s) to D\bDI\bIR\bR/\b/m\bmo\bod\bd/\b/ using ezmlm-sub(1)
+ as shown above.
+
+
+ 1\b17\b7.\b.1\b13\b3.\b. A\bAn\bnn\bno\bou\bun\bnc\bce\bem\bme\ben\bnt\bt l\bli\bis\bst\bts\bs w\bwi\bit\bth\bh l\ble\bes\bss\bs s\bse\bec\bcu\bur\bri\bit\bty\by a\ban\bnd\bd m\bmo\bor\bre\be c\bco\bon\bnv\bve\ben\bni\bie\ben\bnc\bce\be.\b.
+
+ 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 D\bDI\bIR\bR/\b/m\bmo\bod\bdp\bpo\bos\bst\bt exists,
+ ezmlm-store(1) will send out other messages for moderation. To bounce
+ such messages, create D\bDI\bIR\bR/\b/m\bmo\bod\bdp\bpo\bos\bst\bt, 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.
+
+
+ 1\b18\b8.\b. E\bEz\bzm\bml\blm\bm-\b-i\bid\bdx\bx c\bco\bom\bmp\bpi\bil\ble\be t\bti\bim\bme\be o\bop\bpt\bti\bio\bon\bns\bs.\b.
+
+
+ 1\b18\b8.\b.1\b1.\b. L\bLo\boc\bca\bat\bti\bio\bon\bn o\bof\bf b\bbi\bin\bna\bar\bri\bie\bes\bs.\b.
+
+ This is configured via c\bco\bon\bnf\bf-\b-b\bbi\bin\bn as for other ezmlm programs. The
+ default is /\b/u\bus\bsr\br/\b/l\blo\boc\bca\bal\bl/\b/b\bbi\bin\bn/\b/e\bez\bzm\bml\blm\bm.
+
+
+ 1\b18\b8.\b.2\b2.\b. L\bLo\boc\bca\bat\bti\bio\bon\bn o\bof\bf m\bma\ban\bn p\bpa\bag\bge\bes\bs.\b.
+
+ This is configured via c\bco\bon\bnf\bf-\b-m\bma\ban\bn as for other ezmlm programs. The
+ default is /\b/u\bus\bsr\br/\b/l\blo\boc\bca\bal\bl/\b/m\bma\ban\bn.
+
+
+ 1\b18\b8.\b.3\b3.\b. B\bBa\bas\bse\be d\bdi\bir\bre\bec\bct\bto\bor\bry\by o\bof\bf q\bqm\bma\bai\bil\bl-\b-i\bin\bns\bst\bta\bal\bll\bla\bat\bti\bio\bon\bn.\b.
+
+ This is configured via c\bco\bon\bnf\bf-\b-q\bqm\bma\bai\bil\bl as for other ezmlm programs. The
+ default is /\b/v\bva\bar\br/\b/q\bqm\bma\bai\bil\bl.
+
+
+ 1\b18\b8.\b.4\b4.\b. S\bSh\bho\bor\brt\bt h\bhe\bea\bad\bde\ber\br t\bte\bex\bxt\bts\bs,\b, e\bet\btc\bc.\b.
+
+ Ezmlm-idx text (short lines, such as ``Administrivia'' for digests),
+ command names, etc, are defined in i\bid\bdx\bx.\b.h\bh, used at compile time. You
+ can change them by changing the defines in this file.
+
+
+ 1\b18\b8.\b.5\b5.\b. A\bAr\brb\bbi\bit\btr\bra\bar\bry\by l\bli\bim\bmi\bit\bts\bs.\b.
+
+ i\bid\bdx\bx.\b.h\bh contains defines for some ezmlm-idx arbitrary limits, such as
+ the maximum number of messages per ``-get'' request. They can be
+ changed here.
+
+
+ 1\b18\b8.\b.6\b6.\b. C\bCo\bom\bmm\bma\ban\bnd\bd n\bna\bam\bme\bes\bs.\b.
+
+ There is support for one alias per user command for
+ internationalization. (See ``Multiple language support''.)
+
+
+ 1\b18\b8.\b.7\b7.\b. E\bEr\brr\bro\bor\br m\bme\bes\bss\bsa\bag\bge\bes\bs.\b.
+
+ All ezmlm-idx error messages are defines in e\ber\brr\brt\btx\bxt\bt.\b.h\bh, 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).
+
+
+
+ 1\b18\b8.\b.8\b8.\b. P\bPa\bat\bth\bhs\bs a\ban\bnd\bd o\bot\bth\bhe\ber\br o\bod\bdd\bd c\bco\bon\bnf\bfi\big\bgu\bur\bra\bat\bti\bio\bon\bn i\bit\bte\bem\bms\bs.\b.
+
+ idx.h also has defines for /\b/e\bet\btc\bc/\b/e\bez\bzm\bml\blm\bmr\brc\bc, 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.
+
+
+ 1\b19\b9.\b. M\bMu\bul\blt\bti\bip\bpl\ble\be l\bla\ban\bng\bgu\bua\bag\bge\be s\bsu\bup\bpp\bpo\bor\brt\bt.\b.
+
+
+ 1\b19\b9.\b.1\b1.\b. C\bCo\bom\bmm\bma\ban\bnd\bd n\bna\bam\bme\bes\bs.\b.
+
+ 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 un-define 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''.
+
+
+ 1\b19\b9.\b.2\b2.\b. T\bTe\bex\bxt\bt f\bfi\bil\ble\bes\bs.\b.
+
+ Most ezmlm responses are made from text files in D\bDI\bIR\bR/\b/t\bte\bex\bxt\bt/\b/. These are
+ created from the template file ``ezmlmrc''. Thanks to Frank Denis, and
+ Masashi Fujita, Wanderlei Antonio Cavassin, Sergiusz Pawlowicz, Frank
+ Tegtmeyer, Torben Fjerdingstad, Jan Kasprzak, and Sebastian Andersson,
+ French, Japanese, Portuguese (var. Brazil), Polish, German, Danish,
+ Czech, and Swedish versions are available. Just:
+
+
+ % make jp
+
+
+
+
+ before
+
+
+ # make setup
+
+
+
+
+ or just copy e\bez\bzm\bml\blm\bmr\brc\bc.\b.j\bjp\bp to /\b/e\bet\btc\bc/\b/e\bez\bzm\bml\blm\bmr\brc\bc, where it will override the
+ copy installed in the ezmlm binary directory. For rpm packages, the
+ en_US version is installed, but the other versions are available in
+ the /\b/u\bus\bsr\br/\b/d\bdo\boc\bc/\b/ hierarchy.
+
+ If you have made an e\bez\bzm\bml\blm\bmr\brc\bc(\b(5\b5)\b) 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 e\bez\bzm\bml\blm\bmr\brc\bc 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
+ i\bid\bdx\bx.\b.h\bh 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 e\ber\brr\brt\btx\bxt\bt.\b.h\bh.
+
+
+ 1\b19\b9.\b.3\b3.\b. M\bMu\bul\blt\bti\bi-\b-b\bby\byt\bte\be c\bch\bha\bar\bra\bac\bct\bte\ber\br c\bco\bod\bde\be s\bsu\bup\bpp\bpo\bor\brt\bt.\b.
+
+ 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 _\bp_\be_\br
+ _\bs_\be 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(5).
+
+
+ 2\b20\b0.\b. S\bSu\bub\bbs\bsc\bcr\bri\bib\bbe\ber\br n\bno\bot\bti\bif\bfi\bic\bca\bat\bti\bio\bon\bn o\bof\bf m\bmo\bod\bde\ber\bra\bat\bti\bio\bon\bn e\bev\bve\ben\bnt\bts\bs.\b.
+
+
+ 2\b20\b0.\b.1\b1.\b. G\bGe\ben\bne\ber\bra\bal\bl o\bop\bpi\bin\bni\bio\bon\bns\bs.\b.
+
+ This is a collection of the authors opinions and an explanation of
+ ezmlm-idx moderation design, which you may or may not agree with.
+
+
+ 2\b20\b0.\b.2\b2.\b. U\bUs\bse\ber\brs\bs s\bsh\bho\bou\bul\bld\bd k\bkn\bno\bow\bw t\bth\bha\bat\bt t\bth\bhe\be l\bli\bis\bst\bt i\bis\bs s\bsu\bub\bbs\bsc\bcr\bri\bip\bpt\bti\bio\bon\bn m\bmo\bod\bde\ber\bra\bat\bte\bed\bd.\b.
+
+ 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 D\bDI\bIR\bR/\b/t\bte\bex\bxt\bt/\b/ files.
+
+
+ 2\b20\b0.\b.3\b3.\b. S\bSu\bub\bbs\bsc\bcr\bri\bib\bbe\ber\brs\bs s\bsh\bho\bou\bul\bld\bd k\bkn\bno\bow\bw t\bth\bha\bat\bt p\bpo\bos\bst\bts\bs a\bar\bre\be m\bmo\bod\bde\ber\bra\bat\bte\bed\bd.\b.
+
+ 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.
+
+
+ 2\b20\b0.\b.4\b4.\b. S\bSe\ben\bnd\bde\ber\brs\bs o\bof\bf p\bpo\bos\bst\bts\bs s\bsh\bho\bou\bul\bld\bd b\bbe\be n\bno\bot\bti\bif\bfi\bie\bed\bd o\bof\bf r\bre\bej\bje\bec\bct\bti\bio\bon\bns\bs.\b.
+
+ 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 D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br and D\bDI\bIR\bR/\b/m\bmo\bod\bde\ber\bra\bat\bto\bor\br). 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.
+
+
+ 2\b21\b1.\b. E\bEz\bzm\bml\blm\bm-\b-i\bid\bdx\bx s\bse\bec\bcu\bur\bri\bit\bty\by.\b.
+
+
+ 2\b21\b1.\b.1\b1.\b. G\bGe\ben\bne\ber\bra\bal\bl a\bas\bss\bsu\bum\bmp\bpt\bti\bio\bon\bns\bs.\b.
+
+ 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.
+
+
+ 2\b21\b1.\b.2\b2.\b. S\bSE\bEN\bND\bDE\bER\bR m\bma\ban\bni\bip\bpu\bul\bla\bat\bti\bio\bon\bn.\b.
+
+ We assume that the cost of manipulating/falsifying the SENDER address
+ of a message is zero. Thus, any mechanism relying on SENDER alone is
+ 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.
+
+
+ 2\b21\b1.\b.3\b3.\b. e\bez\bzm\bml\blm\bm c\bco\boo\bok\bki\bie\bes\bs.\b.
+
+ 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.
+
+
+ 2\b21\b1.\b.4\b4.\b. L\bLi\bis\bst\bts\bs w\bwi\bit\bth\bho\bou\but\bt r\bre\bem\bmo\bot\bte\be a\bad\bdm\bmi\bin\bn/\b/s\bsu\bub\bbs\bsc\bcr\bri\bip\bpt\bti\bio\bon\bn m\bmo\bod\bde\ber\bra\bat\bti\bio\bon\bn.\b.
+
+ 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).
+
+
+ 2\b21\b1.\b.5\b5.\b. M\bMe\bes\bss\bsa\bag\bge\be m\bmo\bod\bde\ber\bra\bat\bti\bio\bon\bn.\b.
+
+ 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.
+
+
+ 2\b21\b1.\b.6\b6.\b. S\bSu\bub\bbs\bsc\bcr\bri\bip\bpt\bti\bio\bon\bn m\bmo\bod\bde\ber\bra\bat\bti\bio\bon\bn.\b.
+
+ 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.
+
+
+ 2\b21\b1.\b.7\b7.\b. R\bRe\bem\bmo\bot\bte\be a\bad\bdm\bmi\bin\bni\bis\bst\btr\bra\bat\bti\bio\bon\bn.\b.
+
+ 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.
+
+
+ 2\b21\b1.\b.8\b8.\b. R\bRe\bem\bmo\bot\bte\be e\bed\bdi\bit\bti\bin\bng\bg o\bof\bf e\bez\bzm\bml\blm\bm t\bte\bex\bxt\bt f\bfi\bil\ble\bes\bs.\b.
+
+ ezmlm-manage(1) can allow remote administrators to edit files in
+ D\bDI\bIR\bR/\b/t\bte\bex\bxt\bt. 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 D\bDI\bIR\bR/\b/t\bte\bex\bxt\bt
+ 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 i\bid\bdx\bx.\b.h\bh)) 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.
+
+
+ 2\b21\b1.\b.9\b9.\b. D\bDi\big\bge\bes\bst\bt g\bge\ben\bne\ber\bra\bat\bti\bio\bon\bn a\ban\bnd\bd a\bar\brc\bch\bhi\biv\bve\be r\bre\bet\btr\bri\bie\bev\bva\bal\bl.\b.
+
+ 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 D\bDI\bIR\bR/\b/m\bma\ban\bna\bag\bge\ber\br 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 D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br 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
+ D\bDI\bIR\bR/\b/p\bpu\bub\bbl\bli\bic\bc. 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 (D\bDI\bIR\bR/\b/t\bte\bex\bxt\bt/\b/m\bmo\bod\bd-\b-h\bhe\bel\blp\bp) 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).
+
+
+ 2\b21\b1.\b.1\b10\b0.\b. C\bCo\bon\bnv\bve\ben\bni\bie\ben\bnc\bce\be f\bfo\bor\br s\bse\bec\bcu\bur\bri\bit\bty\by:\b: t\bth\bhe\be e\bez\bzm\bml\blm\bm-\b-m\bma\ban\bna\bag\bge\be `\b``\b`-\b-S\bS'\b''\b' a\ban\bnd\bd `\b``\b`-\b-U\bU'\b''\b'
+ s\bsw\bwi\bit\btc\bch\bhe\bes\bs.\b.
+
+ 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 (D\bDI\bIR\bR/\b/r\bre\bem\bmo\bot\bte\be 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.
+
+
+ 2\b21\b1.\b.1\b11\b1.\b. D\bDe\ben\bni\bia\bal\bl o\bof\bf s\bse\ber\brv\bvi\bic\bce\be.\b.
+
+ 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 D\bDI\bIR\bR/\b/p\bpu\bub\bbl\bli\bic\bc, 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 from D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br as in the default setup with the
+ ezmlm-make(1) ``-d'' switch.
+
+
+ 2\b21\b1.\b.1\b12\b2.\b. M\bMo\bod\bde\ber\bra\bat\bto\bor\br a\ban\bno\bon\bny\bym\bmi\bit\bty\by.\b.
+
+ 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 e\bez\bzm\bml\blm\bm-\b-s\bst\bto\bor\bre\be.\b.c\bc.
+
+ 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 D\bDI\bIR\bR/\b/m\bmo\bod\bdt\bti\bim\bme\be - and the parameters are likewise
+ configurable at compile time via i\bid\bdx\bx.\b.h\bh) 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.
+ 2\b21\b1.\b.1\b13\b3.\b. C\bCo\bon\bnf\bfi\bid\bde\ben\bnt\bti\bia\bal\bli\bit\bty\by o\bof\bf s\bsu\bub\bbs\bsc\bcr\bri\bib\bbe\ber\br E\bE-\b-m\bma\bai\bil\bl a\bad\bdd\bdr\bre\bes\bss\bse\bes\bs.\b.
+
+ 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.
+
+
+ 2\b21\b1.\b.1\b14\b4.\b. H\bHe\bel\blp\bp m\bme\bes\bss\bsa\bag\bge\be f\bfo\bor\br m\bmo\bod\bde\ber\bra\bat\bto\bor\brs\bs.\b.
+
+ ezmlm-manage sends D\bDI\bIR\bR/\b/t\bte\bex\bxt\bt/\b/m\bmo\bod\bd-\b-h\bhe\bel\blp\bp, rather than D\bDI\bIR\bR/\b/t\bte\bex\bxt\bt/\b/h\bhe\bel\blp\bp in
+ reply to messages to list-help@host if the target address is a
+ moderator. D\bDI\bIR\bR/\b/t\bte\bex\bxt\bt/\b/m\bmo\bod\bd-\b-h\bhe\bel\blp\bp should not contain secrets or other
+ confidential information.
+
+
+ 2\b21\b1.\b.1\b15\b5.\b. S\bSu\bub\bbl\bli\bis\bst\bts\bs.\b.
+
+ ezmlm sublists require that the message envelope sender is the main
+ list, and that the message has a ``Mailing-List:'' header. Both are
+ easy to fake, allowing an attacker to inject messages at the sublist
+ level. Other than the possible ramifications of only a subset of
+ subscribers seeing the message, this is of no concern for open lists.
+ For a ``subscriber-only'' list based on SENDER checks, it is no harder
+ to set SENDER to the address of a subscriber than to fake the headers
+ required by the sublist. However, for a moderated list the mainlist to
+ sublist communication becomes the weakest link. Sublists using a SQL
+ database also use better authentication in this step (see ``SQL-
+ enabled ezmlm lists'').
+
+ A sublist user can unsubscribe a normal ezmlm sublist from the main
+ list. To guard against this, you need to prevent propagation of
+ unsubscribe confirm requests by the sublist. Easiest is to add a line
+ to D\bDI\bIR\bR/\b/e\bed\bdi\bit\bto\bor\br before the ezmlm-send(1) line:
+
+
+ |grep -i '^Subject: CONFIRM' >/dev/null 2>&1 && exit 99; exit 0
+
+
+
+
+ Another option would be to take advantage of the fact that D\bDI\bIR\bR/\b/h\bhe\bea\bad\bde\ber\br-\b-
+ a\bad\bdd\bd headers at the main list are added to normal messages, but not to
+ administrative messages. Thus, one could discard messages that lack
+ the default ``Precedence: bulk'' header:
+
+
+ |grep -i '^Precedence: bulk' >/dev/null 2>&1 || exit 99; exit 0
+
+
+
+
+ For lists with SQL-support, users cannot unsubscribe sublists (see
+ ``SQL-enabled ezmlm lists'').
+
+ Break-in at a sublist host for normal ezmlm lists leads to
+ loss/compromise of the addresses handled by the sublist. For MySQL-
+ enabled lists, the sublist access credentials give DELETE and SELECT
+ access to all addresses serviced by the list. Thus, a successful
+ sublist attacker can completely disable the list. The MySQL log (if
+ used) will reveal from which host the attack was done. Although the
+ potential damage to a SQL-enabled list is greater, the results are of
+ the same order of magnitude. The risk in minimized by keeping control
+ over all sublist hosts. A successful sublist attacker cannot normally
+ add addresses, since the sublist users by default are set up without
+ INSERT privileges to the address database.
+
+
+ 2\b21\b1.\b.1\b16\b6.\b. S\bSQ\bQL\bL d\bda\bat\bta\bab\bba\bas\bse\bes\bs.\b.
+
+ For SQL-enabled lists, the database contains all list information.
+ Subversion of your database server allows an attacker to add/remove
+ addresses at will. This is also true for normal ezmlm lists. In
+ addition, modification of the ``*_name'', ``*_cookie'', and ``*_mlog''
+ tables can cause the list to misbehave in a manner that doesn't
+ immediately suggest a security breach. Keep your ezmlm list and
+ database servers secure.
+
+
+ 2\b21\b1.\b.1\b17\b7.\b. R\bRe\bep\bpo\bor\brt\bti\bin\bng\bg s\bse\bec\bcu\bur\bri\bit\bty\by p\bpr\bro\bob\bbl\ble\bem\bms\bs.\b.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
~mdw / ezmlm / commitdiff