Testing Exchange through Telnet

Alexander Zammit

Software Development Consultant. Involved in the development of various Enterprise software solutions. Today focused on Blockchain and DLT technologies.

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:

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.

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'.

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'.

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.