|
Version 6.3 |
|
| ||||||||||||||||||||||
SMTP Relaying
Incoming SMTP connections are received with a TCP Load Balancer and sent to Cluster Frontends.
A Frontend Server receives a message in the same way as it does in the single-server mode, but it may
contact the Backend Servers (via CLI) when it needs to:
Received messages are enqueued. If a message is directed to an external address, it can be relayed by the same Frontend: Local DeliveryA 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). Backend QueuesWebUser Interface, XIMSS, MAPI sessions, Rules, 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 these problems and the inevitable overhead, the Remote Queue Processing method should be used. Remote Queue ProcessingMost of the Queue processing takes place on the Frontend Servers. Frontend Servers accept incoming SMTP E-mail 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 E-mail 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:
|