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.
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.
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
and buttons to delete rules from the list.Use the
button (or ) to open a dialog where rules can be defined or modified.Filtering rules consist of the following items:
Comment on the rule (for use of administrator).
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.
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
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 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).
Required entry content (according to the selected type).
Once a rule is set, select one of the following actions:
Messages treated as spam may be accepted as non-spam using this option.
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).
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:
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.
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.
The settings are applied only to custom rules where the Treat the message as spam and reject it option is set:
Message will be discarded without notification. This action is
not performed if the rule filters the From
and
To
items (for details, see above).
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.
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.