- What the postmaster does.
- What an account is.
- E-mail forms.
- Web forms.
- What aliases are for.
| This
is the conceptual part of operations in which we explain:
|
Concepts in Postmaster Operations |
This chapter covers the major concepts which define your role as the postmaster of the post.office mail system.
First we look at what your job will be as postmaster and the forms you will use.
We then explore three major themes: post.office accounts, operations with E-mail or World Wide Web (WWW) forms, and post.office aliases . The definition of accounts, forms, and aliases have implications which are specific to the post.office system, and cannot be equated with, for example, login accounts or system aliases (such as on UNIX systems).
An introduction to the role of the postmaster and the E-mail forms used to operate post.office.
Running post.office is quite easy. Many other E-mail message transport agents are so complex that they must be maintained by experienced computer users and often require programming skills. With post.office, this is not the case. Anybody who is comfortable with computers can be the postmaster.
The postmaster's first job may be to install post.office, a procedure which is described in chapter 3. If the postmaster does not have root or administrator privileges on the host where post.office is being installed, the installation will have to be performed by the system administrator of that machine.
The next step is setting up accounts for all the people who will receive E-mail at the particular host you are setting up.
On a UNIX machine,
post.office may have automatically set up accounts (depending
on the choice you made during the installation) for everybody
who already had a login account on the host, so you will only
need to create accounts for users who don't have a UNIX login.
If you are installing
post.office on an NT system, accounts will need to be
established manually since the security APIs for Window NT necessary
to provide an automated method were not yet solidified by Microsoft
at the time the installation program was written.
You will use the account form (described in this and the next chapter) to add additional users or to make changes to their accounts from time to time, as well as closing old accounts. All this is done simply by submitting the account form via E-mail or using your web browser. (Note: users can make certain limited changes on their own using a special form provided for that purpose, the information form.)
As the postmaster you'll start receiving all messages which are sent to "Postmaster" in addition to your personal mail. If you run a large system or are hooked-up to the Internet, you may get a fair number of messages as people write you to ask you about how to find someone on your network and other such questions.
The postmaster also receives any error messages which are generated by post.office, most often when someone sends a message to your domain with an address that is incorrect.
Finally you may want to make configuration changes to optimize system performance or make changes to your addressing system.
We've made a real effort to make things simple for the postmaster. Your users are able to change certain aspects of their own accounts and will generally leave you alone. This should minimize the administrative aspects of your job as postmaster.
Users can choose how their messages are delivered and change their password on their own using a scaled-down version of the Account Form called the user Information Form. When leaving town for a few days, they can set-up the auto-reply handler to let people know that they're on vacation.
There are no arcane and apparently nonsensical configuration files to puzzle through, such as the sendmail.cf file. We tried to do everything in English. If you catch us being overly technical and using esoteric jargon and abbreviations, E-mail us, and we'll fix it.
When we designed post.office the idea was to create an enterprise message transport agent that was truly user friendly. We settled on a fill-in-the-blank format for configuration and system maintenance because we felt this was the most self-explanatory way to do it. The result is configuration by forms, meaning that all configuration and user account changes are performed by submitting simple forms to post.office.
A form is an E-mail message or a World Wide Web (also know as simply the "Web") document containing various fields. A field represents a piece of information that is required by post.office in order to carry out its tasks.
The Web forms use text entry boxes, buttons, and such which provides an intuitive point, click, and type interface.
In E-mail forms, each field name is followed by a pair of brackets, between which you insert the information that post.office needs.
Post.office will supply you with the forms you need upon request. With E-mail, you use the reply feature on your user agent, fill out the form and return it. When using the Web, you simply point your favorite web browser at the post.office host to request and submit forms.
If you get stuck, turn to the remaining chapters which are the reference chapters that cover post.office operations. You can go there, for example, to find step-by-step instructions on how to fill out a particular form. Most of the time, however, you will be able to fill out a form without referring to the manual: we've included a good deal of explanatory material within the forms themselves. But if you need more details, chapter 5 and on are where you'll find them.
Most of the forms are for you, the postmaster. However there are also two forms for users, one to welcome and introduce them to their E-mail account, and another to allow them to make limited changes to their account. These are the kind of changes which have no effect on the integrity of the mail system yet need to be made from time to time. This should be convenient both for users who need to make the changes and for the postmaster who doesn't have to be bothered with them.
An introduction to three fundamental concepts for postmaster operation: what an account is, what a form is, and what post.office aliases are.
Everybody who gets E-mail through post.office has a mail account. The information in an account determines how E-mail messages are accepted and delivered for that account, what directory information is provided, and if that account makes use of any special features such as the Auto-Reply Handler.
Information about the users who receive E-mail on your system is organized by post.office into accounts. Accounts contain, among other information, the name of the user, their E-mail address or addresses, how and where they receive their E-mail, what their password is , and what their directory information is. The sum of the information in all the accounts is held in an internal post.office account databaseaccount database 4 -. There are five principle kinds of information in each account in the database:
While most of the account information is controlled solely by the postmaster, certain items which apply only to the account, namely the password and certain delivery and directory information can be changed by the account's owner (i.e., the individual user, so as to avoid bothering the postmaster).
post.office uses the information in the account database to make decisions about how to handle incoming E-mail messages. (A detailed description of each piece of information in an account can be found in section 5.1.2.)
The illustrations below demonstrate a couple ways that the information in an account ends up in actual E-mail (4.2.1a) and in a reply to a finger query (4.2.1b):
 |
figure 4.2.1a - How account information is used in messages. In order to ensure that mail recipients (such as Jim Jones in this example) can send a reply back to the sender, post.office can rewrite the From: header of outgoing mail with the sender's primary address (which is the first one listed on the account form).
 |
figure 4.2.1b - How account information is used in finger queries. Finger queries elicit the user's name and official E-mail address, as well as their custom information. In this case Jane Doe uses her finger information to make her mailing address and telephone number public.
Security of post.office accounts is enforced by careful use of passwords and access-domains. These concepts are discussed briefly below. A more comprehensive discussion of security is provided in chapter 8.
Passwords (recall that we are referring here to the mail account passwords and not to login account passwords), when kept private and changed from time to time, act as electronic keys.
Note: post.office passwords are case-senSiTive, arbitrarily long strings of characters (6 characters minimum).
Note: be cautious about sending an unencrypted password across a public network (such as outside of your organization and across the Internet). If passwords are sent "in the clear" over such a network you may want to use the access domain feature for added security (see below and chapter 8).
An access domain restricts the places from which a user can obtain access to their account, for example to read their E-mail or change their account information (for E-mail configuration the access domains are applied to the From addresses in the E-mail message and for WWW configuration the access domains are applied to the WWW browser's host name or IP number. Additionally, configuration by E-mail can be disabled via the Security form, if desired).
Access can be limited to a single computer or a set of computers in an addressing hierarchy. A single computer can be specified either by specifying its fully-qualified domain name (e.g. chicago.sales.software.com) or its IP address. Likewise, a set of computers can be specified by using an incomplete DNS address or IP address. An incomplete DNS address is one which does not specify a host, while an incomplete IP address is one which contains a "0" (zero) in any of the 4 places. The "0" acts as a wildcard.
The access domain feature can be left blank to allow access from anywhere (with the appropriate password) or contain the keyword "none" to prevent any access at all to an account (except by the postmaster).
If a single computer is specified as the access domain, for instance chicago.software.com, a user can not access mail from any other machine even when giving the correct password. If instead the access domain is specified as software.com, the user can access his or her mail from any computer within the software.com domain.
Use of domain names or IP addresses is a trade off between flexibility and security. Using a host or domain name is easily understandable and immune to network topology changes while an IP address or range may not be. Generally speaking IP addresses are safer than domain names as access domains.
For maximum security, you can configure your access domain to be the IP address of a single computer in your office. With this precaution in place, keeping the door to your office locked or otherwise restricting access to your computer will ensure that nobody can access your E-mail even if they obtain your password. This subject is treated in greater detail in chapter 8, post.office security.
For example, an access domain might be set up as follows:
chicago.software.com 128.123.45.0 math.ucsb.edu
The domain entries would allow you to access the account from any of the following computers:
chicago.software.com complex.math.ucsb.edu fourier.math.ucsb.edu
The IP entry would allow access from these hosts:
128.123.45.22 128.123.45.67 128.123.45.82
However, you would not be able to access the account from the following:
newark.software.com laser.ece.ucsb.edu 128.123.46.22 128.124.45.67
(Emphasized areas show why above addresses do not conform to specified access domain.)
The finger access domain limits the domains that have access to an account's finger information. If access is not allowed, no information is returned for the request. The rules for finger access are the same as those for access domains discussed above.
For example, you may want to restrict your finger access to your company's domain (possibly because of company policy), so that only people within your organization can get access to the directory information in your account. You can run the finger server while being certain that nobody outside your company can access that information.
Note: The same security concerns apply to finger access as discussed in the previous section on access domains (and are covered in more detail in chapter 8).
This section describes the precise steps which post.office carries out when it verifies and limits access domains when processing forms and delivering messages. This discussion is a bit on the technical side, but this will be helpful if you run into trouble figuring out exactly how access domains work.
Network Servers
When a client connects to the web server on your machine, post.office is given the IP address of the connecting computer. To determine if this client computer is allowed to connect to the web server for configuration purposes, the web access domains (which are specified using the security form) are consulted. The algorithm used to determine if the client computer can access the server is as follows:
Once it has been determined that a client machine is allowed to connect, the user attempts to authenticate with the server. When a user correctly identifies herself, the individual access domains in her account are then checked to see if she is allowed to configure her account from that location. The algorithm for checking the user's individual access domains is identical to the algorithm shown above.
The POP3 server works the same way as the web server except that there is not a general POP3 access domain variable limiting all connections. each account must be restricted individually.
E-mail Managers
The E-mail managers do not have the same luxury as the web and POP3 servers of knowing which client machine originated a mail message. This is due to the fact that mail can be sent through any number of machines before it reaches post.office. The managers therefore use access domains in a different way.
When a form is received by an E-mail manager, the sender's address is used to determine who submitted the form (the address is taken from the SMTP envelope, not the From: header of the message, as discussed in chapter 8). The checks used to determine if the form should be accepted and processed are as follows:
99% of post.office administration is done using "fill-in-the-blank" forms. Account administration is done using an account form, errors are dealt with using an error form, and so on.
(The are a very few things that you really can't do without a form, such as starting post.office up and shutting it down. Start-up and shut-down on UNIX machines is described in chapter 6. On NT hosts, post.office runs as a service.)
Forms can be obtained from the account manager or from the configuration manager by sending an E-mail message to one or the other (each manager has its own address). Insert the name of the form you want in the body of the message. The illustration below (4.2.2a) shows how a request should be filled out for the account form:
To: Accounts@your.host.domain Subject: <can be blank or anything desired> Other-Headers: Date:, cc:, etc. <not necessary> ------------------------------------------------------------------------------- account
|
Figure 4.2.2a - You request the account form by E-mailing to the address "accounts" on whatever host you want the form from.
The error handler will send unsolicited forms to the postmaster. These are generated when an error occurs which can only be resolved by the postmaster. (see section 6.2 for more dirt on this).
Generally, if you err in submitting a form request, post.office will send you a list of the forms that are available to you.
The tables of contents in chapters 5, 6 and 7 list which forms are available (they are all highlighted) and tells you where to look to find the specific instructions on their use. Specific instructions on retrieving particular forms are given, step-by-step, in these sections.
Short Cut!
Note: You can request as many forms as you like on a single form request (although you can only get account forms from the account handler and configuration forms from the configuration handler). To do this, simply list all the forms you want in the body of the message, one form name per line. For example, you could request the account forms for every user on your system by first requesting the list form, then replying to the list of account names you receive after deleting any accounts you might not want. Whenever you need to submit more than one form, this will save you time.
Short Cut!
Note: You can add an asterisk ("*") to any form name request (it must immediately follow the form name) in order to get the E-mail form without any of the help information. (i.e. "account*"). This way you get only the field names and brackets.
Short Cut!
Note: You only have to type enough of the form name you want so that it is not an ambiguous request - post.office will complete the form name. (i.e. "acc" will get you an account form and "acc*" will get an account form without help).
You select the HTML (Web) version of post.office forms by pointing your web browser at the host where post.office is installed. Web browsers allow you to manually enter a URL. Simply enter your host's URL:
http://host.domain:port#
Note: if the default network port#, which is 80 for the Web, is used by post.office, you can skip the colon and port# part of the URL so that you would type:
http://chicago.software.com
The post.office web server then asks for your E-mail address and your account password (figure 4.2.2b below). Using this information, it will verify that you have an account on the host and that your password is correct.
 |
Figure 4.2.2b: In order to access any of the web forms, post.office must first verify your name and password to determine if you are allowed access to the forms. This is necessary, since unlike the E-mail forms, the postmaster password is not required to submit a form. Instead the password is provided at the beginning of every web session.
If you log in as "postmaster@your.host.domain" with the postmaster password, the menu will list all of the various post.office account and configuration forms which are covered in the following chapters. (Note: You can also log in as postmaster using your personal E-mail address as long as you are listed in the delivery section of the postmaster account and you log in with the postmaster password rather than your personal account password).
  |
Figure 4.2.2c: Once post.office has verified that you are indeed allowed access to the forms on the host you are logged in to, you are presented with a menu of the forms which are available to you.
Normal users logging in with their personal password will only have access to the limited subset of forms appropriate for users.
Web forms include highlighted words which you can click on in order to obtain further information. For example, clicking on a field name will give you a description of what the field means and what your options are in filling it out.
Short Cut!:
When you have more than one postmaster on your system, you do not need to have them all listed on the postmaster account. Rather, you can have one postmaster designated in the "Forwarding-Addresses:" field of the postmaster account form, who will be in charge of handling error action messages and any other messages generated by post.office. Other postmasters do not have to be listed (so that they won't receive superfluous messages) and can log on to the web server as "postmaster@your.domain" using the postmaster password when they need access to the mail system.
In order to make the most efficient use of post.office, you need to understand how forms work. You need to know what a field is, how to use MIME (multimedia) attachments (for E-mail forms only), the role of forms in security, and how to figure out what you did wrong if a form is returned. These topics are discussed below.
When you get an E-mail form from post.office, use the reply feature of your user agent to fill out the form and return it. Don't worry about it if your user agent puts a bunch of symbols such as an angle bracket (>) down the left margin of the form. post.office will be able to read the form anyway. (Note: in order to be able to read forms in spite of these symbols, forms must be at least ten lines long. This is important when submitting the queue form or the list form after deleting part of the form.)
Web forms can be filled out as soon as you receive them. Generally they are a little easier to use than E-mail forms due to their graphical point-and-click nature, and are preferred by many people.
A form is made up of fields and their corresponding values. Each field consists of a parameter which can (or sometimes must) be specified in order to configure post.office. Whenever possible, fields are multiple choice with the options listed adjacent to the field or described nearby (E-mail forms), or selectable from a scroll menu or buttons (Web forms), to keep things easy. The figures below serve to illustrate what a field is and the rules you should follow when filling out a form:
 |
figure 4.2.2d - Fields: where information is entered on forms (E-mail form is shown in this example).
|
figure 4.2.2e - Fields: where information is entered on forms (Web form is shown in this example).
If you make a mistake either the form will be returned to you, with an explanation about some field missing, or in some cases the entry for the field may be ignored.
Note: E-mail forms include one or more lines at the very bottom which are there to tell the post.office program which form it is. Do not edit or modify these lines.
MIME is a standard message format that allows users with MIME-enabled user agents to send attachments of various formats along with their E-mail. Frequently it is used to send files from one user to another.
Aside from including just about anything you want in an E-mail message, you can use MIME in post.office E-mail forms. You can attach files to your forms when you want to avoid entering large blocks of text between the brackets or in text boxes. You can also use MIME attachments in order to make maximum use of the auto-reply handler to send back large amounts of textual information without human intervention.
Reply-Message: [Attachment]
|
Figure 4.2.2f: A MIME attachment can be used to specify field information. In this case only one attachment is used, so it is not necessary to differentiate between attachments.
or, with two attachments:
Reply-Message: [Attachment 1]
[Attachment 2]
|
Figure 4.2.2g: When more than one attachment is used you should specify which is which by numbering them.
Note: In order to include a large block of text in web form, simply paste or type the text into the appropriate field. Since there are no brackets to deal with, it should be as easy as including an attachment on an E-mail form.
Because it is fairly easy to forge E-mail messages in any E-mail system and anybody on your network can log onto the web port of your host, it is important to make use of the security features of an account in order to preserve the security of remote configuration. The postmaster is strongly encouraged to restrict which computers the postmaster forms can be accessed from.
Even within the access domain, the postmaster password is required to submit any of the postmaster forms.
Similarly, users can only request a form or log in to the POP server from within the access domain which you (are strongly urged to) specify in their account. Furthermore, E-mail forms are delivered to the addresses listed in the user's account, not to the return-path shown in the request for the form. Users, like the postmaster, must be sure to include their account password when they submit any forms to post.office.
Here are a couple of the most common mishaps encountered and helpful tips for dealing with them :
I. I can't remember which address to send E-mail form requests to.
The main thing to remember is that you send form requests To: either "accounts@host.domain" or "configuration@host.domain". As long as you get the address right, you will get at the very least a list of the available forms returned to you. Then you can send a proper request containing the form name in the body of the message.
II. When I get E-mail forms back from the system, they are messy and mis-aligned.
The forms aren't exactly art, but they should look fairly neat as long as you have your font size and screen width set correctly and are using a non-proportional font such as courier, which is used in the example below. If you don't see something that looks like the example below, adjust your window size and/or your font.
Your forms should look like this (this is part of the account form):
GENERAL INFORMATION -- (See the Description Section Below for help)
Account-Name: [] (Jane Q. Smith)
Account's-Password: [] (password)
Access-Domains: [] ("none", host.domain or domain, blank)
|
Not like this (font size too large):
GENERAL INFORMATION -- (See the Description Section Below for help) Account-Name: [] (Jane Q. Smith) Account's-Password: [] (password) Access-Domains: [] ("none", host.domain or domain, blank)
|
(Notice that the phrase "Section Below for help" ran over to the next line.)
Nor like this (proportional font):
|
GENERAL INFORMATION -- (See the Description Section Below for
help)
|
(Nothing lines up and its hard to see what's going on.)
You may run into similar difficulties with the way forms appear on your web browser. Simply reset the preferences and the forms should straighten out.
III. My form didn't work
One common problem stems from a form being too short. Forms must be at least 10 lines long. If you delete too much of a form (for example if you are replying to the list form in order to get some accounts), then nothing will happen.
Another problem stems from not having your user agent configured correctly. Make sure it is sending outgoing mail to your post.office host. The form has to get to post.office in order to work. Otherwise all bets are off. (Be especially alert for this one when you just reconfigured your network, for example when you've just moved.)
Finally, you may have gotten things just a teeny-tiny-weensy bit off. Get the form back from post.office and look for typos.
IV. Your problem isn't here
Take a look at our FAQ. you can either FTP (anonymous@ftp.software.com) it or look at it on the Web (http://www.software.com). There's a lot of good troubleshooting material and real life advice to be found there.
There are three distinct types of aliases supported by post.office. All three perform the function of delivering mail for one address to another address.
This section describes the differences between, and the uses of, the three distinct types of aliases available in post.office.
Note: This discussion of aliases is relevant only to understanding and creating aliases for specific addresses. If you want to route mail for a group of addresses (for example, all mail addressed to a specific domain or sub-domain), you should use the mail routing table on the SMTP form described in chapter 6.
An alias address is an alternate address for a post.office E-mail account. Each alias address is basically a different version of the primary address for the account, even if it is entirely dissimilar to the primary address. A message addressed to any of an account's alias addresses is delivered to that account.
Each account must always have an address which includes the host name. For example, an account on a host named chicago must include an address similar to:
Jane.Doe@chicago.software.com
Many sites prefer that the specific host name not be included on the sender's outgoing electronic mail address (this is called "host name hiding"). If host name hiding is desired, the account will also have an address which does not include the host name.
Jane.Doe@Software.com
This address should be listed first on the account form (which would make it the primary address which is used on the "From:" line of outgoing mail). The other address, Jane.Doe@chicago.software.com would be listed below, as an alias address. (For more, see the information on host name hiding in the chapter 3 discussion on setting up your E-mail network).
Furthermore, most UNIX mail
systems use the user's login ID as their mail address, so further
aliases may be required. For instance, if Jane Doe's UNIX login
is "jane", you might also have the following addresses
in her account:
jane@chicago.software.com
jane@Software.com (second address may not be necessary)
Consequently it is desirable that all of the above addresses be recognized as referring to a single user's account. A full list of addresses, including the primary address and all alias addresses, for Jane might therefore be:
Jane.Doe@Software.com
jane.doe@chicago.software.com
jane@chicago.software.com
jane@software.com
These addresses can all be specified in the Internet-Address field of Jane Doe's account form and will be recognized as referring to her account:
Internet-Addresses: [Jane.Doe@Software.com]
[Jane.Doe@chicago.software.com]
[jane@chicago.software.com]
[jane@software.com]
|
Figure 4.2.3a: The Internet-Address field of Jane's account form (E-mail version) is shown above. In this case, the addresses reflect a need for an address which "hides" Jane's host's name, an alias which includes her host name, and two aliases based on her UNIX login name.
Short Cut!
Note: There is another reason for Jane to have an alias for the address "Jane@chicago.software.com". This allows her co-workers, whose mail goes through the host "chicago" (or any host with a channel alias for her), to send her E-mail at the address "Jane", which is easier than typing out a full address. This works because post.office automatically completes incomplete addresses by adding a host name and a domain (note that you can change this default using the system configuration form, in which case you might want to change you aliases accordingly). Thus the post.office on chicago, in the domain Software.com, will take the incomplete address "Jane" and turn it into "Jane@chicago.software.com", which is a valid address for Jane. This feature makes it a little easier for users sharing the same host to send each other mail.
An alias account is an account created to give delivery to one or more (usually multiple) people who already have accounts on a host. For example, there may be several people who need to receive any messages addressed to "sales@software.com"
Since all addresses must be uniquely assigned to an account, this address can not be listed as an alternate address on another account. Instead, this is handled by creating an account for the address sales@software.com. Deliveries to all the people who are sharing the responsibility of messages for sales is illustrated in the figure below.
 |
Figure 4.2.3b - An illustration of alias account delivery. A message to "sales" is forwarded to Jane, Homer, and Narcissus.
The reason that a single message addressed to "sales" is delivered to three people is that the delivery field of the alias account for sales includes the addresses of Jane, Homer, and Narcissus. The following illustration shows what the Internet-Address and Delivery fields of the account form for "sales" look like:
Internet-Addresses: [sales@software.com]
Forwarding-Addresses: [Jane@chicago.software.com]
[Homer@newark.software.com]
[Narcisus@fresno.software.com]
|
Figure 4.2.3c - The above segment of an E-mail account form dictates the process illustrated in figure 4.2.3b. The "Internet-Address" field dictates which addresses the account will accept messages for. The "Delivery" field tells post.office to deliver any incoming messages to Jane, Homer, and Narcissus.
At Software.com, alias accounts are established for several other addresses as well. It is required that all sites connected to the Internet maintain a valid address for "Postmaster," where people can contact the person responsible for mail at that site.
In the example below, the postmaster of software.com is Homer, a paragon of responsibility and a model system administrator. Given his near-total knowledge of just about everything, we've also put him in charge of the address "support," so that he can deal with the occasional requests that come in to software.com for technical support.
Jane, who is our point person when it comes to public relations, gets any mail addressed to "info". The result is that our alias addresses on the host chicago.software.com, follow the flow chart below:
 |
Figure 4.2.3d - The tangled alias accounts above show how mail for "sales", "postmaster", "support", and "info" gets shuffled to Jane, Homer, and Narcissus.
TIP:
A good rule of thumb is to create accounts for all the real (i.e. people) users, assigning them the alias addresses that refer directly to them and only them as individuals. On the other hand, whenever you need an address for a specific purpose such as receiving information requests, instead of adding another alias to a user's account, create a new account and assign deliveries to the appropriate individual recipients. If someone else has to take over the job of handling the information requests down the road, it'll be easier to change a single alias account than to go about finding alias addresses in people's personal accounts.
Note: No greeting message (the "hello" message sent to new accounts when they are created) is generated for an alias account; therefore, the people listed for delivery in an alias account do not automatically receive the account password. This allows the postmaster to assign one person in the group the responsibility of modifying the account with the user information form (or to disallow any of the users this access). The postmaster must inform the selected individual of the account password. None of the others, though they also receive mail addressed to this account, will be able to modify the account with the user information form without the password.
Channel aliases are designed to handle the special case of incoming messages that are forwarded to another mail transport agent located on a different host (i.e. for an address which has no local delivery). Channel aliases are specific to a particular message channel, such as the SMTP Channel. Whenever a message enters the post.office system destined for one of the listed channel aliases, the address is immediately rewritten and the message delivered to the new address at a remote host. The message is delivered to the remote machine without ever being seen by the Account-Handler.
This type of alias is more efficient than account aliases for forwarding addresses since fewer processing steps are performed; however, they are less powerful since they are limited to routing messages to another host.
A situation where channel aliases are used extensively is when a site sets up a mail "hub" through which all incoming messages are routed before getting delivered to the intended user's host machine. This set-up is described in the chapter 3 discussion of network configuration, for example in the discussion of how to set up a firewall.
Figure 4.2.3e illustrates a channel alias in action. Jim Jones of the XYZ organization occasionally sends mail to Jane Doe. Unfortunately Jane recently left us to start her own company. In order to help her continue receiving her mail, we set up a channel alias for her using the SMTP aliases form:
Jane.Doe@Software.com --> Jane@JaneCorp.com
Whenever a message arrives addressed to Jane.Doe@Software.com, the address is replaced with her new address. The message is then forwarded to its new destination, JaneCorp.com (figure 4.2.3e).
 |
figure 4.2.3e - Jane's channel alias: a message from the host xyz.org shows up at software.com for Jane. The SMTP channel module recognizes Jane's name and immediately redirects the message to Jane's new address at JaneCorp.com.
A good rule of thumb with regard to channel aliases is that if an account receives messages which are all delivered to another host, it should probably be replaced by a channel alias which is more efficient. For specific instructions on setting up channel aliases, see section 6.1.4.
