CommuniGate Pro
Version 5.2
E-mail
 
 
Overview

E-Mail Transfer

One of the main functions of the CommuniGate Pro Server is E-mail Message transfer. Acting as an MTA (Mail Transfer Agent), the Server accepts messages from various sources (modules, internal 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.

E-mail Sources and Destinations

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:
Transfer Scheme

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 an internal component stores the message envelope and the message itself in such a file and then submits it to the Enqueuer component 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 of the temporary file.

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

When the Server restarts, the Enqueuer component finds all files with the .msg extension stored in the Queue directory and resubmits them for processing.

Open the General pages in the Settings realm of the CommuniGate Pro WebAdmin Interface, and find the Temp File Manager panel panel on the Others page:

Temp File Manager
Log Level:
Recycle Temp Files:
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.

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

Recycle Temp Files
Enable this option to improve performance of your system under heavy load: discarded temporary file are not deleted, and they are reused.

Queue Limits and Foldering

If a Server is heavily loaded, it can contain thousands of message files in its Queue directory. Many operating and file systems cannot efficiently process large directories. You may want to split the Queue directory into several subdirectories, each containing a portion of Temporary and Queue files.

You may want to limit the total number of messages in the CommuniGate Pro Queue. When this number is reached, the modules reject attempts to submit new messages.

Use the WebAdmin Interface to specify the Queue processing options. Open the Mail pages in the Settings realm, then open the Queue page:

Message Queue
Log Level:   
Queue Size Limit: Queue Foldering:
Queue Limit
If you specify a limit with this option, the CommuniGate Pro modules (SMTP, PIPE, RPOP, MAPI, WebUser) will stop accepting new messages when the number of messages in the Queue exceeds the specified limit.
Queue Foldering
This setting specifies where the CommuniGate Pro Server will create new Temporary files, and, as a result, how the message files will be stored in the Queue Directory.
If you select the 0 (zero) value, no subdirectory will be created in the Queue directory, and all Temporary files will be created directly in the Queue directory.
If you select the 10 or 100 value, subdirectory with NN names (where NN is a 2-digit number from 00 to 99) will be created in the Queue directory. The newly created Temporary files will be created inside these subdirectories. The server will use 10 or 100 subdirectories, depending on this setting value.
If you select the Auto value, Queue subdirectories will be used when the total number of messages in the Queue exceeds 5000.

Routing

When a message is submitted for processing, the Enqueuer component examines its envelope information. Each recipient address is parsed and passed to the Router component. The Router component decides which module or 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 E-mail messages immediately, but enqueue them into the module-specific queues. The SMTP module creates and maintains a queue for each Internet domain, the Local Delivery module creates and maintains a queue for each local Account, etc.

The Enqueuer component can enqueue messages:

Most of the internal components enqueue messages asynchronously, as they cannot do anything useful if a message is rejected with the Enqueuer component. The components receiving messages directly from users or remote systems (SMTP, MAPI, WebMail, XIMSS) try to enqueue messages synchronously, so if a message is rejected with the Enqueuer component, the submitting agent (a user or a remote system) can get an error message.

Use the WebAdmin Interface to configure the Enqueuer component. Open the Queue page in the Settings realm.

Message Enqueuer
Log: Processors:
Hop Counter Limit:  Enqueue Asynchronously
Enqueuer Log
Use this 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.
Enqueue Asynchronously
Select this option to use the asynchronous Enqueuer mode for all components, including those directly receiving messages from users or remote systems.
Processors
Use this setting to specify the number of Enqueuer processors (threads).
If the Enqueue Asynchronously option is not selected, the Enqueuer threads are needed only to enqueue existing messages after the Server restart, and to enqueue messages generated with the internat Server component, so you may want to use 2-3 threads only.
If the Enqueue Asynchronously option is selected, then each message is processed with the Enqueuer thread. In this case, 5-10 Enqueuer threads should be enough even for a heavily loaded Server.

You should increase the number of Enqueuer processors if:

  • there are very many Server-Wide Rules;
  • Server-Wide Rules use the Execute action to start external programs;
  • one or more External Filter (anti-virus, content filtering, etc.) programs are enabled;
  • incoming load is very high, with many messages being submitted every second via the SMTP or other modules.

The numEnqueuerMessages SNMP element shows the number of messages that have been recieved, but not enqueued yet. If this number is growing, you need to increase the number of Enqueuer processors.
Hop Counter Limit
When a message is being received by any host or module, it gets an additional Received: header field. The Hop Counter is the number of Received: header fields in the message. If a message contains too many Received: header fields, it may indicate that a message is in some sort of mail loop. This parameter specifies the Limit for the Hop Counter - any message that has more Received: header fields than specified in this setting is rejected by the ENQUEUER - without any attempt to deliver it to the recipients specified in the message envelope.

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 module transfers a message or when it rejects a message because of a fatal error, it removes the message from the module queue. The module composes a delivery report and passes it to the Dequeuer 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 component 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.

Use the WebAdmin Interface to configure the Dequeuer component. Open the Queue page in the Settings realm.

Message Dequeuer
Log: Processors:
Reporting Delay: Send Return-Receipts to:
On Failure, Return:
Copy Failure Reports to:
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 your Server performs some kind of special message processing and has to generate a lot of DSN messages, should you use several 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.
Copy Failure Reports
When this option is enabled, all error messages generated with the CommuniGate Pro Dequeuer are sent to both the failed message return-path and to the specified E-mail address.
Send Return-Receipts to
Positive reports (delivery reports and relay reports) are generated only if the message sender has requested them. Use this setting to specify who can request these reports:
everybody reports are generated and sent whenever the message sender requests them.
clients reports are generated and sent if the sender has submitted the message from a Client IP Address or if the message has been submitted by an authenticated user.
authenticated reports are generated and sent if the message has been submitted by an authenticated user (via WebUser, XIMSS, SMTP AUTH, MAPI, etc.)
nobody positive reports are not generated.

Monitoring a Queue

Transfer modules (such as SMTP, Local Delivery, LIST, and PIPE) maintain one or several queues for messages to be delivered. Each module uses its own methods to build the queues (for example, the SMTP module usually builds a separate queue for each remote domain to deliver to, while the Local Delivery module builds a separate queue for each local Account), see the manual section describing the module for more details.

To open a module queue, click the queue name link on module Monitor page. The module ("host") queue page opens:

  2 of 2 selected

ModuleStatusLast Problem
SMTP Processing no response

Message In Queue Return Path Recipients Size Delayed Last Problem
44220010 5 min <system_admin@domain.dom> 2 634
44220003 15 min <user2@domain3.dom> 1 26K

The table header contains the information about the entire queue ("host"):
Module
The link to the Monitor page of the Transfer module this queue belongs to.
Status
Active - this queue is being processes by the module.
Ready - this queue can be processes by the module at any time.
Delayed till time - this queue will not be processes by the module until the time specified. The queue can be delayed because there was a queue-wide transfer operation error (an SMTP host did not respond, or a Local Account is over its quota, etc.)
Last Error
This field indicates the last queue-wide transfer operation error.

The table contains a record for each message in the queue. For each enqueued message, the following information fields are displayed:

Message
The message internal ID. You can use this link to open the Message Monitor page.
In Queue
The time the message has spent in this queue.
Return Path
The message envelope "Return-Path" address.
Recipients
The number of message addresses that should be delivered to the "host" this queue is created for. For example, a message directed to user1@company.dom and user2@company.dom addresses via SMTP will appear once in the company.dom SMTP queue, with the indicated number of addresses being 2.
Size
The message size.
Delayed and Last Error
If delivery failed for this particular message, the Transfer module could delay this message individually (rather than delaying the entire queue). In this case, this field will show the time when the module will try to deliver the message again, and the Last Error field will show the information about the cause of the transfer operation failure.

If you have the Can Release Queues access right, and the Queue has the Delayed status, the Host Queue Monitor page contains the Release Now button. Click this button to remove the delay interval set for this queue and to allow the module to process the queue immediately.

If you have the Can Reject Queues access right, and the Queue has the Delayed or Ready status, the Host Queue Monitor page contains the Reject Host Queue button. Click this button to reject the queue:

Suppress Failed Delivery Reports

The specified text is used to generate DSN messages (error reports) for all messages placed into this queue.

If the Suppress Failed Delivery Reports option is selected, no DSN message is generated when the queue messages are being rejected.


Monitoring a Message

To monitor the status of a message in the Server Queue, click the message link on the Module queue or other Monitor page. The Message Monitor page opens:

Return-Path:<CGatePro-report@mail.communigate.com>
Message-ID:<list-26325892@mail.communigate.com>
Envelope-ID:
Subject:Re: FormMail.pl configured for CGP
Size:37222 bytes (34018 in envelope)
Submitted:Mon, 30 Dec 2002 09:16:58 -0800 (12hours ago)

Recipient Module Queue Status Retry in
postmaster@domain1.domSMTPdomain1.domDelayed24min
john.smith@domain2.domSMTPdomain2.domDelayed57min

The first part of the page shows the message attributes: the envelope Return-Path, Message-ID, Envelope-ID (if present), message Subject, and the time the message was submitted to the Server Queue.

The second part of the page lists all active message recipient addresses (if a message address has been already processed, it is not shown). For each address the following information is displayed:

Recipient
Recipient address.
Module
The name of the module that will process this address. This is also a link to the module Monitor page.
Queue
The name of the module queue containg this address. This is also a link to the module queue Monitor page.
Status
Processing - the module is processing this address.
Ready - the module can start processing of this address at any time.
Suspended - the module has delayed processing of this message.
Delayed - the module has delayed processing of the entire queue containing this address.
Retry In
Time till the module resumes processing of this message or the queue containing this message.

If you have the Can Reject Queues access right, the Message Monitor page contains the Reject Message button. Click this button to reject all active message addresses.

Suppress Failed Delivery Reports

Only the addresses that are not being processed can be rejected.

The specified text is used to generate DSN messages (error reports) for all rejected recipient addresses.

If the Suppress Failed Delivery Reports option is selected, no DSN message is generated when the message addresses are being rejected.

If you have the Can View Queue Messages access right, the Message Monitor page contains the Message content (it is displayed using the Unnamed Stock Skin).

From: "User Name" <userName@server.dom>
Subject: Some subject here
Date: Fri, 07 Dec 2007 02:56:41 -0800
Message-Id: <web-12490003@server.dom>
X-Mailer: CommuniGate Pro WebUser v5.3.5
TEST - TEST TEST

--
This is a test letter with one attachment.

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