Background:
There is no single right way to install Pegasus Mail for Windows (WinPMail) and Mercury/32 in multi-user standalone mode or in a non-NetWare network (such as WinNT, Lantastic, Win95/98 peer-to-peer, etc.). However, we do recommend that you use a network with advanced rights capability, like WinNT or NetWare or Lantastic. When you use Win95/98 peer-to-peer technology, you are limited to only three possible security rights: none, read-only, and full access. To provide the best security, your network must also support add/create rights (sort of an "incoming" or "drop-box" right that allows you to create files in a directory, but not see anything within in the directory, including the file you just created. Create rights are used by WinPMail in order to deliver mail directly into other local user's mailboxes and to spool outgoing SMTP messages to Mercury/32. If you decide to not allow users to send mail directly to other local users (forcing them to go through Mercury/32 instead) and do not care whether or not users can view spooled outgoing SMTP messages from all users on the system (or if you plan to force all users to send outgoing mail to Mercury/32 via the built-in SMTP client feature), then a Win95/98 peer-to-peer network will do just fine.
For SMTP mail, Mercury/32 can either be configured to:
- receive incoming mail directly from other Internet mail hosts; or
- use POP3 to download mail from one or more POP3 mailboxes (including domain mailboxes) on your ISP's mail host.
The method you decide to use above normally depends upon the type of Internet connection you have. Having a full-time Internet connection (even if only a dial-up 56K modem connection that is always active) is the most versatile, allowing you to choose either option above, although using Mercury/32 as your SMTP server for incoming mail instead of using your ISP's POP3 server would be the preferred method of operation. Even if you choose to use Mercury/32 as your SMTP mail host, you should still request that your ISP's mail host serve as a secondary backup mail host on behalf of your domain in case your server or connection goes down; this allows incoming mail to queue up on the ISP's server and when your connection is re-established, the ISP's server can quickly transfer the mail to Mercury/32. Full-time connections include full-time dial-up regular modems or ISDN modems, cable modems, xDSL modems, frame relay, T1 or T3 leased lines, etc. Note that you'll also need a fixed IP address for your Mercury/32 machine so that it can be assigned to your domain name for incoming mail.
If you can only afford a standard part-time dial-up modem connection, then you'll most likely be using the ISP's mail host for POP3 mailbox services using either separate POP3 mailboxes for each user (preferred to reduce the chance of mis-directed mail and to enhance privacy/security) or a single POP3 domain mailbox that stores all incoming mail for your network. Domain mailboxes may have a limited number of defined aliases (or usernames) that can be used with the domain (attempting to use any other alias username would fail) or may be unlimited, allowing any username to be used whether or not that username actually exists in your network.
POP3 domain mailboxes can be problematic when a message's recipient list is suppressed, such as in the case of receiving mail from mailing lists as well as spam mail. In such cases, manual intervention by the default user (usually your network's sysadmin) will usually be required in order to redirect the message to the appropriate user.
If your ISP's SMTP mail host supports the ERTN standard and your ISP is willing to queue incoming SMTP mail on behalf of your network, then you can have Mercury/32 send an ERTN command to the SMTP host immediately after the dial-up Internet connection becomes active so that the SMTP host will know it can start transferring any queued incoming SMTP mail it has for your network. In this scenario, incoming SMTP mail is queued on your ISP's host while your Internet connection is down. If supported by your ISP, this solution is much better than using POP3 mailboxes on your ISP's mail host.
You also need to decide whether to have Mercury/32 simply relay all outgoing mail to your ISP's mail host (using the MercuryC SMTP relay module) or to have Mercury/32 actually attempt the transfer of outgoing mail to the recipients' mail hosts (using the MercuryE SMTP end-to-end delivery module). The MercuryE module requires that you have access to a DNS name server in order to perform DNS domain host name resolution. Due to the abuse of mail relaying by spammers (those who send unsolicited commercial junk e-mail), most ISPs use anti-relay code on their SMTP hosts; thus, you'll need to ask whether or not your ISP to allow mail relaying from your domain if you decide to use the MercuryC SMTP relay client. MercuryC has the advantage of pumping messages out very quickly to the SMTP relay host, which is helpful in locations where time online or on the phone is an extra expense. MercuryE has the advantage of not having to mess with an ISP's policy and particular (possibly proprietary) implementation for relaying SMTP mail through their mail host. However, MercuryE requires more online time for delivery since it has to lookup the domain host names for the recipients and actually transfer the outgoing messages separately to each recipient's mail host.
Preparation:
Once you've determined the type of Internet connection and mail technology you're going to use, you need to determine where you will store the user mailboxes and on which machine you will install Mercury/32. The user mailboxes normally need to be on a generally accessible machine (usually a server) that is always running and to which all users have the required rights to work with their mailbox and (optionally) to deliver mail to other local user mailboxes. The rights requirement above doesn't apply if all users will be accessing their mailboxes via POP3 and/or IMAP4. This machine should be fast (although any Pentium PC capable of running a Win32 OS will generally do fine for small installations of up to 25 users), have plenty of disk space available, and be able to handle the large number of network connections that will be accessing files from its drive(s) and polling the mailboxes for new messages. Note that IMAP4 places the largest amount of load on the Mercury server in terms of network and disk activity as well as memory usage. Content control, filtering rules, and policies (especially anti-virus policies) cause the most CPU utilitization and cause the most delay in processing incoming mail.
Mercury/32 usually must be installed onto the PC that has the dial-up modem, if applicable. If there are multiple PCs with modems, you might want to pick the one on which the user mailboxes reside for quicker response time and higher reliability. If you happen to have an external dial-on-demand dial-up router providing your Internet connection and you have IP addresses defined on your network, then you can install Mercury/32 on any Win32 PC on your network. Mercury/32 requires full rights to the user mailboxes as well as to the Mercury queue directory. Such rights normally mean that Mercury/32 should either be installed onto an NT server as a service, on the sysadmin's PC, or onto a secured machine. Mercury/32 can be installed as a service under Windows NT using the SRVANY utility available from Microsoft.
WinPMail can be either installed on all the workstations or just on a central file server with WinPMail shortcut icons created on each of the user workstations.
Installation:
Start by installing WinPMail (if applicable to your environment) onto your workstations or onto a central file server. For increased performance, you may install WinPMail on each of the workstations. However large sites may want to use central file servers to save the time of installing onto each individual workstation and for easier upgradeability to newer versions and patch installations.
While logged in on one of the workstations with administrative rights over the network to the "mail server" machine, run WinPMail. When prompted for the type of installation (single-user or multi-user), choose a "multi-user network" installation. When prompted for the root mailbox directory path, type in the UNC path to root directory of the multi-user mailbox on the "mail server" machine. WinPMail will create the directory structure if it doesn't already exist. e.g.
\\mailpc\c-drive\mail
WinPMail creates a PMAIL.CFG configuration file in the WinPMail program directory once you've completed this step of the configuration process. Rather than having to respecify this configuration on each of the other workstations in your network, you can simply copy this PMAIL.CFG file to the WinPMail program directories on each of the other workstations (if applicable).
Next, you will be prompted to create each of your users. A list of these users will be created in a PMAIL.USR file in the root mailbox structure (e.g. \\mailpc\c-drive\mail). You need to create at least one administrative user account so that you can run WinPMail with that account and perform future user management functions (such as adding, modifying, or deleting users). WinPMail uses the usernames as the user mailbox directory names. e.g.
user1 ---> \\mailpc\c-drive\mail\user1
Additionally, WinPMail is normally limited to using 8-character dos directory names (for compatibility with Win16 and DOS systems), so each of the usernames you create may need to be 8 characters long or less. WinPMail won't allow you to create usernames longer than 8 characters; you also cannot use spaces nor other characters in the username that would be considered illegal in a dos directory name. While this may all seem limiting, you can get around the limitation to provide such extravagant e-mail addresses as firstname.lastname@domain.com by using synonyms, which will be discussed later in this document.
Note: Mercury allows you to create usernames and mailbox directories longer than 8 characters. If you plan to be using Mercury in your Pegasus Mail environment, you must use Mercury to manage the local users.
You should then assign network rights on the "mail server" machine for each of your users. Users will require full rights to their own mailbox directory (e.g. \\mailpc\c-drive\mail\user1), read rights to the root mailbox structure (e.g. \\mailpc\c-drive\mail) in order to be able to read the PMAIL.USR user file, and (optionally) create rights to each of the mailbox subdirectories below the root mailbox structure so that they can send mail locally to other users. You can use the Everyone group or another mailusers-related group to assign rights for all users. At this point WinPMail is fully set up for local internal mail purposes.
For SMTP/POP3 mail services, you should now install Mercury/32 onto the "SMTP gateway" machine. Choose New Installation when prompted and then choose No NetWare Support. Next the installer will ask you for the path into which to install Mercury/32. By default Mercury/32 will be installed into the C:\MERCURY directory and will contain a C:\MERCURY\QUEUE subdirectory for outgoing queued SMTP messages. Since WinPMail on each workstation needs to be able to write outgoing messages into the queue subdirectory, you might need to reconfigure Mercury/32 to reference a queue directory on the "mail server" machine instead (we'll explain how to do this later on).
The installer will next ask you to type in the directory path to the WinPMail program so that a PMGATE.SYS Mercury gateway definition file can be created within the WinPMail program directory to allow WinPMail to integrate with Mercury/32. If you have installed WinPMail locally on all your workstations, you'll later need to copy this PMGATE.SYS file to the WinPMail program directory on each of your workstations.
If you specified the correct directory above for the WinPMail program files, the next prompt concerning the mailbox directory location should already point to the proper directory where the root mailbox directory structure is location on the server. The path here can be entered in as a UNC network path or a local drive path if the mailboxes actually reside on the Mercury/32 machine.
The next installation dialog window prompts you to check those protocol modules of Mercury/32 that you wish to use. There are currently ten different modules to Mercury/32:
- Mercury core module (always required, not listed in this dialog)
- Mercury SMTP Server module (MercuryS)
- Mercury SMTP Relay Client module (MercuryC)
- Mercury SMTP End-to-end Client module (MercuryE)
- Mercury POP3 Server module (MercuryP)
- Mercury POP3 Client module (MercuryD)
- Mercury Task Scheduling module (MercuryX)
- Mercury Finger Server module (MercuryF)
- Mercury PH Query Server module (MercuryH)
- Mercury PopPass Server module (MercuryW)
Note: The two SMTP Client protocol modules listed above are actually prompted for in the next dialog rather than in this dialog. There is a "?" Information button next to each module to give you more info about that module.
So which protocol modules do you select? Well, you can usually select all of them without adverse problems, just in case you decide to use one later. It's also simple enough to add a module in later on by modifying the MERCURY.INI file in the Mercury/32 program directory with a text editor like Windows Notepad and adding a statement for the respective protocol module's dll file within the [Protocols] section. Knowing this, you can decide initially to only install those modules you really know you need. If you have a full-time Internet connection, you will most likely need only MercuryS and MercuryC or MercuryE. If you have a dial-up connection and are using SMTP with ERTN , you need MercuryS, MercuryC, and MercuryX. If using POP3 mailboxes over a dial-up connection, you'll need MercuryC, MercuryD, and MercuryX. If you will have users dialing into your network from home to download their new mail mail via POP3 or some of your users run a different POP3 mail client or run WinPMail remotely from another location over your full-time Internet connection, you'll also need the MercuryP and MercuryS modules (regardless of the type of Internet connection you have). The MercuryF, MercuryH, and MercuryW modules are all optional. MercuryF provides a FINGER server capability similar to those found on unix systems. MercuryH provides a CSO-PH directory service ability that can be configured to use a Pegasus Mail address book as its directory source and that can be accessed by Pegasus Mail's or some other PH directory client. The MercuryW module provides a way for users to remotely change their mailbox password (useful if users access their WinPMail/Mercury mailbox remotely via POP3).
After selecting the desired protocols, the next dialog prompts you for which SMTP Client protocol you wish to use: MercuryC SMTP Relay Client or MercuryE SMTP End-to-end Delivery Client. After selecting the desired SMTP Client protocol, the next step of Mercury/32's installation regards setting up the basic working configuration. You'll need to know or obtain the following info from your ISP:
- the host name or IP address of this Mercury/32 machine (it can also just be your domain name).
- WinPMail username to use as your local Mercury Postmaster.
- the host name or IP address of your ISP's SMTP relay host, if you will be using the MercuryC SMTP Relay Client.
- which level of anti-relaying to enable, if any (only required if MercuryS is installed). Normal anti-relaying is usually sufficient. Other options include Strict and None.
The last thing the installer needs from you is the directory path to the mail queue location. This path is used by both Mercury/32 and WinPMail. We recommend that the queue directory reside on your "mail server" PC; you should use a UNC network path to reference it (e.g. \\mailpc\c-drive\mail\outgoing).
Once the installation is completed, you should copy the PMGATE.SYS file (mentioned earlier) to the WinPMail program directory on each workstation. If you want to first verify that the PMGATE.SYS gateway definition file is okay before copying it to all of your other workstations, run
PCONFIG.EXE -S
within the WinPMail program directory where the PMGATE.SYS file was created and go to the user-defined gateways section. You shoud see an entry for MERCURY. When you view this MERCURY gateway definition, you should see a screen similar to the following:
Gateway name : MERCURY
*New mail path :
Is ^ a program to run? : N
*New mail search mask :
*Outgoing mail path : \\mailpc\c-drive\mail\outgoing
*Run for outgoing mail :
*Filename format : ~d~d.101
Run to validate address :
*Reply address format : "~p" <~L~L~8@domain.com>
Accepts SMTP addresses? : Y
Simple message headers? : 'Glue' headers
UUEncode attachments? : Y
Burst messages? : N Gateway processes BCC? : N
Strip gateway name? : Y
Force all mail through? : N
Make sure the Outgoing mail path specifies the UNC network path to your Mercury/32 spool directory, as seen by your workstations. Also check the Reply address format field. This field shows you how your From: header will look on outgoing SMTP mail messages. The "~p" represents your full name, as defined within the Personal Name field within the General Settings options of WinPMail. The two "~L" sequences can optionally have a filename between them referencing a synonym file (SYNONYM.MER is the default filename if none is specified, as shown above); the synonym file should be placed into both the Mercury/32 program directory as well as the WinPMail program directory wherever it is installed (on central file server and/or on all of the workstation PCs). More about synonyms shortly. The "~8" represents your WinPMail username (8-char max). Make sure the host name given after the "@" (e.g. "domain.com") is listed exactly how you want it to look in e-mail address. e.g.
"John Doe" <user1@domain.com>
If this form of e-mail address formation is too restrictive for you or you need to map POP3 user aliases to WinPMail usernames or you wish to standardize on a formal username structure, like "Firstname.Lastname", you can set up personalized synonyms for each user so that their username looks however you need it to look. e.g.
Jonathan.Doe@somedomain.com == jdoe
POP3-username@domain.com == User1
If you wish to create synonyms for your users, read further below in the section entitled Synonyms.
You can also set up aliases within Mercury/32 so that incoming mail to certain e-mail addresses will be redirected as necessary to either local or external addresses. e.g.
support@domain.com ---> fred
someone@domain.com ---> ex-employee@another.company.com
Note that aliases have no effect on how the From: field looks in outgoing messages--although you can reference your alias address as your default reply-to address.
If you wish to create aliases for your users, read further below in the section entitled Aliases.
At this point, the general setup of WinPMail and Mercury/32 is complete. However, there is much more required to get Mercury/32 operational, such as configuring MercuryD for POP3 downloads from your ISP's mail host, setting your timezone value (we recommend just enabling the Auto setting), configuring the MercuryX task scheduler to set up dial-up intervals, etc. These topics are covered below.
Configuring MercuryD to download POP3 mail from your ISP's mail host:
If you will be using POP3 mailboxes on your ISP's mail host, you'll need to configure the MercuryD POP3 client module to download your users' POP3 mail. The POP3 account information section lists the different POP3 accounts you've defined already. Each entry can be configured for one of two possible types of POP3 accounts:
- a regular single-user POP3 mailbox account, or
- a POP3 domain mailbox account.
It's quite possible to have both types of POP3 mailbox accounts defined within MercuryD's POP3 Account Information list.
To configure a single-user POP3 mailbox account, you'll type in the host name or IP address of your ISP's POP3 host, the POP3 port number used by the POP3 host (defaults to 110 if left blank), the POP3 username and password for this mailbox, and the WinPMail local username for which this POP3 mailbox belongs. The Default User field should be left blank.
To configure a POP3 domain mailbox account, you'll type in the same info as above, but leave the Local User field blank. This will force Mercury/32 to scan the To:, CC:, and BCC: message header fields of the POP3 messages to locate any e-mail addresses it recongizes as local users (it also scans against the Mercury synonym file and alias file when determining if an address is local). Any messages for which a local user cannot be found is discarded, unless you type a local username into the Default User field, in which case these messages will be delivered to the default user for manual distribution or deletion.
Configuring the MercuryX Task scheduler:
The MercuryX Task Scheduler module has the job of coordinating the online/offline periods of Mercury/32's modules as well as starting and disconnecting the dial-up connection. We recommend that you enable the two checkbox options to "Use Win98/MS IE 4 dialling functions" (WinInet.dll) for both dialing before and hanging up after.
If you'd rather use an external dialer utility to dial and/or disconnect the connection or when you need to dial a DUN connection other than the default one or if you don't have access to WinInet.dll, Mercury/32 includes an external utility in the RESOURCE subdirectory called RASDIAL95 that can be used for this purpose, or you can choose your own external RAS dialer.
It is usually also a good idea to enable the option to allow the processes to finish completely (drain) before disconnecting (there is a max wait timeframe though, in case a process gets locked up).
If you will be using the MercuryS SMTP Server module along with an ETRN mail queue on the ISP's mail host, you'll need to enable the SMTP ETRN (RFC1985) checkbox to start the remote queues when MercuryX goes online. Click on the Specify button to modify the ETRN.DAT configuration file within the Mercury program directory. The syntax of the ETRN.DAT file is as follows:
Supplier SMTP host name
Your SMTP host name (as your provider expects it to be)
(Make sure the second line is indented with at least one space or a tab character.)
For example,
mail.isp.com
mail.local.domain.com
The last configuration item for MercuryX is setting up the actual schedule. You can set a separate schedule for each day of the week and you can effortlessly copy schedules from one day to another day if you want to set up multiple days with the same schedule.
To set up a schedule, pick a day of the week first. You have the ability to schedule two different sets (peak and off-peak) of start intervals and connection durations. Be sure to specify all times in 24-hour military time. e.g.
11:05am == 1105
5:30pm == 1730
Specifying an interval of 0 leaves the connection active continuously throughout that specific (peak or off-peak) schedule set. Setting it to -1 will disable any connection activity throughout that period of time.
Synonyms:
Many sites need to use custom address formats where the user's e-mail address is quite different from the actual user name on the system. For example, you may want your addresses to have the form Firstname.Lastname@host.domain. Simple aliasing won't allow you to do this kind of addressing easily; it will handle incoming mail well enough, but in order to get mail going out from your system to use the alternative address forms requires the co-operation of your mail client.
Pegasus Mail and Mercury/32 can combine to support alternative address formats like this (referred to as synonyms) using a special database called a synonym database: Mercury needs this database so it can work out the recipient for incoming mail, while Pegasus Mail needs it to work out what address it should write into outgoing messages for this user. Here are the steps to configure Pegasus Mail and Mercury/32 for synonyms in non-NetWare mode:
- Create a synonym source file (e.g. SYNONYM.TXT). This is a text file where each line has the form:
synonym@domain.com == username
So, on the right-hand side you place the user's local name, and on the left-hand side his or her e-mail address as you want it to appear in outgoing mail. Note that each line must begin hard against the left-hand margin.
- Compile the source file using the FSYNONYM.EXE commandline program. FSYNONYM.EXE takes your input file and creates a synonym database file. This file is included with Mercury/32.
- Copy the synonym database somewhere accessible by Mercury/32 and make sure the Synonym database file entry of the Files tab preferences page of the Mercury/32 core module configuration dialog refers to that file.
- Copy the synonym database file into the same directory as your copy of the Pegasus Mail executable file (either WINPMAIL.EXE or WINPM-32.EXE), making sure it is called SYNONYM.MER. If Pegasus Mail is installed locally on all the user workstations, you'll have to copy this file to each of the workstations.
- [Only required once] If you didn't see a MERCURY user-defined gateway definition specified earlier when running PCONFIG.EXE -S, you can use the Pegasus Mail option on the Mercury/32 configuration menu to configure your copy of Pegasus Mail. This operation is only required if you have upgraded your copy of Mercury/32 from an earlier version or have never installed Mercury/32 until now, and only needs to be done the one time: it creates a new version of PMGATE.SYS that instructs Pegasus Mail to use the synonym file (SYNONYM.MER) if it exists in the Pegasus Mail program directory. If Pegasus Mail is installed locally on all of the user workstations, this PMGATE.SYS file will also need to be copied to each of the workstations.
Aliases:
An alias is a virtual e-mail address that stands in for another e-mail address on your system for incoming mail only. Aliases are often used to create addresses which do not vary, even though the person who receives the mail may change. For example, say you want to offer your customers an e-mail address they can use to obtain support; it is clearly much better to use an address like support@mydomain.com than to give the address of a specific user on your system (like Fred@mydomain.com). That way, if the user leaves or is transferred, you can simply redirect the alias for "support" to someone else without having to contact all of your customers to change the e-mail address required for support. It also is useful for when a user's name has changed (e.g. marriage/divorce) or when a user's name is easily mispelled and you want to provide alternatives that match the most common mispellings (e.g. Villarreal, Vilareal, Villareal, etc.).
A synonym is a specialized form of alias that effectively replaces a user's real e-mail address with an alternative form. Using synonyms, you can adopt consistent addressing schemes that differ from your users' actual login names. For more information on creating and using synonyms, see above in the section about Synonyms.
Mercury/32 has very powerful aliasing features: you can access them either from the Configuration -> Aliases... menu option, or by using the commandline import/export tool MALIAS.EXE supplied with Mercury/32. An alias simply consists of two parts - the alias (or, the address people use to send mail) and the real world address (the address to which Mercury should deliver any messages it receives addressed to the alias). The real world address does not have to be a local address - it is perfectly valid to have an alias for an address on a remote system (this approach is often used to redirect mail to someone while they are absent, or if they leave the organization).
Keywords: WINPMAIL WINPMAIL/16 WINPMAIL/32 MERCURY/32 INSTALL INSTALLING INSTALLATION CONFIGURE CONFIGURING CONFIGURATION WINDOWS NT WINNT LANTASTIC PEER NETWORK
Date Created:
|
7/1/2000, 8:36:31 PM
|
Last Updated:
|
9/26/2004, 1:33:36 PM
|
Document ID:
|
C1523317-4EC6-11D4-8B6B0008C709E5EC
|
