لطفا منتظر باشید ...
Basic Sendmail
Configuration
In 2002, Sendmail was the most popular MTA in
the world, according to surveys of MTA use. It's also the MTA that's the
default with most Linux distributions, including Caldera, Red Hat, Slackware,
SuSE, and TurboLinux. Debian and Mandrake, although they install other SMTP
servers by default, also provide the option of using sendmail. As I write,
version 8.12.2 is the latest, but some Linux distributions still ship with
older versions of 8.11.x or earlier.Sendmail uses a fairly obtuse configuration
file format, but utilities exist to configure the software by compiling a
simpler file format into the one that sendmail actually reads. Knowing how to
do this is critical to configuring sendmail. In addition to the configuration
files themselves, this section covers a few specific areas of sendmail
configuration: address masquerading, accepting incoming mail, and relay
configuration.
Sendmail's Configuration Files
Sendmail's primary configuration file is
called sendmail.cf , and it's usually located in /etc . This file is
difficult to edit directly, though, because there are many options, they use
very non-mnemonic names, and they're formatted in a way that's difficult to
read.To work around the difficulties inherent in
directly editing sendmail.cf , most distributions use the m4 macro processing
utility to create the sendmail.cf file from a simpler and more easily understood file. The m4 source file
usually has a filename that ends in .mc , but the exact name
varies from one distribution to another. For instance, in Red Hat it's /etc/sendmail.mc , in Slackware it's /usr/src/sendmail/cf/cf/linux.smtp.mc , and
in SuSE it's /etc/mail/linux.mc . No matter the name, the m4 source files are much
shorter and more readable than the .cf files they create. For
instance, in SuSE 7.1, the sendmail.cf file is 1669 lines long, whereas the linux.mc file that
creates it is only 221 lines longand most of those lines are comments (lines
that begin with dnl ). A working sendmail m4 file can be less than 50 lines long.To create a sendmail.cf file from an m4 file, you
must run the m4 command, using input redirection to feed it the m4 configuration file and using output redirection to send the output to a file. For
instance, you might use the following command on SuSE Linux: # m4 < /etc/mail/linux.mc > /etc/sendmail.cf
NOTE
align=left border=0> Some distributions require you to install a
separate package of support files before you can build your m4 source
files into a working sendmail.cf file. For instance, Red Hat needs the sendmail-cf package before you can rebuild a sendmail configuration file.
WARNING
align=left border=0> Be sure not to overwrite a working sendmail.cf file. It's generally best to back up this file, and your original m4 source
file, to a location in another directory. This way if something goes wrong
and you can't seem to get sendmail working again, you can restore the
original files.
You'll have to restart sendmail after you
rebuild its configuration file in order to see your changes take effect. Most
distributions start sendmail through SysV scripts, so you should restart
sendmail via the script's restart option.Most options in an m4 configuration file take the following form: FEATURE-NAME( ` option1'[, ` option2'[,...])
The FEATURE-NAME is a
name that's at least somewhat descriptive, such as define or MASQUERADE_AS .
The options ( option1 , option2 , and so on) may be hostnames, sendmail-specific option names such
as always_add_domain , and so on. Some feature definitions can omit the single quote
marks, but most use them.WARNING
align=left border=0> When present, the single quote marks
surrounding the options are unusual because they're dissimilar. The opening
quote in any given option is a backquote character ( ` ), which is
located on the key to the left of the 1 key on most
keyboards. The ending quote is a regular single quote character, which is
located on the key to the right of the semicolon ( ; ) key on
most keyboards. If you use two regular single quote characters, as you would
in most configuration files, either m4 won't be able to
process the file or the sendmail configuration file will not work as expected.
In addition to the sendmail.cf file and the m4 file that creates it, sendmail relies on additional files. A couple
of the more important of these include the following: access.db This file is a binary file that's derived from the plain-text access file. This
file controls what computers may access sendmail in what ways. Sendmail relay
configurations, described shortly, often depend upon this file's contents. Most
sendmail startup scripts run makemap to automatically generate access.db if access has changed
since the last time access.db was built. aliases.db This is another binary file derived from a text file with a
similar name ( aliases ). It defines mail aliasesthat is, names that are to be considered
equivalent to one another. For instance, most distributions set up postmaster as
an alias for root , and you may want to set up an alias for root to direct
root 's mail to your ordinary user account. As with access.db ,
many sendmail startup scripts automatically generate aliases.db from aliases .You'll probably find these files in /etc or /etc/mail ,
along with other database files that control other details of sendmail's
operation. These files are referenced by the m4 file, and by sendmail.cf .
Sendmail Address Masquerading
If you want your SMTP server to announce
itself under a name other than its regular hostname, you must configure
sendmail to perform some form of address masquerading, as described earlier. There
are two lines you can set in your m4 configuration file to activate two
different facets of address masquerading: MASQUERADE_AS(` desired-address ') FEATURE(masquerade_envelope)
The MASQUERADE_AS feature
enables the most basic level of masquerading, which only changes the address
used in the mail header's From: field if the user's mail program doesn't specify a hostname. Because
many mail programs set this field, this option is most useful as a fallback in
case a user's mail program isn't completely or correctly configured. The FEATURE (masquerade_envelope) line does more, because it actively changes the From: header
even if the sender's mail program set this option.If you want your masquerading to apply only
to mail from certain domains' users, you can use a couple of additional lines
to limit the application of these masquerading features: MASQUERADE_DOMAIN(` source-domain ') FEATURE(`limited_masquerade')
These options tell sendmail to limit its
masquerading to addresses within the specified source-domain . Such a
configuration is most likely to be helpful if your system functions as a mail
server for two domains; you can set it to masquerade as a system within the
appropriate domain for each message it sends.
Configuring Sendmail to Accept Mail
When a remote server sends mail to your
system, the mail is addressed to a specific user on a specific computer. In
order to accept delivery of local mail, sendmail must be able to recognize all
the local addresses, as described earlier. Sendmail allows you to add all the
names for the mail server to a local hostnames file, including the raw domain
name if you've configured an MX record for it. This file has different names in
different distributions, and these names are set in files loaded with the
sendmail m4 package. In Red Hat, it's /etc/mail/local-host-names ; in SuSE, it's /etc/sendmail.cw . If you can't find the file, try searching for a line in sendmail.cf that begins Fw . This line sets the name of the local hostnames file. Whatever its
name, this file consists of a series of lines, each of which contains a hostname
that the computer will consider to be local. Sendmail ignores lines that begin
with a pound sign ( # ), though. You can omit the computer's regular hostname, although
including it will do no harm.
Sendmail Relay Configuration
As described earlier, relay configurations
are extremely important in setting up a mail server. You must be able to
configure sendmail to relay its own mail, possibly mail from the local network,
and perhaps even mail from remote networks, as appropriate, without opening up
the system as one that might be abused by spammers. In addition, you may want
or need to configure the system to send its outgoing mail through another
system as a relay. Fortunately, sendmail offers many mail relay options.
Configuring Sendmail to Relay Mail
One common mail relay configuration is to
have a mail server forward mail for a local network. The idea is to use a mail
server to relay mail, storing it temporarily in the event of network problems. You
then point other local systems' mail programs to the mail server.Out of the box, most sendmail installations
will not work as mail relays. If you try it, the mail server refuses to relay
the message. Most mail clients inform you that they've received a
"relaying denied" response from the mail server. Sendmail allows you
to activate several different relay options if you want it to function as a
relay. You can include any of the following options in a FEATURE line: relay_entire_domain When this option is used, sendmail accepts relay mail that
originates from within its own domain, or that's addressed to any system within
its local domain. Sendmail uses DNS to verify the sender's domain based upon
the IP address. This can be a quick and convenient way to enable relaying. relay_local_from This option tells sendmail to accept relays of any message that
uses a From: address within sendmail's local domain. This differs from the
preceding option in that this one uses only the claimed
address in the From: header, which is easily forged. This option is therefore a
poor one from an anti-spam point of view. relay_based_on_MX This option tells sendmail to accept a relay if the domain in
which the sender resides lists your sendmail system as a mail exchanger. This
can be a quick and convenient way to control relaying, because you don't need
to modify the sendmail configuration if you want to add domains; you need only
modify the DNS records. The drawback is that spammers who control their own
domains can easily adjust their MX records and hijack your mail server. relay_hosts_only If you use this option, sendmail uses an access database,
described shortly. Only individual hosts listed in this database are allowed to
relay. This can be a good way to limit relays to an arbitrary set of computers. access_db Many sendmail configurations use this option by default. Like relay_hosts_only , it causes sendmail to use an access database. This option causes
the database to be interpreted a bit more loosely, though; you can list entire
domains in the database by using this option.WARNING
align=left border=0> A final option, promiscuous_relay , should be avoided at all costs. This feature tells sendmail to
accept any relay request. Such an open relay
configuration is almost certain to be discovered and abused by spammers.
An example of a relay configuration line is
the following: FEATURE(`access_db')
This option is present in many installations'
default m4 configuration files, but it doesn't actually enable practical
relaying because the default access.db file permits only localhost relaying, as described shortly. If the access_db option is active, sendmail reads the access.db file when it
starts. As described earlier, this file is usually stored in /etc or /etc/mail , and
it's built from a file called access . A typical access file
looks like this: # Allow relaying from localhost... localhost.localdomain RELAY localhost RELAY 127.0.0.1 RELAY # Relay for the local network 192.168.99 RELAY
The first three entries are present in most
configurations; they tell sendmail to accept mail from the localhost computer
(that is, the sendmail computer itself) for relaying. Some local mail programs
rely on such a configuration. The final entry tells sendmail to relay any mail
that comes from the 192.168.99.0/24 network. You can also provide hostnames or
domain names instead of IP addresses, but IP addresses are slightly harder to
forge, and so are preferable whenever possible.All of the preceding examples end in RELAY , but
there are other options you can use: OK This option tells sendmail to accept the mail for local delivery
even if other rules would cause the mail to be rejected. RELAY As you might guess, this causes sendmail to relay mail that
originates from the specified host or domain. It also causes mail addressed to these hosts or domains to be relayed, as well. REJECT If you want to block mail coming from or going to a given host or
domain, you can use this option, which rejects the mail and generates a bounce
message. DISCARD This option works very much like REJECT , but no bounce
message is generated. nnn text This is another option that works like REJECT , but it
generates the error code nnn along with text as a bounce message.Once you've edited the access file,
you can create a binary database file from it with the makemap command, thus: # makemap hash /etc/mail/access.db < /etc/mail/access
Many sendmail installations include such a
command in their startup scripts, so this step may not be strictly necessary. Either
way, you should restart sendmail to have it reread the access file.
Configuring Sendmail to Send Through a Relay
The preceding section dealt with the question
of using sendmail as a mail relay. There's one other aspect of relay
configuration you may want to consider, though: Having sendmail use another
system as a mail relay. You might do this if you run a small network or even a
single computer, and want or need to use your ISP's mail server as a relay. Although
Linux and sendmail are capable of queuing mail locally and delivering it
directly, a few ISPs require you to use their own mail servers for outgoing
mail. Some mail servers refuse mail that's sent directly from dial-up IP
addresses that are listed on certain anti-spam lists, so dial-up users may need
to use this approach to send mail reliably. Also, some Linux
systemsparticularly laptopsmight be shut down much of the time, so you'd do
well to configure them to use another system as a mail relay.Most Linux distributions' sendmail configurations
don't use an outgoing mail relay, but you can use one by adding a single line
to your m4 configuration file: FEATURE(`nullclient', `outgoing.mail.relay')
In this example, outgoing.mail.relay is the hostname of the computer that's to relay your mail. After
you rebuild sendmail.cf and restart the server, it should relay all mail through the
specified outgoing mail server. Be sure to test that mail is being delivered
correctly after making this change.
Sendmail
Anti-Spam Configuration
There are several ways to configure sendmail
to block spam and to prevent unauthorized relay use. One simple anti-spam
configuration is to use the access file and its binary equivalent, access.db , to block spam
based on source hostnames or domains. If you associate a hostname, domain name,
or IP address with a REJECT or DISCARD action, as described earlier, sendmail will block all mail from
that address. This can be an effective tool if you regularly receive spam from
certain source sites, but you should be cautious about using this approach; you
can easily block a great deal of legitimate mail if spammers happen to abuse a
popular ISP.Another approach to blocking incoming spam
with sendmail is to use one or more blackhole lists. You can do this with the dnsbl feature
in your m4 file, thus: FEATURE(dnsbl, `blackholes.mail-abuse.org', `Rejected - see \ http://www.mail-abuse.org/
border=0> rbl/')
This line causes sendmail to use the MAPS
RBL. Change the second option of FEATURE to the value listed in the Server
Address column of
another blackhole list. The final argument is a string that's included in
bounced mail. You should use it to point the bounce recipient to the appropriate
blackhole list's Web site, so that if legitimate e-mail is mistakenly bounced,
the sender can take steps to correct the problem. You can specify
multiple blackhole lists if you like.NOTE
align=left border=0> The use of blackhole lists has changed
substantially with sendmail 8.10, and this discussion applies to that version
and later. Prior versions had much less sophisticated blackhole provisions.
Consult http://mail-abuse.org/rbl/usagel for further information on this point.
Preventing unauthorized relaying with sendmail
is a matter of configuring sendmail to relay in the most stringent manner
possible. The simplest approach is usually to list individual IP addresses or
IP address blocks in access , but some of the other relay options may be useful in some
situations. You should never use the promiscuous_relay feature.WARNING
align=left border=0> If you're using a version of sendmail
that's older than 8.9.0, it's probably configured to allow relays by default.
You should upgrade to a newer version of sendmail, or consult
promiscuously. Versions prior to 8.8.4 are not easily reconfigured to prevent
unauthorized relays; they should almost certainly be upgraded.
