Supporting ISA Server 2000 Publishing of Exchange Server 2000/2003 with SMTP Relays
Part 1: What is an SMTP Relay and Why You Should Use One
By Thomas W Shinder M.D.
SMTP relay issues are very common for Exchange Server administrators who need their mail servers to connect to the Internet. The problem is that there aren’t a lot of good descriptions of what SMTP relay is, how it works, why you want one, and what problems you might encounter with them.
The issue of SMTP relay comes up most often when a keeper of a Black Hole list (aka RBL) has victimized a hapless ISA Server firewall or Exchange Server administrator. A black hole list is a list of “banned” SMTP servers. If your SMTP server’s address is placed on such a list, subscribers of the list will not accept mail from your server. The people who maintain black hole lists have varied backgrounds and equally varied motivations for maintaining these lists.
Some of the RBLs are based on searches for “open relays” and some RBLs are based on reports from aggrieved individuals who believe they have been spammed. Keepers of these lists typically do not charge for their services and they take no responsibility for the damage they do to persons or businesses. It’s our opinion that that RBLs should never be used and that you and your organization must take professional responsibility for spam related problems using more ethical methods of spam control. Anonymous and irresponsible keepers of RBLs cannot be trusted and in fact, they can be realistically considered a potential security risk by virtue of their ability to DoS your outbound mail services.
Busy network and security administrators use RBLs because they don’t have time or expertise to control the volume of spam entering their network. They consider RBLs a good thing until the time they get placed on an RBL because they’re accused of having an “open relay”. The problem is that many network and security administrators are not exactly sure what an “open relay” is and if they indeed do have such a thing, they’re not sure how to fix it.
The goals of this series on using SMTP relays is to help with your ISA Server 2000 Exchange Publishing design and to allow you to leverage the security and performance enhancements you’ll find when you start using SMTP relay. In addition, this series will help prevent you from ever having an open relay. Once you have a good understanding of SMTP relays, you’ll know that the RBL’er (a keeper of an RBL) put you on his blacklist because he has malicious intent, not because you’re maintaining an open relay.
We’ll cover the following major issues in this series on SMTP relays:
In this, part 1 of the three part series, we’ll go over what an SMTP relay is and how it works.
What is an SMTP Relay and Why Should You Use Them
First, let’s define what an SMTP relay computer is:
The key concept is that the SMTP relay computer is not the endpoint for the SMTP message. The SMTP relay computer must always hand-off or forward the SMTP messages to another SMTP server. The SMTP server the SMTP relay computer forwards the message to may be the endpoint for the SMTP message, or it might be another SMTP relay.
Let’s look at two simple, but common examples of SMTP relay:
The outbound SMTP relay scenario is described in figure 1 below. The client computer uses Outlook Express as its email client application and the user has configured Outlook Express as an SMTP and POP3 client. The SMTP server setting in the Outlook Express client tells the application what address it should send outgoing mail to and the POP3 setting on the Outlook Express client tells the email application what address it should connect to so that it can download mail from the user’s mailbox.
The user connects to the dial-up ISP network via his modem and establishes a connection with the ISP’s RAS server. The user then starts up Outlook Express and sends an email message to [email protected]. The ISP the user is connected to is named isp.com and this ISP is responsible for all mail destined to the isp.com mail domain. After the user connects to the ISP and sends the email message to [email protected], the message is sent to the SMTP server at the isp.com facilities.
The ISP’s SMTP server realizes that it’s not responsible for mail destined for users in the domain.com domain. The ISP’s SMTP server needs to relay the message to another SMTP server that is responsible for mail destined to the domain.com domain. In order to determine what SMTP server is responsible domain.com SMTP mail, the ISP’s SMTP server must use DNS queries.
There are two records the ISP’s SMTP server requires to find out the information it needs to relay the SMTP message to [email protected] properly:
MX records in the DNS zone for the domain.com domain contain names of SMTP servers are responsible for accepting SMTP mail for the domain.com domain. In this example the domain.com authoritative SMTP server is names mail.domain.com and the MX record contains this name.
In order for the ISP’s SMTP server to use the information in the MX record to properly relay the mail to user [email protected], the server name contained in the MX record must be resolvable to an IP address. The DNS zone file for the domain.com domain contains a Host resource record for the name mail.domain.com which maps that name to the IP address 1.1.1.1.
Now that the ISP’s SMTP server knows the IP address of the SMTP server responsible for SMTP messages for the domain.com mail domain, it will relay the message to that address. This is what SMTP relay is all about: SMTP relay servers forward messages to another SMTP server that is responsible for mail for a particular mail domain.
Figure 1
The above example should also make it clear how critical a proper DNS configuration is to successful SMTP relay. The ISP’s DNS server queried a DNS server to obtain information in the MX and A records for the SMTP server responsible for domain.com’s SMTP mail. If the ISP’s SMTP server could not resolve the email domain to an IP address of the SMTP server responsible for mail for the domain.com domain, the mail delivery to [email protected] would have failed and the user who sent the message would have received an error indicating that no such domain exists.
Our second example of SMTP relay is also a common one, and reflects more closely on how we’ll use SMTP relays to support Exchange Server publishing using ISA Server 2000 firewalls. Figure 2 describes this second scenario.
A user connected to the domain.com network wants to send an email message using his Outlook Express email client application to the user [email protected]. The user at the domain.com network has configured his Outlook Express client application to send SMTP messages to the SMTP server at domain.com.
When the user over at the domain.com network sends messages to [email protected], the message initially is sent to the SMTP server configured in the Outlook Express account settings. The SMTP server at the domain.com network receives the SMTP mail destined for [email protected]. The domain.com SMTP server knows it is not responsible for internal.net users and therefore it must relay the mail to an SMTP server that is responsible for internal.net users.
The domain.com SMTP server queries a DNS server for the MX record information for the internal.net domain and also queries the DNS server for Host address information on the servers mentioned in the MX record. The SMTP server at the domain.com domain receives the following information from the DNS server:
MX = mail.internal.net
A = mail.internal.net = 1.1.1.1
The domain.com SMTP server now knows that it can relay mail for users at the internal.net domain to the IP address 1.1.1.1. The SMTP server now relays the mail to that address.
The address 1.1.1.1 is used by the external interface of the ISA Server firewall. This address on the external interface of the ISA Server firewall is used by an SMTP Server Publishing Rule that accepts SMTP connections forwards these connection requests to an SMTP relay computer on the internal network.
In the example shown in figure 2, the ISA Server firewall forwards the SMTP message for [email protected] to a dedicated SMTP relay machine. This dedicated SMTP relay machine has the IIS SMTP service installed and is not the same machine as the Exchange Server. This SMTP relay computer looks at the “to:” address in the SMTP message and compares that with the email domains its responsible for. This SMTP relay computer accepts mail for the internal.net domain and drops all other mail it receives. The SMTP relay is not the endpoint for this message, so it must relay the SMTP mail to the Exchange Server on the internal network. The Exchange server has a recipient policy configured so that it knows it’s responsible for the internal.net mail.
Figure 2
This example demonstrates the utility of an inbound anonymous SMTP relay server. However, there are many more types of SMTP relay servers. Some of the advantages of using one of the many types of SMTP relay servers include:
There are many more advantages to using an SMTP relay computer to send mail from, and receive mail to, your corporate network. The advantages will become apparent when you read in parts 2 and 3 of this article about the various types of SMTP relays, how they’re used, and where you can place your SMTP relays.
In part 2 of this series we’ll look at the various types of SMTP relays, the feature sets they provide and how you can use them to your best advantage. See you then!
Check out part 2 of this article at http://isaserver.org/articles/smtprelaypart2.html
I hope you enjoyed this article and found something in it that you can apply to your own network. If you have any questions on anything I discussed in this article, head on over to
http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=6;t=002070 and post a message. I’ll be informed of your post and will answer your questions ASAP. Thanks! –Tom
If you would like us to email you when Tom Shinder releases another article on ISAserver.org, subscribe to our ‘Real-Time Article Update’
by clicking here. Please note that we do NOT sell or rent the email addresses belonging to our subscribers; we respect your privacy!
