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.