X-Git-Url: https://git.distorted.org.uk/~mdw/ezmlm/blobdiff_plain/5b62e993b0af39700031c2875d7f6654e6a02850..f8beb284087c279acfb30506f5bb32baa4949b44:/FAQ.idx diff --git a/FAQ.idx b/FAQ.idx new file mode 100644 index 0000000..38a46eb --- /dev/null +++ b/FAQ.idx @@ -0,0 +1,6072 @@ + 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. + + + ______________________________________________________________________ + + 11.. GGeenneerraall IInnffoorrmmaattiioonn + + + 11..11.. AAcckknnoowwlleeddggeemmeennttss + + Many ezmlm users have contributed to improvements in ezmlm-idx. These + are listed in the RREEAADDMMEE..iiddxx file in the ezmlm-idx distribution. + Others have through questions and suggestions inspired parts in this + FAQ, or pointed out errors or omissions. Thanks! Direct contributions + are attributed to the respective authors in the text. Thanks again! + + + 11..22.. WWhhaatt iiss tthhiiss ddooccuummeenntt?? + + This FAQ contains answers to many questions that arise while + installing ezmlm, ezmlm-idx, and while setting up and managing ezmlm + mailing lists. 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 _H_O_W_T_O form. Finally, + there are sections on information philosophy for moderated lists and + on security aspects on ezmlm lists. + + This is an evolving document. If you find any errors, or wish to + comment, please do so to the authors. This FAQ is currently aimed at + system administrators and knowledgeable users, and heavily weighted + towards questions specific to the ezmlm-idx add-on. + + If you have problems with the ezmlm-idx package, please start by + reading the ``man'' pages which come with each program, then this + document and other ezmlm documentation which is identified here. If + you have exhausted these resources, try the ezmlm and qmail mailing + lists and their respective mailing list archives. If you have solved a + problem not in the documentation, write it up as a proposed section of + a FAQ and send it to the authors. This way, it can be added to the + next version of this FAQ. + + + 11..33.. TTeerrmmiinnoollooggyy + + This document uses a number of terms. Here are the meanings ascribed + to them by the authors. + + DDIIRR + The base directory of the list. + + + SSEENNDDEERR + The envelope sender of the message, as passed to ezmlm by qmail + via the $SENDER environment variable. + + + LLOOCCAALL + The local part of the envelope recipient. For list-get-1@host, + it is usually _l_i_s_t_-_g_e_t_-_1. If host is a virtual domain, + controlled by _u_s_e_r_-_s_u_b, then local would be _u_s_e_r_-_s_u_b_-_l_i_s_t_-_g_e_t_-_1. + + + mmooddddiirr + Base directory for moderators. Moderator E-mail addresses are + stored in a hashed database in mmooddddiirr//ssuubbssccrriibbeerrss//. By default, + ``moddir'' is DDIIRR//mmoodd//. + + To add or remove moderators: + + + % ezmlm-sub DIR/moddir moderator@host.domain + % ezmlm-unsub DIR/moddir moderator@host.domain + + + + + + ddoottddiirr + + The second argument of ezmlm-make is the main .qmail file for + the list. dotdir is the directory in which this ``dot file'' + resides, i.e. the directory part of the ``dot'' argument. This + is usually the home directory of the user controlling the list + (but NOT necessarily of the one creating the list). Thus, _d_o_t_d_i_r + is ~~aalliiaass// if ``root'' creates a list: + + + # ezmlm-make ~alias/list ~alias/.qmail-list ... + + + + + _d_o_t_d_i_r is where the ..eezzmmllmmrrcc file is expected when the ezmlm- + make(1) ``-c'' switch is used (see ``Customizing ezmlm-make opera- + tion''). + + + eezzmmllmm bbiinnaarryy ddiirreeccttoorryy + The directory where the ezmlm-binaries are normally stored, as + defined at compile time in ccoonnff--bbiinn. This is compiled into the + programs and does not change just because you have moved the + program. + + + eezzmmllmm--ggeett((11)) + This is a reference to the ezmlm-get.1 man page. Access it with + one of the following: + + + % man ezmlm-get + % man 1 ezmlm-get + + + + + or if you have not yet installed ezmlm-idx (replace ``xxx'' with + the version number): + + + % cd ezmlm-idx-0.xxx + % man ./ezmlm-get.1 + + + + bbaasseeddiirr + The list directory when referencing the list subscriber address + database. For E-mail addresses stored in a set of files within + DDIIRR//ssuubbssccrriibbeerrss//, the ``basedir'' is ``DIR''. + + + aaddddrreessss ddaattaabbaassee + A collection of E-mail addresses stored in a set of files within + the ``subscribers'' subdirectory of the basedir, + DDIIRR//ssuubbssccrriibbeerrss//. + + + mmeessssaaggee mmooddeerraattoorr + An address to which moderation requests for posts to the list + are sent. The moderation requests are formatted with + ``From:''-``reject'' and a ``To:''-``accept'' default headers + for moderator replies. A reply to the ``reject'' address leads + to the rejection of the post. A reply to the ``accept'' address + leads to the acceptance of the post. Any E-mail address can be a + moderator E-mail address. Any number of moderator E-mail + addresses can be used. If a post is sent from a moderator E-mail + address, the moderation request is sent to that E-mail address + only. If a post is sent from an E-mail address that is not a + moderator, a moderation request is sent to all moderators. + + The first reply to the moderation request determines the fate of + the message. Further requests for the action already taken are + silently ignored, while a request for the contrary action + results in an error message stating the actual fate of the + message. Thus, if you want to ``accept'' the message and it has + already been accepted, you receive no reply, but if you attempt + to ``reject'' it, you will receive an error message stating that + the message already has been accepted. + + Most lists are not message moderated. If they are, the owner is + usually a ``message moderator'', sometimes together with a few + other trusted users. + + For an announcement list, it is common to make all the + ``official announcers'' ``message moderators''. This way, they + can post securely and ``accept'' their own posts, while posts + from other users will be sent to this set of ``official + announcers'' for approval. + + + ssuubbssccrriippttiioonn mmooddeerraattoorr + An E-mail address where subscription moderation requests are + sent. A subscription moderation request is sent after a user has + confirmed her intention to subscribe. The subscription + moderation request is sent to all moderators. As soon as a reply + to this message is received, the user is subscribed and + notified. Any E-mail address can be a subscription moderator and + any number of subscription moderators can be used. + + Unsubscribe requests are never moderated (except when the ezmlm- + manage(1) ``-U'' flag is used and the sender attempts to remove + an address other than the one s/he is sending from). It is hard + to imagine a legitimate mailing list that would want to prevent + unsubscriptions. + + + rreemmoottee aaddmmiinniissttrraattoorr + When a remote administrator subscribes or unsubscribes a list + member, the ``confirm'' request is sent back to the remote + administrator, rather than to the subscriber's E-mail address. + This allows the remote administrator to (un)subscribe any list + member without the cooperation of the subscriber at that + address. Any E-mail address can be a remote administrator and + any number of E-mail addresses can be remote administrators. + + The set of E-mail addresses that are ``remote administrators'' + and ``subscription moderators'' are always the same. This set of + E-mail addresses can be ``remote administrators'', + ``subscription moderators'' or both. + + For most lists, the owner would be the ``remote administrator'', + if s/he wishes to moderate messages, the owner would be the + ``message moderator'' and if s/he wishes to moderate + subscriptions the owner would also be the ``subscription + moderator''. + + The list's ``message moderator(s)'' can be the same, but can + also be set up to be completely different. + + + CChhaannggiinngg lliisstt ````oowwnneerrsshhiipp'''' + Within this FAQ there are references to the need to check or + change the list ``ownership.'' This is not a reference to the + individual user who is the ``list-owner'', but a reference to + the ownership of the files by your operating system which make + up the list and reside in DDIIRR//. + + To change the ownership of DDIIRR// and everything within: + + + % chown -R user DIR + % chgrp -R group DIR + + + + + Depending on your system/shell, it may be possible to combine these + commands into either: + + + % chown -R user.group DIR + % chown -R user:group DIR + + + + + + 11..44.. WWhhaatt iiss tthhee ddiiffffeerreennccee bbeettwweeeenn eezzmmllmm aanndd eezzmmllmm--iiddxx?? + + 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. + + + 11..55.. WWhheerree ccaann II ggeett aallll ooff tthhee eezzmmllmm--rreellaatteedd pprrooggrraammss?? + + We have now registered ezmlm.org to make access to ezmlm-idx and + related programs/documentation easier. www.ezmlm.org is currently an + alias for Fred B. Ringel's www.rivertown.net/~ezmlm/ and ftp.ezmlm.org + an alias for Fred Lindberg's ftp.id.wustl.edu. + + + DDaann JJ.. BBeerrnnsstteeiinn''ss eezzmmllmm--00..5533 + + +o + + +o + + +o + + +o + + +o + + +o + + +o + + +o + + TThhee llaatteesstt vveerrssiioonn ooff eezzmmllmm--iiddxx + ezmlm-idx releases are numbered ``ezmlm-idx-0.xy[z]''. Versions + with the same ``x'' are backwards compatible. A change in ``x'' + signifies major changes, some of which _m_a_y require list changes + (see 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. + + + +o + + +o ftp + mirror in Austria. + + +o http + access to the same mirror. + + +o ftp + mirror in Japan. + + eezzmmllmmrrcc((55)) ffiilleess ffoorr ddiiffffeerreenntt llaanngguuaaggeess + 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. + + + +o + + +o + + +o + + +o + + eezzmmllmm--iissssuubb--00..0055 + + +o . 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. + + +o Also via mirrors mentioned above. + + + RRPPMMss aanndd SSRRPPMMSS ooff qqmmaaiill,, eezzmmllmm aanndd eezzmmllmm--iiddxx + + +o + + +o + + + 11..66.. WWhheerree ccaann II ffiinndd ddooccuummeennttaattiioonn ffoorr eezzmmllmm aanndd ppaattcchheess?? + + + mmaann ppaaggeess + All ezmlm component programs come with their own man pages. + Thus, for info on _e_z_m_l_m_-_s_e_n_d, type: + + + + % man ezmlm-send + + + + + or if you have unpacked ezmlm, but not made it or installed it: + + + + % cd ezmlm-0.53 + % man ./ezmlm-send.1 + + + + + + eezzmmllmm((55)) + General info on ezmlm and list directories is in eezzmmllmm..55: + + + + % man ezmlm + + + + + or + + + + % cd ezmlm-0.53 + % man ./ezmlm.5 + + + + + _N_O_T_E_: Installation of the ezmlm-idx package updates some existing + man pages to reflect changes made by the patch (e.g. ezmlm- + send(1), ezmlm(5)). + + + TTeexxtt ffiilleess iinn tthhee ddiissttrriibbuuttiioonn + ezmlm comes with a RREEAADDMMEE file with general instructions, an + IINNSSTTAALLLL file with installation instructions, an UUPPGGRRAADDEE file for + upgrading from a previous version and a CCHHAANNGGEESS file with + information on changes from previous versions. ezmlm-idx comes + with similar files suffixed with ``..iiddxx''. Most other patches or + add-ons contain similar files and man pages and should contain + identifying suffixes (.iss for ezmlm-issub, for example). For a + discussion of the authors' understanding of ezmlm security, see + ``Ezmlm-idx security''. + + + ````EEzzmmaann'''',, aann eezzmmllmm//iiddxx mmaannuuaall + The ezmlm manual is a brief manual that is meant for list + 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: + + +o ezman for download + + +o An on-line html version + + + TThhiiss FFAAQQ + This FAQ is built from a sgml source. It is available in the + following formats: + + +o A text file + + +o An on-line html version + + +o Html for download + + + +o A postscript (letter) version + + + +o A postscript (A4) version + + + +o Via mirrors mentioned for the ezmlm-idx package. + + +o An up-to-date text version,FFAAQQ..iiddxx, included with the ezmlm-idx + package. + + + WWWWWW rreessoouurrcceess + + AAnn oonn--lliinnee vveerrssiioonn ooff tthhiiss FFAAQQ + The main site with an up-to-date + mirror list. German mirror. + Polish mirror. + Japanese mirror. + Portuguese mirror. + Austrian mirror. + Canadian mirror. + + GGeenneerraall qqmmaaiill aanndd eezzmmllmm iinnffoo + + +o Dan J. Bernstein's qmail page + + + +o Dan J. Bernstein's ezmlm page + + + +o Russell Nelson's qmail page + + +o Mirrors of www.qmail.org . + Substitute your two-letter country abbreviation for ``ISO''. + + TThhee qqmmaaiill mmaaiilliinngg lliisstt aarrcchhiivvee + + + +o + + TThhee eezzmmllmm mmaaiilliinngg lliisstt aarrcchhiivvee + + +o + 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. + + MMaaiilliinngg lliissttss + Please read other documentation and mailing list archives before + posting questions to the lists. It's also useful to ``lurk'' on + the list for a few days, (i.e. to subscribe and read without + posting) before asking your questions on the list. + + To subscribe, send mail to the E-mail addresses listed: + + +o Dan Bernstein's ezmlm list: ezmlm-subscribe@list.cr.yp.to + + +o A digest version of the ezmlm list fredr-ezmlm-digest- + subscribe@rivertown.net + + +o Dan Bernstein's qmail list: qmail-subscribe@list.cr.yp.to + + +o The Japanese ezmlm list: ezmlm-subscribe@jp.qmail.org + + +o The Japanese qmail list: qmail-subscribe@jp.qmail.org + + +o A ezmlm/idx digest list of djb-qmail: qmail-digest- + subscribe@id.wustl.edu + + +o A ezmlm/idx sublist of djb-qmail (you can test ezmlm-idx + commands): qmail-index@id.wustl.edu + + + 11..77.. WWhheerree ddoo II sseenndd ccoommmmeennttss oonn tthhiiss ddooccuummeenntt?? + + To the authors via E-mail: + + +o Fred Lindberg, lindberg@id.wustl.edu + + +o Fred B. Ringel, fredr@rivertown.net + + + 11..88.. HHooww ttoo eexxppeerriimmeenntt wwiitthh nneeww vveerrssiioonnss ooff eezzmmllmm--iiddxx.. + + ezmlm-idx>=0.23 writes DDIIRR//ccoonnffiigg in a standard format. If ezmlm- + make(1) is invoked with the ``-e'' 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 _l_o_s_e _m_a_n_u_a_l _c_u_s_t_o_m_i_z_a_t_i_o_n_s _t_o _s_o_m_e _o_f _y_o_u_r + _f_i_l_e_s. However, text files and DDIIRR//hheeaaddeerraadddd 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 IINNSSTTAALLLL..iiddxx (if you haven't used ezmlm-idx before) + or UUPPGGRRAADDEE..iiddxx (if you've got a previous version of ezmlm-idx + installed), setting ccoonnff--bbiinn to a new directory. You can use either + the current directory or any other directory. If not using the current + dir, you also have to: + + + % make setup + + + + + If you now edit the list using the new ezmlm-make program, the list + will automatically be configured to use the new binaries. To change + back to the ``default'' installation, just edit the list again, this + time with the old ezmlm-make(1). + + If your system has an //eettcc//eezzmmllmmrrcc file, you may need to temporarily + place the eezzmmllmmrrcc((55)) file for the ezmlm version you want to test in + ddoottddiirr of the list and use the ezmlm-make(1) ``-c'' switch (see + ``Terminology: dotdir''). + + ezmlm-idx>=0.314 comes with ezmlm-test(1), a program that tests most + functions of ezmlm+idx and can be used before installation. + + + 22.. QQuuiicckk ssttaarrtt + + + 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 ccoonnff--bbiinn and ccoonnff--mmaann 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 (FFAAQQ..iiddxx in the distribution), + RREEAADDMMEE//RREEAADDMMEE..iiddxx, IINNSSTTAALLLL//IINNSSTTAALLLL..iiddxx, and UUPPGGRRAADDEE..iiddxx. + + + 33.. OOvveerrvviieeww ooff mmaaiilliinngg lliisstt mmaannaaggeemmeenntt aanndd mmaaiilliinngg lliisstt mmaannaaggeerrss + + (To be written. Until then, please consult the + manual for ezmlm and ezmlm-idx related + material.) + + + 44.. OOvveerrvviieeww ooff eezzmmllmm ffuunnccttiioonn + + + 44..11.. TThhee bbaassiicc sseettuupp.. + + In designing ezmlm, _D_a_n _J_. _B_e_r_n_s_t_e_i_n has used the unix philosophy of + small component programs with limited and well defined functions. + Requests for specific functions can then be met by the addition of new + programs. + + Thanks to the program execution mechanism Dan built into qmail, it is + easy to execute several small programs per delivery in a defined + sequence. It is also very easy to add shell scripts for further + customization. + + + 44..22.. IInnvveennttiioonnss iinn eezzmmllmm.. + + Dan J. Bernstein has written ezmlm in C. It is written for speed and + reliability even in the face of power loss and NFS. These features + are augmented to a large extent by the ruggedness of the qmail (also + by Dan) delivery mechanism (see qmail-command(8)). + + ezmlm uses some routines and techniques that still are not frequently + seen in many mailing list managers. For example, subscriber E-mail + addresses are stored in a hash so that searches require reading only, + at most, 2% of the E-mail addresses. ezmlm has a optional message + archive, where messages are stored 100 per directory, again to allow + more efficient storage and retrieval. Important files are written + under a new name and, only when safely written, moved in place, to + assure that 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. + + + 44..33.. TThhee qqmmaaiill ddeelliivveerryy mmeecchhaanniissmm.. + + See qmail(7), qmail-local(8), qmail-command(8), envelopes(5), and dot- + qmail(5). Briefly, qmail having resolved the delivery address + delivers it via the ..qqmmaaiill file that most completely matches the + address. This file may be a link to another file, as is the case in + ezmlm lists. qmail then delivers the message according to successive + lines in this file forwarding it to an address, storing it, or piping + it to a program. In the latter case, the program is expected to exit 0 + leading delivery to proceed to the next line in the ..qqmmaaiill file, or 99 + leading to success without delivery to succeeding lines. An exit code + of 100 is a permanent error leading to an error message to the SENDER. + An exit code of 111 is used for temporary errors, leading to re- + delivery until successful or until the queue lifetime of the message + has been exceeded. + + Delivery granularity is the ..qqmmaaiill file and re-deliveries start at the + top. Thus, if the message fails temporarily at a later line, the + delivery according to an earlier line will be repeated. Similarly, + qmail may have made deliveries successfully according to most of the + ..qqmmaaiill file and then fail permanently. The SENDER is informed that the + delivery failed, but not about at which point. + + ezmlm takes advantage of these basic mechanisms to build a fast, + efficient, and very configurable mailing list manager from a set of + small independent programs. + + + 44..44.. WWhhaatt tthhee ddiiffffeerreenntt pprrooggrraammss ddoo.. + + See ezmlm(5) and the man pages for the different programs (listed in + ezmlm(5)). + + + 44..55.. WWhhaatt tthhee ddiiffffeerreenntt ffiilleess iinn tthhee lliisstt ddiirreeccttoorryy ddoo.. + + See ezmlm(5). + + + 44..66.. TThhee ppaappeerr ppaatthh ffoorr ppoossttss.. + + Messages to the list are delivered to a ..qqmmaaiill file, usually ~~//..qqmmaaiill-- + lliissttnnaammee which is linked to DDIIRR//eeddiittoorr. Here, the message is first + delivered to ezmlm-reject(1) which can reject messages based on + subject line contents, MIME content-type, and message body length. It + also by default rejects all messages that do not have the list address + in the ``To:'' or ``Cc:'' header. This eliminates most bulk spam. If + the list is set up for restrictions based on envelope SENDER, the next + delivery is to one or more instances of ezmlm-issubn(1). If the + messages passed this check, it is usually delivered to ezmlm-send(1) + for distribution. If the list is message moderated, it is instead + delivered to ezmlm-store(1) which queues the message and sends out a + moderation request. ezmlm-gate(1) is used by some other setups. It + will for message moderated lists invoke ezmlm-send(1) directly if the + message is from a specific set of SENDERs, and in other cases ezmlm- + store(1) to send the message out for moderation. + + You can specify a separate ..qqmmaaiill-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, DDIIRR//eeddiittoorr also contains an + ezmlm-tstdig(1) line followed by an ezmlm-get(1) line. If ezmlm- + tstdig(1) determines that the criteria are met for digest generation, + it exits with an exit code of 0, causing the ezmlm-get(1) line to be + executed leading to a digest mailing. Otherwise, ezmlm-tstdig(1) exits + 99, resulting in the remainder of the DDIIRR//eeddiittoorr file to be ignored + too long. The digest is not related to the message being delivered, + but the delivery is used to trigger execution of the relevant + programs. + + + In addition, DDIIRR//eeddiittoorr contains a number of house-keeping functions. + These are invocations of ezmlm-warn(1) to send out bounce warnings and + 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. + + + 44..77.. TThhee eezzmmllmm ppaatthh ffoorr mmooddeerraattiioonn mmeessssaaggeess.. + + Replies to moderation requests are channeled to DDIIRR//mmooddeerraattoorr. This + file contains an invocation of ezmlm-moderate(1) which invokes ezmlm- + send(1) for accepted messages and sends out a rejection notice for + rejected messages. It also sends error messages if the message is not + found or already accepted/rejected _c_o_n_t_r_a_r_y to the moderation message. + Thus, if you accept a message already accepted, no error message is + sent. ezmlm-clean(1) is also invoked from DDIIRR//mmooddeerraattoorr for house + keeping. + + + 44..88.. TThhee eezzmmllmm ppaatthh ffoorr aaddmmiinniissttrraattiivvee mmeessssaaggeess.. + + Administrative requests for both list and digest lists are captured by + ~~//..qqmmaaiill--lliissttnnaammee--ddeeffaauulltt linked to DDIIRR//mmaannaaggeerr. Here they are + delivered first to ezmlm-get(1) which processed archive retrieval + requests, exiting 99 after successful completion which causes the rest + of the delivery lines to be ignored. If the request is not for ezmlm- + get(1) it rapidly exits 0. This leads to invocation of ezmlm-manage(1) + which handles subscriber database functions, help messages, and (if + configured) editing of DDIIRR//tteexxtt// files. Again, ezmlm-warn(1) lines are + included for bounce directory processing. + + If configured, an ezmlm-request(1) line is present. This program + constructs valid ezmlm requests from command in the subject lines of + messages sent to listname-request@host and exits 99. These requests + are mailed and will then return to be processed by one of the other + programs. + + 44..99.. TThhee eezzmmllmm ppaatthh ffoorr bboouunncceess.. + + Bounces to the list are handled by DDIIRR//bboouunncceerr. For the digest list + this is DDIIRR//ddiiggeesstt//bboouunncceerr. 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 DDIIRR//bboouunnccee// for the list and + DDIIRR//ddiiggeesstt//bboouunnccee// for the digest. This is the information that + ezmlm-warn(1) (invoked from DDIIRR//eeddiittoorr and DDIIRR//mmaannaaggeerr) uses and + processes for automatic bounce handling. ezmlm-return(1) will also + unsubscribe a subscriber from whom a probe message has bounced. + + + 44..1100.. MMeessssaaggeess ttoo lliisstt--oowwnneerr aanndd lliisstt--ddiiggeesstt--oowwnneerr.. + + These are processed by DDIIRR//oowwnneerr and delivered to DDIIRR//mmaaiillbbooxx by + default. It is better to put the real owner address in this location. + This can be done manually, via editing of eezzmmllmmrrcc((55)), or via the + ezmlm-make(1) -5 switch. Again, some house-keeping functions are also + executed. + + + 44..1111.. SSttrruuccttuurree ooff ssuubbssccrriibbeerr ddaattaabbaasseess.. + + ezmlm subscriber E-mail addresses are stored within DDIIRR//ssuubbssccrriibbeerrss// + as a hashed set of 53 files. The hash calculated from the address + determines which of the 53 files and address is stored in. Thus, to + find out if an address is a subscriber, ezmlm has to read at most + about 2% of the E-mail addresses. The hash function insures that E- + mail addresses are reasonably evenly distributed among the 53 files. + + Addresses in the files in DDIIRR//ssuubbssccrriibbeerrss// are stored as strings + starting with ``T'', followed by the address, followed by a zero byte. + This is the same format as taken by qmail-queue(8) on file descriptor + 1. Thus, subscriber lists can be directly copied to qmail without any + further processing. + + 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''). + + + 44..1122.. LLooccaall ccaassee iinn EE--mmaaiill aaddddrreesssseess.. + + 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. + + + 44..1133.. TTeessttiinngg SSEENNDDEERR ttoo aallllooww ppoossttss oonnllyy ffrroomm lliisstt ssuubbssccrriibbeerrss.. + + This mode of operation is automatically set up if you specify the + ezmlm-make(1) ``-u'' switch. Since there may be some addresses that + should be allowed to post, but are not subscribers of list or list- + digest, ezmlm-make(1) sets up an additional address database in + DDIIRR//aallllooww//. Use ezmlm-sub(1), ezmlm-unsub(1), and ezmlm-list(1) to + manipulate these addresses. If the list is configured for remote + administration (see ``How remote administration works''), you can + add/remove addresses from the DDIIRR//aallllooww// database by mailing list- + allow-subscribe@listhost and list-allow-unsubscribe@listhost, + respectively. Other commands that access subscriber databases work in + the same manner. + + To similarly restrict archive access, use the ezmlm-make(1) ``-g'' + switch. + + Since SENDER is under the control of a potential attacker, it is not + secure to use tests of SENDER for anything important. However, when + replies are always sent to SENDER (such as for archive access), a + check of SENDER can prevent the sending of information to E-mail + addresses not in the database. + + To test sender, use the program ezmlm-issubn(1). It will return 0 + (true for the shell, success for qmail deliveries) if SENDER is in at + least one of a set of subscriber databases. If not, it will return 99 + (false for the shell: success, but skip remainder of ..qqmmaaiill file for + qmail deliveries). The basedirs of the subscriber lists (i.e. the + directories in which the ``subscriber'' dirs are located) are given as + arguments. ezmlm-issubn(1) can take any number of arguments. + + Thus, to permit an action if SENDER is a subscriber to the list in any + of DDIIRR//, DDIIRR//ddiiggeesstt//, or DDIIRR//aallllooww// and exit silently, put the + following into the relevant ..qqmmaaiill 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 _N_O_T 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 DDIIRR//ddeennyy, 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. + + + 44..1144.. HHooww ccooookkiieess wwoorrkk.. + + Each ezmlm list has it's own ``key'' created by ezmlm-make at setup + time. This key is stored in DDIIRR//kkeeyy, and you can improve it by adding + garbage of your own to it. However, changing the key will make all + outstanding cookies invalid, so this should be done when the list is + established. + + When ezmlm receives an action request, such as ``subscribe'', it + constructs a cookie as a function of: + + +o the request, + + +o the time, + + +o and the target address. + + The cookie and these items are then assembled into a address that + is sent out as the ``Reply-To:'' address in the confirmation + request sent to the subscriber. When the subscriber replies, ezmlm + first checks if the timestamp is more than 1,000,000 seconds old + (approx 11.6 days) and rejects the request if it is. Next, ezmlm + recalculates the cookie from the items. If the cookies match, the + request is valid and will be completed. Depending on the + circumstances, ezmlm generates an error message or a new cookie + based on the current time and sends the target a new confirmation + request. + + Dan has based these cookies on cryptographic functions that make it + very unlikely that a change in any part of the cookie or the items + will result in a valid combination. Thus, it is virtually impossible + to forge a request even for someone who has a number of valid requests + to analyze. Since the algorithm ezmlm uses is available, the security + rests on the key (and the correctness of the algorithm). Anyone who + knows the key for your lists can easily construct valid requests. + + As ezmlm-make(1) doesn't use a truly random process to generate the + key, it is theoretically possible that someone with sufficient + knowledge about your system can guess your key. In practice, this is + very unlikely, and the safety of the system is orders of magnitude + higher than that of other mechanisms that you may rely on in your list + management and mail transport (exclusive of strong encryption, such as + _P_G_P). + + + 44..1155.. HHooww mmooddeerraattoorr EE--mmaaiill aaddddrreesssseess aarree ssttoorreedd.. + + Moderator E-mail addresses are stored just like ezmlm subscriber + addresses, in a set of up to 53 files within the ssuubbssccrriibbeerrss + subdirectory of the list's bbaasseeddiirr//. For subscribers, the bbaasseeddiirr// is + the list directory itself, i.e. DDIIRR//. For moderators, the default is + DDIIRR//mmoodd//, which can be overridden by placing a bbaasseeddiirr name (starting + with a ``/'') in DDIIRR//mmooddssuubb, DDIIRR//rreemmoottee, or DDIIRR//mmooddppoosstt for + subscription moderation, remote administration, and message + moderation, respectively. This permits the use of one moderator + database for multiple lists. _N_o_t_e_: _S_u_b_s_c_r_i_p_t_i_o_n _m_o_d_e_r_a_t_o_r_s _a_n_d _r_e_m_o_t_e + _a_d_m_i_n_i_s_t_r_a_t_o_r_s _a_r_e _a_l_w_a_y_s _t_h_e _s_a_m_e _a_d_d_r_e_s_s_e_s_. _I_f _b_o_t_h DDIIRR//mmooddssuubb and + DDIIRR//rreemmoottee contain paths, only the DDIIRR//mmooddssuubb path is used. + + + 44..1166.. HHooww ssuubbssccrriippttiioonn mmooddeerraattiioonn wwoorrkkss.. + + Subscription moderation is a simple extension of the ezmlm subscribe + mechanism. Once the user has confirmed the subscribe request, a new + request is constructed with a _d_i_f_f_e_r_e_n_t _a_c_t_i_o_n _c_o_d_e. This is sent out + to the moderator(s). When a moderator replies with a valid request and + cookie combination, the user is subscribed. The user is then also + welcomed to the list. Other moderators won't know that the request has + already been approved. If other moderators reply to the request, no + notification of the duplicate action is sent to the subscriber of the + duplicate action. Ezmlm knows that this is a repeat request since the + target address is already a subscriber. + + The moderators are not informed about the result, unless there was an + error (subscribing a target that is already a subscriber is not + considered an error). This cuts down the number of messages a + moderator receives. Any list moderator knows (or _s_h_o_u_l_d know) the + qmail/ezmlm/unix paradigm: _i_f _y_o_u_'_r_e _n_o_t _t_o_l_d _o_t_h_e_r_w_i_s_e_, _y_o_u_r _c_o_m_m_a_n_d + _w_a_s _c_a_r_r_i_e_d _o_u_t _s_u_c_c_e_s_s_f_u_l_l_y. This may be counterintuitive to those + used to some other operating systems, but in our experience it doesn't + take long to get used to the reliability and efficiency of + U*ix/qmail/ezmlm. + + Subscription moderation is enabled by creating DDIIRR//mmooddssuubb and adding + the subscription moderator to DDIIRR//mmoodd//: + + + % ezmlm-sub DIR/mod moderator@host + + + + + To use an alternative basedir for subscription moderators, place that + directory name with a leading ``/'' in DDIIRR//mmooddssuubb. + + + 44..1177.. HHooww rreemmoottee aaddmmiinniissttrraattiioonn wwoorrkkss.. + + 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 DDIIRR//rreemmoottee and adding the + remote administrator E-mail address(es) to DDIIRR//mmoodd//: + + + % ezmlm-sub DIR/mod remoteadm@host + + + + + To use an alternative basedir for remote administrators, place that + directory name with a leading ``/'' in DDIIRR//mmooddssuubb. Remote administra- + tors and subscription moderators databases always consist of the same + E-mail addresses. If both are enabled and one of DDIIRR//mmooddssuubb and + DDIIRR//rreemmoottee contains an alternative basedir name, this basedir is used + for both functions. If both DDIIRR//mmooddssuubb and DDIIRR//rreemmoottee contain direc- + tory names, the one in DDIIRR//mmooddssuubb is used for both functions. + + Remote administrators can add and remove addresses to the digest list, + the ``allow'' list (user aliases for lists using SENDER restrictions + on posting and archive access), and if used the ``deny'' list + containing addresses that are denied posting rights to the list. The + latter is easy to circumvent and intended to block errant mail robots, + rather than human users. + + + 44..1188.. HHooww mmeessssaaggee mmooddeerraattiioonn wwoorrkkss.. + + ezmlm-store(1), invoked in DDIIRR//eeddiittoorr, receives messages for message + moderated lists. If DDIIRR//mmooddppoosstt does not exist, ezmlm-store(1) just + calls ezmlm-send(1) and the message is posted to the list as if it + were not moderated. If DDIIRR//mmooddppoosstt exists, ezmlm-store(1) places the + message in DDIIRR//mmoodd//ppeennddiinngg//. It also sends a moderation request to + all the moderators. Included with this request is a copy of the + message. The ``From:'' and ``Reply-To:'' E-mail addresses contain + codes for ``reject'' and ``accept'', together with a unique message + name (derived from the message timestamp and process id) and a cookie + based on these items. When a moderator replies, ezmlm-moderate(1) is + invoked via DDIIRR//mmooddeerraattoorr. ezmlm-moderate(1) validates the request, + and if the request is valid and the message is found in + DDIIRR//mmoodd//ppeennddiinngg//, it carries out the requested action. + + If the request is ``reject'' the post is returned to SENDER with an + explanation and an optional moderator comment. If the request is + ``accept'' the message is posted to the list via ezmlm-send(1). As the + request is processed, a stub for the message is created in + DDIIRR//mmoodd//rreejjeecctteedd// or DDIIRR//mmoodd//aacccceepptteedd// for ``reject'' and ``accept'' + requests, respectively. + + If a valid reply is received but the message is no longer in + DDIIRR//mmoodd//ppeennddiinngg//, ezmlm-moderate(1) looks for the corresponding stub + in DDIIRR//mmoodd//rreejjeecctteedd// and DDIIRR//mmoodd//aacccceepptteedd//. If the stub is found and + the fate of the message was the one dictated by the new request, no + further action is taken. If, however, no stub is found or the request + and the actual message fate do not match, a notification is sent to + the moderator. This scheme was chosen to impart a maximum of + information with a minimum of messages. Also, it is the least + demoralizing setup for multiple moderator lists, where it is important + not to notify subsequent moderators that their work was in vain since + the action of the first responding moderator has already resulted in + processing of the message. + + If a message is not ``rejected'' or ``accepted'' it remains in + DDIIRR//mmoodd//ppeennddiinngg// until it times out. Cleanup of both messages and + stubs is accomplished by ezmlm-clean(1) which is invoked through both + DDIIRR//eeddiittoorr and DDIIRR//mmooddeerraattoorr for message moderated lists. ezmlm- + clean(1) looks at the timestamp used to generate the message/stub + name. If it is older than 120 hours (configurable in a range of 24-240 + hours, by placing the value in DDIIRR//mmooddttiimmee) it is removed. Unless + suppressed with the ezmlm-clean(1) ``-R'' switch, the SENDER of the + message is notified. + + By default, the E-mail addresses of message moderators are stored as a + subscriber list with a basedir of DDIIRR//mmoodd//. This can be changed to + any other bbaasseeddiirr by placing the name of that directory with a leading + ``/'' in DDIIRR//mmooddppoosstt. Although the default basedirs for message + moderation and subscription moderation/remote administration are the + same, both the functions and actors are entirely independent. + + + 44..1199.. HHooww QQMMQQPP ssuuppppoorrtt wwoorrkkss + + 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 DDIIRR//qqmmqqppsseerrvveerrss//00. The list housed in + DDIIRR 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 DDIIRR//qqmmqqppsseerrvveerrss//00, just as you normally + would in //vvaarr//qqmmaaiill//ccoonnttrrooll//qqmmqqppsseerrvveerrss. 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. + + + 44..2200.. HHooww mmeessssaaggeess aarree ssttoorreedd iinn tthhee aarrcchhiivvee.. + + The structure of the ezmlm list archive is described in the ezmlm(5) + manual page. Basically, the message is stored in DDIIRR//aarrcchhiivvee//nn//mm, + where ``n'' is the message number divided by 100 and ``m'' the + remainder (2 digits). The first message is stored in DDIIRR//aarrcchhiivvee//00//0011. + + + 44..2211.. HHooww tthhee mmeessssaaggee iinnddeexx wwoorrkkss.. + + The ezmlm-idx(1) adds the option (default) of a message index to + ezmlm. The ``From:'' line, the subject, the author's E-mail address + and name and the time of receipt are logged for each message as it is + received. The subject is ``normalized'' by concatenating split lines + and removing reply-indicators such as ``Re:''. A hash of the + normalized subject with all white space removed is also stored. The + hash for any message within a thread is almost always the same and is + used together with the order of receipt to connect a set of messages + into a ``thread''. 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 DDIIRR//aarrcchhiivvee//nn//iinnddeexx, where ``n'' is the + message number mod 100. Thus, the directory DDIIRR//aarrcchhiivvee//5522// stores + messages 5200 through 5299 and the file ``index'' which contains the + index for those messages. + + The message index can be retrieved with the -index command (see ezmlm- + get(1)). You can also retrieve a range of messages, a specific thread, + or generate a message digest (see ezmlm-get(1)). Each of these + commands can be disabled or restricted as desired by the list owner. + + The ezmlm-idx(1) can be used at any time to either reconstruct an + existing index or create one an index for an existing message archive. + without one. + + + 44..2222.. HHooww tthhrreeaaddiinngg wwoorrkkss.. + + A ezmlm thread is just a message number-ordered set of messages with + identical ``normalized'' subject entries. This is a very reliable + method for threading messages. It does not rely on any variably + present ``In-Reply-To:'' or ``References:'' headers. If the subject + changes, the continuation becomes a separate thread very close to the + original thread in a digest. ezmlm uses this mechanism to return + message sets threaded and with a thread and author index, unless + specifically told not to do so with the ``n'' format specifier. + Naturally, lists set up without a message index (using the ezmlm-make + ``-I'' switch) do not maintain thread information. + + + 44..2233.. HHooww ddiiggeessttss wwoorrkk.. + + A ``digest'' is just an ordered collection of messages from a list, + usually sent out regularly depending on the time and traffic volume + since the last digest. Digest subscribers thus can read messages as + ``threads'' once daily, rather than receiving a constant trickle of + messages. + + As a major change in ezmlm-idx-0.30, the digest is no longer a totally + separate ezmlm-list, but a part of the main list. This has security + advantages, makes setup and administration easier, saves space, and + allows a consistent way for subscribers of both ``list'' and ``list- + digest'' to retrieve missed messages from a single archive. + + The digest of the list ``list'' is always called ``list-digest''. To + set up a list with a digest, simply use the ezmlm-make(1) ``-d'' + switch. You subscribe to and unsubscribe from a digest the same way as + for the main list, except that the request is sent to e.g. list- + digest-subscribe@host rather than to list-subscribe@host. + + Any option such as remote admin or subscription moderation that is + active for the list applies also to the digest list. Any restrictions + in posts or archive retrieval set up for the list, automatically + accept both subscribers of the main list and of the digest list. + + The changes in ezmlm-idx>=0.30 allow all programs to service both list + and list-digest functions. All digest-specific files are stored in + DDIIRR//ddiiggeesstt//. Digest list subscriber addresses in + DDIIRR//ddiiggeesstt//ssuubbssccrriibbeerrss// and digest list bounce information in + DDIIRR//ddiiggeesstt//bboouunnccee//. Text files are shared between list and digest. To + get the local part of the list or list-digest name in a context + sensitive manner, use ``<#l#>'' (lower case ``L'') in the text file. + + + In order to generate digest, the list needs to be archived and indexed + (both default). You can retrieve sets of messages from the message + archive. Such sets are always returned to the SENDER of the request. + ``Digests'' are a special form of such a set/request. First, there are + no restrictions on the number of messages that can be in a digest + (which is balanced by the requirement for a ``digest code'' that needs + to be specified in order to create a digest based on a mailed + request). Second, special files (DDIIRR//ddiiggiissssuuee and DDIIRR//ddiiggnnuumm) keep + track of the digest issue and the message number, amount, and time + when the last digest was created. Thus, the system is adapted to make + it easy to create the regular collections of messages commonly + referred to as ``digests''. + + Digest can be generated in several different ways: + + CCoommmmaanndd lliinnee + ezmlm-get can be invoked on the command line, or via a script + from e.g. crond(8): + + + % ezmlm-get DIR + + + + + If for some reason the digest should be disseminated via a separate + list, the digest can be redirected to a ``target address'' with the + ezmlm-get(1) ``-t'' switch. This may be useful if a non-standard + digest list name is required. In this case, the list disseminating + the digest must be set up as a sublist of the main list (see ``How + sublists work''). + + + ffrroomm DDIIRR//eeddiittoorr + This is the default and does not require and additional setup. + It works well with most lists. The only possible advantage is + for very low traffic lists and for lists where it is important + that a digest be sent out at a specific time (as DDIIRR//eeddiittoorr + digests are triggered only when messages are received). + + In DDIIRR//eeddiittoorr, ezmlm-get(1) needs to be combined with ezmlm- + tstdig(1) so that digests are generated only if certain criteria + are met (in this case, more than 30 messages, 64 kbytes of + message body or 48 hours since the latest digest). Add these + lines after the ezmlm-send line in DDIIRR//eeddiittoorr: + + + |/usr/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. + + ffrroomm DDIIRR//mmaannaaggeerr + 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 DDIIRR//mmaannaaggeerr 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 DDIIRR//mmaannaaggeerr. 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 DDIIRR//eeddiittoorr works + very well, and does not require any extra setup work. + + CCoommbbiinnaattiioonn sseettuuppss + The default setup in the ezmlmrc(5) file included in the + distribution is the DDIIRR//eeddiittoorr triggered setup described above. + If you in addition use ezmlm-cron(1) or crond(8) directly to + generate trigger messages to list-dig.code@host, you can get + regular digests (via the trigger messages and DDIIRR//mmaannaaggeerr), with + extra digest sent when traffic is unusually high (via the ezmlm- + tstdig/ezmlm-get limits set in DDIIRR//eeddiittoorr). This works best + when the time argument on the ezmlm-tstdig(1) command line is + the same as the trigger message interval, and the other ezmlm- + tstdig(1) parameters are set so that they are only rarely + exceeded within the normal digest interval. + + + 44..2244.. HHooww WWWWWW aarrcchhiivvee aacccceessss wwoorrkkss.. + + If the list is set up with ezmlm-make -i, ezmlm-archive(1) will be + invoked from DDIIRR//eeddiittoorr. This program creates indices for threads, + subjects, and authors under DDIIRR//aarrcchhiivvee from the iinnddeexx files. ezmlm- + cgi(1) is set up per user or globally (see man page) and told about + different lists via the //eettcc//eezzmmllmm//eezzccggiirrcc 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. + + + + + 44..2255.. HHooww eezzmmllmm--ttssttddiigg wwoorrkkss.. + + ezmlm-tstdig(1) looks at DDIIRR//nnuumm and DDIIRR//ddiiggnnuumm to determine how many + messages and how much traffic (in terms of bytes of message body) has + arrived to the list since the latest digest. It also determines how + much time has passed since the last digest was generated. If any of + the criteria specified by command line switches exists, ezmlm- + tstdig(1) exits 0, causing the invocation of the next line in the + .qmail file. If not, ezmlm-tstdig(1) exits 99 causing qmail to skip + the rest of the .qmail file. ezmlm-tstdig(1) looks at LOCAL to + determine if it is invoked in the command line, in DDIIRR//eeddiittoorr, or in + DDIIRR//mmaannaaggeerr. In the latter two cases, ezmlm-tstdig(1) verifies that + the list local address is correct. If invoked in DDIIRR//mmaannaaggeerr, ezmlm- + tstdig(1) exits 0 for all action requests except list-dig, so that is + does not interfere with the normal functions of ezmlm-get(1) and + ezmlm-manage(1). ezmlm-tstdig(1) uses DDIIRR//ttssttddiigg 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. + + + 44..2266.. HHooww ssuubblliissttss wwoorrkk.. + + ezmlm uses the concept of sublists. Sublists are regular ezmlm lists, + except that they only accept messages from their parent list, which is + placed in the file DDIIRR//ssuubblliisstt. + + sublists are used to split the load of a large mailing list among + several hosts. All you need to do to set up a local sublist of e.g. + the qmail@list.cr.yp.to list is to create a ezmlm list, and put + ``qmail@list.cr.yp.to'' into DDIIRR//ssuubblliisstt of you list, and subscribe + the sublist to the main qmail list. Now anyone can subscribe to your + local list which handles its own bounces, subscribe requests, etc. + The load on the main list is only the single message to your local + list. + + Sublists will not add their own mailing list header and they will not + add a subject prefix. Normally, sublists will use their own message + number, rather than that used by the main list. With ezmlm-idx>=0.23, + sublists that are not archived and not indexed, will instead use the + main list message number. This way, bounce messages from the sublist + can refer the subscriber to the main list archive. This is not done + for indexed/archived sublists for security reasons (an attacker could + overwrite messages in the sublist archive). + + With ezmlm-idx>=0.31, there is support for using ezmlm as a sublist of + a mailing list run by another mailing list manager. To set this up, + set up a normal ezmlm sublist, then edit DDIIRR//eeddiittoorr so that the _e_z_m_l_m_- + _s_e_n_d line contains the command line option ``--hh _X_-_L_i_s_t_p_r_o_c_e_s_s_o_r_- + _V_e_r_s_i_o_n_:'' (before DDIIRR). As the header text, you need to use a header + that the main list manager adds to messages. Now your sublist will + accept only messages from the main list requiring that they come from + that list _a_n_d contain the header specified. + + ezmlm-idx>=0.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 DDIIRR//eeddiittoorr has ``-h'' and + ``DDIIRR'' on it, ezmlm-reject(1) will read DDIIRR//hheeaaddeerrrreejjeecctt and reject + messages that have any header specified in that file. See the ezmlm- + reject(1) man page for suitable headers. + + + + 44..2277.. HHooww ssuubblliissttiinngg ccaann bbee mmaaddee ttrraannssppaarreenntt ttoo tthhee uusseerr.. + + 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 DDIIRR//mmaannaaggeerr. If it detects a subscribe or unsubscribe + command, it will forward the command to the appropriate sublist based + on a ``split file'' DDIIRR//sspplliitt. 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''). + + 44..2288.. HHooww ttoo sseerrvviiccee ccoommmmaannddss iinn tthhee ssuubbjjeecctt lliinnee.. + + 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 + DDIIRR//mmaannaaggeerr. 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 DDIIRR//mmaannaaggeerr before ezmlm- + get(1) and ezmlm-manage(1). It ignores all requests that are not for + the list-request address. For requests to the list-request@host + address, ezmlm-request(1) parses the ``Subject:'' line. If a ezmlm + command address starting with the contents of DDIIRR//oouuttllooccaall (e.g. list- + get45) is on the command line, ezmlm-request(1) generates the + corresponding full ezmlm request message. If the subject does not + start with the contents of DDIIRR//oouuttllooccaall, ezmlm-request(1) prefixes the + line with the contents of DDIIRR//oouuttllooccaall, thereby building a complete + ezmlm command. If a host name is specified, it must match the contents + of DDIIRR//oouutthhoosstt, 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 DDIIRR//mmaannaaggeerr. + + To set up a list to include ezmlm-request processing, use the ezmlm- + make(1) ``-q'' switch. The default is to not do this. + + + 44..2299.. HHooww ttoo ssuuppppoorrtt aalltteerrnnaattiivvee ccoommmmaanndd nnaammeess.. + + ezmlm-idx>=0.23 allows alternate names for all user commands. This can + be used to e.g. make a message to 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. + + + + + 44..3300.. HHooww ttoo aadddd yyoouurr oowwnn ccoommmmaannddss.. + + The qmail/ezmlm mechanism makes it very easy to add your own commands. + You can add them to DDIIRR//mmaannaaggeerr, but this requires great care in terms + of ordering and exit codes. Easier is to set them up separately with a + ..qqmmaaiill--lliisstt--ccoommmmaanndd 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 <>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 + DDIIRR//bboouunnccee//dd//, one per 10,000 seconds. The corresponding address + hashes are stored in 16 subdirectories of DDIIRR//bboouunnccee//hh//. Instead of + looking at all bounces, ezmlm-warn(1) processes only the bounces in + DDIIRR//bboouunnccee//dd// subdirectories that are ``due''. In addition, ezmlm- + warn(1) uses DDIIRR//bboouunnccee//llaassttdd 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. + + + 44..3388.. HHooww tthhee iinnffoo aanndd ffaaqq ccoommmmaannddss wwoorrkk.. + + The _-_i_n_f_o and _-_f_a_q commands simply reply with the contents of the + DDIIRR//tteexxtt//iinnffoo and DDIIRR//tteexxtt//ffaaqq files. Edit these files directly or + remotely (see ``How to remotely edit dir/text files''). The + DDIIRR//tteexxtt//iinnffoo file should start with a single line that is meaningful + as is and describes the list. This will be used in later versions to + allow automatic assembly of the global ``list-of-lists'' (see ``How to + set up a global list address like majordomo@host or listserv@host''). + + + 44..3399.. HHooww tthhee gglloobbaall eezzmmllmm lliisstt aaddddrreessss wwoorrkkss.. + + 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. + + + 44..4400.. HHooww eezzmmllmm--ccrroonn wwoorrkkss.. + + 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 + eezzccrroonnrrcc 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 + + + + 44..4411.. HHooww eezzmmllmm--mmaakkee wwoorrkkss.. + + 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 //eettcc// directory + with a default install. If not found, the file in the ezmlm binary + directory will be used. The second ezmlm-make command line argument + specify the root name of the .qmail files. If the ezmlm-make(1) ``-c'' + switch is used, ezmlm-make(1) will look in that directory for a + ..eezzmmllmmrrcc file and use it instead. If this file does not exist, ezmlm- + make(1) will print a warning and use the previously discussed + ezmlmrc(5) files in the same order. You can also use ``-C + _e_z_m_l_m_r_c_._a_l_t'' to use _e_z_m_l_m_r_c_._a_l_t as the ezmlmrc(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 DDIIRR//kkeeyy 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 DDIIRR//ccoonnffiigg. This files saves all + the flags that were set at the last execution of ezmlm-make, as well + as all the switch and command line arguments. When editing a list, + only ``DIR'' and the non-default letter switches need to be specified. + Other command line arguments and the ``digit switch'' arguments are + read from DDIIRR//ccoonnffiigg. To remove a digit switch, simply use it with + two single quotes as the argument. + + You can also easily determine how a list was set up by looking at + DDIIRR//ccoonnffiigg. + + _N_o_t_e_: DDIIRR//tteexxtt// 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 eezzmmllmmrrcc, use ``-ee'' or ``-++''. + + _N_o_t_e_: 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. + + + 44..4422.. WWhhaatt nnaammeess ccaann II uussee ffoorr mmyy lliissttss?? + + 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 nnoott part of the ..qqmmaaiill 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 ~~aalliiaass// directory. + + + 44..4433.. LLiissttss iinn vviirrttuuaall ddoommaaiinnss + + 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. + + + 44..4444.. HHooww ddoo II mmaakkee ccuussttoommiizzaattiioonn ssiimmppllee ffoorr mmee//mmyy uusseerrss?? + + All non-default switches, ezmlm-issubn(1) setups, etc, can be made + standard for new lists by customizing the ezmlm-make(1) configuration + file named ``eezzmmllmmrrcc''. A default eezzmmllmmrrcc((55)) is installed in the + ezmlm binary directory. If installed, a system-wide customized ezmlmrc + file in //eettcc//eezzmmllmmrrcc (or symlinked from there) overrides this. + Installing a ~~//..eezzmmllmmrrcc file in a user ddoottddiirr and using the ezmlm- + make(1) ``-c'' switch allows further per user customization (see + ``Customizing ezmlm-make operation''). + + + 55.. eezzmmllmm ssuuppppoorrtt ffoorr SSQQLL ddaattaabbaasseess.. + + + 55..11.. WWhhyy uussee aann SSQQLL ddaattaabbaassee wwiitthh eezzmmllmm?? + + 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. + + + 55..22.. WWhhyy nnoott ttoo uussee aann SSQQLL ddaattaabbaassee wwiitthh eezzmmllmm.. + + 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. + + + 55..33.. TTaabblleess uusseedd ffoorr ((MMyy))SSQQLL ssuuppppoorrtt.. + + 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. + + + 55..33..11.. AAddddrreessss ttaabblleess.. + + + lliisstt + List subscriber addresses. + + lliisstt__ddiiggeesstt + Digest list subscriber addresses. + + lliisstt__aallllooww + 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. + + lliisstt__ddeennyy + 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. + + lliisstt__mmoodd + Moderator addresses. Created for completeness, but not used in + the default configuration. If moderators are used, the addresses + are stored in a local database. + + + 55..33..22.. SSuubbssccrriibbeerr lloogg ttaabblleess.. + + 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''). + + + 55..33..33.. MMeessssaaggee llooggggiinngg ttaabblleess.. + + For both the list and the digest list, there are a pair of tables that + log messages: + + + lliisstt__ccooookkiiee + 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 DDIIRR//kkeeyy, 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''. + + + lliisstt__mmlloogg + 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 _a_f_t_e_r 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. + + + + + 55..44.. HHooww ttoo sseett uupp aa ssiimmppllee lliisstt wwiitthh SSQQLL ssuuppppoorrtt.. + + To use SQL database support, you have to compile the programs with SQL + support. Currently, only MySQL support is available. See IINNSSTTAALLLL..iiddxx + 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 ssqqll 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. + + + 55..44..11.. HHeellppeerr pprrooggrraammss ffoorr SSQQLL--eennaabblleedd lliissttss.. + + 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. + + + CCrreeaattiinngg tthhee ttaabblleess + 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. + ). + + 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. + + + CCrreeaattiinngg aa uusseerr eennttrryy + Create a user that has full access to the database from the list + host. How to do this depends on the RDBMS. + + + CCrreeaattiinngg tthhee lliisstt + 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). + + + 55..55.. MMaannuuaallllyy mmaanniippuullaattiinngg tthhee ssuubbssccrriibbeerrss ooff aa SSQQLL--eennaabblleedd lliisstt.. + + 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). + + + 55..66.. CCoonnvveerrttiinngg ttoo aanndd ffrroomm aanndd SSQQLL ddaattaabbaassee.. + + Just like other programs, ezmlm-list(1), ezmlm-sub(1), and ezmlm- + unsub(1) will work with normal address databases in the absence of + DDIIRR//ssqqll. However, they also have a ``-M'' switch to force this + behavior even in the presence of DDIIRR//ssqqll. 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). + + _N_o_t_e_: This inter-conversion requires the DDIIRR//ssqqll 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 DDIIRR//ssqqll exists. + + + 55..77.. OOppttiimmiizziinngg MMyySSQQLL ffoorr eezzmmllmm.. + + + 55..77..11.. AAddddrreessss SSEELLEECCTTss,, aaddddiittiioonnss,, rreemmoovvaallss.. + + 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). + + + 55..88.. MMaaiinntteennaannccee ooff tthhee MMyySSQQLL ddaattaabbaassee.. + + 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 ( + ) for more info. + + + 66.. PPoossssiibbllee eerrrroorr ccoonnddiittiioonnss iinn eezzmmllmm lliissttss.. + + + 66..11.. WWhhaatt ddoo II ddoo iiff eezzmmllmm ddooeessnn''tt wwoorrkk?? + + Try to determine where the problem occurs and how to reproduce it: + + +o Do messages to ezmlm return an error message to the sender or not? + + +o What is/are the error message(s)? + + +o What does ezmlm log into the mail log? + + +o Are you using a setup with virtual domains, and qmail<1.02 or + ezmlm-idx<0.31? If so, have you adjusted DDIIRR//iinnllooccaall (see + ``Adapting ezmlm-make for virtual domains'')? + + +o Are posts sent out to the subscribers? + + +o Are there subscribers? + + + % ezmlm-list DIR + + + + + +o Are there moderators? + + + + % ezmlm-list moddir + + + + + where ``moddir'' is the contents of DDIIRR//rreemmoottee (for remote admin + lists), of DDIIRR//mmooddssuubb (for subscription moderated lists) or DDIIRR//mmoodd-- + ppoosstt (for message moderation), if and only if the contents start with + a forward slash. The default in all cases is DDIIRR//mmoodd//. If both + DDIIRR//mmooddssuubb and DDIIRR//rreemmoottee contain directory names, the one in DDIIRR//mmoodd-- + ssuubb is used for both subscription moderation and remote admin. + + +o Are the ownerships of all files correct, i.e. read/writable for the + owner? + + + % chown -R user DIR + + + + + For lists under alias: + + + % chown -R alias DIR + + + + + If you use custom moderator databases, those directories and all their + contents must also be readable for the user under which the list oper- + ates (i.e. the user qmail changes to during the delivery). + + +o Read the qmail log and capture relevant parts. + + +o Did you customize the package at all? If so, try the default + settings which are known to work. + + +o Did you customize eezzmmllmmrrcc((55))? Try to use the default copy (skip the + -c switch). + + +o Did your customization of ..eezzmmllmmrrcc fail to have an effect? + Remember to use the -c switch. The ..eezzmmllmmrrcc file used is the one in + ``dotdir'', i.e. the directory where the ..qqmmaaiill files go, usually, + but NOT necessarily, the one in your home directory. + + +o Make sure you followed the instructions in man pages and other + documentation. Most of the problems are due to not closely + following the instructions. Try again with a new test list. + + +o Make sure to take notes of how the list was created (which flags + you used, etc.). + + +o use ezmlm-check(1) (see ``Using ezmlm-check to find setup + errors''). and compare the variables identified by ezmlm-check to + DDIIRR//iinnllooccaall, etc. If you don't get a reply from ezmlm-check, then + message was not delivered properly. Check your qmail setup. + + +o Try to find your problem or a question/item close to it in the FAQ. + + +o If this didn't resolve the problem, post to the ezmlm mailing list, + describing how you set up the list, your general setup (especially + the relevant control files for a virtual domain), what works and + what doesn't and what results from different actions (log entries, + error messages). + + If you have solved a problem that you believe might be more general, + please send a description of the problem and its solution to the + authors, ideally as a FAQ item. + + + 66..22.. HHooww ddoo II rreeppoorrtt eezzmmllmm bbuuggss?? + + If you have found a bug in the ezmlm-idx additions, please send a bug + report by E-mail to lindberg@id.wustl.edu. Describe the error, your + setup, and your system in sufficient detail so that it can be + reproduced by third parties. Include relevant sections of mail log, + and information about any error messages returned. If you ran into a + problem and resolved it on your own, include a fix as a context diff + against the distribution. + + If you have found a bug in ezmlm proper (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. + + + 66..33.. WWhheerree ddoo II sseenndd ssuuggggeessttiioonnss ffoorr eezzmmllmm--iiddxx iimmpprroovveemmeennttss?? + + E-mail to lindberg@id.wustl.edu, ideally with a context diff. For + ezmlm proper, ezmlm@list.cr.yp.to may be better. + + + 66..44.. UUssiinngg eezzmmllmm--tteesstt ttoo cchheecckk tthhee eezzmmllmm((--iiddxx)) pprrooggrraammss.. + + 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. ~~//____TTSSTTDDIIRR____eerrrr may contain a relevant error + message. For further help, E-mail lindberg@id.wustl.edu. + + + 66..55.. UUssiinngg eezzmmllmm--cchheecckk ttoo ffiinndd sseettuupp eerrrroorrss.. + + ezmlm-check(1) is included in the ezmlm-idx distribution. ezmlm- + check(1) is an evolving shell script which when put into a ..qqmmaaiill file + of a mailing list will return information about the environment + variables passed by qmail to ezmlm as well as the list setup. It also + attempts to check for common error conditions, such as HOST and + DDIIRR//iinnhhoosstt mismatch, missing files, etc. To use ezmlm-check(1), place + a line: + + + |/usr/local/bin/ezmlm/ezmlm-check 'DIR' + + + + + where ``DIR'' is the list directory, as the first line in DDIIRR//eeddiittoorr + (for mail to list), DDIIRR//mmaannaaggeerr (for mail to list-subscribe, list- + help, etc), DDIIRR//mmooddeerraattoorr (for mail to list-accept, list-reject). + ezmlm-check(1) will send its output to SENDER. The rest of the ..qqmmaaiill + file will be ignored. If you use a non-standard ezmlm binary direc- + tory, change the ezmlm-check(1) path accordingly. + + ezmlm-check(1) in combination with mail logs and ezmlm error messages + should make it easy to diagnose setup problems. When done, don't + forget to remove the ezmlm-check(1) line. It is not security-proofed + against SENDER manipulation and with it in place, the list won't work. + + ezmlm-check(1) does not check all aspects of list generation, but + catches all common errors when lists are created with ezmlm-make(1), + an many other errors as well. The ezmlm-check(1) reply is also very + valuable for support via E-mail. + + + 66..66.. PPoossttss aarree rreejjeecctteedd:: SSoorrrryy,, nnoo mmaaiillbbooxx hheerree bbyy tthhaatt nnaammee + ((##55..11..11)).. + + qmail tried to deliver the mail, but there is no mailbox with that + name. 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 ~~vviirrtt//..qqmmaaiill--tteesstt + 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 ~~uusseerr//..qqmmaaiill--tteesstt + 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 ~~vviirrtt//..qqmmaaiill--tteesstt for the list test@virtual.dom and ~~uusseerr//..qqmmaaiill-- + tteesstt for the list user-test@host. + + + 66..77.. PPoosstt aarree nnoott sseenntt ttoo ssuubbssccrriibbeerrss.. + + + NNoonn--mmooddeerraatteedd lliissttss + + 1. Read the qmail log. Is your message delivered to the list? + You can also: + + + + % cat DIR/num + + + + + 2. Send a message to the list. + + 3. See if it was received/processed: + + + + % cat DIR/num + + + + + If the number was incremented, the message went to the list, and + was successfully sent out in the opinion of ezmlm-send(1) + (ezmlm-send(1) doesn't mind if there are no subscribers, 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!). + + + MMeessssaaggee mmooddeerraatteedd lliissttss + + 1. Check number of queued messages awaiting moderation: + + + + % ls -l DIR/mod/pending + + + + + 2. Send a message to the list. + + 3. Check if another message was added to the queue: + + + + % ls -l DIR/mod/pending + + + + + A new file should have appeared. If this file has the owner exe- + cute bit set, it was successfully processed by ezmlm-store(1). + If this is true, but no moderation request was sent, then con- + tinue with ``Messages posted to the list do not result in moder- + ation requests''. If there is no new file, the message did not + reach ezmlm-store(1), or ezmlm-store(1) failed early. In both + cases, the mail log should tell you more. + + If the message is there, but the owner execute bit is not set, + ezmlm-store(1) failed. Check the mail log. Possible reasons + include a failure to find the ezmlm-send(1) binary or DDIIRR//mmssgg-- + ssiizzee is specified and the message body size is outside of the + allowed range (again, this is accompanied by an error message + and mail log entry). + + + GGeenneerraall + + 1. If the message was not received/processed, there should be an + error message in the mail log. + + 2. Fix temporary and permanent errors with the help of qmail and + ezmlm documentation. + + 3. If there is no log entry at all, then the mail went to + another host. Check your qmail setup. + + 4. If mail was delivered to the list, but not forwarded to the + subscribers (check the qmail log - there should be an entry + for a new delivery to the list), tthhee mmoosstt ccoommmmoonn eerrrroorr iiss + tthhaatt tthheerree aarree nnoo ssuubbssccrriibbeerrss.. 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. + + + 66..88.. eezzmmllmm--mmaakkee ffaaiillss:: uussaaggee:: eezzmmllmm--mmaakkee ...... + + The command line you specified is incomplete. Usually, a command line + argument has been omitted or a switch was placed after the other + arguments rather than before. + + The same error is issued when you attempt to invoke ezmlm-make(1) with + only the ``DIR'' argument without using the ``-e'' 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. + + + 66..99.. eezzmmllmm--mmaakkee ffaaiillss:: UUnnaabbllee ttoo ccrreeaattee ...... + + This error occurs when ezmlm-make is used to set up a list, and it + tries to create a directory or a ..qqmmaaiill--lliisstt link that already exists. + Usually, this occurs because the list already exists. If you are + creating a new list, first erase remnants of any old test lists by + deleting the list directory and the link files: _N_O_T_E_: _D_O _N_O_T _U_S_E _T_H_E_S_E + _C_O_M_M_A_N_D_S _W_I_T_H_O_U_T _U_N_D_E_R_S_T_A_N_D_I_N_G _T_H_E_M_. You may erase more than you + intended! + + + + % rm -rf DIR + % rm -rf ~/.qmail-list ~/.qmail-list-* + + + + + If you want to save some files (such as in DDIIRR//tteexxtt//), make backup + copies first, run ezmlm-make, then copy the backups to DDIIRR//tteexxtt//. Of + course, it is usually easier to create a custom ..eezzmmllmmrrcc, 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 DDIIRR//eeddiittoorr will be overwritten. For instance, if + you manually added checks to DDIIRR//eeddiittoorr or added a pointer to a custom + moderator database in e.g. DDIIRR//mmooddssuubb these changes will be lost. To + retain such changes (especially ones that are common for several of + your lists), place them in a local ~~//..eezzmmllmmrrcc file instead. You can + either make such changes the default for your lists, or you can + configure ~~//..eezzmmllmmrrcc so that they are added only if a specific ezmlm- + make switch is used. (see ``Customizing ezmlm-make operation''). + + + 66..1100.. eezzmmllmm--mmaakkee ffaaiillss:: ...... eezzmmllmmrrcc ddooeess nnoott eexxiisstt + + There is no readable ezmlmrc(5) file in //eettcc//eezzmmllmm nor in the ezmlm + binary directory. If you have ..eezzmmllmmrrcc in ``dotdir'' (see + ``Terminology: dotdir'') use the ezmlm-make(1) ``-c'' switch (see + ``Customizing ezmlm-make operation''). _N_o_t_e_: The default location for + a global edited eezzmmllmmrrcc file is //eettcc//eezzmmllmm//eezzmmllmmrrcc as of ezmlm- + idx-0.40. + + + 66..1111.. IInnddeexx//ggeett//tthhrreeaadd rreeqquueessttss ffaaiill qquuiieettllyy oorr wwiitthh eerrrroorrss ffrroomm + eezzmmllmm--mmaannaaggee.. + + Make sure this is an indexed list and has an ``ezmlm-get'' line first + in DDIIRR//mmaannaaggeerr. If not, your commands are fed directly to ezmlm- + manage(1). If they contain ``-'', ezmlm-manage interprets the rest as + an address to which it sends the error message. Usually, this results + in a "trash address" mail log entry and a bounce, which is why you + don't see any error message. The same happens if you send non-existing + commands followed by ``-'' and arguments. Thus, list-gugu-54@host + results in an ezmlm-manage error, resulting in help text being sent to + 54@localhost ... When testing, try using syntax with a ``.'', not a + ``-'', after the action command, e.g. list-get.54_60@host. This will + assure that error messages get back to you. + + + 66..1122.. DDiiggeesstt ttrriiggggeerriinngg rreeqquueessttss ffaaiill.. + + (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. + + + 66..1133.. RReemmoottee aaddmmiinniissttrraattiioonn ((uunn))ssuubbssccrriibbee ccoonnffiirrmm rreeqquueessttss ggoo ttoo tthhee + uusseerr,, nnoott tthhee mmooddeerraattoorr.. + + Either the list is not set up for remote administration (i.e. + DDIIRR//rreemmoottee does not exist), or the moderator is sending the request + from an address that is not in the moderator database (e.g. from + Fred@host.dom, when fred@host.dom is in the moderator db, but + Fred@host.dom is not). ezmlm-manage(1) has no way of knowing that the + SENDER is a moderator and treats the request as coming from a regular + user, i.e. it sends a confirmation request to the target address. + Correct the SENDER address, the address in the moderator db, or create + DDIIRR//rreemmoottee. If you are using a non-default moderator db location, make + sure that the moddir name is in DDIIRR//rreemmoottee (for remote admin only) or + DDIIRR//mmooddssuubb (if there is subscription moderation as well). In both + cases, the contents will be ignored unless they start with a ``/''. + + + 66..1144.. ((UUnn))ssuubbssccrriibbeerrss ddooeess nnoott rreecceeiivvee aa ((uunn))ssuubbssccrriibbee aacckknnoowwlleeddggee-- + mmeenntt + + With normal ezmlm lists, a subscriber confirming a subscription or a + non-subscriber confirming a unsubscribe request results in a message + to the target address. This message is suppressed when the list is set + up for subscription and/or remote administration, 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). + + + 66..1155.. MMeessssaaggeess ppoosstteedd ttoo aa mmooddeerraatteedd lliisstt aarree sseenntt oouutt wwiitthhoouutt mmooddeerr-- + aattiioonn.. + + The list is not set up as a moderated list. Check DDIIRR//eeddiittoorr. If + should contain a ezmlm-store(1) line after the ezmlm-reject line if it + is a moderated list. No ezmlm-send(1) line should be in DDIIRR//eeddiittoorr. + If there is, the list is not moderated. Also, DDIIRR//mmooddppoosstt must exist. + If it does not, ezmlm-store(1) will post the messages directly (via + ezmlm-send(1)) without sending them out for moderation first. This + makes it easy to temporarily remove message moderation by simply + removing DDIIRR//mmooddppoosstt, but may be confusing if the user is unaware of + this ezmlm-store(1) feature. + + + 66..1166.. MMeessssaaggeess ppoosstteedd ttoo aa mmooddeerraatteedd lliisstt ddoo nnoott rreessuulltt iinn mmooddeerraattiioonn + rreeqquueessttss.. + + + +o Check that ~~//..qqmmaaiill--lliisstt is a link to DDIIRR//eeddiittoorr. + + +o Check that DDIIRR//eeddiittoorr contains ezmlm-store(1) and not ezmlm- + send(1). If this is not the case, the list is not message + moderated. + + +o Check for the presence of DDIIRR//mmooddppoosstt. If this file is missing, the + list is not moderated, even if DDIIRR//eeddiittoorr is set up with ezmlm- + store(1). + + +o Check qmail logs for error conditions during post delivery and + correct these. If the messages are delivered correctly, verify that + ezmlm-store(1) generated the moderation requests to the moderators. + + +o Check to see that there are indeed moderators: + + + + % ezmlm-list moddir + + + + + where ``moddir'' is the contents of DDIIRR//mmooddppoosstt if they start with a + ``/'', otherwise those of DDIIRR//rreemmoottee (same ``/'' requirement), and + DDIIRR//mmoodd// by default. + + + +o Check file ownerships. + + Another common problem is directory ownerships, especially for + lists under ~alias. To correct this error, issue the following + command while in the ~alias directory (User the user/group of the + list owner; for ~alias lists user=alias, group=qmail): + + + % chown -R user DIR + + + + + + 66..1177.. MMooddeerraattiioonn rreeqquueesstt rreepplliieess ddoo nnoott rreessuulltt iinn tthhee aapppprroopprriiaattee + aaccttiioonn.. + + + +o Check that the address in the moderation request is correct. + + +o Check that the ~~//..qqmmaaiill--lliisstt--aacccceepptt--ddeeffaauulltt and ~~..//qqmmaaiill--lliisstt-- + rreejjeecctt--ddeeffaauulltt links exists and point to DDIIRR//mmooddeerraattoorr. + + +o Check that DDIIRR//mmooddeerraattoorr invokes ezmlm-moderate(1), and that there + is a copy of ezmlm-send(1) in the ezmlm binary directory. + + +o Check the qmail log to see that the replies were delivered to this + address. + + +o Check directory ownerships. For lists under alias: + + + + % chown -R alias DIR + + + + + _N_O_T_E_: This needs to be done every time you add/remove moderators as + ``root''. For user-controlled lists (i.e. you are ``user'' when run- + ning e.g. ezmlm-sub(1)) this is not a problem. + + If setting up lists for _a_l_i_a_s, you can avoid many problems by setting + them up as ``alias'', i.e. use ``su alias'' not ``su''. + + If setting up lists for a user controlling a virtual domain, you can + avoid many problems by assuming that uid (``su user'') before making + any changes. + + +o Check the qmail logs: After the delivery of the moderation request, + ezmlm-send(1) should run to send messages to all the list + subscribers. + + +o Make sure there are list subscribers: + + + + % ezmlm-list DIR + + + + + Most error conditions, incorrect request cookies, etc, should result + in informative error messages in the mail log. + + + 66..1188.. MMooddeerraattoorr ccoommmmeennttss wwiitthh mmooddeerraattiioonn rreeqquueesstt rreepplliieess aarree nnoott + aaddddeedd ttoo tthhee ppoosstt//sseenntt ttoo tthhee ppoosstteerr.. + + Moderator comments are where the moderator chooses to ``reject'' the + message and inform the person posting which his/her message was + inappropriate. However, if a moderator wants to comment on aacccceepptteedd + 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 + DDIIRR//eeddiittoorr 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>%%% + + + + + 66..1199.. SSoommee hheeaaddeerrss aarree mmiissssiinngg ffrroomm mmeessssaaggeess iinn tthhee ddiiggeesstt.. + + By default, only a subset of message headers are sent out in any + digest and archive retrieval requests. First, headers in + DDIIRR//hheeaaddeerrrreemmoovvee are stripped. Most non-essential headers are excluded + when the default archive retrieval format (``m'') is used. Use the + ``v'' or ``n'' format (see ezmlm-get(1)) to get all message headers + that are in the archive. + + + 66..2200.. SSoommee RReecceeiivveedd:: hheeaaddeerrss aarree mmiissssiinngg ffrroomm mmeessssaaggeess.. + + 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. + + + 66..2211.. MMyy MMuutttt uusseerrss ccaannnnoott tthhrreeaadd tthheeiirr ddiiggeesstt mmeessssaaggeess.. + + The digest by default removed non-essential headers like ``In-Reply- + To:'' from messages. Modern MUAs, like _M_u_t_t can split out messages + from a digest and then thread them based on such headers. To include + these and all other headers in the digest messages, use the ``v'' or + ``n'' format as described on the ezmlm-get(1) man page. Normally, the + threading done by ezmlm is sufficient and the default format preferred + to reduce message and digest size, often by 25% or more. + + + 66..2222.. PPoossttss ffaaiill:: MMeessssaaggee aallrreeaaddyy hhaass MMaaiilliinngg--LLiisstt ((##55..77..22)).. + + The list you are trying to post to is used as a sublist (a list fed + with messages from another (ezmlm) list), but not properly set up as a + sublist. Put the name of the parent list (``origlist@orighost'') + which exactly matches the SENDER of the original (or parent) list into + DDIIRR//ssuubblliisstt. Check the ownership of DDIIRR//ssuubblliisstt, to make sure that + the user controlling the list can read it. + + Alternatively, use the ezmlm-make(1) ``-0 origlist@orighost'' switch + (see ``Customizing ezmlm-make operation''). + + + 66..2233.. TThhee llaasstt lliinnee ooff aa DDIIRR//tteexxtt// ffiillee iiss iiggnnoorreedd.. + + Only complete lines ending with ``newline'' are copied. The last line + in the DDIIRR//tteexxtt// file most likely lacks a terminal ``newline''. + + + 66..2244.. NNoo CCOONNFFIIRRMM rreeqquueessttss aarree sseenntt ttoo mmooddeerraattoorrss.. + + Assuming that the user initiated the subscribe request, got a + ``confirm'' request, and replied correctly, there are two possible + causes for the problem: Either the list is not subscription moderated + (in this case the user is subscribed and received a note saying so) or + the list is subscription moderated 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 ``DDIIRR//mmoodd//''. + + Check for moderators: + + + + % ezmlm-list moddir + + + + + If there are none, this is your problem. If there are some, check the + mail log to see what happened when the CONFIRM requests was supposed + to have gone out. Assure correct ownerships for the moderator db: + + + + % chown -R user moddir + + + + + For ~alias: + + + + # chown -R alias moddir + + + + + Another possible problem is that you are trying to use the remote + admin feature to subscribe a user, but you get no CONFIRM request. + Usually, this is due to your SENDER address not being in the moderator + database. The CONFIRM request went to the target address instead, + since as far as ezmlm is concerned, you are a regular user. + + + 66..2255.. DDeelliivveerriieess ffaaiill ````tteemmppoorraarryy qqmmaaiill--qquueeuuee eerrrroorr'''' + + Usually, this is due to a corrupted qmail queue (should affect all + mail) or a corrupted ezmlm subscriber database (See ``How to deal with + corrupted subscriber lists''). ezmlm-idx>=0.40 has more informative + qmail error messages. + + + + + + 66..2266.. HHooww ttoo ddeeaall wwiitthh ccoorrrruupptteedd ssuubbssccrriibbeerr lliissttss + + Dan has made ezmlm very robust, but a subscriber list can still become + corrupted due to e.g. disk errors. Usually, this will lead to a + ``temporary qmail-queue error'' because an address does not conform to + the standard format. Occasionally, two E-mail addresses are fused, + e.g. ``addr1@hostTaddr2@host''. To diagnose and fix this type of + error, disable deliveries (easiest is to ``chmod 0 DIR/lock''), back + up the contents of DDIIRR//ssuubbssccrriibbeerrss//, then: + + + + % ezmlm-list DIR > tmp.tmp + + ( edit tmp.tmp to fix any problems ) + + % rm -rf DIR/subscribers/* + % 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. + + + 66..2277.. VVaaccaattiioonn pprrooggrraamm rreepplliieess aarree ttrreeaatteedd aass bboouunncceess bbyy eezzmmllmm.. + + Standard vacation programs do not reply to messages that contain a + ``Precedence: bulk'' header. ezmlm-idx>=0.23 sets up lists with this + header in DDIIRR//hheeaaddeerraadddd. For older lists, use ``ezmlm-make -+'' or + ``ezmlm-make -e'' to update them, or just add a ``Precedence: bulk'' + line to DDIIRR//hheeaaddeerraadddd. + + + 66..2288.. DDiiggeessttss ddoo nnoott ccoommee aatt rreegguullaarr hhoouurrss.. + + In the default setup, ezmlm-tstdig(1) determines if a new digest is + due every time a message arrives to the list. Thus, even though ezmlm- + tstdig is set to produce digests 48 hours after the previous digest, + the digest will not be generated until a message arrives. If you'd + like digests at a specific time each day, use crond(8) and crontab(1) + to daily run: + + + % ezmlm-get DIR + + + + + + 66..2299.. PPrreevveennttiinngg llooooppss ffrroomm mmiissccoonnffiigguurreedd ssuubbssccrriibbeerr aaddddrreesssseess.. + + Occasionally, a subscriber address is misconfigured and automatically + sends a message back to the list. Sometimes, the subscriber's setup + has removed headers that ezmlm uses for loop detection or the + generated messages has nothing in common with the send-out. To block + such mail at the list, include the ezmlm-make(1) ``-k'' (kill) switch + and add the offending address to DDIIRR//ddeennyy// 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 DDIIRR//eeddiittoorr or DDIIRR//mmaannaaggeerr. This + discards the bounce messages generated by the looping systems. ezmlm- + weed(1) is also useful in other settings where excessive numbers of + error messages are sent to the wrong address. + + + 66..3300.. AA uusseerr ccaann ssuubbssccrriibbee aanndd rreecceeiivveess wwaarrnniinngg aanndd pprroobbee mmeessssaaggeess,, + bbuutt nnoo mmeessssaaggeess ffrroomm tthhee lliisstt.. + + ezmlm lists (ezmlm-idx>=0.31) remove ``Received:'' headers from + incoming messages by default. This can be prevented with the ezmlm- + send(1) ``-r'' switch. When the headers are propagated, especially + sublist message may have many (15-20 or more), ``Received:'' headers. + If there is a poorly configured sendmail host with a ``hopcount'' set + too low, it will bounce these messages, incorrectly believing that the + many ``Received:'' headers are due to a mail loop. The reason that + administrative from the list do not bounce is that they have fewer + ``Received:'' headers, since they originate from the sublist. + + The message with all headers including the removed ``Received:'' + headers can be retrieved from the list archive with the _-_g_e_t_v command. + The top incoming ``Received:'' header is added by qmail at the receipt + to the list (or last sublist) host. This header is not removed, to + allow the recipient to determine when the message reached the list. + + + 77.. CCuussttoommiizziinngg eezzmmllmm--mmaakkee ooppeerraattiioonn vviiaa eezzmmllmmrrcc + + + 77..11.. UUssiinngg eezzmmllmm--mmaakkee ttoo eeddiitt eexxiissttiinngg lliissttss.. + + With ezmlm-make(1) (from ezmlm-idx >=0.21) you can use the ``-e'' + switch to edit existing lists. Invoke the ezmlm-make(1) command just + as you would to create the list anew, but change the switches to + reflect the desired change, and add the ``-e'' switch. ezmlm-make will + accept preexisting directories and overwrite or remove files to change + the setup. The message counter (DDIIRR//nnuumm), digest counters (DDIIRR//ddiiggnnuumm + and DDIIRR//ddiiggiissssuuee), the key (DDIIRR//kkeeyy) and the message archive will not + be affected. + + If the list has been created or previously edited with ezmlm-make(1) + from ezmlm-idx>=0.23, the list remembers (via DDIIRR//ccoonnffiigg) the + arguments and the switches. 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. + + _N_O_T_E_: ezmlm-make(1) ``-e'' and ``-+'' will OVERWRITE any manual + customizations you have made to the program files, but not text files + and DDIIRR//hheeaaddeerraadddd, DDIIRR//hheeaaddeerrrreemmoovvee, etc. To reset all such files + (such as when changing list name), use ``-ee'' or ``-++''. + + To make general customizations, please change eezzmmllmmrrcc((55)) (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''). + + + 77..22.. WWhhaatt iiss eezzmmllmmrrcc?? + + ezmlm-make(1) has a number of default switches that through eezzmmllmmrrcc((55)) + 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 eezzmmllmmrrcc((55)) file in + //eettcc//eezzmmllmmrrcc (or symlinked from there) which overrides the file in the + ezmlm binary directory. If the ezmlm-make(1) ``-c'' (custom) switch is + used, ezmlm-make(1) will look for ..eezzmmllmmrrcc in the ``dotdir'', i.e. the + directory in which the ..qqmmaaiill--lliisstt links are placed. This is usually a + set directory for a given user/virtual domain (usually, the home + directory for the user controlling the lists). + + eezzmmllmmrrcc((55)) controls everything except creation of the list directory + itself and the key used for cookie generation. The syntax of + eezzmmllmmrrcc((55)) 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. + + + 77..33.. CChhaannggiinngg ddeeffaauullttss ffoorr DDIIRR//tteexxtt// ffiilleess.. + + Copy the ezmlmrc(5) file from the ezmlm bin directory to ..eezzmmllmmrrcc in + your ..qqmmaaiill file base directory (usually your home directory): + + + % cp /usr/local/bin/ezmlm/ezmlmrc ~/.ezmlmrc + + + + + The base eezzmmllmmrrcc((55)) file lives in the ezmlm binary directory, which + may differ from ``//uussrr//llooccaall//bbiinn//eezzmmllmm//eezzmmllmmrrcc'' if you do not have a + default setup. If your system administrator has placed a ezmlmrc(5) + file into the //eettcc directory, start with that one instead, as it is + likely to already contain some useful local customization and + comments. + + Now edit ~~//..eezzmmllmmrrcc. Find the tag corresponding to the text file you + want to change, e.g. ``'', 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 ``'' is copied into DDIIRR//tteexxtt//ffiillee if and + only if the ezmlm-make(1) ``-rms'' switches are all used. For more + info, see documentation in eezzmmllmmrrcc((55)) and the ezmlm-make(1) man page. + To invoke a custom ..eezzmmllmmrrcc file, use the ezmlm-make(1) ``-c'' + (custom) switch. + + + 77..44.. CChhaannggiinngg ddeeffaauulltt mmooddeerraattoorr ddiirreeccttoorriieess.. + + See above. Edit the ..eezzmmllmmrrcc file to add a directory name to e.g. + ``''. Also, you need to create that directory, and the + subscribers subdirectory under it. NOTE: DDIIRR//mmoodd// is still required as + the base directory for the message moderation queue. + 77..55.. AAddaappttiinngg eezzmmllmm--mmaakkee ffoorr vviirrttuuaall ddoommaaiinnss.. + + 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 DDIIRR//iinnllooccaall. However, if the domain host1.dom.com is + controlled by the user ``virt'', then the local part of the address + for the list list@host.dom.com will be ``virt-list'', not ``list''. + This is easily accommodated by putting a ..eezzmmllmmrrcc file in ~~vviirrtt//. In + the ``'' section of this file, enter ``virt-<#L#>'' instead + of ``<#L#>''. Now, all lists created under ~~vviirrtt will be + automatically set up correctly. + + Similarly, if host1.dom.com is controlled by virt-dom1 and + host2.dom.com by ``virt-dom2'', inlocal for list list@host1.dom.com + should be ``virt-dom1-list'' and for list@host2.dom.com should be + ``virt-dom2-list''. To accommodate this, put ``virt-<#1#>-<#L#>'' in + ``''. + + Running: + + + % ezmlm-make -c ~virt/LIST ~virt/.qmail-dom1-list \ + list host1.dom.com + + + + + will produce a LLIISSTT//iinnllooccaall of virt-dom1-list by substituting the + first part between two ``-'' (dom1) for ``<#1#>''. Two levels of + dashes are accommodated, i.e. ``<#2#>'' will be replaced by the second + part between two ``-'' (in this case empty (_S_i_c_!)). For more info, + see ezmlm-make(1) and comments in eezzmmllmmrrcc. + + + 77..66.. SSeettttiinngg uupp eezzmmllmm--mmaakkee ffoorr ssppeecciiaall ssiittuuaattiioonnss.. + + Ezmlm-make is very flexible. There are only three sets of special + command line switches: ``-vV'' for version info, ``-cC'' controlling + the use of a custom file ..eezzmmllmmrrcc in the ``dot'' directory, and + ``-eE'' for edit mode (i.e. reconfiguration of existing list setups). + All other switches are soft, i.e. controlled through eezzmmllmmrrcc((55)). Many + switches, have special meanings via eezzmmllmmrrcc((55)) and are documented in + the man page. Any other switches can be used for customization (_N_O_T_E_: + _w_e _m_a_y _u_s_e _s_w_i_t_c_h_e_s _o_t_h_e_r _t_h_a_n _`_`_-_x_y_z_'_' _f_o_r _s_p_e_c_i_f_i_c _p_u_r_p_o_s_e_s _i_n + _f_u_t_u_r_e _v_e_r_s_i_o_n_s_.) The ``-xyz'' switches will always be available for + your use, with the ``-x'' switch being configured for some + demo/special features in the distributed eezzmmllmmrrcc((55)). You can use them + for anything you like. They are by default off=false. The complement + of these switches is ``-XYZ'' (by default on=true). You can use these + to cause specific changes in the list setup if a given switch is used. + For an example, see the ``-x'' switch as used and documented in the + default eezzmmllmmrrcc((55)) 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 DDIIRR//ccoonnffiigg (if available). + + + 88.. RReessttrriiccttiinngg mmeessssaaggee ppoossttiinngg ttoo tthhee lliisstt.. + + + + 88..11.. RReeqquuiirriinngg tthhee lliisstt aaddddrreessss iinn TToo:://CCcc:: hheeaaddeerrss.. + + 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. + + + 88..22.. RReejjeeccttiinngg mmeessssaaggeess sseenntt ffrroomm ootthheerr mmaaiilliinngg lliissttss.. + + ezmlm automatically detects are rejects messages that are sent from + other ezmlm mailing lists. Some other mailing list managers do not use + a rigorous mechanisms to verify subscribers. Thus, it is possible to + subscribe an ezmlm list address to such a mailing list. You can easily + block such a list by adding the address to the ``deny'' if you use the + ezmlm-make(1) ``-k'' option. However, you can also configure ezmlm- + reject(1) to reject messages based on specific headers placed into + DDIIRR//hheeaaddeerrrreejjeecctt. A set of headers which will catch mailing list + managers known to us are listed in the ezmlm-reject(1) man page. To + activate this option, you must specify the ``-h'' switch and DDIIRR on + the ezmlm-reject(1) line in DDIIRR//eeddiittoorr. Naturally, you can make this + the default by editing ezmlmrc(5) (See ``Customizing ezmlm-make + operation''). + + + 88..33.. RReessttrriiccttiinngg ppoossttss bbaasseedd oonn tthhee SSuubbjjeecctt lliinnee.. + + ezmlm-reject(1) is by default configured to reject posts with empty + subject (``-s'' switch) or with a subject that consists of only an + administrative command word (``-c'' switch), such as ``subscribe''. To + remove these restrictions, use the ezmlm-reject(1) ``-S'' and ``-C'' + switch, respectively. You can also into DDIIRR//eeddiittoorr 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 DDIIRR//bbaadd__wwoorrddss. + + + 88..44.. RReessttrriiccttiinngg tthhee ssiizzee ooff ppoossttss.. + + If the ``DIR'' argument is specified on the ezmlm-reject(1) line in + DDIIRR//eeddiittoorr and DDIIRR//mmssggssiizzee exists and contains a number (in bytes) + greater than ``0'', then any posts with a body larger than the number + specified is rejected. The maximum message size can optionally be + followed by ``:'' and a minimum message body size in bytes. For + moderated lists, messages that are too large are rejected and not sent + to the moderators. This feature can be used to prevent the posting an + entire digest to the list by setting DDIIRR//mmssggssiizzee slightly below the + message size set in your ezmlm-tstdig(1) innovation (if any). A + minimum size can catch a few administrative request sent to the main + list, but is otherwise not that useful. To always configure your lists + with a message size restriction, add to eezzmmllmmrrcc((55)): + + + + max:min + + + + + The ezmlm-make(1) ``-x'' switch adds this with 40000:2. + + + 88..55.. RReessttrriiccttiinngg ppoossttss bbaasseedd oonn MMIIMMEE ccoonntteenntt--ttyyppee.. + + ezmlm-reject(1) will look for DDIIRR//mmssggssiizzee, DDIIRR//mmiimmeerreejjeecctt, and + DDIIRR//mmiimmeerreemmoovvee if the ``DIR'' argument is specified (``DIR'' can be + left out to conserve resources on lists that do not use these + features). _N_o_t_e_: _T_h_e _`_`_D_I_R_'_' _a_r_g_u_m_e_n_t _i_s _a_l_s_o _r_e_q_u_i_r_e_d _f_o_r _t_h_e _t_h_e + _T_o_:_/_C_c_: _l_i_s_t _a_d_d_r_e_s_s _r_e_s_t_r_i_c_t_i_o_n _(_s_e_e _`_`_R_e_q_u_i_r_i_n_g _t_h_e _l_i_s_t _a_d_d_r_e_s_s _i_n + _T_o_:_/_C_c_: _h_e_a_d_e_r_s_'_'_)_. If the message contains MIME parts that are of a + content-type listed in DDIIRR//mmiimmeerreejjeecctt they are rejected. If the + message is a simple MIME message of a content-type listed in either + DDIIRR//mmiimmeerreejjeecctt or DDIIRR//mmiimmeerreemmoovvee it is also rejected. + + There is currently no ezmlm-make(1) switch for DDIIRR//mmiimmeerreejjeecctt, but it + can easily be configured by editing eezzmmllmmrrcc((55)). The ezmlm-make ``-x'' + switch configures DDIIRR//mmiimmeerreemmoovvee (see ``mimeremove'') for a list of + content-types). Messages consisting solely of these content-types + (rare) will be rejected, and the corresponding MIME parts of composite + messages will be removed. + + + 88..66.. RReessttrriiccttiinngg ppoossttss ttoo lliisstt ssuubbssccrriibbeerrss.. + + 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; } + + + + + _A_L_L _O_N _O_N_E _L_I_N_E to DDIIRR//eeddiittoorr before the ezmlm-send(1) line. ``DIR'' + is the main list directory. If your ezmlm binaries live in a different + directory, change the ezmlm-issubn(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 + DDIIRR//ddiiggeesstt// from the ezmlm-issubn command line. To allow posts from an + address that is not a subscriber, simply add it to the addresses in + DDIIRR//aallllooww//: + + + % 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)''. + + + + 88..77.. RReessttrriiccttiinngg ppoossttss ttoo aann aarrbbiittrraarryy sseett ooff EE--mmaaiill aaddddrreesssseess + ((hhiigghheerr sseeccuurriittyy ooppttiioonn)).. + + The easiest way to achieve this is to simply set up a message + moderated list, and add all the e-mail addresses to the moderator db. + Use a custom location, if you want a different set of moderators for + subscription moderation/remote admin. If a "moderator" posts, only + s/he will get a confirmation request. If anybody else posts, the post + will be sent to all moderators. + + + To directly bounce posts from SENDERs not in the database, use the + ezmlm-store ``-P'' (not public) switch. This is more secure than a + simple ezmlm-issubn(1) construct, since faking SENDER to a moderator + address will result in a confirmation request to that moderator (which + s/he will reject/ignore), rather than a direct post. The draw-back is + that each post has to be confirmed, but with the speed of ezmlm the + request will arrive immediately after the post is made, so the + overhead should 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. + + + 88..88.. CCoommpplleetteellyy rreessttrriiccttiinngg ppoossttss.. + + To completely prevent posting (for instance a message-of-the-day + list), set up a normal list, and just remove ~~//..qqmmaaiill--lliisstt and + DDIIRR//eeddiittoorr altogether. Make posts from the shell, or from shell + scripts or crond, by simply piping a (complete) message to ezmlm- + send(1): + + + + % /usr/local/bin/ezmlm/ezmlm-send DIR < message + + + + + _N_O_T_E: 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 DDIIRR//ssuubbssccrriibbeerrss// and other address lists. + + + 88..99.. AA ggeenneerraall ssoolluuttiioonn ttoo rreessttrriiccttiinngg ppoossttss bbaasseedd oonn SSEENNDDEERR.. + + As discussed above, the security afforded by SENDER checks is minimal, + but nevertheless sufficient to keep out most spam and garbage. + However, some subscribers post from e-mail addresses other than their + subscription address, and users tend to become unfriendly when their + posts are denied even though they are subscribers. This is a general + solution to this problem which has minimal overhead for the list owner + and is essentially completely transparent to the subscriber. + + Set up the list with ezmlm-gate(1) in DDIIRR//eeddiittoorr in place of the + ezmlm-send(1) line. To the ezmlm-gate(1) command line add the list + directory twice, then a digest directory DDIIRR//ddiiggeesstt// (if it exists), + then DDIIRR//aallllooww//. Create DDIIRR//mmooddppoosstt. Add the list owner as a message + moderator. + + With this setup, any message from a SENDER that is a subscriber of the + main list, the digest list or added to DDIIRR//aallllooww//, will be posted + directly, others will be sent to the list owner for approval. If the + list wants to automatically approve posts from that address in future + (e.g. it is an alias for a subscriber) s/he just adds it to the + database in DDIIRR//aallllooww//. If the owner wants to approve this post, but + not necessarily future posts from that address, s/he just accepts the + message. To reject the message with a comment is equally easy. If the + owner wished to have the option to silently ignore posts (and not have + the SENDER notified that the post timed out), just add the ezmlm- + clean(1) ``-R'' switch in DDIIRR//eeddiittoorr and DDIIRR//mmooddeerraattoorr. + + In this way, the normal subscriber is always happy and the ``behind + the scenes'' work of the owner is minimalized. + + ezmlm-make creates lists with this setup if you specify the ``-u'' + switch in addition to the ``-m'' switch: + + + + % ezmlm-make -mu ~/list ~/.qmail-list joe-list host + + + + + 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. + + + 99.. CCuussttoommiizziinngg oouuttggooiinngg mmeessssaaggeess.. + + + 99..11.. AAddddiinngg aa ttrraaiilleerr ttoo oouuttggooiinngg mmeessssaaggeess.. + + Put the text in DDIIRR//tteexxtt//ttrraaiilleerr. The text is NOT copied to the + archived version of the message. This works also for sublists. Tags + ``<#h#>'', ``<#l#>'', and ``<#n#>'' are replaced by the list host, + local name, and current message number, respectively. + + + 99..22.. AAddddiinngg aa ssuubbjjeecctt pprreeffiixx ttoo oouuttggooiinngg mmeessssaaggeess.. + + Put the exact text in DDIIRR//pprreeffiixx. You can include the message number + assigned to the post in the list archive by adding the ``#'' character + in the text in DDIIRR//pprreeffiixx (example: put ``lsqb;listname-#rsqb;'' in + DDIIRR//pprreeffiixx). ezmlm does not modify the subject other than by + prefixing it with the prefix. ezmlm knows about rfc2047 encoded + subject and can detect a prefix within an encoded word. However, ezmlm + will not modify the subject itself. It will add a prefix only of none + has been added before. A consequence of this is that a message will + have the message number prefix of the first message in the thread + rather than a prefix with the number of the message itself. The entire + thread can always be retrieved with a message to list-thread-x@host, + where ``x'' is the number in the prefix. + + We recommend against using the prefix feature and strongly against the + message number prefix. If you use it, make sure you understand the + drawbacks, of message modification and subjects that change between + message and reply. ezmlm can deal with this, but other programs may + not be able to. + + Sublists ignore DDIIRR//pprreeffiixx. + + If you add a prefix, especially if you previously added it by other + means (procmail, etc.), use ezmlm-idx to re-index the archive. Due to + the way ezmlm-get(1) does threading from the subject, it works best if + you use exactly the same prefix as you did before. + + + 99..33.. AAddddiinngg aa hheeaaddeerr ttoo oouuttggooiinngg mmeessssaaggeess.. + + Put the exact header text as a line in DDIIRR//hheeaaddeerraadddd. Thus, if you'd + like a ``Precedence: bulk'' header added to outgoing messages, put a + line ``Precedence: bulk'' into DDIIRR//hheeaaddeerraadddd. 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 DDIIRR//hheeaaddeerraadddd, 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. + + + 99..44.. AAddddiinngg aa mmeessssaaggee nnuummbbeerr hheeaaddeerr.. + + Don't! A sequence header may be useful for users whose systems don't + pass on the ``Return-to:'' header to the MUA. + + Use DDIIRR//hheeaaddeerraadddd 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 DDIIRR//sseeqquueennccee on the sublist, + not the main list. To get consistent message numbering in digests, + digest have the message number of the first message in the digest. + + ezmlm-idx tries to make message numbering problems with sublists a + little easier: sublists use the incoming message number, but only when + the sublist is not archived and not indexed. This restriction is + necessary for security reasons. Otherwise, an attacker could wreak + havoc in the local message archive by sending messages with faked + message numbers in the SENDER. + + 99..55.. RReemmoovviinngg hheeaaddeerrss ffrroomm oouuttggooiinngg mmeessssaaggeess.. + + Put the header up to, but excluding the ``:'' in DDIIRR//hheeaaddeerrrreemmoovvee. + + + 99..66.. RReemmoovviinngg MMIIMMEE ppaarrttss ffrroomm mmeessssaaggeess.. + + ezmlm-idx>=0.30 can strip parts from composite mime messages based on + content type. Just put the appropriate content-types such as + ``text/ms-word'' or ``text/html'' into DDIIRR//mmiimmeerreemmoovvee. This is + automatically configured when using the ezmlm-make(1) ``-x'' switch. + + + 99..77.. LLiimmiittiinngg ````RReecceeiivveedd::'''' hheeaaddeerrss iinn oouuttggooiinngg mmeessssaaggeess.. + + Sendmail still is being used on the majority of mail hubs. Sendmail + has very primitive loop detection, bouncing messages based on + excessive ``hopcount''. The ``hopcount'' is determined by counting + ``Received:'' headers. ezmlm by default propagates ``Received:'' + headers to facilitate message tracking. Thus, messages, especially + from a sublist, can have a number of ``Received:'' headers that + exceeds the ``hopcount'' set on poorly configured sendmail hosts. + Subscription confirmation requests, warning, and probe messages have + fewer ``Received:'' headers. Thus, a user may be able to receive + these, but not (some of the) list messages. Of course, the best is to + correct the configuration on the bouncing host, but this is often + under the control of neither list owner nor user. + + To compensate for this problem, ezmlm-send(1) of ezmlm-idx->=0.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. + + + 99..88.. SSeettttiinngg ````RReeppllyy--TToo:: lliisstt@@hhoosstt''''.. + + This is not recommended, since it leads to dissemination via the list + of messages returned from bad auto-responders and MTAs. Also, it may + lead to public replies to the list where personal replies were + intended. In addition, the original ``Reply-To:'' header is lost. If + you do want to add a reply-to list header, put ``reply-to'' into + DDIIRR//hheeaaddeerrrreemmoovvee, and ``Reply-To: list@host.dom'' into DDIIRR//hheeaaddeerraadddd. + + + 99..99.. CCoonnffiigguurriinngg tthhee lliisstt ssoo ppoossttss aarree nnoott ccooppiieedd ttoo tthhee oorriiggiinnaall + sseennddeerr.. + + For most mailing lists, you want all subscribers, including the sender + of a particular message, to get all messages. This way, the sender + sees that the message reached the list. For small lists, such as a + project group, it may be annoying for the members to receive their own + posts. + + ezmlm-send(1) can be configured to exclude the sender from the + recipient E-mail addresses if configured with the ``-C'' switch. To + add this switch, edit the ezmlm-send(1) line of DDIIRR//eeddiittoorr. + + + 99..1100.. CCuussttoommiizziinngg eezzmmllmm nnoottiiffiiccaattiioonn mmeessssaaggeess.. + + Most of ezmlm's more commonly used messages are stored in DDIIRR//tteexxtt//. + These messages can be edited manually for a list once it is set up, or + on a global basis via modification of eezzmmllmmrrcc((55)). 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 DDIIRR//tteexxtt//ssuubb--ookk (and for subscription + moderated lists DDIIRR//tteexxtt//mmoodd--ssuubb) for new subscriber information (such + as the traditional ``welcome'' message, or a list charter or list + posting rules/guidelines); DDIIRR//tteexxtt//uunnssuubb--nnoopp is useful for messages + to frustrated users unsuccessful in their unsubscribe attempts; + DDIIRR//tteexxtt//hheellpp for general help information in reply to list-help@host + or unrecognized commands, DDIIRR//tteexxtt//bboottttoomm for inclusion at the bottom + of virtually all ezmlm messages; DDIIRR//tteexxtt//mmoodd--hheellpp for moderator + information; DDIIRR//tteexxtt//ttrraaiilleerr for a (few) line(s) at the bottom of + each post; DDIIRR//tteexxtt//ddiiggeesstt for information in the ``Administrivia'' + section of digests. + + + 99..1111.. SSppeecciiffyyiinngg cchhaarraacctteerr sseett aanndd ccoonntteenntt--ttrraannssffeerr--eennccooddiinngg ffoorr oouutt-- + ggooiinngg eezzmmllmm mmeessssaaggeess.. + + All ezmlm replies, except errors handled directly by qmail, can be + sent in any character set and optionally with quoted-printable or + base64 content-transfer-encoding. DDIIRR//tteexxtt// files are always 8-bit + files, but even though qmail has no problems with 8-bit mail, other + MTAs and MUAs do. Problems due to this can be avoided by assuring + that outgoing ezmlm messages are 7bit by using the appropriate + content-transfer-encoding. + + To specify a character set, put the name in DDIIRR//cchhaarrsseett (default: us- + ascii). To specify quoted-printable or base64 content-transfer- + encoding, add ``:Q'' or ``:B'' after the character set name in + DDIIRR//cchhaarrsseett. + + + 1100.. CCuussttoommiizziinngg aarrcchhiivvee rreettrriieevvaall.. + + + 1100..11.. SSppeecciiffyyiinngg tthhee ffoorrmmaatt ffoorr rreettrriieevveedd mmeessssaaggeess.. + + Add a format (f) specifier after the archive retrieval command: + + + + list-getf@host + + + + + where ``f'' is ``r'' for rfc1153 format, ``m'' (mime; default) for + MIME multipart/digest with subset of ordered headers, and ``v'' (vir- + gin) MIME multipart/digest, i.e. with all headers retained from the + archive, and ``n'' (native) the same as ``v'' except that no threading + is performed and messages are returned in numerical order. Under some + circumstances, it may be preferable to have a digest in ``multi- + part/mixed''. The ``x'' (mixed) format is identical to ``m'' except + for this header. + + For ezmlm-cron(1), just suffix the format code to the digest code. + + + 1100..22.. SSppeecciiffyyiinngg tthhee ddeeffaauulltt ffoorrmmaatt ffoorr ddiiggeessttss aanndd aarrcchhiivvee + rreettrriieevvaall.. + + The ezmlm-get(1) ``-f'' switch can be used to change the default + format (MIME with removal of less relevant headers) to other formats. + The format specifiers are the same as for individual archive + retrievals (see ``Specifying the format for retrieved messages''). + + + 1100..33.. LLiimmiittiinngg tthhee nnuummbbeerr ooff mmeessssaaggeess ppeerr --ggeett//--iinnddeexx rreeqquueesstt.. + + By default, a single -get request returns a maximum of 100 messages, + and a single -index request 2000 subjects entries (20 files of 100 + subjects entries each). This can be changed by editing MAXGET, and + MAXINDEX in iiddxx..hh and recompiling. Remember to edit tteexxtt//bboottttoomm, + tteexxtt//bboouunnccee, and eezzmmllmmrrcc((55)) to reflect these changes so that your + users won't get confused. + + + 1111.. RReessttrriiccttiinngg aarrcchhiivvee rreettrriieevvaall.. + + + 1111..11.. RReessttrriiccttiinngg aarrcchhiivvee aacccceessss ttoo ssuubbssccrriibbeerrss.. + + 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 DDIIRR//aallllooww//. + 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 + DDIIRR//aallllooww// 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. + + + 1111..22.. RReessttrriiccttiinngg aavvaaiillaabbllee aarrcchhiivvee rreettrriieevvaall ccoommmmaannddss.. + + If you want to disable all archive retrieval except digest creation, + simply add the ``-C'' command line switch to the ezmlm-get(1) line in + DDIIRR//mmaannaaggeerr. If you don't want digest creation via trigger messages + and DDIIRR//mmaannaaggeerr, but use other means to created digests, you can + remove the ezmlm-get(1) line from DDIIRR//mmaannaaggeerr. + + + 1111..33.. RReessttrriiccttiinngg aarrcchhiivvee rreettrriieevvaall ttoo mmooddeerraattoorrss.. + + If DDIIRR//ppuubblliicc does not exist, ezmlm-manage(1) and ezmlm-get(1) modify + their behavior. They disallow user requests, but for remote + administration lists, honor moderator requests. Thus, for a remote + admin list without DDIIRR//ppuubblliicc, only subscription moderators or remote + administrators can receive archive retrievals and only remote + administrators can subscribe and unsubscribe user addresses. + + If you'd like this restriction of archive retrieval with maintained + user-initiated ezmlm-manage(1) subscription functions, use the ezmlm- + get(1) ``-P'' (not public) switch, and retain DDIIRR//ppuubblliicc. Also, look + at the ezmlm-make ``-b'' switch. + + + 1111..44.. AAlllloowwiinngg aarrcchhiivvee rreettrriieevvaall ffrroomm aa nnoonn--ppuubblliicc lliisstt.. + + A non-public list lacks DDIIRR//ppuubblliicc. 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. + + + 1122.. CCuussttoommiizziinngg ddiiggeessttss.. + + + 1122..11.. SSeettttiinngg uupp aa ddiiggeesstt lliisstt.. + + 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. + + + 1122..22.. GGeenneerraattiinngg ddaaiillyy ddiiggeessttss.. + + 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 DDIIRR//eeddiittoorr 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 DDIIRR//eeddiittoorr 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 eezzmmllmmrrcc 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. + + + + + + 1122..33.. GGeenneerraattiinngg tthhee ffiirrsstt ddiiggeesstt.. + + If you want the first digest to start with issue 1 and the first + message in your archive, no special action is required. + + If you want the first digest to start at message 123 and you have + shell access, put '122' into DDIIRR//ddiiggnnuumm. + + If you want the next digest to start at message 456, you can always + edit DDIIRR//ddiiggnnuumm to contain '455'. If you want the next digest to be + named issue 678, put '677' into DDIIRR//ddiiggiissssuuee. + + + 1122..44.. AAddddiinngg ssttaannddaarrdd aaddmmiinniissttrraattiivvee iinnffoorrmmaattiioonn ttoo ddiiggeessttss.. + + The text in DDIIRR//tteexxtt//ddiiggeesstt is copied into the ``Administrivia'' + section of the digest. This information can be customized on a + system-wide basis by editing //eettcc//eezzmmllmmrrcc, on a user-wide basis by + editing ~~//..eezzmmllmmrrcc, or for the list by directly editing the + DDIIRR//tteexxtt//ddiiggeesstt file, or by a remote administrator by editing the file + via e-mail, if the list has been set up using the ezmlm-make(1) + ``-nr'' switches (see ``How text file editing works''). + + + 1122..55.. CCoonnttrroolllliinngg tthhee ddiiggeesstt ffoorrmmaatt.. + + You can control the default format that ezmlm-get(1) uses for its + output by using the ``-f x'' switch. For individual digests triggered + by mail or other archive access, add a format specifier after the + digestcode: + + + + list-dig.codef@host + + + + + For example: + + + + joe-sos-dig.gagax@id.com + + + + + where ``x'' is ``r'' for rfc1153 format, ``m'' (default) for MIME mul- + tipart/digest with a subset of headers, ``v'' for virgin MIME multi- + part/digest, i.e. with all headers retained from the archive, ``n'' + produces format similar to ``v'', without threading and with messages + in numerical order. The ``x'' format is identical to the default ``m'' + format, but the digest content-type is ``multipart/alternative'' + rather than ``multipart/digest''. This helps with a pine bug if you + are using quoted-printable/base64 encoding of ezmlm messages. + + With 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 + DDIIRR//eeddiittoorr. Just add the ``-fx'' switch to the ezmlm-get(1) command + line there. Edit ~~//eezzmmllmmrrcc to assure that such customizations will be + used for future list creations/edits. + + + 1122..66.. CCuussttoommiizziinngg bboouunnccee hhaannddlliinngg.. + + The time out for bounce messages is normally 11.6 days. This means + that a bad address will take longer that 3 weeks to be removed. + Usually, this delay is desirable. After all, it is much worse to + remove a subscriber just because the address had temporary problems + that to send a few extra messages and receive a few extra bounces. + + However, for large lists, bounce handling can consume a considerable + amount of resources. To decrease the load, remove all ezmlm-warn(1) + lines from the DDIIRR//eeddiittoorr, and DDIIRR//mmaannaaggeerr files. Instead, execute: + + + /path/ezmlm-warn DIR + /path/ezmlm-warn -d DIR + + + + + daily during off-peak hours via a cron script. The second line can be + omitted if you are not using the digest capability of the list. + + 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. + + + 1133.. RReemmoottee aaddmmiinniissttrraattiioonn.. + + + 1133..11.. HHooww ccaann II rreemmootteellyy aadddd mmooddeerraattoorrss,, ssuubbssccrriibbeerr aalliiaasseess,, eettcc?? + + On any list, the DDIIRR//aallllooww// 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 DDIIRR//ddeennyy// 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 DDIIRR//mmoodd// databases (i.e., without shell + access), you need to set up a non-public, remotely administered list + which ``resides'' within the DDIIRR//mmoodd. _P_l_e_a_s_e _c_a_r_e_f_u_l_l_y _c_o_n_s_i_d_e_r _t_h_e + _i_m_p_l_i_c_a_t_i_o_n_s _o_f _m_a_k_i_n_g _i_t _p_o_s_s_i_b_l_e _t_o _r_e_m_o_t_e_l_y _a_d_d_, _r_e_m_o_v_e_, _a_n_d _l_i_s_t + _m_o_d_e_r_a_t_o_r_s_. _I_n _m_a_n_y _c_i_r_c_u_m_s_t_a_n_c_e_s_, _t_h_i_s _i_s _d_a_n_g_e_r_o_u_s_. + + After setting up your list with the specific functionality you need, + use the following command for DDIIRR//mmoodd//: + + + % ezmlm-make -ePrIAl ~/list/mod ~/.qmail-list-mod joe-list-mod host + + + + + The '-l' flag is not necessary, but makes it easier to administrate + your moderator database by permitting the ``supermoderator'' to see + who is on the list. + + The new list does not have a key. Using the key from the main list is + inadvisable. Instead, create a dummy list, copy the key from this list + to your ``moderator'' list: + + + % cp ~/DUMMY/key ~/DIR/mod/key + + + + + Erase the dummy list. Also, posts to this list should not be allowed. + Erase the ~~//..qqmmaaiill--lliisstt--mmoodd and ~~//DDIIRR//mmoodd//eeddiittoorr. Then add the remote + administrator of the ``moderator'' list: + + + % ezmlm-sub ~/list/mod/mod supermod@superhost + + + + + The ``supermoderator'' can now remotely administrate the moderators of + the main list. + + + 1133..22.. MMooddeerraattiinngg ppoossttss ffrroomm aa sseeccoonnddaarryy aaccccoouunntt.. + + Request for moderation of posts can be forwarded to any address and + acted on from that address. By default, all post moderation requests + have subjects starting with ``MODERATE for'' followed by the list + name. + + 1133..33.. MMooddeerraattiinngg ssuubbssccrriippttiioonn ffrroomm aa sseeccoonnddaarryy aaccccoouunntt.. + + Requests for moderator approval of user subscribe requests can be + forwarded to any address and acted on from that address. All + subscription moderation requests have subjects starting with + ``CONFIRM'' (or ``CONFIRM subscribe to listname'', since ``CONFIRM + unsubscribe from listname'' is sent to the moderator only in reply to + a moderator-initiated request on a list with remote admin). + + Remote administration (initiation by the moderator of (un)subscribe + requests on behalf of a user) CANNOT be initiated from an account that + is not listed in the moderator database. If such attempts are made, + these will be treated as regular requests, resulting in a confirm + request to the user (which includes a copy of the initial request, + revealing the moderator's address to the user). The user reply to a + confirm request will on a non-moderated list result in the addition of + the user address to the subscriber list, and in a moderated list a + CONFIRM request to all the moderators. Replies to unsubscribe confirm + requests always result in the removal of the address, without + moderator intervention (except in some cases when the ezmlm-manage -U + switch is used (see below)). With this caveat, moderation and remote + administration can be done from a secondary address. + + For the subscription moderator to temporarily use a different address, + s/he needs to forward all ``CONFIRM'' messages to the new address. For + a permanent move, it is better to remove the old moderator address and + add the new SENDER address to allow moderator-initiated (un)subscribes + without user intervention from the new address (of course, the list + has to be configured for remote administration with DDIIRR//rreemmoottee). + + + 1133..44.. AAuuttoommaattiiccaallllyy aapppprroovviinngg ppoossttss oorr ssuubbssccrriippttiioonnss.. + + Sometimes, it may be desirable for the moderator to automatically + approve all moderation requests. This may be appropriate for a single + moderator of a ``civilized'' list when away for the week. + + Set up your client to auto-reply to the ``Reply-To:'' address for all + messages with subjects ``CONFIRM subscribe to listname'' or ``MODERATE + for listname''. Beware that this can be used by malicious people to + trick your account to send mail anywhere. In practice, this should + not be a problem. If you are worried, forward the messages to a + (trusted) friend and ask him/her to appropriately reply to the + requests. + + + 1133..55.. AAlllloowwiinngg rreemmoottee aaddmmiinniissttrraattoorrss ttoo ggeett aa ssuubbssccrriibbeerr lliisstt.. + + Access to the subscriber list is sensitive. Thus, this option is + disabled by default. The ezmlm-manage(1) ``-l'' command line switch + enables this option, but will send a subscriber list only to a + moderator's address. This allows a moderator to also initiate a + subscriber list retrieval from a secondary account (i.e. one to which + the moderator's mail is delivered, but for which SENDER is not a + moderator). The latter option does not decrease security, as it is + trivial to fake SENDER (see ``Ezmlm-idx security'' for a discussion of + ezmlm-idx security aspects). + + For maximum subscriber list security, do not enable this feature. To + enable this feature by default, just modify eezzmmllmmrrcc((55)) (see + ``Customizing ezmlm-make operation''). + + + + + + 1133..66.. AAlllloowwiinngg rreemmoottee aaddmmiinniissttrraattoorrss ttoo rreettrriieevvee oorr sseeaarrcchh aa ssuubb-- + ssccrriippttiioonn lloogg.. + + 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. + + + 1133..77.. AAlllloowwiinngg uusseerrss ttoo ggeett aa ssuubbssccrriibbeerr lliisstt.. + + If you want any user to be able to get a subscriber list, you can set + up a separate link to DDIIRR//lliisstt and then put in a script using ezmlm- + list (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. + + + 1133..88.. CChhaannggiinngg tthhee ttiimmeeoouutt ffoorr mmeessssaaggeess iinn tthhee mmooddeerraattiioonn qquueeuuee.. + + Put the time, in hours, into DDIIRR//mmooddttiimmee. This value may not exceed + the range of 24-120 h set at compile time by the defines in iiddxx..hh. + + + 1133..99.. FFiinnddiinngg oouutt hhooww mmaannyy mmeessssaaggeess aarree wwaaiittiinngg ffoorr mmooddeerraattiioonn.. + + + + % ls -l DIR/mod/pending + + + + + and count lines with the owner execute bit set (rwx------). Others + are remnants from failed ezmlm-store runs (ignore - ezmlm-clean(1) + will remove them). + + There is currently no way to see this remotely, although you could + easily install a script mailing the 'ls' output in response to a + message to e.g. lliisstt--cchhkkqquueeuuee@@hhoosstt. (See ezmlm-check(1) and ``adding + your own commands'' for examples.) + + + 1133..1100.. UUssiinngg tthhee ssaammee mmooddeerraattoorrss ffoorr mmuullttiippllee lliissttss.. + + Set up a moderator dir: + + + + + + + % mkdir /path/moddir /path/moddir/subscribers + % touch /path/moddir/lock + % chown -R user /path/moddir + + + + + For alias: + + + + # chown -R alias /path/moddir + + + + + For example: + + + + % mkdir ~joe/mods ~joe/mods/subscribers + % touch ~joe/mods/lock + + + + + Then for the lists, put //ppaatthh//mmooddddiirr into DDIIRR//mmooddssuubb (for moderation + of subscribes), DDIIRR//rreemmoottee (for remote admin if DDIIRR//mmooddssuubb does not + exist), and DDIIRR//mmooddppoosstt (for moderation of messages). + + For example: + + + + % echo "/home/joe/mods" > ~joe/DIR/modsub + + + + + _N_O_T_E_: The path must start with a '/'. + + + 1133..1111.. UUssiinngg ddiiffffeerreenntt mmooddeerraattoorrss ffoorr mmeessssaaggee aanndd ssuubbssccrriippttiioonn mmooddeerr-- + aattiioonn.. + + Proceed as in the previous point, but set up two different moddirs. + Naturally, one of these can be DDIIRR//mmoodd// (preferably the one for posts, + to keep it cleaner). Then modify the appropriate files (DDIIRR//mmooddppoosstt + and DDIIRR//mmooddssuubb) to contain absolute paths to the correct moddir. + + + 1133..1122.. tthhee ````ssuuppeerr mmooddeerraattoorr'''' aabbllee ttoo aadddd//rreemmoovvee mmooddeerraattoorrss + rreemmootteellyy.. SSeettttiinngg uupp mmooddeerraatteedd lliissttss wwiitthh tthhee lliisstt oowwnneerr aass + + This is done by crating a list that has DDIIRR//mmoodd// as it's main list + directory, then adding the ``super moderator'' to DDIIRR//mmoodd//mmoodd// (see + ``remotely adding moderators''). + + If this is a common setup for you, you can write a simple script + creating both lists (plus a digest list, if desired) with one simple + action (see ezmlm-both(1) for an example). + + + + + + 1133..1133.. CCuussttoommiizziinngg eezzmmllmm aaddmmiinniissttrraattiivvee mmeessssaaggeess.. + + Subject lines, and other ezmlm output for moderation are controlled by + defines in iiddxx..hh and by files in DDIIRR//tteexxtt. To customize these, change + iiddxx..hh and recompile or for DDIIRR//tteexxtt files, edit eezzmmllmmrrcc((55)) (see + ``Customizing ezmlm-make operation''). + + You can also configure the list to allow remote administrators to edit + files in DDIIRR//tteexxtt// via E-mail (see ``How text file editing works''). + + + 1133..1144.. MMaannuuaallllyy aapppprroovviinngg aa mmeessssaaggee aawwaaiittiinngg mmooddeerraattiioonn.. + + All you have to do is to pipe the corresponding message to ``ezmlm- + send DIR''. Messages awaiting moderation are kept in DDIIRR//mmoodd//ppeennddiinngg//. + To find a particular file, grep the contents. Thus, to find a file + from user@host.dom, try: + + + + % grep 'user@host\.dom' DIR/mod/pending/* + + + + + (Depending on your setup, you may not have to escape the period.) + Check the files for the owner execute (``x'') bit. It is set on all + messages queued successfully. Ignore other files! + + To then accept the message (change the ezmlm-send(1) path if you've + installed in a non-default directory): + + + + % cat DIR/mod/pending/filename \ + % /usr/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 ~~jjooee//SSOOSS//. + + + 1133..1155.. MMaannuuaallllyy rreejjeeccttiinngg aa mmeessssaaggee aawwaaiittiinngg mmooddeerraattiioonn.. + + Simply deleting the file from DDIIRR//mmoodd//ppeennddiinngg// will do it. If you want + to notify the sender, just send him/her an E-mail. There is an easy + way to get ezmlm-idx programs to do it for you: just wait and let + ezmlm-clean(1) take care of it for you, once the message has timed out + (number of hours settable within 24-240 in DDIIRR//mmooddttiimmee; default 120). + + + + + 1144.. SSuubblliissttss.. + + A sublist is a list that receives its input from another mailing list, + rather than from users directly. The sublist is just a regular + subscriber of the main list. A sublist in e.g. Tasmania is very useful + since only one message is sent from the main list and then the + sublists servers all subscribers in Tasmania. Bounces and all + administration is handled locally. The local sublist can have a + digest, even though the main list may not. (See ``How sublists work'' + for more info on how sublists work). + + + 1144..11.. SSuubblliissttss ooff eezzmmllmm lliissttss.. + + To set up a sublist to an ezmlm list, just use the ezmlm-make ``-5 + mainlist@mainhost'' switch. This will configure your list as a sublist + to the mainlist@mainhost mailing list. + + + 1144..22.. SSuubblliissttss ooff nnoonn--eezzmmllmm lliissttss.. + + To set up a sublist to an ezmlm list, just use the ezmlm-make ``-5 + mainlist@mainhost'' switch. This will configure your list as a sublist + to the mainlist@mainhost mailing list. Since the main list may not use + the ``Mailing-List'' header, you must identify another header that the + main list adds to all messages. See the ezmlm-reject(1) man page for + examples. Next, edit DDIIRR//eeddiittoorr of your sublist and add a ``-h + _L_i_s_t_p_r_o_c_e_s_s_o_r_-_V_e_r_s_i_o_n_:'' option to the ezmlm-send(1) line, but + replacing ``_L_i_s_t_p_r_o_c_e_s_s_o_r_-_V_e_r_s_i_o_n_:'' with your mainlist header. + + Now your list will accept only messages from mainlist@mainhost and + with the header specified. + + + 1144..33.. HHooww ttoo sseett uupp aa cclluusstteerr ooff lliisstt aanndd ssuubblliissttss wwiitthh ssttaannddaarrdd + ddaattaabbaasseess.. + + 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: + + + +o + + ccrreeaattee tthhee mmaaiinn lliisstt + + + ezmlm-make dir dot local host + + + + + +o + + aadddd aann eezzmmllmm--sspplliitt((11)) iinnvvooccaattiioonn + Before the ezmlm-manage(1) line in DDIIRR//mmaannaaggeerr add: + + + |/path/ezmlm-split dir + + + + + +o + + ddeecciiddee hhooww ttoo sspplliitt tthhee llooaadd + 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. + + +o + + CCrreeaattee tthhee ssuubblliissttss + 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 + + + + + +o + + ssuubbssccrriibbee tthhee rreessppeeccttiivvee ssuubblliissttss ttoo tthhee mmaaiinn lliisstt + 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. + 1155.. MMiiggrraattiioonn ttoo EEzzmmllmm ffrroomm ootthheerr MMaaiilliinngg LLiisstt MMaannaaggeerrss.. + + This section describes differences and similarities between ezmlm and + other mailing list managers. It also details functions of ezmlm-idx + that allow you to configure ezmlm to respond to commands utilized by + such other mailing list managers so the command syntax will be + familiar to such users. Contributions to complete this sections are + welcome. + + + 1155..11.. BBaassiicc CCoonncceeppttss.. + + Ezmlm is different from other mailing list managers in that it is + _l_i_s_t_-_c_e_n_t_r_i_c rather than _h_o_s_t_-_c_e_n_t_r_i_c. With a _l_i_s_t_-_c_e_n_t_r_i_c interface, + you address the list directly with administrative commands. With + ezmlm, the command is embedded in the list address thus becoming part + of it (i.e., the ``command address''.) With smartlist, again you + address the list, but send all administrative commands to the list- + request address. Ezmlm lists can support this if you use the ezmlm- + make(1) ``-q'' switch to configure ezmlm-request(1) in DDIIRR//mmaannaaggeerr. + + Other mailing list managers are _h_o_s_t_-_c_e_n_t_r_i_c, i.e. administrative + commands for any list on that particular host are addressed to a + central address such as majordomo@host, listserv@host, or + listproc@host. Then the user is required to place the command in + either the subject header or more commonly in the body text of the + message. The listname has to be included with the command. [_N_o_t_e_: The + above concept is not universally applicable to all host-centric + mailing lists. While intended to to used in a host-centric manner, + many such mailing list managers also support listname-request@host + addressing. See the applicable list manger documentation for details. + Coverage of this aspect of other mailing list manager functionality is + beyond the scope of this FAQ.] To make the migration to ezmlm easier, + support for a _h_o_s_t_-_c_e_n_t_r_i_c style mailing list manger is available. + This is based on the use of ezmlm-request(1) with the ``-f + ccoonnffiigg__ffiillee'' switch. + + + 1155..22.. SSeettttiinngg uupp eezzmmllmm ttoo rreessppoonndd ttoo hhoosstt--cceennttrriicc ccoommmmaannddss.. + + 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 + eezzddoommoo//cchhaarrsseett. + + All that remains is to set up DDIIRR//eezzddoommoo..ccff 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 DDIIRR//eezzddoommoo..ccff 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 DDIIRR//, which contains the + subscriber database, must be readable by the user under which mail is + delivered. This means that ``which'' is usually limited to lists owned + by the user or virtual domain under which the ``ezdomo'' interface is + set up. + + + 1155..33.. CCoommmmaannddss ooff ootthheerr mmaaiilliinngglliisstt mmaannaaggeerrss rreeccooggnniizzeedd bbyy eezzmmllmm.. + + + 1155..33..11.. LLiissttpprroocc//LLiissttsseerrvv.. + + When set up as above, substituting ``listproc'' or ``listserv'' for + ``majordomo'' as appropriate, ezmlm will recognize and respond to the + following commands placed in the body of the e-mail with the syntax + below. NNoottee:: eezzmmllmm wwiillll oonnllyy rreessppoonndd ttoo oonnee ccoommmmaanndd ppeerr mmeessssaaggee.. + + ssyynnttaaxx:: ccoommmmaanndd lliissttnnaammee [[ssuubbssccrriibbeerr@@hhoosstt]] + + + SSuuppppoorrtteedd ccoommmmaannddss + subscribe, sub, unsubscribe, unsub, list, help, review. + + AAddddiittiioonnaall ssuuppppoorrtteedd ccoommmmaannddss + All ezmlm commands, such as ``thread'', ``index'' and ``get'' as + well as the list owner's commands. + + This interfaced makes information available via command messages to + the appropriate mailing list. Thus, ``list'' and ``review'' will send + a subscriber list only to remote administrators and only if + specifically allowed by the list owner. + + + 1155..33..22.. MMaajjoorrddoommoo.. + + ssyynnttaaxx:: ccoommmmaanndd lliissttnnaammee [[ssuubbssccrriibbeerr@@hhoosstt]] + + + SSuuppppoorrtteedd ccoommmmaannddss + lists, subscribe, unsubscribe, help, which, who. + AAddddiittiioonnaall ssuuppppoorrtteedd ccoommmmaannddss + All ezmlm user and ezmlm owner commands. + + This interfaced makes information available via command messages to + the appropriate mailing list. Thus, ``who'' will send a subscriber + list only to remote administrators and only if specifically allowed by + the list owner. + + + 1155..33..33.. SSmmaarrttlliisstt.. + + 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. + + + SSuuppppoorrtteedd ccoommmmaannddss + subscribe, unsubscribe. + + AAddddiittiioonnaall SSuuppppoorrtteedd CCoommmmaannddss + All ezmlm user and ezmlm owner commands. + + + 1166.. OOppttiimmiizziinngg lliisstt ppeerrffoorrmmaannccee.. + + Ezmlm-idx is designed to make it as easy as possible to set up mailing + lists. The default setup works well for small and medium-sized lists. + For large lists, the lists can be made more efficient with a few + simple changes. + + + 1166..11.. CCrroonndd--ggeenneerraatteedd ddiiggeessttss ffoorr bbeetttteerr ppeerrffoorrmmaannccee.. + + With the default setup, ezmlm-tstdig(1) in DDIIRR//eeddiittoorr tests if a + digest should be sent out. On lists with a lot of traffic this is + inefficient. Also, you may want digests to be delivered as a specific + time. To do this, use crond(8) to execute ezmlm-get(1) directly, as + described elsewhere. + + + 1166..22.. OOppttiimmiizziinngg eexxeeccuuttiioonn ooff eezzmmllmm--wwaarrnn((11)).. + + 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 ( + 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. + + _N_o_t_e_: the ezmlm-make(1) ``-w'' switch has a special meaning if used at + the same time as enabling SQL-support (``-6''; see man pages). + + + 1166..33.. DDeeccrreeaassiinngg eezzmmllmm--wwaarrnn ttiimmee oouutt ttoo iinnccrreeaassee ppeerrffoorrmmaannccee.. + + With ezmlm-idx, you may alter the ezmlm-warn(1) timeout to a number of + seconds with the ``-t seconds'' switch. The default is 1,000,000 + seconds or about 11.6 days. This is the time from the first bounce + until ezmlm-warn(1) sends a warning message and the time from the + warning message bounce until ezmlm-warn(1) sends a probe (which if + bounced leads to removal of the address from the subscriber list). If + you have a digest list, remember to execute ezmlm-warn(1) with the + ``-d'' switch as well. + + Decreasing the default to e.g. 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. + + + 1166..44.. UUssee eezzmmllmm wwiitthhoouutt eezzmmllmm--iiddxx ffoorr mmaaxxiimmuumm ppeerrffoorrmmaannccee.. + + ezmlm-idx adds a number of functions to ezmlm. It indexes the archive, + and adds an index entry for each message, it can remove MIME parts, it + can add a subject prefix and message trailer, decode rfc2047-encoded + subjects, etc. Although designed to impact minimally on performance, + these options when used take time. Even when they are not used, time + is spent looking for e.g. the prefix. However, the performance penalty + is small, as the absolutely dominating cost of a mailing list is the + work qmail does to deliver the messages to subscribers. + + 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. + + + 1166..55.. NNoott aarrcchhiivviinngg ttoo mmaaxxiimmiizzee ppeerrffoorrmmaannccee.. + + An archived list needs to write the message to the archive. If you + don't need an archive, don't archive. However, the archive is very + useful to allow users to catch up on messages that they didn't receive + due to delivery problems. + + + 1166..66.. SSuubblliissttss ttoo mmaaxxiimmiizzee ppeerrffoorrmmaannccee.. + + Consider splitting your list into sublists, ideally geographically. + The main list deals only with a subset of subscribers (or only the + sublists), and each sublist deals with a subset of subscribers, + bounces, etc. This is the most rational way to scale ezmlm to large + lists (see ``How sublists work'' for more info on how sublists work + and ``Sublists'' on how to set up sublists). + + + 1177.. MMiisscceellllaanneeoouuss.. + + + 1177..11.. HHooww ddoo II qquuiicckkllyy cchhaannggee tthhee pprrooppeerrttiieess ooff mmyy lliisstt?? + + + + ezmlm-make -+ [changed_switches] dir + + + + + ezmlm-make(1) stores configuration info in DDIIRR//ccoonnffiigg 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. + + + 1177..22.. OOppeenn aarrcchhiivveedd lliisstt wwiitthh ddaaiillyy ddiiggeessttss.. + + This is the default setup. The main list generates digests in response + to a mailed request or when a message arrives and the amount of + messages since the last digest exceeds set limits (see ezmlm- + tstdig(1)). Alternatively, ezmlm-get(1) can be invoked from the + command line. In both cases, the generated digest message is + disseminated to the subscribers stored in DDIIRR//ddiiggeesstt//ssuubbssccrriibbeerrss//, + i.e. the subscriber database with the base directory DDIIRR//ddiiggeesstt//. + + +o See ``setting up a digest list'' on how to set up the lists. + + + 1177..33.. VVaarriiaattiioonnss iinn mmooddeerraattiioonn + + You can set up lists with combinations of message moderation, + subscription moderation, and remote administration, easiest by + combining ezmlm-make(1) ``-m'' ,``-s'', and ``-r'' switches. You can + use a non-default moderator db, by specifying a directory starting + with a slash in DDIIRR//mmooddssuubb or DDIIRR//rreemmoottee (for remote admin and + subscription moderation - always the same db for both functions) or in + DDIIRR//mmooddppoosstt for message moderation. You can point several lists to the + same moderator db, thus using the same moderators for several lists. + _N_O_T_E_: The user controlling the list must have read/write access to the + files (specifically, must be able to write the lock file). + + Some of these setups are not trivial. However, you can make them + trivial by modifying ezmlmrc(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''). + + + 1177..44.. LLiissttss tthhaatt aallllooww rreemmoottee aaddmmiinn,, bbuutt nnoott uusseerr iinniittiiaatteedd ssuubbssccrriipp-- + ttiioonn oorr aarrcchhiivvee rreettrriieevvaall.. + + Create a regular remote admin list, but remove DDIIRR//ppuubblliicc. This + allows moderators to (un)subscribe users and have archive access, but + rejects all user requests. Posts work as usual. Naturally, this can + be combined with message moderation or ezmlm-issub SENDER checks (see + ``Restricting message posting to the list''). + + + 1177..55.. LLiissttss tthhaatt aallllooww rreemmoottee aaddmmiinn,, uusseerr aarrcchhiivvee rreettrriieevvaall,, bbuutt nnoott + uusseerr--iinniittiiaatteedd ssuubbssccrriippttiioonn.. + + Create a regular remote admin list, remove DDIIRR//ppuubblliicc, and add the + ``-p'' [public] switch to the ezmlm-get(1) command line in + DDIIRR//mmaannaaggeerr. This overrides the normal DDIIRR//ppuubblliicc effect on ezmlm- + get(1) and archive retrieval, allowing full archive access to anyone, + but rejecting user -help and subscription commands. It is assumed + that the users know archive retrieval commands without help. If you + want to provide specific help, just link ~~//..qqmmaaiill--lliissttnnaammee--hheellpp to + DDIIRR//hheellpp, and invoke a script that copies help info from there. See + ezmlm-check(1) for an example. + + + 1177..66.. LLiissttss tthhaatt rreessttrriicctt aarrcchhiivvee rreettrriieevvaall ttoo ssuubbssccrriibbeerrss.. + + Use a standard list, but add the ezmlm-get(1) ``-s'' command line + switch in DDIIRR//mmaannaaggeerr. Only subscribers can receive archive excerpts. + Digests work as usual. This can be set up using the ezmlm-make(1) + ``-g'' switch. + + + 1177..77.. LLiissttss tthhaatt ddoo nnoott aallllooww aarrcchhiivvee rreettrriieevvaall aatt aallll.. + + Use a standard list, but add the ``-C'' switch to both the ezmlm- + get(1) and ezmlm-manage(1) command lines in DDIIRR//mmaannaaggeerr. No archive + retrieval commands will be honored. Digest can be created as usual + (See ``Restricting archive retrieval''). + + + 1177..88.. LLiissttss tthhaatt ddoo nnoott aallllooww aarrcchhiivvee rreettrriieevvaall aanndd ddoo nnoott aallllooww + ddiiggeesstt ttrriiggggeerriinngg ppeerr mmaaiill.. + + For maximal archive security, set up a normal indexed and archived + list, then remove the ezmlm-get(1) line from DDIIRR//mmaannaaggeerr and add the + ``-C'' switch to the ezmlm-manage(1) command line. You can still + create digests by direct invocation of ezmlm-get(1) from a script or + crontab entry. + + + 1177..99.. LLiissttss tthhaatt aallllooww aarrcchhiivvee rreettrriieevvaall oonnllyy ttoo mmooddeerraattoorrss,, bbuutt + aallllooww uusseerr--iinniittiiaatteedd ssuubbssccrriippttiioonn.. + + Create a normal remote admin (+ subscription moderated) list, and add + the ``-P'' (not public) switch to the ezmlm-get(1) command line in + DDIIRR//mmaannaaggeerr. Subscription will not be affected, but ezmlm-get(1) will + send archive excerpts only to moderators. Digests are unaffected. + + + 1177..1100.. LLiissttss tthhaatt ddoo nnoott rreeqquuiirree uusseerr ccoonnffiirrmmaattiioonn ffoorr ((uunn))ssuubbssccrriipp-- + ttiioonn.. + + + The need for a user handshake can be eliminated by the ezmlm-manage(1) + ``-S'' (subscribe) and/or ``-U'' (unsubscribe) switches. Alone, this + is very insecure. However, there may be some use for it in local lists + with subscription moderation, or alone for notifications where ease of + use is more important than preventing users from (un)subscribing + others. If the list has subscription moderation or remote + administration, any user subscribe or unsubscribe request is forwarded + to the moderators if the SENDER and target address do not match, even + if the ``-U/-S'' switches are specified. This is put in place to make + a ``-U/-S'' list similar to other list managers, not for security + (it's not secure, since a malicious outsider can easily fake the + SENDER address). Unsubscribe confirmations are sent also to the target + in this case, to avoid situations where the user needs moderator + ``permission'' to get off the list. + + + 1177..1111.. AAnnnnoouunncceemmeenntt lliissttss ffoorr aa ssmmaallll sseett ooff ttrruusstteedd ppoosstteerrss + + Set up the list with ezmlm-make ``-om'' and add the ``trusted E-mail + addresses'' to DDIIRR//mmoodd// with + + + % ezmlm-sub DIR/mod address@host + + + + + A post from a ``trusted address'' is sent back to that address for + approval, assuring that the user at that address really sent the post. + Posts from other e-mail addresses are rejected. + + + 1177..1122.. AAnnnnoouunncceemmeenntt lliissttss aalllloowwiinngg mmooddeerraatteedd ppoossttss ffrroomm aannyyoonnee.. + + This is useful in many circumstances. A list announcing new programs + for a system, where both the main developers and other users may have + contributed programs. + + Set up the list with ezmlm-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 DDIIRR//mmooddppoosstt (needs leading + ``/''), and add the post moderator(s) to DDIIRR//mmoodd// using ezmlm-sub(1) + as shown above. + + + 1177..1133.. AAnnnnoouunncceemmeenntt lliissttss wwiitthh lleessss sseeccuurriittyy aanndd mmoorree ccoonnvveenniieennccee.. + + A general solution for SENDER checking is to configure list with + ezmlm-gate(1). ezmlm-gate(1) takes as arguments any number of + basedirs for subscriber lists. Posts from SENDERs that are found are + posted. For others ezmlm-store(1) is invoked. If DDIIRR//mmooddppoosstt exists, + ezmlm-store(1) will send out other messages for moderation. To bounce + such messages, create DDIIRR//mmooddppoosstt, and use the ezmlm-gate(1) ``-P'' + switch (will be passed on to ezmlm-store(1) to bounce any posts not + from a moderator). + + By default, ezmlm-gate(1) accepts messages from subscribers. However, + this is overridden if any ``basedirs'' are put on the ezmlm-gate(1) + command line. Common would be to create a address list and put its + ``basedir'' on the ezmlm-gate(1) command line. Trusted E-mail + addresses can then be added with: + % ezmlm-sub basedir trusted@host + + + + + As this relies on SENDER checks it is less secure than the ezmlm-store + based confirmation-requiring setup. + + + 1188.. EEzzmmllmm--iiddxx ccoommppiillee ttiimmee ooppttiioonnss.. + + + 1188..11.. LLooccaattiioonn ooff bbiinnaarriieess.. + + This is configured via ccoonnff--bbiinn as for other ezmlm programs. The + default is //uussrr//llooccaall//bbiinn//eezzmmllmm. + + + 1188..22.. LLooccaattiioonn ooff mmaann ppaaggeess.. + + This is configured via ccoonnff--mmaann as for other ezmlm programs. The + default is //uussrr//llooccaall//mmaann. + + + 1188..33.. BBaassee ddiirreeccttoorryy ooff qqmmaaiill--iinnssttaallllaattiioonn.. + + This is configured via ccoonnff--qqmmaaiill as for other ezmlm programs. The + default is //vvaarr//qqmmaaiill. + + + 1188..44.. SShhoorrtt hheeaaddeerr tteexxttss,, eettcc.. + + Ezmlm-idx text (short lines, such as ``Administrivia'' for digests), + command names, etc, are defined in iiddxx..hh, used at compile time. You + can change them by changing the defines in this file. + + + 1188..55.. AArrbbiittrraarryy lliimmiittss.. + + iiddxx..hh contains defines for some ezmlm-idx arbitrary limits, such as + the maximum number of messages per ``-get'' request. They can be + changed here. + + + 1188..66.. CCoommmmaanndd nnaammeess.. + + There is support for one alias per user command for + internationalization. (See ``Multiple language support''.) + + + 1188..77.. EErrrroorr mmeessssaaggeess.. + + All ezmlm-idx error messages are defines in eerrrrttxxtt..hh, used at compile + time. These can be changed for special situations, but we would advise + against doing so. If you do for some reason produce such a translated + file, we would appreciate if you sent a copy to the authors. NOTE: + These do not affect error messages from programs that are not part of + the ezmlm-idx package, nor of some subroutines used by ezmlm-idx + programs (getconf_line.c comes to mind). + + Hopefully, the error messages for all parts will be synchronized in + later versions of ezmlm, and possibly handled from a run-time + changeable separate file (maybe as a .cdb database). + + + + 1188..88.. PPaatthhss aanndd ootthheerr oodddd ccoonnffiigguurraattiioonn iitteemmss.. + + idx.h also has defines for //eettcc//eezzmmllmmrrcc, default formats for + moderation enclosures, default character set, default digest format, + etc. Since most of these items are easily changed at run time, there + is usually no need to change the compiled-in defaults. If you do need + to, this is where they are. + + + 1199.. MMuullttiippllee llaanngguuaaggee ssuuppppoorrtt.. + + + 1199..11.. CCoommmmaanndd nnaammeess.. + + ezmlm commands can have aliases for use in translations for non- + English use. Due to the use of commands in mail e-mail addresses, the + character set is limited by rfc822 to us-ascii. To enable the command + aliases, remove the comment marks around the INTL_CMDS define in + idx.h. Also, remove the comments from the define corresponding to one + language (currently, only LANG_FR - French) available. + + The INTL_CMDS define results in the compilation of all ezmlm programs + with support for alias commands for those commands listed in the INTL + section (all that are used directly by users). All aliases MUST be + defined, but should be the normal English commands. The language- + specific sections 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''. + + + 1199..22.. TTeexxtt ffiilleess.. + + Most ezmlm responses are made from text files in DDIIRR//tteexxtt//. These are + created from the template file ``ezmlmrc''. Thanks to Frank Denis, and + Masashi Fujita, Wanderlei Antonio Cavassin, Sergiusz Pawlowicz, Frank + Tegtmeyer, Torben Fjerdingstad, 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 eezzmmllmmrrcc..jjpp to //eettcc//eezzmmllmmrrcc, 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 //uussrr//ddoocc// hierarchy. + + If you have made an eezzmmllmmrrcc((55)) version for another language, please + make it public domain and E-mail it as an attachment to + lindberg@id.wustl.edu. It will then be put into the eezzmmllmmrrcc directory + of the distribution site. Please take advantage of the ``Content- + transfer-encoding'' capability of ezmlm-idx>=0.30, if needed, as this + avoids problems when messages are sent via non-8-bit MUAs. + + + Other ezmlm responses, such as words in subject lines, are defines in + iiddxx..hh and can be changed there. Error messages should ideally not be + altered. However, it may make sense to change a few of them which are + used as messages to e.g. remote administrators. The defines for all + error messages are in eerrrrttxxtt..hh. + + + 1199..33.. MMuullttii--bbyyttee cchhaarraacctteerr ccooddee ssuuppppoorrtt.. + + ezmlm, as far as we know, places no restrictions on character sets. + The configurable default character set allows you to use other + character sets for out going ezmlm messages. ezmlm-make does not _p_e_r + _s_e support other character sets. However, any single-byte character + set is supported, as long as the us-ascii character sequence ``'' (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, + ``'' sequence within the text risks substitution. In practice, + both of these should be very rare and easily avoidable when setting up + an ezmlmrc(5). + + + 2200.. SSuubbssccrriibbeerr nnoottiiffiiccaattiioonn ooff mmooddeerraattiioonn eevveennttss.. + + + 2200..11.. GGeenneerraall ooppiinniioonnss.. + + This is a collection of the authors opinions and an explanation of + ezmlm-idx moderation design, which you may or may not agree with. + + + 2200..22.. UUsseerrss sshhoouulldd kknnooww tthhaatt tthhee lliisstt iiss ssuubbssccrriippttiioonn mmooddeerraatteedd.. + + List subscribers should be informed that subscriptions to the list are + controlled by a moderator. ezmlm-idx in its default setup handles + this notification during and after the subscribe handshake. Most of + this can be disabled by manipulation of the DDIIRR//tteexxtt// files. + + + 2200..33.. SSuubbssccrriibbeerrss sshhoouulldd kknnooww tthhaatt ppoossttss aarree mmooddeerraatteedd.. + + List subscribers should be informed that posts to the list are + moderated. ezmlm-idx does this by adding the ``Delivered-To: moderator + for ...'' header, but IOHO, the list owner should make the fact of + list moderation plain in introductory messages, or other means, to the + list subscribers. + + + 2200..44.. SSeennddeerrss ooff ppoossttss sshhoouulldd bbee nnoottiiffiieedd ooff rreejjeeccttiioonnss.. + + With normal use of ezmlm-idx, the sender of a rejected post is + notified that the post has been rejected and if the moderators chooses + to comment, the sender receives this comment, usually describing why + the post was rejected. This ezmlm behavior cannot be disabled at run + time. + + If post are neither accepted or rejected, they time out. ezmlm- + clean(1) notifies the sender when this happens. This behavior can be + disabled with the ezmlm-clean(1) ``-R'' (not return) switch, which has + to be placed on the command line of all invocations of ezmlm-clean(1) + (normally in DDIIRR//eeddiittoorr and DDIIRR//mmooddeerraattoorr). If you for some reason do + not wish to inform the sender of your editorial decision, you can use + this switch and let undesirable posts time out, rather than actively + rejecting them. IOHO, it is better to be "above board" and use the + normal notification mechanisms, together with active rejection and + informative rejection comments. + + The ezmlm-make(1) ``-u'' switch uses moderation in a slightly + different way. Here, posts are restricted to subscribers, but posts + from non-subscribers are sent to the moderator(s) rather that being + ignored. This to help the subscriber that posts from an alias of the + subscribed address, or the occasional non-subscriber. In this case it + is perfectly acceptable to just ignore non-accepted posts. Thus, using + the ezmlm-make(1) ``-u'' switch configures the ezmlm-clean(1) + invocations with the ``-R'' switch. + + + 2211.. EEzzmmllmm--iiddxx sseeccuurriittyy.. + + + 2211..11.. GGeenneerraall aassssuummppttiioonnss.. + + This document discusses security aspects of ezmlm-idx addition to the + ezmlm-0.53 mailing list manager. This is the authors' understanding of + security aspects of ezmlm-idx functions and not to be taken as a + warranty. If you find any errors in this document or the ezmlm-idx + package in general, please inform the authors. + + In general, ezmlm with or without the ezmlm-idx package is more secure + and less resource hungry than most other mailing list managers. Better + security than afforded by ezmlm +/- ezmlm-idx would require encryption + or PGP/digital signatures. Such an addition would make it difficult, + if not impossible, to run the mailing list from a standard MUA. The + ezmlm-idx package adds a number of functions and options, which under + some conditions may decrease security. The purpose of this document is + to discuss security aspects of using/enabling these different + functions. + + + 2211..22.. SSEENNDDEERR mmaanniippuullaattiioonn.. + + We assume that the cost of manipulating/falsifying the SENDER address + of a message is zero. Thus, any mechanism relying on SENDER alone is + 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. + + + 2211..33.. eezzmmllmm ccooookkiieess.. + + Since ezmlm doesn't rely on the SENDER, the security lies entirely + within the action-time-cookie-address combination. Anyone obtaining a + valid "combination" can do whatever the combination is meant to do, + but nothing else. Also, the cookie times out 1000000 seconds + (approximately 11.6 days) after it was issued. Since the + "combinations" are specific for a particular action and address, they + can only be reused for that particular purpose, and within 11.6 days. + Ezmlm (un)subscriptions for a given address are usually pointless to + repeat. Message moderation "combinations" are useless after they've + been used, since the message is no longer in the moderation queue. + + + 2211..44.. LLiissttss wwiitthhoouutt rreemmoottee aaddmmiinn//ssuubbssccrriippttiioonn mmooddeerraattiioonn.. + + Maliciously (un)subscribing an address with ezmlm-0.53 requires that + the attacker is able to read mail sent to the subscription address. + + With the ezmlm-idx add-on, a non-moderated list works exactly the same + way. Ezmlm-idx introduces the moderator for moderated and remote admin + lists. For any moderator functions, an attacker needs to be able to + read mail sent to a moderator's address. If s/he can do this, the + attacker can affect anything the moderator is allowed to do (since + falsifying SENDER is trivial). To minimize risks, give moderators only + the power they need, do not use more moderators than necessary, and + use moderators whose mail is hard to intercept (on the same + machine/same internal/secure network or by encryption via e.g. ssh). + + + 2211..55.. MMeessssaaggee mmooddeerraattiioonn.. + + A basic message moderated list keeps ezmlm subscriber security, but + interpolates the moderator(s) between the address of the list and the + list itself. An attacker able to read moderator mail can accept/reject + a post, if s/he can do it before a regular moderator has taken action. + The potential for abuse can be minimized by using few and local + moderators. Mail logs are needed to trace which moderator address was + misused. + + + 2211..66.. SSuubbssccrriippttiioonn mmooddeerraattiioonn.. + + A basic subscription moderated list retains ezmlm subscriber security, + but adds a moderator handshake. An attacker would need to be able to + both read mail to the subscriber address and to at least one + moderator. + + + 2211..77.. RReemmoottee aaddmmiinniissttrraattiioonn.. + + A remote admin (-r) list adds the ability of the moderator to + (un)subscribe any address. The price of this is that an attacker able + to read moderator mail can (un)subscribe any address. The moderator + handshake message will be delivered to the abused moderator address, + which will alert that moderator and reveal the compromise. Another + basic assumption is that action-date-cookie-address combinations are + only sent to the target address or a moderator and that moderator + action "combinations" are never sent to non-moderators. + + + 2211..88.. RReemmoottee eeddiittiinngg ooff eezzmmllmm tteexxtt ffiilleess.. + + ezmlm-manage(1) can allow remote administrators to edit files in + DDIIRR//tteexxtt. First, this option is disabled by default. Second, the + ``-edit'' command is accepted only when the target (the recipient) is + a remote administrator. Third, only existing files within DDIIRR//tteexxtt + are editable. It is not possible to create files. + + ezmlm replies to a valid request with an informative message and the + contents of the file. In addition, the ``Reply-To:'' address contains + a cookie based on the file name and contents, as well as the current + time. Anyone possessing this cookie can save a new version of the + text file. As with other ezmlm security, the security of this process + depends on only the remote administrator receiving remote + administrator mail. If this is not sufficiently secure for you, do not + enable this option. As always, an increase in accessibility results + results in a decrease in security. + + Cookies for editing expire in approximately 27 hours. Also, as soon as + a file is changed, the cookie is invalidated since the file contents + change. This also means that an outstanding edit request cannot be + completed if the files has been updated in the interim. + + A potential attacker obtaining a valid cookie has a window of + opportunity while you edit the file, or for at most 27 hours. S/he can + overwrite and existing text file with potentially offensive material. + Usually, this can be achieved more easily by posting to the list. S/he + can also potentially fill your disk with a large amount of data (up to + two times 10240 bytes (limited by MAXEDIT in iiddxx..hh)) and could put + part of this data onto messages leaving the list. Again, this is much + more easily achieved by e.g. sending the equivalently sized message to + your list. + + + 2211..99.. DDiiggeesstt ggeenneerraattiioonn aanndd aarrcchhiivvee rreettrriieevvaall.. + + The archive retrieval functions added by ezmlm-idx are digests + (protected by a "code") and other functions. Anyone who knows the + digest code (through reading mail logs, reading DDIIRR//mmaannaaggeerr of the + list, or reading any scripts used to send digest triggering messages) + can trigger a digest. Protect these locations accordingly! For + default lists with digests triggered from DDIIRR//eeddiittoorr via ezmlm- + tstdig(1) and ezmlm-get(1), you do not need the digest code and can + thus disable the possibility to trigger digest by mail. For other + functions, the output is sent to SENDER and can be restricted to + subscribers (the ``-s'' switch). ezmlm-get(1) functions (apart from + digest) can be entirely disabled with the i``-C'' switch, or + restricted to moderators with the ``-P'' switch or by removing + DDIIRR//ppuubblliicc. Other sections of this document discuss several other + options. All switches are documented in the man pages. + + The moderator support functions added by the ezmlm-idx package + (extended help and subscriber list) are sent only to a moderator + address, i.e. an attacker again needs to be able to read moderator + mail to read the output. The help info (DDIIRR//tteexxtt//mmoodd--hheellpp) should not + contain secrets. The ``-list'' function is normally disabled, but can + be enabled with the ezmlm-manage -l switch to aid the remote + administrator(s). + + + 2211..1100.. CCoonnvveenniieennccee ffoorr sseeccuurriittyy:: tthhee eezzmmllmm--mmaannaaggee ````--SS'''' aanndd ````--UU'''' + sswwiittcchheess.. + + ezmlm-manage(1) functions can be made more convenient, at the expense + of security. There have been many requests for these options, so they + have been added, although we recommend against using them: + + The ezmlm-manage(1) ``-S'' switch eliminates the subscriber handshake + from subscribe requests. Thus, it is no longer necessary for the + subscriber to confirm the subscription. This is not secure, but may be + convenient for some moderated lists. Use only with extreme caution. + The ezmlm-manage(1) ``-U'' switch similarly eliminates subscriber + confirmation from unsubscribe requests. Again, this is insecure and + useful only under special circumstances. If the list has any + moderators (remote or modsub), requests to (un)subscribe an address + other than sender are still routed to a moderator. This is similar to + how some other lists work. Naturally, this is insecure because it + relies on SENDER. Unsubscribe requests are always non-moderated, + since, IOHO, it seems un-ethical to force a subscriber to remain on a + list. Where an unsubscribe confirm request is sent out it is (also) + sent to the target, except when the request was initiated by a + moderator on a list with remote administration (DDIIRR//rreemmoottee exists). + The (un)subscription target is always informed about completed + (un)subscribe request, whether initiated by that address, another + address, or by a moderator. Thus, attempts of a user or moderator to + subscribe an address will be brought to the attention of the user + receiving mail at that address. + + + 2211..1111.. DDeenniiaall ooff sseerrvviiccee.. + + ezmlm-get(1) archive retrieval functions can be used to deplete system + resources. However, this can also be done by posting messages to + lists, mail bombing, etc. If you are worried about this, you can use a + combination of ezmlm-manage/ezmlm-get ``-C'', ``-s'', and ``-P'' + switches, removal of DDIIRR//ppuubblliicc, and removal of the mail-triggered + digest function (by removing the digest code from the ezmlm-get(1) + command line) to decrease availability of these functions (see man + pages). Digest can also be triggered by direct execution of ezmlm-get + from within a script from DDIIRR//eeddiittoorr as in the default setup with the + ezmlm-make(1) ``-d'' switch. + + + 2211..1122.. MMooddeerraattoorr aannoonnyymmiittyy.. + + Anyone getting messages from the list can see the ``Delivered-To: + Moderator for ...'' header and realize that the list is moderated. In + the authors opinion, this is fair and appropriate. If this bothers + you, edit the source of eezzmmllmm--ssttoorree..cc. + + While the fact that the list is moderated will be disclosed by the + headers, the moderator(s)' identity will not be disclosed by the + header. Moderators are anonymous to anyone who cannot directly read + the mail log, the moderator list, or monitor your outgoing and + incoming mail. Anyone intercepting the acting moderators' mail or able + to read the mail log can determine who took a particular action. + + Moderator E-mail addresses are not (to our knowledge) disclosed by any + ezmlm mechanism. Thus, the poster does not know who rejected/accepted + the message. Other moderators can find out that the message was + accepted (by seeing it on the list or by themselves committing to a + reject/accept reply) or rejected (by being informed by the poster or + by themselves committing to a reject/accept reply). If no moderator + takes any action for a given time (120 h - configurable to anything + 24-240 h via DDIIRR//mmooddttiimmee - and the parameters are likewise + configurable at compile time via iiddxx..hh) the message times out, an act + for which no particular moderator can be held accountable. + + Subscription requests are acted upon only if a moderator completes the + transaction by approving the requests. Requests can not be directly + disapproved, but the associated cookie becomes invalid after + approximately 11.6 days. Neither the subscriber nor the other + moderators know which moderator accepted the subscription request. + Requests to unsubscribe from the list are never moderated or otherwise + controlled, except by requiring confirmation from the subscriber + (normal unsubscribe) or the moderator that initiated the request + (remote administration). If several moderators approve the same + subscribe request, the user gets multiple notifications. + + The triggering message (the moderation approval or the moderator's + completion of the subscription request) are not returned or logged. + This protects moderator anonymity, but makes it harder to track down + the offender in case of abuse. Only a good mail log will help. IOHO, + abuse of these mechanisms requires considerably more effort that it is + worth to (un)subscribe someone to a list. Also, IOHO, moderator + anonymity is more important. If this increased difficulty in tracking + down abusive behavior bothers you, don't use the remote administration + and moderated subscription features. + 2211..1133.. CCoonnffiiddeennttiiaalliittyy ooff ssuubbssccrriibbeerr EE--mmaaiill aaddddrreesssseess.. + + The optional ``-list'' command enabled by the ``-l'' ezmlm-manage(1) + command line switch returns a subscriber list to the moderator. Again, + anyone who can intercept a moderators' mail can fake SENDER and use + this command to obtain a subscriber list. The use of local moderators + minimize the risk. If the risk of subscriber disclosure is not worth + this convenience, do not enable this feature. + + + 2211..1144.. HHeellpp mmeessssaaggee ffoorr mmooddeerraattoorrss.. + + ezmlm-manage sends DDIIRR//tteexxtt//mmoodd--hheellpp, rather than DDIIRR//tteexxtt//hheellpp in + reply to messages to list-help@host if the target address is a + moderator. DDIIRR//tteexxtt//mmoodd--hheellpp should not contain secrets or other + confidential information. + + + 2211..1155.. SSuubblliissttss.. + + 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 DDIIRR//eeddiittoorr 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 DDIIRR//hheeaaddeerr-- + aadddd 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. + + + 2211..1166.. SSQQLL ddaattaabbaasseess.. + + 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. + + + 2211..1177.. RReeppoorrttiinngg sseeccuurriittyy pprroobblleemmss.. + + Please send private E-mail about any security problems with the ezmlm- + idx additions to Fred Lindberg, lindberg@id.wustl.edu. For ezmlm, + please send them via private E-mail to Dan J. Bernstein, the author of + ezmlm proper. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +