This is the main control point by which you configure Praetor to use either the basic or advanced methods of spam filtering, both of which implement several different techniques. Security experts almost unanimously recommend this approach so that you have a multi-layered defense because reliance on a single technique will eventually be defeated. In this escalating war against spam, the enemy is not about to give up so easily.
Praetor's multiple layers of defense against spam is implemented in the default ADVANCED selection shown above. This selection puts you in full control of the rules filtering, which also includes DNSBL and Bayesian statistical filtering methods.
Here is a description of each available selection with links to the appropriate pages for more detailed information on its configuration where appropriate.
Note:
|
SMTP Protocol Level DNS Blacklist Filtering This technique causes Praetor to use the connecting session's source IP address and perform a look-up on specified DNS blacklist servers operating on the Internet. If the IP address exists on the blacklist servers, the connection attempt on port 25 is refused. This happens even before the normal SMTP greeting is emitted by the virtual SMTP server and so the message transfer has not yet started. Starting in early 2005, CMS began to notice that spammers were changing tactics in response to the protocol level DNS blacklist technique of refusing their transmissions. Instead of honoring the refusal, their new tactic was to flood the receiving mail server and this sometimes may precipitate a denial-of-service (D-O-S) attack. CMS now believes that DNS blacklist lookup should not be done at the SMTP protocol level. Instead you should rely on the message level filtering to perform this DNS blacklist lookup and reject the spam. Besides circumventing a possible D-O-S attack doing this provides other distinctive benefits over the SMTP protocol level:
If you want to restore control of this selection, contact CMS Support to discuss and get assistance. Discussion on how this DNS blacklist filtering is configured can be found here. |
Note:
|
This selection is a convenience for those Praetor installations that have no desire to control the rules so that Praetor's only use is to filter spam. Thus no non-spam content filtering tests are wanted (e.g. profanity, confidential information). By default this basic filtering is not selected because the advanced filter rules are a superset of this pre-configured anti-spam rule filter. |
Selecting this BASIC filter causes Praetor to perform the antispam pre-configured rule filter that includes the Bayesian statistical method to evaluate the message and compute a spam probability index based upon message content. Click here to see the FAQ with the full list of pre-configured rules.
The Bayesian statistics testing is positioned near the end of the list for two reasons. First, it allows Praetor to accept messages from approved senders/domains who sometimes might send something that the Bayesian statistics might find as being spam-like. Second, to help reduce the number of messages that need to go through the statistical computations since it consumes a lot of system resources.
If you need to deviate from these pre-set rules with the Bayesian filtering, then you should not enable this selection, and depend only on the advanced rule filter selection. Doing so would permit you to manually configure the rules to suit your needs, and you still have the Bayesian filtering capabilities, which are expressed as one or more rules.
This Praetor selection is actually a superset of all the techniques listed above it and is our recommended and default selection. Using the rules filter you can have greater flexibility since you can choose additional conditions and optional actions for the rules, and create new ones. Furthermore the default set of rules that are enabled implement multiple layers of defense against spam.
For example, while the norm is to perform DNSBL filtering at the SMTP protocol level so that messages originating from blacklisted mail servers are refused (no message received), you may be concerned about refusing messages from your trading partners that have been blacklisted. Thus it is be better to perform DNSBL filtering at the message level so that you can add the exceptions for such partners. Even more important, SMTP protocol level DNSBL filtering now appears to be susceptible to a denial-of-service form of attack as noted above.
Select this ADVANCED rule filter to have Praetor perform rules-based filtering that you can control both the order and tests. (This was the original feature that was available when Praetor was first released in 1999.) Many of the rules perform tests for spam and two in particular protect you against attached virus infections as they implement your policy concerning message attachments.
You may feel that the DNS blacklist and Bayesian filtering will screen out much of your spam and so all you need is to enable these methods. This is true, but there are some rules-based filters that can catch other spams very successfully because they test for spammer tricks used in HTML messages. One example is the detection of "invisible ink", characters that are placed into the spam to fool anti-spam products but are hidden from the viewer because the font color is the same as the background. This type of trick is not something that is used in real messages.
Another reason for enabling the ADVANCED rule filter is that it can be used for many other functions besides spam detection. Functions like archiving only certain messages or adding disclaimers to the messages.