Contents
Using Pegasus Mail and Mercury in NDS Mode on Novell NetWare™ 4.1 Servers

This help file gives details of how Pegasus Mail and Mercury work on NetWare 4.1 servers in full NDS mode. It includes step by step instructions on setting up both programs and discussion of the way the programs interact with NDS.

What is Pegasus Mail?

What is Mercury, and why do I need it?

Overview

Step by step setup guides - choose one of the following:

Installing Pegasus Mail only (no Internet mail via Mercury)

or

Installing Pegasus Mail for local mail, Mercury for Internet mail

or

Installing so that Mercury handles all mail on the system


What is Pegasus Mail?

Pegasus Mail is an electronic mail system that has in depth support for the Novell NetWare environment. Its awareness of the underlying NetWare architecture and its ability to make NetWare system calls means that it is a very powerful, yet low-maintenance system in that environment.

Pegasus Mail has separate support for Novell's older Bindery mode servers - NetWare 3.x and earlier, and also for Novell's NDS mode servers - NetWare 4.1 and later. This document describes how to configure the Pegasus Mail plugin module that allows it to support the NDS environment. If you want to run Pegasus Mail on a Bindery mode server, such as NetWare 3.12 then you do not need this file or the contents of this archive - please consult the file WGUIDE.HLP supplied with Pegasus Mail for details on using Pegasus Mail in the Bindery mode environment.


What is Mercury and why do I need it?

Mercury is a set of programs that run on your NetWare file server to provide access to Internet mail services for your Pegasus Mail users. Mercury talks the Internet SMTP and POP3 protocols to exchange mail with other Internet hosts on behalf of your Pegasus Mail users, and also offers a wide range of automated mail service functions, such as mailing list management, mail services (file retrieval, user listings and so on). Because the Mercury NLMs run on your file server, they are always available and because they handle the low-level protocols, your workstations do not need to have specialised TCP/IP protocol stacks loaded.

Mercury is particularly NetWare-aware and is designed to integrate seamlessly and effortlessly with your Pegasus Mail users. Different versions of Mercury exist for older NetWare Bindery mode servers, such as NetWare 3.12, and NetWare NDS servers, such as NetWare 4.1. This document describes how to use Mercury with NDS mode servers - if you want to load Mercury on a NetWare 3.x server, you do not need this archive - instead, please consult MGUIDE.EXE, the online guide supplied with the standard Mercury distribution.


Operational Overview
Overview

Description and operating requirements

An overview of the installation process

Contexts and operation

Addresses

Synonyms (alternative addressing formats)

Installing Pegasus Mail for Windows in NDS Mode

Installing Mercury in NDS Mode

Allowing Local User Lookup

Extended Features

Security Considerations

POP3 server considerations

Troubleshooting


Description and Operating Requirements

In NDS mode, Pegasus Mail no longer uses the old NetWare 3.x SYS:MAIL directory structure to deliver and store mail: instead, it expects to deliver mail to a directory called PMAIL in each user's home directory on the file server. The MAKEMBOX utility creates the necessary directories for existing users, while the PMUSER NLM creates them automatically for each user that is created in future. The aim is to produce a system that is as nearly maintenance-free as possible, and to isolate Pegasus Mail from further disastrous changes in Novell system policy in future. Clearly, though, there are a couple of specific requirements that must be met in order to make this work:

* All mail users must have a writable home directory in which they have full rights.

* PMUSER.NLM must be run on every file server containing a partition where Pegasus Mail users could be created.

Operating requirements

Systems: NetWare 4.1 and later are the target platforms. Neither Mercury nor WinPMail are guaranteed to work under NetWare 4.0 or 4.01, although they may do so (we have not tested them in these environments and do not support them). Client workstations must be running the VLM shell v1.2 or later, or the Novell Client-32 Requester or the Microsoft Service for NetWare Directory Services driver.

Mercury currently uses two connections on the file server where it runs, and will establish one connection to every server on the network where it is required to deliver mail. In NDS mode, a fully-configured copy of Mercury may use up to a total of 300KB of server memory.

PMUSER.NLM uses one service connection and about 10KB of server RAM in normal use, and introduces almost no load on your server when it is idle. PMUSER.NLM is not required if you use the NDS-Aware version of Mercury to handle all of your mail delivery, since Mercury can duplicate the functionality of PMUSER. Running PMUSER, however, allows Pegasus Mail's local delivery agent to function normally, just as it always has under NetWare 3.x and earlier.


Overview of the installation process

Because NetWare 4.1 does not have some of the features of NetWare 3.x that made it possible to create a maintenance-free mail system, some extra work is required to set it up for optimum use, so you should take the time to familiarise yourself with this document thoroughly before attempting the installation.

In brief, installing Pegasus Mail for Windows entails following these steps:

* Install WPNNW4.DLL into the same directory as WINPMAIL.EXE

* Make sure current versions of the Novell API DLLs are installed on your system

* Run the NDS-Aware version of PCONFIG to configure WinPMail for each context on your server that needs its own configuration.

* Run the Pegasus Mail MAKEMBOX utility to create user mail directories as required in each configured context.

* [Optional] Run the PMIGRATE utility to copy the mailbox contents of any user who has previously run Pegasus Mail in Bindery Emulation mode on your server to the new mailbox location.

* Install PMUSER.NLM, the mailbox maintenance utility, on your file server.

* [Optional] Make a small change to NDS to allow local user lookup (see section 7 in this file).

Installing the NDS-Aware version of Mercury on your file server is a

simpler process requiring these steps:

* If you have never installed Mercury before, run SETUP.EXE

-- or --

* Install MERCNDS.NLM and MERCNDSS.NLM in SYS:SYSTEM

* Add a couple of new sections to your MERCURY.INI file

* [Optional] Install MERCNDSP.NLM in SYS:SYSTEM for POP3 support.

Installing Pegasus Mail and Mercury in NDS mode is slightly more complex than it is in Bindery Mode, but the ultimate aim is to produce a system with little or no ongoing maintenance or management requirement at the expense of a small amount of relatively simple extra initial setup and configuration.


Contexts and operation

NDS provides a tree structure which can contain many organizational units. Pegasus Mail's NDS-awareness supports the full idea of NDS, allowing different configurations for specific organizational units within your NDS tree. You can also create configurations that apply to a particular subtree of the NDS hierarchy, or even to the whole NDS tree by choosing where you place the configuration information.

To find its configuration information, Pegasus Mail starts in the user's "Home context" - the organizational unit in the tree where the user was created, and looks for a "Profile" object called "Pegasus Mail". If it finds it, it parses the object's "Login script" attribute for its configuration information. If it does not find the object, it changes up one level in the NDS tree and repeats the search. The search continues until either a configuration object is found, or else the root of the tree is reached without finding a record. The NDS-aware version of PCONFIG creates and maintains the "Pegasus Mail" profile object for you, ensuring that all users have the rights necessary to be able to read its login script. The Profile Object Pegasus Mail uses is, however, a standard NDS data type, and can be easily manipulated using standard Novell tools such as NWADMIN or NETADMIN, provided the user doing so has sufficient rights.

Unlike running in NetWare 3.x mode, Pegasus Mail MUST find at least one configuration record somewhere in the tree or it will refuse to run. The context where Pegasus Mail finds its configuration record is known as the Configuration context and is important for other reasons: Pegasus Mail's control groups, such as GROUPMAIL, MAILUSERS and NOMAIL must all be located in the configuration context in order to operate. Similarly, a simple mail address, such as "Peter" is presumed to be relative to the configuration context. This brings us to the next topic, addresses.


Addresses

Just as it does under NetWare 3.x, Pegasus Mail uses the native NetWare user naming structure when running in NDS mode. So, you can enter addresses like "Admin.pmail", or "CN=Admin.O=PMAIL" and Pegasus Mail will accept these as normal addresses, routing the mail as required. You can also use "relative addresses" - so if there is an organizational unit called "Dev" in the configuration context and it contains a user called "David", you can use "David.Dev" as an address as well.

For Internet mail using Mercury, you can attach different Internet domain names to any organizational unit in your NDS tree. A user's Internet mail address on the server is simply his Common Name, or CN, or login name, with any spaces changed to underscores.

Example:

You have a user CN=Joe User.OU=Dev.O=Acme. You have told Mercury that the Internet domain develop.acme.com should be used for users in the NDS context OU=Dev.O=Acme Joe User's Internet address is Joe_User@develop.acme.com.

Provided you install Pegasus Mail correctly in NDS mode, it can easily act as a low-maintenance enterprise-wide mail system providing mail services to all users throughout your NDS hierarchy.


Synonyms (alternative addressing formats)

Many sites have policies mandating that particular addressing formats should be used in their outgoing Internet mail - for example, a site may want its users' Internet addresses to consist of their initials and surname, like this: D.L.Harris@pmail.gen.nz. Basic address changes like this are beyond the scope of simple aliasing - they require the co-operation of both the mail program (Pegasus Mail) to ensure that the "from" field of the message is written properly in outgoing mail, and also of the Mail Transport System (Mercury) to ensure that incoming mail using the alternative address format is routed to the proper user. In the Pegasus Mail and Mercury systems, an address of this kind, which is completely different from the user's actual login name, is called a Synonym.

Creating synonyms in NDS mode is an easy two-stage process. The first stage involves using standard NetWare tools to give users their synonyms, while the second stage involves running a utility supplied with this archive to build a reverse lookup database allowing Mercury to match synonyms to their users. Note that using synonyms is NOT an all-or-nothing process - you can define synonyms for only some of your users if you wish. To create synonyms under NDS mode simply follow these steps:

1:  Run the NetWare NWADMIN utility. Open the details screen for the user whose synonym you wish to set.

2: Select the Foreign Email Address button at the right of the dialog

3: Click the Set button beneath the Foreign Email Address field

4: Type in the address you want the user to have - the address can contain a domain if you wish, but if you do not add a domain, Pegasus Mail will add the proper domain for you.

5: Set the Type field to SMTP.

6: Save the entry.

Repeat steps 1 to 6 for as many users as need synonyms. Once you have finished adding synonyms, start a DOS shell and run the NSYNONYM.EXE utility supplied with this archive. This utility processes the information in the NDS tree and builds a reverse synonym database Mercury can use to match incoming synonyms to the proper users. NSYNONYM has the following syntax:

NSYNONYM <starting_domain> <synonym_file> [SUB]

Starting_domain is the point in your NDS tree at which NSYNONYM should start looking for users with synonyms defined. You can enter [Root] here if you want NSYNONYM to process the whole NDS tree.

Synonym_file is the name of the database file NSYNONYM should create: this will be the same file you have defined in the Synfile entry of the [Mercury] Section of your MERCURY.INI file. You should always delete the existing file before running NSYNONYM.

[Sub] If you add the word "sub" at the end of the NSYNONYM command line, it will search in all contexts below the starting context for users with synonyms.

Example: to have NSYNONYM create a synonym database for all users in the context Dev.PMail and in all contexts below that and write the results to the default synonym database file, you would use the commandline:

NSYNONYM Dev.PMail \\SERVER\SYS\SYSTEM\MERCURY\SYNONYM.MER sub


Installing WinPMail in NDS Mode

This section gives detailed instructions on installing Pegasus Mail for Windows in NDS mode on your NetWare 4.1 server. It goes into more detail and explanation than the step by step procedures provided in this guide. If you would sooner follow the step by step guides, click here.

To install WinPMail for use in NetWare NDS mode, complete the normal installation process for Pegasus Mail (using the SETUP.EXE program), then follow these additional steps:

a) Install WPNNW4.DLL into the same directory as WINPMAIL.EXE. Note that if any of your users have "-P <server>" commandlines in use for WinPMail under Bindery Emulation mode, these options must be removed because the -P option forces Pegasus Mail to run in Bindery mode.

b) Pegasus Mail is supplied with three Novell DLL files that provide the Interface into NetWare for NDS-aware utilities. These files are: NWCALLS.DLL, NWNET.DLL and NWLOCALE.DLL. You should ensure that you have exactly one copy of each of these files loadable on your system. The safest approach is to make sure that they appear in your \WINDOWS\SYSTEM directory and that all other copies on your system are deleted or removed. If you have more recent versions of these files than the ones supplied with Pegasus Mail, always use the newer versions and discard the Pegasus Mail versions.

c) Run the NDS-aware version of PCONFIG to configure Pegasus Mail for the specific contexts in which it is to run. The only difference between running the NDS version of PCONFIG and the standard Bindery version is that it will ask you at startup for the name of the context in which you want the configuration Profile Object to be placed. Provided you have the necessary privileges, you can create or edit configuration objects in any context in your NDS tree. Apart from this, the screens and general operation of PCONFIG are identical to the way they operate under Bindery mode.

d) Run MAKEMBOX to create user mail directories. MAKEMBOX performs the following tasks:

* It ensures that the target user has a "Home Directory" attribute and issues an error if not.

* It creates a directory called PMAIL in the user's home directory

* It grants [C] (File create) rights to mail users in that directory: by default, the grant of rights is to [Root] (any logged-in user), but you can if you wish specify a NetWare group to which the grant of rights should be made instead.

* It adds an ACL entry (ACLs are "Access Control Lists", and are the equivalent of Trustee Rights for NDS itself, controlling who can see or change what in the NDS database) that allows either [Root] or your designated mail group to read the specified user's NDS "Home Directory" attribute.

* It creates an empty extended features file (PMXF.INI) in each user's new mailbox and grants [RF] rights to all mail users for it. It also grants the owning user only [RF] rights, preventing the user from modifying his/her extended features without permission.

MAKEMBOX can be run in a number of ways:

MAKEMBOX <username>

- simply creates the mailbox for the single specified user

MAKEMBOX -s <context>

- creates mailboxes for every user in the context specified in the <context> parameter.

Examples:

MAKEMBOX -s dev.pmail

 creates mailboxes for all user objects in the context "dev.pmail".

MAKEMBOX -r -s <context>

- creates mailboxes for every user in the specified context and in every organizational unit below it in the NDS tree.

In order to run MAKEMBOX you must be logged in as a user with full administrative privilege over every organizational unit in which you run the program.

e) [Optional] Run PMIGRATE: if you have previously run Pegasus Mail in Bindery Emulation mode under NetWare 4.1, you can run PMIGRATE to transfer the mailbox information from the old SYS:MAIL directories to the new mailboxes for affected users. The PMIGRATE commandline syntax is simply

PMIGRATE <search mask>

where "search mask" is a pattern matching the names of bindery-based users you want to migrate.

Examples:

To migrate all users, use the commandline

PMIGRATE *

To migrate all Bindery Users whose bindery username starts with "JOHN", use the commandline:

PMIGRATE JOHN*

f) Install PMUSER.NLM on your file server. PMUSER is a very small NLM that asks NDS to notify it every time a user is created on the file server. When a user is created, PMUSER attempts to create the necessary mailbox directory for that user via the same method as MAKEMBOX. PMUSER logs into your file server using a privileged account name and uses one licensed connection on your server while it runs. If your user creation process is automated, you can duplicate the functionality of PMUSER by running MAKEMBOX for each user as you create it - the advantage of PMUSER is that if you use utilities such as NWADMIN or NETADMIN to create your users, it will automatically ensure that the necessary mailbox information is created for them without further intervention from you. PMUSER can be loaded using the following syntax

LOAD PMUSER [-u username] [-p password] [-g group]

where "username" is the NDS username PMUSER should use when logging in to NDS, "password" is the password for the account and "group" is the name of the user group PMUSER should give access to the mail properties of new user mailboxes. "group" defaults to "[Root]" (that is, all users logged-in to the file server); "username" and "password" can be omitted, in which case PMUSER will prompt you for them.


Installing Mercury in NDS mode

You will install Mercury on your file server if you want your Pegasus Mail users to have access to Internet mail using the SMTP protocol. Installing Mercury for operation in NDS mode is only slightly different from installing it for normal Bindery-mode operation. Complete all the steps in the normal installation process, then do the following:

a) If there are copies of MERCURY.NLM, MERCURYP.NLM or MERCURYS.NLM in SYS:SYSTEM, remove them; they are not used in NDS mode.

b) Make sure MERCNDS.NLM and MERCNDSS.NLM have been installed in SYS:SYSTEM on your file server.

c) Edit your MERCURY.INI: add the [NDS] section and modify the [Domains] section as described below.

d) Load MERCNDS.NLM, MERCNDSS.NLM and MERCURYC.NLM on your server. Optionally, load MERCNDSP.NLM if you want to make POP3 services available for your server.

Modifying MERCURY.INI for NDS use.

At startup, Mercury parses your MERCURY.INI file as it has always done, except that it expects to find a new section, [NDS], and to find different entries in the [Domains] section. A sample MERCURY.INI file is provided with this release - we suggest you examine it (MERCNDS.INI) to see how the information Mercury needs should be provided.

a) The [NDS] section. Mercury uses this section to work out who it should log in as. In order to operate in NDS mode, Mercury needs to login to Directory Services using a privileged user account. See the section entitled "Security considerations" at the end of this document for discussion of the type of usercode Mercury should be given. The NDS section can contain four entries:

USERID the NDS "Distinguished Name" of the user identity Mercury should use to login to NDS. Example "USERID : Admin.pmail". There is no default for this section - if you leave it blank or omit it, Mercury will prompt you for a username when it starts up.IMPORTANT NOTE: The name you use must be expressed relative to the root of the NDS tree.

PASSWORD the password for the account given in "USERID". If you omit this field, or leave it blank, Mercury will prompt you for a password when it loads and will not process any mail until you respond.

MAILBOX_MODE - should be either 0 or 1. If 0 (the default), Mercury will use the mailbox methods described in section 5d above. If 1, Mercury will assume that you have installed the Novell MHS Services product on your server and will use the mailboxes created by that system instead.IMPORTANT NOTE: Mercury is NOT an MHS gateway and cannot provide SMTP mail services to the Novell MHS product range. It can use the MHS directory structure, but only Pegasus Mail will be able to take advantage of its services.

AUTOMAINTENANCE - should be either 0 or 1. If 0 (the default), Mercury will NOT attempt to create mailboxes for users that do not have them already. If 1, Mercury will use the same creation method as MAKEMBOX and PMUSER to create mailboxes for users when it detects a user without a mailbox. If "Automaintenance" is set to 0 and mail is sent to a user without a mailbox, a delivery error occurs.

It is legal to omit the [NDS] section; if you do so, Mercury will prompt you to enter a username and password when it starts up.

b) The [Domains] Section.

In NDS mode, Mercury uses the [Domains] section to associate an NDS organizational unit with an Internet domain. The syntax of the section is basically the same as under Bindery mode, but with one or two extra capabilities. Each entry in the [Domains] section must have an NDS context on the left and an Internet domain name on the right. The NDS context name must be expressed relative to the root of the NDS tree. If you wish to apply an entry to an entire subtree rather than to a single specific context, add a '/' character at the start of the NDS context name.

Example:

The Organization "Acme Inc", has two separate divisions in the same NDS tree, "Sales" and "Manufacturing". The "Manufacturing" division contains three more organizational units, "Development", "Futures" and "Production". The Sales division has only one organizational unit, "Marketing". The NDS tree for Acme Inc looks like this:

   Acme Inc --+-- Sales ----------+-- Marketing

              |

              +-- Manufacturing --+-- Development

                                  |

                                  +-- Futures

                                  |

                                  +-- Production

The Internet domain name for Acme Inc is "acme.com". Because the Sales and Manufacturing Divisions are administratively separate, they want to have the domain names "sales.acme.com" and "mfg.acme.com" respectively.Because of political divisions within the Sales group, the Marketing division also wants to have its own domain name, "mktg.acme.com". The Manufacturing Division, however, is happy to have "mfg.acme.com" apply to all its sub-divisions. The [Domains] section that achieves this organizational structure would be as follows:

[Domains]

Marketing.Sales.Acme Inc   :  mktg.acme.com

Sales.Acme Inc             :  sales.acme.com

/Manufacturing.Acme Inc    :  mfg.acme.com

Note the use of the '/' in the last entry to indicate that "mfg.acme.com" should apply to all the organizational units beneath "Manufacturing" in the NDS tree.

c) Restrictions

There are certain restrictions you must observe when running Mercury in NDS mode:

i: 	Your users' names must only contain standard ASCII characters. If you have usernames that contain special or extended ASCII characters, then you must create ASCII-only synonyms for those users.

ii:	If you use the '/' character to apply an Internet domain name to an NDS subtree then your users' names must be unique throughout that subtree. If you have two users with the same names in different organizational units of a subtree served by Mercury, then one of the users must be given a synonym that distinguishes him or her from the other user.

iii:	Usernames may contain spaces; Mercury and Pegasus Mail will convert the space characters to underscores when writing the user's address into Internet mail. NDS regards spaces and underscores as exactly equivalent - if this condition ever changes in future versions of NetWare, then users whose names contain spaces must be given synonyms.

iv:	You may have more than one Internet domain name mapped to a single NDS context, but you may not have multiple NDS contexts mapped to a single Internet domain name except by using the '/' operator.


Enabling full user lookup

WinPMail supports local user lookup directly from the NDS database (via the "Local users" option on the "Addresses" menu). Unfortunately, Novell made some curious design decisions about default access rights when they implemented NDS - most notably that users cannot by default access any information about other users other than their surnames and their default servers. By default, the PMUSER.NLM and MAKEMBOX utilities will add an ACL (ACLs are the same as trustee rights except they apply to the NDS database and control who can see what information) allowing all users to see other users' full names, but this grant of rights can be suppressed on the commandline if you wish. An alternative way of allowing all users to see other users' full names involves making a small global change to the NDS database one time. If you would prefer to use this option to enable local user lookup within Pegasus Mail, follow these steps:

1:	Login as ADMIN

2:	Run the NetWare NWADMIN administrator tool.

3:	Highlight the first context below the root context (i.e, the highest level context other than "Root").

4:	Choose "Trustees of this object" from the "Object" menu.

5:	Click on "Add trustee"

6:	Change your context to "[Root]" and double-click "[Root]" in the "Objects" list.

7:	Click OK to save the trustee assignment.

8:	Highlight "[Root]" in the "Trustees" list, then check the controls labelled "Browse" (on the left) and "Read" and "Compare" (on the right).

The effect of this change is to permit all users the default right to browse information about other users.


Extended features

Pegasus Mail has a number of specialised features that are not normally enabled for every user. In NetWare 3.x mode, these features were stored in the NetWare Bindery, where they were readable by all users. Under NetWare 4.1, the only equivalent way of doing this involves modifying the base NDS schema to add a new object type: unfortunately, at the time of writing, modifying the base schema has far-reaching consequences (most specifically that it is impossible to merge two NDS trees where either has a modified schema) and hence we have had to rule out this approach.

Instead, WinPMail and Mercury look for a file called PMXF.INI in each user's new mail directory. This file must be world-readable to be effective. PMUSER and MAKEMBOX will automatically create a zero-length version of this file when creating a new mail directory for a user, and will grant [RF] rights to all users, as well as making an explicit grant of [RF] to the user himself; this latter grant prevents the user from modifying the file, thus keeping compatibility with Pegasus Mail under NetWare 3.x (where by default users are not permitted to modify their extended feature sets).

To allow a user to modify his/her extended features, grant all rights to PMXF.INI. Note that if you manually edit a PMXF.INI file, you will probably alter the rights grants to the file. Make sure you grant [RF] to [Root] (all logged-in users) each time you modify the file manually.

PMXF.INI is a simple text file that contains statements, one per line.The following statements are recognized:

Local autoforward = <address>

Sets a forwarding address for mail delivered by Pegasus Mail itself. "<address>" can be any valid address to which you could normally send mail using Pegasus Mail.

Internet autoforward = <internet_address>

Sets a forwarding address for mail delivered by Mercury. The address can only be a local NDS address or an Internet address.

Deliver even when forwarding = <Y or N>

Determines whether or not a copy of mail that is automatically forwarded by Mercury or Pegasus Mail should be left in the recipient's new mailfolder as well.

Allow confirmation of reading = <Y or N>

If 'N', then Pegasus Mail will not honour requests for confirmation that a message has been read.

Disable mail delivery = <Y or N>

If 'Y', then no mail can be delivered to this account.

Send delivery broadcasts = <Y or N>"

If 'Y', then NetWare broadcast messages will be sent to the recipient when new mail arrives.

Lines beginning with '#', ';' or '*' in PMXF.INI are regarded as comments and are ignored.


Security Considerations

Running Pegasus Mail in NDS mode does not compromise the security of your server, but it does create some conditions of which you should be aware.

Firstly, Mercury and PMUSER must login to Directory Services using privileged usercodes. The most expedient approach is to have them login using the ADMIN account: this creates a security issue in that the passwords for these accounts must be given to the programs in some way. Mercury will prompt for a password if none is provided in MERCURY.INI and PMUSER will also prompt for the password if it is not passed on the commandline; you may want to consider carefully how these applications are loaded in this light.

Another alternative is to create a user account that can be used by PMUSER and Mercury but which is more limited in privilege than the ADMIN account. If you do this, the account you create must be able to do the following things:

  * Read and set the Home Directory attribute for any mail user

  * Create directories in any user's home directory

  * Grant trustee rights in any user's home directory

  * Browse the entire NDS tree without restriction

  * Grant ACLs covering any mail user's "Home Directory" attribute

  * Create, rename, delete, read and write files in any mail user's

    home directory.

  * Change the ownership of any file on the system

  * Read SYS:SYSTEM/MERCURY.INI

  * Verify any user's NDS password

Pegasus Mail and Mercury require grants of rights to all mail users, but only at the smallest possible rights levels. The only viable security consideration that can arise from these extra grants of rights is a fairly standard service denial attack - because all mail users have [C] rights in all other mail users' new mail directories, it is possible for someone to exhaust a user's disk space allocation by repeatedly creating files in that user's new mail directory. This is not much of an attack, though, because you can always see the owner of the files that are created in the process and trace back to the culprit that way.

The only other security consideration arising from the use of Pegasus Mail and Mercury in NDS mode is a provision of information consideration: by default, NetWare NDS permits users to read their own home directory information from the Directory Services database, but not to read the location of other users' home directories. MAKEMBOX, Mercury and PMUSER can all alter this so that all mail users can see all other mail users' home directory locations in the database. While it is unlikely that this information could really have much consequence, some sites may prefer not to make it available for some reason. In cases like this, you should consider using Mercury to handle all your mail.


POP3 Server Considerations

Under NDS, it is possible to have exactly the same username defined in multiple contexts in your NDS tree. This can pose a problem for MERCNDSP, the POP3 server, in that when presented with a name like "david", it may be unable to tell which of several possible "david"s in your NDS tree is the proper user. To get around this, you can take one of two approaches:

1: Require your users to give a full NDS distinguished name when logging in to the server (for example, "david.dev.pmail").

2: Create a POP3 alias file, POPALIAS.MER, in SYS:SYSTEM. This file simply equates a simple username (like "david") to the full NDS format used for logging in (like "david.dev.pmail"). POPALIAS.MER is a simple text file where each line has the form:

<pop3_login_name> = <nds_username>

As an example, using the names above, you would have the line

david = david.dev.pmail

NDS usernames must be expressed as full paths relative to the root of your NDS tree. Each line must begin hard against the left margin. Lines beginning with #, * or ; are regarded as comments and are ignored.


Troubleshooting

- When I run MAKEMBOX or the other commandline utilities, they complain about failing to initialize unicode tables.

This is a problem with the NetWare API library. Novell provide a suite of files to handle the conversion from unicode to local character sets and back - these files are the ones in SYS:PUBLIC/NLS on your NetWare 4.1 file server, and have names like 1250_UNI.042 or UNI_MON.061. These files MUST be on your DOS PATH before you run any of the Pegasus Mail support utilities, and when running Pegasus Mail itself.

- WinPMail complains about a Locale Failure at startup

- WinPMail appears to start up, but when I look in the 'Info' screen in the 'About Pegasus Mail' dialog it hasn't picked up any of my NDS information.

This problem can be caused by unicode table failure - see above for more information on this. There is also a more subtle cause for this problem: if you are running Windows 95, it is possible for you to select a country setting (using the "Regional Settings" control panel) for which Novell have not provided Locale support. An example of this is New Zealand, which Microsoft supports as a separate country, but which Novell seems to regard as part of Australia. Unfortunately, the ONLY known solution for this at this stage is to change your regional setting to one for which Novell DO offer support.

- I've granted extended features to a user and can see the PMXF.INI file in his new mail directory, but none of the settings are being used.

Have you edited the file manually? If so, the rights settings for the file have probably been disturbed. Make sure that [Root] (all logged-in users) has [RF] rights to the file - you can do this using the command:

RIGHTS PMXF.INI RF /name=[Root]


Installing Pegasus Mail only (no Internet mail via Mercury)

This section provides step by step instructions on installing Pegasus Mail onto a NetWare 4.1 file server on its own, without installing the Mercury system to provide Internet mail services.

IMPORTANT NOTE BEFORE STARTING!!!

The DOS utilities MAKEMBOX.EXE and PMIGRATE.EXE, and the Windows NICA enabler WPNNW4.DLL all need to be able to find the Novell Unicode files on your DOS path in order to operate. The unicode files are the 200 or so files that appear in SYS:PUBLIC/NLS on your file server. The easiest way to ensure that this happens is to map a search drive to that directory before using the utilities - use the command:

MAP INS S16:=SYS:PUBLIC/NLS

STEP 1  Copy WPNNW4.DLL into the same directory as your copy of WinPMail v2.23 or later.

STEP 2  Run the version of PCONFIG supplied with this archive. Choose a configuration context (the context into which PCONFIG should store the configuration profile). Make sure that "Enabled" is set to 'N' in both the SMTP and MHS configuration screens. Choose "Save and exit".

STEP 3  Run MAKEMBOX to create the new mail directories for all your existing users. The usual way to do this is to issue the command "MAKEMBOX -r *".

STEP 4  [Optional] Install PMUSER.NLM on your file server by copying it into SYS:SYSTEM then going to the file server console and typing the command "LOAD PMUSER". When PMUSER asks for a user and password, enter your Admin username and password (see the main reference document for details on using less privileged accounts for this purpose). If you do not load PMUSER, mailboxes will not be created automatically for your users - you will have to create them manually using MAKEMBOX.EXE.

STEP 5  [Optional] If you have previously been running Pegasus Mail in Bindery Emulation mode on your file server, migrate the user mailboxes from Bindery mode to NDS mode using the PMIGRATE command. The most usual way of doing this is to issue the command "PMIGRATE *".


Installing Pegasus Mail for local mail, Mercury for Internet mail

This section provides step by step instructions for installing Pegasus Mail and Mercury onto a NetWare 4.1 file server so that Pegasus Mail itself handles all delivery of mail to local addresses and Mercury is used to handle delivery to Internet addresses.

IMPORTANT NOTE BEFORE STARTING!!!

The DOS utilities MAKEMBOX.EXE and PMIGRATE.EXE, and the Windows NICA enabler WPNNW4.DLL all need to be able to find the Novell Unicode files on your DOS path in order to operate. The unicode files are the 200 or so files that appear in SYS:PUBLIC/NLS on your file server. The easiest way to ensure that this happens is to map a search drive to that directory before using the utilities - use the command:

MAP INS S16:=SYS:PUBLIC/NLS

PART A - Installing WinPMail

STEP 1:  Copy WPNNW4.DLL into the same directory as your copy of inPMail v2.23 or later.

STEP 2:  Run the version of PCONFIG supplied with this archive. Choose a configuration context (the context into which PCONFIG should store the configuration profile). Choose "SMTP Internet Mail Interfaces" from the Main Menu and fill in the blanks according to the guidelines you will find in WGUIDE.HLP (the WinPMail online guide). In particular, make sure that "Use always" is set to 'N' so that WinPMail can deliver mail locally. When you have finished, press Ctrl+Enter to save the settings, then from the main menu, choose "Save and exit".

STEP 3:  Run MAKEMBOX to create the new mail directories for all your existing users. The usual way to do this is to issue the command "MAKEMBOX -r *".

STEP 4:  [Optional] Install PMUSER.NLM on your file server by copying it into SYS:SYSTEM then going to the file server console and typing the command "LOAD PMUSER". When PMUSER asks for a user and password, enter your Admin username and password (see the main reference document for details on using less privileged accounts for this purpose). If you do not load PMUSER, mailboxes will not be created automatically for your users - you will have to create them manually using MAKEMBOX.EXE.

STEP 5:  [Optional] If you have previously been running Pegasus Mail in Bindery Emulation mode on your file server, migrate the user mailboxes from Bindery mode to NDS mode using the PMIGRATE command. The most usual way of doing this is to issue the command "PMIGRATE *".

PART B - Installing Mercury

If you have never installed Mercury on your file server before, run the program SETUP.EXE supplied with Mercury to install it, then once you have done so, go straight to step 4. If you already have Mercury installed on your server, or if you want a customized installation, follow steps 1-3.

STEP 1:  Copy the various Mercury NLM files to your file server's SYS:SYSTEM directory. You will need to copy MERCNDS.NLM, MERCNDSS.NLM, MERCURYC.NLM and optionally MERCNDSP.NLM.

STEP 2:  Create the Spool directory for Mercury - we recommend that you use SYS:SMTPMAIL, since this is the value in the default MERCURY.INI file. Make sure that all users have [C] rights in this directory.

STEP 3:  Copy the sample MERCURY.INI file supplied with Mercury to your file server's SYS:SYSTEM directory. Edit it using any text editor (even - <shudder> - DOS EDIT) and change the various settings to reflect your system. In particular, you will probably have to change the following entries:

In the [General] section:

- myname

- timezone

- mailqueue and smtpqueue (if you used a directory other than SYS:SMTPMAIL in step 2)

In the [Mercury] section:

- scratch

- postmaster

- noticeboards (optional)

In the [NDS] section:

- username (we strongly recommend using ADMIN).

In the [MercuryC] section:

- host

In the [Groups] section:

- any NetWare groups you want to enable for mailing

In the [Domains] section:

- see the detailed explanation in the sample INI file for instructions on this section.

In a default installation, where you have used MINSTALL or the Mercury SETUP.EXE program to install the files, you should not need to change any other entries in MERCURY.INI

STEP 4:  Load MERCNDS.NLM, MERCNDSS.NLM, MERCURYC.NLM and optionally MERCNDSP.NLM from the file server console. MERCNDSP is only required if you have users who need to access their mail via the POP3 protocol - it is not usually required when you are using Pegasus Mail.

STEP 5:  (Optional) Modify your file server's AUTOEXEC.NCF so that the Mercury modules are loaded automatically at startup. The LOAD statements for the Mercury NLMs should usually appear at the very end of your AUTOEXEC.NCF. Mercury Setup will offer to make this change for you if you run it to install the program.

STEP 6:  (Optional) Create any alias files you need on your server using the MALIAS alias compiler. See the sample ALIAS.MER file supplied with Mercury for details on aliasing.

STEP 7:  (Optional) If you need POP3 aliases (aliases to allow users to login to a specific context using a simple username), then create a POPALIAS.MER file in SYS:SYSTEM. See the sample POPALIAS.MER file supplied with Mercury for more details on this function.


Installing so that Mercury handles all mail on the system

This section provides step by step instructions for installing Pegasus Mail and Mercury onto a NetWare 4.1 file server in such a way that Pegasus Mail does not attempt any mail delivery at all, but passes all mail to Mercury to handle instead, even local mail.

IMPORTANT NOTE BEFORE STARTING!!!

The DOS utilities MAKEMBOX.EXE and PMIGRATE.EXE, and the Windows NICA enabler WPNNW4.DLL all need to be able to find the Novell Unicode files on your DOS path in order to operate. The unicode files are the 200 or so files that appear in SYS:PUBLIC/NLS on your file server. The easiest way to ensure that this happens is to map a search drive to that directory before using the utilities - use the command:

MAP INS S16:=SYS:PUBLIC/NLS

PART A - Installing WinPMail

STEP 1:  Copy WPNNW4.DLL into the same directory as your copy of inPMail v2.23 or later.

STEP 2:  Run the version of PCONFIG supplied with this archive. Choose a configuration context (the context into which PCONFIG should store the configuration profile). Choose "SMTP Internet Mail Interfaces" from the Main Menu and fill in the blanks according to the guidelines you will find in WGUIDE.HLPE (the WinPMail online guide). In particular, make sure that "Use always" is set to 'Y' to force WinPMail to pass all mail to Mercury for processing. When you have finished, press Ctrl+Enter to save the settings, then from the main menu, choose "Save and exit".

STEP 3:  Run MAKEMBOX to create the new mail directories for all your existing users. The usual way to do this is to issue the command "MAKEMBOX -r *".

STEP 4:  [Optional] Install PMUSER.NLM on your file server by copying it into SYS:SYSTEM then going to the file server console and typing the command "LOAD PMUSER". When PMUSER asks for a user and password, enter your Admin username and password (see the main reference document for details on using less privileged accounts for this purpose). If you do not load PMUSER, mailboxes will not be created automatically for your users - you will have to create them manually using MAKEMBOX.EXE.

STEP 5:  [Optional] If you have previously been running Pegasus Mail in Bindery Emulation mode on your file server, migrate the user mailboxes from Bindery mode to NDS mode using the PMIGRATE command. The most usual way of doing this is to issue the command "PMIGRATE *".

PART B - Installing Mercury

If you have never installed Mercury on your file server before, run the program SETUP.EXE supplied with Mercury to install it, then once you have done so, go straight to step 4. If you already have Mercury installed on your server, or if you want a customized installation, follow steps 1-3.

STEP 1:  Copy the various Mercury NLM files to your file server's SYS:SYSTEM directory. You will need to copy MERCNDS.NLM, MERCNDSS.NLM, MERCURYC.NLM and optionally MERCNDSP.NLM.

STEP 2:  Create the Spool directory for Mercury - we recommend that you use SYS:SMTPMAIL, since this is the value in the default MERCURY.INI file. Make sure that all users have [C] rights in this directory.

STEP 3:  Copy the sample MERCURY.INI file supplied with Mercury to your file server's SYS:SYSTEM directory. Edit it using any text editor (even - <shudder> - DOS EDIT) and change the various settings to reflect your system. In particular, you will probably have to change the following entries:

In the [General] section:

- myname

- timezone

- mailqueue and smtpqueue (if you used a directory other than SYS:SMTPMAIL in step 2)

In the [Mercury] section:

- scratch

- postmaster

- noticeboards (optional)

In the [NDS] section:

- username (we strongly recommend using ADMIN).

In the [MercuryC] section:

- host

In the [Groups] section:

- any NetWare groups you want to enable for mailing

In the [Domains] section:

- see the detailed explanation in the sample INI file for instructions on this section.

In a default installation, where you have used MINSTALL or the Mercury SETUP.EXE program to install the files, you should not need to change any other entries in MERCURY.INI

STEP 4:  Load MERCNDS.NLM, MERCNDSS.NLM, MERCURYC.NLM and optionally MERCNDSP.NLM from the file server console. MERCNDSP is only required if you have users who need to access their mail via the POP3 protocol - it is not usually required when you are using Pegasus Mail.

STEP 5:  (Optional) Modify your file server's AUTOEXEC.NCF so that the Mercury modules are loaded automatically at startup. The LOAD statements for the Mercury NLMs should usually appear at the very end of your AUTOEXEC.NCF. Mercury Setup will offer to make this change for you if you run it to install the program.

STEP 6:  (Optional) Create any alias files you need on your server using the MALIAS alias compiler. See the sample ALIAS.MER file supplied with Mercury for details on aliasing.

STEP 7:  (Optional) If you need POP3 aliases (aliases to allow users to login to a specific context using a simple username), then create a POPALIAS.MER file in SYS:SYSTEM. See the sample POPALIAS.MER file supplied with Mercury for more details on this function.