#pragma page-filename DOC/versions/4030723
== 4.78. Troubleshooting: No mail going out to lists members ==

See also

 * [[../../DOC/I've set up Mailman, created a list, and added myself to the list, but I don't get any messages!|I've set up Mailman, created a list, and added myself to the list, but I don't get any messages!]],
 * [[../../DOC/4.07 How can I rotate my Mailman logs?|4.07 How can I rotate my Mailman logs?]],
 * [[../../DOC/4.76 I can't access one of my lists via the web interface.  One of my lists is not sending mail. List locked.|4.76 I can't access one of my lists via the web interface.  One of my lists is not sending mail. List locked.]]

Here are some common things to check when no mail is going out from your lists.

Also, do you get no mail at all from Mailman or just no posts? If you get no posts but you do get some notifications, still check everything but focus more on items 2., 3., 4., 6., 7., 8. and if applicable 11.


I'm going to assume Sendmail as the MTA (its still the most commonly found - though postfix is gaining ground): Note however that the only MTA specific items in this FAQ are item 3 about aliases which doesn't apply to all MTA configurations; item 4 about smrsh which applies only to sendmail, and item 11 about mm-handler which applies only to that rarely used configuration.

 1. Check_perms. In all cases you should start by checking the permissions on the files that were setup: 
 {{{
~mailman/bin/check_perms
}}}
 1. Cron/mailmanctl.  
  1. Mailman 2.0.x only - Make sure that the cron daemon is running 
  {{{
ps aux |grep cron |grep -v grep
}}} This will print out the process information about the cron daemon. If it returns a blank line, then cron is NOT running. '''NOTE''': Mailman 2.0.13 and lower does not run an independent daemon. The qrunner process is run via cron.
  1. Mailman 2.1.x - Later versions of Mailman, versions 2.1 and above, need cron for certain support jobs, but not for normal mail delivery. In Mailman 2.1.x there is an independent daemon called mailmanctl. You need to make sure that the mailmanctl daemon is also running 
  {{{
ps auxww| grep mailmanctl |grep -v grep
}}} If this returns a blank line then the Mailman daemon is not running! Also, do 
  {{{
ps auxww | egrep 'p[y]thon'
}}} or 
  {{{
ps -fAww | egrep 'p[y]thon'
}}} or however you might spell it on your system. This should show that mailmanctl and eight qrunner processes are all running. See item 6. below.  
 1. Aliases. To create a mailman list you ran "newlist" and it printed out four (or ten) lines that you needed to copy to the /etc/aliases file (or wherever your MTA goes to find its aliases). Check that the aliases are in /etc/aliases: 
 {{{
grep wrapper /etc/aliases
}}} Note for version 2.1: "wrapper" has been replaced with "mailman", 
 {{{
grep mailman /etc/aliases
}}} Even if the aliases are there, you may still need to reset the aliases hash table so that it includes this new alias information: 
 {{{
newaliases
}}} Here is a typical alias listing for a group called "sys": 
 {{{
     ## Mailman verion 2.0.x system mailing list
     sys:           "|/home/mailman/mail/wrapper post sys"
     sys-admin:     "|/home/mailman/mail/wrapper mailowner sys"
     sys-request:   "|/home/mailman/mail/wrapper mailcmd sys"
     sys-owner:      sys-admin
}}} And here's a typical list of aliases for the 'mailman' list in mailman 2.1.x. 
 {{{
    ## mailman mailing list
    mailman:             "|/usr/local/mailman/mail/mailman post mailman"
    mailman-admin:       "|/usr/local/mailman/mail/mailman admin mailman"
    mailman-bounces:     "|/usr/local/mailman/mail/mailman bounces mailman"
    mailman-confirm:     "|/usr/local/mailman/mail/mailman confirm mailman"
    mailman-join:        "|/usr/local/mailman/mail/mailman join mailman"
    mailman-leave:       "|/usr/local/mailman/mail/mailman leave mailman"
    mailman-owner:       "|/usr/local/mailman/mail/mailman owner mailman"
    mailman-request:     "|/usr/local/mailman/mail/mailman request mailman"
    mailman-subscribe:   "|/usr/local/mailman/mail/mailman subscribe mailman"
    mailman-unsubscribe: "|/usr/local/mailman/mail/mailman unsubscribe mailman"
}}} If you are using Sendmail with virtual domains, you will have to also add entries into the into the 'virtusertable' to make the mapping for the virtual domain to the local aliases previously setup, similiar to the following: 
 {{{
     ## mailman virtual mappings
     sys@virtdomain.com                    sys
     sys-admin@virtdomain.com              sys-admin
     sys-request@virtdomain.com            sys-request
     sys-owner@virtdomain.com              sys-admin
}}} then run 'make' or 'makemap' to rebuild the virtusertable.db file and restart sendmail. This solution is limited in that you can not have multiple virtual domain with the same local address/list name. '''NOTE:''' in mailman version 2.1 and above you may have a secondary aliases file that is used specifically for Mailman and the lists that it creates: 
 {{{
~mailman/data/aliases
}}} You will need to make sure that this alias file isrecognized by your MTA (postfix, sendmail, etc), and that it is up-to-date with your latest aliases. If you do not have integration turned on, or you do not have this alias file, then all your aliases '''must''' go in the standard /etc/aliases file as specified above.
 1. Smrsh. Check to see if your MTA uses smrsh. Red Hat as well as a few other distributions automatically setup Sendmail to use smrsh. Smrsh stops Sendmail from running a script or other program that is included in an alias. Mailman uses a program called "wrapper" to run all of its aliases (see the alias examples above): 
 {{{
     grep "smrsh" sendmail.cf
}}} If this comes up blank then Sendmail does not use smrsh and the rest of this section doesn't apply - skip to 5.; if not, then your server is probably running smrsh and you need to make sure that smrsh is setup to allow Mailman's wrapper program to run. Locate the smrsh directory and do an ls -l of that directory. On Red Hat: 
 {{{
     ls -l /etc/smrsh
}}} and the output should be similar to: 
 {{{
     wrapper -> /home/mailman/mail/wrapper
}}} '''Note''': some systems setup the smrsh directory in: 
 {{{
     /usr/adm/sm.bin/
}}} '''Note''': to find the sm.bin directory try: 
 {{{
      strings /usr/lib/smrsh | grep sm.bin
}}} '''Note for version 2.1''': the wrapper program is now simply called "mailman", 
 {{{
      mailman -> /var/mailman/mail/mailman
}}}
 1. Interface. Some distributions in a noble "attempt" to limit the number of open relays on the internet, default Sendmail so that it listens to a limited number of interfaces. The default interface that Mailman list's use is "localhost" (127.0.0.1) - this is configurable in Mailman's mm_cfg.py file. To check Sendmail's configuration file: 
 {{{
     grep "Port" sendmail.cf
}}} This will list out the !DeamonPortOption and indicate the interfaces it listens on (0.0.0.0 would mean all interfaces). You can also check out which interfaces your MTA is listening on by using: 
 {{{
     netstat -na |grep ":25 "
}}} In a similar vein, some folks have reported that "localhost" is not defined in their /etc/hosts file (it should be set to 127.0.0.1). Also make sure /etc/hosts is world readable. Also see [[../../DOC/4.73 How do I debug smtp-failure problems - delivery to user-example.com failed with code -1- and Low level smtp error-|4.73 How do I debug smtp-failure problems - delivery to user-example.com failed with code -1- and Low level smtp error-]]. The settings in ~mailman/Mailman/mm_cfg.py (or Defaults.py) that are used to set these "Delivery Defaults": 
 {{{
     DELIVERY_MODULE = 'SMTPDirect'
     SMTPHOST = 'localhost'
     SMTPPORT = 0               # default from smtplib
}}} Also, ensure that connection to 'localhost' port 25 is not blocked by a firewall. From a shell on your Mailman server check if you can establish an smtp connection to localhost: 
 {{{
     $ telnet localhost 25
}}} If you get a timeout instead of the expected 220 greeting from your mail server you need to check if a firewall is running on that mailhost. Packets to localhost may be sent with an empty interface field. So a working "fire free for localhost" ruleset should always include 127.0.0.1: 
 {{{
     iptables -I INPUT -i lo        -j ACCEPT
     iptables -A INPUT -s 127.0.0.1 -j ACCEPT
}}}
 1. qrunner.  
  1. Mailman 2.0.x only - If you are running Mailman 2.0.x then qrunner is run every minute via a cron job (that is why cron '''must''' be running for Mailman to work). Try running the program by hand. The exact syntax can be found in Mailman's cron jobs: 
  {{{
     su mailman
     crontab -l
}}} Here is an example of running qrunner by hand: 
  {{{
     su mailman
     /usr/bin/python -S /home/mailman/cron/qrunner
}}} If this generates any errors then send those to the list for diagnosis - or look at the last few lines of errors and search the list for key words from the error messages.
  1. Mailman 2.1.x - If you are running Mailman 2.1.x then the qrunners are daemons that are started by $prefix/bin/mailmanctl, which itself may be being run via a 'mailman' startup script. This is described in the INSTALL document for the version of MM you are running. Note that there are eight qrunners. These runners and their functions are: 
  {{{
    ArchRunner       # messages for the archiver
    BounceRunner     # for processing of bounces
    CommandRunner    # commands and confirmations from the outside world
    IncomingRunner   # posts from the outside world
    NewsRunner       # outgoing messages to the nntpd
    OutgoingRunner   # outgoing messages to the smtpd
    VirginRunner     # internally crafted (virgin birth) messages
    RetryRunner      # retry temporarily failed deliveries
}}} If you aren't doing any gatewaying to usenet, you can do without !NewsRunner, and if you aren't archiving any lists, you can do without !ArchRunner, but the other six are required to be running for normal Mailman operation. Also note that if any queues are 'sliced' there will be more than one runner for that queue, and you need them all. For example, if !OutgoingRunner is set up for 4 slices, there will be four copies of !OutgoingRunner processing slices 0:4, 1:4, 2:4 and 3:4. If any of these four is not running, its portion of the out queue will not be processed.  
 1. Locks. A errant lock file can stop a list from processing as Mailman waits for the lock to be removed. Since your list is not sending, we shall assume that no lock files should be on the list and that it is safe to delete any we find. Note that we are talking here about locks with the list name as part of the lock file name. The master-qrunner locks are normal and are not the cause of non-delivery problems. On the contrary, if they weren't there it would indicate that the qrunners weren't running. 
 {{{
     ls -l ~mailman/locks
}}} The output will be something like: 
 {{{
qrunner.lock.server.example.com.22845
}}} This indicates that process # 22845 running on server.example.com created the lock. To look at this process and see what it is (if it still exists): 
 {{{
ps aux |grep 22845 |grep -v grep
}}} See [[../../DOC/4.76 I can't access one of my lists via the web interface.  One of my lists is not sending mail. List locked.|FAQ 4.76]] for more info on locks.
 1. Logs. If you don't have any of the common problems above, then you should look for errors in your log files. First look for errors in your MTA log files. On Red Hat that would be in /var/log/maillog. Look in the log starting at the time you sent a test message. You should see your initial message come in and be passed on to your Mailman list, afterwards you may see warnings or errors caused by Mailman trying to send out mail to the members of the list.<<BR>> Next look in Mailman's logs. The files are in ~mailman/logs/ or usually /var/log/mailman on !RedHat.<<BR>> There are several logs to look in for problems: 
 {{{
     error
     smtp-failure
     smtp
     vette
     locks
     post
     qrunner
}}} '''Note''': if you look in the qrunner log you may see several warnings about "Could not acquire qrunner lock", these are actually normal and are NOT a problem, but other messages about qrunners terminating and being restarted or not do indicate a problem.<<BR>> Every line in the log files is dated so you should be able to isolate the place in the log files to start looking, based on when your problem started.  
  * What do the logs and the times of the entries in your MTA show. Is it passing the mail into the mailman alias properly? Check the time.
  * Now check the Mailman post log and when it shows the message accepted for posting. The time should be very close to the MTA's time.
  * Now back to the MTA, does it show the message going out to the various folks on the list?  
 1. Qfiles. You may have a malformed email (or one that is simply too big) clogging up the flow of mail to your lists. Mail that is queued up by Mailman is stored in the directory: 
 {{{
~mailman/qfiles
}}} or in FHS compliant !RedHat systems 
 {{{
/var/spool/mailman
}}} Move any files out of the directory and into a temporary directory, then send a new test message to your list. If that works, then you can move some of the old queued up files back and let those process. If it stops working again then you have a bad message in that batch - delete them or copy them to a different temporary directory.<<BR>> Note that files accumulating in a queue directory can also mean that its qrunner (or one of its slice qrunners) is not running. See 1b and 5b above
 1. SMTPHOST. Mailman would accept messages but they wouldn't go anywhere. logs/smtp would just show "All recipients refused: (61, 'Connection refused')". My mailserver is configured to listen only on its external IP address, no localhost or anything like that. I had to add to ~mailman/Mailman/mm_cfg.py: 
 {{{
SMTPHOST = '<ip of my mailserver>'
}}} After that Mailman started working perfectly.
 1. Sendmail + mm-handler. If your mail is not getting to the mailing list then try testing mm-handler independently of sendmail: 
 {{{
echo "From: jbloggs@hotmail.com
 To: testlist@mailman.mydomain.com
 Subject: Test
 test mail body
 " | /etc/mail/mm-handler mailman.mydomain.com \
 -r jbloggs@hotmail.com testlist
}}} To test with sendmail without your email client try: 
 {{{
echo "From: jbloggs@hotmail.com
 To: testlist@mailman.mydomain.com
 Subject: Test
 test mail body
 " | /usr/sbin/sendmail -fjbloggs@hotmail.com \
 testlist@mailman.mydomain.com
}}} Also try editing mm-handler and setting DEBUG=1 and rerun the sendmail command above and see if you get a bounce.
 1. Topics. If your list has topics defined, make sure users have appropriate settings to receive the posts they want.
 1. Archives. If your list(s) have archives, do posts get archived? If so, the problem is almost certainly in outgoing mail delivery. Focus on !OutgoingRunner, qfiles/out, the 'error', 'smtp' and 'smtp-failure' logs and the logs of your MTA.

If none of the above steps helps, then try seeking out help on the mailman-users@python.org mailing list. When submitting your problem to the list please include the following information:

 * version of mailman you are running,
 * how it was installed (via rpm, apt-get, or source),
 * version of OS your server is running,
 * the MTA (sendmail, postfix, exim, qmail, etc) running on your server.

As a courtesy to the good folks on the list please use a Subject that describes your problem (and not simply the word "Help), and please join the list at http://mail.python.org/mailman/listinfo/mailman-users before posting as it is a members only list.

Please feel free to criticize and expand on this. I'm hoping that it proves useful as a starting point for folks having mail-flow problems. -Mark Sapiro

Converted from the Mailman FAQ Wizard

This is one of many [[../../DOC/Frequently Asked Questions|Frequently Asked Questions]].