Dr.Web MailD can operate as both a proxy server for SMTP/LMTP protocol and as a service for checking emails in the Callback mode. In this mode, MTA, which receives an email message, transmits it to Dr.Web MailD for check via the SMTP/LMTP protocol. Having checked the message, Dr.Web MailD returns it to the same server, which transmitted the message, via the SMTP/LMTP protocol.
The scheme of the Callback mode implementation is shown in the picture below.
Picture 21. Integration between Dr.Web MailD and mail systems in the Callback mode
The set of running components and main settings are similar to those of the SMTP/LMTP proxy integration mode.
Special Settings of Callback Mode
The feature of the Callback mode settings is that Sender must return the email message to the same host which sent this message to Receiver (but to another port). For that purpose, add special Rules that modify the procedure of sending messages. The rules are specified in the [Rules] section of the main Dr.Web MailD configuration file. When specifying the Rules, use the SenderAddress parameter to set the address to which checked messages are returned.
Specify the Rules as follows:
<CONDITION> cont SenderAddress = inet:<pont-num>@CLIENT-IP
where <CONDITION> - condition when the Rule is executed (in the most trivial case, specifying true is sufficient), and <port-num> - number of the port where MTA is waiting for a message (for example, 10025). CLIENT-IP - special macro that is substituted with the address which Receiver stores as the address from which the message was received.
Note that all actions applied to messages by Receiver and plug-ins must be configured so as to avoid denial to receive messages for check (do not use the following actions: reject, discard, tempfail). Alternatively, you must adjust these MTA so that they can correctly handle the cases, when the callback filter rejects or discards the message.
Moreover, if Dr.Web MailD is configured to enable generation of DSN (for example, when the operation mode is asynchronous and the SkipDSNOnBlock parameter value is set to No)and notifications, the <CONDITION> part of the Rule must contain the validation condition that does not allow service messages to be sent to the address where MTA is waiting for the checked messages. For that purpose, specify validation conditions which contain the from (sender) parameter. All DSN are always sent with the empty From field and the From field of notifications contains the address specified in the FilterMail parameter value ([Notifier] section).
Example:
!(from:"" || from:"root@localhost") cont SenderAddress = inet:10025@CLIENT-IP
This Rule sends an outgoing message to the port 10025 on the sender's host only if the From field is empty or does not contain the root@localhost address.
The SenderAddress parameter, used in rules, overrides the Address parameter value (specified in the [Sender] section) dynamically. Thus, if the Rule is not executed, the message will be sent to the MTA specified in the Sender settings. It is recommended to specify an active MTA in the settings to rapidly receive messages notifying on problems that occurred upon email processing (in the picture above, this MTA is indicated with a dashed line).