Pass
(Pass)

The email message will be delivered to the recipient. Besides, all actions aimed at adding and changing headers will be applied, as well as actions aimed at repacking if such have been indicated in the rules triggered for this email message.

Arguments: None.

Features of action implementation:

An action can be applied for all methods of connection to MTA, as well as for integration via the proxy mechanism into any mail protocol.

Reject
(Reject)

The email message will not be accepted from the sender (for POP3/IMAP—from the mail server) and will not be delivered to the recipient.

Features of action implementation:

•Integration with MTA as a filter:

For interfaces Spamd and Rspamd MTA returns the verdict “the email message is spam”. Real action with the email message depends on the settings of the protected MTA. Optional parameter of the action <description>, if indicated, will be used as the value of the header “Message”, added by MTA to the email message after the message with scanning results (it allows to indirectly return to MTA the reason of the email message rejection).

•Integration into mail protocols via the proxy mechanism:

▫For protocols IMAP and POP3, return email messages to the sender, i.e. MUA, protocol error.

▫For SMTP—return of the code 541 to the sender.

Temporary error
(Tempfail)

The email message will not be accepted from the sender (for POP3/IMAP—from the mail server) and will not be delivered to the recipient.

Features of action implementation:

•Integration with MTA as a filter:

For interfaces Spamd and Rspamd MTA returns the verdict “the email message is spam”. Real action with the email message depends on the settings of the protected MTA. Optional parameter of the action <description>, if indicated, will be used as the value of the header “Message”, added by MTA to the email message after the message with scanning results (it allows to indirectly return to MTA the reason of the email message rejection).

•Integration into mail protocols via the proxy mechanism:

▫For protocols IMAP and POP3, return email messages to the sender, i.e. MUA, protocol error.

▫For SMTP—return of the code 451 to the sender.

Discard
(Discard)

The email message will not be accepted from the sender (for POP3/IMAP—from the mail server) and will not be delivered to the recipient.

Features of action implementation:

•Integration with MTA as a filter:

For interfaces Spamd and Rspamd MTA returns the verdict “the email message is spam”. Real action with the email message depends on the settings of the protected MTA.

•Integration into mail protocols via the proxy mechanism:

▫For protocols IMAP and POP3, return email messages to the sender, i.e. MUA, protocol error.

▫For SMTP—receipt of the email message from the sender with the OK confirmation and removal instead of delivery to the recipient.

Block
(Block)

Synonym for the action “Reject”. Used for compatibility.

Repack
(Repack)

The email message will be delivered to the recipient changed: it will have an added notification on detection of threats, and the threats themselves will be placed in the archive attached to the created email message. Depending on the settings, this archive can be protected with password.

If threats were in headers or text of the email message, not in its attachments (including cases when the email letter is considered spam or does not meet the corresponding security policy determined by the administrator in the rules), all source email message will be entirely placed in the source email message.

There are the following predetermined templates for repacking:

1.The email message is spam (the source email message is moved to the archive);

2.One or more threats in the email message (files with threats are moved to the archive);

3.One or more malicious/unwanted URLs in the email message (the source email message or its parts containing URL are moved to the archive);

4.Violation of the security policy established by the administrator (the source email message or its unwanted parts are moved to the archive).

The action will be applied to the email message if the rules contain the final resolution Pass (or does not contain Reject, Block, Tempfail, Discard).

Features of action implementation:

•Integration with MTA as a filter:

For interfaces Spamd and Rspamd it is not supported (impossible to return the server the modified email message).

Add header
(Add Header)

Add the indicated header to the email message.

The action will be applied to the email message if the rules contain the final resolution Pass (or does not contain Reject, Block, Tempfail, Discard).

Features of action implementation:

•Integration with MTA as a filter:

For interfaces Spamd and Rspamd it is not supported (impossible to return the server the modified email message).

Change header
(Change Header)

Change value of the indicated header in the email message.

The action will be applied to the email message if the rules contain the final resolution Pass (or does not contain Reject, Block, Tempfail, Discard).

Features of action implementation:

•Integration with MTA as a filter:

For interfaces Spamd and Rspamd it is not supported (impossible to return the server the modified email message).