Configuring sendmail

Configuring sendmail

One of the tasks in setting up DNS for your domain (my-web-site.org) is to use the MX record in the configuration zone file to state the hostname of the server that will handle the mail for the domain. The most popular Unix mail transport agent is sendmail, but others, such as postfix and qmail, are also gaining popularity with Linux. The steps used to convert a Linux box into a sendmail mail server will be explained here.

How sendmail Works

As stated before, sendmail can handle both incoming and outgoing mail for your domain. Take a closer look.

Incoming Mail

Usually each user in your home has a regular Linux account on your mail server. Mail sent to each of these users (username@my-web-site.org) eventually arrives at your mail server and sendmail then processes it and deposits it in the mailbox file of the user's Linux account.

Mail isn't actually sent directly to the user's PC. Users retrieve their mail from the mail server using client software, such as Microsoft's Outlook or Outlook Express, that supports either the POP or IMAP mail retrieval protocols.

Linux users logged into the mail server can read their mail directly using a text-based client, such as mail, or a GUI client, such as Evolution. Linux workstation users can use the same programs to access their mail remotely.

Outgoing Mail

The process is different when sending mail via the mail server. PC and Linux workstation users configure their e-mail software to make the mail server their outbound SMTP mail server.

If the mail is destined for a local user in the mysite.com domain, then sendmail places the message in that person's mailbox so that they can retrieve it using one of the methods above.

If the mail is being sent to another domain, sendmail first uses DNS to get the MX record for the other domain. It then attempts to relay the mail to the appropriate destination mail server using the Simple Mail Transport Protocol (SMTP). One of the main advantages of mail relaying is that when a PC user A sends mail to user B on the Internet, the PC of user A can delegate the SMTP processing to the mail server.

sendmail Macros

When mail passes through a sendmail server the mail routing information in its header is analyzed, and sometimes modified, according to the desires of the systems administrator. Using a series of highly complicated regular expressions listed in the /etc/mail/sendmail.cf file, sendmail inspects this header and then acts accordingly.

In recognition of the complexity of the /etc/mail/sendmail.cf file, a much simpler file named /etc/sendmail.mc was created, and it contains more understandable instructions for systems administrators to use. These are then interpreted by a number of macro routines to create the sendmail.cf file. After editing sendmail.mc, you must always run the macros and restart sendmail for the changes to take effect.

Each sendmail.mc directive starts with a keyword, such as DOMAIN, FEATURE, or OSTYPE, followed by a subdirective and in some cases arguments. A typical example is:

     FEATURE(`virtusertable',`hash -o /etc/mail/virtusertable.db')dnl

The keywords usually define a subdirectory of /usr/share/sendmail-cf, in which the macro may be found and the subdirective is usually the name of the macro file itself. So in the example, the macro name is /usr/share/sendmail-cf/feature/virtusertable.m4, and the instruction `\ hash -o /etc/mail/virtusertable.db' is being passed to it.

Notice that sendmail is sensitive to the quotation marks used in the m4 macro directives. They open with a grave mark and end with a single quote:

     FEATURE(_`masquerade_envelope'_)dnl

Some keywords, such as define for the definition of certain sendmail variables and MASQUERADE_DOMAIN, have no corresponding directories with matching macro files. The macros in the /usr/share/sendmail-cf/m4 directory deal with these.

Once you finish editing the sendmail.mc file, you can then execute the make command while in the /etc/mail directory to regenerate the new sendmail.cf file.

     [root@bigboy tmp]# cd /etc/mail
     [root@bigboy mail]# make

If there have been no changes to the files in /etc/mail since the last time make was run, then you'll get an error like this:

     [root@bigboy mail]# make
     make: Nothing to be done for `all'.
     [root@bigboy mail]#

The make command actually generates the sendmail.cf file using the m4 command. The m4 usage is simple, you just specify the name of the macro file as the argument, in this case sendmail.mc, and redirect the output, which would normally go to the screen, to the sendmail.cf file with the > redirector symbol.

     # m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf

I'll discuss many of the features of the sendmail.mc file later in the chapter.

Installing sendmail

Most Red Hat and Fedora Linux software products are available in the RPM format. You will need to make sure that the sendmail, sendmail-cf, and m4 software RPMs are installed. (Chapter 6, "Installing RPM Software," will tell you how.) When searching for the RPMs, remember that the filename usually starts with the software package name by a version number, as in sendmail-8.12.10-1.1.1.i386.rpm.

Starting sendmail

You can use the chkconfig command to get sendmail configured to start at boot:

     [root@bigboy tmp]# chkconfig sendmail on

To start, stop, and restart sendmail after booting, use:

     [root@bigboy tmp]# service sendmail start
     [root@bigboy tmp]# service sendmail stop
     [root@bigboy tmp]# service sendmail restart

Remember to restart the sendmail process every time you make a change to the configuration files for the changes to take effect on the running process. You can also test whether the sendmail process is running with the pgrep command.

     [root@bigboy tmp]# pgrep sendmail

You should get a response of plain old process ID numbers.

How to Restart sendmail After Editing Your Configuration Files

In this chapter, you'll see that sendmail uses a variety of configuration files that require different treatments for their commands to take effect. This little script encapsulates all the required post configuration steps:

     #!/bin/bash
     cd /etc/mail
     make
     newaliases
     /etc/init.d/sendmail restart

It first runs the make command, which creates a new sendmail.cf file from the sendmail.mc file and compiles supporting configuration files in the /etc/mail directory according to the instructions in the file /etc/mail/Makefile.

It then generates new e-mail aliases with the newaliases command, (this will be covered later), and then restarts sendmail.

Use this command to make the script executable:

     chmod 700 filename

You'll need to run the script each time you change any of the sendmail configuration files.

The line in the script that restarts sendmail is only needed if you have made changes to the /etc/mail/sendmail.mc file, but I included it so that you don't forget. This may not be a good idea in a production system.

The /etc/mail/sendmail.mc File

As discussed earlier, you can define most of sendmail's configuration parameters in the /etc/mail/sendmail.mc file, which is then used by the m4 macros to create the /etc/mail/sendmail.cf file. Configuration of the sendmail.mc file is much simpler than configuration of sendmail.cf, but it is still often viewed as an intimidating task with its series of structured directive statements that get the job done. Fortunately, in most cases you won't have to edit this file very often.

How to Put Comments in sendmail.mc

In most Linux configuration files a # symbol is used at the beginning of a line to convert it into a comment line or to deactivate any commands that may reside on that line.

The sendmail.mc file doesn't use this character for commenting, but instead uses the string "dnl". Here are some valid examples of comments used with the sendmail.mc configuration file:

These statements are disabled by dnl commenting:

     dnl DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')
     dnl # DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')

This statement is incorrectly disabled:

     # DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')

This statement is active:

     DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')

Configuring DNS for sendmail

Remember that you will never receive mail unless you have configured DNS for your domain to make your new Linux box mail server the target of the DNS domain's MX record. See either Chapter 18, "Configuring DNS," or Chapter 19, "Dynamic DNS," for details on how to do this.

Configure Your Mail Server's Name In DNS

You first need to make sure that your mail server's name resolves in DNS correctly. For example, if your mail server's name is Bigboy and you intend for it to mostly handle mail for the domain my-web-site.org, then bigboy.my-web-site.org must correctly resolve to the IP address of one of the mail server's interfaces. You can test this using the host command:

     [root@smallfry tmp]# host bigboy.my-site.com
     bigboy.my-web-site.org has address 192.168.1.100
     [root@smallfry tmp]#

You will need to fix your DNS server's entries if the resolution isn't correct.

Configure the /etc/resolv.conf File

The sendmail program expects DNS to be configured correctly on the DNS server. The MX record for your domain must point to the IP address of the mail server.

The program also expects the files used by the mail server's DNS client to be configured correctly. The first one is the /etc/resolv.conf file in which there must be a domain directive that matches one of the domains the mail server is expected to handle mail for.

Finally, sendmail expects a nameserver directive that points to the IP address of the DNS server the mail server should use to get its DNS information.

For example, if the mail server is handling mail for my-web-site.org and the IP address of the DNS server is 192.168.1.100, there must be directives that look like this:

     domain my-web-site.org
     nameserver 192.168.1.100

An incorrectly configured resolv.conf file can lead to errors when running the m4 command to process the information in your sendmail.mc file:

     WARNING: local host name (smallfry) is not qualified; fix $j in config
     file

The /etc/hosts File

The /etc/hosts file also is used by DNS clients and also needs to be correctly configured. Here is a brief example of the first line you should expect to see in it:

     127.0.0.1 bigboy.my-web-site.org localhost.localdomain localhost
     bigboy

The entry for 127.0.0.1 must always be followed by the fully qualified domain name (FQDN) of the server. In the case above, it would be bigboy.my-web-site.org. Then you must have an entry for localhost and localhost.localdomain. Linux does not function properly if the 127.0.0.1 entry in /etc/hosts doesn't also include localhost and localhost.localdomain. Finally, you can add any other aliases your host may have to the end of the line.

How to Configure Linux sendmail Clients

All Linux mail clients in your home or company need to know which server is the mail server. This is configured in the sendmail.mc file by setting the SMART_HOST statement to include the mail server. In the example below, the mail server has been set to mail.my-web-site.org, the mail server for the my-web-site.org domain.

     define(`SMART_HOST',`mail.my-web-site.org')

If you don't have a mail server on your network, you can either create one or use the one offered by your ISP.

Once this is done, you need to process the sendmail.mc file and restart sendmail. To do this, run the restarting script from earlier in the chapter.

If the sendmail server is a Linux server, then the /etc/hosts file will also have to be correctly configured.

Converting From a Mail Client to a Mail Server

All Linux systems have a virtual loopback interface that lives only in memory with an IP address of 127.0.0.1. As mail must be sent to a target IP address even when there is no NIC in the box, sendmail therefore uses the loopback address to send mail between users on the same Linux server. To become a mail server, and not a mail client, sendmail needs to be configured to listen for messages on NIC interfaces, as well:

[root@bigboy tmp]# netstat -an | grep :25 | grep tcp
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN
[root@bigboy tmp]#

dnl
dnl This changes sendmail to only listen on the loopback
dnl device 127.0.0.1 and not on any other network
dnl devices. Comment this out if you want
dnl to accept email over the network.
dnl DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')
dnl
...
...
...
dnl
dnl We strongly recommend to comment this one out if you want
dnl to protect yourself from spam. However, the laptop and
dnl users on computers that do
dnl not have 24x7 DNS do need this.
dnl FEATURE(`accept_unresolvable_domains')dnl
dnl FEATURE(`relay_based_on_MX')dnl
dnl

dnl define(`SMART_HOST',`mail.my-web-site.org')

[root@bigboy tmp]# netstat -an | grep :25 | grep tcp
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN
[root@bigboy tmp]#

You have now completed the first phase of converting your Linux server into a sendmail server by enabling it to listen to SMTP traffic on its interfaces. The following sections will show you how to define what type of mail it should handle and the various ways this mail can be processed.

A General Guide to Using the sendmail.mc File

The sendmail.mc file can seem jumbled. To make it less cluttered, I usually create two easily identifiable sections in it with all the custom commands I've ever added.

The first section is near the top where the FEATURE statements usually are, and the second section is at the very bottom.

Sometimes sendmail will archive this file when you do a version upgrade. Having easily identifiable modifications in the file will make post upgrade reconfiguration much easier. Here is a sample:

     dnl ***** Customised section 1 start *****
     dnl
     dnl
     FEATURE(delay_checks)dnl
     FEATURE(masquerade_envelope)dnl
     FEATURE(allmasquerade)dnl
     FEATURE(masquerade_entire_domain)dnl
     dnl
     dnl
     dnl ***** Customised section 1 end *****

The /etc/mail/relay-domains File

The /etc/mail/relay-domains file is used to determine domains from which it will relay mail. The contents of the relay-domains file should be limited to those domains that can be trusted not to originate spam. By default, this file does not exist in a standard Red Hat/Fedora install. In this case, all mail sent from another-web-site.org and not destined for this mail server will be forwarded:

     another-web-site.org

One disadvantage of this file is that it controls mail based on the source domain only, and source domains can be spoofed by spam e-mail servers. The /etc/mail/access file has more capabilities, such as restricting relaying by IP address or network range and is more commonly used. If you delete /etc/mail/relay-domains, then relay access is fully determined by the /etc/mail/access file.

Be sure to run the restart sendmail script from the beginning of the chapter for these changes to take effect.

The /etc/mail/access File

You can make sure that only trusted PCs on your network have the ability to relay mail via your mail server by using the /etc/mail/access file. That is to say, the mail server will relay mail only for those PCs on your network that have their e-mail clients configured to use the mail server as their outgoing SMTP mail server. (In Outlook Express, you set this using: Tools>Accounts>Properties>Servers.)

If you don't take the precaution of using this feature, you may find your server being used to relay mail for spam e-mail sites. Configuring the /etc/mail/access file will not stop spam coming to you, only spam flowing through you.

The /etc/mail/access file has two columns. The first lists IP addresses and domains from which the mail is coming or going. The second lists the type of action to be taken when mail from these sources or destinations is received. Keywords include RELAY, REJECT, OK (not ACCEPT), and DISCARD. There is no third column to state whether the IP address or domain is the source or destination of the mail, sendmail assumes it could be either and tries to match both. All other attempted relayed mail that doesn't match any of the entries in the /etc/mail/access file, sendmail will reject. Despite this, my experience has been that control on a per e-mail address basis is much more intuitive via the /etc/mail/virtusertable file.

The sample file that follows allows relaying for only the server itself (127.0.0.1, localhost), two client PCs on your home 192.168.1.X network, everyone on your 192.168.2.X network, and everyone passing e-mail through the mail server from servers belonging to my-web-site.org. Remember that a server will be considered a part of my-web-site.org only if its IP address can be found in a DNS reverse zone file:

     localhost.localdomain           RELAY
     localhost                       RELAY
     127.0.0.1                       RELAY
     192.168.1.16                    RELAY
     192.168.1.17                    RELAY
     192.168.2                       RELAY
     my-web-site.org                 RELAY

You'll then have to convert this text file into a sendmail readable database file named /etc/mail/access.db. Here are the commands you need:

     [root@bigboy tmp]# cd /etc/mail
     [root@bigboy mail]# make

The sendmail restart script configured at the beginning of the chapter does this for you too.

Remember that the relay security features of this file may not work if you don't have a correctly configured /etc/hosts file.

The /etc/mail/local-host-names File

When sendmail receives mail, it needs a way of determining whether it is responsible for the mail it receives. It uses the /etc/mail/local-host-names file to do this. This file has a list of hostnames and domains for which sendmail accepts responsibility. For example, if this mail server was to accept mail for the domains my-web-site.org and another-site then the file would look like this:

     my-web-site.org
     another-web-site.org

In this case, remember to modify the MX record of the another-website.org DNS zone file to point to my-web-site.org. Here is an example. (Remember each is important.)

     ; Primary Mail Exchanger for another-web-site.org
     another-web-site.org. MX 10 mail.my-web-site.org.

Which User Should Really Receive the Mail?

After checking the contents of the virtusertable, sendmail checks the aliases files to determine the ultimate recipient of mail.

The /etc/mail/virtusertable file

The /etc/mail/virtusertable file contains a set of simple instructions on what to do with received mail. The first column lists the target e-mail address, and the second column lists the local user's mail box, a remote e-mail address, or a mailing list entry in the /etc/aliases file to which the e-mail should be forwarded.

If there is no match in the virtusertable file, sendmail checks for the full e-mail address in the /etc/aliases file:

     webmaster@another-web-site.org   webmasters
     @another-web-site.org            marc
     sales@my-web-site.org             sales@another-web-site.org
     paul@my-web-site.org              paul
     finance@my-web-site.org           paul
     @my-web-site.org                  error:nouser User unknown

In this example, mail sent to:

• webmaster@another-web-site.org goes to local user (or mailing list) webmasters, all other mail to another-web-site.org goes to local user marc

• sales at my-web-site.org goes to the sales department at my-othersite.com

• paul and finance at my-web-site.org goes to local user (or mailing list) paul

All other users at my-web-site.org receive a bounce back message stating "User unknown."

After editing the /etc/mail/virtusertable file, you have to convert it into a sendmail-readable database file named /etc/mail/virtusertable.db with two commands:

     [root@bigboy tmp]# cd /etc/mail
     [root@bigboy mail]# make

If these lines look like you've seen them before, you have: They're in your all-purpose sendmail restart script.

The /etc/aliases File

You can think of the /etc/aliases file as a mailing list file. The first column has the mailing list name (sometimes called a virtual mailbox), and the second column has the members of the mailing list separated by commas.

To start, sendmail searches the first column of the file for a match. If there is no match, then sendmail assumes the recipient is a regular user on the local server and deposits the mail in their mailbox.

If it finds a match in the first column, sendmail notes the nickname entry in the second column. It then searches for the nickname again in the first column to see if the recipient isn't on yet another mailing list.

If sendmail doesn't find a duplicate, it assumes the recipient is a regular user on the local server and deposits the mail in their mailbox.

If the recipient is a mailing list, then sendmail goes through the process all over again to determine if any of the members is on yet another list, and when it is all finished, they all get a copy of the e-mail message.

In the example that follows, you can see that mail sent to users bin, daemon, lp, shutdown, apache, named, and so on by system processes will all be sent to user (or mailing list) root. In this case, root is actually an alias for a mailing list consisting of user marc and webmaster@my-web-site.org.

      [root@bigboy tmp]# newaliases

     # Basic system aliases -- these MUST be present.
     mailer-daemon:        postmaster
     postmaster:           root

     # General redirections for pseudo accounts.
     bin:                  root
     daemon:               root
     ...
     ...
     abuse:                root

     # trap decode to catch security attacks
     decode:               root

     # Person who should get root's mail
     root:                  marc,webmaster@my-web-site.org

Notice that there are no spaces between the mailing list entries for root: You will get errors if you add spaces.

In this simple mailing list example, mail sent to root actually goes to user account marc and webmaster@my-web-site.org. Because aliases can be very useful, here are a few more list examples for your /etc/aliases file.

• Mail to directors@my-web-site.org goes to users peter, paul, and mary:

  # Directors of my SOHO company
  directors:      peter,paul,mary
  

  
  

• Mail sent to family@my-web-site.org goes to users grandma, brother, and sister:

  # My family
  family:        grandma,brother,sister
  

  
  

• Mail sent to admin-list gets sent to all the users listed in the file /home/mailings/admin-list.

  # My mailing list file
  admin-list:     ":include:/home/mailings/admin-list"
  

  
  

The advantage of using mailing list files is that the admin-list file can be a file that trusted users can edit, user root is only needed to update the aliases file. Despite this, there are some problems with mail reflectors. One is that bounce messages from failed attempts to broadcast go to all users. Another is that all subscriptions and unsubscriptions have to be done manually by the mailing list administrator. If either of these are a problem for you, then consider using a mailing list manager, such as majordomo.

One important note about the /etc/aliases file: By default your system uses sendmail to mail system messages to local user root. When sendmail sends e-mail to a local user, the mail has no To: in the e-mail header. If you then use a mail client with a spam mail filtering rule to reject mail with no To: in the header, such as Outlook Express or Evolution, you may find yourself dumping legitimate mail.

To get around this, try making root have an alias for a user with a fully qualified domain name, this forces sendmail to insert the correct fields in the header; for example:

     # Person who should get root's mail
     root:                 webmaster@my-web-site.org

sendmail Masquerading Explained

If you want your mail to appear to come from user@mysite.com and not user@bigboy.mysite.com, then you have two choices:

• Configure your e-mail client, such as Outlook Express, to set your e-mail address to user@mysite.com. (I'll explain this in the "Configuring Your POP Mail Server" section.)

• Set up masquerading to modify the domain name of all traffic originating from and passing trough your mail server.

Configuring Masquerading

In the DNS configuration, you made Bigboy the mail server for the domain my-web-site.org. You now have to tell Bigboy in the sendmail configuration file sendmail.mc that all outgoing mail originating on Bigboy should appear to be coming from my-web-site.org; if not, based on the settings in the /etc/hosts file, mail will appear to come from mail.my-web-site.org. This isn't terrible, but you may not want your Web site to be remembered with the word "mail" in front of it. In other words, you may want your mail server to handle all e-mail by assigning a consistent return address to all outgoing mail, no matter which server originated the e-mail.

You can solve this by editing your sendmail.mc configuration file and adding some masquerading commands and directives:

     FEATURE(always_add_domain)dnl
     FEATURE(`masquerade_entire_domain')dnl
     FEATURE(`masquerade_envelope')dnl
     FEATURE(`allmasquerade')dnl
     MASQUERADE_AS(`my-web-site.org')dnl
     MASQUERADE_DOMAIN(`my-web-site.org.')dnl
     MASQUERADE_DOMAIN(localhost)dnl
     MASQUERADE_DOMAIN(localhost.localdomain)dnl

The result is that:

• The MASQUERADE_AS directive makes all mail originating on Bigboy appear to come from a server within the domain my-web-site.org by rewriting the e-mail header.

• The MASQUERADE_DOMAIN directive makes mail relayed via Bigboy from all machines in the another-web-site.org and localdomain domains appear to come from the MASQUERADE_AS domain of my-web-site.org. Using DNS, sendmail checks the domain name associated with the IP address of the mail relay client sending the mail to help it determine whether it should do masquerading or not.

• FEATURE masquerade_entire_domain makes sendmail masquerade servers named *my-web-site.org and *another-web-site.org as my-web-site.org. In other words, mail from sales.my-web-site.org would be masqueraded as my-web-site.org. If this wasn't selected, then only servers named my-web-site.org and my-othersite.com would be masqueraded. Use this with caution when you are sure you have the necessary authority.

• FEATURE allmasquerade makes sendmail rewrite both recipient addresses and sender addresses relative to the local machine. If you cc: yourself on an outgoing mail, the other recipient sees a cc: to an address he knows instead of one on localhost.localdomain.

  Note Use FEATURE allmasquerade with caution if your mail server handles e-mail for many different domains and the mailboxes for the users in these domains reside on the mail server. The allmasquerade statement causes all mail destined for these mailboxes to appear to be destined for users in the domain defined in the MASQUERADE_AS statement. In other words, if MASQUERADE_AS is my-web-site.org and you use allmasquerade, then mail for peter@another-web-site.org enters the correct mailbox but sendmail rewrites the To:, making the e-mail appear to be sent to peter@myste.com originally.

  
  

• FEATURE always_add_domain always masquerades e-mail addresses, even if the mail is sent from a user on the mail server to another user on the same mail server.

• FEATURE masquerade_envelope rewrites the e-mail envelope just as MASQUERADE_AS rewrote the header.

Masquerading is an important part of any mail server configuration as it enables systems administrators to use multiple outbound mail servers, each providing only the global domain name for a company and not the fully qualified domain name of the server itself. All e-mail correspondence then has a uniform e-mail address format that complies with the company's brand marketing policies.

Testing Masquerading

The best way of testing masquerading from the Linux command line is to use the mail -v username command. I have noticed that sendmail -v username ignores masquerading altogether. You should also tail the /var/log/maillog file to verify that the masquerading is operating correctly and check the envelope and header of test e-mail received by test e-mail accounts.

Other Masquerading Notes

By default, user root will not be masqueraded. To remove this restriction use the

     EXPOSED_USER(`root')dnl

command in /etc/mail/sendmail.mc. You can comment this out if you like with a "dnl" at the beginning of the line and running the sendmail start script.

Using sendmail to Change the Sender's E-mail Address

Sometimes masquerading isn't enough. At times you may need to change not only the domain of the sender but also the username portion of the sender's e-mail address. For example, perhaps you bought a program for your SOHO office that sends out notifications to your staff, but the program inserts its own address as sender's address, not that of the IT person.

Web-based CGI scripts tend to run as user apache and, therefore, send mail as user apache too. Often you won't want this, not only because apache's e-mail address may not be suitable, but also because some anti-spam programs check to ensure that the From:, or source e-mail address, actually exists as a real user. If your virtusertable file allows e-mail to only predefined users, then queries about the apache user will fail, and your valid e-mail may be classified as being spam.

With sendmail, you can change both the domain and username on a case-by-case basis using the genericstable feature:

FEATURE(`genericstable',`hash -o
/etc/mail/genericstable.db')dnl
GENERICS_DOMAIN_FILE(`/etc/mail/generics-domains')dnl

sendmail -bt -d0.1 </dev/null

my-web-site.org
another-web-site.org
bigboy.my-web-site.org

linux-username username@new-domain.com

alert          security-alert@my-web-site.org
peter          urgent-message@my-web-site.org
apache         mailer@my-web-site.org

Your e-mails from linux-username should now appear to come from username@new-domain.com.

Troubleshooting sendmail

When sendmail doesn't appear to work correctly, you can test it in a number of ways. Here are a few tests and techniques you can use to fix some of the most common problems.

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

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

[root@bigboy tmp]# telnet mail.my-web-site.org 25
Trying mail.my-web-site.org...
Connected to mail.my-web-site.org.
Escape character is '^]'.
220 mail.my-web-site.org ESMTP server ready

hello another-web-site.org
250 mail.my-web-site.org Hello c-24-4-97-
110.client.comcast.net [24.4.97.110], pleased to meet you.

MAIL FROM:sender@another-web-site.org
250 2.1.0 sender@another-web-site.org... Sender ok

RCPT TO: user@my-web-site.org
250 2.1.5 user@my-web-site.org... Recipient ok

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

Subject: Test Message
Testing sendmail interactively
.

250 2.0.0 iA75r9si017840 Message accepted for delivery

QUIT
221 2.0.0 mail.my-web-site.org 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

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]#
  

  
  

• Sample errors when processing the sendmail.mc file

  [root@bigboy mail]# m4 /etc/mail/sendmail.mc > /etc/mail/send-
  mail.cf
  /etc/mail/sendmail.mc:8: 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
  [FAILED]
  Starting sm-client: [ OK ]
  [root@bigboy mail]#
  

  
  

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

Incorrectly Configured /etc/hosts Files

By default, Fedora inserts the host name of the server between the 127.0.0.1 and the localhost entries in /etc/hosts:

127.0.0.1     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 127.0.0.1 entry. Here sendmail thinks that the server's FDQN was my-site and that the domain was all of.com:

127.0.0.1   my-web-site.org  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 bigboy.my-web-site.org.

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 example@another-web-site.org
     test text
     test text
     .
     example@another-web-site.org... Connecting to mail.another-web-
     site.org. via esmtp...
     220 ltmail.another-web-site.org LiteMail v3.02(BFLITEMAIL4A); Sat, 05
     Oct 2002 06:48:44 -0400
     >>> EHLO localhost.localdomain
     250-mx.another-web-site.org Hello [67.120.221.106], pleased to meet
     you
     250 HELP
     >>> MAIL From:<root@localhost.localdomain>
     250 <root@localhost.localdomain>... Sender Ok
     >>> RCPT To:<example@another-web-site.org>
     250 <example@another-web-site.org>... Recipient Ok
     >>> DATA
     354 Enter mail, end with "." on a line by itself
     >>> .
     250 Message accepted for delivery
     example@another-web-site.org... Sent (Message accepted for delivery)
     Closing connection to mail.another-web-site.org.
     >>> 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 telltale 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