Foundations of Python Network Programming

Chapter 13 ■ SMtp

242

the SMtp prOtOCOL

purpose: deliver e-mail to a server

Standard: rFC 2821

runs atop: tCp or tLS

port number: 53

Libraries: smtplib

But for all of these early users, the network was not even involved in the simple task of e-mail submission; after
all, the e-mail client and the server were on the same machine! The actual means of bridging this small gap and
performing e-mail submission was a mere implementation detail, usually hidden behind a command-line client
program that came with the server software that knew exactly how to communicate with it. The first widespread
e-mail daemon, sendmail, came with a program for submitting e-mail called /usr/lib/sendmail.
Because the first-generation client programs for reading and writing e-mail were designed to interact with
sendmail, the e-mail daemons that have subsequently risen to popularity, like qmail, postfix, and exim, generally
followed suit by providing a sendmail binary of their own (its official home is now /usr/sbin, thanks to recent file
system standards) that, when invoked by the user’s e-mail program, follows that specific e-mail daemon’s own
peculiar procedure for getting a message moved into the queue.
When an e-mail arrived, it was typically deposited into a file belonging to the user to whom the message had
been addressed. The e-mail client running on the command line could simply open this file and parse it to see the
messages that were waiting for the user to read. This book does not cover these mailbox formats, because its focus is
on how e-mail uses the network. If you are curious, however, you can check out the mailbox package in the Python
Standard Library, which supports all of the strange and curious ways in which various e-mail programs have read and
written messages to disk over the years.

The Rise of Clients

The next generation of users to begin using the Internet was often not familiar with the idea of a command line. Users
were skilled in the use of the graphical interface of the Apple Macintosh—or, when it arrived later, the Microsoft
Windows operating system—and they expected to accomplish things by clicking an icon and running a graphical
program. Thus a number of different e-mail clients were written that brought this Internet service to the desktop.
Mozilla Thunderbird and Microsoft Outlook are only two of the most popular of these clients still in use today.
The problems with this approach are obvious. First, reading incoming e-mail was transformed from a simple
task for your e-mail program—which had previously been able to open a local file and read it—to being an operation
that now required a network connection. When you opened your graphical e-mail program, it somehow had to reach
across the Internet to a full-time server that had been receiving e-mail on your behalf while you were away, and bring
the e-mail down to the local machine.
Second, users are notorious for not properly backing up their desktop and laptop file systems, and clients that
downloaded and stored messages locally thereby made those messages vulnerable to obliteration when the laptop
or desktop hard drive crashed. By contrast, university and industrial servers—despite their clunky command lines—
usually had small armies of people specifically tasked with keeping their data archived, duplicated, and safe.
Third, laptop and desktop machines are usually not suitable environments for an e-mail server and its queue of
outgoing messages. Users, after all, often turn their machines off when they are done using them, disconnect from the
Internet, or leave the Internet café and lose their wireless signal. Outgoing messages generally need more than a few
moments online to finish their retries and final transmission, so completed e-mails need some way to be submitted
back to a full-time server for queuing and delivery.