Installation manual

normalized value assigned to a message that indicates the likelihood of the message being spam (based on the

characteristics of the message header, its subject, content, etc.). A rating of 0 indicates that the message is highly

unlikely to be spam, while a rating of 9 indicates that the message is very likely spam. SCL values can be processed

further by the Microsoft Exchange Server's Intelligent Message Filter (or Content Filter Agent). For additional

information, please refer to the Microsoft Exchange Server documentation.

The When deleting messages, send SMTP reject response option:

If unchecked, the server sends an OK SMTP response to the sender’s Mail Transfer Agent (MTA) in the format ‘250

2.5.0 – Requested mail action okay, completed’ and then performs a silent drop.

If checked, an SMTP reject response is sent back to the sender’s MTA. You can type a response message in the

following format:

Primary response code

Complementary status code

Description

250

2.5.0

Requested mail action okay, completed

451

4.5.1

Requested action aborted: local error in processing

550

5.5.0

Requested action not taken: mailbox unavailable

Warning: Incorrect syntax of the SMTP response codes can lead to program components malfunctioning and a

decrease in

NOTE: You can also use system variables when configuring SMTP Reject Responses.

3.1.2 Rules

The Rules menu item allows administrators to manually define email filtering conditions and actions to take with

filtered emails. The rules are applied according to a set of combined conditions. Multiple conditions are combined

with the logical operator AND, applying the rule only if all the conditions are met. The Number column (next to

each rule name) displays the number of times the rule was successfully applied.

The rules are checked against a message when it is processed by the transport agent (TA) or VSAPI. When both the

TA and VSAPI are enabled and the message matches the rule conditions, the rule counter may increase by 2 or

more. This is because the VSAPI accesses each part of the message individually (body, attachment) meaning the

rules are consequently applied to each part individually. Rules are also applied during background scanning (e.g.

repeated mailbox-store scan after a virus signature database update), which can increase the rule counter.