Debian iTOps Tube

Tuesday, November 22, 2011

Troubleshooting Sendmail

Troubleshooting Sendmail

There are a number of ways to test sendmail when it doesn't appear to work correctly. Here are a few methods you can use to fix some of the most common problems.

Testing TCP connectivity

The very first step is to determine whether your mail server is accessible on the sendmail SMTP TCP port 25. Lack of connectivity could be caused by a firewall with incorrect permit, NAT, or port forwarding rules to your mail server. Failure could also be caused by the sendmail process being stopped. It is best to test this from both inside your network and from the Internet.

Chapter 4, "Simple Network Troubleshooting", covers troubleshooting with TELNET.

Further Testing of TCP connectivity

You can also mimic a full mail session using TELNET to make sure everything is working correctly. If you get a "500 Command not recognized" error message along the way, the cause is probably a typographical error. Follow these steps carefully.

1) Telnet to the mail server on port 25. You should get a response with a 220 status code.

[root@bigboy tmp]# telnet 25
Connected to
Escape character is '^]'.
220 ESMTP server ready

If this basic step fails, you probably have a connection problem that could be the result of typical network issues outlined in Chapter 4, "Simple Network Troubleshooting". Review this chapter if you find yourself having problems related to basic connectivity.

2) Use the hello command to tell the mail server the domain you belong to. You should receive a message with a successful status 250 code at the beginning of the response.

250 Hello [], pleased to meet you.

3) Inform the mail server from which the test message is coming with the MAIL FROM: statement.

250 2.1.0 Sender ok

4) Tell the mail server to whom the test message is going with the " RCPT TO:" statement.

250 2.1.5 Recipient ok

5) Prepare the mail server to receive data with the DATA statement

354 Enter mail, end with "." on a line by itself

6) Type the string "subject:" then type a subject. Type in your text message, ending it with a single period on the last line. For example.

Subject: Test Message
Testing sendmail interactively
250 2.0.0 iA75r9si017840 Message accepted for delivery

7) Use the QUIT command to end the session.

221 2.0.0 closing connection
Connection closed by foreign host.
[root@bigboy tmp]#

Now verify that the intended recipient received the message, and check the system logs for any mail application errors.

The /var/log/maillog File

Because sendmail writes all its status messages in the /var/log/maillog file, always monitor this file whenever you are doing changes. Open two TELNET, SSH, or console windows. Work in one of them and monitor the sendmail status output in the other using the command

[root@bigboy tmp]# tail -f /var/log/maillog

This tactic will make it much easier to troubleshoot any issues you may find in sendmail.

Common Errors Due To Incomplete RPM Installation

Both the newaliases and m4 commands require the sendmail-cf and m4 RPM packages. These must be installed. If they are not, you'll get errors when running various sendmail related commands.

  • Sample Errors when running newaliases

[root@bigboy mail]# newaliases
Warning: .cf file is out of date: sendmail 8.12.5 supports version 10, .cf file is version 0
No local mailer defined
QueueDirectory (Q) option must be set
[root@bigboy mail]#

[root@bigboy mail]# m4 /etc/mail/ > /etc/mail/
/etc/mail/ m4: Cannot open /usr/share/sendmail-cf/m4/cf.m4: No such file or directory
[root@bigboy mail]#

  • Sample errors when restarting sendmail

[root@bigboy mail]# service sendmail restart
Shutting down sendmail: [ OK ]
Shutting down sm-client: [FAILED]
Starting sendmail: 554 5.0.0 No local mailer defined
554 5.0.0 QueueDirectory (Q) option must be set
Starting sm-client: [ OK ]
[root@bigboy mail]#

If these errors occur, make sure your m4, sendmail and senmail-cf RPM packages are installed correctly.

Incorrectly Configured /etc/hosts Files

By default, Fedora inserts the hostname of the server between the and the localhost entries in /etc/hosts like this: bigboy localhost.localdomain localhost

Unfortunately in this configuration, sendmail will think that the server's FQDN is bigboy, which it will identify as being invalid because there is no extension at the end, such as .com or .net. It will then default to sending e-mails in which the domain is localhost.localdomain.

The /etc/hosts file is also important for configuring mail relay. You can create problems if you fail to place the server name in the FDQN for entry. Here sendmail thinks that the server's FDQN was my-site and that the domain was all of .com. localhost.localdomain localhost # (Wrong!!!)

The server would therefore be open to relay all mail from any .com domain and would ignore the security features of the access and relay-domains files I'll describe later.

As mentioned, a poorly configured /etc/hosts file can make mail sent from your server to the outside world appear as if it came from users at localhost.localdomain and not

Use the sendmail program to send a sample e-mail to someone in verbose mode. Enter some text after issuing the command and end your message with a single period all by itself on the last line, for example:

[root@bigboy tmp]# sendmail -v
test text
test text
. Connecting to via esmtp... 
220 LiteMail v3.02(BFLITEMAIL4A); Sat, 05 Oct 2002 06:48:44 -0400
>>> EHLO localhost.localdomain Hello [], pleased to meet you
250 HELP
>>> MAIL From:<root@localhost.localdomain>
250 <root@localhost.localdomain>... Sender Ok
250 <>... Recipient Ok
>>> DATA
354 Enter mail, end with "." on a line by itself
>>> .
250 Message accepted for delivery Sent (Message accepted for delivery)
Closing connection to
>>> QUIT
[root@bigboy tmp]#

localhost.localdomain is the domain that all computers use to refer to themselves, it is therefore an illegal Internet domain. Consider an example: Mail sent from computer PC1 to PC2 appears to come from a user at localhost.localdomain on PC1 and is rejected. The rejected e-mail is returned to localhost.localdomain. PC2 sees that the mail originated from localhost.localdomain and thinks that the rejected e-mail should be sent to a user on PC2 that may not exist. You end up with an error in /var/log/maillog:

Oct 16 10:20:04 bigboy sendmail[2500]: g9GHK3iQ002500: SYSERR(root): savemail: cannot save rejected email anywhere
Oct 16 10:20:04 bigboy sendmail[2500]: g9GHK3iQ002500: Losing ./qfg9GHK3iQ002500: savemail panic

You may also get this error if you are using a spam prevention program, such as a script based on the PERL module Mail::Audit. An error in the script could cause this type of message too.

Another set of tell tale errors caused by the same problem can be generated when trying to send mail to a user (the example uses root) or creating a new alias database file. (I'll explain the newaliases command later.)

[root@bigboy tmp]# sendmail -v  root
WARNING: local host name (bigboy) is not qualified; fix $j in config file
[root@bigboy tmp]# newaliases
WARNING: local host name (bigboy) is not qualified; fix $j in config file
[root@bigboy tmp]#

An accompanying error in /var/log/maillog log file looks like this:

Oct 16 10:23:58 bigboy sendmail[2582]: My unqualified host name (bigboy) unknown; sleeping for retry

When you have got sendmail finally working it will be time to focus your attention on fighting unwanted email, or SPAM. This will be covered next.

No comments:

Post a Comment