Message level tests

Testing at the message level is considerably different than the testing done at the SMTP protocol level. First, Praetor will not even make its rounds on this level if it finds cause to reject a message during protocol testing. (Remember, since acceptance or rejection is absolute, an inbound message is either accepted or rejected once it absolutely passes or fails a given test). Second, while protocol level testing is performed during a connected session with the sending MTA and before Praetor receives the complete message data stream, message level testing is begun after the message is completely received and stored locally. In fact, just like SMTP protocol level, testing at the message level is performed by scanning the message headers which are defined according to the Internet standard specification known as RFC-822 and subsequent additions.

Every SMTP message contains header lines followed by a blank line separator and the actual message text. Typically only a few of these message header lines are displayed in the aesthetically pleasing graphical user interfaces (GUIs) of modern client e-mail software. What is displayed is usually basic information, while the full Internet message headers are often concealed for the sake of readability and user-friendliness. In fact, a sample of the full message header - from which Praetor bases its message level testing - appears as the following.

Received: (mail@localhost) by bighorn.terra.net (8.8.6/jr3.11)
  for id PAA16497; Mon, 1 Feb 1999 15:52:27 -0500
Precedence: bulk
Errors-To: owner-clubmed@bipi.com
Received: from argali.terra.net (root@argali.terra.net [199.103.128.1])
  by bighorn.terra.net (8.8.6/jr3.11) with ESMTP
  for <clubmed@bighorn.terra.net>
  id PAA16308; Mon, 1 Feb 1999 15:51:52 -0500
Received: from argali.terra.net (root@localhost)
  by argali.terra.net (8.8.8/jr3.11) with EXEC
  for clubmed id PAA09846; Mon, 1 Feb 1999 15:51:52 -0500
Received: from brendan.bipi.com (pc238.bipi.com [199.103.194.238])
  by argali.terra.net (8.8.8/jr3.11) with SMTP
  for <clubmed@bipi.com> id PAA09837; Mon, 1 Feb 1999 15:51:50 -0500
Message-ID: <000701be4e24$ea36c640$ee267c7@brendan.bipi.com>
From: "Club Med email" <clubmed-admin@bipi.com>
To: <clubmed@bipi.com>
Subject: HANDS UP!
Date: Mon, 1 Feb 1999 15:53:26 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4

Dear Traveler,
  :
  :
  :

Figure B.1 - Sample RFC-822 Message

For reasons that should be apparent, most modern e-mail clients abbreviate these full headers choosing instead to display only the most relevant information, such as sender, recipient, time/day stamp, and subject. While this increases readability and presentation dramatically, it removes some very useful information - information that Praetor analyzes to discriminate spam mail from useful mail. Fortunately, unlike many products available today, Praetor operates at the server level and not the client level of the email software. It intercedes and captures the message even before the normal mail server (Exchange, Domino, or generic SMTP server) gets the message. Thus Praetor performs its spam-eradicating functions and passes to the mail server only those messages that passes the antispam rules set by the administrator.

Some of the countermeasures specific to Praetor's Message Header (RFC-822) defenses are explained in this appendix. These are rules that are delivered by CMS and appear on the list of Conditional Inbound Rules by default. Use the links provided below to see each rule, or select the page on the left pane which organizes the rules by what conditions they test.

Praetor also provides default Rule templates within Praetor's administration program so that they may be easily used as the starting point for new rules with additional or modified conditions.

CMS plans to make available to all supported Praetor customers software updates and additional rules or templates in the future. The rules or templates will likely implement different techniques and possibly modify existing rules based upon what new methods are being used by spammers.

Note: