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.
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
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)
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.
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
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”
