"Keep a copy of all my inbound and outbound Simple Mail Transfer
Protocol (SMTP) mail so that I can comply with industry regulations," the customer requested.
"No problem," I said. "That feature is built into the
Exchange Internet Mail Connector."
"But remember," the customer said. "I don't want you to keep copies of any internal SMTP messages that travel between Exchange and my legacy mail system."
BZZZZZZZZZZ! Thanks to my alarm clock, I escaped a dream that replayed the
previous day's meeting with a new customer. The customer asked us to assist in a
company migration from Novell's GroupWise to Microsoft Exchange Server 4.0.
Together we identified three key objectives:
- Migrate nearly 650 users gradually, and provide coexistence of the two
mail systems.
- Provide uninterrupted Internet mail flow for GroupWise and Exchange users
and do not modify users' Internet mail addresses (user@ourfirm.com).
- Archive all external messages, inbound and outbound, to comply with an
industry regulation without archiving internal messages between Exchange and
GroupWise.
After considering third-party gateway products, we opted for an
Exchange-only solution that met the customer's requirements and reduced
administrative effort. This article describes the solution and explores its
application in other environments.
The Solution
Figure 1, illustrates our initial plan to introduce Exchange into
the customer's messaging environment. To meet the first objective, to migrate
gradually and have the two mail systems coexist, we changed the function of the
client's GroupWise SMTP gateway. Previously, the gateway handled Internet-only
messages, but we restricted it to passing all outgoing SMTP messages to
Exchange. This change and configuration of the Exchange Internet Mail Connector
(IMC) let the two systems communicate without additional gateways.
The second objective, uninterrupted mail flow and maintaining Internet mail
addresses, required more consideration. Although we planned to use the Exchange
IMC as the conduit to the Internet, recipient addressing was a problem. Because
we needed to address GroupWise and Exchange users at the same email domain (ourfirm.com)
regardless of platform, we had to intelligently route messages
addressed to user@ourfirm.com to either Exchange or GroupWise, depending on the
recipient's migration status. Exchange's Alternate Recipient and Custom
Recipient features, which let us redirect incoming messages to user mailboxes on
foreign systems, solved the addressing problem and minimized overall
administration during the migration.
To achieve the third objective, archiving external communications, we had
two options: Develop an application to scan mail headers to distinguish and
archive external messages, or create an infrastructure extension to provide
service for external messages only. The second option proved cost-effective and
easy to support. We added a second Exchange server and IMC to the site and
routed all Internet mail through it to fulfill the archiving requirement.
SMTP Configuration and Proposed Mail Routing
Our customer's existing SMTP gateway had provided a messaging link to the
Internet for several months. To fulfill the first two necessities, which
required connecting the two mail systems, we leveraged the existing gateway as a
dedicated path to Exchange. We determined that with the IMC Sample Extension
DLL, Exchange can act as a smart mail host, rerouting messages to other SMTP
hosts. This solution was the key to GroupWise Internet connectivity.
Next, we created Exchange mailboxes for current email users. We also
represented each GroupWise user with an alias (Custom Recipient) in the Exchange
directory and hid the aliases from view. Then, we modified delivery properties
of each Exchange mailbox to reroute messages to an Alternate Recipient, the
GroupWise mailbox alias. Table 1 lists Exchange objects and their properties
relevant to our plan. This configuration let us route messages from unattended
Exchange mailboxes to corresponding GroupWise mailboxes and eliminated
addressing confusion for Exchange users.
To illustrate our proposal, let's briefly follow the route for three types
of messages and their replies. First, Internet messages addressed to Exchange
users at the ourfirm.com domain are delivered to the Exchange server. (Note: To
make this approach work, we had to contact the customer's Internet Service
Provider--ISP--and request modification of the MX record for the ourfirm.com
domain. We had the ISP replace the GroupWise SMTP gateway name and address
information with that of the Exchange server.) Likewise, Exchange performs a
Domain Name System (DNS) lookup to transfer any reply or other outgoing message
to Internet mail hosts.
With the second type of message, GroupWise messages to Exchange resemble
incoming Internet mail, addressed to user@ourfirm.com. (Note: The GroupWise
directory is populated with aliases, such as user@ourfirm.com, for each former
GroupWise user, to simplify addressing for GroupWise users.) By configuring the
GroupWise SMTP gateway to forward all messages to Exchange, messages now arrive
in an Exchange recipient's mailbox from a sender in the ourfirm.com domain.
Replies and other Exchange to GroupWise messages are delivered to the GroupWise
SMTP gateway (gw.ourfirm.com) because of the address space and message
delivery configuration.
Finally, GroupWise communication with the Internet showcases the utility of
our design. Incoming Internet mail addressed to user@ourfirm.com reaches an
Exchange mailbox, and the Alternate Recipient feature reroutes the mail to the
appropriate GroupWise mailbox. Replies and other GroupWise mail to Internet
users pass through the GroupWise SMTP gateway and are delivered to Exchange.
With the IMC Sample Extension DLL in place, if the message does not match the
domain criteria ourfirm.com, it is then forwarded (via DNS lookup) to the
appropriate Internet mail host.