Diagnosing Sendmail Problems

You may find yourself in a messy spot if you know there's a Sendmail problem but you can't figure out what it is. Since you need to know the problem before you can solve it, it's important to know how to diagnose Sendmail trouble. In this section, we show you two methods to do so.

Using Log Files to Diagnose Problems

Often the quickest and easiest way to diagnose a mail-related problem is to watch the Sendmail log file as you restart the service, test ports or passwords, or perform other functions that seem to be causing trouble for the MTA. Use the logs to monitor service start and stop errors, system errors in messages, and identify runtime errors. There are several ways to use logs to track Sendmail problems.

If you're having trouble with bad authentications (usernames and passwords) and you want to watch while a particular user logs in with the pop3 service (for example), then use the command

   # tail -f /var/log/messages | grep username

The output will show exactly what's happening, and only for the username that you're interested in:

   Dec 26 21:53:29 localhost pop(pam_unix)[7950]: authentication
   failure; logname= uid=0 euid=0 tty= ruser= rhost=127.0.0.1
   user=tweeks
   Dec 26 21:53:31 localhost ipop3d[7950]: Login failed user=tweeks
   auth=tweeks host=localhost.localdomain [127.0.0.1]
   Dec 26 21:53:36 localhost ipop3d[7950]: Logout user=tweeks
   host=localhost.localdomain  [127.0.0.1]

Very useful indeed! If you suspect a bad password, you can filter the output even further to check only for login failures:

   # tail -f /var/log/messages| grep 'Login failed'
   Dec 26 22:00:39 localhost ipop3d[7958]: Login failed
   user=tweeks auth=tweeks host=localhost.localdomain
   [127.0.0.1]

Now you know that the client has forgotten his mail password, or is using a misconfigured mail client-possibly one of the most common mail administration problems seen.

To watch for bounced mail, mail relaying, and other connection issues, watch the Sendmail log file /var/log/maillog, grepping for a specific username or string with the command

   # tail -f /var/log/maillog | grep bob2
   Mar 26 02:55:18 localhost sendmail[8651]: i2Q8tFiJ008651:
   to=bob2@fakebaddomain.com, ctladdr=tweeks (500/500),
   delay=00:00:03, xdelay=00:00:02, mailer=relay, pri=30055,
   relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent
   (i2Q8tG0d008653 Message accepted for delivery)
   Mar 26 02:55:18 localhost sendmail[8655]: i2Q8tG0d008653:
   to=<bob2@fakebaddomain.com>,
   ctladdr=<tweeks@localhost.localdomain> (500/500),
   delay=00:00:02, xdelay=00:00:00, mailer=esmtp, pri=30365,
   relay=fakebaddomain.com, dsn=5.1.2, stat=Host unknown (Name
   server:
   fakebaddomain.com: host not found)

Here we see that it could not find the domain name fakebaddomain.com: there lies your problem.

Tip

Always ask users with mail problems whether they've upgraded or changed their mail client or hardware lately. Most users let their mail clients remember the e-mail password; when new software is installed or new hardware is configured for them, they can't remember the password and blame the mail server or administrator for a problem. Though you'll probably need to change the client's password, you should explain the problem to the client (and to the client's manager, if you have that responsibility). Stored passwords defeat the purpose of password-protected e-mail accounts, and in some secure environments, client-side password storage may be actually against company security policy.

Diagnosing MTA Problems using Telnet

Take a cue from those who troubleshoot MTAs for a living. The most common way to identify and track remote SMTP mail server problems is actually with Telnet: not Telnet as in a shell or login to the server, but running Telnet to the SMTP port (port 25) on the mail server itself and attempting to send a message directly to the server using the SMTP protocol. The resulting output will show you exactly what happens when a message is delivered on your machine, and is a good way to diagnose server issues, rule out or prove user/client-side issues, or identify things such as problems with SMTP-Auth.

This command session shows you how:

# telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^ ]'.
220 playground.test.mydomain.com ESMTP Sendmail 8.11.6/8.11.6;
     Tue, 10 Sep 2002
14:11:41 -0500
ehlo mydomain.com <---------------Initial Handshake & Option Listing
250-playground.test.mydomain.com Hello localhost [127.0.0.1],
     pleased to meet you
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-SIZE
250-DSN
250-ONEX
250-ETRN
250-XUSR
250-AUTH LOGIN PLAIN   <------------------- Types of SMTP-Auth
250 HELP
mail from:tweeks@mydomain.com <------------Email "From"
250 2.1.0 tweeks@mydomain.com... Sender ok
rcpt to:tweeks@mydomain.com <------------- Email "To"
250 2.1.5 tweeks@mydomain.com... Recipient ok
data  <------------------------------------ Go into "data mode"
354 Enter mail, end with "." on a line by itself
SUBJECT: This is a test from Playground
This is a test..

Tweeks
.   <-------------------------------------- Terminating "."
250 2.0.0 g8AJBu004136 Message accepted for delivery
quit <------------------------------------
221 2.0.0 playground.test.mydomain.com closing connection
Connection closed by foreign host.

This is what an e-mail client or another mail server does every time it connects to your e-mail server on port 25 and sends an e-mail. You could actually send e-mail like this if you were in a pinch!