|
|
Though Sendmail servers can produce the same wide range of problems that any Unix server can generate, most daily Sendmail issues fall into just a few categories. Administrators spend a great deal of time resolving issues with client connections, passwords, with SMTP-Auth, with user mailboxes and POP3, and other such situations. In this section, you'll find some of the most common Sendmail troubleshooting problems and solutions.
If you're not receiving incoming e-mail or are seeing less than you think you should, Sendmail may be listening on the wrong IP address. You may also have bound SMTP to a single IP address, though you receive incoming traffic on multiple IPs.
As seen previously, to check the IP address that Sendmail is using, issue this command:
# netstat -antp| grep :25 tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 3780/sendmail: acce
The output should show the IP address defined by your settings in sendmail.mc and rebuilt sendmail.cf files. If you need to change the setting, use the process described in Turning on Public IP SMTP Bindings earlier in this chapter.
| Note |
An IP setting of 0.0.0.0:25 means that Sendmail listens for incoming SMTP traffic on all IP addresses associated with your system. Depending on your network configuration, this may be a security risk. 127.0.0.1:25 means that it is only listening to itself (web server CGI scripts, user programs, and so on). |
Sometimes Sendmail problems are simple in nature. If the server isn't running, you can't get mail. In other cases, Sendmail may have stopped running due to server load, as it is configured by default to stop accepting connections when server load reaches 8. Here's a simple test to check Sendmail's status:
# ps auxw| grep [a]ccepting root 670 0.0 0.8 5628 2072 ? S Aug08 0:00 sendmail: accepting connections
| Tip |
If you want to check the IP addresses that Sendmail is using at the same time, you can append the command above with ; netstat-ant | grep:25 to get additional information. |
Need to find out if a local or remote e-mail address accepts e-mail? This command will tell you whether a given e-mail address is deliverable (locally or remotely) and will use all the proper /etc/aliases and virtusertable mappings assigned to it. It's an excellent way to weed out local problems as you diagnose a user's e-mail problems.
# sendmail -bv root@mydomain.com root@mydomain.com... deliverable: mailer local, user bob
This shows that the root user is on the local system, and is aliased to the local user bob.
Although the queue contains a lot of useful information, it can be daunting to parse a lengthy queue yourself. Use this command to get a verbose parsing of the queue. It's particularly helpful when you have many e-mails queued due to DNS troubles or if you have persistent problems with third-party daemons rejecting your connections.
# mailq
/var/spool/mqueue (1 request)
----- Q-ID----- --Size-- -Priority- ---Q-Time--- -----Sender/Recipient------
i202a4hb003780 5243 1655192 Mar 23 20:36 MAILER-DAEMON
(Deferred: office100-235.sat.rackspace.com.: No route to host)
<root@office 100-235.sat.rackspace.com>
(Deferred: office100-235.sat.rackspace.com.: No route to host)
Total requests: 1This output shows a verbose listing of the mail queue and why it was queued. The following command will do the same, but also attempts to redeliver it:
# sendmail -v -q
This is a good command to run after you think that you've solved the problem.
| Tip |
Combine this command with tail-f var/log/maillog in another shell or window to monitor the mail log file and help figure out complex local delivery issues, such as those involving procmail or vacation mail processing systems. |
POP3 is the protocol by which users are able to hit a mail server, authenticate, and pull their mail down to their client PC. Users love POP3 because POP3-based mail clients are usually feature-rich and simple to use. However, POP3 problems may be client-based or server-based, and aren't always easy to diagnose. This section offers a basic troubleshooting process for POP3, and it explains what to check to ensure that your POP3 daemon will come back up when the server is rebooted. First, you should ensure that the POP3 service is actually running. If it's not, user mail clients will be unable to connect to the server and download waiting messages. Use these commands to determine whether the service is up:
$ telnet localhost 110 Trying 127.0.0.... telnet: connect to address 127.0.0.1: Connection refused $ $ netstat -ant | grep 110 $
The service doesn't seem to be running, so you need to turn it on:
# chkconfig --list| grep pop
ipop2: off
ipop3: off
pop3s: off
# chkconfig ipop3 on
# chkconfig --list| grep pop
ipop2: off
ipop3: on
pop3s: off
| Note |
Pop3 is currently one of the more popular mail retrieval protocols. However, if security is a concern, pop3s is better in that it runs over an encrypted SSL session. |
Once the POP3 service is on, you can repeat the first command to see whether POP3 is now functional:
$ telnet localhost 110 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. +OK POP3 localhost.localdomain v2003.83rh server ready user tweeks +OK User name accepted, password please pass mY1337p45swOrd +OK Mailbox open, 3 messages list +OK Mailbox scan listing follows 1 122243 2 122247 3 122251
Note that the ipop3 service on Red Hat based systems is a subservice of the xinetd daemon. The current running status of xinetd can be determined with the Red Hat based command
# service xinetd status xinetd (pid 3747) is running...
and the boot-time configuration with
# chkconfig --list xinetd xinetd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
Be sure that xinetd is running, and that it is configured to run on at least runlevels 3, 4, and 5. The output of the chkconfig -list xinetd command, when xinetd is properly configured, will look like this:
xinetd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
|
|