SMTP

UNDERSTANDING SMTP
The SMTP protocol defines the method by which mail is sent from one host to another.
That’s it. It does not define how the mail should be stored. It does not define how the
mail should be displayed to the recipient.
SMTP’s strength is its simplicity, and that is due, in part, to the dynamic nature of net-
works during the early 1980s. (The SMTP protocol was originally defined in 1982.) Back
in those days, people were linking networks together with everything short of bubble
gum and glue. SMTP was the first mail standard that was independent of the transport
mechanism. This meant people using Transmission Control Protocol/Internet Protocol
(TCP/IP) networks could use the same format to send a message as someone using two
cans and a string.
SMTP is also independent of operating systems, which means each system can use its
own style of storing mail without worrying about how the sender of a message stores his
mail. You can draw parallels to how the phone system works: Each phone service pro-
vider has its own independent accounting system. However, they all have agreed upon
a standard way to link their networks together so that calls can go from one network to
another transparently.
Rudimentary SMTP Details
Ever had a “friend” who sent you an e-mail on behalf of some government agency
informing you that you owe taxes from the previous year, plus additional penalties?
Somehow, a message like this ends up in a lot of people’s mailboxes around April
Fool’s Day. We’re going to show you how they did it and, what’s even more fun, how
you can do it yourself. (Not that we would advocate such behavior, of course.)
The purpose of this example is to show how the SMTP protocol sends a message
from one host to another. After all, more important than learning how to forge an
e-mail is learning how to troubleshoot mail-related problems. So in this example, you
are acting as the sending host, and whichever machine you connect to is the receiv-
ing host
The SMTP protocol requires only that a host be able to send straight ASCII text to
another host. Typically, this is done by contacting the SMTP port (port 25) on a mail
server. You can do this using the Telnet program. For example,
[root@serverA /root]# telnet mailserver 25
where the host mailserver is the recipient’s mail server. The 25 that follows mailserver
tells Telnet that you want to communicate with the server’s port 25 rather than the nor-
mal port 23. (Port 23 is used for remote logins, and port 25 is for the SMTP server.)
The mail server will respond with a greeting message such as this:
220 mail ESMTP Postfix
You are now communicating directly with the SMTP server.
Although there are many SMTP commands, the four worth noting are
 ? HELO
? MAIL FROM:
? RCPT TO:
 ? DATA
TheHELO command is used when a client introduces itself to the server. The param-
eter to HELO is the hostname that is originating the connection. Of course, most mail
servers take this information with a grain of salt and double-check it themselves. For
example:
HELO example.org
If you aren’t coming from the example.org domain, many mail servers will respond
by telling you that they know your real IP address, but they may or may not stop the
connection from continuing.
The MAIL FROM: command requires the sender’s e-mail address as its argument.
This tells the mail server the e-mail’s origin. For example:
MAIL FROM: suckup@example.org
means the message is from suckup@example.org.
TheRCPT TO: command requires the receiver’s e-mail address as an argument. For
example:
RCPT TO: manager@example.org
means the message is destined to manager@example.org.
Now that the server knows who the sender and recipient are, it needs to know what
message to send. This is done by using the DATA command. Once issued, the server will
expect the entire message, with relevant header information, followed by one empty line, a period, and then another empty line. Continuing the example, suckup@example.
org might want to send the following message to manager@example.org:
DATA
354 End data with .
Just an FYI, boss. The project is not only on time, but it is within
budget, too!
Regards –
SuckUp_to Upper_Management
.
250 2.0.0 Ok: queued as B9E3B3C0D
And that’s all there is to it. To close the connection, enter the QUIT command.
This is the basic technique used by applications that send mail—except, of course,
that all the gory details are masked behind a nice GUI application. The underlying trans-
action between the client and the server remains mostly the same.
Security Implications
Sendmail, the mail server a majority of Internet sites use, is the same package most Linux
distributions use. Like any other server software, its internal structure and design are
complex and require a considerable amount of care during development. In recent years,
however, the developers of Sendmail have taken a paranoid approach to their design to
help alleviate these issues. The Postfix developers took it one step further and wrote the
server from scratch with security in mind. Basically, they ship the package in a tight secu-
rity mode and leave it to us to loosen it up as much as we need to for our site. This means
the responsibility falls to us for making sure we keep the software properly configured
(and thus not vulnerable to attacks).
These are some issues to keep in mind when deploying any mail server:
 ? When an e-mail is sent to the server, what programs will it trigger?
? Are those programs securely designed?
? If they cannot be made secure, how can you limit their damage?
 ? Under what permissions do those programs run?
In Postfix’s case, we need to back up and examine its architecture.
Mail service has three distinct components. The mail user agent (MUA) is what the user
sees and interacts with, such as the Eudora, Outlook, Evolution, and Mutt programs. An
MUA is responsible only for reading mail and allowing users to compose mail. The mail
transport agent (MTA) handles the process of getting the mail from one site to another;
Sendmail and Postfix are MTAs. Finally, the mail delivery agent (MDA) is what takes the
message, once received at a site, and gets it to the appropriate user mailbox.
Many mail systems integrate these components. For example, Microsoft Exchange
Server integrates the MTA and MDA functionalities into a single system. (If you consider
the Outlook Web Access interface to Exchange Server, it is also an MUA.) Lotus Domino
also works in a similar fashion. Postfix, on the other hand, works as an MTA only, pass-
ing the task of performing local mail delivery to another external program. This allows
each operating system or site configuration to use its own custom tool, if necessary (that
is, to be able to use a special mailbox store mechanism).
In most straightforward configurations, sites prefer using the Procmail program to
perform the actual mail delivery (MDA). This is because of its advanced filtering mecha-
nism, as well as its secure design from the ground up. Many older configurations have
stayed with their default /bin/mail program to perform mail delivery.
INSTALLING THE POSTFIX SERVER
In this section, we will cover the installation of the Postfix mail server. We chose it for its
ease of use and because it was written from the ground up to be simpler than Sendmail.
(The author of Postfix also argues that the simplicity has led to improved security.) Post-
fix can perform most of the things that the Sendmail program can do—in fact, the typical
installation procedure for Postfix is to replace the Sendmail binaries completely.
In this section, we install Postfix in one of two ways: either using the Red Hat Pack-
age Manager (RPM) method (recommended) or via source code.
Installing Postfix via RPM in Fedora
To install Postfix via RPM, simply use the Yum tool as follows:
[root@fedora-serverA ~]# yum -y install postfix
Once the command runs to completion, you should have Postfix installed. Since
Sendmail is the default mailer that gets installed in Fedora and Red Hat Enterprise Linux
(RHEL) distros, you will need to disable it using the chkconfig command and then
enable Postfix.
[root@fedora-serverA ~]# chkconfig sendmail off
[root@fedora-serverA ~]# chkconfig postfix on
Finally, we can flip the switch and actually start the Postfix process. With a default
configuration, it won’t do much, but it will confirm whether the installation worked as
expected.
[root@fedora-serverA ~]# service sendmail stop
[root@
fedora-serverA ~]# service postfix start
Installing Postfix via APT in Ubuntu
Postfix can be installed in Ubuntu by using Advanced Packaging Tool (APT). Ubuntu,
unlike other Linux distributions, does not ship with any MTA software preconfigured
and running out of the box. You need to explicitly install and set one up. To install the
Postfix MTA in Ubuntu, run the command
yyang@ubuntu-serverA:~$ sudo apt-get -y install postfix
The install process will offer a choice of various Postfix configuration options during
the install process. The choices are
 ? No configuration This option will leave the current configuration unchanged.
? Internet site Mail is sent and received directly using SMTP.
? Internet with smarthost Mail is received directly using SMTP or by running a
utility such as fetchmail. Outgoing mail is sent using a smarthost.
? Satellite system All mail is sent to another machine, called a smarthost, for
delivery.
 ? Local only The only delivered mail is the mail for local users. The system does
not need any sort of network connectivity for this option.
We will select the first option, No configuration, on our sample Ubuntu server. The
install process will create the necessary user and group accounts that Postfix needs.
With the script in place, double-check that its permissions are correct with a quick
chmod