Using Internal Proxy

Internal proxy included in Dr.Web MailD allows to achieve several goals in management of computing resources:

1.Dr.Web for UNIX mail servers efficiency may improve greatly, when Receiver and Sender components are working separately from MailD core component (drweb-maild module), so that mail processing and mail checking operations are performed on different hosts.

2.Computing resources in a network can be managed flexibly, using load balancing scheme N:M, where N is the number of hosts processing mail traffic, and M is the number of hosts checking mail for viruses and spam.

Please note that drweb-maild module does not support cluster implementation and different module instances cannot share internal data (statistics, Quarantine, database settings, etc.).

As a result, each drweb-maild module of the M group will has its own statistics, Quarantine, and configuration.

Proxy consists of the following components: Proxy-client (drweb-proxy-client module) and Proxy-server (drweb-proxy-server module).

•Proxy client works on a host, where Receiver and Sender components are operating. It is started instead of MailD core and plays its role in interaction with other components.

•Proxy server works on a host, where the MailD core component is operating, and plays the role of Receiver and Sender components.

Both Proxy client and Proxy server components interact with each other, enabling transfer of original mail messages and their modifications to other components of Dr.Web for UNIX mail servers on different hosts for further processing.

Note that role of Sender and Receiver components can be played by different executable modules (for example, functions of Receiver can be performed not only by drweb-receiver, but also drweb-milter, drweb-cgp-receiver depending on the method of integration with MTA selected during Dr.Web MailD installation and adjustment).

Full list of the modules and their roles (Sender, Receiver) in terms of Dr.Web MailD is provided in the Used Modules section.

Dr.Web Notifier, Dr.Web Monitor and Dr.Web Agent components are working on each host.

As it appears from the scheme, both Proxy client and Proxy server can interact with an arbitrary number of complementary components residing on different hosts. This is implemented using a special balance system.

A certain weight is assigned to each socket address specified in a value of the ProxyServersAddresses or ProxyClientsAddresses parameters (from the [ProxyClient] and [ProxyServer] sections respectively). So, addresses are specified in the following format:

where ADDRESS has a basic address type, and WEIGHT is an optional numeric value from a range of 0 to 100, defining a weight of this address. This WEIGHT determines a relative work load on a certain host in the network. The greater the value is specified, the greater the load is on a certain server.

The ProxyServersAddresses parameter in the [ProxyClient] section on Server1, Server2 hosts specifies addresses of Server3, Server4, Server5 (see the scheme above), which are used by Proxy-server components to receive requests.

The ProxyClientsAddresses parameter in the [ProxyServer] section on Server3, Server4, Server5 hosts specifies addresses of Server1, Server2 (see the scheme above), which are used by Proxy-client components to receive requests.

In this case, 10.3.0.73 host will receive twice as much mail messages as 10.3.0.72 host does (5 and 10 messages out of 15 respectively).

If the WEIGHT is not specified, it is considered to be equal to 1 by default. If several addresses have the same WEGHT, they are considered equivalent and receive the same amount of requests.

If the WEIGHT is set to 0, such addresses are considered backup-addresses. Requests are sent to them only if no other available addresses with WEIGHTs equal to or greater than 1 are left.

1)Randomly selects an address according to weights (than more weight the more probability to selection).

3)If the message was sent successfully, the algorithm ends. Otherwise, one of the following is selected:

and goes to step 2. If there are no more not-tried addresses (with weight not less than 1), the algorithm goes to step 4.

4)Attempts to send the message to backup addresses (in accordance with the order they are specified). If no address from the backup list is accessible, an error is returned.

WEIGHT values should be selected and assigned according to the resources available on each server, that is, assign greater WEIGHT values to hosts with more resources.

When messages are passed for check to the drweb-maild module and processed by plug-ins from the BeforeQueue queue, all processed mail is returned to the client that sent it for processing. If messages are processed by plug-ins assigned to AfterQueue, the address of the client that receives already processed mail will be selected according to the weights of client addresses in ProxyClientsAddresses. Duplicated messages (see the Rules description) and messages generated by drweb-maild (reports and notifications) will be also sent to the client selected from the ProxyClientsAddresses list - regardless of the queue in which the plug-ins reside. For messages sent to the client selected from the ProxyClientsAddresses list, settings specified in Rules (if there are any) will be applied (for example, value of the SenderAddress parameter).

Note that when a proxy interacts with Qmail, Courier MTAs (and other MTA using Milter protocol), it is better not to assign plug-ins to the AfterQueue. Currently a proxy does not support callback connections to drweb-milter. So, if the response from drweb-maild is not returned immediately (for example, when the plug-in is in the AfterQueueFilters and operation mode is asynchronous), drweb-milter finishes SMTP session only after expiration of the ProcessingTimeout period.

Optimal connection scheme for M=N=1 is described below (the scheme is preferable to avoid various errors in configuration):

1.Set up and adjust Dr.Web for UNIX mail servers on Server1 (that is, on the host that is used for mail traffic processing and where Proxy client component resides). Check validity of the configuration with the following command:

/etc/init.d/drweb-monitor check (for Linux and Solaris)
/usr/local/etc/rc.d/00.drweb-monitor.sh check (for FreeBSD)

2.Run Dr.Web for UNIX mail servers on Server1 and check if the mail is processed correctly.

3.Setup Dr.Web for UNIX mail servers on Server2 (that is, on the host used for mail message check and where Proxy-server component resides). During setup you may skip configuration of Receiver and Sender components - they are not necessary on this host.

5.Disable startup of Receiver and Sender components by commenting out the corresponding lines in the mmc file (from the %etc_dir/monitor directory) on the Server2 and enable startup of Proxy-server (drweb-proxy-server).

6.Specify the IP address of Server1 as a value of the ProxyClientsAddresses parameter from the [ProxyServer] section in the Dr.Web MailD configuration file on the Server2. This address must be the same that is specified as a value of the Address parameter from the [ProxyClient]section. Mail will be sent to it.

7.Check validity of configuration on the Server2 host with the following command:

/etc/init.d/drweb-monitor check (for Linux and Solaris)
/usr/local/etc/rc.d/00.drweb-monitor.sh check (for FreeBSD)

8.Specify IP address of the Server2 as a value of the ProxyServersAddresses parameter from the [ProxyClient] section in the Dr.Web MailD configuration file on the Server1. This address must be the same that is specified as a value of the Address parameter from the [ProxyServer] section. Requests for message checks will be sent to in.

9.Disable startup of MailD core (drweb-maild) component by commenting out the corresponding line in the mmc file from the %etc_dir/monitor directory on the Server1 and enable startup of Proxy client (drweb-proxy-client).

Note that at attempt to start simultaneously on the same host Proxy-client and MailD core components Dr.Web Monitor will finish its operation, and no components will be initialized. Information about this error will be logged.

10.Check validity of configuration on the Server1 host with the following command:

/etc/init.d/drweb-monitor check (for Linux and Solaris)
/usr/local/etc/rc.d/00.drweb-monitor.sh check (for FreeBSD)

If the configuration is correct, you can restart Dr.Web MailD - and all the mail will be transferred for check to the Server2.

11.You may also disable Dr.Web Daemon and Dr.Web Updater on the Server1 (if there are no more Dr.Web products on the system). These modules are no longer necessary.

You can also apply this algorithm when M and/or N are greater than 1: just connect additional hosts as it is described above and edit values of the corresponding parameters (ProxyClientsAddresses from the [ProxyServer] section and ProxyServersAddresses from the [ProxyClient] section) in the configuration files on those hosts. Specify WEIGHT values for addresses with respect to their resources.

Note the following operation aspect of the proxy server if Proxy client is functioning on several hosts and Receiver on one of these hosts has the ReturnReject = No setting.

In this case, if the proxy server rejects a message received from this client, the server generates DSN and sends it to a randomly selected proxy client. If it serves a subnetwork different to the one from where the message was transmitted, the DSN might be not delivered to the message sender due to the address being unavailable from this subnetwork.

Thus, it is recommended to avoid setting the ReturnReject parameter value to No when configuring proxying if the server has several clients serving different subnetworks and message non-delivery might occur.