The base SMTP protocol is defined in RFC 5321.

SMTP is the Internet protocol which is used on the internet for sending email from one computer to another. It is widely known as the protocol used when individuals send messages from their email client (or MUA - Mail User Agent) to their own (or their ISP's) mail server (or MSA - Mail Submission Agent), but it is also used for mail servers (or MTAs - Mail Transfer Agents) to send messages between each other.

SMTP is a relay protocol; messages are passed along a chain of mail servers like a baton in a relay race. Once the receiving server has acknowledged receipt of the message, the sending software has to assume it will be delivered or a delivery status notification message will be returned to the sender. The sending software has no way of finding out what happened to the message once it was acknowledged by the receiving server.

Types of SMTP

There are two 'types' of SMTP server, but they are very closely related and use mostly the same commands so the roles can be combined. An MTA is used for sending mail from one server to another. This MUST use TCP port 25 for transmission and can support negotiated 'STARTTLS' encryption. An MSA is used for a user to send mail to (and will typically then send the message to an MTA). These usually use TCP ports 25 or 587, they may occasionally use port 465 if they use an old method for encrypting traffic. An MSA should require SMTP authentication and encryption, an MTA must not require authentication (or other servers won't be able to send mail to it because they won't know any authentication details) and must not require encryption (to allow receiving messages from older MTAs which may not support encryption). It is possible for software to listen only on port 25 and behave like an MSA if authentication is used or an MTA if it isn't.

SMTP authentication

SMTP authentication is optional in the protocol. Most well configured SMTP servers will require some form of authentication to be able to send outgoing mail (otherwise the server is in a state known as 'open relay' which is BAD THING), but MTAs will not require authentication for incoming mail to local recipients.

There are three forms of authentication used in SMTP:

•The oldest is authenticating by looking at the sender's IP address. ISPs will often only allow the use of their SMTP servers by customers who are on one of that ISP's IP addresses.

•Then there is 'POP3 then SMTP' authentication. This was often used before 'proper' SMTP authentication was available. In this method the user has to collect mail using POP3 first, then the ISP's server will remember that user's IP address for a few minutes so they can send mail from the same IP address immediately after checking for mail.

•"Proper" SMTP authentication was finally added to the SMTP protocol in 1999 (SMTP itself has been around since 1982). This allows the user to log in using a username & password. Most MSAs and MUAs support this type of authentication nowadays. The login details can be sent in plain text (AUTH PLAIN or AUTH LOGIN) or encrypted using a one-way hash (AUTH CRAM-MD5).

SMTP Data

In an SMTP transaction there are two parts of data:

•The first is the SMTP Envelope - like a normal mail envelope, this contains the sender's address ('return path') and the recipient(s) address(es). Normally when the message is delivered into a mailbox (e.g. POP3 or IMAP4) then the SMTP Envelope is discarded so the recipient cannot see it.

•The second part is the Message Data - this contains the message content itself (like the letter in a normal mail item). This may or may not contain the sender and recipients, or may even contain different sender and recipient addresses from the envelope, but these addresses are not used for routing messages.

 

The 'return path' for a message is notionally where it came from. This is actually used as the email address to send bounce (delivery failure) messages to. Note that it is trivial for a sender to forge the return path (or any of the message content) so it cannot be used for authentication. A special case return path is a blank one. This indicates that bounce messages should not be generated. Typically this will be used with automated messages such as bounce messages or autoresponder messages because you do not want to generate bounce messages in response to bounce messages or you can end up with a bounce message loop.

 

To help with diagnosing problems, an important part of SMTP is that each MTA which the message passes through will add a line beginning with Received: to the top of the message. This means that you can read the Received: headers from the bottom upwards to see the path the message took to reach you (however, note that it is possible for the earlier header lines to be forged by the sender).

 

A sample SMTP session might go like this:

220 mail.example.com ESMTP server ready

EHLO mail.domain.com

250-Hello mail.domain.com, I'm pleased to meet you

250-AUTH PLAIN CRAM-MD5

250-SIZE 10000000

250-STARTTLS

250 HELP

MAIL FROM:<bob@domain.com>

250 OK

RCPT TO:<joe@example.com>

250 OK

RCPT TO:<katy@example.com>

550 Recipient not recognised

RCPT TO:<kate@example.com>

250 OK

DATA

354 End data with <CR><LF>.<CR><LF>

Subject: test message

From: Bobby Tables <bob@domain.com>

To: joe@example.com,katy@example.com,bill@example.com

 

This is a test message

.

250 OK - queued as 6234efgge9gwkwe6d

QUIT

221 Bye, see you later

 

ETRN and ATRN

SMTP is a 'push' protocol where messages are pushed from the sender to the recipient (unlike POP3 & IMAP4 where the recipient goes and collects the messages). In some situations a push protocol doesn't work well, such as when the recipient has an intermittent Internet connection.

The ETRN (Extended TuRN) and ATRN (Authenticated TuRN) commands were designed to allow SMTP to work in these situations. The mechanism that uses ATRN is also known as ODMR (On-Demand Mail Relay).

VPOP3 supports both ETRN and ATRN/ODMR connections. The ISP has to support them as well for them to be used.

 

With ETRN, the recipient sends an ETRN command to an SMTP server which tells that server (or a related server) to start sending messages for the specified domain to an SMTP server on a known IP address. There is no authentication in this case because the messages are sent to a known IP address linked to the domain. There are two SMTP sessions in this case

ETRN Session 1

Client C1 at the user connects to server S1 at the ISP

C1 > ETRN mydomain

S1 < 250 OK queuing started

C1 > QUIT

S1 < 250 Goodbye

ETRN Session 2

Client C2 a the ISP connects to server S2 at the user (note the other way around from Session 1) and sends mail using SMTP as for a normal SMTP session.

 

With ATRN, the recipient logs into the remote SMTP server using SMTP authentication and then sends an ATRN command. Now, the same session switches modes, so the SMTP client becomes the server and the SMTP server becomes the client. This will work with dynamic IP addresses because the session has been authenticated and there is only a single session.

ATRN Session

Client C at the user connects to server S at the ISP

C > EHLO client.com

S < 250-myisp.com

S < 250 ATRN

C > AUTH LOGIN <login details>

S < OK

C > ATRN mydomain.com,mydomain.org

S < OK now reversing the connection                                - from now on the server acts as the client and the client acts as the server

C > 220 client.com ready to receive mail

S < EHLO myisp.com

C > 250 client.com

S < MAIL FROM:<...>

etc - standard SMTP session now, but with 'S' sending the commands and 'C' responding