Message Transfer

Intro
Installation
SysAdmin
Objects
Transfer
Router 
Rules 
SMTP 
UUCP 
Local 
RPOP 
LIST 
PIPE 
Access
Directory
Data Files
Clusters
WebMail
Miscellaneous
Licensing
HowTo

One of the main functions of the CommuniGate Pro server is message transfer. Acting as an MTA (Message Transfer Agent), the server accepts messages from various sources (modules, internal kernel components, etc), and delivers (transfers) them to remote or local destinations using the same or different modules.

While all submitted messages are stored as individual files in the Queue directory inside the CommuniGate Pro "base directory", each message can be enqueued into several different queues (if it has several recipients). Each communication module can maintain one or several logical queues. For example, the SMTP module maintains one queue for each Internet domain.

The CommuniGate Pro Server has the following set of message sources:

The CommuniGate Pro Server transfers messages to the following destinations:

The following diagram illustrates the message flow inside the CommuniGate Pro server.


Submitting Messages

All messages are created as temporary files. They are stored in the Queue directory as files with the .tmp extension. A module or a kernel component stores message envelope and the message itself in such a file and then submits it to the kernel for processing.

The message envelope is a set of text lines. Each line specifies either the message return-path, or one message recipient address, or message delivery options.

If a module fails to compose a message (for example, an SMTP connection breaks during message transfer), the module discards the temporary file, and the kernel deletes it.

When a message is completely composed and submitted to the kernel, the file extensions is changed to .msg and the message is scheduled for processing.

When a systems restarts, a kernel modules checks all files with the .msg extension stored in the Queue directory. All such files are resubmitted for processing.

You can use a Web browser to configure the Temporary Files manager. Open the Obscure page in the Settings section.

Temp File Options
TempFiler Log: Recycle Temp Files:

TempFiler Log
This setting specifies what kind of information the Temporary Files manager should put in the Server Log. Usually you should use the Failures (file system error reports) level. But when you experience a problem with some module submitting messages, you may want to set this setting to Low-Level or All Info: in this case file i/o operations will be recorded in the System Log as well. When the problem is solved, set the TempFiler Log setting to its regular value, otherwise your System Log files will grow in size very quickly.

Recycle Temp Files
Enable this option to imporve performance of your system under heavy load.

The Temporary Files manager Log records are marked with the TEMPFILE tag.


Routing

When a message is submitted for processing, a kernel component examines its envelope information. Each recipient address is parsed and passed to the Router component. The Router component decides which module or kernel component should process each recipient address.


Enqueueing

When all recipient addresses are parsed and routed, the Enqueuer component applies the Server-Wide Rules to the message. Then it passes the message to the modules specified with the Router component.

Communication modules do not process messages immediately, but enqueue them into the module-specific queues. The SMTP module creates and maintains a queue for each Internet domain, the UUCP module maintains one queue for each "uucp neighbor" system, the Local Delivery module creates and maintains a queue for each local account, etc.

You can use a Web browser to configure the Enqueuer component. Open the Obscure page in the Settings section.

Message Queue
Message Log: Enqueuer Log:

Use the Enqueuer Log setting to specify what kind of information the Enqueuer component should put in the Server Log. Usually you should use the Failures (file system error reports) level.

The Enqueuer component Log records are marked with the ENQUEUER tag. The records created when applying the Server-Wide Rules are marked with the ENQUEUERRULES tag


Delays and Suspensions

When a communication module fails to transfer a message, it uses the kernel queue management component to delay processing.

Dequeueing

When a communication modules transfers a message or when it rejects a message because of a fatal error, it removes a message from the module queue. The modules composes a delivery report and passes it to the Dequeuer kernel component.

The Dequeuer component processes delivery information. If requested, it composes Delivery Status Notification (DSN) messages and submits them back to the system for delivery to the original message sender. When a message has several recipients, the Dequeuer module may choose to delay DSN generation, so each DSN message can contain reports about several recipients.

When all message recipients are processed and the message is dequeued from all queues, the Dequeuer component removes the message file from the Queue directory.

You can use a Web browser to configure the Dequeuer component. Open the Obscure page in the Settings section.

Message Dequeuer
Log: Reporting Delay:
Processors: On Failure, Return:
Dequeuer Log
Use this setting to specify what kind of information the Dequeuer component should put in the Server Log. Usually you should use the Major & Failures (delivery reports) level.
The Dequeuer component Log records are marked with the DEQUEUER tag.

Processors
Use this setting to specify the number of Dequeuer processors (threads). Usually one Dequeuer thread is enough even for a heavy-loaded server. Only if you server performs some kind of special message processing and has to generate a lot of DSN messages, you should use server Dequeuer threads.

Reporting Delay
Use this setting to specify the maximum delay between the moment when a message was transferred or failed and the moment when a delivery report is generated. The more the delay, the more reports can be placed in one DSN message. A DSN message is generated immediately after the last message recipient is processed.

On Failure, Return
Use this setting to specify what portion of a failed message should be included into the DSN (error report) message.
  • If the sender has not specified this option explicitly, and the headers by default option is selected, only the failed message headers will be returned;
  • If the sender has not specified this option explicitly, and the body by default option is selected, the entire failed message will be returned;
  • If the always headers option is selected, only the message headers are included into the DSN message, even if the message sender has specified that the entire message should be returned on failure.
  • If the always body option is selected, the entire message is included into the DSN message, even if the message sender has specified that only the message headers should be returned on failure.

CommuniGate® Pro Guide. Copyright © 1998-2000, Stalker Software, Inc.