Subscribe to our Newsletter. The latest news and articles delivered to your Inbox!
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.
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.
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: firstname.lastname@example.org. I will try to relay this through adminstop.com. I would submit the following command sequence:
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 email@example.com'.
If the server allowed relaying it would have accepted it as usual with a 250 response.
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:
Exchange rejected the email following the MAIL command, returning '550 5.7.0 Access Denied'. Following this the connection is dropped.
Sender Filtering blocks emails based on the SMTP MAIL address. I now added firstname.lastname@example.org to the sender block list. Here is my SMTP command sequence:
Exchange behaves in a similar manner to Connection Filtering this time returning the rejection response '554 5.1.0 Sender Denied'.
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 (email@example.com) and to an existing address (firstname.lastname@example.org).
Exchange rejected email@example.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.
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.
Telnet Port 25
Connection Filtering IP Accept List in Exchange SP2
Tar Pitting Directory Harvesting Attacks
Add New Comment...