This module provides procedures which control the operation of the server. A number of constants are defined here which may be changed to affect its behavior (e.g. cmdTimeLimit, defaultInhibitTime). All of the command interpreter is in this module, including interactive write-arounds for public procedures, the syntax help table, and the actual CLI.

Descriptors contain the information about mail items (name of message file, reverse-path, recipients, timeout, etc.). They are kept internally on Queues, and are partially backed up on the filestore. The intention is that, at start of day, the server will initialize its internal queues by requesting the existing descriptors from the filestore (those left over from before the crash or shutdown). The server will create new descriptors as mail items come in, move the descriptors through the queue system, and destroy the descriptors once the mail has been delivered.

There is one file for each mail item. The message body is stored at the beginning of the file so that the item information which follows may be updated without having to rewrite the body. The body and item info are stored directly upon reception from Grapevine or the Arpanet: no processing is done on the fly so that the other machines will not be held up needlessly. The body should only be read when the item is sent or (in the case of a Grapevine item) during processing to extract necessary "item" fields. The item info will not be read unless the server crashes or the user specifically instructs. The item info is updated (e.g. recipients for a target host deleted) as the item moves through the system so that items will not be multiply sent.

This module implements the receiver side of the (interactive) SMTP protocol. It is basically a command interpreter providing protocol functions, on-line help, recipient verification, distribution list expansion, and the ability to mail and send [to users' terminals] messages (not all of which are implemented). It calls Grapevine Registration Server functions directly for verification and expansion, and registers message items with the queue cluster. The Arpa byte stream protocol used is TCP. Though no processing of the incoming item is done on the fly, the syntax of command parameters is checked. The public procs provide the ability to start and stop the Arpanet reception demon.

This module implements the sender side of the (interactive) SMTP protocol. It is primarily used to send items destined for the Arpanet which are waiting in queues. These messages may have come from the Xerox Internet, or they may be messages being relayed from one Arpanet host to another. The public procs provide the ability to open a connection to an Arpa host, send items, and close the connection. All outstanding messages to a host should be sent down the same connection as opening one is expensive. The failure error provides information to determine what should be done with the mail item(s) destined for the host, how backoff should be handled, and what should be reported to the log.

The server must provide that part of the Grapevine Mailserver interface which accepts mail items from other Grapevine Mailservers. Rather than process the item on the fly, it is stored verbatim to keep from tying up the Grapevine server, and is subsequently processed. Because Grapevine mail is more complex than SMTP mail, some information is lost when going from Grapevine to SMTP. However, because this mail may be forwarded to another Grapevine server or returned to the sender, this additional information is not thrown away until delivery. The public procs provide the ability to start and stop the Grapevine reception demons.

The server uses public Grapevine interfaces to forward mail items to Grapevine. There is not quite the same concept of a connection as with the Arpanet because such connections are relatively cheap. The open sets up data structures which disappear (via garbage collection) when dropped on the floor. The interface was designed to be similar to the SMTP one. The information reported in the failure error is the same as for SMTPSend.

The queue system moves mail items through the server, calling on procs provided by other modules to do the processing and sending. It is called by the reception demons to queue incoming items. When mail items come into the server from Grapevine or the Arpanet, they are placed on the ForProcessingQueue. The mail items have been stored straight off the net; the recipients must be sorted by hosts and their syntax converted according to their destination (SMTP syntax for Arpanet destination; GV syntax for Xerox destination). The reverse path must also have its syntax converted (to both SMTP and GV since the item may have destination on both the Arpanet and Internet). The ForProcessingDemon does this conversion and queues the resulting item on the appropriate Arpa host and/or the Grapevine queue for delivery.

There is one queue for Grapevine items, and one queue for each Arpa host with outstanding mail. (There is also a queue containing all of the Arpa queues.) All of these queues can be inhibited, either automatically (when connections in certain ways) or by the user. There is one queue demon for the Grapevine queue and one for the Arpanet queues. Each demon waits until the queue is uninhibited and contains an uninhibited item (done with CVs) and then attempts to process that item. Failure of such an attempt may result in the item being returned to the user or placed on the BadItemQueue. Grapevine managers are notified if their intervention is needed or if something suspicious occurs.

There is also an ExpiryDemon which waits for mail items to expire (items currently have a 2 day expiration) and returns them to the senders.

The queue system provides extensive procs to the user to examine and manipulate the queues. These are available through the command interpreter (SMTPControl). Because this is a server, care is taken to do what is asked, though it may not be sensible if the world were in a consistent state. (The user wouldn't be manipulating the system if nothing were wrong.) However, care is taken not to let the user throw away undelivered items without some trouble.

This module provides monitored queues which may be inhibited, on which the user may wait for a processable element, and on which standard queue operations may be performed. Basic Cedar locks are used to implement queue locks for which the client may specify a timeout when waiting. This is primarily used by procs allowing the user to manipulate the queue system so his CLI will not freeze while waiting on a queue lock (e.g. to print an item). Because Cedar does not provide parameterized types, REF ANYs are used for values and all type checking must be done at run time (though all the information is available at compile time).

This module basically provides parsing and manipulation procs for both SMTP and GV syntax. Part of the syntactic analysis is done in the respective Rcvr and Send modules, but that which is common to several modules is separated out here. This includes procs to interpret the Grapevine "items" constituting the message body, the SMTP command argument syntax, and the procs which convert recipient and reverse path denotations between GV and SMTP (for Processing).

This module provides miscellaneous support functions including logging, notification of undeliverable mail, and the current time.