Algorithm of mail processing
1.Receiver gets email messages from MTA and transmits them to the MailD core component which is responsible for message check.
2.MailD core performs MIME-parsing of the messages and transmits them to plug-ins. The components is also responsible for saving the messages to the storage.
Parameters for the processed message are selected in the following order:
a)search for Rules stored in the built-in database and associated with the recipient (the recipient is determined according to the RCPT TO specified by the sender).
b)search for Rules stored in the built-in database and associated with the user groups which the recipient belongs to. The search is performed in reverse order until the parameter value is found: from the last to the first group in the list.
c)search for the parameter value from Rules defined in the configuration file ([Rules] section).
Rules are searched according to the following procedure:
oAll Rules are checked in the order they are specified in the current group of Rules.
oFor each Rule, its CONDITION is checked. If the CONDITION is true, the parameter value is searched in the SETTINGS part of the Rule.
oIf the CONDITION is false, the Rule is rejected and the next Rule is checked.
oIf the CONDITION is true and is followed by the cont directive, the Rule is rejected and the next Rule is checked. If the CONDITION is true and is followed by the stop directive, the search stops regardless of whether the parameter value is found or not.
As the result of a rule check, the parameter value is determined as follows:
•When the searched parameter is found in one of the Rules which CONDITION is true, the value is taken from the SETTINGS part of this Rule (if more than one Rule are true, the result parameter value depends on its semantics. For details, see Rules of message processing).
•If no Rule is specified, no Rule is true or no Rule with true CONDITION contains value for the required parameter, its value is taken from the corresponding section of the configuration file.
•If the configuration file does not contain value for the required parameter, its default value is used.
|
Note that if an email message has several recipients, truth of the rule is checked for each of them. For details, see Rules of message processing. |
3.Plug-ins can process email messages in the synchronous mode 'before-queue' (if the corresponding plug-ins are specified) and in the asynchronous mode 'after-queue' after saving messages to the storage (if the corresponding plug-ins are specified).
4.Results of email message check are transmitted to Receiver (if the processing results are not timed out).
5.If an email message was regarded as malicious or suspicious, it can be rejected, deleted or moved to Quarantine. If the message was rejected, notifications to the sender and, if required, to the recipient are sent by the Notifier component.
6.Sender dispatches all outgoing email messages to external mail servers or mail systems. It can send checked email messages as well as notifications and reports generated by Dr.Web MailD modules.
Dr.Web MailD uses two modes of message processing:
1.Synchronous mode ("before-queue"): message, received from the sender with the Receiver component, is processed by plug-ins "on the fly", without sending the message to the MailBase storage. In this mode, messages are processed by the plug-ins specified in the BeforeQueue list. The Receiver component does not send a response to the sender until processing ends or time-out is expired. If the message is regarded as malicious or suspicious, the sender gets the error code in response from the Receiver.
2.Asynchronous mode ("after-queue"): Message, received from the sender by the Receiver component is saved to the MailBase storage before the message processing starts. Then Receiver responds to the sender with notification that the message was correctly accepted. After that, the message is processed by plug-ins specified in the AfterQueue list. If the message is regarded as malicious or suspicious, the sender receives DSN with the report on the check results.
If some plug-ins are specified in the BeforeQueue list, and others - in the AfterQueue list, messages are processed in the synchronous mode and then in the asynchronous mode.
Note that if Dr.Web HeadersFilter and Dr.Web Modifier plug-ins are used (that is, if local rules of message processing or Rules that override their parameter values are specified), it is recommended to assign the plug-ins to the AfterQueueFilters queue if Dr.Web MailD operates as the SMTP/LMTP proxy. If Dr.Web MailD is integrated with any MTA, assign all plug-ins to the BeforeQueueFilters queue, but increase the IPC timeout value (IPCTimeout parameter from the [General] section in the configuration file). If these plug-ins are not used for message processing, it is recommended to remove them from all of the queues in the [Filters] section.
In both modes, if a message is not rejected (i.e., if discard, reject or tempfail actions were not applied to it), it is transmitted to the Sender component for delivery to the recipient. When transmitted in the synchronous mode, the message is also synchronously sent, that is, Receiver waits either for sending results from the Sender component or time-out occurrence. Time-out is used to ensure the correct interaction with external MTAs.
|
Please note that best modes for Dr.Web MailD operation depend on: •type and intensity of processed mail traffic •MTA integrated with Dr.Web MailD •method of interaction with the integrated MTA. Thus, before you change the default settings, please, read the description of integration with the selected MTA in the corresponding part of this Manual. |
Features of interaction between Receiver, MailD core and Sender in different modes
1.Time limit of Receiver and MailD core interaction is restricted to the value of the IPCTimeout parameter (defined in the [General] section of the configuration file). When operating in the synchronous mode, this parameter also restricts time limit for interaction between the MailD core and Sender components. The drweb-milter module uses the maximum value out of those set for the IPCTimeout and ProcessingTimeout parameters in [Milter] section.
2.When operating in the asynchronous mode, the received email message is saved to the internal queue of Dr.Web MailD. After that, Receiver immediately responses with the 250 SMTP code indicating that the email message is queued. Dr.Web MailD transmits the message to Sender which dispatches it further. In case of channel latency or if the component cannot connect to the target mail server, Sender delays dispatching of the message.
In this mode, time limit, restricted by the IPCTimeout parameter value, must be commensurate with the average time of message processing by all of the plug-ins.
3.When operating in the synchronous mode, Receiver does not respond to the sender until the email message is processed by all of the plug-ins and dispatched further by Sender. If the time exceeds the value ofIPCTimeout – 1 second (drweb-milter uses the greater value out of the IPCTimeout and ProcessingTimeout parameters) and Sender did not dispatch the message, the component skips all attempts to connect to the target MTA (if more than one connection attempt is specified for Sender in the Address or Router parameters in the [Sender] section). After that, Sender delays dispatching of the message. In this case, Receiver sends the SMTP response 250 Maild Error that indicates queuing of the email message that is to be sent as soon as problems with MTA connection are fixed. The "Maild Error" message indicates that the situation is abnormal for the synchronous mode (it is supposed to process mail traffic and transfer it to the target MTA rapidly). Also in this case errors of the "ERROR Broken pipe" type may be logged. These errors indicate that Sender was trying to send to MailD core a report through the connection closed upon the time-out.
1.Synchronous mode is not supposed for intense workload. It is recommended to select this mode only when Dr.Web MailD operates as a local mail filter. Do not select this mode if Dr.Web MailD operates as a high load SMTP gateway.
2.If most part of mail traffic through Dr.Web MailD consists of messages with large attachments (or with large number of attachments), as well as if delays in the channel or problems with the target MTA are possible, it is recommended to select the asynchronous mode. Also, it is not recommended to assign plug-ins to the before-queue if those plug-ins can process a message during a long time period.
3.When the synchronous mode is selected, it is strongly recommended not to decrease the IPCTimeout default value. If it is necessary to decrease the value, ensure that it is commensurate with the time required for processing by all of the plug-ins (IPCTimeout value must be greater). If the time-out occurs during processing of a message, it can be lost and not delivered to the recipient. In this mode, it is also assumed that no delays occur when Sender dispatches messages to the target MTA (it must be available and correctly configured).
Features of operation with MTA via Milter protocol:
1.If connection between Dr.Web MailD and MTA is established via the Milter protocol (the drweb-milter module is used as Receiver), returning of a checked message back to the MTA queue is configured by the CanChangeBody parameter value (specified in the [Milter] section of the configuration file).
2.If some plug-ins are assigned to the BeforeQueue (that is, the synchronous mode is selected), the parameter CanChangeBody = Yes, and significant delays occur while message processing (for example, one of the plug-ins does not finish message processing during the period specified by ProcessingTimeout), then MTA receives SMTP response code specified in the ProcessingError parameter (all mentioned parameters are specified in the [Milter] section of the configuration file).
3.When the synchronous mode is selected, the parameter CanChangeBody = No and a component (MailD core or Sender) stops responding while processing a message, MTA receives SMTP 451 code in response.
4.If some plug-ins are assigned to AfterQueue (i.e., the asynchronous mode is selected), the parameter CanChangeBody = Yes and significant delays occur when a message is processed (for example, one of the plug-ins does not finish message processing during the period specified by ProcessingTimeout), then MTA receives SMTP 250 queued code in response, but the message is still processed and sent via the Sender module (drweb-sender plug-in). Thus, if the parameter CanChangeBody = Yes, the asynchronous mode is not recommended as it provides neither speed gain (additional time for saving service files to the storage is required), nor reliability gain.
5.When operating in the asynchronous mode, CanChangeBody = No, and a component (MailD core or Sender) is not responding during message processing, the message is lost and MTA receives SMTP 250 queued in response. Thus, this setting combination is strongly not recommended!
6.Thus, it is recommended not to select the asynchronous mode (i.e., assigning plug-ins to AfterQueue) when connecting to MTA via the Milter protocol, as this mode does not provide any gain in message processing.
Moreover, it is recommended to optimize operation and system resources usage if the following problems occur: delays in message processing, queues when receiving or sending messages, not responding errors, shortage of system resources.