Next Previous Contents

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:

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 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 or If you're unsure where the bug is, you can start with 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, ideally with a context diff. For ezmlm proper, may be better.

6.4 Using ezmlm-test to check the ezmlm(-idx) programs.

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

6.5 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'
where ``DIR'' is the list directory, as the first line in DIR/editor (for mail to list), DIR/manager (for mail to 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.

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


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

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.

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-*
If you want to save some files (such as in DIR/text/), make backup copies first, run ezmlm-make, then copy the backups to DIR/text/. Of course, it is usually easier to create a custom .ezmlmrc, 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. 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.

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

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.

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

Most error conditions, incorrect request cookies, etc, should result in informative error messages in the mail log.

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

> %%%
> comment2
> %%%
but not:
and not:
%%% this is my comment %%%
ezmlm said>%%%
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 Some Received: headers are missing from messages.

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.

6.21 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.22 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.23 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.24 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
If this fails the list is not subscription moderated. If it succeeds with a directory name with a leading ``/'', this is your ``moddir''. If not:
% cat DIR/remote
If this succeeds with a directory name with a leading ``/'', this is your moddir, otherwise the moddir is ``DIR/mod/''.

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.

6.25 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.26 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.27 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.28 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

6.29 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/deny/ 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 administration (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 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.30 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.

Next Previous Contents