لطفا منتظر باشید ...
SMTP Server
Configuration Options
The following sections describe various
features you might want to configure in your mail servers. Rather than repeat
the descriptions of what these options mean in each section, I describe them
once here.
Address Masquerading
One of the most common configuration changes
required of a mail server is address masquerading changing
the hostname that the mail server claims to be. Ordinarily, most SMTP server
installations use the hostname as set in the basic network configuration and as
returned by the hostname command. The MTA uses this hostname in its HELO greeting
when contacting other mail servers, as well as in the MAIL FROM command and From: message header if the mail doesn't already include that
information. The server also identifies itself with this name to connecting
computers, as in the 220 response in
but sometimes you may need to use another name. For instance, suppose your mail
server is called franklin.threeroomco.com . You might prefer that outgoing mail never be identified as coming
from this computer, but instead from the threeroomco.com domain. (This
might be important if you've got separate incoming and outgoing mail servers,
for aesthetic reasons, or to allow you to more easily change your mail server
without disrupting mail sent as replies to the default address.) You might also
want to change the hostname used by a computer on a firewalled network so that
return messages go to an externally accessible system. The solution is to use
address masquerading to have franklin.threeroomco.com announce itself as threeroomco.com . All the mail servers
discussed in this chapter can perform address masquerading, but details differ.
Some include extensive options to let you fine-tune which commands, greetings,
and headers use the new name, but others give fewer options. Some make it
relatively easy to alter existing message headers to reflect some new address,
but others discourage such actions.NOTE
align=left border=0> Some mail administrators look down on the
practice of altering mail headers, because these headers are supposed to
provide a clear path back to the originating system. Other mail
administrators consider the ability to rewrite mail headers absolutely vital
to avoid problems that might otherwise result from mail crossing firewalls or
the like. If you're unfamiliar with mail administration, you're probably best
off doing as little masquerading as possible, and adding these features only
if you find you have problems. If used incorrectly, masquerading can result
in confusion and even bounced mail.
Accepting Mail
as Local
The flip side to address masquerading is
telling the mail server what addresses to treat as local. For instance, you
might run a mail server that's called franklin.threeroomco.com .
The default configuration in most SMTP server installations is to accept mail
addressed to users at franklin.threeroomco.com . If your domain is set up with an MX record that points at this
system, though, it will also see mail addressed to users at threeroomco.com . Furthermore, you might want to configure the mail server to accept
mail addressed to completely different hostnames or domains. Perhaps the
company has recently expanded and changed names, so you want to add fourroomco.com to the list of domains that the mail server will accept and deliver locally.All the mail servers covered in this chapter
allow you to specify what hostnames the server is to interpret as local. When
you configure such a list, the server accepts mail addressed to users at these
addresses and drops the messages into the users' local mailboxes (or forwards
the mail, if the server is configured to forward a user's mail to another
system). The details of this configuration differ from one server to another,
of course.
Relaying Mail
One of the trickiest, and potentially most
dangerous, aspects of mail configuration today is proper configuration of a
mail server to handle mail relays. A mail relay
system is one that accepts mail from one computer and delivers it to another. Most
networks use at least one mail relay system, because network connections are
sometimes unreliable. If a client attempted to deliver mail directly to the
recipient and the connection failed, the mail client program would have to
continue running to periodically attempt redelivery. An SMTP server configured
as a relay, though, can accept mail from the local network with high
reliability, then hold onto the mail until network conditions allow its
delivery.Unfortunately, relay configurations can be
easily abused. If the MTA is too promiscuous in the systems for which it will
relay, the server can be abused by third parties to send spam (unsolicited junk e-mail). Thus, you must find
the appropriate balance to secure your server against unwelcome users while
still allowing legitimate users to use the server as a relay. The correct
configuration depends upon the role of the mail server program in your network,
and that in turn depends in part upon your network structure.Sometimes you may need to configure your
system for third-party relaying. This is allowing an outside system to use
yours as a mail relay. This is ordinarily undesirable, but there may be
circumstances in which you might want to allow it. For instance, you might want
to let employees who are traveling use a mail server on your own network to
relay mail. Many MTA relay options that are ordinarily used to permit local
relaying can be used to enable third-party relaying. You might enter the
third-party IP address, domain name, or the like in the configuration options
just as you would a local address or name.NOTE
align=left border=0> Traveling users can be particularly
troublesome, because such users frequently use dial-up ISPs with very large
sets of IP addresses. You probably don't want to enable all of these IP
addresses to relay, since a spammer who uses the same ISP might stumble upon
your system and use it as an open relay. In such situations, it's usually
better to have the traveling user use the ISP's outgoing mail server. Another
option is to use an SMTP-after-POP
configuration, in which a POP server can tell the SMTP server to accept
relays from a particular IP address for some period after that IP address
successfully checked or retrieved e-mail. This allows the remote user to
relay mail, but only after accessing the POP server. Yet another option is to
have the traveler use SSH to log on to a local system, or configure an SSH
tunnel for the outgoing SMTP connection.
You may also want to configure an SMTP server
to deliver all or some of its mail via another SMTP server. You might want
local workstations to send mail via the departmental mail server, for instance,
despite the fact that the workstations' MTAs are capable of direct delivery, in
order to better track e-mail. Systems that use dial-up connections may need to
use a relay in order to deliver mail at all, because some ISPs place their
dial-up addresses on an anti-spam list that's used by others to block direct
SMTP connections. Using the relay on such a network allows for more reliable
mail delivery.TIP
align=left border=0> If you're configuring a system that has
multiple transient Internet connections, such as a notebook that you use with
different ISPs, using a mail relay may be inconvenient. Many ISPs reject
relays except from systems on their own networks, so this approach will work
with just one ISP. You can work around this problem by creating two SMTP
server configuration files, one for each ISP, under names other than the one
used by the standard configuration file. You can then add lines to your PPP
dialing scripts that copy the appropriate configuration files and restart the
SMTP server. For instance, if you're using sendmail, you might call the files
sendmail-isp1.cf and sendmail-isp2.cf , and copy one of these to sendmail.cf in your PPP
dialing scripts.
Anti-Spam Configuration
When e-mail was invented, it was considered a
useful means of personal communication, and it remains that. Unfortunately,
advertisers have discovered that e-mail can be an inexpensive way to
communicate with potential customers. I say "unfortunately" for two
reasons. First, much of the e-mail advertising today is of the lowest
kindget-rich-quick scams, ads for pornographic Web sites, and worthless
products. Second, e-mail advertising is clogging mail servers around the globe,
and the potential for serious harm from this form of advertising is still
greater. Sending e-mail is very inexpensive, but receiving it is costlier, in
terms of disk space used, recipients' time to read or even simply delete the
messages, and so on. If spam becomes popular with more businesses than those of
questionable repute who currently use it heavily, e-mail will quickly become
completely useless, as our e-mail inboxes become clogged with thousands of
worthless messages a day.Because of concerns about spam, mail administrators
frequently take steps to block it. These blocks occur at two levels: Stopping
spam from getting into a mail server, and stopping it from getting out.
Blocking Incoming Spam
Your own personal concerns about spam
probably revolve around the spam that's directed at your system, because this
is the spam that's most obvious to you. There are several ways to control such
spam. The more popular methods include the following: Mail server
pattern-matching blocks Most mail servers
provide some way to block e-mail that matches certain criteria, such as mail
from particular users or networks. You can use these facilities to block
incoming mail from known spammers or ISPs that generate nothing but spam. Unless
you review such blocks, though, you may go too farfor instance, you might
block an ISP, but if the ISP cleans up its act, you'll block its legitimate
users for no reason. Indeed, even an ISP that knowingly hosts spammers may also
host legitimate users. Other pattern matches may be less likely to cause problems
because they're more specific. Blackhole lists Several organizations now publish lists of IP addresses that you
might want to use as a basis for blocking e-mail. IP addresses on these lists
may be known to have sent spam, may be open relays that are easily abused by
spammers, may be associated with PPP dial-up accounts that should ordinarily
relay mail through their ISPs' mail servers, or may be otherwise suspect as
direct senders of e-mail. Most mail servers can be configured to use one or
more such anti-spam blackhole lists.
matches The Procmail system, described in the
upcoming section, "
than are supported by most mail servers. In fact, some sophisticated anti-spam
systems, such as SpamBouncer ( target="_blank">http://www.spambouncer.org ), are built atop Procmail. You can use such a system or design a
Procmail filter yourself. Distributed pattern
matching A fairly recent anti-spam tool is
Vipul's Razor ( http://razor.sourceforge.net ). This system relies upon a catalog of spam identified by a
database of spam message Secure Hash Algorithm (SHA) codes maintained by
Vipul's Razor servers. You can configure your mail system to compute SHA codes
on incoming mail, and if it matches the Vipul's Razor codes, you can be
reasonably sure it's spam.As a general rule, you can block a great deal
of spam using just one or two methods, such as an MTA-based pattern match or a
single blackhole list. One of the problems with any anti-spam measures you
might take is that there is no way for a computer program using today's
technology to determine with 100% certainty that a given message is spam. All
the spam-blocking methods therefore rely upon generalizations of one sort or
another, such as patterns that often appear in spam headers or the IP address
from which a message comes. These generalizations often catch spam, but they
may also discard legitimate e-mail, as well. Occasional false positives like this may be acceptable to you,
or they might not be. To minimize the risk of false positives, you can use
simple custom pattern- matching rules that match by very narrow criteria. Among
the blackhole lists, the RBL and RSS are least likely to produce large numbers
of false positives. The blackhole lists operated by the Mail Abuse Prevention
System (MAPS)the RBL, RSS, and DULare offered on a subscription basis, with
an exception made for hobbyist sites.
Table 19.1. Common
Anti-Spam Blackhole Lists
List Name
URL
Server Address
Description
Dial-Up List (DUL)
http://mailabuse.org/dul/
dialups.mail-abuse.org
This is a list of IP addresses associated with ISPs' dial-up PPP
connections. The rationale is that such users shouldn't need to send mail
directly, because they can use the ISP's mail relay, but spammers frequently
bypass the ISP's relay.
Realtime Blackhole List (RBL)
http://www.mail-abuse.org/rbl/
blackholes.mail-abuse.org
This list includes systems that are known to have spammed,
supported spammers in various ways, or relayed spam and not corrected the problem.
Relay Spam Stopper (RSS)
http://www.mail-abuse.org/rss/
relays.mail-abuse.org
This list holds systems that have been documented as having
relayed spam, and which have been shown to be an open relay by a
semi-automated test.
Open Relay Database (ORDB)
http://www.ordb.org
relays.ordb.org
This list is similar to the RSS, but its criteria for adding
hosts are looser. Therefore, ORDB blocks more spam, but also mistakenly
blocks more legitimate e-mail.
RFC Ignorant
http://www.rfc-ignorant.org
Various;see Web site
The RFC Ignorant organization maintains several blackhole lists
of systems that demonstrate ignorance of one or more Request for Comments
(RFC) Internet standards. Spammers often use such misconfigured systems,
hence the rationale for using this as an anti-spam criterion.
How to Avoid Becoming a Spam Source
Although you're probably most concerned with
blocking incoming spam, you should pay at least as much attention to preventing
your system from being used to transmit spam. On a large network, you may need
to be careful to police your own users to be sure they don't originate spam. This
may involve creating an acceptable use policy (AUP)
that prohibits spamming and ensuring that your users are aware of it. Some
users may not realize the extent to which spam is frowned upon.Especially on a small network or an
individual workstation on which a mail server is installed, a more serious
concern is that of configuring your system so that it doesn't become an open relay a computer that's configured to relay mail
from any system on the Internet to any other system on the Internet. (Even
relaying between subsets of systems may be problematic, if those subsets are
large enough.) Much of the upcoming discussion of individual SMTP servers is
concerned with relay configuration. You may need your system to relay for
certain systems, but it's important when you create this configuration that you
don't open your system too widely.One way to test whether a system is an open
relay is to Telnet from that system to
this causes a reverse connection to your own mail server. You'll see the tests
as they proceed, followed by a statement that your system is or is not an open
relay. Although this test can be very useful, it's not absolutely conclusive;
there are configurations that can fool the test, but it's a good place to
start.To learn more about anti-relay configurations,
including tips for how to configure various mail servers, check the MAPS
Transport Security Initiative (TSI) Web page at
