Understanding Sendmail
January 1, 2001
By Moshe Bar
Sendmail, the venerable
MTA, has been around long enough to have created a whole generation of
mail administrators with the necessary know-how to successfully run mail
systems for big corporations and government institutions.
Sure, over time Sendmail
has had its share of problems, mainly related to security and ease of
use. However, since Sendmails original author, Eric Allen, set out
to create a commercial version of Sendmail two years ago, things have
vastly improved for both the OpenSource version and the for-payment version.
But, what is Sendmail
actually? Lets see what it covers and what it doesnt.
Sendmail today:
- Implements a general
internetwork mail routing facility, featuring aliasing and forwarding,
automatic routing to network gateways and flexible configuration.
- Is a mail router that
collects messages generated by a Mail User Agent (MUA) such as mail,
determines a route for delivery, edits the message header as required
by the destination and delivery agent, and calls an appropriate delivery
agent (called a mailer) to deliver the mail. Typical delivery mechanisms
include TCP/IP (using SMTP), UUCP, x.400 and local delivery programs
such as lmail.
- Supports either Internet-style
addressing, such as user@domain, or UUCP-style addressing, such as host!user.
- Supports delivery of
mail with X.400-style addressing to an X.400 gateway machine, if such
a machine is specified in its configuration.
- Handles text format
files only. Binary data is not allowed unless included in the mail message
as a uuencoded file. See the uuencode manual page.
- Is based on the following
standards:
- RFC 822 (Internet
Mail Format Protocol)
- RFC 821 (Simple Mail
Transport Protocol)
- RFC 1123 (Internet
Host Requirements)
- RFC 1425 (SMTP Service
Extensions)
- Does
not include any client/mail reading software. The OpenSource version
of Sendmail does not include any GUI-based tools for installation, configuration
or monitoring.
The OpenSource version,
downloadable from www.sendmail.org, is based on version 8.11.1. The commercial
version, Sendmail Pro, is based on Sendmail 8.9.3.
For the purpose of this
review, I tested both versions of Sendmail on a dual Netfinity 5100 Pentium
III 700-MHz server with 768 MB of RAM and five disk drives under RAID.
This configuration should be big enough to support thousands of users.
The OS was Linux 2.2.17 based on the RedHat 6.2 distribution. The server
was attached to the LAN through two 100 Mb NICs and one FDDI card.
OpenSource Sendmail 8.11.12.2000
After downloading (and
carefully checking the MD5 signatures) the 1.3 MB source code of Sendmail
8.11.1, I proceeded to compile it on the target system. Considering the
scope of this beast, compiling Sendmail is not that difficult. I downloaded
the file and unzipped it within a work directory. As the readme file specifies
(since version 8.9.), there is a build script that comes with the source
called, appropriately enough, "Build."
It is enough to launch
"sh Build," which will start compiling the source. The machine
trundled for about 10 minutes and then quietly created a new Sendmail
binary. Once I copied that binary file to the /usr/sbin and restarted
Sendmail, everything was done. It couldnt be any easier.
Compiling and installing
Sendmail is one thing. Configuring it is another. Luckily, most Linux
and other Unix distributions already have a capable configuration file
(Sendmail.cf).
The Sendmail.cf file has
a very complex and varied syntax. Suffice to say that of all OReilly
books (www.oreilly.com), the one on Sendmail is by far the thickest. According
to the Sendmail Inc. folks, the average Sendmail.cf file is over 1,100
lines long. The Unix standard character for comments (the # sign) is significant
as a configuration symbol. In fact, in Sendmail.cf every character is
significant.
An m4 macro processor
is only a slight consolation. It allows for a somewhat more readable macro
configuration file, but even that is still overly complex, especially
in these days of click-and-drag-and-drop software.
We won't discuss how to
configure a Sendmail system here, since this subject is beyond the scope
of any article--its even beyond that of a single-tome book. More detailed
instructions describing how to build and install Sendmail.cf are available
at the Sendmail Web site or in the Sendmail book by Bryan Costales
and Eric Allman.
Since e-mail abuse is
high on the list of computer annoyances of the connected generation, we
will instead focus on how to use the modern Sendmail program to avoid
spam and viruses.
Anti-Abuse Features in
Sendmail
Hardly an hour goes by
without yet more unsolicited e-mail entering my inbox. Some people get
used to this abuse, many others dont stand for it and search for
remedies to this plague.
Sendmail today provides
many anti-span and security features. The spam issue is obvious: Some
miscreants obtain a list of e-mail addresses and then use it to send e-mails
promising fast riches, remedies for diseases or both. Mostly the senders
true identity is not easily traceable from the senders e-mail address,
because it is a fake. Actually responding to the sender with a request
to be removed from his/her list only qualifies your e-mail address as
active and thus guarantees its further spread to other mailing lists as
a "quality address."
Sendmail's security features
include anti-virus measures as well as the ability to prevent any unauthorized
use of the relaying capabilities inherent to any MTA.
Since version 8.9 of Sendmail,
there is no relaying mail unless specifically instructed to do so. And
by default, Sendmail rejects messages with "envelope From" addresses
(the address mentioned in the SMTP "MAIL FROM:" command) that contain
a host name that does not resolve successfully by reverse name lookup.
However, relaying is not the same as forwarding. Forwarding is done at
the request of the recipient rather than at the sender's request. Forwarding
addresses may be specified in either a user's .forward file or the global
/etc/mail/aliases or /etc/mail/virtusertable file, regardless of the system's
relaying policy.
Another security option
is FEATURE. It limits programs into which Sendmail can pipe mail (for
example, as a result of an entry in a .forward file or /etc/mail/aliases)
to those programs that reside in a specific directory, usually /usr/libexec/sm.bin.
The administrator usually creates symbolic links in this directory to
programs such as vacation and majordomo. The Sendmail restricted shell,
smrsh, also rejects commands with certain metacharacters and strips the
directory path from the front of the program name. This feature is not
useful if procmail is installed and users can supply their own .procmailrc
files, since other applications can then be invoked through procmail.
Another interesting option is:
define(`confMAX_HEADERS_LENGTH',16384)dnl
This limits the aggregate
size of all headers. It also helps because many spammers try to fool MTAs
by composing very long headers that add the legitimate information out
of the buffer used to hold the headers. Additionally, this option is a
useful feature because it prevents the buffer overflow attack which affects
Outlook and Outlook Express.
The following option prevents
Sendmail from revealing local user names to spammers and hackers:
define(`confPRIVACY_FLAGS',`goaway')dnl
And the following command
limits the number of new connections per second to Sendmail:
define(`confCONNECTION_RATE_THROTTLE',3)dnl
Since every new connection
forks a new Sendmail process, this feature can prevent a very busy mail
server from choking under undue strain. I tested this feature on my mail
server during a recent Cyberwar that erupted as a consequence of conflicts
in Israel, when many known Israeli sites (including mine) were attacked
with a barrage of messages. Turning this feature on kept my system from
crashing.
To prevent hackers and
spammers from knowing which operating system you are using, it is important
to turn off the Sendmail welcome message. Use the following command to
do so:
define(`confSMTP_LOGIN_MSG', `$j server ready at $b')dnl
And, lastly, you can use
this command to limit the number of recipients per e-mail message:
define(`confMAX_RCPTS_PER_MESSAGE,25)dnl
These features should
have an immediate, noticeable and positive impact on the security and
reliability of your Sendmail messaging.
Sendmail Pro
For those corporations
needing top-notch support for a Sendmail-based messaging solution as well
as added management and configuration comfort, the commercial Sendmail
Pro version might be a worthwhile alternative to the OpenSource rendition.
For one thing, Sendmail
Pro includes over 300 pages of online help. But should such extensive
online help not be enough, there is always technical support available
from Sendmail Inc. via Web, e-mail, telephone and even onsite consulting.
In the security arena,
Sendmail Pro provides powerful tools to filter spam, including:
- Sendmail 8.9's Access
Database to filter mail by sender's address, domain or IP address
- MAPS Real-time Blackhole
List (RBL), a public list of known spammers
- Filters for unrecognizable
senders or domains
- Mail message size and
volume limits
Sendmail published application-programming
interfaces to allow developers who are plugging in programs in C, Perl
or others to filter their incoming mail.
This filtering capability
gives companies the opportunity to search for viruses in the incoming
mail stream before they reach departmental e-mail servers. It can filter
out well-known sources of spam and even spot attempts of intrusion hidden
within in-coming connections.
Such content-based filtering
is also a good way to control incoming and outgoing messages to prevent
the use of objectionable language. The law in many countries permits companies
to supervise the content of employees messages.
With Sendmail Multi Switch
2.1 (reviewed in Network Computing here),
the filtering application is built into the product. Sendmail Multi Switch
2.1 manages the workload between multiple departmental or on-site mail
servers and provides a module for encrypted access for both local and
remote mail users through a range of mail protocols. They include IMAP,
POP, Webmail and Wireless Application Protocol. It also provides the capability
to manage e-mail systems by monitoring inbox queues, sending an alert
if one is filling up faster than the e-mail server can handle.
Performance Considerations
During my review, I found
that both the commercial and the OpenSource versions of Sendmail were
able to handle e-mails in excess of 500 per second on the above-mentioned
system. When turning on filtering through C programs, that volume dropped
down to about 140 per second. It is clear that housing the filter within
the same address space as the Sendmail process would speed up filter processing
considerably.
By analysing the Linux
kernel, it became evident that most of the overhead lies in the creation,
management and tearing down of the address space used to handle filtering.
As with Apache, filtering modules within the same process is certainly
the solution. However, e-mail traffic in the magnitude of 140 per second
is certainly more of an issue for ISPs than it is for most companies.
Also, the structure and algorithms for the filtering applets can have
a great impact on the performance.
Even though Sendmail is
already a grown-up product at the age of 19, it is still keeping up with
the times. Sendmail outperforms many other commercial products and still
has by far the greatest marketshare of all of them combined, handling
over 76% of all the e-mail flowing across the Internet.
Moshe Bar (www.moelabs.com)
is an Israeli system administrator and OS researcher with an emphasis
on enterprise computing and clustering. All Unix-based, obviously.
|