SMTP Interactive Testing

Back to top

What is SMTP?

SMTP (pronounced as separate letters) is short for Simple Mail Transfer Protocol, a protocol for sending e-mail messages between servers. Most e-mail systems that send mail over the Internet use SMTP to send messages from one server to another. Most commonly when people are referring to an SMTP server a more generic term can be used which is Mail Transport Agent (MTA). MTA's are usually programs like Postfix and Sendmail.

The other generic term used with SMTP is Mail User Agent (MUA) which refers to a client program like Outlook or Pine. This is typically what a user would use to interract with an SMTP server. In this guide we are looking more at the MTA aspect and things that an administrator would be testing and verifying.

This guide assumes that you already know the SMTP server's IP address and port that you wish to test. This guide is not going to cover the understanding of DNS MX records and TCP/IP ports.

Back to top

Connecting to the SMTP Server

One of the most powerful tools to check all types of things on servers is the use of telnet with the port number of the daemon or service. The IEEE defined port for SMTP is 25, and all Internet accessible SMTP server should be listening on port 25 for connections.

Below is an example of what a typical initial connection would look like:
The arrows denote messages from the server (<--) and commands sent to the server -->)

user@host ~ $ telnet smtp1.google.com 25

<--	Trying 216.239.57.25...
<--	Connected to smtp1.google.com.
<--	Escape character is '^]'.
<--	220 smtp.google.com ESMTP
-->	quit
<--	221 2.0.0 smtp.google.com closing connection
<--	Connection closed by foreign host.

In the next sections we will break down the parts of this connection.

Back to top

Standard SMTP Command / Response Format

Back to top

The first three lines (not including the telnet command) are all from the telnet program. The initial Banner / Greeting from the SMTP server is the line 220 smtp.google.com ESMTP

While all servers will have some variant on this, they should have at the very least, the above three items.

  • Server Response Code (220)
  • Server/Host Name (smtp.google.com)
  • Server Capabilities (ESMTP)

The response code will be discussed in the next section, so we will skip that for now. The "hostname" in this portion is not the same as what we used to telnet to. Many times this is just a generic host or sometimes a cluster name. In all it's not very important in most cases. The "server capabilities" is used by the initiating server to determine what feature set the receiving server supports. In this case it's ESMTP which is Enhanced SMTP. In almost all modern SMTP server this will be the case, rarely you may encounter just SMTP, but not likely. The basic difference is that ESMTP has additional security, authentication and other commands designed to save bandwidth and protect servers.

Back to top
Response Code

The server response codes are broken into three major groups and have the same general meaning across all command. They are:

  • 2xx - Command accepted / good
  • 4xx - Soft error. Command problem, but you may need to try again later
  • 5xx - Hard error. Command failed or was rejected.

As you can see the server reponded with a 220 message, so the inital greeting was accepted. Other possibilities could be a 4xx based command when a server had too many connections at that point in time, which the sending server should queue the message and try deliverly later. A 5xx command would indicate that the server was not accepting any connections and the sending server would bounce the message back immediately.

In almost all cases the numeric command should have a human readable portion after it. This is typically a short message that will help an administrator in determining a problem. A very typical case would be a 5xx message stating that a recipient's mailbox was full.

Typically the XX portion is fairly uniform across all Email servers, but can differ slightly. You may need to consult with your SMTP server software for specific details.

Back to top

Basic SMTP Commands

These are commands that work with both SMTP and ESMTP servers, here is an example of them in use to send a very basic test message:

user@host ~ $ telnet smtp.recipient-domain.com 25

<--	Trying 192.168.1.1...
<--	Connected to smtp.recipient-domain.com.
<--	Escape character is '^]'.
<--	220 smtp.recipient-domain.com ESMTP service ready
-->	HELO sender-domain.com
<--	250 smtp.recipient-domain.com
-->	MAIL FROM: <sender@sender-domain.com>
<--	250 Ok
-->	RCPT TO: <recipient@recipient-domain.com>
<--	250 Ok
-->	DATA
<--	354 End data with <CR><LF>.<CR><LF>
-->	Test
-->	.
<--	250 Ok: queued as 927B06804
-->	QUIT
<--	221 Bye
<--	Connection closed by foreign host.
Back to top
HELO

HELO domain.com - is expected by most all SMTP servers you connect to before they will allow any processing of Email. It is usually used for logging information so the receiving server knows the sending server.

Back to top
MAIL FROM

MAIL FROM: <user@domain.com> - This command is used to specify the sender's Email address. It cannot be omitted, and in many cases is used by the SMTP server to conduct several tests to determine if the message it to be accepted.

Back to top
RCPT TO

RCPT TO: <user@domain.com> - This command is used to specify the recipient's Email address. It cannot be omitted, and in many cases is used by the SMTP server to conduct several tests to determine if the message it to be accepted. Most commonly, it's used to determine if the recipient is valid so that our SMTP server isn't being used as an Open Relay.

Back to top
DATA

DATA - is used to signify that the following information is the actual message we wish to send. The end of the DATA block is indicated by a single period on it's own line. Technically, the end of the DATA block is <CR><LF>.<CR><LF>.

Back to top
QUIT

QUIT - is used to tell the SMTP server that the transaction is complete and to close the TCP/IP connection.

Back to top

Advanced SMTP Commands

Back to top
EHLO

EHLO domain.com - can be used in place of the HELO command provided the SMTP server supports ESMTP. The construct is the same, but it signify's that the sending server may wish to use the advanced features of ESMTP.

Typically after issuing this command, you should receive a list of features that the receiving server supports like below.

user@host ~ $ telnet smtp.domain.com 25

<--	Trying 192.168.1.1...
<--	Connected to smtp.domain.com.
<--	Escape character is '^]'.
<--	220 smtp.domain.com ESMTP service ready
-->	EHLO recipient-domain.com
<--	250-smtp.domain.com
<--	250-PIPELINING
<--	250-SIZE 10240000
<--	250-ETRN
<--	250-AUTH LOGIN PLAIN
<--	250-AUTH=LOGIN PLAIN
<--	250 8BITMIME

Back to top

AUTH LOGIN

AUTH LOGIN - This command is most commonly used by an MUA to authenticate a user that may not be on your network. For example, if you have a roaming CEO that is at Starbucks and he wants to send Email. He is not on your IP range, so you should require him to Authenticate first. This allows your users to send Email, and your server to no be an open relay for SPAM.

Here is a typical AUTH LOGIN session with SMTP:

user@host ~ $ telnet smtp.domain.com 25

<--	Trying 192.168.1.1...
<--	Connected to smtp.domain.com.
<--	Escape character is '^]'.
<--	220 smtp.domain.com ESMTP service ready
-->	EHLO domain.com
<--	250-smtp.domain.com
<--	250-PIPELINING
<--	250-SIZE 10240000
<--	250-ETRN
<--	250-AUTH LOGIN PLAIN
<--	250-AUTH=LOGIN PLAIN
<--	250 8BITMIME
-->	AUTH LOGIN
<--	334 VXNlcm5hbWU6
-->	am9lQGRvbWFpbi5jb20=
<--	334 UGFzc3dvcmQ6
-->	bGFtZXBhc3N3b3Jk
<--	235 Authentication successful
-->	QUIT
<--	221 Bye
<--	Connection closed by foreign host.

If we concentrate on the parts after "AUTH LOGIN", we see the server responded to us with "334 VXNlcm5hbWU6". The garbage after 334 is a Base64 Encoded message. If you use the decoder on the string you will see that VXNlcm5hbWU6 = Username:

The server is telling us that it expects us to send the Username which we do so on the next line. The string is the Base64 encoded username. (I'll leave it to you to decode it and see the name.)

The next 334 message is asking for the password, and likewise we respond with the encoded password.

If everything was correct, we get the "235 Authentication successful" message.

Back to top
AUTH PLAIN

AUTH PLAIN base64_encoded_string - This command is very much like AUTH LOGIN, but does not provide the interactive prompts for username and password. The base64_encoded_string is in the form of: "authorize-id\0authenticate-id\0password".

In most cases the authorize-id and authenticate-id will be the same. So if we has user "john" with password "fooblah", our string would be: john/0john/0fooblah which would encode into "am9obgBqb2huAGZvb2JsYWg=". Note the \0, which are NULL's seperating the parts of the string. In testing, make sure that your Base64 encoder supports them like mine does. You could spend hours trying to figure out why it's not working because many Base64 Encoders on the Internet do not support the \0 character.

Here is what an AUTH PLAIN session would be like:

user@host ~ $ telnet smtp.domain.com 25

<--	Trying 192.168.1.1...
<--	Connected to smtp.domain.com.
<--	Escape character is '^]'.
<--	220 smtp.domain.com ESMTP service ready
-->	EHLO domain.com
<--	250-smtp.domain.com
<--	250-PIPELINING
<--	250-SIZE 10240000
<--	250-ETRN
<--	250-AUTH LOGIN PLAIN
<--	250-AUTH=LOGIN PLAIN
<--	250 8BITMIME
-->	AUTH PLAIN am9obgBqb2huAGZvb2JsYWg=
<--	535 Error: authentication failed
-->	QUIT
<--	221 Bye
<--	Connection closed by foreign host.

In this case "fooblah" was not the password for user "john", so the server gave us a hard 5xx error letting us know something is wrong.

Back to top
Others

There are several other types of authentication encryption schemes supported, most notably is MD5. At this time I have not worked with MD5 as a method to authenticate with. If I have occasion to figure it out, I'll add it to this guide. In most cases if the AUTH LOGIN and AUTH PLAIN work, then the MD5 will as well.

There are other features in ESMTP, but this guide's intention is to cover common items that someone will need to test and troubleshoot an Email server. Please see the related links at the end for more information.

Back to top

Proper Message Body Format

In all of our test cases we simply entered "Test" in as our message body. While most servers will accept this, and it should be sufficient for our testing purposes, it is not the proper format of a message. A properly constructed DATA block should be:

From: "John Smith" <john@sender.com>
To: "Jill Johnson" <jill@recipient.com>
Subject: Test

This is a test message.
.

Note the space between the Subject line and the start of the message. This is expected by most servers, and how they tell the difference from the header and body portions of the message.

Back to top