WinDeveloper O365 Mailer FREE for 1 Year

WinDeveloper IMF Tune
WinDeveloper IMF Tune

Testing Exchange through Telnet

Alexander Zammit

Alexander Zammit Photo

Alexander Zammit has been developing server applications for over 15 years. Most of his works involve Exchange integrated applications, including a FAX server, a mail security product and anti-spam products.

  • Published: Nov 28, 2006
  • Category: General, Anti-Spam
  • Votes: 4.8 out of 5 - 4 Votes
Cast your Vote
Poor Excellent

Exchange includes various settings determining how SMTP emails are to be handled. Here Telnet becomes an excellent testing tool, providing a direct way to verify everything is functioning as expected.

Telnet allows us to directly interact with the Exchange SMTP service. Establishing an inbound connection and manually submitting the individual SMTP commands allows us to see for ourselves how Exchange handles emails. In Telnet Port 25 we saw how to do just that.

Before allowing SMTP connections, before responding to SMTP commands, there is plenty of processing going on. Today we look at some of the Exchange settings having direct effect on SMTP email handling. We see how Exchange behaves when misconfigured as an open relay, when applying connection filtering, when blocking recipients not in Active Directory and more.

Identifying an Open Relay

An open SMTP relay allows anyone to route emails through it. This opens the door to spammers, who use the server to distribute their junk. We can use telnet to quickly verify if a server is allowing such relaying. This test must be performed using an external connection to our SMTP server.

Let say I want to send an email to: someone@exchangeinbox.com. I will try to relay this through adminstop.com. I would submit the following command sequence:

EHLO mail.foo.com
MAIL FROM:<joe@foo.com>
RCPT TO:<someone@exchangeinbox.com>

Here is how a server correctly configured to block relaying responds:

Relaying Blocked

The Exchange server responds successfully to all commands until the RCPT command. At this point it realizes that the recipient is not addressed for local delivery. Thus it rejects it with '550 5.7.1 Unable to relay for someone@exchangeinbox.com'.

If the server allowed relaying it would have accepted it as usual with a 250 response.

Connection Filtering

Exchange Connection Filtering blocks/allows emails from hosts based on their IP. For configuration details check Connection Filtering IP Accept List in Exchange SP2.

To test connection filtering telnet must be run from the machine whose IP is to be verified. In case of remote connections what matters is of course the public IP. For a test I added my IP to the Connection Filtering Deny List. I then submitted the following SMTP commands:

EHLO mail.foo.com
MAIL FROM:<joe@foo.com>

Exchange rejected the email following the MAIL command, returning '550 5.7.0 Access Denied'. Following this the connection is dropped.

Connection Filtering

Sender Filtering

Sender Filtering blocks emails based on the SMTP MAIL address. I now added joe@foo.com to the sender block list. Here is my SMTP command sequence:

EHLO mail.foo.com
MAIL FROM:<joe@foo.com>

Exchange behaves in a similar manner to Connection Filtering this time returning the rejection response '554 5.1.0 Sender Denied'.

Sender Filtering

Recipient Filtering

Exchange recipient filtering blocks emails based on the address supplied to the RCPT command. Through this block list, specific addresses and domains may be filtered. Furthermore one may also block all emails addressed to recipients not present in Active Directory. Recipient filtering configuration was discussed in Tar Pitting Directory Harvesting Attacks.

For a test I enabled filtering of addresses not in AD. Next I attempted to submit an email to a non-existing address (noone@adminstop.com) and to an existing address (user1@adminstop.com).

EHLO mail.foo.com
MAIL FROM:<joe@foo.com>
RCPT TO:<noone@adminstop.com>
RCPT TO:<user1@adminstop.com>

Exchange rejected noone@adminstop.com with '550 5.1.1 User unknown'.

Recipient Filtering

Here we have the opportunity to highlight an important point. If recipient filtering was not enabled, the address and the entire email would have been accepted. The address would still be identified as invalid further down the line. However SMTP rejection would not be possible any longer at that point. To make up for this, Exchange generates a Non-Delivery Report NDR informing the sender that delivery still failed.

Rejecting the recipient at the RCPT command relieves Exchange from generating the NDR. The sending host is immediately alerted. If an NDR is required this is then generated by the sending host itself.

Final Tips

Telnet is readily available on your windows machine. It is perfect for stepping through an SMTP conversation. Analyzing settings affecting SMTP command handling cannot be more direct.

In addition to what we discussed here, more Exchange settings could be verified through telnet. Some examples include the Intelligent Message Filter gateway threshold and the SMTP Virtual server configuration. The tests always follow the same logic.

References

Telnet Port 25

Connection Filtering IP Accept List in Exchange SP2

Tar Pitting Directory Harvesting Attacks

Copyright © 2005 - 2018 All rights reserved. ExchangeInbox.com is not affiliated with Microsoft Corporation