Try to determine where the problem occurs and how to reproduce it:
% ezmlm-list DIR
% ezmlm-list moddir
% chown -R user DIR
% chown -R alias DIR
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.
If you have found a bug in the ezmlm-idx additions, please
send a bug report by E-mail to lindberg@id.wustl.edu. Describe
the error, your setup, and your system in sufficient detail so
that it can be reproduced by third parties. Include relevant sections
of mail log, and information about any error messages
returned. If you ran into a problem and resolved it on your own,
include a fix as a context diff against the distribution.
If you have found a bug in ezmlm proper (unlikely), please send a similar
bug report to djb@cr.yp.to or
djb-ezmlm@cr.yp.to. If you're unsure where the bug is,
you can start with lindberg@id.wustl.edu.
If you have problems and questions, please refer to the
documentation, then to mailing list archives, then E-mail the
ezmlm mailing list or the authors.
E-mail to lindberg@id.wustl.edu, ideally with a context diff.
For ezmlm proper, ezmlm@list.cr.yp.to may be
better.
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. ~/__TSTDIR__err may contain
a relevant error message.
For further help, E-mail lindberg@id.wustl.edu.
ezmlm-check(1) is included in the ezmlm-idx distribution. ezmlm-check(1) is an evolving shell script which when put into a .qmail 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 DIR/inhost mismatch, missing files, etc. To use ezmlm-check(1), place a line:
|/usr/local/bin/ezmlm/ezmlm-check 'DIR'
list-subscribe,
list-help, etc), DIR/moderator (for mail to list-accept,
list-reject).
ezmlm-check(1) will send its output to
SENDER. The rest of the .qmail file will be ignored.
If you use a non-standard
ezmlm binary directory, 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.
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
~virt/.qmail-test
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 ~user/.qmail-test 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
~virt/.qmail-test for the list test@virtual.dom and
~user/.qmail-test for the list user-test@host.
% cat DIR/num
% cat DIR/num
% ls -l DIR/mod/pending
% ls -l DIR/mod/pending
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.
% ezmlm-list DIR
% chown -R user DIR
% chown -R alias DIR
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.
This error occurs when ezmlm-make is used to set up a list, and it tries to create a directory or a .qmail-list 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: NOTE: DO NOT USE THESE COMMANDS WITHOUT UNDERSTANDING THEM. You may erase more than you intended!
% rm -rf DIR
% rm -rf ~/.qmail-list ~/.qmail-list-*
To use ezmlm-make(1) to modify an existing list, without changing the subscriber or moderator lists or the message archive, use the ezmlm-make ``-e'' switch. NOTE: any customization that you've made that is not specified by the ezmlmrc(5) file used will be overwritten. For instance, if you manually added checks to DIR/editor, a pointer to a custom moderator database in e.g. DIR/modsub, or made a change to a DIR/text/ file (such as adding a ``welcome'' message to DIR/text/sub-ok) these changes will be lost. To retain such changes (especially ones that are common for several of your lists), place them in a local ~/.ezmlmrc file instead. You can either make such changes the default for your lists, or you can configure ~/.ezmlmrc so that they are added only if a specific ezmlm-make switch is used. (see Customizing ezmlm-make operation).
There is no readable ezmlmrc(5) file in /etc/ nor in the ezmlm binary directory. If you have .ezmlmrc in ``dotdir'' (see Terminology: dotdir) use the ezmlm-make(1) ``-c'' switch (see Customizing ezmlm-make operation).
Make sure this is an indexed list and has an ``ezmlm-get'' line first
in DIR/manager. 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.
(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.
Either the list is not set up for remote administration (i.e.
DIR/remote 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
DIR/remote. If you are using a non-default moderator db
location, make sure that the moddir name is in DIR/remote (for
remote admin only) or DIR/modsub (if there is subscription
moderation as well). In both cases, the contents will be
ignored unless they start with a ``/''.
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).
The list is not set up as a moderated list. Check DIR/editor. 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 DIR/editor. If there is, the list is not moderated. Also, DIR/modpost 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 DIR/modpost, but may be confusing if the user is unaware of this ezmlm-store(1) feature.
% ezmlm-list moddir
% chown -R user DIR
% chown -R alias DIR
% ezmlm-list DIR
Moderator comments are where the moderator chooses to ``reject'' the message and inform the person posting which his/her message was inappropriate. However, if a moderator wants to comment on accepted posts, the moderator may only do so via a follow-up post to the list. This is to avoid anonymously tagged-on text to posts. If a moderator has something to say to the list, they should (and can only) do so in regular posts. If you want to edit posts before sending them to the list, set up a moderated list with you as the only moderator. Into DIR/editor 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>%%%
By default, only a subset of message headers are sent out in any digest and archive retrieval requests. First, headers in DIR/headerremove 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.
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.
The digest by default removed non-essential headers like ``In-Reply-To:'' from messages. Modern MUAs, like Mutt 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.
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 DIR/sublist. Check the ownership of DIR/sublist, 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).
Only complete lines ending with ``newline'' are copied. The last line in the DIR/text/ file most likely lacks a terminal ``newline''.
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
% cat DIR/remote
Check for moderators:
% ezmlm-list moddir
% chown -R user moddir
# chown -R alias moddir
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).
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 DIR/subscribers/, then:
% ezmlm-list DIR > tmp.tmp
( edit tmp.tmp to fix any problems )
% rm -rf DIR/subscribers/*
% xargs ezmlm-sub DIR < tmp.tmp
This will list all E-mail addresses, allow you to edit them, then re-subscribe them. Don't forget to re-enable deliveries.
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 DIR/headeradd. For older lists, use ``ezmlm-make -+'' or ``ezmlm-make -e'' to update them, or just add a ``Precedence: bulk'' line to DIR/headeradd.
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
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 DIR/deny/ with
% ezmlm-sub DIR/deny badadr@badhost
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 DIR/editor or DIR/manager. 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.
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 -getv 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.