This appendix describes the design architecture of the Netscape Messaging Server software. This information is helpful if you need to assess the software architecture to alleviate security concerns or are curious about the inner workings of the Messaging Server.
The Messaging Server functions are distributed among a number of software modules that work together to carry out message handling and other activities. As Figure A.1 shows, the Messaging Server is divided into six major components. These components, which form the top-level architecture, all run under the supervision of the dispatcher:
The Messaging Server architecture, top level.
The following sections discuss each of these components.
The dispatcher's job is straightforward: it monitors all network ports related to email and launches the appropriate modules to handle incoming connections. The dispatcher also controls the number of processes that can be operating simultaneously so that it can limit the amount of computer resources used to process email.
For example, when the dispatcher notices an incoming email message, it starts up the MTA, which takes the message in and processes it.
The module configuration database contains the Messaging Server configuration information. Every Messaging Server module has a database that contains the configuration information for that module. For most modules, this database is fairly small because it contains only a few configuration options and a list of error messages.
The Messaging Server is first and foremost a message transfer agent, or MTA. The MTA is a powerful and complicated set of modules. Because the MTA represents the primary functionality of the Messaging Server system, it is described in detail in this section.
An MTA can be used to coordinate message transfer between a small number of computers on a local network or to orchestrate the transfer of thousands of messages beyond the local network to millions of Internet users.
The Messaging Server MTA is divided into three components: message channels, the local delivery channel, and handlers:
These three basic components of the Messaging Server MTA are shown in Figure A.2 and are discussed in greater detail in the following sections.
Message channels, the local delivery channel, and handlers.
The Messaging Server message channels exchange messages with other MTAs and accept new messages from mail clients. Message channels can relay messages to and from other the Messaging Server modules and, in some cases, accept and dispatch messages without consulting other modules. (If a channel alias is used, an incoming message can be immediately forwarded to another MTA without being handled by another module.) One of the principal message-channel tasks is to accept messages addressed to local recipients (users with Messaging Server accounts) and forward them to the local delivery channel.
A message channel is a group of Messaging Server modules that transfers messages using a single protocol such as SMTP or X.400. Each channel consists of an accept agent, a routing agent, and a deliver agent, as shown in Figure A.3.
SMTP channel is an example of a message channel.
Accept agents are modules that accept incoming messages detected by the dispatcher. The accept agent can be configured to accept messages only for recipients that it recognizes (that is, for those who have Messaging Server accounts). The Messaging Server can also accept messages and forward them to other MTAs.
Once a message comes in, it is immediately transferred to the message-channel routing agent. The routing agent examines the message headers and makes sure that the instructions they contain are compatible with the way the message is being handled. It then forwards the message to the deliver agent (if the message is to be relayed to another MTA), the account handler (for delivery to a local user), or the error handler (if there is some confusion about what to do with the message). Messages can also enter the message channel at the routing agent if they originated in another module of the Messaging Server (such as the AutoReply handler) or from another message channel (that is, from a different protocol).
The deliver agent sends messages to other remote MTAs that use the same protocol (such as SMTP). The deliver agent takes a message from the routing agent, contacts the remote MTA for the recipient of that message, and delivers the message to that MTA. The deliver agent determines which remote MTA the message should be sent to.
The SMTP channel is a common example of a message channel and is a standard feature. (See Figure A.3.) Most MTAs on the Internet use SMTP to accept and relay messages.
In some cases, a message is transferred solely by the SMTP channel--this means that the message is accepted, routed, and delivered (to another MTA) through the SMTP channel. (For example, this is the process that is followed if the message is just being sorted and forwarded to another MTA on the Internet or your local network.)
In other cases, a message might be accepted by the SMTP accept agent, passed through the SMTP routing agent to the account handler, and then delivered by the local delivery channel to a user on this particular Messaging Server host (see the next section for more information on the local delivery channel).
In a third case, a message might be accepted by one message channel but be delivered by another channel. In this case it is accepted according to one protocol and delivered according to another, so that the Messaging Server acts as a switch (or gateway) between the different mail protocols.
When a message-channel routing agent examines a message envelope, it might determine that the message shouldn't be forwarded to the deliver agent. This happens when the address indicates either that the message should be delivered locally or that it should be delivered according to another protocol. If this occurs, the message is forwarded to the account handler, which determines what to do with the message.
When a message is transferred to another message channel, the account handler forwards it to the appropriate message channel routing agent. For example, a message might go from the SMTP routing agent to the account handler and finally to the routing agent of the X.400 channel.
When a message is transferred to the account handler because it is addressed to a local recipient, the account handler forwards the message to the local delivery channel. Figure A.4 shows the logical paths between message channels and the network.
A detailed look at the role of the message channel.
The local delivery channel consists of those Messaging Server modules that transfer messages to mail clients: POP3 or IMAP4 local delivery, Unix maildrop delivery, and program delivery. Only users with Messaging Server accounts can receive messages through the local delivery channel.
When the Messaging Server accepts a message (with one of the message channels) that it recognizes as being addressed to a local recipient (that is, to someone with an email account), the message is routed to the local delivery channel. The Messaging Server recognizes an address when it compares the address of an incoming message against the entries in the directory database.
The path (POP3, IMAP4, Unix, or program delivery) that a message takes to reach a recipient is determined by the choices you made when completing the New User form for a particular user. If users want to change how they receive their mail, they can use the Information form to do so.
Figure A.5 shows the delivery options in the local delivery channel, which are described in the following subsections.
The local delivery channel--POP3/IMAP4, Unix, and program delivery.
The POP3 and IMAP4 delivery modules take incoming mail for users and file it in the user's mailbox directory, as shown in Figure A.6. The mail is retrieved later by a mail client running on a remote computer.
Note
Users must choose either IMAP4 or POP3; they cannot access their mail from both.
A user who would like an email account need only have a means of establishing temporary contact with the host machine (the computer on which the Messaging Server is running). Thus any computer that can connect to the host machine (generally through a network such as an Ethernet or the Internet) can be part of the email system that the Messaging Server coordinates.
Unix
Unix delivery is available on Unix machines. As Figure A.7 shows, Unix delivery adds new messages to the user's maildrop file. The mail client then looks to this file for any new messages. Unix delivery can be used only by users with a system account on the Messaging Server host (in addition to the Messaging Server account).
Message appended to user's maildrop file.
As Figure A.8 shows, program delivery lets users have their messages delivered to a program.
Message delivered to a program activated at the same time.
Users who receive a high volume of messages sometimes opt to have a program sort their messages as soon as they arrive. Mail-sorting programs can warn users of urgent messages or place different kinds of messages in different folders. For example, messages from mailing lists can go in one folder, professional-related mail in another, and personal mail in yet a third. As with Unix delivery, program delivery requires the user to also have a system account. Some mail clients sort through normal mailbox or Unix delivery and don't require program delivery. Program delivery must be set up by the server administrator or system administrator.
Handlers determines what to do with messages and supervise the transfer of email between modules. Under normal circumstances, the account handler routes messages between the channels and modules. Unusual messages that the account handler cannot process are forwarded to the error handler.
Figure A.9 hints at the central role the account handler plays in coordinating message transfer between message channels. The account handler makes its decisions based on information located in the databases maintained by the Messaging Server managers. It also shuttles messages to and from the AutoReply utility.
The local delivery channel's role detailed in the MTA.
Whenever the Messaging Server receives a message it can't process, it gives the message to the error handler. In some cases these messages are returned to the sender. Alternatively, the Messaging Server can be configured to hold these messages until the server administrator decides what to do with them.
If the error handler receives a message that the Messaging Server can't handle, it sends the server administrator an email explaining what happened. The server administrator has to decide how to handle the error. The error handler provides the server administrator with a form offering options for resolving the error; when this form is completed and submitted, the error is resolved. Alternatively, the server administrator is simply advised that the error occurred, and no action is required.
The AutoReply utility lets you instruct the Messaging Server to automatically reply to messages an account receives.
When the account handler processes an incoming message for a local account, it has to determine whether the account invokes the AutoReply feature. If it does, the AutoReply module takes the AutoReply message (which is specific for that account), formats an automated outbound message in response to the message received, and passes this reply back to the MTA for delivery.
Incoming messages are routed from the message channel to the account handler. The account handler then consults the account database and can forward a message either to a message channel (to deliver to another address at another host) or to the local delivery channel (for delivery to a user).
Similarly, the account handler can forward a message to the AutoReply handler module. Because messages are forwarded to the account handler in much the same way as they are forwarded to the message and delivery channels, the account handler configuration fields are considered to be a specialized form of delivery.
The directory database contains the user's account information (see Figure A.1) and can be either a local database installed on the same system as the Messaging Server or a dedicated Lightweight Directory Access Protocol (LDAP) directory server, such as Netscape Directory Server, running either locally on the same system or on a remote system.
The directory database holds all the user account information and can therefore be quite large. All modules refer to the directory database when they need account information to process a message or otherwise carry out a task. Because all user information is in this database, a single configuration change updates all modules at once.
The finger service is the most common directory service on the Internet and provides a means to obtain basic information about someone by using their email address.
The finger server receives inquiries directly from the network according to the finger protocol. Referring to the appropriate information in the directory database, it responds directly to the query over the network. Although the finger server and the Messaging Server MTA both refer to the directory database, they otherwise work independently. This independence, coupled with the fact that the finger service can be automated, facilitates easy management and consistency of information and greatly reduces the server administrator's workload. It also provides the added security of using one coordinated set of services (to which access can be limited as desired) rather than a haphazard array of individual servers.
For maximum security, access to the finger service can be limited to specific domains or hosts (or eliminated completely) at the discretion of the server administrator.
For the latest technical information on Sun-Netscape Alliance products, go to: http://developer.iplanet.com
For more Internet development resources, try Netscape TechSearch.
