Using Telnet to simulate server communication

The best place to run Telnet is on the server which sends out your SMTP traffic. This will show you the same information that your SMTP engine receives when communicating with an outside system. Telnet allows you to specify the port through which to communicate. SMTP is defined as TCP port 25.

Open a command prompt window. Determine the FQDN or the IP address. If you need to determine this information, you can use NSLookup if you know the SMTP domain name you are attempting to connect to. For more information about this, read this article.

At the prompt, type telnet fqdn 25

If the receiving server is accepting SMTP communications, it will respond with an acknowledgement message indicating it is ready to receive your transmission. The acknowledgement should also indicate if it understands SMTP or ESMTP.

Type ehlo testdomain.com

There are two established protocols, SMTP and ESMTP (Enhanced SMTP). If the receiving system only understands SMTP, you must begin with helo. If the receiving system understands ESMTP, you may begin with either helo or ehlo.

If you receive an OK message from the receiving mail system, proceed. If not, double check the protocol named in the response to the telnet command.

Type
mail from:exchange.admin@testdomain.com

This indicates the reply address. Some receiving systems will compare the parameter from the ehlo command, and the domain listed in the address on the mail from: command to the domain name returned when performing a reverse DNS (RDNS) lookup on the IP address from which the message is coming. It is a method to combat address spoofing and more reliably identify undesirable senders.

If you are testing communications to an outside messaging system, you may need to use your actual domain name to be allowed to continue.

Type
rcpt to:valid.user@receivingdomain.com

This indicates the recipient address. If receivingdomain.com is not a domain being fielded by the receiving system, and the system does not allow relaying to receivingdomain.com, an error code will be returned.

Type data

This begins the actual message. Optionally, From:, To:, and BCC: can be entered at this time (to be covered in a future article).

Type subject: Test message via Telnet

Type a blank line - this denotes the end of the subject and the beginning of the message body.

Type This is a test
Type Please reply if received
Type a blank line
Type a period (".") and press Enter - this marks the end of the message body. The receiving system will understand and return a prompt.
Type quit

This ends the Telnet session and you will be returned to the OS prompt.

If everything has gone well, the message will be on its way to the recipient address. Give it a minute and check. You now know how to manually create and send an SMTP message! This can be a great troubleshooting tool, as you will receive reponses and acknowledgements from the receiving system that can aid in diagnosing a communication problem.

Using NSLookup to determine an SMTP receiving system

Background
NSLookup is a great tool that comes with Windows that allows you to search DNS for information. &nbspIt is especially useful to troubleshoot particular issues with Exchange. &nbspExchange is reliant upon DNS to know where to send outbound messages. &nbspWhen Exchange has problems getting messages to a particular domain, it's time to open the toolbox.

The best place to run NSLookup is on the server which sends out your SMTP traffic. &nbspThis will show you the same information that your SMTP engine uses when determining where to send mail to a particular domain.

Open a command prompt window
At the prompt, type nslookup
Type the command set type=mx
Type the registered domain name (e.g. domain.com)

You will receive a response similar to:

Non-authoritative answer:
domain.com MX preference = 10, mail exchanger = mail1.domain.com
domain.com MX preference = 20, mail exchanger = mail2.domain.com
domain.com MX preference = 30, mail exchanger = mail3.domain.com

Interpreting the NSLookup results
Your SMTP engine will attempt to use the MX records in ascending order according to their value. &nbspThe name associated with the MX record is what your engine will use. &nbspYou can simulate what the engine does by using the Telnet command. &nbspIn other words, the FQDN associated with the lowest numbered MX value would be the one that your SMTP engine would attempt to connect with.

Using the NSLookup results to test connectivity
In the simulated response shown above, you can test the readiness for receiving SMTP communications by using the Telnet command. &nbspIn a command-prompt window, type telnet mail1.domain.com 25. &nbspIf the system connected to the FQDN is accepting SMTP communications, you’ll receive a response.

DNS Root Servers

What are the root servers? These are the DNS servers from which all others get information.

Why would anyone care? To verify the information other mail systems see when trying to reach your SMTP domain.

How do I use the information? You can force NSLookup to poll a particular DNS server by using the command:
server ip_address or server fqdn

As an example, open a command prompt window
At the prompt, type nslookup
Type the command set type = mx
Type the command server a.root-servers.net
Type the registered domain name (e.g. domain.com)

You have requested the MX information for domain.com directly from one of the DNS root servers.

Here is IP information for the thirteen (13) root servers.
a.root-servers.net   198.41.0.4
b.root-servers.net   192.228.79.201
c.root-servers.net   192.33.4.12
d.root-servers.net   128.8.10.90
e.root-servers.net   192.203.230.10
f.root-servers.net   192.5.5.241
g.root-servers.net   192.112.36.4
h.root-servers.net   128.63.2.53
i.root-servers.net   192.36.148.17
j.root-servers.net   192.58.128.30
k.root-servers.net   193.0.14.129
l.root-servers.net   198.32.64.12
m.root-servers.net   202.12.27.33

The complete information can be found at the website: http://www.root-servers.org

Exchange 5.5 Public Folder Tools

This isn't much of a post, but some people may find it useful. I was searching for the old PFInfo and PFAdmin tools for someone in a forum. All of the hits in my Google searching seemed to be similar queries from people trying to find the old utilities, and no reference to any online sources. The only solutions were that they were supposed to be on the Exch5.5 install CD, or that you had to call Microsoft PSS to get them.

I muddled through and finally came across a reference to our good friends at MSExchangeTeam.com and I knew I was on the right track. I can't take any credit for this, other than to say I persevered. Hopefully future search engine inquiries will find my post and this old lost tool won't be so hard to track down.

For those curious what the big deal is, the newer tool (PFDAVAdmin) doesn't work with Exchange 5.5. If you deal with Public Folder permissions, I strongly advise you check out these tools. They can save you a lot of time.

Finally, without further ado, links to all the tools can be found at: http://msexchangeteam.com/archive/2004/11/05/252979.aspx