SMTP Servers

SMTP: Simple Mail Transfer Protocol (TCP Port 25)

The Simple Mail Transfer Protocol (SMTP) is an Internet standard for transferring electronic mail between
computers. UNIX systems implement the SMTP protocol with programs or systems called Message
Transfer Agents (MTAs). MATs usually implement both the client and server sides of the SMTP protocol,
although this is not a requirement.

It is possible for a user to send email directly using an MTA, but it can be awkward. Instead, users more
often employ programs called Message User Agents (MUAs) to send, download, and read their email.
There are many popular MUAs.

Traditionally, UNIX systems used the program sendmail as an MTA, although today there are many
alternatives. sendmail was written by Eric Allman. It was the first UNIX mail system to implement Internet
standard mail protocols. This program was distributed as part of the original Berkeley 4.2 Unix distribution
and since that time has been distributed with the vast majority of UNIX distributions. By many accounts,
sendmail remains the most widely used mailer on the Internet today. Because of its long history,
sendmail has undergone numerous revisions.

All mailers can perform the following functions:

Deliver mail to individual user mailboxes or to files.

Implement a list of aliases that specify rules for email addresses. Aliases can also be used to
create simple mailing lists. Aliases are traditionally located in the aliases file, usually in the
/etc/mail directory on Solaris systems.

Determine if an email message should be sent to another machine and automatically send it to
that machine using SMTP.

Pipe mail messages to programs as standard input.

Provide a command-line utility for sending mail. This program, traditionally called sendmail, is
used primarily by scripts and programs to send email.

Allow individual users to set up an alias for their accounts by placing a file with the name
.forward in their home directory.

Each mail system has a complex set of configuration files and accessory programs. Each has its own
security risks and advantages. All can be run securely and all can be run in a manner that compromises
your system’s security.

Because of their importance and position on the network, email systems have become an important location
for implementing additional security features. For example:
 Many viruses for MAC-based computers propagate by sending themselves to other MAC users
via email. By automatically scanning all email messages for known viruses and dropping
messages that contain viruses, it is possible to protect users of MAC operating systems from
some hostile programs that might otherwise compromise their computer systems.

Many individuals who send out unwanted email, otherwise known as spam, do so using “throw-
away” accounts that they purchase on a “trail” basis from ISPs. By limiting the number of email
messages that a user can send to 500 or 1,000 per day, ISPs and other organizations can
effectively prevent their users from engaging in spamming.

In a similar manner, many different mechanisms exist to detect spam in incoming email. The
various filters and database lookups required can be added to a mail system to prevent some
spam from getting through to end users.

There are a number of security issues arising with SMTP and MTAs that we will explore in the following
sections. These include:

Configuration files

Security concerns with SMTP banners and commands

SMTP relaying and bulk email, a.k.a. spam

Overflowing mailboxes

Delivery to programs

Overall security of Berkeley sendmail versus other MTAs

Configuration Files

sendmail uses several configuration files to control its operation, including sendmail.cf, the master
configuration file and .forward files in each user’s home directory. Many sendmail configuration files are
maintained as text files but compiled into database files, e.g. the aliases file is often compiled into aliases.dir
and aliases.pag or a single aliases.db file. Configuration files on Solaris systems are stored in the /etc/mail
directory. Spool files are stored in the /var/mail directory.

Modern versions of sendmail check ownership of all configuration files and directories that contain
configuration files as well as directories where messages are spooled. If a directory of questionable
permissions is found, sendmail will report an error.

Security Concerns with SMTP Banners and Commands

SMTP is a text-based, asynchronous protocol that has been in use since 1983. Previous versions of SMTP
and MTAs were in use in the 1970s. While the protocol itself is quite simple, the functions that an MTA
needs to invoke on the host computer to properly satisfy the requirements of the protocol can be quite
complex. For this reason, SMTP implementations have been a cause of many security vulnerabilities.

SMTP is also an evolving protocol. In recent years the protocol has been enhanced with mechanisms for
sender authentication and encryption. Other functions remain in the protocol but are now largely blocked
because of security concerns.

When an SMTP server receives a connection, it sends a banner to the SMTP client. Traditionally, this
banner included the name and version of the MTA implementing the SMTP server. You can see what
banner your SMTP server sends to clients by testing it using the telnet command. For example on Sparc2

$ telnet localhost smtp

Trying 127.0.0.1...
Connected to localhost (127.0.0.1).
Escape character is '^]'.
220 sparc2.cs.clemson.edu ESMTP Sendmail 8.14.4+Sun/8.14.4; Sat, 9 Apr 2011
16:52:35 -0400 (EDT)
help
214-2.0.0 This is sendmail version 8.14.4+Sun
214-2.0.0 Topics:
214-2.0.0 HELO EHLO MAIL RCPT DATA
214-2.0.0 RSET NOOP QUIT HELP VRFY
214-2.0.0 EXPN VERB ETRN DSN STARTTLS
214-2.0.0 For more info use "HELP <topic>".
214-2.0.0 To report bugs in the implementation contact Sun Microsystems
214-2.0.0 Technical Support.
214-2.0.0 For local information send email to Postmaster at your site.
214 2.0.0 End of HELP info
QUIT
221 2.0.0 sparc2.cs.clemson.edu closing connection
Connection closed by foreign host.

In general, it is not a good practice for your server to reveal its identity in this fashion. Certain servers have
well-known security flaws. By providing its version numbers to all SMTP clients, this server makes it easy
for an attacker to scan for vulnerable servers. These banners can usually be changed.

Besides leaking information about your MTA version, the SMTP protocol can leak significant information
regarding the names and email addresses of users at your organization. Historically, this information has
been used most often by individuals and organizations sending bulk email. Thus, you may wish to disable
any SMTP commands that leak email addresses. For example the vrfy command will verify whether email
sent to a particular address will be accepted or rejected. Let’s see what happens trying Sparc2

$ telnet localhost smtp

Trying 127.0.0.1...
Connected to localhost (127.0.0.1).
Escape character is '^]'.
220 sparc2.cs.clemson.edu ESMTP Sendmail 8.14.4+Sun/8.14.4; Sat, 9 Apr 2011
17:01:19 -0400 (EDT)
vrfy wayne@cs.clemson.edu
252 2.1.5 <wayne@cs.clemson.edu>
vrfy haas@cs.clemson.edu
252 2.1.5 <haas@cs.clemson.edu>
vrfy zxy@cs.clemson.edu
252 2.1.5 <zxy@cs.clemson.edu>
vrfy hcgrs@clemson.edu
252 2.1.5 <hcgrs@clemson.edu>
vrfy zyx@clemson.edu
252 2.1.5 <zyx@clemson.edu>
quit
221 2.0.0 sparc2.cs.clemson.edu closing connection
Connection closed by foreign host.

Now let’s see what mail.clemson.edu does

$ telnet mail.clemson.edu smtp

Trying 130.127.237.190...
Connected to mail.clemson.edu (130.127.237.190).
Escape character is '^]'.
220 mailclient1.clemson.edu ESMTP Sendmail 8.13.8/8.13.8; Sat, 9 Apr 2011
17:06:43 -0400
vrfy hcgrs@mail.clemson.edu
252 2.5.2 Cannot VRFY user; try RCPT to attempt delivery (or try finger)
quit
221 2.0.0 mailclient1.clemson.edu closing connection
Connection closed by foreign host.

SMTP Relaying and Bulk Email, a.k.a. Spam

By design, SMTP servers accept email from the Internet and deliver the mail to its intended destination.
When the email is destined for a local mailbox, the mail should be delivered. When the mail is destined for
another host, the mail is relayed.

Relaying is an integral part of the SMTP protocol and vital to the proper functioning of Internet mail. A large
organization might have hundreds of individual users with desktop computers that wish to be able to send
mail. Managing hundreds of MTAs can be a very hard task. That task can be made manageable if each
computer is configured to send outgoing email messages to a single computer, which then relays the
messages to the rest of the Internet. Relaying can also improve the reliability of receiving Internet
messages: many domains will designate secondary mail servers that can receive their mail if the primary
mail server is down. This allows for all of the mail to be spooled in a single location and to be delivered in
an orderly fashion when the computer comes back up.

Unfortunately, SMTP relaying has been exploited by individuals and organizations that send large amounts
of bulk electronic mail, known as spam. These so-called spammers have programs that will connect to
another organization’s SMTP server and send a single message that has dozens or even hundreds of
recipients. Following the design of the protocol, the victim’s SMTP server will then methodically copy the
message and deliver it to each of the recipients, whether they want it or not. To make matters worse, many
of the addresses on the spammer’s list may no longer by valid. These undeliverable messages frequently
end up in the mailbox of the system administrator.

Because of abuse by spammers, modern MTAs have provisions designed to prevent or severely restrict the
use of the SMTP server for sending third-party email. The following is a typical set of rules:

Users who are authenticated members of the organization that runs the computer system are
allowed unlimited use of the SMTP server. Users are typically authenticated through one of
three techniques:

Through IP address
The system is configured with a set of IP addresses that are allowed unrestricted relaying

Through a username and password

Authentication mechanisms that are part of the Extended SMTPO are used here.

Through an external mechanism

One of the most common mechanisms is called “POP before SMTP.” This mechanism
requires that a user be able to download a message using POP before she is allowed
unrestricted SMTP access.

These rules allow authenticated users to send email to anywhere on the Internet.

Messages that are delivered over SMTP connections that are not authenticated are accepted
only for a preconfigured set of domains. This rule allows anybody on the Internet to send email
to users of the server.

Overflowing System Mailboxes

The UNIX operating system uses accounts without corresponding real users to perform many system
functions. Examples of these accounts include uucp, news, and root. Unfortunately, the mail system will
happily receive email for these “users.”

Email delivered to one of these accounts normally goes only to a mail file. There, it resides in your /var/mail
directory until it is finally read. On some systems, there is mail waiting for users with the names news or
ingres that is more than five years old.

Is this a problem? Absolutely!

These mail files can grow to be several megabytes long, consuming valuable system resources.

Many programs that run autonomously will send mail to an address such as http or daemon
when they encounter a problem. If this mail is not monitored by the sysadmin, problems can go
undiagnosed.
You can avoid the problem of phantom mail by creating mail aliases for all of your system, nonuser
accounts. To make things easy for future sysadmins, you should put these aliases at the beginning of your
aliases file. For example:

#
# System Aliases
#
root: grossman
Postmaster: root
usenet: root
news: root
MAILER-DAEMON: postmaster
abuse: postmaster

All Internet hosts that run email servers must define a postmaster alias, and mail sent to the postmaster
should be promptly read by a human being. Defining an abuse alias is also good practice. If one of your
users should send spam through your server, recipients will often expect to be able to report it to this alias.

System mailboxes can also be configured so that their messages are gatewayed to locally-managed
newsgroups or web pages. Such configuration has the advantage of providing for access by multiple
individuals, archiving, and searching.

Delivery to Programs

Mail does not have to be delivered to a mailbox. It can also be delivered to a program. One such program
is the vacation program, which sends out a polite message telling the sender of the mail that the recipient is
on vacation and is not able to respond to messages immediately. Many mailing list programs, such as
majordomo and mailman, also work by having the received mail sent to a program rather than to a mailbox.

Because programs that receive mail messages frequently run as a privilege user, they can be a source of
security vulnerabilities. These programs potentially receive unrestricted input, so their authors must take
extra precaution to validate arguments.

Here are some specific recommendations for configuring your email system with respect to mail delivery to
programs:

If you do not specifically need the ability to deliver mail to programs, disable this feature in your
mailer system. With sendmail you can disable this feature by defining
confLOCAL_SHELL_PATH to a program such as /bin/false. If you do need progmailer
functionality, use smrsh bundled with sendmail 8.7.x and above. smrsh restricts the allowed
programs to a small set that you maintain in a special directory.

Inspect your aliases file and verify that it does not have a decode alias. The decode alias is a
single line that looks like this:
decode: “| /usr/bin/uudecode”
The decode alias allows mail to be sent directly to the uudecode program. This ability has
been shown to be a security hole and, in any event, is no longer needed. It was created in the
days before MIME extensions to email. Examine carefully every alias that points to a file or
program instead of a user account. Remember to run newaliases after changing the aliases
file.