SMTP 101

Email as we understand it now started on single mainframe computers in the mid-1960s.  At that time computers were not linked to each other and users used dumb terminals to run applications on the mainframe.   The first email applications were really simple local file sharing, where users deposited text messages in an email folder owned by the recipient.  Early mail programs were SNDMSG and MAILBOX.

Email was therefore limited to users on the same mainframe computer. 
The growth of computer networks meant the post problem became a little more complex - a message needed to go into an envelope, addressed and sent.  The recipient need not be on the same computer anymore.  So, the first issue was to locate and uniquely identify the recipient. ARPANET and Ray Tomlinson fixed that.  Ray Tomlinson defined email addresses to be of the form user@computer.  Something we still use today.  

The first universal email systems were based on the existing paper mail systems and were in effect a store-and-forward system using the Post Office Protocol3 ("PoP3") and Simple Mail Transfer Protocol ("SMTP") standards.   

Using the Tomlinson address structure, networking software would use SMTP software to forward the message to the receiving computer where the PoP3 software would receive the message for the recipient.  The steps in between were handled by standard networking relay techniques. 
SMTP underwent a parallel development.  It had its first formal specification in RFC 821 in 1982, with revisions and extensions over the years.  The last update was in 2008 when some SMTP extensions were defined in RFC 5321.  The 2008 specification is the one in current use. 

It must be clearly understood that SMTP defines message transport, not the message content. It defines standards for the structure of the mail envelope and its associated parameters but that is all.  Specifically, it does not specify the composition of the message header nor the contents of the message itself. 
The first step after the user creates an email message usually with an email client like Outlook, addresses it, and hits the send button is that the email client submits the message to the mail server defined in the user settings. The settings include the address of the server, logon information, the security protocol to be used and the port on which the server expects to receive the mail.  Traditionally, port 25 was the SMTP port.  However, various security protocols require the use of a different port, often 465 or 587.   In the corporate environment, another port may be used as a security measure to ensure that only locally created mail can be sent.

The mail server is actually made up of two applications, a Mail Submission Agent (“MSA”) and a Mail Transmission Agent (“MTA”).   They may be combined in a single program, split into two separate applications running on the same server, or split over several servers in the largest environments. 
The MTA looks up the IP address of the intended recipient server (the bit after the @) using DNS and using accepted network protocols creates a route to that address.  In most instances, the first recipient may not be the final recipient, with the message routed through a series of intermediate MTA servers in a number of hops.   At each stage of the journey, the MTA must report success or failure of delivery of the message.  

At the final recipient, the MTA hands over the message to a local Mail Delivery Agent (“MDA”).  The MDA receives and processes the message, adding it to the user mailbox where it waits for collection by an email client or to be read and processed online. 
It must be clearly understood that standard SMTP is a push service.  As mail arrives, it is immediately pushed onto the next MTA.  The next MTA can be the final destination server or the next server in a mail hop sequence. 

A significant problem with early implementations of SMTP was security at both the MSA/MTA level and at an individual user level. 
A major problem is that of an open relay sending or relaying spam mail.  If an SMTP server does not operate any access restrictions and will send or relay any and all mail, then it is called an open relay.  Most spam mail is sent via open relays and many spam senders have robots continually searching the Internet for open relays they can use.   Blacklisting agencies like ORBS and RBL maintain a list of open relays and most servers will refuse to handle mail coming from blacklisted servers. 
There are several techniques for preventing blacklisting and becoming an open relay:

Restrict access by location.  In this variant, only mail clients with an IP address known to the server are allowed to use the MSA/MTA.  This is accomplished in Microsoft Exchange for example by specifying that only local or specified IP addresses are allowed to send or relay mail.  This can be a problem for mobile users where they connect to an ISP or the company network from a variable or unknown location. Their IP Address is therefore not a valid address and they may find that they cannot send mail. 

This technique has been largely supplanted by client authentication.  In this scenario, an email client needs to provide a user id/password pair to be able to connect to the MSA/MTA.   This resolves the mobile user issue. 

One other area is the use of security protocols such as SSL and TLS in SMTP.  These protocols are transport layer protocols in which messages use cryptographic protocols to secure messages during transport over the Internet.   These strictly speaking are not part of SMTP, but most clients and servers support their use and the SMTP server may require that they are used.  They usually require the use of a dedicated port.  

There are other client add-ons that provide email security.  The most popular implement a PGP interface that encrypts email according to a public/private key pair. They generally do not mean an alteration to the SMTP server but may require the use of a specific port. 

Email Server Software