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.