Version 5.1
Clusters |
|---|
| |||||||
|
|
Version 5.1 |
|||||||||||||||||||||||||||||
|
|
Received messages are enqueued. If a message is directed to an external address, it can be relayed by the same Frontend:
A message directed to a local recipient can be enqueued on a "wrong" Server, i.e. on a Server that cannot open the target Account and deliver the message to that Account.
This situation can happen when a message is enqueued on a Frontend Server (Frontend Servers cannot directly open any Account in Shared Domains), or a message is enqueued on a Backend Server that either does not host the target Account (in a Static Cluster), or it cannot open it, because the Account is opened by some other Backend Server (in a Dynamic Cluster).
To solve the problem, the Local Delivery module uses a Delivery channel connection to the proper Backend Server and passes the message there. The receiving Backend immediately opens the target Account, applies its Account-Level Rule and stores the transferred message. This Backend does not enqueue the message.
If there is a temporary problem or a delivery failure, the receiving Backend Server reports the error back, and the message is either delayed in Queue or it is removed from the Queue (with error report messages generated).
WebUser Interface sessions, Rules, MAPI sessions, and other modules and components can generated E-mail messages on Backend Servers.
Backend Server often do not have direct access to the Internet, in this case they cannot deliver generated messages to remote systems. To solve this problem, the Backend Servers can be configured to relay all messages to the Frontend Servers first, using the * symbol as the SMTP Forwarding Server name.
In this case the message is submitted to the Backend Queue, where it is processed using the Server-wide and Cluster-wide Rules, and if it is not directed to a local recipient, it is directed to the SMTP module which sends it to one of the Frontend Servers:
In this setup, each messages generated on a Backend Server is processed twice. If Cluster Rules invoke content management Plugins, double-processing can create a substantial overhead. To avoid this overhead, the Remote Queue processing method can be used.
Most of the Queue processing takes place on the Frontend Servers. Frontend Servers accept incoming SMTP messages and either relay them to remote locations or deliver them to local Accounts via Backends, using the special inter-cluster protocol, without placing messages into the Backend Server Queue.
A certain amount of messages can be generated directly on the Backend Servers.
They include messages:You may also want to process Message Queues on some Frontends only.
To specify Queue processing options, open the Settings WebAdmin realm and select the Cluster link on the General page. Find the Queue Processing panel:
If the Locally option is selected, messages will be processed in the "regular" way: when a message is composed in a temporary file, it is submitted into the Queue maintained by this Server.
If the Locally for Others option is selected, messages will be processed in the "regular" way, too. In addition, this Server will accept messages generated on other Cluster members and submit them into its own Queue - for processing and delivery. The Dynamic Cluster Controller collects and distributes information about all running Cluster members that have this option selected.
If the Remotely option is selected, this Cluster member will try to connect to any other Cluster member that has the "Locally for Others" option selected. The temporary file content (the message envelope and the message itself) is sent to that other Cluster member via a special protocol that uses the SMTP port. If the remote message submission does not work (the Server failed to connect to the Cluster member(s) or the message file transfer fails), the message is submitted to the Server own Queue to ensure that no message is lost:
