How SMTP commands work

Published date Tue, 2006-09-26 14:10
Category
Author Nicolas Blank
Printable Version | Email this Article
Your rating: None Average: 2.5 (2 votes)
Post to del.icio.us | Furl it | Spurl it

In this article, you will learn what SMTP commands are and how to use them to test SMTP issues such as basic SMTP health, re-laying checking, SMTP versions, etc.

If we send or receive mail over the internet or using Exchange 2000 or higher, it was transported via SMTP. Knowing more about SMTP and how to troubleshoot SMTP on a basic level is essential. Tools for the job are knowledge of the command syntax and a remote terminal tool such as Telnet.

Let’s start by Telneting to port 25 of a mail host and see what comes out of it. The command syntax will be

Telnet hostname 25

If you’re running a flavor of Exchange, you may receive a reply similar to:

220 win2k3dc.target.local Microsoft ESMTP MAIL Service, Version: 6.0.3790.0 ready at Thu, 31 Mar 2005 11:35:01 +0200

I’m going to break the reply down and explain each part:

220

A status code implying that Exchange is available and listening. SMTP mail systems have to return a status code for each line of every mail conversation, which indicates anything from command received successfully, to “go away – you’re not wanted here”. Some replies may only be numbers; others may be numbers with an explanatory text. At the end of this article I have listed some more detail about the meaning of these.

win2k3dc.target.local

The hostname responsible for the service

Microsoft ESMTP MAIL Service, Version: 6.0.3790

Software responding to the service request:

ready at Thu, 31 Mar 2005 11:35:01 +0200

Note that if your machine is internet facing, it’s a really good idea to hide the response, also known as a banner. Knowing what software is installed on a machine gives a malicious person an idea as to how to start attacking. Here’s how you hide this message:

http://support.microsoft.com/kb/281224/

So what do we do now? How do we know what to type? SMTP conversations mirror human conversations in that humans greet, exchange pleasantries that help establish who we are, talk and then say goodbye. For a successful SMTP conversation to occur, something similar happens, and some of the words used may look familiar.

In SMTP talk, that may look like this:


Notice the first word after the 220 message was HELO. This could also have been EHLO. For the purposes of this article, SMTP can be presented in two basic flavors, SMTP and ESMTP. ESMTP is all that SMTP is, with some extra bits bolted on, like large message support, pipelining, authentication etc, which makes it a perfect candidate for Microsoft to build a transport mechanism around, which in fact is what they did. Most internal server to server messages originate and are received using ESMTP, not SMTP. Entering EHLO instead of HELO will produce a list of available commands that Exchange will accept, along with a “ready” message.

Each line was responded to by codes starting with a 2xx or a 5xx. Either my input was good 2xx or I entered a command that was flawed or unacceptable 5xx.

In this case, even though I’m trying to impersonate “noddy.com” my real domain is echoed back to me on the next line as: 250 win2k3dc.target.local Hello [127.0.0.1]

Let’s look at the conversation again.

HELO noddy.com

who I am- email host/domain,

MAIL FROM: dude@noddy.com

who I am – email address

RCPT TO: anotherdude@target.local

who I am mailing. Multiple recipients may be specified by using multiple RCPT lines

DATA

body of the message, including any further arguments, such as subject lines. This needs to be ended using a period “.” Followed by an empty line. Notice that extra tags such as subject: need to be followed by an empty line.

What we have achieved here is test that SMTP is up and accepting mail. To make this more interesting, test for two way communication by requesting a delivery receipt:

Change the RCPT TO line to read:

RCPT TO :anotherdude@target.local notify=success,failure

How would we test for other conditions such as relaying allowed? Simple – change the RCPT TO: line to read another SMTP address for which delivery is not enabled. Here’s an example


If your mail host is configured correctly you will receive a polite – or not so polite message saying that your mail cannot be accepted. If the opposite occurs and your mail submission is succesfull for an email domain that doesn’t isn’t part of your SMTP servers inbound domain list – you have an open relay. A SPAM target. If this is facing the internet you should fix it really soon. Like now.

Here is a basic list of commands. This list is extensive enough to test anything you’re willing to try without breaking out of Telnet and using a mail client. These were sourced from RFC 821, which may be found here: http://www.faqs.org/rfcs/rfc821.html

HELO
MAIL
RCPT
DATA
RSET
NOOP
QUIT

Some of these are not discussed above.

RSET – resets the current session, allowing you to start again.
NOOP – No Operation. Does what it says. Use this to stay connected while thinking about your next command. Prevents timeouts.
QUIT – Quits the current session and disconnects.

Common Messages are listed below, however - to get to the exact meaning of virtually any SMTP code, have a look here: http://www.faqs.org/rfcs/rfc1893.html

211 System status, or system help reply
214 Help message
220 Service ready
221 Service closing transmission channel
250 Requested mail action okay, completed
251 User not local; will forward to
354 Start mail input; end with .
421 Service not available, closing transmission channel
450 Requested mail action not taken: mailbox unavailable
451 Requested action aborted: local error in processing
452 Requested action not taken: insufficient system storage
500 Syntax error, command unrecognized
501 Syntax error in parameters or arguments
502 Command not implemented
504 Command parameter not implemented
550 Requested action not taken: mailbox unavailable
551 User not local; please try
552 Requested mail action aborted: exceeded storage allocation
553 Requested action not taken: mailbox name not allowed
554 Transaction failed


Discuss/Post to digWin

About Nicolas Blank

Nicolas Blank - Operations Director, Credo Technical Services

Nicolas Blank is a Microsoft Infrastructure Architect and Operations Director for Credo Technical Services in South Africa and specializes in Exchange, Active Directory, architecture, systems management, migration and scripting. Nicolas is a Microsoft MVP for Exchange and spends what spare time he has writing, blogging and talking about Exchange and associated technologies. www.credotech.co.za


Featured Links


Subscribe to Articles

Receive monthly article updates.

Join our Exchange forum | View forums