6. Possible error conditions in ezmlm lists

6.1 What do I do if ezmlm doesn't work?

Try to determine where the problem occurs and how to reproduce it:

• Do messages to ezmlm return an error message to the sender or not?
• What is/are the error message(s)?
• What does ezmlm log into the mail log?
• Are you using a setup with virtual domains? If so, have you adjusted DIR/inlocal (see Adapting ezmlm-make for virtual domains)?
• Are posts sent out to the subscribers?
• Are there subscribers?

  %  ezmlm-list DIR
  

• Are there moderators?

  % ezmlm-list moddir
  

  where ``moddir'' is the contents of DIR/remote (for remote admin lists), of DIR/modsub (for subscription moderated lists) or DIR/modpost (for message moderation), if and only if the contents start with a forward slash. The default in all cases is DIR/mod/. If both DIR/modsub and DIR/remote contain directory names, the one in DIR/modsub is used for both subscription moderation and remote admin.
• 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 operates (i.e. the user qmail changes to during the delivery).
• Read the qmail log and capture relevant parts.
• Did you customize the package at all? If so, try the default settings which are known to work.
• Did you customize ezmlmrc(5)? Try to use the default copy (skip the -c switch).
• Did your customization of .ezmlmrc fail to have an effect? Remember to use the -c switch. The .ezmlmrc file used is the one in ``dotdir'', i.e. the directory where the .qmail files go, usually, but NOT necessarily, the one in your home directory.
• 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.
• Make sure to take notes of how the list was created (which flags you used, etc.).
• use ezmlm-check(1) (see Using ezmlm-check to find setup errors). and compare the variables identified by ezmlm-check to DIR/inlocal, etc. If you don't get a reply from ezmlm-check, then message was not delivered properly. Check your qmail setup.
• Try to find your problem or a question/item close to it in the FAQ.
• If this didn't resolve the problem, post to the ezmlm mailing list, describing how you set up the list, your general setup (especially the relevant control files for a virtual domain), what works and what doesn't and what results from different actions (log entries, error messages).

If you have solved a problem that you believe might be more general, please send a description of the problem and its solution to the authors, ideally as a FAQ item.

6.2 How do I report ezmlm bugs?

If you have found a bug in the ezmlm-idx additions, please send a bug report by E-mail to lindberg@id.wustl.edu. Describe the error, your setup, and your system in sufficient detail so that it can be reproduced by third parties. Include relevant sections of mail log, and information about any error messages returned. If you ran into a problem and resolved it on your own, include a fix as a context diff against the distribution.

If you have found a bug in ezmlm proper (unlikely), please send a similar bug report to djb@cr.yp.to or djb-ezmlm@cr.yp.to. If you're unsure where the bug is, you can start with lindberg@id.wustl.edu. If you have problems and questions, please refer to the documentation, then to mailing list archives, then E-mail the ezmlm mailing list or the authors.

6.3 Where do I send suggestions for ezmlm-idx improvements?

E-mail to lindberg@id.wustl.edu, ideally with a context diff. For ezmlm proper, djb-ezmlm@cr.yp.to may be better.

6.4 Using ezmlm-check to find setup errors.

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'

ezmlm-check(1) in combination with mail logs and ezmlm error messages should make it easy to diagnose setup problems. When done, don't forget to remove the ezmlm-check(1) line. It is not security-proofed against SENDER manipulation and with it in place, the list won't work.

ezmlm-check(1) does not check all aspects of list generation, but catches all common errors when lists are created with ezmlm-make(1), an many other errors as well. The ezmlm-check(1) reply is also very valuable for support via E-mail.

6.5 Posts are rejected: Sorry, no mailbox here by that name (#5.1.1).

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.

6.6 Post are not sent to subscribers.

Non-moderated lists

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!).

Message moderated lists

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 execute bit set, it was successfully processed by ezmlm-store(1). If this is true, but no moderation request was sent, then continue with Messages posted to the list do not result in moderation 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 DIR/msgsize 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).

General

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), the most common error is that there are no subscribers. In this case, ezmlm-send(1) sends a message from list-help@host, and logs success, but no recipients are logged. To qmail, it is perfectly acceptable to send a message without recipients, so no error message is logged.
5. Check subscribers:

        
           % ezmlm-list DIR
   

6. Assure that ownerships are correct on the list directories:

           % chown -R user DIR
   

   For lists owned by the ``alias'' user (in ~alias):

           % chown -R alias DIR
   

7. Most other problems should be easily corrected with the help of the qmail log.

6.7 Subscribe fails: I do not accept messages at this address (#5.1.1).

This error occurs because the local part of the recipient address (as passed in the environment variable ``LOCAL''; e.g. user-list-subscribe) does not start with the contents of DIR/inlocal (e.g. user-list). The most common cause of this problem is that ezmlm-make(1) was used with incorrect arguments. For normal users, this includes attempting to create lists that do not start with the user name, and to erroneously include the user name in the ``dot'' file name. For virtual domains, DIR/inlocal needs to be adjusted (See What names can I use for my mailing lists? and Lists in virtual domains).

Another potential source of the problem are mistyped ezmlm-make arguments, such as the host name. It is also possible that address rewriting leaves the recipient host name (as passed in the environment variable ``HOST'') different from the name specified in DIR/inhost.

In general, these problems are easy to diagnose with the ezmlm-check(1) script (See Using ezmlm-check to find setup errors).

6.8 ezmlm-make fails: usage: ezmlm-make ...

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.

6.9 ezmlm-make fails: Unable to create ...

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).

6.10 ezmlm-make fails: ... ezmlmrc does not exist

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).

6.11 Index/get/thread requests fail quietly or with errors from ezmlm-manage.

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.

6.12 Digest triggering requests fail.

If you get an error message, it tells you why the request failed. If you do not, see the previous item. Try using syntax without ``-'' after the ``dig'' command. Also, requests that would result in an empty digest are silently ignored, but the reason why no digest was created is logged to the mail log. This is done so that cron scripts generating daily digest will just fail silently, rather than generating an error, for what isn't really one.

6.13 Remote administration (un)subscribe confirm requests go to the user, not the moderator.

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 ``/''.

6.14 (Un)subscribers does not receive a (un)subscribe acknowledgement

With normal ezmlm lists, a subscriber confirming a subscription or a non-subscriber confirming a unsubscribe request results in a message to the target address. This message is suppressed when the list is set up for subscription and/or remote administration, so that confirmations from multiple moderators do not result in multiple messages to the target address. The target address is always notified if the subscriber status of the address changes (from non-subscriber to subscriber or vice versa).

6.15 Messages posted to a moderated list are sent out without moderation.

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.

6.16 Messages posted to a moderated list do not result in moderation requests.

• Check that ~/.qmail-list is a link to DIR/editor.
• Check that DIR/editor contains ezmlm-store(1) and not ezmlm-send(1). If this is not the case, the list is not message moderated.
• Check for the presence of DIR/modpost. If this file is missing, the list is not moderated, even if DIR/editor is set up with ezmlm-store(1).
• 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.
• Check to see that there are indeed moderators:

        
  % ezmlm-list moddir
  

  where ``moddir'' is the contents of DIR/modpost if they start with a ``/'', otherwise those of DIR/remote (same ``/'' requirement), and DIR/mod/ by default.
• Check file ownerships. Another common problem is directory ownerships, especially for lists under ~alias. To correct this error, issue the following command while in the ~alias directory (User the user/group of the list owner; for ~alias lists user=alias, group=qmail):

  % chown -R user DIR
  

6.17 Moderation request replies do not result in the appropriate action.

• Check that the address in the moderation request is correct.
• Check that the ~/.qmail-list-accept-default and ~./qmail-list-reject-default links exists and point to DIR/moderator.
• Check that DIR/moderator invokes ezmlm-moderate(1), and that there is a copy of ezmlm-send(1) in the ezmlm binary directory.
• Check the qmail log to see that the replies were delivered to this address.
• Check directory ownerships. For lists under alias:

       
  % chown -R alias DIR
  

  NOTE: This needs to be done every time you add/remove moderators as ``root''. For user-controlled lists (i.e. you are ``user'' when running e.g. ezmlm-sub(1)) this is not a problem. If setting up lists for alias, 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.
• Check the qmail logs: After the delivery of the moderation request, ezmlm-send(1) should run to send messages to all the list subscribers.
• Make sure there are list subscribers:

       
  % ezmlm-list DIR
  

6.18 Moderator comments with moderation request replies are not added to the post/sent to the poster.

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
%%%

     
> %%%
comment
> comment2
> %%%

%%
COMMENT
%%

%%% this is my comment %%%

ezmlm said>%%%
comment
ezmlm said>%%%

6.19 Some headers are missing from messages in the digest.

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.

6.20 My Mutt users cannot thread their digest messages.

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.

6.21 Posts fail: Message already has Mailing-List (#5.7.2).

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).

6.22 The last line of a DIR/text/ file is ignored.

Only complete lines ending with ``newline'' are copied. The last line in the DIR/text/ file most likely lacks a terminal ``newline''.

6.23 No CONFIRM requests are sent to moderators.

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

6.24 Deliveries fail ``temporary qmail-queue error''

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).

6.25 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.

6.26 Vacation program replies are treated as bounces by ezmlm

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.

6.27 Digests do not come at regular hours

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 < /dev/null

6.28 Preventing loops from misconfigured subscriber addresses.

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/blacklist/ with

        % ezmlm-sub DIR/blacklist badadr@badhost

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.

6.29 A user can subscribe and receives warning and probe messages, but no messages from the list.

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.