Thursday 25 May 2006 - markwilson.it

Over the last couple of days, I migrated my e-mail service to Microsoft Exchange Server. I’ve been meaning to do this since I first bought my own domain name in the late 1990s but a lack of suitable hardware to dedicate to the task has meant that until now it’s been easier to leave the service with my ISP and download it to Outlook using POP3. Using virtualisation technology has enabled me to build an e-mail infrastructure without using any extra hardware.

Phase 1 of the project was installing the mail service and connecting to my ISP’s servers. I wanted to use Microsoft Exchange Server 2003 but for various reasons I didn’t want to extend the schema for my Active Directory (AD), so I created a separate resource forest with an outgoing trust to the original domain and installed Exchange Server there. Following this, I was able to create disabled user accounts and associate the mailboxes with external accounts in the original forest, allowing me to authenticate to my mailbox in the resource forest using my normal account credentials from the original domain (as described in Marc Grote’s article on the MSExchange.org site, although assigning the external associated account is now much simplified using the Exchange Task wizard).

Next, I needed to tell my ISP’s servers to allow messages for my domain to be routed to my server. The ADSL connection that I use is not associated with my domain but it does have a static IP address (an alternative is to use a dynamic DNS service), so after opening up TCP port 25 on the firewall to allow inbound SMTP traffic I created two DNS records for each domain that I own:

Host (A) record to define a server name that resolves to my IP address.
Mail exchanger (MX) record for the domain that resolves to the A record created previously.

With the appropriate DNS records in place, that was all the configuration needed at the ISP’s end, but Exchange still needed to be configured to forward e-mail to the ISP’s SMTP relay – easily accomplished using the Exchange Server 2003 Internet Mail Wizard. The important thing to be sure of is that the server is not configured as an open relay (recent versions of Exchange Server lock this down by default). Once the SMTP connection was in place, e-mail started to flow (although for a while some mail was still being delivered to my ISP’s servers until the DNS entries had completely propagated around the Internet).

DNS Stuff is a mine of useful information, so I ran a DNS report on my domain name. This turned up various warnings about my ISP’s DNS configuration (which I can’t really do much about) but also a warning that my server’s SMTP greeting included an non-existent host name (the internal DNS name for the Exchange server):

220 hostname.internaldnsdomainname Microsoft ESMTP MAIL Service, Version: 6.0.3790.1830 ready at Thu, 25 May 2006 12:30:31 +0100

According to the warning, if the server sends e-mail using a non-existent host name in its EHLO or HELO, e-mail could be blocked by anti-spam software, as well as being a technical violation of RFC 821 section 4.3 and RFC 2821 section 4.3.1.

A spot of Googling turned up a forum post on changing the SMTP greeting which pointed me in the direction of Microsoft knowledge base article 266686, allowing me to change the fully qualified domain name for the SMTP virtual server so that the SMTP greeting now reads as follows:

220 mailserver.domainname Microsoft ESMTP MAIL Service, Version: 6.0.3790.1830 ready at Thu, 25 May 2006 13:18:44 +0100

Note that the hostname given in the SMTP greeting doesn’t have to be precise – it doesn’t matter that the SMTP server may handle e-mail for multiple domains (as mine does), as long as the host name given resolves to the correct IP address.

Phase 2 of the project will be to configure the intelligent message filter for Exchange Server 2003 (included as part of Exchange Server 2003 service pack 2) and hopefully cut out most of the spam that I receive (as the volume of spam hitting my server is much greater than the previous levels which were mostly handled by the Outlook junk e-mail filter). I’ll also be looking at enabling RPC over HTTP (see Microsoft knowledge base article 833401) to allow Outlook to access my mail servers using HTTP from behind my employer’s firewall.

After having to abort last week’s attempt to replace an aging Microsoft Proxy Server 2.0 installation with Microsoft Internet Security and Acceleration (ISA) Server 2004, last night I had another go and I’m pleased to say that the ISA Server is now up and running. There are still some minor issues that I need to resolve, but here’s a summary of the key points that affected me:

It’s important to configure the underlying network correctly – i.e. check the binding order of the various network interfaces, disable unwanted services on the external interface, only configure one interface with a default gateway (the external interface), only configure one interface for DNS and check that there is a valid route configured back to each internal network. Jim Harrison has written an excellent article on configuring ISA Server interface settings.
By default, ISA Server 2004 will not let any traffic pass (on any interface) – i.e. it is secure by default.
Do not configure the ISA Server to use both internal and external DNS servers. The ideal solution is to configure DNS forwarding from the internal DNS server(s) to the ISP’s DNS servers and create an access rule to allow outbound DNS traffic. If DNS is configured incorrectly, then the server may have difficulties contacting Active Directory which will have a consequential effect on authentication.
Configure individual access rules to allow all required outbound network services and consider the order of the rules (i.e. is one rule denying access before another is processed). Multiple rules can be configured for different user sets and schedules.
In general, access rules are used to allow outbound access whilst internal resources are “published”.
When publishing HTTP(S) servers, make sure that there is an appropriate web listener configured.
When publishing SMTP (or other) servers, there is no web listener, but there must be an appropriate network listener configured. Generally, internal SMTP servers will be configured only to allow mail to be received from certain hosts, so it may be necessary to make the traffic appear as if it originated from the ISA Server. Thomas Shinder has written an excellent article on troubleshooting SMTP server publishing rules.
If restricting access to certain users, ensure that integrated authentication is enabled and authentication is required.