3A contains introductory reference information which will help you set up a distributed E-mail network. Section 3B covers pre-installation planning and installing post.office. NT PLATFORM 3A: SETTING UP YOUR E-MAIL NETWORK 3B: INSTALLATION 3.A.0 SETTING UP YOUR ENTIRE E-MAIL NETWORK 3.A.1 THINGS TO CONSIDER WHEN DESIGNING YOUR NETWORK 3.A.2 ADDRESSING 3.A.3 EXAMPLE SETUPS The basic setup Hostname Hiding Behind a Firewall Intermittently Connected Site 3.B.0 INSTALLATION INSTRUCTIONS (WINDOWS NT VERSION) 3.B.1 SYSTEM REQUIREMENTS 3.B.2 PRE-INSTALLATION PLANNING 3.B.2.1 What to do with your current Mail System 3.B.2.2 the system drive partition format 3.B.2.3 Setting up a NT-Login Account 3.B.2.4 your registration information 3.B.2.5 Your DNS Domain 3.B.2.6 postmaster password 3.B.2.7 Locations of Programs and Working Directories 3.B.2.8 Effect on Your Existing Mail System 3.B.2.9 The Role of the Postmaster 3.B.2.10 Impact of Migration for Mail System Users 3.B.2.11 Checking the permissions for the Systems Directories 3.B.3 INSTALLING POST.OFFICE 3.B.3.1 The Installation Process 3.B.3.2 Checking to see if installation worked 3.B.3.3 postmaster and personal accounts 3.B.3.4 Where to Go Now 3.B.4 COMMON INSTALLATION MISHAPS 3.B.4.1 Rerunning Install 3.B.4.2 Changing the Postmaster Account 3.B.5 DE-INSTALLATION 3.B.5.1 Removing post.office 3.A.0 SETTING UP YOUR ENTIRE E-MAIL NETWORK The purpose of the first part of this chapter (3A) is to provide a rough blueprint of how to successfully set up even the most complicated E-mail network. 3.A.1 is a check list of things you should consider when setting up your E-mail network. 3.A.2 discusses the tools used with post.office to take care of addressing and routing. These include account addresses, aliases, and mail routing facilities. 3.A.3 concludes with several example configurations that cover the most common situations and should spark ideas on how to approach your own solution. Note: If you are already familiar with the material covered in section 3A, you can of course skip ahead to section 3B, which covers pre-installation planning and the installation itself. You may run across some ground which you are not familiar with that you would like to know more about before configuring your system. You may find useful reference information in the sources we list in appendix B, References. 3.A.1 THINGS TO CONSIDER WHEN DESIGNING YOUR NETWORK This section is a check list of key issues to review in thinking about how you're setting up your E-mail network. This is not a formula. Rather, it is a list of things you should keep in mind as you decide how many machines you need and how to configure post.office on each machine so that they work together harmoniously. SYSTEM LOAD The load put on a machine running post.office, or any MTA, is directly proportional to the volume of mail that goes through the system. The volume obviously increases as the number of users increases, and as post.office is set up to handle more mail domains (since that means there are more users). To reduce the impact of mail on a single machine you may want to distribute users among several machines. ADDRESSING post.office will let you assign any valid address to an account. You may want to choose a convention for user addresses (such as First.Lastname@mail_domain). Regardless of the convention you choose, you must set up the DNS so that mail with the addresses you use will be delivered to your network. If you want addresses to exclude hostnames of specific computers, you will need to follow the instructions for hostname hiding discussed a little farther on. USER ACCESS TO E-MAIL post.office allows users to access their E-mail via the network using POP3 remote mail access protocol. The post.office POP3 server provides ease of administration, fast performance, and strong security. CONNECTIVITY TO THE INTERNET There are three levels of Internet connectivity: fully connected, intermittently connected, and not connected. How you set up your E-mail network depends on the category you fit in. Fully and intermittently connected sites are similar. Since intermittently connected sites are not reachable at all times throughout the day, it is especially important that MX records are set up to redirect incoming mail to an alternate host while not connected. Such sites often connect to the Internet using SL/IP or PPP to a network provider who acts as a backup mail exchanger. Unconnected sites that use post.office on a private TCP/IP network for mail may or may not have a mail gateway to the Internet or other network such as UUCP or BITNET. post.office can be set up to deliver all non-local mail to the gateway machine which will pass it to the Internet or other network. Such a setup is very similar to having a firewall (discussed below). FIREWALL CONFIGURATION If your site is behind an Internet firewall you will need to do some extra things to allow mail to flow into and out of your network. Since other machines on the Internet can not directly contact any of your hosts except for the firewall, all incoming mail must be routed to the firewall with MX records. All outgoing mail needs to be sent to the firewall which will forward it to its final destination. The details of setting up post.office in a firewalled environment are discussed in section 3.A.3. 3.A.2 ADDRESSING AND ROUTING WITH POST.OFFICE Addressing and routing are fundamental concerns when setting up your network, from assigning addresses to accounts to setting up alias, routing tables and MX records on other hosts. Various ways of handling addressing and routing are discussed bellow, and will reappear frequently in the examples discussed in section 3.A.3. ACCOUNT ADDRESSES post.office account addresses are very powerful. Any number of addresses (aliases) can be assigned to an account, which are used to determine if a piece of incoming mail should be delivered to the account. Accounts can be configured to rewrite the "From:" header of outgoing mail to list the account's official address. These features can be used to assign arbitrary addresses (such as First.Lastname) to each user and/or to implement hostname hiding, which is discussed later in this chapter. It is trivial to handle several domains on a single machine -- simply assign the addresses to the desired accounts and post.office will recognize them. Addresses within one domain are independent of any other domain. For example, an account with the address can be different from an account with the address with no confusion. LOCAL MAIL DOMAINS The list of Local-Mail-Domains (LMD) is used to tell post.office that it alone knows every recipient in those domains. post.office will never attempt to deliver a message to these domains using a network protocol such as SMTP. If a message arrives for a recipient in one of the listed LMD's, post.office first attempts to find an account or channel alias for the recipient. If that fails, post.office will return an error report to the sender rather than attempt to forward it to the domain. This feature is used primarily to prevent people from attempting to deliver mail to PC's or other computers that are not running a mail server, or when several domains are being served by a single mail server running post.office. CHANNEL ALIASES Channel aliases are a simple address-rewriting way to redirect mail. A channel alias consists of two pieces of information, an incoming address and an outgoing address. Whenever a piece of mail arrives containing the incoming address of one of the channel aliases, the matching address is replaced with the outgoing address. The mail is then redirected to its new destination, generally to a different machine. MAIL ROUTING TABLE The Mail-Routing-Table (MRT) provides a way to redirect mail based on the domain to which it is being sent. Each entry in the MRT consists of a pattern and a domain. Before sending a message, the destination domain is compared against the patterns in the table. If a match is found, the destination host is replaced by the domain corresponding to the pattern that matched. (Note: no addresses are rewritten; the mail is just sent off to a different host.) This feature is useful for sites behind a firewall, or ones that have gateways to other networks such as UUCP or BITNET. MX RECORDS IN THE DNS Mail exchanger (MX) records in the Domain Name System provide a way to tell the outside world how to route mail to your domain(s). For each mail domain you can specify the hosts that should be contacted when attempting to deliver a message to the domain, along with the order they should be tried. The basic use for MX records is to specify one or more "third-party" machines that collect mail during temporary network outages. This is a must for poorly connected sites who use SL/IP or PPP to access the Internet and are only connected a few hours per day. For sites that reside behind an Internet firewall, MX records are used to direct all incoming mail to the firewall machine (since no other machines are reachable). The firewall then relays the mail to its final destination on the internal network. A very similar situation exists for sites that have domain-based E-mail addresses requiring one or more mail hubs. MX records channel all incoming mail into the hubs which then relay the messages to their final destinations. MX records also enable the creation of "virtual domains" that have no machines connected to the Internet, yet are accessible via E-mail. A network provider will often set this up for a customer who has registered a domain name. The network provider advertises MX records for the virtual domain that point to their own mail servers, and the mail is delivered to the virtual domain, for example over a UUCP connection, or by some other method. 3.A.3 EXAMPLE SETUPS In this section, several scenarios are presented which cover most typical setups. Your exact situation may not be covered exactly by one of the examples, but ideas can be pulled from the various examples as suits your situation to get your site set up correctly. Each example describes what is being accomplished and then explains how to set up post.office to achieve the desired effect. The first two examples cover the basic types of addressing (host- and domain-based) and the last two deal with issues unrelated to user addressing, and therefore build on the first two examples. THE BASIC SETUP The basic setup is used in a new, small scale (less than 50 users) installation. Sites that have minimal special requirements for post.office should build on the basic setup model. (If you implemented a domain-based addressing scheme using your current mail server software, skip to the next section which covers hostname hiding.) Scenario: All machines are directly connected to the Internet. Users send and receive mail addressed from/to a single specific computer. User addresses are based on some combination of their real name. Users use POP3 mail clients (e.g. Pegasus, Zmail, Eudora) that access their mailbox. Each machine acts independently; messages are sent and received directly to/from other machines on the Internet. Network Diagram: Figure 3.A.3a: Janie's address is Janie@xanadu.podunk.edu. MX records: Each machine may have MX records that point to itself, and optionally to one or more backup hosts. MX records are not really necessary in this scenario since each computer has an A (address) record. When MX records are set up, they may look like this: xanadu.podunk.edu. IN A 123.45.6.78 IN MX 10 xanadu.podunk.edu. IN MX 20 hub.podunk.edu. Janie's account: This example shows how Janie's account is set up in this situation. Users on the machine xanadu.podunk.edu have their mail delivered to their POP3 mailbox. Since post.office rewrites Janie's "From:" header on outgoing mail, she is sure that recipients will be able to reply to her messages. User's-Real-Name: [Janie Lee] Internet-Addresses: [janie@xanadu.podunk.edu] From-Address-Rewrite: [comment] POP3-Delivery: [yes] POP-Login-Name: [janie] Figure 3.A.3b: Janie's account form settings. Only relevant fields are shown. Local Mail Domains: None are needed (local machine is always implicitly on the list) Mail Routing Table: No entries are needed, but they can be added if you want. See other examples for uses of the Mail-Routing-Table. HOSTNAME HIDING "hostname hiding" refers to the practice of having domain-based E-mail addresses which do not contain the name of a particular host. This effect can be achieved almost as easily as Janie's setup. You will need one or more machines, commonly called mail hubs, to process all incoming mail and distribute the messages to the particular client computer that houses a user's account. Of course you can set up hostname hiding even if you only have one machine acting as both hub and client. Scenario: All machines are directly connected to the Internet. Users send and receive mail addressed from/to their domain (or sub-domain). Mail hub(s) are required to forward incoming mail to client machine(s). Network Diagram: Figure 3.A.3c: All messages for the domain podunk.edu go through the hub machine. On the hub host, Janie has an SMTP channel alias [] that points to Xanadu. MX records: There MUST be MX records for your domain, or mail addressed to your domain will not be deliverable. The MX records should point to each of your hub machines, most likely with equal preference. Backup mail exchangers are recommended and should have lower preference (higher number). Your MX records should look similar to this example: podunk.edu. IN MX 10 hub.podunk.edu. IN MX 20 mx1.backup.net. Hint: some existing (old) mail software does not understand MX records, so it is often a good idea to add an A record for your domain. The address should be that of one of your mail hubs. Each client machine should have MX records that point to itself, and optionally to one or more backup hosts (usually the hub machines). For example: xanadu.podunk.edu. IN A 123.45.6.78 IN MX 10 xanadu.podunk.edu. IN MX 20 hub.podunk.edu. User accounts: This example shows how Janie's account is set up on a client machine supporting hostname hiding. Each user on the machine xanadu.podunk.edu has their mail delivered to their POP3 mailbox and their addresses are based on their first name. It is important that both the domain-based and host-based addresses are present in each account so that mail can flow into and out of the system correctly. It is equally important that each user have a From-Address-Rewrite specified, so post.office will rewrite their "From:" headers on outgoing mail to include their primary (first in the list) address. User's-Real-Name: [Janie Lee] Internet-Addresses: [janie@podunk.edu] [janie@xanadu.podunk.edu] From-Address-Rewrite: [comment] POP3-Delivery: [yes] POP-Login-Name: [janie] Figure 3.A.3d: Janie's account set up for hostname hiding. Channel Aliases Each hub needs to have a list of channel aliases for every user that can receive mail addressed to the domain. The aliases need to redirect mail to the specific machines that hold users' accounts. In the above example, the required channel alias (on the "SMTP aliases" form) is: Aliases: [ ] Figure 3.A.3e: Janie's channel alias on the SMTP aliases form. Note: if you set up a single machine for E-mail for your domain, it acts as both the client and the hub without the need for channel aliases; however, each account should still contain both forms of addresses so that finger programs will work correctly (not to mention that this will also save you a lot of work if you ever expand to multiple machines). Local Mail Domains: Each hub MUST list the domain, since it knows where every account is located. If this is missing, the Postmaster will see lots of "MX loop" error messages. A loop exists when the highest preference mail exchanger for a domain tries to forward a message to the domain and realizes it would send it to itself. No client machine should need any entries. Mail Routing Table: No entries needed, but may be added as desired. The next two examples illustrate the uses of the mail routing table. BEHIND A FIREWALL An Internet firewall provides security for a site by restricting or preventing access to internal machines by outside computers. A typical firewall is safe from hostile users of the Internet since it allows no direct connections to any internal machines, and relies on proxy servers or other trusted programs to carry communication across the divide. A firewall introduces complexity to the delivery of mail between outside organizations. Since the firewall prevents direct connections between internal and external hosts, mail needs to be routed through the firewall in both directions. This is handled with a combination of MX records and the SMTP mail routing table for incoming and outgoing mail respectively. Scenario: Local network is protected from the Internet by a firewall machine. Users have either host- or domain-based addresses as desired -- see previous examples for specifics on how to do this. Network Diagram: Figure 3.A.3f: Diagram of a firewall scenario. Special installation instructions: Follow the instructions for either host-based or domain-based addressing provided in the first two scenarios. If post.office is installed on the firewall itself and domain-based addresses are to be used, the firewall can act as the mail hub and should include a complete list of channel aliases for distributing mail to internal hosts. MX records: If you have a single DNS server on the firewall machine that answers requests from both internal and external hosts, your MX records for a host should point to the host first, then the firewall, and then any backup sites on the Internet (outside your network): xanadu.podunk.edu. IN MX 10 xanadu.podunk.edu. IN MX 20 firewall.podunk.edu. IN MX 40 provider.net. For sites that hide their hostnames, MX records are needed for the domain as usual. These should point to the mail hub(s) first, then the firewall, and then to any backup sites. Another option is to run two DNS servers -- one on the firewall for outside hosts and one on an internal machine for internal use only. The external DNS server (the one on the firewall) can be set up to give out very little information about the network. In fact, it can be set up with a wildcard MX record that says to just send all mail for any host in the domain to the firewall. Here's an example accomplishing that: podunk.edu. IN A 123.45.6.78 ; for dumb mailers IN MX 20 firewall.podunk.edu. IN MX 40 provider.net. * IN MX 20 firewall.podunk.edu. IN MX 40 provider.net. The internal DNS server should contain the detailed information about the internal network and all internal hosts should be configured to use that server in preference to the external server. Mail Routing Table The firewall machine should not need any explicit routes since it can directly contact any internal or external machine. Since the firewall is the only machine capable of delivering outgoing mail, you should set up every other machine with a default route to the firewall. A default route by itself will send all mail, including internal mail, to the firewall, so you need to also have entries in the table for your local domain that override the default. This example accomplishes that: Mail-Routing-Table: [podunk.edu:*] [*.podunk.edu:*] [*:firewall.podunk.edu] Figure 3.A.3g: Mail routing table for a firewall scenario. Recall that a "*" after the colon means to send directly to the matching host (actually to one of its mail exchangers -- the MRT does not override MX routing). Thus any mail destined for a host in the podunk.edu domain will be delivered directly to podunk and any other mail will be sent to the firewall which then forwards it to its destination. INTERMITTENTLY CONNECTED SITE An "intermittently Connected Site" is one that lacks continuous connectivity to the Internet, yet uses TCP/IP for communication. Typically these are sites that have a dialup connection to an Internet Provider and use either SL/IP or PPP to carry their packets over a phone line. Such sites are usually only "connected" for a few hours per day, or less. As such, they have some special requirements which are addressed here. Such sites typically want to be able to connect up to the Internet, receive all their incoming mail, send all their outgoing mail, and then disconnect. For this to work, the site needs to have all their mail collect at a single location, such as their Internet provider, while they're not connected. Similarly they would like all outgoing mail delivered efficiently to minimize connect time. For best efficiency, it can all be dumped to an external site such as the Internet provider who then forwards the messages to their final destinations. These two concepts are discussed in this section. Scenario: Local network is seldom connected to the Internet When connected, all machines have direct access to the Internet Users have either host- or domain-based addresses as desired -- see previous examples for specifics on this. Network Diagram: Figure 3.A.3g: Typical setup for an intermittently connected site. Special installation instructions: None. Follow the installation instructions for either host-based or domain-based addressing provided in the first two scenarios. MX records: Each machine should have MX records that point to itself first, and then to one or more backup hosts. The Internet provider should have the lowest preference (highest number) of all mail exchangers since it should be used only in the case where the dialup connection is down. For example: xanadu.podunk.edu. IN A 123.45.6.78 IN MX 10 xanadu.podunk.edu. IN MX 20 hub.podunk.edu. IN MX 40 provider.net. In this scenario, the number of extra mail exchangers on the "inside" should be small to minimize the impact on outside hosts that try to send you mail while your network is not connected. Mail Routing Table: To achieve the most efficient delivery of outgoing mail, you should set up a default route to a single well-connected site (make sure you have an agreement with the other site before you set this up!) such as your Internet provider. A default route by itself will send all mail, including internal mail, to the default machine, so you need to also have entries in the table for your local domain that override the default. This example accomplishes that: Mail-Routing-Table: [podunk.edu:*] [*.podunk.edu:*] [*:provider.net] Figure 3.A.3h: Mail routing table for an intermittently connected site. Recall that a "*" after the colon means to send directly to the matching host (actually to one of its mail exchangers -- the MRT does not override MX routing). Thus any mail destined for a host in the podunk.edu domain will be delivered directly to podunk and any other mail will be sent to the Internet provider who then forwards the mail to its proper destinations. Retrieving Messages From an Intermittently Connected Site Messages can be retrieved from the backup host by telneting to the SMTP port and using the " qsnd" command. See chapter 6 for details. 3.B.0 INSTALLATION INSTRUCTIONS (WINDOWS NT VERSION) In order to install post.office, you must: 1. Go through section 3.B.2, Pre-Installation Planning,, to make sure that you are ready to install the program. 2. Follow instructions set out in section 3.B.3: Installing post.office. 3B includes a section to assist you with common installation mishaps (3.B.4) and concludes with de-installation instructions should the need arise (3.B.5). Note: If you are setting up a mail system for the first time or are thinking about re-configuring you mail system and are not clear on what your options are, you may want to have a peek at the first section of this chapter: 3A, Setting up your E-mail network, which illustrates some of the more common messaging system configurations. 3.B.1 SYSTEM REQUIREMENS Intel Platform (minimum 486/33) running Windows NT 3.5 (both Server and Workstation are O.K.) NTFS Formatted Hard Drive Recommended. FAT Formatted system partitions are supported but not recommended (Long filenames are required). Mail Client with Post Office Protocol version 3 mail pickup (POP3) e.g. Zmail, Eudora, Pegasus, etc. WWW Browser (e.g. Mosaic or Netscape). 3.B.2 PRE-INSTALLATION PLANNING This section outlines a strategy for installing post.office. As you go through it, a checklist (a series of tables, actually) is provided for you to fill out with your choice of parameters. Completing this checklist will make the installation process flow smoothly. When installing post.office you are urged to create a new account and group for the mail system. You must also decide where to install each of the parts of the system. The following sections cover these decisions and offer suggestions for optimum performance and security. 3.B.2.1 WHAT TO DO WITH YOUR CURRENT MAIL SYSTEM Since you are about to replace your current mail system with the post.office system, any existing services/programs you may have which perform as an SMTP mail server, POP3 Server, or finger service must be shutdown. 3.B.2.2 THE SYSTEM DRIVE PARTITION FORMAT An NTFS formatted hard drive is highly recommended. post.office will run on FAT partitions but you lose tremendous security features and power failure/disk crash recovery capability. 3.B.2.3 SETTING UP A NT-LOGIN ACCOUNT FOR POST.OFFICE How you set up your login account for post.office has a strong impact on how secure your system is. Please read this section carefully. We strongly recommend the use of a new account and group other than the built-in System account for sites connecting to the Internet. DECIDING WHAT KIND OF ACCOUNT TO USE Every process running under Windows NT operates with the privileges of an account. This can be a local account or, if you are using NT Server, a part of a domain. (On a workstation use a local account; on a non-primary server you may opt for either a local or global account; on a domain controller you must choose a global account.) The post.office service can operate using the privileges of the built-in System account or as any local account which is pre-configured (prior to running the installation program) on the machine. This decision is primarily a security consideration. The advantage of using an account other than the built-in System account is that the default installation of post.office will setup permissions which will not allow other processes or accounts to access any of the post.office directories/files or registry information (additionally the post.office service will be unable to read/modify/delete any system or user files). The only disadvantage of using an account other than System is that you will need to setup the local account, and group, and insure over time that they are not deleted as post.office will not be able to run if its account is disabled. USING THE BUILT-IN SYSTEM ACCOUNT If you choose to use the system account, you may skip the remainder of this section and proceed with section 3.B.2.4. When prompted for the system account please use "System" (with an uppercase S). CREATING AN NT ACCOUNT AND GROUP FOR THE SERVICE You must use the User Manager (as an administrator) to create an account and group for the service (post.office) to use during normal operation. The new account and group should be specifically for the post.office service and should have no other members or groups. Note: the account must have User Cannot Change Password, and Password Never Expires checked and must not have User Must Change Password at next login checked. NT Workstation installation notes: You will be creating a local user and group. If the workstation is also part of an NT Domain, we suggest that you use a local user and local group (specific to the workstation, not a member of the NT Domain). Be sure to include only the post.office user in the new group and that the post.office user has membership in only the new post.office group. NT Server notes: We suggest that you use a global user/global group for the post.office service account. After creating the post.office user and group, be sure to: set the post.office group to be the primary group for the post.office user: under the user properties/Groups button, select the post.office group on the left hand side and click the "Set Primary Groups" button. remove the domain users group from the list of groups for the post.office user (it is added by the user manager by default). Suggestion Your Choice Account Namepost.office Account Password Group Namepost.office-group Setting up post.office as a service You must also give the account the logon as a service privilege. This is accomplished while still in the User Manager program: Under the Policies menu, select the User Rights option. There is a click box titled "Show Advanced User Rights" which must be checked. Under the scroll bar titled "Right:" choose "Log on as a Service" and you must add the account name (chosen above) which you created for the mail system to this privilege list. You will need to select the "Add..." button, then select "Show Users", select the post.office user account (it will be near the bottom of the list), and click the "Add" button. 3.B.2.4 YOUR REGISTRATION INFORMATION If you have already purchased a license for post.office you will have a license number. If you are installing post.office and have not yet made the commitment to purchase the license, you will need to use the word "trial" in the registration information section and your software will operate normally with a 45 day period. After the trial period has expired, post.office will operated normally (footnote) but you will be in violation of the trial license agreement. License Number: 3.B.2.5 YOUR DNS DOMAIN Most sites installing post.office will already be connected to the Internet and have a registered Internet domain name. During the installation you will be asked for the domain name of the computer on which you are installing the system. This may be your organization's domain name, or possibly a subdomain. For example, if you were installing post.office on a machine named emile.math.ucsb.edu, the domain name you would specify is math.ucsb.edu. Domain Name: 3.B.2.6 POSTMASTER PASSWORD You will be prompted for a postmaster password. This password is required to perform maintenance of the mail accounts or post.office configuration. Please make a careful note of your choice as it is difficult to recover from a lost postmaster password. Postmaster Password: 3.B.2.7 LOCATIONS OF PROGRAMS AND WORKING DIRECTORIES post.office is broken up into three major parts: the executable modules, the mail processing center (or postoffice), and the message store (or user mailboxes). The locations for each of these directories can be customized during the installation. Note: It is not a good idea to use remote or network mounted directories for any part of the system. THE EXECUTABLES DIRECTORY The executable modules that constitute post.office are all located in a single directory tree. Typically this directory will be in /win32app (depending on your conventions). SuggestionYour Choice Executables/win32app THE POST.OFFICE DIRECTORY The post.office is a directory where mail is processed. All incoming mail is stored in the postoffice and remains there until it is either successfully delivered or returned. Generally mail resides in the postoffice for only a few seconds as it is routed to its destination; however, if a message is destined for a remote computer that is temporarily unreachable, the message can remain queued up in the postoffice for several days, depending on how the system is configured. Typically the system partition is used for such storage in the directory \winnt(35)\system32\spool. Make sure you put the postoffice in a place that gets backed up regularly since it also contains mail messages which are in transit. SuggestionYour Choice Postoffice/winnt/system32/spool THE MAILBOX DIRECTORY The mailbox directory is where mail is stored for users that retrieve their messages via the network using the Post Office Protocol (POP3). The amount of storage needed for this directory depends on the number of users that use POP3, the volume of mail they receive, and whether they leave their mail on the server or download it to their PC or workstation. This directory should be backed up regularly since it contains users' mail. SuggestionYour Choice Mailbox/winnt/system32/spool/post.office 3.B.2.8 EFFECT ON YOUR EXISTING MAIL SYSTEM post.office replaces your current mail transport agent. It does not, however, replace any mail user agent software you are using. Since post.office is designed to be upwardly compatible with your existing mail infrastructure, all POP3 UAs should continue to operate normally when post.office is installed as the MTA. 3.B.2.9 THE ROLE OF THE POSTMASTER During installation you will have to appoint a postmaster. Anybody listed as a recipient of mail addressed to is considered a postmaster. Each postmaster is able to configure the mail system parameters, add, modify, and delete mail accounts, and set up automatic reply accounts. Since none of these tasks require administrator privileges, the system administrator can safely appoint someone else to the position of mail administrator, thus reducing the system administrator workload. Postmasters interact with the mail system by sending it forms E-mail or a Web Browser. Thus the postmaster doesn't even have to be a local user of a machine to be able to configure it. In fact all configuration and account changes for an entire E-mail network can be handled from a remote site. Chapters 5 and 6 contain all of the information necessary to remotely configure post.office. POSTMASTER AND OTHER PASSWORDS There will be three different passwords used in the installation section: the local account password, the Postmaster password, and your personal mail account password. Each of these should be different for security reasons. The local account password (created when you created an account for post.office) is used by the Service Control Program (in Windows NT) to login the post.office service and give it access rights on the machine it is running. The postmaster password will be used by post.office to verify any administrative actions such as creating a new mail account. Your mail account password is the password assigned to your personal E-Mail account and allows you to retrieve your mail (as it is also your POP password) and make any changes to your personal E-mail account (like going on vacation). Local Account Password: Postmaster Password: your Mail Account Password: 3.B.2.10 IMPACT OF MIGRATION FOR MAIL SYSTEM USERS Every time post.office opens an account for a user, that user will receive a message from post.office called the greeting form. The idea of the greeting form is to welcome the user to their account and let them know how to change their password and other select account information (see figure 3.B.1.7a below). Thus, one consequence of installation will be that all the users on your host will get this message: To: You@Your.domain From: Account-Manager<> Reply-To: Account-Manager<> Subject: Form: Greeting MIME-Version: 1.0 Information An electronic mail account has just been opened for you. This account is configured as indicated below. Make sure you note your password and safeguard it since this is the only time it will be sent to you. See the instructions below the account summary for information on how to make changes to your mail account as well as for explanations about each of the fields. Your-Name: [your name here] (Note: your name is sometimes referred to as your account name) Mail-Account-Password: [your secret here] Internet-Addresses: [your address@your.domain] Finger-Information: [Tell the world how happy you are] [about post.office] ========================================================================== Here's some information about changing your account: Only the system administrator can change your name or addresses. If you want to change your password or your finger information, you can do so with a World Wide Web browser (such as NCSA Mosaic), or via E-mail. You simply fill out a form indicating the desired changes and submit the form to the mail system. To request the user Information form: via the Web: connect to http:// via E-mail: You can get the E-mail form to modify your account by simply replying to this message and sending it in, or send a new message To: with the word "Information" as the message body like this: To: Accounts@your.domain Information After receiving the Information Form, make the appropriate changes to the form (use the "Reply" feature of your mail client if you are using the E- mail interface), put in your password, and submit the form. If you don't receive an error message, the changes have been accepted. ========================================================================== Here is an explanation of each of the fields shown for your account: Your-Name ... (full form is not shown) Figure 3.B.2.7a: This is the greeting form which is sent to new users to orient them to how to get the most use out of post.office. 3.B.2.11 CHECKING THE PERMISSIONS FOR THE SYSTEMS DIRECTORIES To insure that the post.office installation program is able to give the proper permissions to the post.office system, it is necessary that the owner of the System directories be the Administrators. You can easily check that this is the case with the File-Manager: Select the system directory (/winnt or /winnt35 or /windows depending on your specific installation) and select Permissions... under the Security menu item. The directory owner must be Administrators for the install to proceed. If this is not the case, you will need to take ownership of the directory, sub-directory and files within, as one of the administrators (this is not a step to take lightly so please review the on-line help and additional manuals to be sure that you understand this operation). 3.B.3 INSTALLING POST.OFFICE Now that you are prepared you are ready to begin this step-by-step guide to installing post.office. If you haven't gone through the previous section and planned for the installation, please do so now. A good plan at the start will make the installation run smoothly. 3.B.3.1 THE INSTALLATION PROCESS There are three main steps to installing post.office. First the software is unpacked (you receive it as a compressed file), then it is installed on the system. Finally a special program is run to initialize the mail system and set up accounts. UNPACKING POST.OFFICE The post.office system is distributed in compressed-file format which is common for Windows NT software. When uncompressed (use your WinZipNT or equivalent program), the result is a setup package which is fairly typical of the software written for the Windows NT operating system. The package contents need to end up in a temporary directory so that post.office can be installed. When the installation is finished you can remove the temporary directory. RUNNING INSTALL After loading the package onto your computer and unpacking it, you need to run the setup.exe program. To do so, from a DOS prompt: Change directories to the temporary directory where you unpacked the package: c:\temp> cd \temp\post.office Execute the install program: c:\temp\post.office> setup.exe You will be asked the questions which you have already answered in the pre-installation planning section you just completed (above). If at any time you quit out of the setup program, you can run it again later to finish the installation process. FINISHING UP When you're done with setup, it may tell you that some things still need to be taken care of. If so, write them down and perform the tasks when you get a chance. In any case, the system should be running so you can start exploring the variety of features of post.office. 3.B.3.2 CHECKING TO SEE IF INSTALLATION WORKED Maybe you're wondering if everything is working. You can double check this by initiating a finger query at a DOS prompt: > finger postmaster@your.hostname You should see this: [hostname] Account Name: Mail Administrator Email address: Postmaster@your.hostname ---------- mail system administrator. Which means post.office is up and running, faithfully serving your E-mail needs. 3.B.3.3 POSTMASTER AND PERSONAL ACCOUNTS The installation program you just ran helped you to set up postmaster and personal accounts. This section's purpose is to ensure that you understand the function of the different accounts so that you can get the most out of them. THE POSTMASTER ACCOUNT The purpose of the postmaster account is: To define who is given access to post.office configuration and operation. To define the individual or individuals who are responsible for day to day supervision of the mail system. These two purposes are closely related. However they are not identical. The first point asserts that when you are postmaster, you have the keys to the car (Note that you can have as many sets of keys as you like). The reason that you and perhaps a few other postmaster cronies are given the "keys" to the system are less to create an E-mail nomenclatura then to establish strict security controls over who has access to the system. If there are too many postmasters, or the postmaster account becomes public domain, then you are short-circuiting one of the primary security mechanisms of your mail system. You will use your position as postmaster to set up new accounts, make configuration changes to the system, and take care of any errors that occur. You will find that in most cases, too many cooks can spoil the batter. In general, your mail system will function better if only one or a few people are entrusted with mapping out and implementing an E-mail game plan. The algorithm for who is a postmaster is simple: Anybody who's E-mail address is listed in the postmaster account delivery field is a postmaster. You do not need to have an account on the post.office host in order to be a postmaster. The second purpose of the postmaster account is that it identifies the responsible party or parties for all E-mail related questions. The postmaster is responsible for dealing with any errors which crop up. For example, most frequently this will mean invalid addresses. The postmaster has to decide whether messages with such addresses should be returned to their sender or forwarded to a user on the system. The postmaster is also the person most often turned to when folks outside your E-mail network have a question about how to contact someone in your organization, or other E-mail related questions. It is conventional that every domain support the "postmaster@domain" address, so that the outside world can have a contact on your network. Note that the postmaster account is not a personal E-mail account. Even if you are a postmaster, you should have a personal account to which all your personal correspondence should be addressed. You should then include the address for your personal account in the delivery field of the postmaster account, so that you will have postmaster privileges on the host and be able to access both E-mail and web forms. PERSONAL ACCOUNTS: The purpose of a personal account is to give an individual access to E-mail. In some cases accounts can also be used to deliver mail to a program or to automatically distribute information (using the auto-reply utility). Thus the postmaster(s) should have a personal E-mail account in order to have access to E-mail as well as to be able to have access to post.office E-mail forms. Users who have personal accounts on a host can receive mail through that host, as well take advantage of other features such as having their addresses re-written on outgoing messages, having finger queries answered, and advising correspondents when they are on vacation (using the auto-reply utility). 3.B.3.4 WHERE TO GO NOW You can now proceed to the operations chapters (chapters 4, 5 & 6) to learn how to run the system. But first, please note section 3.B.4.2 below (regarding changing the Postmaster account) since you may find it useful someday. We've also included below a brief section on setting up postmaster and personal accounts to orient you before you plunge into the nitty gritty of operations. 3.B.4 COMMON INSTALLATION MISHAPS What you should do if you have to abort install half-way or end up without a valid postmaster. 3.B.4.1 RERUNNING INSTALL If you quit out of the setup program before it is finished, you can simply rerun it later to complete the installation process. This can be done by following the instructions in section 3.B.5.1 "Removal of the directories". After this is completed rerun the Setup program and installation will be completed properly. The post.office system will not be started until you explicitly tell setup to start it, and it will warn you if any problems need to be taken care of before the system can be started. 3.B.4.2 CHANGING THE POSTMASTER ACCOUNT It is possible to accidentally configure post.office so that there are no valid postmasters. If this happens, the system will not allow further configuration changes, in other words there will be no way to fix the problem with the postmaster account. If this occurs, contact Technical Support at Software.com (Support@Software.com, 805-882-2470 voice, or 805-882-2473 fax). 3.B.5 DE-INSTALLATION We are confident that you will be entirely satisfied with post.office. However, if you do want to remove it from your system, you can do so quickly and easily. Before you remove post.office from your system, we welcome you to contact customer support at Support@Software.com or by telephone at 805-882-2470 to discuss a solution to your problem. Note: since post.office runs as a service, you can easily disable it by selecting it and turning it off, without removing the program from your system. 3.B.5.1 REMOVING POST.OFFICE The setup program will remove the service if it is executed anytime after the first installation. It will automatically detect if there is currently an installed post.office MTA service and verify that you want to remove it. If you answer yes to the prompt, the install program will stop the service (if it is currently running), remove it from the services list, remove the registry entries, and delete all exectuables. All that will remain is the post.office spool directory - which could contain mail messages. The setup program will have re-assigned ownership to the administrator and given it full control permissions. Therefore, it is a simple task to delete this directory if desired.