13.3  Custom Rules

If Kerio MailServer's internal antispam features do not satisfy your needs, it is possible to manually customize rules to create a suitable filter which would complement the internal system and increase the antispam efficiency. These rules can be defined on the Custom Rules tab.

The tab consists of two sections. One contains list of rules and their definition tools. The latter covers settings of how messages blocked by server-defined rules would be handled.

Custom Rules

Figure 13.5. Custom Rules


Rule Definition

On the tab, each filtering rule is represented by one line (see figure 13.5  Custom Rules). Using matching fields on the left you can activate or disable individual rules. This way you can switch the rules temporarily on and off without the need to remove them and add them again.

When creating rules, bear in mind that their order in the list is very important. Individual rules are processed in the same order as listed, downwards. Rules in the list can be reordered by the arrow buttons on the right. Simply select a rule in the list and click the arrows to move it up or down.

Rules can also be moved by the Drag and Drop method, i.e. by dragging and moving rules by mouse.

It is essential to consider twice especially location of denial and allowance rules since once these rules are processed, no other rules are applied. After rules where only score points are added or taken off, other rules are processed unless all of them are applied or unless the message matches a permission/denial rule.

Note: Rules tested against From and To headers have a peculiarity which might be beneficial. If these rules go before the others, they will be tested on level of SMTP traffic. In case of denial rules, messages matching such a rule are blocked even before accepted to the queue of incoming messages. This decreases the load on the server. It helps the server avoid taking several actions and using of several tools such as antispam tests and antivirus control which is applied once a message is accepted to the queue of incoming messages. In case of permission rules, no other rules are applied if they are tested on level of SMTP traffic. For detailed description on testing of headers, see below (the Headers section).

Click the Remove and Remove unused buttons to delete rules from the list.

Use the Add button (or Edit) to open a dialog where rules can be defined or modified.

Defining rule

Figure 13.6. Defining rule


Filtering rules consist of the following items:

Description

Comment on the rule (for use of administrator).

Header

Tested part of email message header. You can choose from various predefined options (From, To, Cc, Subject and Sender) or create a custom one (i.e. X-Mailer). Do not use colons while defining header names.

The From and To items slightly differ from the other ones. These items are checked for the From and To headers in email and for headers included in SMTP envelopes. The From item is compared with MAIL FROM: and the To item is compared with RCPT TO:. Any other items are compared with headers included in the email itself only.

This implies the following facts:

Any other settings for blocked messages do not apply to messages rejected on SMTP level. Any message meeting the denial rule is rejected and marked with the standard 553 error code (this code means that it is a persistent error and the SMTP server will not retry to deliver it) and a DSN message is sent to the sender.

To rules regarding From and To items, a special exception regarding their order in the rule list is applied (see above). If the From and To rules are starting the rule list (no other rule precedes them), they are executed against the MAIL FROM: and RCPT TO: headers on SMTP level. If there is even a single rule preceding these rules which is tested against a different header, the message is automatically accepted in the queue of incoming messages while the From and To rules are tested against From: and To: headers included inside the message.

The issue will be better understood through the following examples:

  • Example 1:

    In Example 1 (see table 13.1  Example 1:), rules are ordered so that messages sent from spammer@domain.com are accepted by Kerio MailServer, while any other messages from the domain.com domain are blocked on SMTP level. The third rule allows any messages delivered to the local domain company.com on SMTP level.

    Warning

    The following testing methods are applied prior to custom rules:

    • Spam repellent

    • Caller ID and SPF

    • Whitelists/Blacklists

    This, however, implies that every message including the spammer@domain.com address as a sender is tested. If not blocked by the tests listed and having reached custom rules, the permission rule is applied and no additional tests will be applied to the message (actually, they will, but their result scores will be set to 0 points).

    Header Type Content Action
    From Address spammer@domain.com Allow
    From Domain domain.com Reject
    To Domain company.com Allow

    Table 13.1. Example 1:


  • Example 2

    In the second example, all email for admin@company.com will be rejected at the SMTP server level (see table 13.2  Example 2). The next rule blocks any email from the spam.com domain except messages where the test string is included in the Subject header.

    Header Type Content Action
    To Address admin@company.com Reject
    Subject Substring test Allow
    From Domain spam.com Reject

    Table 13.2. Example 2


Warning

The examples imply that, when creating rules, it is also necessary to avoid situations where one rule is unexpectedly influenced by another. This might happen for example when users are subscribed in mailing lists and addresses in MAIL FROM: and RCPT TO: do not match addresses in From and To headers inside the message.

Type

Type of condition under which the entry will be tested. Available types:

  • Is empty — the item is empty

  • Is missing — the message does not contain the specified message header

  • Contains address — the item contains a specific email address

  • Contains address with domain — the item contains all email addresses from this domain. Enter the mail domain, i.e. the second part of the email address right from the @ character, in this field.

  • Contains substring — the item contains specific string of characters (a word, a piece of text, a number, etc.).

  • Contains binary data — using this condition, the above-mentioned specific characters as well as binary data that may be contained in spam messages can be recognized. Binary data are characters that have a different meaning in each character set (e.g. specific national characters).

Content

Required entry content (according to the selected type).

Once a rule is set, select one of the following actions:

Treat the message as non-spam

Messages treated as spam may be accepted as non-spam using this option.

Treat the message as spam and reject it

Email message matching this rule will be marked as spam, regardless of the spam filter. It will use settings from the Custom Rules tab, from section If the message was rejected by a custom spam rule (described below).

Add this value to the message's spam score

Define score value for SpamAssassin (the higher the value, the lower is the possibility that a message passes through the filter). Value that you match with messages meeting this rule will be added to the corresponding SpamAssassin evaluation (negative values protect messages from being considered as spam).

In case of this blacklist, the recommended score value is from 1 to 3 points.

Examples:

  1. Suppose that you want that the server blocks all email sent from someone@domain.com. Define a rule where the From entry will be tested. Choose the contains address condition type (particular email address) and specify the Content entry using the email address (someone@domain.com). In the Score entry specify a value — this should be equal or higher than the value set in the Action tab.

  2. A user has demanded regular messages with current special offers. These messages are sent from info@offer.com and they are treated as spam by SpamAssassin. To override this denial, we will create the following custom rule:

    • Header — use the  From selection

    • Type — select the Contains address option

    • Content — insert info@offer.com

    • Add score to the message — set a negative value that will decrease the total score. You can also use the Treat the message as non-spam (overrides the SpamAssassin score) option.

If the message was rejected by a custom spam rule

The settings are applied only to custom rules where the Treat the message as spam and reject it option is set:

Block the message and do not deliver it to the recipient

Message will be discarded without notification. This action is not performed if the rule filters the From and To items (for details, see above).

Send bounce message to the sender

The server returns the sender a DSN message informing that the email message cannot be delivered.

It is not recommended to use this option since most of spam message use false sender addresses. This implies that the denial message cannot be delivered (the address to which the DNS message is sent might not exist). Messages informing about denial of the original messages are then waiting in a queue where there must be physically removed, otherwise, the server attempts to send them every 30 minutes and discards the messages after two or three days.

Forward the message to quarantine address

The address to which messages will be forwarded and where administrator or another authorized person can check whether there are or there are not legitimate messages included in the spam. Using this option is recommended since it helps you avoid losing of non-spam email without any notification.