Configuring Mercury Mail Transport System to run a LAN-based e-mail server

The Mercury Mail Transport System is an e-mail server that can be installed on client machines, making it unnecessary to run Exchange Server or use another dedicated server. There are two versions of the Mercury Mail Transport System: a Novell NetWare-based version and a Win32-based version. The Win32-based version is referred to as Mercury/32 and provides you with support for both Win32- and Novell NetWare-based e-mail clients. It is the Mercury/32 version that I will refer to in this Daily Drill Down, as I discuss how to configure Mercury Mail Transport System to run a LAN-based e-mail service.
For more information on setting up the Mercury Mail Transport System e-mail server, read Paul Garceau’s other articles in this series:

• “An Exchange alternative: Mercury Mail Transport System can be installed on your client”
• “Configuring Windows NT 4.0 Workstation to run Mercury Mail Transport System”

What does Mercury/32 need?
Mercury/32 needs to know how it is supposed to access your machine. Mercury/32 determines this based on certain network settings, specifically IP addressing and TCP/IP settings that you have defined and enabled via the Network Properties dialog box. IP addressing allows Mercury/32 to understand your LAN configuration. TCP/IP is how Mercury/32 talks to your Win32-based LAN. To ease configuration, Mercury/32 has been organized into two sections for your convenience: the Mercury Core Module and the Mercury Protocol Modules. The Mercury Protocol Module is the module you would use to define and configure the behavior of the SMTP/POP activity for Mercury/32.

Configuring the Mercury Core Module
The Mercury Core Module coordinates all of the e-mail transactions that occur within the Mercury Mail Transport System. Generally speaking, the Mercury Core Module functions quite well with very little need for ongoing maintenance once you’ve supplied the necessary information about local domains, local hosts, and server names.

Before you can configure your Mercury Core Module, you must have already defined certain addresses and protocols for your LAN. The addresses and network protocols you will require for Mercury/32 are typically added either when you first install NT 4.0 Workstation or when you add networking at a later time. If you haven’t added this network support to your NT 4.0 machine, you will need to add TCP/IP and the IP address for your network interface card (NIC).

Your NIC is not the same as your modem. The modem IP address is typically a dynamically assigned IP address value that is defined by your ISP. Since the Mercury Core Module requires that you define certain protocols and IP addresses for your LAN, it is important for you to be able to understand how you would go about configuring your NT 4.0 Workstation network services. For more information on setting up NT 4.0 Workstation to use Mercury/32, read my Daily Feature “Configuring Windows NT 4.0 Workstation to run Mercury Mail Transport System.”

If you’ve already installed Mercury/32, start it by selecting Start | Programs | Mercury For Win32. Then, you will be presented with the friendly Mercury/32 GUI, as shown in Figure A.

Figure A

When started, Mercury/32 opens a user-friendly GUI.

You’ll need to configure the Mercury Core Module to handle your LAN settings. To do this, click on Configuration and select the Mercury Core Module Configuration dialog box (see Figure B).

Figure B

Open the Mercury Core Module Configuration dialog box to configure Mercury/32.

You will then see six tabs. The General tab is used to define your basic Core Module operations. Most (if not all) of the options available from this screen would be defined when you first install Mercury/32. A couple of settings are worth noting here.

Internet Name For This System
This value should be either your fully qualified domain name or the IP address of your machine. The IP address, if used, should always be in brackets and should always reference the machine on which you are currently running Mercury/32. If you don’t know what your IP address is, then you might want to take a look at “Configuring Windows NT 4.0 Workstation to run Mercury Mail Transport System.”

If you are expecting to access mail servers outside your immediate organization some time in the future, the Internet name you enter here will need to be known by your DNS. For now, since you are creating a LAN-only mail server, the static IP address you entered above will work just fine.

Local Mailbox Directory Path
An e-mail account is typically made up of two parts. The first part of the e-mail account is the username, and the second part is the destination or domain reference for the e-mail client in question. For example, josh@some.com tells Mercury/32 to attempt to deliver e-mail to username josh who is a user at the domain some.com.

Default settings for Mercury/32 typically expect e-mail account names to be no longer than eight characters. If you take a look at the text box for entering the Local Mailbox Directory Path, you will notice on the far right-hand side of the directory path either an \~8 or an \~N.

These are wild-card references used by the Mercury Core Module to determine how long an e-mail username may be. If you expect to be using names longer than eight characters, you will need to change the ~8 to ~N. ~N tells the Mercury Core Module that there is no eight-character limit to e-mail usernames.

Configuring local domains
To continue with our settings, click on Local Domains tab (see Figure C). At first, this tab seems pretty straightforward; you simply set the Local Host Or Server name and then you set the corresponding Internet name. However, if you do not correctly enter these values, you could create major problems for Mercury/32.

Figure C

Set your local servers or hosts and their corresponding Internet names.

The local host name and server name must be the name(s) of the local machines that both are authorized for local delivery and exist on your LAN. The Internet name is the one that Mercury Core Module should use when delivering or checking for local mail.

The name game
Each machine on your LAN should have, at the minimum, three different names assigned to it: a fully qualified version, a simple version, and a special version or domain literal version. As you can see in Table 1, I’ve assigned four names to one machine, called Taliesin. The first name is considered the domain literal reference for the local domain (Taliesin). The domain literal reference must always be the IP address of your machine surrounded by brackets. The second entry in the table is an alias and tells the Mercury Core Module that mail.taliesin.org is authorized as a local system. The third entry is the simple name and should always reflect the name of a local host or server that you want the Mercury Core Module to think of as a local machine. Finally, the fourth entry is the fully qualified version of the machine known as Taliesin.

After you’ve assigned your local domains, you will need to completely exit Mercury/32 before the Mercury Core Module changes will be implemented. When you restart Mercury/32, the modifications you completed will be added to the Mercury Core Module.

Implementing your Hosts file
An important aspect of getting your Mercury/32 Mail Transport System to handle local lookup is by defining certain host names and IP addresses in your Hosts file. The Hosts file is what NT uses to look up various local hosts and even some remote hosts. Since the focus of this Daily Drill Down is about setting up a local mail server for your system, and the Hosts file is an important component of that setup, I will touch briefly on this topic.

You can find the Hosts file in your system directory: <your bootdrive>:winnt\system32\drivers\etc\Hosts.

Your Hosts file serves two purposes:

1. It allows you to define a UNIX-like (NT Posix Subsystem) directory reference.
2. It allows you to install Mercury/32 as a stand-alone mail server that is not dependent on an NT domain name or DNS Lookup Service defined for your NT 4.0 machine.

I’ve presented an example of a Hosts file in Figure D.

Figure D

You’ll need to implement a Hosts file, such as the one shown above.

You can see from Figure D that there is a certain amount of documentation associated with the Hosts file that allows you to see exactly what is going on when it comes to assigning specific host names. The Hosts file allows you to assign host names to the specific IP addresses that you have assigned for your machine. Mercury/32 uses these host names to call your machine via TCP/IP. The last two lines in the example show you how to assign a local host name for each of the machines on your LAN.

Let’s take a look at IP address 168.197.0.1. For my LAN configuration (yours will be different), I assigned the IP address 168.97.0.1 to the machine I am using for my installation of the Mercury/32 Mail Transport System. You would assign a host name (it should be a fully qualified, though not necessarily paid for, domain name), such as those noted in the example above. Mercury/32 will use any references it receives for your host (in this case, my host) as the machine responsible for handling mail on the LAN. In the example above, the machine I am using for my LAN mail server is 168.197.0.1. The second IP address (200.200.200.2) is a Class C IP reference to one of the machines on my LAN.

Mercury/32 Protocol Modules
After setting up the Mercury/32 Core Module, we need to set the Protocol Modules. These are the modules that Mercury/32 uses to access POP and SMTP references on your mail server machine.

SMTP services
The SMTP services are what Mercury/32 uses to move e-mail around your LAN to other SMTP servers you may wish to access. Eudora and Outlook 2000 require the SMTP services in order to submit e-mail to your mail server. In simple terms, SMTP is used for your e-mail client’s outgoing mail, and Post Office Protocol (POP) is used for your e-mail client’s incoming mail. Pegasus, Eudora, and Outlook e-mail clients all require a means to deliver and receive your e-mail; SMTP and POP meet this need for you.

Because the SMTP services are so simple to configure, I will simply refer you to my earlier Daily Drill Down that discussed how to install these modules. Once you’ve installed SMTP services, there is no need for you to configure them unless you have special needs in terms of accessing remote SMTP mail servers.

SMTP server
To check your SMTP server, from the menu, choose Configuration | MercuryS SMTP Server. MercuryS is the SMTP Server module. Once you’ve opened your SMTP Configuration window, you will see the following tabs: General, Relay/Connection Control, and Spam Control. Clicking on the Relay/Connection Control tab will give you the dialog box shown in Figure E.

Figure E

You will use the Relay/Connection Control tab to set IP addresses that you will allow or deny the relaying e-mail messages.

Finding your DNS IP addresses
To keep Mercury/32 running in LAN-only mode, you need to disable connection capability with your ISP. This is accomplished by first determining if you have any DNS lookup servers listed that are remote servers. These IP addresses are typically given to you when you install your dial-up networking (DUN) service for NT 4.0. Right-click your Network Neighborhood icon and select the Properties item. Select TCP/IP Protocol and then click the Properties button. You won’t be changing anything here; this is just to remind you which IP addresses are assigned as part of the DNS Lookup Tables. Now, click the DNS tab.

You need to take a look at the section of the dialog box called DNS Service Search Order. The DNS Service Search Order is what your DUN uses to determine where it should pick up any e-mail from the Internet (i.e., e-mail typically handled by your ISP). Mercury/32 uses this same table to determine what you consider to be an authorized SMTP server IP address and what is not an authorized SMTP server IP address. Note that the IP address is typically a Class C IP address.

Since you don’t want Mercury/32 to access any remote DNS Lookup Services, you need to tell your local SMTP server that the IP addresses noted in this dialog box are not allowed as valid relay connections. The only exception to this is the IP address that you’ve assigned to the machine you will use as your mail server. It is this IP address that Mercury/32 will consider an authorized SMTP server.

Restricting servers
Let’s return to the Mercury/32 console Relay/Connection Control tab shown in Figure E. You can see three fields associated with the SMTP services: IP Address, Allow, and Refuse. Mercury/32 allows for fall-through handling; it allows you to either leave these fields blank or to assign some IP addresses.

A completely blank window here means that any and all possible SMTP servers may be accessed. Mercury/32 doesn’t care if those servers are on your LAN or on a remote machine, such as your ISP’s SMTP server. However, if you don’t want Mercury/32 to access your ISP’s SMTP server or any remote server, then you must eliminate any remote servers’ IP addresses from the Authorized SMTP Server List.

Click the Add Restriction button. This will give you a new dialog box (see Figure F), the Edit Connection Restriction dialog box.

Figure F

Click the Add Restriction button to specify an IP address from which to allow or refuse connections.

An IP address set to 0.0.0.0 allows your SMTP server to access any and all remote SMTP servers, limited only by your agreement with your ISP when it comes to using their remote services. To prevent Mercury/32 from accessing your remote SMTP server(s), you must enter the IP address(es) listed in your DNS Service Search Order window that are not part of your LAN IP addressing scheme.

In the Edit Connection Restriction dialog box, enter the first of these restricted IP addresses. You only need to enter the first three octets (sets of numbers) since Mercury/32 will deny access to those you are listing based on those values. If the fourth octet is a zero (0), Mercury/32 will disable any and all machines that are included as part of the set of IP addresses that you are refusing.

Example
Suppose you do not want the Mercury/32 SMTP server to allow any machines on the network that have the following criteria:

1. IP address starts with 204.147.80 and ends with a number between 0 and 255 (Class C IP addresses 204.147.80.0-204.147.80.255)

Thus, when you enter 204.147.80.0 and enable the radio button Refuse Connections From This Address Group, the Mercury Core Module will no longer allow your local SMTP server to accept any SMTP mail deliveries from this group of IP addresses. If you do not restrict the valid IP addresses, the SMTP client will attempt to access all of the IP addresses listed in your DNS Service Search Order.

Configuring SMTP clients
Your SMTP client and its function varies depending on which SMTP Client Module you chose when you installed Mercury/32. There is no need to modify the SMTP Client Module, as the default functionality is sufficient for your basic LAN-only mail server.

POP3 server/client
Your POP3 server and your POP3 client are used to handle e-mail that is sent to your e-mail clients. Whenever your e-mail clients check their mail, it is the POP3 services that facilitate delivery of any mail that may be waiting to be picked up by your e-mail clients, such as Eudora, Outlook 2000, and Pegasus. Before Mercury/32 knows where to send any POP3 mail, Mercury/32 must also know where to store any POP3 mail that is waiting to be delivered.

Setting up POP3 accounts
For Mercury/32 to know where to put POP3 e-mail, you must define each of your local e-mail accounts. Select Configuration from the Mercury/32 menu and open Manage Local Users dialog box. Next you will need to open the Users Defined For This System dialog box, where you will add your POP3 mailboxes (shown in Figure G). These names should reflect the accounts of your LAN users as they will be used by the MercuryD (POP3 client) module to determine where POP3 mail needs to be delivered. The length of the names is not limited if you chose the ~N option while you were configuring your Mercury Core Module. If you haven’t set the ~N option, Mercury/32 assumes that your account names will not exceed eight alphanumeric characters.

Figure G

Use this management dialog box to define local users.

Setting up your MercuryD POP3 client
To set up POP3 clients, from the Mercury/32 menu, choose Configuration | MercuryD POP3 Client. (The General Section of this dialog box was set up when you installed your Mercury/32 Mail Transport System.) You’ll now need to set up your LAN’s POP3 e-mail clients. On the bottom half of the dialog box (see Figure H), you will see an area titled POP3 Account Information. This is the area where you will be entering the names of your POP3 e-mail accounts. The Mercury Core Module adds the @<designation> portion of the e-mail address based on what you instructed the Mercury Core Module to do (see The Name Game section above).

Figure H

You will need to configure your POP3 clients using the MercuryD module configuration dialog box.

Tell the POP3 client what the names of your POP3 e-mail accounts are. Do this by adding the e-mail box name in the area listed as POP3 Account Information. Click Add, and you’ll see the dialog box shown in Figure I.

Figure I

Use this dialog box to enter POP3 mailbox information.

Under the POP3 host name, enter the IP address of the machine that you want the Mercury Core Module to scan for the e-mail accounts you are about to add. Since I am using a small LAN and I want to have all of my POP3 e-mail boxes on the same machine that I use as my e-mail server, I entered the IP address of that workstation in every POP3 Hosts box. The IP address is important as it allows your mail server to decide where it is supposed to place unclaimed POP3 mail. Set up mailboxes like this:

1. Click on the Username box. Enter the account name that will be used by your e-mail client. Unless you have set the ~N option, this account name cannot exceed eight alphanumeric characters.
2. Click on the Password box. This is where you will add the password that you want the e-mail client to use.
3. The Local User box is used to tell POP3 where it should send any e-mail with the name you entered in the Username field. If you choose to leave this field blank, MercuryD will search the To:, CC:, and the BCC: fields of the e-mail it is trying to deliver for a valid username. If you enter a name in this field, then MercuryD will deliver any POP3 mail it receives to that account.
4. The Local User account is the same account that you entered for this user when you began to configure your POP3 mail services client.
5. When you are finished adding your username information, click OK.

Follow the same process above as you configure your MercuryD POP3 client for your other users.

What’s next?
Once you’ve configured the Mercury Mail Transport System, you’re almost ready to enjoy the benefits of this Exchange alternative. Before you can give your LAN’s users the benefit of e-mail support on this workstation-based e-mail server, though, you’ll want to read how to integrate e-mail clients such as Pegasus Mail, Eudora, and Outlook 2000 to work with Mercury/32. I’ll cover that in my final chapter of this series on Mercury Mail Transport System.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.