The Simple Mail Transfer Protocol (SMTP) is a TCP/IP based protocol designed to send and receive email. Since the protocol is limited in the ability to store or queue incoming messages, it is typically used alongside IMAP or POP3 to allow the end-user to save messages in an email server mailbox to be downloaded from the server on demand. As a result, SMTP is primarily used by consumers to send email and IMAP or POP3 for receiving email. Sendmail was the original package used with a built-in POP3 server on Unix-based computing system while Microsoft Exchange includes a SMTP server that supports dual-use of POP3 for incoming mail. On today’s email servers, ESMTP (Extended Simple Mail Transfer) is commonly deployed to support multimedia file delivery as part of email.
SMTP History
There were a number of electronic message systems used during the 1960s. During this timeframe, individuals would electronically communicate with systems that were designed for specific models of mainframe computer. As the number of computers that were interconnected grew to include the United States Government’s ARPANET, communication standards were created to allow users of different system design to communicate with other end-users. The Simple Mail Transfer Protocol grew from the original work on email standards during the 1970s.
More specifically, SMPT’s history is based on early protocol implementations in 1971: the Mail Box Protocol and the SNDMSG program. The Mail Box Protocol was discussed in RFC 196 along with other standards write-ups, while SNDMSG was described in RFC 2235 and was created to allow TENEX computers to transmit messages to other computers on the ARPANET. At the time, there were less than 50 computer hosts connected to the ARPANET.
Additional email protocol implementations of the time include the Mail Protocol and FTP mail in 1973. Throughout the 1970s, work would continue on email protocols until the ARPANET grew to what we know as the modern Internet now in 1980. In 1980, Jon Postel proposed a Mail Transfer Protocol that removed email’s reliance on the FTP standard. In November of 1981, Postel published SMTP as RFC 788.
Early Problems with SMTP
When Postel published the SMTP specification, the Internet was relatively small when compared to what we know the World Wide Web to be today. The web primarily consisted of universities, corporate research labs, and military installations during this timeframe with slow and many times, unreliable connections. The total number of computer hosts at the time was small enough that it was still possible for all computer hosts to recognize one another. As a result, SMTP focused on reliability vice security and helped contribute to the widespread adoption of the protocol.
During this same timeframe, most SMTP users would attempt to help one another by configuring their mail servers as “open relays.” This would allow each email server setup as a relay to forward mail onward to its ultimate destination. As a result of the relay capability, the reliability of email delivery significantly increased.
Just a few years prior to the publication of SMTP in1978, the first documented instance of spam from a DEC sales representative. He sent an announcement of a product demonstration to several hundred recipients that were online. Despite the outcry from those who received the email, spam would become a significant problem for email users in the later portion of the 1990s as the total number of email users increased exponentially.
SMTP Protocol Overview
The Simple Mail Transfer Protocol (SMTP) is designed to be a connection-orientated protocol based on text. It supports the ability for a mail sender to communicate with a mail receiver through issuing command strings along with supporting information over a reliably ordered transmission stream. This stream is normally a TCP (Transmission Control Protocol) connection.
Simple Mail Transfer Protocol defines the message transport, but not email message content. This can be thought of as defining the email envelope and parameters but not the body of the message. Standard 5321 defines the current SMTP envelope and standard 5322 defines the email message header and body which is commonly referred to as the Internet Message Format.
Once established, the SMTP session consists of commands provided by the initiating sender or SMTP client and the SMTP server responses. Once a session is opened, the parameters are exchanged and can include zero to multiple SMTP transactions. A single transaction is defined by three command/reply exchanges or sequences. These include: 1- the MAIL command to help establish the Return-PATH (mfrom) or the return address, 2 – a RCPT command which establishes the recipient of the message. Multiple RCPT commands can be issued for mail that goes to more than one receiver and are part of the envelope, and 3 – DATA for sending the message text.
The DATA command includes the primary content of the email or message. The DATA message includes a message header and body that are separated by an empty line. Since the DATA message includes a group of commands, the email server will reply twice to it: once to the initial command and acknowledge that it is ready to receive the information, and the second time after the data-to-data sequence has been completed in order to accept or reject the entire message.
In addition to the intermediate reply for the SMTP DATA message, each mail server’s reply can either be positive or negative in response. A positive response consists of a 2XX reply code, a negative one can either be a permanent, 5xx, or transient, 4xx code. A rejection code is a permanent failure by an SMTP server. In the event of a rejection, a SMTP client must send a bounce message. A drop message is a positive response followed by a message discard.
An initiating computer host, or the SMTP client, can either be an email client on an end-user’s computer, a relay server’s mail transfer agent (MTA) acting as an SMTP client while relaying mail, or a MUA (mail user agent). A fully capable SMTP server is able to store queues of messages to resend message transmissions that have stalled from transient failures.
SMTP Ports
When SMTP is configured, the server administrator will select whether or not email clients will use TCP port 25 (SMTP or port 587 (Submission) for relaying or sending outbound email to an initial mail server. The use of port 587 was first outlined in RFC 2476 and later formalized in RFC 6409. The majority of SMTP / email related specifications include support for both ports. There are some email servers used in industry; however, which use port 465 for legacy, secure SMTP communications against the published standards.
There are some email servers that are setup to reject all email relays over port 25; however, valid end-users that have authenticated on port 587 are then allowed to relay email to any valid address. Additionally, some Internet Service Providers (ISPs) will intercept port 25 and redirect traffic to the ISP’s SMTP server independent of the ultimate destination address. This action makes it impossible for users to access SMTP servers outside of the ISP’s network by using port 25. There are some SMTP servers that will support authenticated access on alternative ports other than 25 or 587 to allow users to connect to the service even if port 25 is blocked. Port 587 has become the standardized and most widely-support port for users to submit new email.
At the time of this writing, Microsoft Exchange Server 2013 SMTP is capable of listening on ports 25, 465, 475, 587, and 2525 depending on what roles are combined on the single server. For Exchange, ports 25 and 587 are designed to allow client connectivity to the front-end transport service on the CAS (client access server) role. Ports 475, 465, and 25 are primarily used by the mailbox transport service; however when the mailbox and CAS roles are combined on a single server, port 2525 is used by the mailbox role for SMTP and CAS will continue to access port 25.
SMTP port 465 is used by the MTS to receive client connections that are proxied by the CAS role on the server. 475 is used to facilitate communications between mailbox roles and transferring mail between the mailbox transport delivery service and the mailbox transport submission service.
What is the Mail Processing Model?
In the mail processing model, email is transmitted or submitted by a MUA to a MSA (mail submission agent) using SMTP over TCP port 587. At this point, the MSA will send the mail to the designated MTA (mail transfer agent). In the majority of these instances, the two agents will be different instances of the same software application running with different options on the same computer or machine.
In the mail processing model, local processing of email can either be done on a single computer host or split amongst various computers. When the processing is accomplished on a single host, the multiple processes are designed to share files. When two or more computers are used, the SMTP protocol is used to transfer the message between the hosts. Each of these processes is considered to be a MTA or an SMTP server.
The MTA acting on the boundary is tasked with locating the designated or targeted host. It accomplishes this task by looking up the MX record (mail exchanger record) for the recipient’s domain using DNS (domain name system). The MX record that is returned will include the name of the host that is targeted. The MTA will then connect to the exchange server acting as an SMTP client.
After the designated host accepts the incoming message, the connection will be passed to the MDA (mail delivery agent) for delivery of the email. Modern MDAs are capable of saving messages in the appropriate mailbox format using one or many computers. Once an email is received, an MDA is capable of delivering messages directly to a mailbox for storage, using LMTP (Local Mail Transfer Protocol) or SMTP to deliver the message(s) on the targeted server.
After a message is delivered to the designated local mail server, the email is saved for retrieval by an authorized (aka authenticated) MUA or email client. Email can be retrieved using an application or email client using PO (Post Office Protocol) or via web interface making use of IMAP (Internet Message Access Protocol).
SMTP Transport Example
The following is an example of an email message being sent using SMTP to two mailboxes located on the same email domain. After the message sending client (SMTP client) establishes a reliable connection to the message receiver (SMTP server), the SMTP session will open with a server greeting that will include the FQDN (fully qualified domain name). The client will then initiate its dialogue using the HELO command to include its FQDN.
SMTP Server: 220 smtp.tech-faq.org ESMTP Postfix
SMTP Client: HELO relay.example.org
SMTP Server: 250 Hello relay.tech-faq.org, I am glad to meet you
SMTP Client:: MAIL FROM:<bob@tech-faq.com>
SMTP Server: 250 Ok
SMTP Client:: RCPT TO:<janice@tech-faq.com>
SMTP Server: 250 Ok
SMTP Client:: RCPT TO:<will@ tech-faq.com>
SMTP Server: 250 Ok
SMTP Client:: DATA
SMTP Server: 354 End data with <CR><LF>.<CR><LF>
SMTP Client:: From: “Will ” <will@tech-faq.com>
SMTP Client:: To: “Janice” <alice@tech-faq.com>
SMTP Client:: Cc: will@tech-faq.com
SMTP Client:: Date: Sat, 11 May 2013 19:04:55 -0100
SMTP Client:: Subject: Test SMTP message
SMTP Client:
SMTP Client: Hello Janice.
SMTP Client:: This is a test to show five header fields and four lines in the message body.
SMTP Client:: Sincerely,
SMTP Client:: Will
SMTP Client:: .
SMTP Server: 250 Ok: queued as 12345
SMTP Client:: QUIT
SMTP Server: 221 Bye
{The SMTP server now closes the connection}
In the example, the SMTP client will notify the receiver of the originating email address of the communication using the MAIL FROM command. In this example, the message is sent to two fictional mailboxes on the same SMTP server. One receiver is listed in both the TO and CC header fields. The subsequent command is RCPT TO. After each succeeding reception and execution of a command, the server will acknowledge with a result and response code.
When the body of the message is transmitted, it will be initiated with a DATA command. Then, the message is transmitted verbatim and completed with an end-of-data sequence consisting of: a new-line (<CR><LF>), a single full stop (period), and is followed by another new-line.
Since any email message body can include a line with a single period as part of the message text, the email client will transmit two periods every time that a line beings with a period. The server will then replace any sequence of two periods at the beginning of a line with a single period. This escaping method is referred to as “dot-stuffing.”
The email server’s positive reply to the indication of “end-f-data” will imply that the email server no has the responsibility of delivering the email message. If there is a communication failure during this time, the message can be delivered twice based on whether or not the message sender has received the 250 response. During this timeframe, both the sending and receiving agents have exact copies of the email message that they will attempt to deliver.
The SMTP QUIT command will end the email session. If there are multiple recipients on the message located on other web servers, the email client would QUIT and connect to the appropriate SMTP servers for the additional recipients of the message.
Follow Us!