Secure Exchange 2000 IMAP4 Service Publishing with ISA Server 2000 –
Part 2: Understanding the Co-located SMTP Servers
By Thomas W Shinder M.D.
In the first part of this article on publishing the Exchange 2000 IMAP4 service, we went over the procedures required to make the IMAP4 service available to users on the Internet via ISA Server 2000 (ISA Server) Server Publishing Rules. You learned that you can secure your IMAP4 client/server communications by forcing SSL on the link and that in order to support the SSL connection; we bound a certificate to the IMAP4 site.
At this point our scenario is set up to support inbound secure IMAP4 connections to the Exchange Server via an SSL link. Our work isn’t done yet because the IMAP4 client needs a mechanism to send mail. While the secure IMAP4 connection allows external users to obtain mail headers and message bodies, but it doesn’t them to send mail. You need an SMTP server to support outbound messages from your IMAP4 clients.
In this, part 2, of our secure IMAP4 publishing series, we’ll go over the high level details required to understand the Co-located SMTP server scenario we’re building. In part 3 we’ll cover the details of creating and configuring the Co-located SMTP servers. Finally, in part 4 we’ll finish up by configuring SMTP relay on the Exchange Server, configure the ISA Server and set up the IMAP4/SMTP client.
I had originally planned for this to be a two part article. The problem is that the procedures are somewhat involved and complex and everything won’t fit into two articles, so now we’ll all benefit from a four part series that delves deep into the details of IMAP4 and SMTP publishing with Exchange 2000 and ISA Server.
Understanding the Co-located SMTP Server Scenario
While an ideal setup has your SMTP relays on a third machine that is neither an Exchange Server nor an ISA Server, this isn’t always possible. Money is tight these days and if there’s a way to safety consolidate services, we should endeavor to do so. While I would never recommend putting a Web, NNTP or FTP server on the ISA Server machine, a case can be made for securely co-locating SMTP servers on the ISA Server itself.
There are a number of ways an external user can access an SMTP server. External users can connect to their own SMTP server if they dial up to their own ISP before making the IMAP4 connection to your Exchange 2000 Server. This used to be the most common scenario because the vast majority of remote connections were made via some type of dial up interface. Things have changed a lot in the last couple of years and a good percentage of remote connections now come from broadband networks where the remote user just “plugs in” to the an existing network. He doesn’t need to log on to a local ISP and local access provider usually doesn’t provide an “in network” SMTP server. You’ll have to provide an SMTP for these users.
To solve our problem we’ll create two SMTP servers on the ISA Sever: a Private SMTP server and a Public SMTP Server. The Private SMTP server will require user based authentication and SSL, in order to provide a reasonable level of protection for user credentials and data. We’ll use packet filters on the ISA Sever to make the Private SMTP server available to external network users. Our Public SMTP server will allow anonymous, unsecured connections from public SMTP servers that need to relay mail to our corporate domains. The Public SMTP server is published using Server Publishing Rules. The ISA Server SMTP Application Filter will protect the ISA Server from SMTP exploits.
NOTE:
While Server Publishing Rules can leverage application filters to inspect layer 7 components of a communication, packet filter do not. I would not generally recommend publishing a co-located SMTP server on the ISA Server itself using packet filters, but since the connection requires authentication and an SSL link, I consider it a reasonable trade-off
Figure 1 shows the typical dial up situation. The dial up user logs onto his ISP. He can now configure his IMAP4 client software to use the ISP’s SMTP server. Because this SMTP server allows relay from “on network” hosts, the user can use this SMTP server to relay mail to any domain on the Internet, including your corporate mail domains. In contrast, the default settings on your corporate SMTP server do not allow relay from external hosts, and that’s a very good thing! You need to be very careful about who can relay through your SMTP servers because spammers can generate GB’s of network traffic through unsecured SMTP relays.
NOTE:
“On network” hosts are those under the control of the ISP. ISP’s generally allow SMTP relay through their SMTP servers if the sender has an IP address on the ISP’s network. ISPs usually do not allow hosts external to their network to relay. Some ISPs allow you to log into their SMTP servers so that you can relay SMTP traffic even when you’re not “on network”. This is essentially the same as the solution we’re creating with our Private SMTP server.
Figure 1
Many users don’t log onto an ISP. These remote users just “plug in” to an Ethernet network and receive and IP address, a DNS server address and a gateway address. Its up to the user to provide his own SMTP server. In this situation, you need to provide an SMTP server for the user. One good solution for the cash strapped organization is to co-locate two virtual SMTP servers on the ISA Server. One of the virtual SMTP servers is a Public SMTP server that allows anonymous SMTP servers to connect and relay to your internal network domains (MX mail domains under your administrative control). The other virtual SMTP server allows authenticated users to relay to any domain, including those within and not within your administrative control. This is your Private SMTP server.
Figure 2 shows laptops connected to the hotel network. The hotel doesn’t provide an SMTP server, so your users need to connect to an SMTP server that allows them to relay. The ISA Server computer can provide SMTP relay services for your users via the co-located Private SMTP server.
Figure 2
Figure 3 provides a closer look of the co-located SMTP servers on the ISA Server machine. The Public SMTP Server accepts incoming mail from Internet SMTP servers. This mail is forwarded to internal mail domains that are hosted by your Exchange Server. The public SMTP server allows relay only to domains you host. You create Remote Domains on this virtual SMTP server and allow relay only to those Remote Domains. The Private SMTP server allows users to connect and authenticate via a secure SSL link. Once authenticated, the users can relay to any domain. If the user can’t authenticate, he can’t relay.
Figure 3
Figure 4 drills down on the Public SMTP server. This public SMTP server acts an SMTP relay for your domains. For example, suppose you host mail services on your Exchange Server for maildomain.com and smtpmail.com. The Public SMTP server on the ISA Server machine allows anonymous connections (non-authenticated) from Internet SMTP servers to allow those servers to forward mail to addresses in the maildomain.com and the smtpmail.com domains. Remote Domains are configured on the Public SMTP server and the remote domains are configured to relay to the Exchange Server on the internal network. Incoming messages to addresses that do not have a remote domain configured on the Public SMTP server are dropped. This prevents spammers from using your Public SMTP server as an anonymous relay. Of course, this doesn’t prevent spammers from sending spam to your domains, but that’s another problem for another time 
.
Figure 4
Figure 5 drills down on the Private SMTP server setup. This setup looks a bit more complex than the Public SMTP server, but its really not that difficult to understand or implement. Remote corporate SMTP clients use the Private SMTP server co-located on the ISA Server. External users must authenticate and they must use SSL connect to Private SMTP server. We require authentication because we want this server to support relay and we never want to allow anonymous relay.
We also need to prevent capture of user credentials and data on the remote network. You never know who is on the same network as your remote user. Maybe the hotel your remote user is at is hosting a Sniffer Pro academy. Forcing external users to use SSL will prevent the enterprising Sniffer Pro users from capturing user credentials and data.
Note in figure 5 that our external network SMTP clients are able to send mail to both external and internal mail domains. The Private SMTP relay server is able to resolve all MX domain names, not just external domains. Your Private SMTP server must be able to resolve both internal and external mail domains because this server needs to relay SMTP messages sent by your IMAP4/SMTP clients to remote mail servers and your internal network’s Exchange 2000 SMTP service (for those domains under your administrative control).
Figure 5
NOTE:
I will not cover outbound relay in this series. Outbound relay is helpful if your are using the outbound SMTP relay server to look for keywords and viruses in outgoing email. If you’re interested in supporting outbound relay on an SMTP server co-located on the ISA Server and you require the step-by-step configuration, check out ISA Server and Beyond.
Lab Network Layout
You’ve heard me say this many times before, but I’m going to say it again. Never implement a solution on a production network until you completely understand what you’re doing. The best way to get that understanding is by performing the same procedures on a lab network. I like to use VMware to create my lab networks because I don’t have to get up our of my chair to manage multiple servers on multiple virtual network segments. I can access all the machines in my VMware lab network from my single workstation.
Figure 6 shows the setup of the lab network. It’s always good to keep things simple and replicate only the relevant components. In this case we need to test the external network client, the ISA Server/SMTP server, and the Exchange Server. The ISA Server has two addresses bound to its external interface and the primary address is 192.168.10.2. Only the internal interface has a DNS server entry. The Exchange Server is a domain controller hosting an Active Directory integrated DNS server. The DNS server is configured to resolve all internal domain names (in this example, only internal.net is an internal domain). While not required in our lab network, you might want to allow your DNS server to perform recursion in order to resolve external MX domain names. Your other option is to use a DNS forwarder. The external network client is running Outlook Express 6.0 and the IIS SMTP is running to test outbound relay.
Figure 6
I’ve added an external zone for shinder.net to the DNS server so that it can find MX records for the shinder.net domain without having to perform recursion. We want mail directed to shinder.net to be sent to the IIS SMTP service on the external client. If true recursion were performed, the result would point to the actual mail server, not the one we want it to point to in this lab. This will allow us to test the relay configuration for the Private SMTP server.
Summary
In this article we reviewed the SMTP relay concepts that will be critical to making our SMTP servers available to anonymous SMTP servers on the Internet and to our corporate users working remotely. The scenario we covered here allows cash stressed businesses to intelligently co-locate services on the ISA Server firewall without creating major security risks. While its never a good idea to put Web, FTP or NNTP resources on the ISA Server, proper configuration of the SMTP service will lead to minimal negative impact and obviate the requirement for a third server to act as an SMTP relay.
In part 3 we’ll go over the details of the Public and Private SMTP server configurations. See you then!
