When a connection from an SMTP client arrives, the configuration is searched for a matching session-acl. If the ACL says that the connection should be denied or there is no matching ACL, the proxy closes regularly the session.

According to the session-acl settings, the client identity is verified (see the Client verification section above). If the verification fails, the proxy closes regularly the session.

Proxy reads the HELO/EHLO command, checks it according to the RFC 2821, tries to resolve its argument (A DNS RR) in case of domain name and stores all results for further processing. The command is always responded by 250 OK reply.

Proxy reads the MAIL command, checks it according to the RFC 2821, tries to resolve domain part of sender's email address, checks client identity according to the SPF (if configured, see above the section called “Client verification”) and stores all results for further processing. The command is always responded by 250 OK reply.

The domain name resolution proceeds as follows: The proxy tries to find MX DNS RRs for the domain name. If it succeedes, each mail exchanger is resolved again until at least one A DNS RR is found. If no MX DNS RR exists, the proxy tries to get an A DNS RR for the domain name. If no A DNS RR is found by either way, the sender name is treated as unknown for further processing (in delivery-acl.sender items). The whole resolution process has a single total timeout equal to the conn-timeout value in the sense of resolver(5) settings.

For every mail, a unique internal message identification is generated. This MSGID is then used for identifying log messages, mail documents etc.

Proxy repeatedly reads RCPT commands, checks them according to the RFC 2821, tries to resolve domain part of recipient's email address (in the same manner as the sender's one) and then finds the appropriate delivery-acl taking paricular recipient and also HELO/MAIL check results into account. According to the delivery-acl settings, proxy responds to the command.

There are several ways how to deny service for particular recipient:

If the recipient is accepted, the default behavior is to deliver the mail to him/her via proper smtp-forwarder. The list of forwarders is searched for the first one who serves domain of particular recipient. The item deliver can be used to choose another forwarder (via elem) or even another recipient (to elem).

If the response code was 250 (accept or deny+discard used), a copy of this mail can be sent to another person. This person's email address is given as a parameter of the copy-to item. This address is added to the set of recipients for further processing (searching for proper ACLs of phase 3) with the same delivery-acl as the originator has (no new search for it is done). The smtp-forwarder for the delivery will be determined by searching through forwarders' domains regardless of the deliver item of the original delivery-acl.

Under the same condition, the mail can be stored into the quarantine by the quarantine item. For easy controlling the mails in the quarantine, use the quarc.sh(1) tool.

When the DATA command comes, proxy checkes the number of accepted recipients and, if not zero, responds by 354 response code and starts receiving the mail. Otherwise, the proxy responds by 554 response code and waits for the next MAIL command.

The mail is read into the mail-pool directory under a name derived from the MSGID. It is stored as-is, without any changes, checking only the RFC 2821 rules (line length, leading dot dubbing etc.).

By default, the proxy checks every line, whether its normalized length (line length not counting the leading dot duplicated for transparency and the CR+LF line separators) fits the 998 chars limitation. This check can be changed or switched off by the session-acl.mail-line-len configuration item. Even in this case, mail line length (unnormalized) cannot be greater than the client-conn.recv-bufsize and the server-conn.send-bufsize value.

The mail size-limit is also checked during mail reading. Every line is counted in its normalized length plus two bytes (for the standard CR+LF line separator). This normalized size is then used in “statistical” log messages (SMTS-815-I and SMTR-819-I), too.

The mail MIME structure is decoded according to the RFC 2822, 2045 and others. All MIME documents are stored into the mail-pool and several checks are done. For detail configuration description, see mod-mail-doc(5).

The smtp-proxy can check mail documents by an antivirus. Antivirus checking is defined by item use-antivirus which selects a global antivirus section. See antivirus(5) for details about configuration of virus checking.

The smtp-proxy can check the whole mail by an antispam. In the current version of Kernun firewall, SpamAssassin is supported. Antispam checking is defined by item use-antispam which selects a global antispam section. See mod-antispam(5) for details about configuration of spam checking.

The smtp-proxy can check particular MIME types of mail body documents according to the rules defined in configuration, see doctype-identification(7) for details.

The smtp-proxy checks correctness of the mail headers and the MIME structure. Mails not conforming the RFCs are rejected. However, many clients do not respect RFC and if the security policy allows sending such mails you can enforce proxy to correct or even to pass them.

If a document header folded line is longer than the internal buffer size, the header is not processed and the mail is rejected. The buffer size is 16kB, by default, and it can be increased by the client-conn.recv-bufsize and server-conn.send-bufsize configuration directives.

If smtp-proxy forwards delivery error report, it checks (and corrects, if required) also the reported mail (if included). If the correction fails, it rejects whole mail. You can switch off this behavior by setting the treat-rfc822-as-text configuration directive that tells proxy to read included mails as regular texts.

After receiving the whole mail data, proxy finds the appropriate mail-acl taking all checks from previous steps into account. After that, for each MIME document, the appropriate doc-acl is searched for. These steps are repeated for every recipient (including the ones added by copy-to items), because mail processing can vary for different addressee (level 3 ACLs can use also sender's and recipient's email addresses as entry condition). In the case of changing the final recipient (by deliver+to item), the original recipient's address is used for this search.

In phase 3 ACL, following actions are available to deny the service for particular recipient:

Among all denial actions for one recipient ordered by all mail-acl and delivery-acl sections, the one with the highest severity is chosen to use.

If the mail/document is accepted, there are several modifications that can be done: HTML filtering, document replacement, header modifications etc., see mod-mail-doc(5) for more details.

If the mail is not aborted, it can be stored into the quarantine by the quarantine item.

If the mail is accepted to delivery, all forwarder channels are opened and the mail is forwarded to all recipients. While sending copies, the recipients are grouped together according to the set of phase 3 ACL used.

For every such a group, the mail is reassembled from parts (excluding the case of signed documents) using the filtering operations specified in level 3 ACLs (see mod-mail-doc(5)).

Moreover, some header modifications are done in following steps:

During mail reassembly, the RFC 2821 and 2045 rules are respected. Every line longer than 998 bytes (in the sense of normalized length — see above) is splitted into parts (converting the subdocument into MIME quoted-printable transfer encoding, if necessary). Subdocuments being encoded by some MIME encoding (quoted-printable or base64) are re-encoded using 76 chars long lines.

If smtp-proxy forwards signed document, it must not alter its content. That's why the standard way of processing mails (decomposition and reconstruction) cannot be used. Thus, the proxy uses original mail image saved on the beginning of processing, except two cases:

In these cases the proxy does reconstruct mail (because site security has priority) and signature becomes not valid.

In the case of transient failure during forwarding, all servers available for particular forwarder channel are tried. In the case of permanent failure, or when all servers have failed, sending the copy is given up. If any forwarding server does not support 8bit transfer, the mail is converted to 7bit stream. If this is not possible, mail forwarding is rejected.

The result of forwarding is stored for every recipient and in the case of failure of mail coming from a non-null sender, the DSN (Delivery Status Notification) message is constructed and sent to the original sender. This behavior and the content of the message can be partially controlled by the dsn-mail-copy and omit-dsn configuration items. In the case of forwarding mail to a forwarder without ESMTP DSN extension, the proxy sends also DSN RELAYED messages if requested by the clients.

If the mail was ordered to be stored into the quarantine, the image of it, stored at the beginning of processing, is moved or copied to the quarantine directory. Together with this copy, the quarantine control file is stored. It contains all available information about sender, recipient, MIME structure, viruses etc. and also reasons for storing the mail into the quarantine.

The final response code is sent to the client and the proxy is waiting for a new mail, or the QUIT command.