Electronic Mail has existed in one form or another as far back as the 1960’s. People would leave messages for one another using a number of different methods on mainframe computers but it wasn’t until August 1982 when the Information Sciences Institute published The Simple Mail Transfer Protocol (SMTP; RFC 821) that a standardized method for sending and receiving email was proposed.
SMTP quickly became popular on the ARPANET, replacing older more complicated methods used to move mail from one mainframe to another, and was first supported in late 1982 by the early Mail Transfer Agent Sendmail in BSD 4.1c.
The protocol has been revised and extended fairly regularly since that time but the fundamental method for sending mail has largely remained unchanged.
The protocol is a text based protocol, originally not supporting the delivery of binary data. However being text based made the protocol easy to implement and maintain. MIME (Multipurpose Internet Mail Extensions) became popular in the late 80’s for encoding and sending binary data via SMTP. Today SMTP is the dominant protocol for sending and receiving email on the internet and detained knowledge of this protocol is essential for any network administrator.
As SMTP is text based, learning the protocol is significantly easier than many others and a program capable of sending ASCII data over TCP/IP port 25, such as Telnet, is all that is required to communicate directly with an SMTP server.
Mail is sent via SMTP in a transaction, that is if the sending of the message does not complete in full and without generating an error the message is dropped. RFC 821 Describes a transaction as having three stages: specifying a sender, provide one or more recipient(s) and then send the message itself. However it is easier to think of an SMTP transaction as 5 stages:
- Send Reply address
- Send Recipients
- Send Message Data
- End Transaction
Upon connecting to an SMTP server on port 25 the sender of a message must wait for the receiver to accept the connection and identify itself in the following format:
220 [domain] [Service Information]
Example: 220 example.com Service ready
The sender must then identify itself to the receiver using the HELO command.
Example: HELO example.com
The mail servers will expect each one to identify itself using a domain name which could be used to verify the identity of the server by performing an MX record lookup, however the receiving server must not reject the connection at this stage even if the identity of the sender cannot be verified and so must reply with:
Example: 250 example.com Hello bob at example.com
Reply code 250 is the generic ‘OK’ response from an SMTP server to say the last action completed successfully.
Send Reply Address:
Once the two servers have performed their handshake the SMTP transaction has started and we can begin sending commands to the server. If you would like to see the commands supported by the server send the command HELP and the SMTP server should respond with a message detailing which commands are supported.
For us to send a message to a user on this server though we must first set a reply address. The reply address must be provided first so that if there are any errors during the SMTP transaction the can be reported to this address. To do this we use the command ‘MAIL FROM:’:
Example: MAIL FROM:
Note the Less than and Greater than characters. These are required by RFC 821 to contain the email address itself. If the address is accepted SMTP will return a 250 OK reply.
After setting a reply address SMTP will allow us to identify the recipients of the message. To do this we use the ‘RCPT TO:’ command:
Example: RCPT TO:
To set multiple recipients simply repeat this command for each recipient.Should the receiver accept mail for this user and can accept the message at this time it should reply with a 250 OK reply. However if mail is not accepted for this user a 550 failure reply will be sent or the appropriate error code. Should we receive a 250 OK reply we can continue on to sending the message data.
Send Message Data
Sending data via SMTP is quite simple however message formats can be quite complicated, especially so when sending binary attachments. To start sending data we should issue the command ‘DATA’ to which the server should reply with 354 Intermediate reply. i.e.:
354 Enter message, ending with “.” on a line by itself
The simplest message we can send is a plain text message which does not require us to use the multipart MIME message format. All messages, plain text or otherwise, are ended by sending a line containing only a period character. Also before a message is sent you may send some header information such as Date, Subject, To, Cc and From.
354 Enter message, ending with “.” on a line by itself
Subject: This is the subject line of the plan text message
And this is the message body of the plain text message.
If accepted the SMTP server will return a 250 OK reply or an error code if the transaction has failed or was incomplete. Note the period character at the end of the line of the message body, it is only when a period character is found on a line on its own that the server will stop listening for data. Should the sender server be sending a message that would cause the data session to close prematurely it as the message contains a single period character on a line it should add an additional period character to the line.
Ending the transaction
Up until this point everything that has been sent to the receiving SMTP server is considered to be disposable. If the command ‘QUIT’ is not sent before the connection closes the destination server will simply delete any message data that has been stored. Originally used as a graceful way to close a connection it is commonly used today to represent a completed transaction with many mail servers waiting for the QUIT command before queuing the mail for the Message Transfer Agent to route. Once you have sent the QUIT command the destination server should send a 221 Reply to confirm the transaction has completed and the connection is closing.
If you are learning the SMTP protocol you are advised to read RFC 821, 2476 and 2554. You should remember, especially when reading RFC 821, that since 1982 Email servers have changed significantly partly in response to abuse by spammers.