Page 8 - Mercury Manual.book

3 Overview of Mercury/32
Planning your installation

vide a few common scenarios with suggested installations to match them, although we cannot
stress enough that every installation is different, and these should therefore be regarded as
guidelines only.

The key issue in any installation of Mercury is to decide which Mercury protocol modules
will best suit your needs. In the end, this issue is primarily dependent on exactly how you con-
nect to the Internet and on the services provided by your ISP (Internet Service Provider).

Scenario 1: Permanent Internet connection
If you have a full-time connection to the Internet, for instance using a leased circuit, or a mi-
crowave link, then you will typically install MercuryS to handle incoming mail, and Mercu-
ryE to handle outbound mail. In this scenario, the computer where Mercury/32 is running
needs a permanent IP address and a domain name that is properly advertised by your domain's
authoritative DNS server. The same combination will also typically work quite well if you
are on a permanently-connected network that uses NAT to assign addresses: in this case, you
can only have one SMTP server anywhere on your network - typically MercuryS.

Scenario 2: ADSL or ISDN connection with non-static IP
addresses
If you are using an ISDN or ADSL connection to access the Internet, then you will typically
not have a permanent IP address, which complicates the process of receiving mail somewhat.
The choice of modules you will make in this environment depends on whether or not your
ISP provides what are known as "smart DNS services", in which your computers' domain You can also get dynam-
names are dynamically mapped in real-time to the addresses allocated by your ISP. If your ic DNS services from or-
ganizations like DynDns,
ISP provides this kind of dynamic DNS mapping, you can proceed as if using scenario 1 (see http://www.dyndns.org
above). If your ISP does not provide dynamic address mapping for your hostnames, then you
will need to have your mailboxes located on one of your ISP's systems and download mail
from them using the MercuryD distributing POP3 client module. For outgoing mail you can
usually use MercuryE, although you may save some connection time by using the MercuryC
module and relaying through your ISP's smart host (you will need your ISP's permission and
some configuration on their systems to do this).

Scenario 3: Dialup connection
If you connect to the Internet via an intermittent connection, such as a dialup connection us-
ing a conventional modem, then you will need to use the MercuryD module to retrieve your
mail from POP3 mailboxes stored on your ISP's systems, the MercuryC module to send out-
going Internet mail via one of your ISP's mail hosts (you will need your ISP's permission and
some configuration on their systems to do this), and the MercuryX scheduling module to syn-
chronize these operations on a scheduled basis. In this scenario, your ISP must be ready to
create and maintain POP3 mailboxes for you on one or more of their systems - this is so that
mail can be stored until you are online and available to retrieve it.

Scenario 4: No Internet connection
Even if you do not have any kind of Internet connection, Mercury can still be useful to you
and provide services on your local area network. In this scenario, all mail is local, so you will
typically only install the MercuryS SMTP module (and you may not even need to install this
if your users run Pegasus Mail as their mail client, because Pegasus Mail can interact with
Mercury through a much simpler file-based interface). Using Mercury in an unconnected en-
vironment still gives you access to powerful features like its mailing list management servic-
es and directory lookup functions.