Note:The order of processing your message filtering rules will have an impact on Praetor's overall performance, measured in terms of speed and accuracy.
Note:
|
The discussion contained in this section deals only with the rules which affect messages that have been received. As these are at the message level, these rules operate after any and all accept/reject decisions which occurred at the earlier SMTP protocol level. Click on the following link for a discussion on the order of SMTP protocol level tests. |
Ever since the infamous I-LOVE-YOU worm/virus struck in May 2000, CMS has strongly recommended that you place this rule to reject known virus attachment files first in the ordering of Praetor's rules. This should even be done ahead of any acceptance rules, e.g. for partner domains and email addresses.
The reason for this strong recommendation is quite simple. These worm viruses propagate themselves by using the Outlook address book. Of course, your trading partners will likely have the email addresses of people in your domain. Therefore if any partner has an infected PC in their network, email may be sent to your people.
Similar to the motivations for placing the above rule rejecting banned attachments, CMS also strongly recommends that this rule be placed as the second in your order of Praetor filtering rules. This rule is very useful since it tests for attachment files of a suspicious nature. Indeed our experience has been that this one rule has been the filter that protected all our customers from infection.
This rule's effectiveness is due to the fact that attachments must be fully declared using the standard MIME specification. Thus it is possible for Praetor to test if the attachment meets the Suspicious Attachment list where *.EXE, *.VBS, and other filename patterns can be found. The Banned Attachment list only contains known virus filenames.
Note:
|
Please review the Banned Attachment and Suspicious Attachment lists. If you want to reject all EXE, VBS, PIF, SCR attachments then move the entries *.EXE, *.VBS, etc. to the Banned Attachment list since they only appear in the Suspicious Attachment list. With the release of the MyDoom / NOVARG virus in early 2004 that also sent out infections in compressed ZIP files, we have added a rule specifically to deal with *.ZIP attachments. This is being done instead of adding the entry into the Suspicious Attachment list so that you may conveniently add any exceptions. |
The next observation that will help in arriving at an optimal ordering sequence is to realize that most messages received will not be spam, and therefore, must go through the gauntlet of all the rules you have set. Thus the most time to be saved is when a message can be readily identified to be non-spam and accepted, thereby skipping all the other subsequent remaining rules. This observation leads to the conclusion that rules resulting in message acceptance is best positioned at the top so that their tests may be performed earliest.
The second observation pertains to the relative placement of the rules according to the frequency of spam that are caught by your rules. The rule that catches the most spam should be placed so that their test may be performed earliest. Doing so will result in early detection and rejection of the spam, thereby skipping all the subsequent remaining rules.
Unfortunately to put this observation into effect would require some experience with the effectiveness of the various message filtering rules that you have set up, against the spam traffic that your site experiences. When you first install Praetor, you don't have sufficient experience to know which rules are trapping the most spam. Until you have that experience, CMS recommends that you start by ordering the rules according to their theoretical speed of processing, that is according to the rule types discussed earlier. Specifically place the single-shot rules earliest and the rules involving external sources last.
The third observation involves ordering for accuracy. The main objective here is to minimize the numbers of "false positives" -- good messages that were incorrectly detected as spam. Of course, where string of banned words or phrases are involved, one should obviously make careful choices. In general terms, make the tests as specific as possible, opting for phrases instead of single words. Additionally, it would be best to order the rules so that those with more specific conditions would be tested earlier than those with less specific conditions.
Putting all these observations into practice we arrive at the following guidelines as a start.
Single-shot rules for acceptance with specific test first, followed by tests in decreasing specificity
Single-shot rules for rejection with specific test first, followed by tests in decreasing specificity
String search rules for acceptance with specific test first, followed by tests in decreasing specificity
String search rules for rejection with specific test first, followed by tests in decreasing specificity
List search rules for acceptance with specific test first, followed by tests in decreasing specificity
List search rules for rejection with specific test first, followed by tests in decreasing specificity
Rules with external information sources for acceptance with specific test first, followed by tests in decreasing specificity
Rules with external information sources for rejection with specific test first, followed by tests in decreasing specificity
With experience, you should re-order the rules so that the most frequent type of spam is caught as early as possible.