Subscribe to our Newsletter. The latest news and articles delivered to your Inbox!
A Software Development Consultant with over 20 years of experience. Many of his projects involved Exchange integrated applications, including a FAX server, a mail security product and anti-spam products.
Telnet allows submitting emails to any SMTP server manually. Stepping through the SMTP protocol is an excellent opportunity to test and troubleshoot an email server. Here is what any email administrator should know.
The Simple Mail Transfer Protocol SMTP defines a command/reply sequence allowing the transport and delivery of emails. This de facto standard is defined by RFC2821 and is probably one of the most fundamental to email administrators. A good understanding of SMTP can be very useful especially when testing and troubleshooting email delivery.
We shall see how to connect directly to the Exchange SMTP server and submit an email. In a second article we will put this knowledge into practice and test/troubleshoot various Exchange features.
SMTP is a text based protocol. Commands and responses are transmitted in US-ASCII text. Establishing an SMTP connection is a simple matter of running:
telnet <host> 25
Telnet attempts to establish a connection to port 25 on the server identified by <host>. Port 25 is the standard port to which SMTP servers listen for inbound connections. The port number is configurable from the Exchange SMTP virtual server properties. However this is only done in very particular configuration scenarios.
The host may be identified by name or IP. When connecting to an SMTP server running on the same machine, localhost could also be used. Using a host name may sound simpler. However this involves an extra name resolution step in order to obtain the IP. Thus specifying the IP at the command line is the most direct way to connect.
Once connected, Exchange greets us with a successful response. SMTP responses start with a 3 digit code. The leading digit is the most interesting to us as summarized below.
2xx and 3xx - operation successful
4xx - temporary error, the server failed to handle the command at this time
5xx - permanent error
When troubleshooting, error responses are the most interesting. 4xx codes indicate that we may want to retry submitting the email at a later time. The receiving server might recover from its failure state and handle it. On the other hand there is no hope for emails rejected with a 5xx code.
Once connected, we may proceed to submit our first command. Exchange supports the Extended SMTP (ESMTP) specifications; hence this will be the EHLO command:
EHLO takes the fully qualified sending domain as parameter. Exchange returns a sequence of success responses listing supported extensions. These are beyond our scope.
We next submit the MAIL command:
This identifies the sender address. Exchange responds, letting us know the sender is ok.
It is now time to identify the email recipients. This involves submitting an RCPT command for each recipient address.
In this case I am submitting the email to two recipients. Thus I submit two RCPT commands, to which Exchange responds successfully.
We are now ready to submit the email content. The server is alerted of this through the DATA command.
The server responds showing it is now waiting for the email content. All the text entered at the console will add up to it. This goes on until a special character sequence is entered:
<CRLF> stands for carriage return line feed. This is what you get when hitting the Enter key. Thus the end of data marker is simply a line containing only a period.
The content of a simple SMTP email is composed of a bunch of headers followed by the body text. This is covered in the RFC 2822 specifications. More complex content including attachments and an HTML body are typically submitted with the help of MIME encoding. The MIME specifications are covered by yet another set of RFCs. However this is again beyond our scope. So we just limit ourselves to the most popular email headers (From, To, Subject) and a simple text body:
From: Sender <firstname.lastname@example.org>
To: <email@example.com>, <firstname.lastname@example.org>
Subject: Telnet Port 25
This is a test email
Headers start with a name immediately followed by a colon. Note the empty line following the subject header. This indicates the beginning of the body text. If missing, Exchange will normally still be able to identify the correct body start position. Also note the final period indicating the end of content data.
When performing a simple test, we don't really need to remember any syntax rules for the email body. We could have easily just entered:
Exchange will still be able to deliver this. Just be ready to seem some "less than perfect" emails at the recipient mailbox.
On detecting the end of data sequence the SMTP server queues the email for delivery. We could now submit another email starting straight from the MAIL command. When ready the QUIT command closes the connection.
This completes submitting an email in a scenario where everything is plain sailing. However, as we shall see in an upcoming article, things get more interesting when testing an email rejection or when verifying our Exchange configuration.
From this discussion we have the opportunity to highlight an important point that tends to confuse some email administrators. In this SMTP session we specified the sender address twice, first at the MAIL command and next at the From content header. The same goes for recipient addresses. We had the same addresses on submitting RCPT TO and the To content header.
An SMTP server is only concerned with addressing information delivered through MAIL and RCPT protocol commands. It does not interpret any addressing information within content headers. Headers are what email clients see and display at their interface.
Indeed the email headers could contain anything. Legitimate email sources will typically provide consistent addressing data. However spammers often jumble these in all manners. What has to be valid are the recipient addresses specified by the RCPT protocol commands since these determine the destination mailboxes. This means that what email clients show may be completely unrelated to what an SMTP server operates on.
Today we looked at the basics of SMTP and used telnet to submit an email. We focused on the bare essentials that are most important in everyday use. For a thorough understanding of SMTP it is best to check RFC2821. Watch out for an upcoming article that will use telnet to test various Exchange 2003 features.
RFC 2821 - Simple Mail Transfer Protocol
RFC 2822 - Internet Message Format
Add New Comment...