You Had Me At EHLO - For Techies: Troubleshooting SMTP Problems

This Microsoft article explains how to use the EHLO commands to easily find troubleshoot your SMTP services. It’s very useful for the IT administrator if they host their own exchange server or for that matter even just want to troubleshoot a third party server in case email is not working! Definitely peruse this article and I’m sure you’ll learn something interesting!

 

XFOR: Telnet to Port 25 to Test SMTP Communication

View products that this article applies to.

Article ID	:	153119
Last Review	:	December 3, 2007
Revision	:	6.6

This article was previously published under Q153119

On This Page

SUMMARY

MORE INFORMATION

Basic Testing

Advanced Testing

SUMMARY

This article describes how to telnet to port 25 on a computer that runs Simple Mail Transfer Protocol (SMTP) services to troubleshoot SMTP communication problems. The information in this article, including error messages, only applies to issues when attempting to resolve SMTP communication issues with Microsoft Exchange-based servers and is not intended for general troubleshooting purposes.

You can use the following troubleshooting steps that are appropriate for the type of problem that you are experiencing. For example, if you are having problems sending over SMTP between two of your Microsoft Exchange 2000 Server servers, you can test the SMTP connectivity by using Telnet on the sending server to connect to port 25 on the destination server. By default, SMTP listens on port 25. Alternatively, if you are having problems receiving SMTP mail from the Internet, you can follow the steps that are listed in this article to test connectivity to your SMTP server from a host that resides on the Internet and that is not on your network.

NOTE: This article only outlines information for a connectivity test for messaging with Exchange Server, if you are not able to connect to the Exchange Server, please search the KB for other symptoms or error messages you are experiencing. For additional information on troubleshooting Exchange transport issues, please refer to the following article in the Microsoft knowledgebase:

257265 (http://support.microsoft.com/kb/257265/) General troubleshooting for transport issues in Exchange 2000 Server and in Exchange Server 2003

Back to the top

MORE INFORMATION

There are several different variations of SMTP in the Microsoft product line. The Microsoft Windows product line has an SMTP service that is included with Internet Information Services (IIS), and in Microsoft Windows NT Server 4.0, the SMTP service was included in the Option Pack. In more recent versions of Windows, IIS has been integrated in the operating system, and you can add IIS by using Add or Remove Programs in Control Panel. Additionally, Exchange 2000 and Microsoft Exchange Server 2003 use the existing SMTP service from IIS with additional features. Microsoft Exchange Server versions 4.0, 5.0, and 5.5 all come with their own versions of SMTP in the form of the Internet Mail Connector (IMC) or Internet Mail Service (IMS).

Note In Exchange 5.0 and later, the Internet Mail Connector (IMC) is renamed the Internet Mail Service.

Before you start the Telnet session, you must have the full SMTP e-mail address of the destination user who you want to send this test message to. This e-mail address must be in the following format:

User@Site.Domain.com

You must also have the fully qualified domain name (FQDN) or the IP address of the server computer that is running the SMTP services (for example, 10.120.159.1). If the servers are in your organization, you may already have this information. If the servers are external, the easiest way to find this information is to use Nslookup.exe to find the DNS records that contain this information. For additional information about NSlookup, click the following article number to view the article in the Microsoft Knowledge Base:

200525 (http://support.microsoft.com/kb/200525/) Using NSlookup.exe

For additional information about obtaining Internet Mail Exchanger records, click the following article number to view the article in the Microsoft Knowledge Base:

203204 (http://support.microsoft.com/kb/203204/) XFOR: How to Obtain Internet Mail Exchanger Records

Make sure that SMTP has started on the server that runs the SMTP service. To test if SMTP has started, you can run the basic tests that are listed in this article and verify that you receive the 220 response from the remote server. This also verifies that SMTP is running.

Notes

•	Some Telnet applications require you to turn on local echoing to see the commands that you are typing. To do this while in a Microsoft Telnet session, type set local_echo at the command prompt.
•	In Microsoft Windows XP, type set localecho instead of set local_echo.

Back to the top

Basic Testing

Follow these steps to make sure that the host computer and the remote SMTP server can communicate. If you receive the following error message after you type any one of the following commands, the SMTP server does not recognize what you typed because of a syntax error or an erroneous command:

500 Command not recognized

Check the command and type it again or verify that you are communicating directly to a Microsoft SMTP server.

Note Microsoft Telnet does not permit you to use the Backspace key. If you make a mistake when you type a command, you must press ENTER, and then start a new command.

In the following steps, you run Telnet from the command line. To open a command line, Click Start, click Run, type cmd in the Open box, and then click OK.

1.	You can start a Telnet session by using the Telnet command in the following format: Note Press ENTER after you type each line. telnet servername portnumber For example, type: telnet mail.contoso.com 25 Note You can replace servername with the IP address or the FQDN of the SMTP server that you want to connect to. Remember to press ENTER after each command. If the command works, you receive a response from the SMTP server that is similar to the following: 220 site.contoso.com Microsoft Exchange Internet Mail Connector <version number of the IMC> Note There are different versions of Microsoft SMTP or third party SMTP servers, and you may receive different responses from the receiving server. What is important is that you receive the 220 response with the FQDN of the server and the version of SMTP. Additionally, all versions of Microsoft SMTP include the term "Microsoft" in the 220 response.
2.	Start communication by typing the following command: EHLO test.com Note You can use the HELO command, but EHLO is a verb that exists in the Extended SMTP verb set that is supported in all current Microsoft implementations of SMTP. It is a good idea to use EHLO, unless you believe that there is a problem with the Extended SMTP Verbs. If the command is successful, you receive the following response: 250 OK
3.	Type the following command to tell the receiving SMTP server who the message is from: MAIL FROM:Admin@test.com Note This address can be any SMTP address that you want, but it is a good idea to consider the following issues: a. Some SMTP mail systems filter messages based on the MAIL FROM: address and may not permit certain IP addresses to connect or may not permit the IP address to send e-mail to the SMTP mail system if the connecting IP address does not match the domain where the SMTP mail system resides. In this example, that domain is test.com. b. If you do not use a valid e-mail address when you send a message, you cannot determine if the message had a delivery problem, because the non-delivery report (NDR) cannot reach an IP address that is not valid. If you use a valid e-mail address, you receive the following response from the SMTP server: 250 OK - MAIL FROM Admin@test.com
4.	Type the following command to tell the receiving SMTP server whom the message is to. Note It is a good idea to always use a valid recipient SMTP address in the domain that you are sending to. For example, if you are sending to john@domain.com, you must be certain that john@domain.com exists in the domain. Otherwise, you will receive an NDR. Type the following command with the SMTP address of the person you want to send to: RCPT TO: User@Domain.Com You receive the following response: 250 OK - Recipient User@ Domain.Com
5.	Type the following command to tell the SMTP server that you are ready to send data: DATA You receive the following response: 354 Send data. End with CRLF.CRLF
6.	You are now ready to start typing the 822/2822 section of the message. The user will see this part of the message in their inbox. Type the following command to add a subject line: Subject: test message Press ENTER two times. You do not receive a response from this command. Note The two ENTER commands comply with Request for Comments (RFC) 822 and 2822. 822 commands must be followed by a blank line.
7.	Type the following command to add message body text: This is a test message you will not see a response from this command.
8.	Type a period (.) at the next blank line, and then press ENTER. You receive the following response: 250 OK
9.	Close the connection by typing the following command: QUIT You receive the following response: 221 closing connection
10.	Verify that the recipient received the message that you sent. If any error event messages appear in the application event log, or if there are problems receiving the message, check the configuration or the communication to the host.

Back to the top

Advanced Testing

In addition to the basic testing steps that are listed in this article, you can use a delivery receipt to test mail in both directions. You can use this method to verify that the SMTP server can accept an inbound connection and generate a delivery receipt back to the sender to test outbound connectivity of the SMTP server.

To request a delivery receipt for the test message, see step 4 in the "Basic Testing" section of this article to make sure that the information provided is a valid e-mail address that can receive the delivery receipt. Then in step 5 in the "Basic Testing" section of this article, type the following command in the Telnet session:

RCPT TO:User@Site.Domain.Com notify=success,failure

 

Why a Microsoft Windows Domain Network?

Microsoft Windows Domains are fantastic for supporting business computer networks. Fort Lauderdale computer networking experts are available 24/7. Please contact D&K Enterprise for more information about networking your computers systems professionally.

 

Here’s the brief list on how Windows domains can be handy in managing aspects of the computer network infrastructure as opposed to a workgroup. These are some of the most valuable tools we use on a day to day basis.

 

1.       Active Directory – user and computer infrastructure

1.       Add/Disable users instantly

2.       Specify groups and containers divided geographically or functionally

3.       Specify what groups have access to certain shared resources.

4.       Allow certain hours of logon to computers, and specify groups of computers where the users can login.

5.       Create the global catalogue of all user information published across the network

6.       Allow users to log into any computer and have their information follow them.

7.       If running exchange then the email address policy will automatically configure a mailbox for them.

2.       Group Policy - permission based structure that disseminates policies which:

1.       Run scripts based upon login that auto-map drives, add shortcuts, add printers based on location in office etc…

2.       Set specific desktop background and withhold permission to change it

3.       Specify Microsoft Installer (.msi) files to automatically install. 1Ex. Adobe Reader, Java, Macromedia Player

4.       Specify certain favorites or links and custom browser title

5.       Force windows firewall to be on with certain program/port exceptions

6.       Allow everyone to be added automatically to certain local groups(ex. Power Users)

7.       Disable access to functions such as parts of the control panel or the whole control panel, CD burning, streaming media, network connections, command prompt, registry etc…

8.       Automatically update other Microsoft servers or workstations with updates pushed out from a central location.

 

There are many more reasons to utilize a domain such as remotely (without screen sharing) accessing the registry, services, and files on other domain computers etc…  The biggest reason is for security purposes though. For instance the server hands out globally unique identifiers to the entire network and controls all access to every file across the board.

 

For more information please contact D&K Enterprise LLC by calling 1-866-760.8298 or email info@dandkenterprise.com.

Workgroup Vs. Domain?

Workgroup Vs. Domain: Simple explanation

If you have just one computer, you have the beginnings of a network. With two computers, you definitely have a network. With three computers, you have a workgroup. Beyond that, consider the benefits of a domain. Look at the members (people) in your workgroup. Remember that the purpose of networking computers is to share resources (data and / or printers). Do you have a group of people who trust each other, totally, with all shared resources? If so, then you can setup an open workgroup, with no reservations. And you can, generally, use Guest authentication. If you can't trust everybody with all shared resources, you will have to setup non-Guest authentication (who is this person?) and authorization (should this person access this resource?). Without a domain to provide authentication, you have to setup an account for each person on both one or more clients, and one or more servers. With a domain, it's simply a matter of adding one more domain account. Account and password maintenance, in a workgroup environment, can be a real experience.

 

 You have to create an account, with an identical password, on each client and on each server.

 

 You have to change a password on each client, and each server, simultaneously. The account owner has to be logged off on each client, while you do this, or face password conflicts.

 

 When somebody leaves the group, you have to delete their account on each client and server.

 

With a domain, again just add an account, change the password, or delete the domain account. Will you possibly have people sharing each other's computer from time to time? Will you have people accessing shared resources on more than one computer? Will you have group turnover, where one person leaves the group, and is replaced by somebody else? Will you have staff sharing each other's account / password (you know folks shouldn't share passwords, but eventually they will). For that matter, how does a workgroup member change his / her password, on the servers? Surely you wouldn't want each person walking up to the server, and logging themselves in, locally, for a simple password change? And how about the need for one person to have unrestricted access to each computer? Any LAN of any size needs an administrator. The administrator account has to be on each computer. Proper security procedures demand regular changing of the administrator password - but how do you do that on each computer? Besides the people related issues, how about the network layout? Is your workgroup likely to span multiple subnets? If so, you will need a domain. Be aware of issues involved with Browsing Across Multiple Subnets. There is one show stopper here. If you have computers running XP Home, you might as well stick with the workgroup. Computers running XP Home can't join a domain. Now, setting up a domain shouldn't be done casually. The initial expense, and setup, of a domain, is significant. Minimally, you need:

 

 A dedicated server (not shared as somebody's desktop computer).

 

 A server Operating System.

 

 Windows Server 2003 is the basic solution.

 

 Windows Small Business Server 2003 is a limited license domain and file server, with bundled products.

 

 Server administration techniques. Since the server is depended upon by each person, it is proportionally more important to keep it secure and stable.

 

Setting up Server 2003, and a domain, is a lot more work than setting up a single Windows XP host. Maintaining a server is a little more work than maintaining a single personal computer. But, as soon as you see how simple it is to add or update a new person in a domain, compared to adding or updating multiple clients and servers in a workgroup, you'll see that it's worth the initial and ongoing complications. In short, a workgroup setup makes sense for a group that is:

 

 Trusting of each person.

 

 Small.

 

 Doesn't share multiple resources.

 

 Static.

 

 Mostly computers running XP Home.

 

My personal experience? If you have more than 4 or 5 computers or people, you will, eventually, end up with one or more problems with the limitations listed above. You can maybe work around each of those limits procedurally; and if you have enough time and patience (by the staff, and whoever maintains the LAN), none of them will matter too much. If you need to move somebody from one computer to another, you can use the File and Settings Transfer Wizard to make the process almost scriptable. But, if you have ever administered a workgroup of any size, with any staff turnover, secreting of data, and / or sharing of computers, you will know that a domain, with a simple procedure to setup and maintain each account, makes more sense in the long run.