Google Git
Sign in
apache/infrastructure-ezmlm-idx/refs/heads/avoid-duplicate-headers/./FAQ
blob: f34e1ac4fa72602d887b0a59b447e336f61d34a2 [file]
EZFAQ 0.40 - ezmlm-idx and ezmlm FAQ
Fred Lindberg, lindberg@id.wustl.edu, Fred B. Ringel,
fredr@rivertown.net, & Bruce Guenter bruce@untroubled.org
2006-11-24
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.
DDaann JJ.. BBeerrnnsstteeiinn''ss eezzmmllmm--00..5533
+o <ftp://cr.yp.to/pub/software/ezmlm-0.53.tar.gz>
+o <ftp://ftp.ezmlm.org/pub/qmail/ezmlm-0.53.tar.gz>
+o <ftp://ftp.ntnu.no/pub/unix/mail/qmail/ezmlm-0.53.tar.gz>
+o <ftp://ftp.pipex.net/mirrors/qmail/ezmlm-0.53.tar.gz>
+o <ftp://ftp.jp.qmail.org/qmail/ezmlm-0.53.tar.gz>
+o <ftp://ftp.rifkin.technion.ac.il/pub/qmail/ezmlm-0.53.tar.gz>
+o <ftp://ftp.mira.net.au/unix/mail/qmail/ezmlm-0.53.tar.gz>
+o <http://www.qmail.org/>
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). 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 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 <ftp://ftp.ezmlm.org/pub/patches/>
+o <ftp://gd.tuwien.ac.at/infosys/mail/qmail/ezmlm-patches/> ftp
mirror in Austria.
+o <http://gd.tuwien.ac.at/infosys/mail/qmail/ezmlm-patches/> http
access to the same mirror.
+o <ftp://ftp.win.or.jp/pub/network/mail/qmail/ezmlm-idx/> ftp
mirror in Japan.
eezzmmllmmrrcc((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), 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 bruce@untroubled.org. Please leave comments intact and
in English and do not change the order of items in the file.
This will facilitate maintenance.
+o <ftp://ftp.ezmlm.org/pub/patches/ezmlmrc/>
+o <ftp://gd.tuwien.ac.at/infosys/mail/qmail/ezmlm-
patches/ezmlmrc/>
+o <http://gd.tuwien.ac.at/infosys/mail/qmail/ezmlm-
patches/ezmlmrc/>
+o <ftp://ftp.win.or.jp/pub/network/mail/qmail/ezmlm-idx/ezmlmrc/>
eezzmmllmm--iissssuubb--00..0055
+o <ftp://ftp.ezmlm.org/pub/patches/ezmlm-issub-0.05.tar.gz>. 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 <ftp://ftp.ezmlm.org/pub/patches/>
+o <ftp://summersoft.fay.ar.us/pub/qmail/>
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 <ftp://ftp.ezmlm.org/pub/patches/ezman/>
+o An on-line html version <http://www.ezmlm.org/ezman>
TThhiiss FFAAQQ
This FAQ is built from a sgml source. It is available in the
following formats:
+o A text file <ftp://ftp.ezmlm.org/pub/patches/ezfaq.txt.gz>
+o An on-line html version <http://www.ezmlm.org/>
+o Html for download
<ftp://ftp.ezmlm.org/pub/patches/ezfaq.html.tar.gz>
+o A postscript (letter) version
<ftp://ftp.ezmlm.org/pub/patches/ezfaq.ps.gz>
+o A postscript (A4) version
<ftp://ftp.ezmlm.org/pub/patches/ezfaq.ps4.gz>
+o Via mirrors mentioned for the ezmlm-idx package.
+o An up-to-date text version,FFAAQQ..iiddxx, included with the ezmlm-idx
package.
WWWWWW rreessoouurrcceess
AAnn oonn--lliinnee vveerrssiioonn ooff tthhiiss FFAAQQ
<http://www.ezmlm.org/>The main site with an up-to-date
mirror list. <http://www.de.ezmlm.org/>German mirror.
<http://www.pl.ezmlm.org/www.ezmlm.org/>Polish mirror.
<http://www.jp.ezmlm.org/>Japanese mirror.
<http://www.pt.ezmlm.org/>Portuguese mirror.
<http://www.at.ezmlm.org/>Austrian mirror.
<http://www.ca.ezmlm.org/ezmlm/>Canadian mirror.
GGeenneerraall qqmmaaiill aanndd eezzmmllmm iinnffoo
+o Dan J. Bernstein's qmail page
<http://www.pobox.com/~djb/qmail.html>
+o Dan J. Bernstein's ezmlm page
<http://www.pobox.com/~djb/ezmlm.html>
+o Russell Nelson's qmail page <http://www.qmail.org>
+o Mirrors of www.qmail.org <http://www.ISO.qmail.org>.
Substitute your two-letter country abbreviation for ``ISO''.
TThhee qqmmaaiill mmaaiilliinngg lliisstt aarrcchhiivvee
+o <http://www.ornl.gov/cts/archives/mailing-lists/qmail/>
TThhee eezzmmllmm mmaaiilliinngg lliisstt aarrcchhiivvee
+o <http://sunsite.auc.dk/mhonarc-archives/ezmlm/>
<http://www.ezmlm.org/archive/> This archive of the ezmlm
list is searchable from 11/97-present. ezmlm-cgi(1) is used
to allow direct access to the sublist archive.
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
11..77.. WWhheerree ddoo II sseenndd ccoommmmeennttss oonn tthhiiss ddooccuummeenntt??
To the authors via E-mail:
+^Ho Bruce Guenter, bruce@untroubled.org
+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 install
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 install
# 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
<http://www.ezmlm.org/ezman/> 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 <<EOF
From: list-help@host
To: $SENDER
Subject: list@host subscriber count
Current number of subscribers:
EOF
ezmlm-list ~/DIR | wc -l
} | /var/qmail/qmail-inject -f list-return- "$SENDER"
exit 0
Then, create DDIIRR//ccoouunntt containing ``|/path/program'' and then do ``ln
-sf DIR/count ~/.qmail-list-count''. Now, the command will pass the
message to ``program''. The first thing ``program'' looks for is its
delivered-to line to detect looping. If not found, it goes on to print
this header, followed by some minimal text and the subscriber number.
This can of course be made prettier with ezmlm-list error checking,
and maybe in perl, but shows how easy it is to extend ezmlm. All
thanks to the DJB/qmail delivery mechanism.
44..3311.. HHooww rreemmoottee aaddmmiinniissttrraattoorrss ccaann rreettrriieevvee aa ssuubbssccrriibbeerr lliisstt
A user with shell access can always manipulate subscriber lists with
ezmlm-sub(1), ezmlm-unsub(1), and ezmlm-list(1) for the lists s/he
owns.
Sometimes a remote administrator requires a list of subscriber E-mail
addresses. At the same time, the list should be kept out of the hands
of spammers and all unauthorized entities. By default, ezmlm does not
allow remote subscriber list retrieval. You can enable the ``-list''
command for remote retrieval of a subscriber list by using the ezmlm-
make(1) ``-l'' switch or by adding the ``-l'' switch to the ezmlm-
manage(1) line in DIR/manager. With this switch, ezmlm will permit
retrieval of a subscriber list, but only to remote administrators.
Subscribers cannot get the list membership, and any outsider would
have to be able to read a remote administrator's mail to get the list.
_N_o_t_e_: _T_h_i_s _o_p_t_i_o_n _i_s _n_o_t _f_u_n_c_t_i_o_n_a_l _u_n_l_e_s_s _t_h_e _l_i_s_t _i_s _c_o_n_f_i_g_u_r_e_d _f_o_r
_r_e_m_o_t_e _a_d_m_i_n_i_s_t_r_a_t_i_o_n_, _i_._e_. _t_h_e _e_z_m_l_m_-_m_a_k_e_(_1_) _`_`_-_r_l_'_' _s_w_i_t_c_h_e_s _n_e_e_d _t_o
_b_o_t_h _b_e _u_s_e_d_.
The list returned is unsorted for efficiency reasons. You can easily
sort it or use your mail reader to find a specific entry. The number
of subscribers is shown at the bottom of the list. To get the number
of subscribers from the command line, use:
% ezmlm-list DIR | wc -l
44..3322.. HHooww rreemmoottee aaddmmiinniissttrraattoorrss ccaann ddeetteerrmmiinnee tthhee nnuummbbeerr ooff ssuubb--
ssccrriibbeerrss
For the list aaa@example.com, send a message to aaa-listn@example.com.
This is preferable to the ``-list'' command for very large lists.
44..3333.. HHooww rreemmoottee aaddmmiinnss ccaann sseeee iiff aann aaddddrreessss iiss aa ssuubbssccrriibbeerr oorr nnoott
For the list aaa@example.com, and subscriber user@host.cn send a
message to aaa-query=host.cn@example.com. Users can do this as well,
but in that case the reply is sent to the target address
(user@host.cn) and not to the SENDER to protect the subscriber
addresses.
44..3344.. HHooww rreemmoottee aaddmmiinniissttrraattoorrss ccaann sseeaarrcchh tthhee ssuubbssccrriippttiioonn lloogg
The same conditions that enable remote administrators to retrieve a
subscriber list (see ``'') also enable the remote admin to retrieve
the subscription log, i.e. the log of changes made to the subscriber
list. The command is list-log@host. The entries are of the form ``date
timestamp dir event address comment''. ``dir'' is ``+'' for addition
of an address, ``-'' for removal, ``event'' is empty for normal
(un)subscribe ``manual'' for changes made with ezmlm-(un)sub, and
``probe'' for removals via bounce handling. ``address'' is the
subscription address, and ``comment'' is empty or the subscribers
``From:'' line. The log can be used to look at recent
additions/removals and to try to track down a subscriber address from
e.g. the name on the ``From:'' line. The log is written on a best-
effort basis. In contrast to the subscriber database, entries in the
log may be lost at a system crash.
The remote administrator can do a case-insensitive search through the
log with the command list-log.xxx@host, where ``xxx'' is any sequence
of letters/numbers that must occur on a line in order for that line to
be included in the reply. A ``_'' is a wild card and should be used
for special characters as well. Thus, to search for any entry with a
host name of host* mail list-log._host and to find entries for ``Keith
John...'' etc, use list-log.keith_john.
For SQL-enabled lists, this command searches the ``list_slog'' table.
44..3355.. HHooww tteexxtt ffiillee eeddiittiinngg wwoorrkkss..
If a list is set up with the ezmlm-make(1) ``-n'' switch, or if the
``-e'' switch is added to the ezmlm-manage(1) line in DDIIRR//mmaannaaggeerr,
ezmlm allows remote administrators to edit the text files that make up
most of the ezmlm responses. Of course, this will work only if remote
administration is enabled for the list. Replies are sent only if the
target address is a remote administrator. Thus, ezmlm does not rely
on SENDER (easily forged) but on the notion that only the recipient
receives the message. This is a reasonable assumption for remote
administrators that receive mail on the local system.
With this switch, ezmlm replies to the -edit command with a list of
the files in DDIIRR//tteexxtt//. Only files where editing seems reasonable are
included in the list. The remote administrator can edit any file in
DDIIRR//tteexxtt// by sending e-mail containing the new text to -edit.file
where ``file'' is the name of the file replaced (edited). The file
must exist and the name consist of only lower case letters and '-'.
Any '-' (hyphen) must be substituted by a '_' (underscore). For remote
administrator convenience, the substitution has been made in the list
of files sent in reply to the -edit command.
In reply to this command, ezmlm sends a message with the file and
editing instructions. A ``cookie'' based on the date, file name, and
contents of the file is added to the ``Reply-To:'' address. The cookie
becomes invalid as soon as the file has been changed, or after 27
hours, whichever is shorter. Also, the cookie cannot be used to edit
any other file, even if the other file has exactly the same contents.
If you sent an edit request, and decide not to edit the file, you can
simply delete the message.
To apply standard changes to all your text files it is easier to edit
~~//..eezzmmllmmrrcc. To reset the list's text files back to their default
contents (as specified by eezzmmllmmrrcc((55))), use the ezmlm-make(1) ``-ee''
switch together with any other switches used to set up the list, or
the ``-++'' switch and any switches that you whish to change from the
current configuration.
44..3366.. HHooww ssuubbjjeecctt lliinnee pprreeffiixxeess wwoorrkk..
First of all, it is against a number of RFCs to modify the
``Subject:'' header of messages. However, it is frequently requested
by users who have seen it on other list managers. Second, it is many
times worse to have a prefix that changes from message to message,
such as a prefix with the message number. However, a number of lists,
especially in Japan, use this feature and in its absence these lists
might be unable to take advantage of ezmlm. Thus, while we recommend
against using a prefix, ezmlm-idx supports it.
To add a subject prefix, just put the text into DDIIRR//pprreeffiixx. The only
format that makes any sense is ``list:'' or ``(list)'' or such.
The message number prefix is activated by putting e.g. ``(list-#)''
into DDIIRR//pprreeffiixx. ``#'' is replaced by the message number. ezmlm
refuses to make more drastic changes in the subject of a message. As a
consequence, the message number prefix is added only when the subject
does not already contain a prefix. Thus, replies will have the message
number of the original message. Doing anything else and still
supporting rfc2047-encoded subjects in the archive threading (much
more important) would require decoding the subject, removing/editing
the prefix, and re-encoding the subject. This is far too invasive.
The entire thread can always be retrieved by sending a message to
list-thread-x where ``x'' is the message number in the prefix of any
message in the thread.
44..3377.. HHooww bboouunncceess aarree hhaannddlleedd..
Ezmlm messages are sent with an envelope sender (``Return-Path'') that
directs bounces to DDIIRR//bboouunncceerr and also via ``VERP'' contain
information about the intended recipient. Thus, programs run from
DDIIRR//bboouunncceerr know the subscriber for whom the message bounced. ezmlm-
weed(1) is used to weed out delivery delay notification and other
junk. For others ezmlm-return(1) decides if the address is a
subscriber. If so, it saves the first bounce message and a list of
bounced-message numbers. ezmlm-warn(1) executed from e.g. DDIIRR//eeddiittoorr
goes through these bounce files. If it finds any that are older than
1,000,000 seconds (about 11.6 days) it sends a warning message to the
subscriber. If this warning message bounces, ezmlm-return(1) sets up a
"warning flag" for the subscriber. If ezmlm-warn(1) finds a warning
flag older than 11.6 days, it sends a "probe" to the subscriber. If
ezmlm-return(1) receives a bounced probe, the subscriber is
automatically unsubscribed.
The ezmlm-warn(1) ``-t'' switch can be used to change the time-out (in
days). The ezmlm-warn(1) ``-d'' switch causes processing of ``list-
digest'' bounces rather than ``list'' bounces. ezmlm-weed(1) and
ezmlm-return(1) can handle bounces for either list.
ezmlm-warn(1) also removes any files in the bounce directory that are
older than 3 times the bounce time-out.
ezmlm-warn(1) is normally run from DDIIRR//eeddiittoorr. This can take quite a
lot of resources, if there are a large number of bouncing addresses
(>>1000) on a busy list, since by default all bounces are stored in a
single directory and ezmlm-warn(1) examines all of them with each
invocation. ezmlm-idx->=0.32 changes bounce handling to improve
performance for large lists. Bounces are stored in subdirectories of
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.
<http://www.tcx.se/>).
For most lists, the only addresses that are stored in the SQL
database are the subscribers of list and digest, and the ``allow''
aliases. It is NOT normally advisable to store moderator addresses
there, since they are needed only at the main list and secrecy is
more important. ``Deny'' addresses are few and again only needed at
the main list. ``Allow'' are put in the SQL database when using the
default ezmlmrc file only to make all relevant addresses
manipulatable via the SQL server. The other tables are created, in
case they are wanted (the cost for having them as empty table is
zero). The basedir/sql file is the decision point. If it exists, an
SQL table is used; if not a local ezmlm db is used.
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 (
<http://www.tcx.se>) 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 bruce@untroubled.org. 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 ezmlm@list.cr.yp.to. If you're
unsure where the bug is, you can start with bruce@untroubled.org. 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 bruce@untroubled.org, 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 bruce@untroubled.org.
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, this is your ``moddir''. If not:
% cat DIR/remote
If this succeeds with a directory name, 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. ``</text/mod-request/>'', and modify it
appropriately. Some tags have conditional flags, so that succeeding
text is copied only if specific switches are on/off. Thus, text
succeeding ``</text/file#rms/>'' is copied into DDIIRR//tteexxtt//ffiillee if and
only if the ezmlm-make(1) ``-rms'' switches are all used. For more
info, see documentation in eezzmmllmmrrcc((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.
``</modsub/#s>''. Also, you need to create that directory, and the
subscribers subdirectory under it. NOTE: DDIIRR//mmoodd// is still required as
the base directory for the message moderation queue.
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 ``</inlocal/>'' 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
``</inlocal/>''.
Running:
% ezmlm-make -c ~virt/LIST ~virt/.qmail-dom1-list \
list host1.dom.com
will produce a LLIISSTT//iinnllooccaall of virt-dom1-list by substituting the
first part between two ``-'' (dom1) for ``<#1#>''. Two levels of
dashes are accommodated, i.e. ``<#2#>'' will be replaced by the second
part between two ``-'' (in this case empty (_S_i_c_!)). For more info,
see ezmlm-make(1) and comments in eezzmmllmmrrcc.
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)):
</msgsize/>
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 ``-0
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 ``-0
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
(http://ezmlm.org/archive/patches/ezmlm-return.diff) which fixes a
bug in ezmlm-0.53 bounce handling. The patch is superseded by ezmlm-
idx.
To redistribute the load of bounce warning and probe addresses to off-
peak hours, you may want to set up the list without ezmlm-warn(1) by
using the ezmlm-make ``-w'' switch, and instead execute ``ezmlm-warn
DIR'' via crond(8). You also need to run ``ezmlm-warn -d DIR'' for
digest bounces if your list is configured with digests. Normal ezmlm
list with ezmlm-idx>=0.32 will have an insignificant bounce load,
except if you bulk add addresses, e.g. from a MLM without bounce
handling. In the latter case, the load will be higher for the first
2-4 weeks, then decrease drastically. If you feel you need to run
ezmlm-warn(1) from crond(8), you should seriously consider sublisting
your lists.
_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 install
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
bruce@untroubled.org. 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 ``</''
does not occur anywhere as the first characters of the line, and the
character sequence ``<#x#>'' (where ``x'' is any number, or A, B, C,
D, F, H, L, R, T) does not occur anywhere is text (if it does, it
risks being substituted). Also, any occurrence or ``<#A#>'' and
``<#R#>'' that is the first on any text line will be substituted by
ezmlm-manage and ezmlm-store. Any occurrence of ``!A'' and ``!R'' as
the first characters on a line will be substituted by ezmlm-manage and
ezmlm-store.
For multi-byte character codes, the same restrictions apply. Thus,
``</'' at the start of a line will confuse ezmlm-make, and any
``<#x#>'' sequence within the text risks substitution. In practice,
both of these should be very rare and easily avoidable when setting up
an ezmlmrc(5).
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 Bruce Guenter, bruce@untroubled.org. For ezmlm,
please send them via private E-mail to Dan J. Bernstein, the author of
ezmlm proper.