Overview of Mercury/32

Overview of Mercury/32
Introduction
Mercury/32 is a Mail Transport System — a suite of programs designed to move electronic
mail messages from one computer system to another (possibly different) system. Unlike a
user agent, or client such as Pegasus Mail, with which individual users interact to read and
send mail, Mercury is seldom directly encountered by users; its operation is largely invisible
— it is a “black box” running in the background, performing tasks autonomously.
Mercury/32 is divided into a core processing module (MERCURY.EXE) and a set of “service”
components, called protocol modules. Each protocol module supplies a specific service to the
core processing module – for instance, the Mercury SMTP Server Module, MERCURYS, accepts
incoming mail delivery connections and submits them to the core module for processing.
The core module is responsible for routing mail (that is, deciding whether messages are
local or need to be sent to the outside world), and for providing core services such as the autonomous
mail server, mailing list management and error handling.
The following protocol modules are supplied with Mercury/32:
MercuryS – SMTP server module This module is responsible for handling incoming mail delivery
connections from the outside world. It accepts mail and places it in the core module’s
mail queue for processing. MercuryS implements the Internet SMTP standard (Simple Mail
Transfer Protocol) and supports several Extended SMTP extensions.
MercuryC – SMTP client module MercuryC is responsible for sending mail to the outside
world using the Internet SMTP mail protocol. MercuryC is what is known as a relay mailer
– it does not attempt to deliver mail directly to the recipient; instead, it asks a larger SMTP
implementation (often a unix host) to deliver it on its behalf. This relay model makes MercuryC
particularly suitable for use behind firewalls, since it can ask the firewall system to send
mail on its behalf.
MercuryE — SMTP direct delivery module MercuryE is an alternative SMTP client module
for Mercury; like the MercuryC module, it is responsible for sending mail from your system
to the outside world. Unlike MercuryC, though, MercuryE can perform complete end-to-end
delivery without requiring a relay host. MercuryE is typically used in situations where you
have either a permanent Internet connection, or one with fast establishment, such as an ISDN
connection. You can choose to install either MercuryC or MercuryE, depending on your
needs, but you can only install one, not both.
MercuryP – POP3 server module MercuryP listens for connections from POP3 client packages,
such as Pegasus Mail, Eudora or Outlook Express, and provides access to new mail
waiting on the server via the POP3 protocol. MercuryP conforms to Internet Standards Document
RFC1939, including support for advanced commands such as APOP and UIDL.
MercuryD – POP3 client module MercuryD acts as a POP3 client on behalf of one or more
users on your system. Using MercuryD to download mail for your users from an Internet
Service Provider allows you to centralize your Internet connection to the single machine
where Mercury runs – users can see their mail without their own workstations actually being
connected to the Internet or having modems. MercuryD can also retrieve mail from Domain
Mailboxes – that is, single mailboxes where all mail destined for a specific domain gets delivered
– and route the contents to the local users on your system.
You can change the set
of protocol modules Mercury
loads at any time using
the Protocol Modules
option on the Configuration
menu.
2 Overview of Mercury/32
System Requirements
MercuryI – IMAP server module MercuryI allows users running IMAP-capable mail programs
such as Pegasus Mail and Microsoft Outlook to access entire mailboxes of folders remotely.
Where the POP3 protocol only makes new mail available to the remote client, all of
a user's folders can be opened and manipulated using the IMAP protocol. IMAP is also a
common way of providing WebMail services - many WebMail interfaces can connect to an
IMAP server to provide their services.
MercuryX – scheduling module MercuryX is a specialized module that provides scheduling
services: it can be used to start and stop other protocol modules periodically. This can be particularly
valuable when your Internet connection is based on dialup services and is charged
on elapsed time, since it means you can receive and send mail at specific times.
MercuryH — PH directory lookup server MercuryH allows you to publicize addresses using
the Internet PH protocol. You simply create a Pegasus Mail address book and tell MercuryH
to use it, and it will answer queries about addresses and users on your system using information
from that addressbook.
MercuryW — Change password server MercuryW implements the PopPass protocol to allow
your users to change their POP3 mailbox passwords. Common mail clients such as Eudora
and Pegasus Mail support the PopPass protocol.
System Requirements
Mercury/32 requires Windows 98, ME, NT 4.x, 2000, XP, Vista, or Windows Server 2003 to
run: we suggest running Mercury/32 on Windows Server 2003 or XP for best results. We recommend
a minimum of 8MB RAM for Windows 95 systems, a minimum of 32MB of RAM
for Windows NT systems, and a minimum of 128MB RAM for Windows 2000 and Windows
XP systems. A properly installed TCP/IP services layer (implemented in a file called
WSOCK32.DLL) must be installed and correctly configured on the workstation where Mercury/
32 is to run – consult your Windows manuals for information on setting up your workstation
for TCP/IP operation. Mercury/32 has full support for Novell NetWare local area
networks, but you must use genuine Novell workstation client software to take advantage of
this - the Microsoft NetWare client software lacks the full NetWare support required by Mercury
and cannot be used.
Running under Windows Vista
Windows Vista (introduced in February 2007) no longer supports the WinHelp help system
offered in previous versions of Windows. Unfortunately, the help system it does support,
HTMLHelp, is badly broken (because of its reliance on Microsoft’s Internet Explorer engine)
and will not display help files when they are located on a shared volume, a common form of
installation for Mercury/32. This means that under Vista, there is effectively no help system
that an application can use reliably. In the medium term, we will be writing our own help system
to get around this problem, but in the short term, if you use Vista and wish to be able to
access Mercury’s online help, you will need to download WinHelp for Vista from the Microsoft
web site - http://www.microsoft.com/downloads/details.aspx?familyid=
6ebcfad9-d3f5-4365-8070-334cd175d4bb&displaylang=en.
Planning your installation
Before you install Mercury/32, you should spend a few minutes working out what mail services
you need, and how best to configure Mercury/32 to provide them. In this section, we pro-
Mercury has support for
NetWare 3.2 in Bindery
Mode, and for NetWare
4.x, 5.x and 6.x in native
NDS mode.
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 connect
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 microwave
link, then you will typically install MercuryS to handle incoming mail, and MercuryE
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
names are dynamically mapped in real-time to the addresses allocated by your ISP. If your
ISP provides this kind of dynamic DNS mapping, you can proceed as if using scenario 1 (see
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 using
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 outgoing
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 synchronize
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 environment
still gives you access to powerful features like its mailing list management services
and directory lookup functions.
You can also get dynamic
DNS services from organizations
like DynDns,
http://www.dyndns.org
4 Overview of Mercury/32
Using other modules
Using other modules
If your users are not running Pegasus Mail locally, or if you want to access your mailbox from
remote locations (such as hotels, or cybercafes), then you may wish to consider installing the
MercuryI module to provide IMAP services. MercuryI is also a useful back-end service provider
for many popular webmail interfaces, such as Twig, SquirrelMail, and Horde/IMP.
If you want to provide remote access to users' new mail folders via the POP3 protocol, you
will typically install the MercuryP module. This is primarily useful if you have users who use
a mail program that does not support the IMAP protocol.
If you want to provide address lookup services, you may want to consider installing the MercuryH
module: popular mail programs such as Pegasus Mail and Eudora support the PH protocol
offered by MercuryH.
If you want to allow your user to change their passwords remotely, you will typically install
the MercuryW module. Your users must be running a mail program that supports the POPPass
protocol to be able to use this facility – Pegasus Mail and Eudora do, but Outlook does
not.
Installing Mercury/32
As supplied, Mercury/32 will typically be packaged in a self-extracting, self-installing archive
called M32-XXX.EXE, where XXX is the version number of the program. Simply run
this archive and follow the prompts to install the program. The installer will prompt you for
the information it needs on a step by step basis, and each step has extensive online help. You
can change any aspect of the installation from within the program after installation is complete,
so if there are specific areas that you don't understand or where the help is insufficient,
you can always adjust them later.
Under normal circumstances, the installer will create a basic working Mercury/32 setup for
you, but the program is enormously rich and configurable, so you will almost certainly want
to change aspects of its operation after installation – that is the focus of much of the remainder
of this manual.
Running Mercury/32
There are two ways you can run Mercury/32 – either by selecting the Mercury/32 shortcut
created for you in the Windows Start menu by the installer, or by using the Mercury/32 loader:
the loader program starts Mercury/32 for you, then sits in the background; if there is a
problem with Mercury/32, or if you instruct Mercury/32 to exit once a day (you can do this
in the program's preferences) the loader will wait a few seconds then restart the program for
you automatically. The choice of run method depends on your needs and preferences, but our
opinion is that it is probably best to run Mercury via its loader instead of directly.
Note that the Mercury loader program will only attempt to reload Mercury a maximum of six
times in any 60 minute period: if it has to restart the program more often than this, then it will
assume that there is something terribly wrong (typically a major misconfiguration) and will
give up.
The latest versions of
Mercury are always
available from our home
web site,
http://www.pmail.com
5 Overview of Mercury/32
Running Mercury/32
Running Mercury/32 as a service:
Windows NT, 2000 and XP support a concept called a Service, or a special type of process
that runs in the background in a space separate from the desktop and the user. Mercury/32
currently cannot operate as a native service, but there are third-party tools, such as Microsoft's
SRVANY program (available as part of the Windows NT Resource Kit), which can be used
to run Mercury in this way. Running the program as a service has some trade-offs, especially
if you are using either of its NetWare-specific personality modules, and as a result, installation
of Mercury/32 as a service using a third-party tool should only be attempted by experienced
network administrators.