(redirected from Technical.Sendmail)
On this page… (hide)
Sendmail is the most popular Linux program for processing mail. Once the mail arrives on the mail server it can be read in a number of ways:
The process is different when sending mail via the mail server:
Configuring DNS
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 the Static DNS or Dynamic DNS pages on how to do this.
Most RedHat Linux software products are available in the RPM format. Downloading and installing `RPMs isn’t hard. If you need a refresher, the chapter on `RPMs covers how to do this in detail.
[root@bigboy tmp]# rpm -Uvh sendmail-cf-8.12.5-7 .i386.rpm [root@bigboy tmp]# rpm -Uvh sendmail-8.12.5-7 .i386.rpm [root@bigboy tmp]# rpm -Uvh sendmail-devel-8.12.5-7 .i386.rpm
[root@bigboy tmp]# chkconfig --level 35 sendmail on
[root@bigboy tmp]# /etc/init.d/sendmail start [root@bigboy tmp]# /etc/init.d/sendmail stop [root@bigboy tmp]# /etc/init.d/sendmail restart
[root@bigboy tmp]# pgrep sendmail
In this chapter we’ll see that Sendmail uses a variety of configuration files which require different treatments in order for their commands to take effect. This little script encapsulates all the required post configuration steps.
#!/bin/bash
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 described in the sections to follow.
The line in the script that restarts sendmail is only needed if you have made changes to the /etc/mail/sendmail.mc file, but it has been included so that you don’t forget. This may not be a good idea in a production system. Delete the appropriate "m4" line depending on your version of RedHat.
Both the newaliases and m4 commands depend on the sendmail-cf RPM package. This must be installed, if not, you'll get errors like this when running the script:
Sendmail throws all its status messages in the /var/log/maillog file. It is always good to 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
Most of sendmail's configuration parameters are set in this file with the exception of mailing list and mail relay security features. It is often viewed as an intimidating file 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.
The two most basic steps in configuring a Sendmail server are to modify this file to enable Sendmail to listen on the NIC interface and to make Sendmail to accept mail from valid web domains.
All Linux systems have a virtual loopback interface that only lives in memory with an IP address 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 to users on the local box. To become a server, and not a client, Sendmail needs to be also configured to listen for messages on the NIC interface.
We can verify that sendmail is running by first using the pgrep command which will return the sendmail process ID number once sendmail is running. If it isn't running, then the return value will be blank.
[root@bigboy tmp]# pgrep sendmail
We can also see the interfaces on which Sendmail is listening with the “netstat” command. Sendmail listens on TCP port 25, so we use "netstat" and "grep" for "25" to see a default configuration listening only on IP address 127.0.0.1 (loopback).
[root@bigboy tmp]# netstat -an | grep :25 | grep tcp
Edit /etc/mail/sendmail.mc To Make Sendmail Listen On NICs Too
To correct this you'll have to comment out the daemon_options line in the /etc/mail/sendmail.mc file with "dnl" statements. It is also good practice to take precautions against SPAM by not accepting mail from domains that don't exist by commenting out the "accept_unresolvable_domains" feature too. See the italicized lines in the example below.
dnl This changes sendmail to only listen on the loopback device 127.0.0.1
You need to be careful with the accept_unresolvable_names feature. In our sample network, bigboy the mail server will not accept email relayed from any of the other `PCs on your network if they are not in DNS. The chapter on DNS shows how to create your own internal domain just for this purpose.
Once finished editing the file, we have to regenerate a new sendmail.cf file and restart sendmail.
Redhat versions up to 7.3
[root@bigboy tmp]# m4 /etc/mail/sendmail.mc > /etc/sendmail.cf
Redhat versions 8.0+
[root@bigboy tmp]# m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
Sendmail should start listening on all interfaces (0.0.0.0)
[root@bigboy tmp]# netstat -an | grep :25 | grep tcp
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 this file will make post upgrade reconfiguration much easier. Here is a sample:
dnl ***** Customised section 1 start *****
The /etc/hosts File
It is very important to have a correctly configured /etc/hosts file. Here is a brief example:
127.0.0.1 localhost.localdomain localhost
Here the IP address is followed by the hostname.domain (bigboy.example.com) followed by the hostname and all the DNS `CNAMEs assigned to the server's IP address. Sendmail uses this file to determine:
Sendmail looks for the IP address of your NIC in /etc/hosts and then assumes the first name after it is the fully qualified domain name of the server such as bigboy.example.com. If bigboy had an entry like this:
192.168.1.100 example.com (Wrong!!!)
Sendmail would assume the server's name was example and that the domain was all of ".com". 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 we'll describe below.
If you fail to put the IP address of your NIC in the /etc/hosts file altogether, then you run the risk of having all your mail appear to come from localhost.localdomain and not bigboy.example.com.
As discussed above, 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.example.com.
Use the sendmail program to send a sample email to someone in verbose mode. Enter some text after issuing the command and end your message with a single "." all by itself on the last line.
[root@bigboy tmp]# sendmail -v example@example.com
LiteMail v3.02(BFLITEMAIL4A); Sat, 05 Oct 2002
06:48:44 -0400
>>> EHLO localhost.localdomain
250-mx.example.com 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@example.com>
250 <example@example.com>… Recipient Ok
>>> DATA
354 Enter mail, end with "." on a line by itself
>>> .
250 Message accepted for delivery
example@example.com… Sent (Message accepted for delivery)
Closing connection to mail.example.com.
>>> QUIT
[root@bigboy tmp]#
Localhost.localdomain is the domain that all computers use to refer to themselves, it is therefore an illegal internet domain. If mail sent from computer PC1 to PC2 appears to come from a user at localhost.localdomain on PC1 and is rejected, the rejected email will be returned to localhost.localdomain. PC2 will see that the mail originated from localhost.localdomain and will think that the rejected email should be sent to a user on PC2 that may not exist. You will probably get an error like this in /var/log/maillog if this happens:
Oct 16 10:20:04 bigboy sendmail[2500]: g9GHK3iQ002500: SYSERR(root):
Another set of tell tale errors caused by the same problem can be generated when trying to send mail to a user , in this example "root", or creating a new alias database file. (The newalias command will be explained later):
[root@bigboy tmp]# sendmail -v root
With the accompanying error in /var/log/maillog log file that looks like this:
Oct 16 10:23:58 bigboy sendmail[2582]: My unqualified host name (bigboy)
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 RedHat install. In this case, all mail sent from example.com and not destined for this mail server will be forwarded.
example.com
One disadvantage of this file is that it can only control mail based on the source domain which can be spoofed by SPAM email 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.
Sendmail has to be restarted after editing this file for the changes to take effect.
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 only relay mail for those `PCs on your network that have their email clients configured to use the mail server as their "outgoing SMTP mail server". (In Outlook Express you set this using: Tools Menu -> 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 email 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 / 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. Sendmail will REJECT all other attempted relayed mail that doesn't match any of the entries in the /etc/mail/access file. Despite this, my experience has been that control on a per email address basis is much more intuitive via the /etc/mail/virtusertable file.
In the sample file below, we allow 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 email through the mail server from servers belonging to example.com. Remember that a server will only be considered a part of example.com if its IP address can be found in a DNS reverse zone file:
localhost.localdomain 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 to do that:
[root@bigboy tmp]# cd /etc/mail
Remember that the relay security features of this file may not work if you don't have a correctly configured /etc/hosts 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 will accept responsibility. For example, if this mail server was to accept mail for the domains example.com and example.org and the host server.example.com then the file would look like this:
example.com
In this case, remember to modify the MX record of the "example.org" DNS zonefile point to example.com. Here is an example (Remember each "." is important):
example.org. MX 10 mail.example.com. ; Primary Mail Exchanger for example.org
Sendmail uses two different methods to determine who the ultimate mail recipient will be. It checks these methods in this order:
The /etc/mail/virtusertable file
This file has two columns.
The true destination in the eyes of the mail server could be a local Linux user, a mailing list entry in the /etc/aliases file or the email address of someone on some other mail server to which the mail should be automatically forwarded.
The /etc/aliases file
This file has two columns too. It could be viewed 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.
This file contains a set of simple instructions on what to do with received mail. The first column lists the target email address and the second column lists the local user’s mail box or remote email address to which the email should be forwarded.
In the example below; mail sent to:
webmaster@example.org webmasters @example.org marc sales@example.com sales@example.org paul@example.com paul finance@example.com paul @example.com error:nouser User unknown
After editing this file you'll have to convert it into a sendmail readable database file named /etc/mail/virtusertable.db. Here are the commands to do that:
[root@bigboy tmp]# cd /etc/mail
This file is really a list of email aliases for local users. It contains a list of virtual mail boxes (or mailing lists) in the first column, and members of the mailing lists in the second column. In the example below, you can see that mail sent to users "bin", "daemon", "lp", "shutdown", "apache", "named"… etc 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@example.com.
Basic system aliases -- these MUST be present.
mailer-daemon: postmaster
postmaster: root
General redirections for pseudo accounts.
bin: root
daemon: root
lp: root
shutdown: root
mail: root
apache: root
named: root
system: root
manager: root
abuse: root
trap decode to catch security attacks
decode: root
Person who should get root's mail
root: marc,webmaster@example.com
Notice that there are no spaces between the mailing list entries for “root”. This is important as you will get errors if you add spaces.
After editing this file you'll have to convert it into a sendmail readable database file named /etc/aliases.db. Here is the command to do that:
[root@bigboy tmp]# newaliases
In the simple mailing list example above, mail sent to "root" actually goes to user account "marc" and webmaster@example.com. Here are a few more list examples for your /etc/aliases file.
Mail to "directors@example.com" goes to users "peter", "paul" and "mary".
Directors of my SOHO company
directors: peter,paul,mary
Mail sent to "family@example.com" 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 /usr/home/admin/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 update the aliases file. Despite this, there are some problems with mail reflectors. One is that bounce messages from failed attempts to broadcast goes 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 like majordomo.
My mailing list file
admin-list: ":include:/home/mailings/admin-list"
After editing this file, you'll have to convert it into a sendmail readable database file named /etc/aliases.db. Here is the command to do that:
[root@bigboy tmp]# newaliases
By default your system uses sendmail to mail system messages to local user "root". When sendmail sends email to a local user, it will have no "to:" in the email header. If you then use a mail client like Outlook Express with a SPAM mail filtering rule to reject mail with no to: in the header, 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 will force sendmail to insert the correct fields in the header. Here is an example:
Person who should get root's mail
root: webmaster@example.com
If you want your mail to appear to come from user@example.com and not user@bigboy.example.com then you have two choices:
In the DNS configuration, we made bigboy the mailserver for the domain example.com. 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 example.com, if not, based on our settings in the /etc/hosts file, it will appear to come from mail.example.com. This isn't terrible, but you may not want your website site to be remembered with the word "mail" in front of it. In other words you may want your mail server to handle all email by assigning a consistent return address to all outgoing mail, no matter which server originated the email.
This can be solved by editing your sendmail.mc configuration file and adding some masquerading commands and directives. These are explained below:
FEATURE(always_add_domain)dnl
The email header is what email clients, such as Outlook Express, say the "to:" and "from:" should be. The "to:" and "from:" in the header is what is used when you use Outlook Express to do a "reply" or "reply all". It is easy to fake the header, as Spammers often do, it is detrimental to email delivery to fake the envelope.
The email envelope contains the "to:" and "from:" used by mailservers for protocol negotiation. It is the envelope's "from:" which is used when email rejection messages are sent between mail servers.
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 email received by test email accounts.
By default, user "root" will not be masqueraded. This is achieved with 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 recompiling / restarting sendmail
It is possible to limit the amount of unsolicited commercial email (UCE or SPAM) SPAM you receive by writing a small script to intercept your mail before it is written to your mailbox.
This is fairly simple to do as sendmail always checks the “.forward” file in your home directory for the name of this script. Sendmail then looks for the filename in the directory /etc/smrsh and executes it.
By default, PERL doesn’t come with modules that are able to check email headers and envelopes so you will have to download them from CPAN (www.cpan.org). The most important modules are:
I have written a script called mail-filter.pl that effectively filters out SPAM email for my home system. There are a few steps required to make the script work:
Mail-filter will first reject all email based on the "reject" file and will then accept all mail found in the "accept" file. It will then deny everything else.
I have included a simple script with instructions on how to install the PERL modules in the Appendix.
Sendmail will just handle mail sent to your "example.com" domain. Each user on your Linux box will get mail sent to their account's mail folder. If you want to retrieve this mail from your Linux box's user account, using a mail client such as Microsoft Outlook or Outlook Express, then you have a few more steps. You'll also have to make your Linux box a POP mail server.
Most RedHat Linux software products are available in the RPM format. Downloading and installing `RPMs isn’t hard. If you need a refresher, the chapter on `RPMs covers how to do this in detail.
[root@bigboy tmp]# rpm -Uvh imap-2001a-15.i386.rpm
[root@bigboy tmp]# chkconfig --level 35 xinetd on
[root@bigboy tmp]# /etc/init.d/xinetd start [root@bigboy tmp]# /etc/init.d/xinetd stop [root@bigboy tmp]# /etc/init.d/xinetd restart
Remember to restart the POP mail process every time you make a change to the configuration files for the changes to take effect on the running process
The starting and stopping of POP Mail is controlled by xinetd via the /etc/xinetd.d/ipop3 file. POP Mail is deactivated by default, so you’ll have to edit this file to start the program. Make sure the contents look like this. The disable feature must be set to "no" to accept connections.
Follow the steps below and set the "disable" parameter to "no".
[root@bigboy tmp]# cd /etc/xinetd.d
default: off description: The POP3 service allows remote users
to access their mail using an POP3 client such as Netscape Communicator, mutt, or fetchmail.
service pop3 {
socket_type = stream
You will then have to restart xinetd for these changes to take effect using the startup script in the /etc/init.d directory.
Naturally, to disable POP Mail once again, you’ll have to edit the /etc/xinetd.d/ipop3 file, set “disable” to “yes” and restart xinetd.
All your POP email accounts are really only regular Linux user accounts in which Sendmail has deposited mail. You can now configure your email client such as Outlook Express to use your use your new POP / SMTP Mail Server quite easily. Here’s how:
If you have a user overlap, eg. John Smith (john@example.com) and John Brown (john@example.org), by default, both users will get sent to the Linux user account "john". You have two choices:
users insist on overlapping names then you may need to modify your virtusertable file.
(:commentable:)
Copyright © 1997-2010 Benjamin C. Wilson · All Rights Reserved.