Cover page

Generation.2

Version 2.1 — June 2005 Edition

Click here to see what's new in Praetor


Introduction

"Well, there's egg and bacon; egg sausage and bacon; egg and spam; egg bacon and spam; egg bacon sausage and spam; spam bacon sausage and spam; spam egg spam spam bacon and spam; spam sausage spam spam bacon spam tomato and spam; ..." — Monty Python's Flying Circus, 1970 (read the full skit)

Beginning from the time when the word "spam" was used as a pejorative item in this now-famous Monty Python sketch to what you now have with the unsolicited junk messages clogging your electronic mail, spam has gone from being humorous to being the harbinger of serious consequences.

According to testimony given to the Federal Trade Commission by America Online even as early as 1997, on any given day approximately a third of all messages received from the Internet is spam. In fact, it was spam that overwhelmed AT&T WorldNet's system in July 1997 and caused hours of delay for legitimate messages. For corporate email users, a study published in the Communications of the ACM in August 1998 estimates that spam received by AT&T Research and Bell Labs Research ranged from 5% to 15%. Today in 2003 estimates range upwards of 45% of corporate received email traffic.

Suffice it to say that spam is a growing problem that continues unabated that led your company to purchase this email content filtering product.

The consequences of the deluge of spam fall into several distinct areas for any company using email and which is the victim of spam.

  1. Loss of human resources on the part of the recipient who has to open the junk messages and to delete them.

  2. Loss of computer resources as the junk messages take up valuable storage space.

  3. Loss of human resources on the part of the email administrator who has to deal with Internet mail delivery being bogged down.

  4. Loss of connectivity bandwidth that is being stolen to needlessly carry the spam.

  5. Loss of company reputation if its mail hosts are being hijacked to relay spam and the public is led to believe the company is engaged in spamming activity.

In total, for the spam recipients, the price is too high. Take, for example, the productivity loss from the simple act of deleting the spam from one's inbox. Assuming it takes five seconds to complete the deletion, at an fully-loaded average of $25 per hour per employee (salary, benefits, desk space, etc.) the productivity loss is costing the company $0.03 for each spam. While that may seem small, multiply it by the thousands of spam that may be received and you will see how big the problem really is. And that is just in terms of the productivity loss by the recipients, item 1 in the above list!

Of course there are many other ills borne by Internet email! Here are some of the worse examples.

  • Email carrying virus infections and self-propagating worms

  • Reverse NDR attacks to turn your mail server into an indirect email relay

The problems are so serious that email is in jeopardy as a business tool. With experience in Internet email products since 1992, CMS had the foresight to release Praetor in 1999 to stem the tide that has become such a big problem with email today.

How ironic, then, that the root cause of spam is its low cost from the viewpoint of the perpetrators. Using a single unlimited account with any ISP with a monthly charge of $20 or less, a spammer can send out millions of messages using a slow 28.8Kbps modem. An estimate of a penny for 10,000 messages is probably "in the ballpark" with respect to the cost to send out spam.

Next


What's in this manual

Praetor was developed to implement techniques that are highly effective in combating spam. These techniques were obtained from the profiling and analysis of countless spam email messages, many of which were graciously provided by the Spam Recycling Center. Praetor, therefore, guards against tactics that are commonly used by the perpetrators of spam. It also has a flexible means of extending those techniques using a scripting language to add to its effectiveness as new spam techniques appear.

This manual starts with a technical overview in Chapter 1. Beginning with standard Internet messaging basics, the material is presented so that you have a firm grasp of how anti-spam techniques can be used at key message processing events. Discussion then focuses on how the Praetor product will fit within an existing email infrastructure at your company.

Chapter 2 provides some pre-installation considerations including requirements for Praetor and recommendations for the equipment needed. Also covered are the few preparatory steps for Windows XP Professional, 2000 or 2003 Server.

Chapter 3 deals with the Praetor installation process which now consists of installing the following three components in the following order: SQL databases, SMTP filter component, and personal Log Viewer web application.

Chapter 4 deals with the configuration although you will likely used most of the product's default settings. In this way, you can quickly get Praetor started. This chapter is set up in a referential manner for each feature found in the administration program with many active links in the screenshots. These links will show you how to configure Praetor's filtering capabilities and adjust settings to reflect with your own experiences and needs.

Chapter 5 discusses the message-level rules that can be created, with detailed description of the two different rule types, conditional and global, and the components that make up a rule: conditions and actions. Rule templates are supplied to make the creation of new rules even simpler based upon the template.

Chapter 6 has a discussion of the user-based licensing that Praetor implements.

Chapters 7 and 8 discuss two useful Praetor utilities Praetor -- the Log Viewer and Log Analyzer. The Log Viewer is used to deal with the messages that are quarantined. Also provided are instructions on how to provide your local users to access their personal message log via a web browser within your network. The Log Analyzer is a Microsoft Access application that will access the SQL database of Praetor log entries to analyze and report on the message traffic passing through Praetor.

The final chapter lists several command-line tools for use in managing Praetor.

Note:

You can always see if there is a new version of the electronic manual by visiting the CMS Internet web site at http://www.cmsconnect.com and going to the Praetor product area and clicking on link to the online documentation.

The end of this manual contains appendices on various topics:

A. Listing of all SMTP protocol level tests

B. Supplied message level rules

C. How to contact Computer Mail Services

D. Resources found on the Internet

E. Details of Praetor scripting resources

F. Frequently asked questions

Next


Conventions used

Throughout this manual the enclosing of bolded letters of constant width between the less than '<' and greater than '>' symbols are used to denote single keyboard keystrokes. Those commonly used are:

<Enter> | The carriage return key
<Escape> | The escape key
<Insert> | The insert key
<Delete> | The delete key

Also any characters displayed on the screen are denoted in non-bolded, non-underlined characters of constant width.

Menu selections or commands and buttons to be pressed are denoted in bolded characters such as File, Run, and Finish. References to on-screen field names, selection check boxes or radio buttons, and titles for list boxes will be made in bolded italics using this color such as Connection Type. Group boxes are shown bolded italics using a different font and color such as Connection Method. Tab titles are shown as System, while Windows titles appear as Manage Templates.

Any keyboard entry to be made by the user are bolded and underlined and of constant width. An example of this is:

C>A:setup <ENTER>

Also hyperlinks to other topics will be shown as underlined text in blue as such as this link to the next page.

Next


Basics of Internet Messaging

Internet messaging occurs at two distinct levels, between message transport hosts or agents (MTA) commonly referred to as mail hosts or mail servers, and between a mail client software (known as a mail user agent, MUA) such as Microsoft Outlook or Lotus Notes, and its MTA that would be Microsoft Exchange or Lotus Domino. As it relates to the Praetor product, we will focus our discussion to the more relevant MTA-MTA message exchange between two SMTP mail servers.

The MTA-MTA message exchange is analogous to a live telephone call between two people. For the telephone call to be successful, a caller must be able to dial the phone number, the phone network must be able to make the connection, and the receiver must be able to answer the ringing phone. If there is no one to pick up the ringing phone, the call is not completed. In the Internet messaging world, these three elements are equivalent to the sending MTA using the IP address of the receiving MTA, the Internet routing the data packets, and the receiving MTA being available to respond by opening the connection. When all three elements are present, the message exchange can happen using the Internet standard known as the Simple Mail Transfer Protocol (SMTP) defined by the document known as RFC-2821.

Next


Praetor anti-spam countermeasures

Continuing with the telephone call analogy, it is possible for the call to go through but no phone conversation actually takes place. One possibility for this is that the recipient is too busy to talk and refuses to talk with the caller.

In the same way, the MTA-MTA message exchange can also be incomplete, with the receiver MTA abruptly ending the message transfer session. This incomplete message transfer reflects one level of filtering that Praetor provides -- at the SMTP protocol level and so the message is never actually received. Should the message survive the protocol level filter and is received, Praetor will scan them according to the message level filtering rules that are enabled.

Click below to learn more about the various filters provided in Praetor, many of which are used to combat the growing spam problem.

^ SMTP protocol level | Occurs during the actual message transfer process.
* Message level | Occurs after the inbound message is received completely or before the outbound message is transmitted.

Praetor implements these filters using a variety of methodologies within the framework of a rules-based system that is designed to give you the ultimate in flexibility. Within this framework, you select the message direction, conditions, actions, and exceptions that comprise your rules. The available methods include:

  • DNS blackhole lists

  • Bayesian technique of statistical content filtering

  • Heuristics using a weighted score of content

  • CMS-supplied rules using:

    • Local black and white lists

    • Basic lexical analysis on body content

    • Weighted words

Compared to the previous version 1.5, this new G2 version has additional methods that make spam detection far more accurate with fewer false positives and requiring much less administration. Here is a comparison table with a summary of the differences.


SMTP Protocol level

The table below contains a summary of a complete SMTP message transfer session between the sending MTA, tx-moon.com, and the receiving MTA, rx-earth.com. In this conversation the sending MTA is written in bold blue characters while the receiving MTA is in normal green characters, and comments are in italics.

Sender or Receiver | Comments
 | Sender tx-moon.com connects to port 25 at Receiver rx-earth.com and session is established
220 rx-earth.com ESMTP Sendmail 8.12.7/8.12.6; Mon, 10 Mar 2003 | rx-earth.com announces that it is listening
HELO tx.moon.com | Sender identifies itself
250 Pleased to meet you | Receiver returns greeting
MAIL FROM: <sender@tx-moon.com> | Sender identifies the message sender's address
250 OK | Receiver confirms sender address
RCPT TO: <recipient@rx-earth.com> | Sender gives the address of the message recipient
250 OK | Receiver confirms the address
DATA | Sender states that it is about to transmit the message
354 Enter mail, end with CRLF.CRLF | Receiver states that it is ready to accept the message
message data transmission begins : : : . | Sender starts sending the message which includes the message header, body text, and any attachment(s) Period on line by itself indicates the end of the message data
250 OK | Receiver states that it got the entire message data
QUIT | Sender states that it is done
 | Receiver closes the connection

The Microsoft SMTP virtual server provides connection based filtering by using the IP address of the connected session, even before any greeting is exchanged. These include the following.

  1. IP address of the connected session

  2. Domain name based on a reverse DNS lookup of the connected IP

  3. Relay control

Unfortunately this leaves out a very useful filtering technique that can eliminate a substantial amount of spam — the ability to check various DNS-based blacklist servers to see if the connected IP belongs to known spammer machines. Praetor G2 provides this missing filter

Note:

If you were using the previous version 1.5 of Praetor, you will note that many other SMTP protocol level tests appear to have been removed. In reality, these facilities have been moved to message-level testing resulting from this G2 version's reliance on the Windows 2000/XP SMTP virtual server.

1. MAIL FROM sender address check
2. MAIL FROM sender domain check
3. RCPT TO recipient address check

Naturally, this will require the message to be received in its entirety instead of abruptly terminating the message transfer process by disconnecting the session.

Order of SMTP protocol level tests

The order of these tests are as follows.

  1. Banned IP blacklist

  2. Reverse DNS check on domain name

  3. Relay check

  4. DNS blacklist filter

Next


Message level

Even if the message transfer is completed and a message is received, Praetor performs message-level filtering. At this stage, it will examine the message, analyzing it using rules that were specified by the administrator. Should the analysis conclude with the determination that the message is spam, Praetor will dispose of it, and optionally archive it before it is deleted.

A few examples of these filtering rules include the following checks:

  1. From address is on the banned or accepted sender list

  2. From address has a non-existent domain

  3. Reply-to address is nonsense or non-existent

  4. From and To address are the same

  5. Recipient address is on the ban list

  6. Blank message ID

  7. Inappropriate content on the subject line

  8. Inappropriate content in the message body itself, like profanity

  9. Check if attachment name matches forbidden names

Please refer to Appendix B for a complete list with more details.

As stated before, the administrator can add additional rules. In fact, Praetor has the flexibility to allow filtering any message header line for either banned content to reject the message or approved content to accept the message and stop further checking.

Next


Praetor requirements

To operate Praetor you will need the following:

  • A 2004-era off-the-shelf PC with at least a Pentium IV processor operating at 2 GHz or faster, with a minimum of 512 MB RAM preferably 1GB, and 10 GB of free hard disk space. Click here to see our recommendations.

  • Color display & adapter set with a minimum resolution of 1024x768 pixels and at least 64K colors

  • Network interface card

  • One of the following operating systems with the latest service pack applied and the Microsoft virtual SMTP server already installed:

    • Windows 2000 Professional Edition

    • Windows XP Professional Edition

    • Windows 2000 Server

    • Windows 2003 .NET Server

Note:

Keep in mind that Microsoft has placed limitations on the number of simultaneous IP sessions for their non-server editions of the Windows OS. Both Windows 2000 and XP Professional is limited to 10 concurrent IP sessions. Thus if yours is a site that receives a lot of email, you may need to use a Windows server edition.

Exceeding 10 connections is not catastrophic; the sending server will simply have to retry sending the email to you. CMS estimates that the non-server editions will suffice for sites receiving less than 500 messages per hour or 5000 messages per day.

  • Installed and operational Microsoft virtual SMTP server (Windows 2000/XP) or Exchange 200x SMTP server (a component of Microsoft's Internet Information Services).

  • Installed and operational Microsoft IIS web server for use with the optional browser-based log viewer called PLGV.

  • Microsoft .NET Framework 1.1 or later which Praetor's installer will download and install for you. Alternatively you can download from Microsoft's website. Information is also provided on how you can if .NET Framework has already been installed.

Note:

While Windows 2003 may have this framework already installed and known as ASP.NET, you will need to verify it. Also, even if installed, you need to verify that ASP.NET is allowed to run as a web service extension under IIS.

See how this is done by clicking here.

  • Installed Microsoft SQL Server or the Microsoft SQL Desktop Engine (MSDE) which Praetor's installed will download and install for you. Alternatively you can be downloaded from Microsoft's website. Be sure to get the version that was published on or after October 29, 2003 since this release includes the fixes that prevent the Slammer worm to propagate.

    Even if you want to use a remote SQL Server, just have MSDE installed so that the database can be attached. You can later detach and move the Praetor databases onto the remote SQL Server and re-attach it there.

Note:

Microsoft has limited MSDE to 8 concurrent queries. The built-in "workload governor" will automatically inject a fixed delay of "a few milliseconds" when there are more than 8. You can read more about this on Microsoft's website.

Exceeding this amount occasionally is not catastrophic but will likely slow down Praetor's message processing ability during the period whenever the this governor is activated. CMS estimates that the non-server editions will suffice for sites receiving less than 500 messages per hour or 5000 messages per day. Typically this will be for sites with less than 100 users.

Exceeding this limit constantly will be cause filtering issues, and in extreme cases it may appear that Praetor no longer filters as there are no new log entries. Click here to read more about this situation.

Another limit found in MSDE is the maximum database size of 2GB. Even if your site may not have many users, your volume of mail may eventually cause you to reach this database limit. You need to make certain to regularly run the database cleanup tools to eliminate very old records to avoid reaching this limit. Once this limit is reached Praetor cannot add any more records so that quarantined messages cannot be reviewed and released.

As of late June 2004, Microsoft announced plans to update MSDE with a follow-on product they call the SQL Server 2005 Express Edition. The reason for the name change was "MSDE was confusing to customers and partners because many did not realize that it was associated with SQL Server." CMS has not yet tested this as-yet beta version of MSDE's successor.

  • One of the following mail servers, installed and configured to receive/transmit SMTP mail:

    • Microsoft Exchange Server v5.5 with operational Internet Mail Service,

    • Microsoft Exchange 2000 or 2003 with the Virtual SMTP server,

    • Lotus Domino Server v4.6 or later with its SMTP MTA,

    • Novell GroupWise Server with its Internet Agent, or

    • Sendmail or any SMTP compatible mail server

  • Visual Basic Script file VBScript.DLL must be version 5.6 or higher. This file is located in:

Windows 2000: | C:\WINNT\System32
Windows XP: | C:\WINDOWS\System32
Windows 2003: | C:\WINDOWS\System32

  • Access 2000 or XP to use the LogAnalyzer application.

  • Dedicated connection to the Internet.

Note:

Since 2002 Praetor dropped support for a dial-up connection and made full-time Internet connectivity a requirement. This decision was made for several reasons:

  • Dial-up significantly reduced the effectiveness in Praetor since messages destined to the LAN will be stored on the mail host of the Internet Service Provider. As a result it would not be possible for Praetor to properly perform the SMTP transport level tests associated with the IP connection and declared domain in the initial HELO / EHLO greeting, essentially rendering all such transport tests useless.

  • General availability of high-speed, always-ON Internet connections.

  • Significantly increases the complexity in setting up Praetor. Cooperation must be obtained from the ISP technical support department since they need to properly configure their mail hosts.

Next


Preparing Windows

Praetor requires installation on one of the following Windows operating system platforms:

  • Windows 2000 Professional

  • Windows XP Professional

  • Windows 2000 Server

  • Windows 2000 Advanced Server

  • Windows 2003 .NET Server

You will need to make certain that Windows is properly installed and configured with the latest Service Pack installed. This is very important if you intend to put this machine on the unprotected side of your firewall so that the latest security patches are in effect.

Also, if the platform has the non-server edition of Windows 2000 or XP, you must first insure that the optional Windows SMTP virtual server is installed and configured. This is a component of the Internet Information Server bundle and is not normally installed on Windows 2000 or XP Professional. It is possible to install just the SMTP virtual server software. Click here to see how to check if this component is installed and , if not then how to install it.

You may want to disable other Internet services such as the FTP server as these are not used by Praetor.

Please note that from an installation standpoint the use of a valid Windows user login is very important. Since Praetor will operate as a part of the SMTP virtual server service, the account used to log into Windows must have administrator privileges.

Warning:

If you have an anti-virus product installed to scan the local drive of the Praetor machine, please configure it so as not to scan any Praetor subdirectories. These locations may hold transient files that do contain virus, but those messages are being quarantined by Praetor.

This chapter deals with:

  • Praetor requirements

  • Recommendations for the Praetor machine

  • Installing the Microsoft virtual SMTP server component of Internet Information Services

  • Splicing Praetor into the existing email infrastructure

Next


Recommendations

Equipment recommendations

With the addition of Bayesian statistical filtering the computational needs were substantially increased as compared to the previous Praetor v1.5. For each message, hundreds of tokens may be present that require as many token database accesses to obtain the good and bad counts from past training. Thus, there are an estimated 10 times more floating point operations to compute the overall statistical probability that the message under review is spam, a value we call spamicity.

The following are CMS's recommendations for optimal performance of a Praetor G2 installation. (Praetor will still function with a lesser machine but delivery may be slowed down a few seconds.) These recommendations are based upon the number of email users and assume an average of 50 received messages per person per day, including spam.

Site size (users) | Rcvd emails per day | CPU | Speed | RAM | Free Disk Storage | Windows OS | Database Server
10 - 49 | < 2,500 | Pentium IV | 1.5 GHz | 512 MB | 10 GB | Pro edition | MSDE
50 - 99 | < 5,000 | Pentium IV | 2.0 GHz | 1 GB | 15 GB | Server edition | MSDE
100 - 249 | < 12,500 | Pentium IV | 2.6 GHz | 1 GB | 20 GB | Server edition | SQL Server
250 - 999 | < 50,000 | Pentium IV | > 3 GHz | 1 GB | 40 GB | Server edition | Separate SQL Server
1,000+ | > 50,000 | Multiple Pentium IV or Xeon in a cluster | > 3 GHz | 2 GB | Clustered disk array | Server edition | Separate SQL Server

Use the above as guidelines focusing on the volume of email received each day. CMS realizes that your company may have different needs that require different configurations. To further discuss how to fit Praetor.G2 into your email system, please contact CMS Support

If you are trying to decide whether to install Praetor on a stand-alone machine or onto the same machine as your Windows 200x-based mail server, click here.

Keep in mind that Microsoft has put limits as follows:

  • Non-server versions of the Windows OS can only have 10 simultaneous IP sessions

  • MSDE can only have 8 concurrent accesses before a "workload governor" is activated to artificially delay each access by several milliseconds. Also, there is a 2GB database (MDF) file limit

Praetor Requirements


Splicing Praetor into the existing site

The introduction of Praetor into your messaging environment is a simple one, with several alternatives on where to install it.

  • Install Praetor on a standalone Windows machine, or

  • Install Praetor on the same machine as the Microsoft Exchange 200x

  • Install Praetor on the same machine as the Windows 2000-based Lotus Domino server.

Choosing between these alternatives requires some consideration as it involves a few factors. One obvious factor is the normal load on the Exchange or Domino server even before Praetor is introduced. If that server is normally operating at 30% CPU utilization or higher and your site receives heavy Internet email traffic, then it would be advisable you don't add Praetor to operate on it. Since allowing Praetor to receive incoming mail directly from the sending host is needed for enabling the SMTP protocol level filters, another factor is how vulnerable you might feel to expose your Domino or Exchange server to the outside world.

Note:

Some firewalls allow you to place Praetor on the protected side and still have direct reception from the sending mail host. This is done by designating a tunnel for port 25 on the firewall's exposed IP address to be dedicated to the internal Praetor machine. If your firewall has its own mail receiver which will receive the inbound message and then simply relays to Praetor on the interior, then many of Praetor's SMTP protocol level filters will be de-activated as these tests use the connecting host's IP address. Obviously in such a situation, the connecting host is your firewall.

An example of such a protocol level filter is the DNS blacklist which Praetor accesses to determine if the sending mail host is known for spamming activities.

Another factor is whether or not you are willing to place the Praetor machine on the unprotected side of your firewall so that it is capable of receiving inbound messages directly from the transmitting mail host. For the most part, that would be fine for a standalone Windows machine with only Praetor on it so that very little is at risk, but you may not feel as comfortable exposing your Exchange server with Praetor in this manner.

Yet another factor is if you ever want to have inbound message reception even when you take your local Exchange or Domino server off-line for maintenance, upgrades, etc.

These are a few of the considerations you need to review.

Stand-alone recommendation

The CMS recommendation is to install Praetor on its own Windows machine which provides several advantages over installing it on the directly on your mail server:

  • Praetor can be used for older mail systems that are using Windows NT such as Exchange 5.5 and earlier, Domino R4. It can also be used for mail servers that are not based on a Windows platform such GroupWise.

  • Praetor can process significantly more messages without any impact on your Exchange or Domino server.

  • You can place Praetor outside your firewall with the comfort of knowing there are no critical resources at risk other than the normal mail server (reception) function. Praetor only needs access to your internal network to send the filtered SMTP messages to your mail server, and LDAP if you are using the PLGV web application to allow your users to review their personal quarantined messages.

  • De-couples Praetor from your mail server which allows it to continue receiving inbound messages even while the mail server is taken off-line for any preventative maintenance, back-up, software/hardware upgrades, testing, etc.

  • Allows for easy relocation of your inbound mail server by simply changing the destination IP address for your internal mail server to which Praetor sends filtered inbound messages.

Next


Installing IIS Virtual SMTP server

Installing IIS virtual SMTP and web servers

On a Windows 2000 or XP machine, you can determine if the Windows Internet Information Server (IIS) components for the Virtual SMTP and web server is installed by using the Add/Remove Program wizard from the Control Panel.

Double-click the icon and when the Add or Remove Programs window appears with the list of installed software, press the [image] button on the left. You will then be presented with the following screen showing the Windows Components Wizard.

Select the line for Internet Information Services (IIS) and press [image] button to show the Internet Information Services (IIS)window with a selectable list of its subcomponents.

At this point, scroll through the list of subcomponents. If all needed components have been installed you should see checked the lines with

  • Internet Information Services Snap-in

  • SMTP Service

  • World Wide Web Service

If any of these components do not have their checkbox is not checked, then check the box(es) and press [image]. On the Windows Component Wizard press [image] to proceed with installing these missing IIS components.

Configure the SMTP Server with your local domains


Configuring IIS Virtual SMTP server

Configuring the SMTP Server

Warning:

On its own, IBM's Domino Server, Microsoft's SMTP Server in IIS and Exchange (prior to Exchange 2003) are vulnerable to the Reverse NDR attack, which will make it into an unwitting indirect mail relay. Exchange 2003 has a different vulnerability known as the Directory Harvest attack.

You can check your vulnerability using the Reverse NDR test page on the CMS website.

To protect against this, you must populate the Approved local addresses list with all your valid local email addresses and enable the Reverse NDR rule in Praetor.

To fully configure the Virtual SMTP server you must first define your local domains and specify the IP address where messages will be delivered. Then you need to test for successful mail deliverability using these settings. This section describes how do perform these tasks.

Defining your local domains

1.

Run the Internet Information Services (IIS) manager (from Control Panel's Administrator Tools folder) to display the Default SMTP Virtual Server in the left pane and select the Domains container. Right mouse click to select New -> Domain as shown below.

2.

This will open a window for you to select the type, which should be the default Remote button.

3.

Press [image] to enter the remote SMTP domain name.

4.

Press [image] and you will be returned to the list of domain in the right pane.

5.

Next, select your newly created remote domain and right-mouse click to view its properties.

As shown above, select the checkbox to Allow incoming mail to be relayed to this domain and button Forward all mail to smart host . In the field below, enter the IP address for your receiving mail server surrounded by square brackets.

Press [image] to finish this configuration for the newly created remote domain.

If you have more domains, repeat the above steps for each remote domain. Note that it is fine if the IP addresses for all your remote domains are to the same mail server.

Note:

Some mail servers are unable to accept messages sent by the IIS SMTP Server using the Extended SMTP (ESMTP) standard, indicated by the EHLO command. Known mail servers adhering to the older SMTP standard instead of ESMTP include:

  • Microsoft Exchange v5.5 and earlier

  • Symantec Mail Security™ for SMTP, all versions as of 2004

Thus to avoid any failures when the IIS SMTP Server is attempting to deliver the filtered messages to your downstream mail server, you will need to check the box Send HELO instead of EHLO above.

In most cases, the problem stems from IIS SMTP Server trying to relay messages it receives in binary form because it advertises the ability to support 8BITMIME. You can turn this off by following the steps in this Microsoft KnowledgeBase article Q262168.

All the remote domains you created are under the single (default) SMTP virtual server, and thus the message limits set for this server will apply to all these domains. Among the global settings are limits with the following default values:

  • Per-message size limit of 4096 KB

  • Per-session (delivery) of 10240 KB

  • Per-session number of messages to 10

  • Per-message number of recipients to 100

If you want to change these values, view the properties of the SMTP virtual server and look on the Messages tab.

Press [image] to finish configuring these limits on message delivery.

Finally, stop (if running) and restart the IIS SMTP Server to make these changes take effect.

Testing mail deliverability to local domains

Once your local domains has been defined, you need to test the SMTP virtual server for deliverability to a real address at each local domain. One method to do this is to use the Microsoft Outlook Express email client to send this test message directly to this SMTP virtual server. Other email clients may also be used but this section will describe how to use Outlook Express 6 to perform this testing.

Warning:

If you are trying to test mail delivery to non-local (remote) domains on the Internet, you will need to add the IP address of the Outlook Express machine onto the IIS SMTP Server's Relay list. This is because the IIS SMTP Server is set to prevent relaying by default, and your Outlook Express testing to remote domains would appear as a relay attempt. Click here to find out how to set this up.

1.

Create a mail account in Outlook Express by selecting Tools -> Accounts.

2.

When the Internet Accounts window appears, select the Mail tab and pressing [image] .

3.

This will invoke the Internet Connection Wizard to prompt you for various pieces of information.

  • Your display name

  • Your email address

  • The incoming and outgoing mail server which is this Praetor machine's IP address. Use a fictitious IP address for the incoming mail since we are simply testing outbound SMTP directly to the Praetor machine

  • Account login and password for inbound mail retrieval

Note:

The important information to enter in the above is the IP address of the outgoing mail server. This is because the SMTP server being configured has no POP3 or IMAP server operational for retrieval of incoming mail.

As a result you will get errors when your email client attempts to retrieve incoming messages stored on the SMTP server. It cannot authenticate successfully.

This is just fine since all we are trying to do is configure the email client software to directly send test messages to the SMTP server.

4.

When completed, click [image].

5.

Compose the test message to a valid address in your domain.

Press [image] to send the message.

6.

Use your normal email client to verify that the message was properly relayed by the SMTP virtual server and sent to your specified mail server (in step 5 of setting up the new domain properties for the SMTP virtual server.)

If mail deliverability is unsuccessful, you will need to get it to work before proceeding with Praetor installation.

Testing mail deliverability to non-local domains

Before you can successfully test deliverability to non-local (remote) domains on the Internet, you will need to configure the IIS SMTP Server so that it does not see your test message from Outlook Express as a relay attempt.

To avoid this problem you will need to add the IP address of the Outlook Express machine so that it is permitted to use IIS as a mail relay. This is done via the IIS Manager by selecting the SMTP Server properties, specifically those shown on the Access tab.

Press on the [image] button and enter the IP address of the Outlook Express test machine in the field shown below.

Next


ASPNET in Windows 2003

ASPNET in Windows 2003 Server

Depending how the Windows 2003 operating system was installed, it may already have ASP.NET services. This is a critical component to allow the PLGV web application to operate properly and allow users to access their quarantined email, so it needs to be verified as being installed and running.

Even if it is already installed, you will need to verify that the web server extensions indicate that it is allowed to run on this server.

Here are the steps to perform this.

1. | Use Control Panel's Add/Remove Programs to view the list of Windows components. Press [image] to view what application servers are installed.
2. | Verify that ASP.NET is checked indicating that it was installed on this machine. If it is not checked, then check it so that it may be installed.
3. | Once ASP.NET is installed use the IIS Manager to view the ASP.NET entry under Web Service Extensions. You must verify that the status for ASP.NET is set to allow it to run. If the status shows it is prohibited, then press on the button to allow this extension to run.


Overview

Install process overview

Warning:

You should not attempt to perform the installation remotely via technologies such as Windows Remote Desktop (formerly Terminal Services) or similar remote control products. Doing so may cause the wrong security settings to be used and Praetor may function incorrectly or erratically.

Even Microsoft's own Service Pack 4 for MSDE cannot be installed using a Remote Desktop client!

Also, recording a CDR with the downloaded Praetor files will not allow you to perform the installation directly from the read-only CDR. You must copy the files onto your local drive and run the SETUP from that location.

This chapter describes the installation process for the different scenarios possible, all of which will be performed automatically by the Praetor installer. However, before the main Praetor filter can be installed, the installer will check to verify that other components are present and performs the following:

  1. Install the blank Praetor SQL databases

  2. Update the Bayesian database with the default word list

  3. Install PLGV, the Personal Log Viewer web application

This can be seen in the following initial screen.

After pressing [image] the installer then begins to check if you have the requisite Microsoft components also installed and that you are logged in with administrator privileges. Should the Praetor installer determine that you are missing either the .NET Framework v1.1 or a local SQL Server (e.g. the free Microsoft SQL Desktop Engine or MSDE), then it will download those components from the Microsoft website and install them. This can be seen in this sample screen with SQL Server missing.

To avoid this long download from within the Praetor installer, CMS strongly recommends that you have these Microsoft components already installed before attempting to install Praetor. You can find the download links here.

Note:

When upgrading from Praetor v1.5, CMS recommends that you get a new machine with Windows machine. In this way you can introduce it into your existing email stream transparently.

If you insist on installing Praetor G2 on your existing Windows 2000/XP-based Praetor v1.5 machine, you would need to:

  1. Shut down Praetor v1.5 to take it off-line so it is no longer listening for incoming email on port 25.

  2. Make sure the SMTP Virtual Server is installed and operationally receiving mail on port 25.

  3. Use MODLIST to export your lists by invoking it as follows:

    MODLIST /EXPLISTS:MyList.TXT

  4. Copy of the Praetor.DAT, PraetorScript.TXT, and MyList.TXT files to a backup location thereby preserving your rules and lists.

  5. De-install the Praetor v1.5 to prevent conflicts in Praetor's subcomponents.

  6. Install this new Praetor version in the standalone manner outlined below.

Please click on the pictured links below for your selected process.

  1. Installing Praetor on a standalone Windows machine (recommended)

    This is also applicable for Exchange v5.5 and any non-Windows 2000 based mail systems including Lotus Domino, Novell GroupWise, Sendmail, or other SMTP mail server. In this configuration Praetor can filter both inbound and outbound email.

    For a discussion why CMS recommends this, click here.

  2. Installing Praetor directly on the Exchange 2000 or 2003 server

    In this configuration Praetor can filter only inbound email.

  3. Installing Praetor directly on a Windows 2000-based Domino server

    In this configuration Praetor can filter only inbound email.

Next


Installing Praetor on a standalone Windows machine

Standalone Praetor installation

Praetor can be installed on a standalone Windows 2000 (server or professional editions) or XP (professional edition only) to filter Internet messages for any email system:

  • Lotus Domino (R4.5 and higher)

  • Microsoft Exchange (v5.5 and higher)

  • Novell GroupWise (all versions)

  • Sendmail, smail, procmail, and any other SMTP mail system

Before you attempt to install Praetor, you will need to insure that the virtual SMTP server that came with Windows is already installed by using Control Panel Services to see if the entry for the Simple Mail Transfer Protocol (SMTP) exists. If it does not exist, then you need to install it first before you attempt to install Praetor. In fact, it is imperative that you have that Windows SMTP server fully operational and passing messages into your mail server before Praetor is ever installed. This critical dependency reflects the fact that Praetor is now an extension of the native Windows SMTP server, which is a component of the Microsoft Internet Information Server (IIS).

Note:

Some firewalls allow you to place Praetor on the protected side and still have direct reception from the sending mail host. This is done by designating a tunnel for port 25 on the firewall to be dedicated to the Praetor machine.

If your firewall has its own mail receiver and simply relays messages to Praetor on the interior, then Praetor's SMTP protocol level filters will be de-activated as these tests use the connecting host's IP address. Obviously in such a situation, the connecting host is your firewall. An example of this is the DNS blacklist server which Praetor queries by using the IP address of the connecting (sending) mail server.

As mentioned in the Overview, the installation process involves insuring other Praetor components are present, installing them as necessary. Click on the links provided to read the details of installing that specific Praetor component.

1. | Install the blank Praetor SQL databases
2. | Update the Bayesian database with the default word list
3. | Install PLGV, the Personal Log Viewer web application to give your users the ability to self-release their quarantined messages.

After all of these components are successfully installed, the final step is to install Praetor filter.

Next


Installing Praetor on the same machine with Exchange 200x

Installing Praetor on the same machine with Exchange 200x Server

While there may be situations where it would be better for Praetor to be on a machine of its own, it is definitely possible to install Praetor onto the very same machine that has Microsoft Exchange 2000 or 2003 server operational.

Note:

Some firewalls allow you to place Praetor on the protected side and still have direct reception from the sending mail host. This is done by designating a tunnel for port 25 on the firewall to be dedicated to the Praetor machine.

If your firewall has its own mail receiver and simply relays messages to Praetor on the interior, then Praetor's SMTP protocol level filters will be de-activated as these tests use the connecting host's IP address. Obviously in such a situation, the connecting host is your firewall. An example of this is the DNS blacklist server which Praetor queries by using the IP address of the connecting (sending) mail server.

As mentioned in the Overview, the installation process involves insuring other Praetor components are present, installing them as necessary. Click on the links provided to read the details of installing that specific Praetor component.

1. | Install the blank Praetor SQL databases
2. | Update the Bayesian database with the default word list
3. | Install PLGV, the Personal Log Viewer web application to give your users the ability to self-release their quarantined messages.

After all of these components are successfully installed, the final step is to install Praetor filter.

Next


How to install Praetor with Exchange v5.5

Installing with Exchange v5.5

This second generation (G2) of Praetor was developed with Exchange 200x in mind and not the older v5.x as was the case with the Praetor v1.5 that G2 replaces. In spite of this, Praetor will work to filter email for Exchange v5.5 by installing it onto a standalone Windows 2000 or XP machine.

Once installed and Praetor G2 has been configured, there are two items to note.

1.

The Internet Mail Service (IMS) of Exchange v5.5 does not have 8BITMIME support which allows for transmission of 8-bit data. Praetor G2 uses IIS SMTP server which does support this feature by default so you will need to disable this in IIS. Without 8BITMIME disabled, your Exchange v5.5 will not be able to receive messages from Praetor G2.

Read the Microsoft Knowledge Base article #262168 with instructions on how to disable this in IIS SMTP Server used by Praetor G2.

2.

While Praetor G2 is ready to begin filtering inbound mail items from the Internet, your Exchange 5.5 server sends outbound mail directly so Praetor will not see that traffic. In order to enable Praetor to filter outbound messages, it is necessary to re-route all outgoing mail back to Praetor. This is accomplished in the Microsoft Exchange Admin program under the Internet Mail Service Tab called Connections.

Next


Installing Praetor on the same machine with Domino SMTP

Installing Praetor on the same machine with Domino SMTP Server

Praetor can be installed on the very same machine as the Domino server but only if that platform is using Windows 2000 or 2003 server. If your Domino server uses a different Windows platform, then you will need to install Praetor on a standalone machine.

Normal SMTP message transfer occurs using the TCP/IP SMTP standard port 25. When Praetor is co-resident on the same machine with the Domino server, it will be necessary to change the SMTP MTA to let Praetor become the message receiver. Only when Praetor determines the message is acceptable will it be transferred to the SMTP MTA. Thus it becomes necessary to reconfigure the normal receiving port used by Domino, changing it from port 25 to 28.

You can read to see how this is done using the Domino administration program.

Note:

Some firewalls allow you to place Praetor on the protected side and still have direct reception from the sending mail host. This is done by designating a tunnel for port 25 on the firewall to be dedicated to the Praetor machine.

If your firewall has its own mail receiver and simply relays messages to Praetor on the interior, then Praetor's SMTP protocol level filters will be de-activated as these tests use the connecting host's IP address. Obviously in such a situation, the connecting host is your firewall. An example of this is the DNS blacklist server which Praetor queries by using the IP address of the connecting (sending) mail server.

Before you attempt to install Praetor, you will need to insure that the virtual SMTP server that came with Windows is already installed by using Control Panel Services to see if the entry for the Simple Mail Transfer Protocol (SMTP) exists. If it does not exist, then you need to install it first before you attempt to install Praetor. In fact, it is imperative that you have that Windows SMTP server fully operational and passing messages into your mail server before Praetor is ever installed. This critical dependency reflects the fact that Praetor is now an extension of the native Windows SMTP server, which is a component of the Microsoft Internet Information Server (IIS).

As mentioned in the Overview, the installation process involves insuring other Praetor components are present, installing them as necessary. Click on the links provided to read the details of installing that specific Praetor component.

1. | Install the blank Praetor SQL databases
2. | Update the Bayesian database with the default word list
3. | Install PLGV, the Personal Log Viewer web application to give your users the ability to self-release their quarantined messages.

After all of these components are successfully installed, the final step is to install Praetor filter.

Note:

Don't forget to change the SMTP port that the Domino SMTP server is using from the standard 25 to 28. After this configuration change is made, you need to stop and restart the SMTP MTA in order to have this port change take effect.

When Praetor starts, it is set to begin filtering inbound mail items from the Internet. In order to enable filtering for outbound messages, it is necessary to configure Domino to re-route all outgoing mail back to Praetor. Click here to see how this is accomplished in the Domino administration program.

Next


Upgrading Praetor

Note:

This page is only valid for an existing Praetor v2.0 installation.

If you are trying to upgrade from the older Praetor v1.5, then CMS recommends that you get a new Windows machine. In this way you can introduce Praetor into your existing email stream transparently and without disrupting your mail traffic.

Please read the following:

  • Differences between Praetor v1.5 and v2.x

  • Praetor v2.x equipment recommendations to cope with the numerically intensive Bayesian statistical filtering in Praetor v2.x

Upgrading from Praetor v2.0 to this latest release is simple — just use the supplied installer and it detects your installation and preserves the settings for restoration after upgrading. Your log and Bayesian token database will remain with new stored procedures added.

When you run the installer it will check your installation to determine which components need to be updated before upgrading Praetor's filtering. You will see a screen that lists all the components that need to be upgraded, as shown below.

Press [image] to proceed.

You will see the install welcome screen for the Praetor components, PLGV and the G2 filter, such as that shown below for the filter.

Return


Overview

Configuring Praetor

This chapter provides step-by-step instructions for using the Microsoft Management Console (MMC) administration snap-in program to set the parameters that control Praetor. This snap-in can be conveniently invoked using the shortcut provided in the CMS Praetor G2 program group under the Windows Start button.

When you start it for the very first time, you will see the welcome screen below with the collapsed view in the left pane. Expanding the left pane to display the branches and leaf nodes, you will see the following screen.

Click on links to jump to that topic

Administration welcome screen

(Like all MMC snap-ins, subsequent invocations will show the left pane as you left it, highlighting your last selection.)

Note:

The Praetor administration program screens you see in this chapter of the online manual such as the one above contains many hyperlinks to their appropriate pages. Your cursor will change as you hover over these links and pressing on any of them will jump directly to those pages.

The various topics discussed in this section are:

Topic

Purpose

Text lists

Review the various text lists used by Praetor filtering, typically at the message level.

IP Lists

Review the various IP address lists used by Praetor filtering, typically at the SMTP protocol level.

Bayesian Filter

Statistical filtering technique to discriminate the spam from good messages.

Inbound conditional rules
Outbound conditional rules
Bidirectional conditional rules

Review the condition-based rules that are applied to inbound or outbound messages or both.

Inbound global rules
Outbound global rules
Bidirectional global rules

Review the rules without conditions that are applied to inbound or outbound messages or both. Useful for globally archiving messages or adding disclaimers.

Rule templates

Review the available templates from which new rules can be quickly created and modified to your specific requirement.

Rule script

View the Praetor script generated from all the enabled rules.

Heuristic filter

Configure the heuristic analyzer.

Message logs

Current events

Find

Review the current (real-time) message log.

Search the log by creating static reports based on your criteria with sortable columns.

Protocol logs

(Not shown)

This node is normally hidden because enabling the protocol DNS Blacklist capability is vulnerable to a denial-of-service attack. This feature can, however, be enabled with help from CMS Technical Support.

When the DNS Blacklist capability is enabled, this node will appear in the left pan and allows review of the current (real-time) SMTP protocol log.

Configure SPAM filters

Configure the various techniques for spam filtering.

Configure DNS Blacklist

Configure the DNS Blacklist servers that Praetor will use to test the connecting IP address.

Configure Local Domains

Configure the domain names that Praetor will treat as local. This is used to determine the inbound/outbound direction of messages being filtered.

View License Information

View the license of your installed Praetor.

CMS on the web

View the CMS website.

There are other relevant topics in this section pertaining to configuring the Windows virtual SMTP server used by Praetor G2.

  • SMTP protocol level IP address and domain filtering

  • Relay filtering

If you are trying to perform a quick configuration of Praetor for the first time, you should review the various default settings on each of the configuration screens accessible via the links in the above table or the active links embedded in the figure above. This is especially true for the various lists used by Praetor's message-level filtering rules.

Note

Praetor G2 differences from previous version 1.5

Many of the SMTP protocol filtering capabilities found in the previous version (IP, relay, domain, sender address) are no longer part of Praetor. This is simply because the previous version included its own SMTP server, whereas now Praetor relies upon the native virtual SMTP server that is part of the Windows OS or part of Microsoft Exchange 200x server. Thus much of these controls are performed via administration interfaces of Internet Information Services or Exchange.

Remote administration

While individual local users can remotely view the Praetor log and take action on their personal quarantined messages, this is separate from actual remote administration of Praetor itself. To perform this remote administration you may consider the following alternatives.

  • Windows Terminal Services for internal use or via VPN for external access

  • Other commercial remote control product such as pcAnywhere, etc.


Configure Spam Filters

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:

  1. Since the message is actually received, it now becomes possible for more information to be logged. So in addition to the source IP address of the message Praetor will now log the sender address, intended recipient address, and subject.

  2. It is no longer necessary to make Praetor to be the first SMTP server to receive the external message in order to use DNSBL. This is because the connecting IP address is not taken from the actual session but from the received message headers. Just populate a special IP list with IP addresses of all your interior SMTP servers upstream from Praetor and the correct external IP address can be identified to use in the DNSBL query.

  3. You can decide to quarantine instead of reject the DNSBL filtered messages. This would be useful if you suspect a trading partner is on a DNSBL. Once quarantined, the message can be approved.

    CMS suggests you do this temporarily to avoid the accumulation of too many message files in the Praetor QUAR folder on the hard drive.

  4. You can add other optional actions such as archiving spam samples for occassional re-training of the Bayesian filters.

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.

BASIC: Pre-configured Rule Filter

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.

ADVANCED: Configurable Rule Filter

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.


DNS Blackhole List

Configure DNS Blacklist

A DNS blackhole list (DNSBL) is an actively maintained DNS server with a database of IP addresses associated with Internet mail servers. These mail servers got into the database because of one or more spam-related criteria, e.g. known open relay, dial-up IPs used by spammers, etc. This window allows you to add these blacklist servers to Praetor.

Press the Add button to enter the domain name for the DNS blacklist server. Using these DNSBL servers, Praetor will perform a DNS query on every connection attempt it receives from a sending mail server to see if the IP address associated with the connecting session is found in the database. If the IP address is listed, Praetor can refuse the connection attempt at the protocol level (not recommended for this reason) or reject at the message level (default).

While you may list multiple DNSBL servers, keep in mind that multiple queries may slow Praetor's mail processing, either the message reception itself (protocol level) or the message filtering (message level). Thus CMS recommends and the administration program will permit no more than two DNSBL servers be checked.

Note:

If you want to use more than two DNSBL servers, it is best to have your own DNS server participate in the zone transfers of blacklist data. By doing this, you will set Praetor to query that local DNS server at much faster LAN speeds, and since it is being used exclusively by your Praetor that is querying only once for each IP address, the response times will be extremely fast.

Protocol vs Message Level DNSBL testing

CMS has found in early 2005 that spammers have changed tactics making SMTP protocol level DNSBL testing susceptible to a denial-of-service attack. This susceptibility makes other competing products dangerous to use. Praetor G2 may be the first product to offer DNSBL testing at the message level (set as the default starting in v2.1), and the dangerous protocol level testing can be switched on by contacting CMS Technical Support.

This choice is mutually-exclusive and can be summarized as follows:

  • SMTP protocol:

Using the connecting IP address, Praetor performs the DNSBL query even before a session is established. If found on the DNSBL, the connection is refused and terminated. Thus the message is never received.

When such a refusal occurs, only basic information such as the connecting IP address and any information reported by the DNSBL is actually logged as a protocol event.

  • Message:

If you don't filter at the SMTP protocol level, then the message can be received and Praetor allows you to create rules to perform the DNSBL filtering using the recorded IP address found in the received header lines of the message. Naturally this DNSBL rule must be enabled.

Based upon the response from the DNSBL, you may determine different actions for Praetor to take, giving you much greater control. For example, you may decide that if the response indicates the IP found in the server's database, then you may quarantine (default) the message instead of rejecting it. In this way, it is possible to 'reclaim' the message and release it for delivery to the recipients' mailbox.

Note:

This message level DNSBL test is especially useful for Bayesian training purposes. If Praetor is set to capture messages for training, those that were to be rejected based on being sent by a blacklisted mail server will automatically be tagged as queued for training. In this way you won't need to examine these messages to verify correct classification as spam since these messages are extremely likely to be sent from a spammer.

From experience with the earlier version of Praetor, we learned that using the protocol level testing is difficult to identify partner mail servers that happen to be blacklisted by the DNSBL server. The logged entries only save the connecting IP address without any domain name. In contrast to this, the message level DNSBL test allows us to examine the quarantined message and find the sender who is in the trading partner's domain.

Here are some comparison points for you to consider.

Criterion | Protocol level | Message level
Connectivity requirement? | Praetor must receive the message directly from the sending mail server | Praetor can be downstream from the point of entry (more info)
Message actually received? | No since the IP session is closed immediately | Yes
Can blacklisted messages be approved and delivered? | No | Yes
Saves on disk storage? | Yes since the message is not received | No since the message is received and likely to be quarantined
Discovery of valid correspondents whose mail server is blacklisted? | Difficult since protocol log entries only have IP addresses and no domain information | Simple since the quarantined message is available for review to identify the domain associated with the blacklisted IP address

Based upon these factors and the fact that disk storage costs are falling, CMS recommends the use of message level DNSBL testing over the protocol level.

Warning:

Using message level DNSBL testing and choosing the (default) action to quarantine the message will mean messages will accumulate very quickly in the Quar folder. You will need to monitor the number of message files in the quarantine folder since this will impact performance due to limitations in the Windows OS. With 512MB of RAM, Windows gets bogged down when there are more than 40,000 message files in the Quar folder.

You should take advantage of the PURGEQUAR tool to age and delete old quarantined message files.

DNSBL Bypass List

Sometimes you discover that a trading partner has been blacklisted on your specified DNSBL servers. If this happens use the DNSBL Bypass List so that Praetor will ignore the negative report and allow messages from your partner to get past the DNSBL test.

Note:

Although DNSBL may be bypassed using this list, messages will still be tested by your enabled message level rules.


IP lists

The IP Lists node shows the available system-level IP address lists in Praetor whose details are explained below.

List name

Description

DNS Blacklist Bypass IP List

This is a list of IP addresses that are exceptions to the DNS blackhole list. It is used to allow those trading partners that have been blacklisted by the servers you specified here.

Received Header Line Ignored IP List

This is a list of local and internal mail servers that may have handled the message before it is received by Praetor. It is used to identify the first originating IP address outside of the local network that is found in the Received header line of the message which cannot be forged by the spammer since it is recorded by a mail server in your network.

This external IP address is the source of the message when transferred to your domain, and Praetor will use it to query the DNSBL at the message level.

If you double-click on any IP list, you will be presented with a screen as the empty one shown below.

For more discussion on Praetor lists, click here, including how to import entries.

IP lists handle by IIS SMTP Sever

There are other IP address lists that used to be handled by the earlier Praetor v1.5 when it included the SMTP server. These are the white and black IP lists and allowed mail relays. Since Praetor G2 is now dependent upon the IIS SMTP Virtual Server included with Windows, these IP lists are administered via the IIS Manager or the Exchange server administration, as shown below. View the Access tab page and you will find the Connection or Relay control buttons.

Return to overview


Text lists

When you highlight this leaf node in the left pane the right pane will display a master directory of all available text string lists used by Praetor in various rules, as shown above for the ADVANCED setting of the spam filter configuration. The BASIC spam filter setting shows only an abbreviated version for those text lists that are used in the pre-configured rule filters.

You may directly manage any list by selecting a list in the right pane and double-clicking on it and the list edit window will appear as shown below.

The alternative to managing the list is via opening the rule that uses the particular list and clicking on the link to open the list manager window.

Note:

Praetor list changes will take place immediately after you make them and it will start filtering with any message that arrives after your change. There is no need to stop and restart Praetor or the IIS SMTP virtual server.

Starting with Praetor G2, the ADVANCED spam filter setting provides the ability to create your own user lists. These user lists can then be used in your rule by using the custom condition that allows the selection of what message header field to test with your user list.

For more discussion on Praetor lists, click here, including how to import entries.


Bayesian Statistical Filtering

Introduction

The technique using Bayesian statistics was first publicly proposed by Paul Graham in his August 2002 paper A Plan for Spam. The basic idea is to attempt classifying email into spam or non-spam (also called "ham") by breaking down the email into components he calls tokens - words, IP addresses, and other significant features in the email, and then comparing those tokens with a database. This database is simply a frequency table that counts how often any token has been seen in spam and ham.

Let us take a quantitative example with the word "cash". If the database of experiences indicates that we found this word a total of 200 out of 1000 spams and only 3 times out of 500 hams, then the ratio of spam to total occurrences is:

spam ratio P =

(200/1000)
------------------------------- =
(3/500 + 200/1000)

0.200
----------------------- =
0.006 + 0.200

0.971

Now imagine you did this for all N tokens seen in the message under review, and computed the ratios P1 ... Pn. Using naive Bayesian statistics you can compute an overall probability that the message is spam using the following equation:

spam probability =

P1 P2 ... Pn
--------------------------------------------------------------------
P1 P2 ... Pn + (1 - P1)(1 - P2) ... (1 - Pn)

While simplistic, this overview summarizes what was originally proposed by Graham. From this historical reference the technique has been further optimized to:

  • speed up the many calculations needed

  • improve the spam-versus-ham discrimination

  • reduce false positives, which are ham incorrectly identified as spam

Pre-configured token database

Praetor is installed with a default token database trained from several thousand samples with 85% being spam. Thus you do not need to perform any initial bulk training, rather, you can perform subsequent training from this default starting point. Since there are already plenty of examples of spam, you should concentrate your efforts on training the false positives — good messages that were caught as spam or unsure.

(If you were using Praetor v1.5, please note that all our test sites have found that the Bayesian filtering method does a far better job than the many rules used previously. Even better, there was less administration to tweak the rules.)

To check if Bayesian filtering is being performed via the system filters check on the spam control screen as shown below.

If the BASIC pre-configured rule filter is checked, then verify that Bayesian classifying is enabled (default) by checking on the Classify tab page.

At times when you want to capture some samples of spam for further training, you may want to enable the checkbox to save any message that is classified as Unsure, i.e. those whose "spamicity" or spam probability is between the two cut-off values on the Options tab page (default range is between 0.30 and 0.60). If such "unsure" messages are saved, then they will appear in the [image] category in the [image] node so that you may review them and queue them for training as good or bad samples. Click here to read how periodic incremental training is performed.

Warning:

Saving Unsure messages should be done sparingly as it can cause many message files to be captured which can slow down the Windows operating system. Depending on how much email traffic your site receives, you should do this only for brief periods.


Bayesian Training

Note:

You do not have to constantly train the Bayesian filter. Incremental training is suggested periodically and only on the errors:

  1. Good messages that are quarantined (false positives), and

  2. Spam that is rated as unsure and accepted (false negatives).

Doing this will improve the spam detection accuracy and reduce falsely classified good messages that the Bayesian filter considers as spam (false positives). When you first install and use Praetor, if you find the spam detection rate satisfactory and false positives sufficiently low, you will not need to perform any training whatsoever.

If you do any training, keep in mind that:

  1. You should not train on spam already caught because it has a high spamicity or non-spam already accepted because it has a low spamicity. To train on these is pointless since you are only trying to raise or lower the spamicity when messages are already rated higher than the spam threshold or lower than the non-spam threshold. Besides, with a larger Bayesian token database, more resources are needed to make the many more statistical computations and will only slow down filtering.

  2. Your objective is to have approximately equal numbers of spam and non-spam messages trained. As you can see, the default Bayesian token database has 7x more spam than non-spam samples trained.

More training tips can be found in this FAQ.

The optional checkboxes shown above for automatically saving training samples were designed to capture samples if you were to clear the default Bayesian token database supplied with your Praetor installation. CMS does not recommend using these checkboxes for incremental training purposes. Incremental training should only be performed only on Bayesian classification errors: non-spam that are quarantined and spam that are rated as unsure.

As supplied, Praetor includes a default Bayesian token database obtained from training on several thousand samples, which you can see in the Already Trained groupbox in the above screen image. Thus initial training is not a necessary step to begin using Bayesian filtering. CMS periodically tests this default token database by submitting spam samples that would normally be rejected by DNS Blacklists, and we find that the Bayesian filter will catch >90% of these received spam samples.

Nevertheless our default token database may still cause the Bayesian filter to allow a few messages to get improperly classified. Especially important are the good messages that get quarantined (called "false positives") and spam that is accepted because it was rated as unsure (called "false negatives") . By periodically retraining on these Bayesian classification errors you can get the filter to be even more accurate for both good and bad messages, increasing the spam detection rate while lowering the false positives and false negatives.

This section discusses:

  • Message samples to train

  • Training the good messages classified as spam by the Bayesian filter

  • Training the spam caught by heuristic or rules instead of Bayesian filter

  • Performing the training

If for some special reason you want to perform initial training from a completely blank token database, then it would be best if you first contact CMS to discuss this need. This would be an extremely unusual situation that you need to start from a blank database. You can read about the process by clicking here.

For more tips on training your Bayesian filter, view this FAQ.

Message samples to train

The default token database already includes far many more spam than good message samples so CMS recommends that you focus your effort on training Praetor with the following types of messages.

  1. False positives which are good messages that get quarantined as spam either by the Bayesian or heuristic filters.

  2. False negatives which are spam messages that are not caught because the Bayesian filter classified them as unsure.

Keep in mind that, if those false positives are messages coming from listservers (e.g. airline promotions, newsletters, joke-of-the-day, etc.) you should just add the listserver addresses to the approved listserver list and avoid Bayesian classification altogether. Messages from listservers tend to have characteristics that are spam-like so training these as good message samples would only 'dirty' the token database and make the Bayesian filter less accurate. Thus, it is a bad idea to train messages from listservers.

Note:

Some listserver addresses may contain variable information to the left of the @-sign. This tab page is only visible if you have selected the BASIC pre-configured filters on the Configure Spam Filters page. It does not apply to the ADVANCED selection since you have full control via the configurable rules.

The two main message types listed above are trained in slightly different ways by the administrator because of the difference in how frequently they are captured. In both cases, the administrator must verify the improper classification by the Bayesian filter and queue for training as spam or non-spam. Users do not have this opportunity because of the risk in poisoning the token database that would render it less useful in properly discriminating spam.

Training good messages classified as spam by the Bayesian filter

Praetor provides a novel method for training messages that the Bayesian filter improperly classified as spam — use those messages that have been reviewed and then released by the administrator(s). This is performed by using the Praetor administrator console selectively reviewing the quarantined messages listed in the Current Events view of the Message Logs, a facility we call the Log Viewer.

When the message details are shown and you have determined this is a good message, press [image] to update the token database with this message sample before pressing [image] to release the message from quarantine.

Training spam caught by heuristics or rules instead of Bayesian filter

Praetor can be configured to save all messages classified as UNSURE by the Bayesian filter.

If the option to save the UNSURE is checked, then you will find the captured UNSURE messages listed in the Praetor administration program when selecting the [image] node for [image]. It is best to sort on the Rule (second) column by clicking on this column as shown below.

It is likely that you can quickly determine if a message is spam simply by looking at the From or Subject columns. Once you have verified the proper classification for a group of messages, highlight the group and right-mouse click to select to queue for training either as GOOD (non-spam) or BAD (spam).

In this list of UNSURE messages, you will also find those that were rejected by the DNSBL but found to be UNSURE nonetheless. It is not necessary to queue to train these as BAD samples since they are already caught by the DNSBL. If you do train them, however, it would allow the Bayesian filter to improve itself in the event you decided to disable DNSBL.

Here are some suggestions whether or not to train for other rules that may have caught messages listed as UNSURE. Note that the name may be slightly differently than those listed, but they convey the same idea.

Rule capturing the unsure message | Train | Don't Train
Heuristics | X |
DNS Blacklist |  | X
Spamicity is UNSURE | X |
Reverse NDR |  | X
Approved domains, senders, listservers |  | X

Warning:

If you enable this option to save the UNSURE message, your free disk space will be consumed at a faster rate than normal. CMS recommends that you enable it for only a short period when you want to capture samples for training the Bayesian filter.

Performing the training

When you choose to queue for training, this will simply mark that message for later training using the training wizard. As a result, this choice will move the message entry from the [image] node of [image] to the to the [image] node for either [image] or [image] as appropriate.

Next you will run the training wizard so that these queued [image] messages are analyzed and the Bayesian token database is updated.

Pressing [image] displays the review window allowing you to select which class you want to train -- GOOD, BAD, or both.

Note the numbers shown for training are those found in the [image] state for both GOOD and BAD. Press [image] to begin the training.

Warning:

CMS does not recommend performing bulk training during the business day. The reason this is unwise is that the number of simultaneous accesses to the MSDE SQL Server will likely exceed the limit of 8 and this will cause its workload governor to get engaged. This governor will slow both Bayesian classification of incoming messages and the training.

The training process consists of processing each message to break it down into its component tokens and accumulating them.

After this collection is done, the token database is updated with the addition of new tokens that are found in the training samples.

Depending on how many messages you train, how many tokens are found, and how busy the Praetor machine is, the training process may take some time and a significant amount of CPU resources. Therefore it is a good idea to perform this training during a period when the machine is not busy.

The counter in the above display is only updated periodically so that resources are not wasted for display.

Once the initial bulk training is completed, all the messages once listed as [image] will now be found in the [image] archive list for the GOOD and BAD nodes. You can always check how many messages have been trained thus far by viewing the Train tab page of the Bayesian configuration.

To begin using the Bayesian filter to classify your messages, you will need to make the setting change from training on this page.

Note:

Once training has been performed, the message samples will remain in the TrainBAD or TrainGOOD physical folders on the disk indefinitely. The reason for leaving these message samples is to allow you to re-use them in future initial training after resetting (emptying) the token database. If you want, you may delete these files by using the administration program and highlighting all entries in [image] for the [image] and/or [image] and then right-mouse click and choose to delete them.


Bayesian Classify

Bayesian Classifying (BASIC Only)

Note:

This tab page is only visible if you have selected the BASIC pre-configured filters on the Configure Spam Filters page. It does not apply to the ADVANCED selection since you have full control via the configurable rules.

In the BASIC level, Praetor will perform the Bayesian classification on your inbound messages and act upon them based upon what spam probability index, or spamicity, is computed. It is here that you can specify what actions will be taken, along with other options described below.

  • Observe message size limits

Since spam is usually rather small in size, this setting and the corresponding limit value will prevent the Bayesian analysis to be attempted on messages exceeding this size limit. This will help performance by skipping large messages since those will contain many tokens and require a lot of needless probability computations.

  • Spam Message Options

You need to choose what action will be performed should the Bayesian method detect that the message is spam, i.e. when the computed spamicity value equals or exceeds the "Bad mail cut-off value" (default 0.60). As seen above you may chose from one of two possible actions:

    1. Quarantine the message and allow it to be released either by the administrator or recipient.

    2. Reject the message and delete it.

All messages with a spamicity value between the good and bad mail cut-off values will be deemed as unsure and accepted for delivery to the intended recipient. Additionally such message will have a message header line inserted as follows:

X-Spamicity: Unsure; spamicity=######

where ###### is the value for the computed spam probability index.

  • Unsure Message Option

Bayesian unsure messages are those whose computed spamicity value is between the two cut-off values with the default values being 0.30 to 0.60. Since these messages are delivered to the intended local recipients, you would not normally have a chance to train on the missed spam. As an aid for periodic Bayesian training you can enable this option to capture all those Unsure messages and place them in [image] folder.

Note:

If you choose to enable this option, please note that your free disk space will be consumed at a faster rate than normal. If you have too many sample messages being saved, Praetor's performance will suffer due to Windows becoming sluggish with file operations.

CMS suggests that you enable this only for a short period, and then perform the review and training.

Press [image] to save these settings and put them into effect immediately.


Local Domains

Configure Local Domains

Use this window to set up Praetor for multiple local domains for your site. Praetor uses this information to determine the direction of the messages. Should there be one recipient of the message found with a domain that matches the entries in the local domain list, then that message is considered to be inbound; otherwise the message is considered to be outbound. Based on the direction, the appropriate rules will be used to filter the message.

While you can certainly add entries here manually, as a native extension of the Windows virtual SMTP server CMS recommends that you add the local domain within Internet Services Manager as a new remote entry. Once added, simply pressing [image] above will re-sync Praetor to all the local domains that exist.

Note: Praetor co-resident with Exchange 200x

If Praetor is installed on the Exchange 200x server, you can add new domains via the Recipient Policies property page as shown below.

Once added, simply press [image] above to re-sync Praetor to all the local domains that exist in the Exchange server.


Rules Filtering

Rules Filtering (ADVANCED only)

Note:

This facility only appears if you have selected the Advanced Configurable Rule Filter. It does not appear if you have selected the Basic Pre-configured Rule Filter.

This is the main control page for all the rules you can create in Praetor. From here, the links are provided to create new rules, both conditional and global, based on the different message directions. You can also import rules from the periodic updates you receive via email from CMS that contain additional capabilities to deal with new spamming techniques.

Note:

For outbound rules, if Praetor is installed directly onto an Exchange 200x server, it will never see the outbound SMTP message. This is true even if you try to configure Exchange to deliver to itself by declaring its own IP address as the smarthost for all outbound mail. The reason for this is because Exchange 200x detects that the IP address specified is its own address, and therefore bypasses it to deliver directly to the receiving mailhost. In this way it prevents a message loop.

The only way to allow Praetor to perform outbound mail filtering for Exchange 220x is to install it onto a separate machine. Then your smarthost setup will work as expected.

To view the list of all existing rules simply select the appropriate node in the tree structure you see in the left pane. The right pane will then show the available rules, which are listed in the order by which they will be performed, with the top-most rule being performed first.

Note:

As supplied, these default rules simulate the preset and system internal Bayesian and pre-filter rules. If you want to manipulate the order of these default rules, keep in mind that your enable rule order will only be recognized if you disable the preset "Bayesian Filtering" on this page, relying instead on the user rules that test the Bayesian spamicity values as seen above.

Also two default rules near the very top of the list deal with attachments. One rule will reject messages with banned attachments known to be virus infections and the second rule deals with quarantining suspicious attachments. It is this second rule that has protected all Praetor customers from email-borne virus infections without the need to wait for any updates. CMS highly recommends that you leave these two rules active and positioned near the top of the list.

Many of the default inbound conditional rules deal with spam and they are enabled as you can see above. One in particular deals with a new spamming technique we call a "Reverse NDR" attack. The rule to defend against this is left disabled so that you can populate the list of local user addresses. This attack essentially turns your mail server into an indirect mail relay. Spammers have found that most mail servers are immune for a direct attempt to relay mail, but they are vulnerable to this indirect relay attack, most especially Exchange and Domino. Read how to set up Praetor to defend against this attack.

You may deactivate any default enabled inbound conditional rules. We do suggest, however, that you continue to quarantine those messages until you have some experience with what messages these rules will trap. Do not change the primary action from quarantine to reject until you are familiar with what messages might get trapped.

If you find too many messages are getting quarantined, perhaps you might want to let your users decide for themselves. This can be done if you are using Microsoft Exchange server and the users have the Outlook desktop client. Read this FAQ to learn how this is set up.

Positioning your rules

If you select on any rule in the right pane and press the right-mouse button, a menu will appear to give you several options on making rule changes. Also notice the appearance of additional icons on the toolbar at the top of the window when a rule has been selected in the right pane.

Icon | Menu item | Description
 | New Rule ... | Create a new rule in the same direction and the same type, conditional or global, as the others in the list.
 | Save changes | Save any changes you made so that they take effect immediately.
 | Move down | Move the selected rule down in the list so that it is performed by Praetor after other rules above it.
 | Move up | Move the selected rule up in the list so that it is performed by Praetor before other rules below it.
- | Enable / Disable | Enable or disable the selected rule(s).
 | Delete | Delete the selected rule. An alternative is to simply uncheck the rule so that it is de-activated and not used by Praetor.
 | Properties | Open the rule to change any of the conditions, exceptions, or actions of the selected rule. If you want to change or add new word criteria, you can easily do this by clicking on the appropriate entry in the lower window containing the rule description details.
 | Help | Open the online help manual.

For a discussion on rule ordering and its importance in the optimal performance of Praetor, click here.

Note:

Unlike changes to lists which take effect immediately, Praetor rule additions, changes in position, enable/disable, etc. only take effect after you press the [image] Save button on the toolbar. You do not need to stop or restart Praetor or the IIS SMTP virtual server.

Return to Configuring Praetor


Adding keywords to an existing rule

Adding new keyword entries to an existing rule is very simple. From the appropriate rule list, global or conditional type and a direction, double-click on the specific rule to open a dialog box with rule components organized in separate tab pages.

The tabbed interface allows you quick access to modify any component of your rule: conditions, actions, and exceptions. For the purposes of adding new entries, it is sufficient to simply view the General tab page and click on the blue underlined phrase to open a data entry window.

Type your new entry and press [image] or the Enter key. Do this for all your new entries and press [image] when you are finished. Your entries will now appear in the details of the rule description lower window.

Note:

Unlike the original Praetor, this G2 series puts your modified entries into effect the moment you press [image]. There is no longer any need to stop and re-start the Praetor G2 service.

For more information about modifying rules, click here.

Return to Rules Filtering


Creating a new rule

The process of creating a new rule is facilitated by a wizard that is started by highlighting the specific type of rule in the left pane, conditional or global, and then clicking the right mouse button. The difference between these two rule types is that the global rule has no condition(s) to test and so they will always run based on the direction of the message.

Conditional rule example

Upon invoking the Rule Wizard to create a new condition rule, you will start by selecting the condition(s) by checking the appropriate box(es).

List of available conditions

Once selected, the condition(s) will appear in the lower Rule Description window containing the details. Any required input will be shown by a phrase that is underlined and blue in color; clicking on it will present a user interface for data entry. You may provide the needed entries right away or wait until the rule is fully created.

Select the conditions

Press [image] to proceed with selection of the rule action(s).

List of available actions

Press [image] to proceed with selection of any exceptions. If you have exceptions that require data entry, like the conditions, you will see an underlined phrase that upon clicking will open an appropriate user interface.

List of available exceptions

Press [image] to proceed to name and enable the completed rule.

Naming the new rule

Press [image] to save your newly created rule.

Note:

As you can see, your newly created conditional rule will be positioned at the very bottom of the rule list. You must keep the "Spamicity is unsure" rule as the very last rule, so use the [image] and [image] icons on the toolbar to reposition it so that Praetor will perform the rule in the desired sequence. Without repositioning above the unsure spamicity rule, your new rule will never get a chance to run.

When you are done, press the [image] icon to save the rules with this new addition.

In this example no keyword entries were made for the banned subject text. To illustrate the method in which you may modify rules with new entries, let us now add keyword entries to this existing rule.

Return to Rules Filtering


Modifying a rule

The process of modifying an existing rule is started by double-clicking any rule listed in the left pane of the Praetor administration program.

From this General tab page, you may change the rule name, choose to enable/disable it, or provide additional entries where provided in the lower Rule Description window. You can also jump directly to any particular component that make up the rule:

  • Conditions

  • Actions

  • Exceptions

Changing rule conditions

Click on the ConditionS tab to jump directly to the list of conditions. On this page you may change the one currently selected or add more conditions. Your choices will be reflected in the lower Rule Description window and any needed entries can be provided by clicking on the phrases you see underlined and in blue.

When you are done, press [image] and your changes will take effect immediately.

Changing rule actions

Click on the ACTIONS tab to jump directly to the list of actions. On this page you may change your primary action or select additional optional actions. These changes will be reflected in the lower Rule Description window, and clicking on a blue underlined phrase allows you to provide information needed by those actions.

When you are done, press [image] and your changes will take effect immediately.

Changing rule exceptions

Click on the EXCEPTIONS tab to jump directly to the list of exceptions. On this page you may change any selected exceptions or add more exceptions. These changes will be reflected in the lower Rule Description window, and clicking on a blue underlined phrase allows you to provide information needed by those exceptions.

When you are done, press [image] and your changes will take effect immediately.

Note:

In Praetor G2 once you press [image] your changes take effect immediately with the very next message. There is no need to stop and re-start the Praetor G2 service.

Return to Rules Filtering


Heuristic Filter

Heuristic Filter (Advanced only)

Note:

This facility only appears if you have selected the Advanced Configurable Rule Filter. It does not appear if you have selected the Basic Pre-configured Rule Filter.

Starting with Praetor G2, a new technique was introduced to score a message based upon heuristics. This form of filtering scores a message based on the presence of certain enabled characteristics, each of which is given a weight. This method gives you a way to set spam detection to look for one or more spamming technique(s).

For single-factor characteristics which are indicated with a value of 1 in the Factor column, the very presence within the message will add the specified weight to the score. It does not matter how many times the characteristic is found in the message and only the weight value will be added to the score.

Multiple factor characteristics are indicated with a value of Multiple in the Factor column. It is different from the single factor type because the frequency found in the message is significant. In this case, the value added to the overall score will be the weight multiplied by the frequency.

If you double-click on any characteristic, you will be presented with a screen to change the weight and enable/disable it as part of the testing.

To change the value, either enter a value in the weight field or move the slider bar.

To enable or disable this characteristic from being included in the heuristic tests, check the box accordingly.

The Multiple Factor is informational only.

The heuristic filter is used by creating a condition that provides a score threshold.

Click here to read more about this condition.

Return to Configuring Praetor


View License

View License Information

By default Praetor installs as a 21-day evaluation copy. You can see this when you click on the View License Information link in the right pane as shown below.

The license information will then be shown on the License tab.

This page will show when your evaluation period will expire. At expiration, messages will still flow properly but Praetor will no longer filter them. For more information about licensing, click here.


IP Filtering

IP and Domain Filtering

IP Filtering is performed under the administrative facilities of the Microsoft Windows SMTP Server that is accessed via the Control Panel applet for the Internet Information Services, which appears in the folder for Administrative Tools. Expand the left pane until you can select the [image] icon in the left pane.

Right-mouse click and select to view the properties of this SMTP Virtual Server and select the Access tab.

Press the [image] button in the Connection control group box.

It is here that you may add access restrictions, either based on IP address, IP address range using a subnet mask, or domain name.

The Windows SMTP server will perform a check against this restricted list as soon an attempted connection is made. If the attempt is being made by a mail server on this restricted list, the connection is denied or accepted according to the radio button selection of which computers may access this one.

Warning:

CMS strongly recommends you carefully consider before putting any public IP address entry using an address range into this IP Address list since this represents an entire group of machines.


Overview

Message Filter Rules

Note:

Control of the configurable rule filter is only possible if you have selected to use the ADVANCED setting on this page. Setting to use the BASIC pre-configured rule filter will not allow you to see the Rule node in the left pane of the Praetor administration MMC.

As you know, Praetor filters mostly at the message level with the DNS blacklist check also available to function at the SMTP protocol level. There are other protocol level filtering but this occurs via the IIS Services Manager:

  • IP addresses

  • Domain names

  • Sender addresses

The message level filtering, however, is entirely based upon the Bayesian statistical technique and filtering rules using heuristics about the message and other conditions that you control. These rules provide substantial flexibility and power via a convenient user interface that is similar to the rules wizard found in Microsoft Outlook.

This chapter provides a discussion on message level filtering rules, the types, conditions and their lists, actions, exceptions, and templates. Equally important is a discussion on rule ordering, a topic that has significant bearing to Praetor's efficient operation. Improper ordering can result in Praetor spending more time than is necessary to determine if a message is spam. Some general ordering guidelines will be presented so that you can adjust Praetor to perform optimally for your site.

Praetor stores the rules and their order into a single script file. This rule script file is used for each message that Praetor processes. The scripting is expressed as a Microsoft Visual Basic Script and you can learn more by clicking here.

How Praetor determines message direction

Regardless of the rule type, global or conditional, the direction of the message being analyzed is an important determination of what rules will be tested. Praetor determines the direction of the message by checking the email address(es) of each intended recipient. If every address is found with a domain that was configured as a local domain in Praetor, then the message is considered as inbound. Otherwise the message is considered as outbound to the Internet.

Praetor will treat the message as a whole and perform its filtering consistently across all the recipients it finds. It does not split recipients and uses the inbound rules on one set of recipients, and the outbound rules on another set. Thus if a message contains mixed recipients with some being in the local domain(s) and at least one is out of the local domain(s), the message is considered as being outbound.

Next


Types

Types of rules

The default inbound conditional rules that are supplied by CMS can be seen below in the opening screen of the Praetor administration immediately after installing the software.

Rules list

These rules can be divided into different types, which are ordered below in increasing theoretical processing time.

  1. Global rules that will always be performed based upon the direction of the message

  2. Single-shot rules that require no input whatsoever

  3. String search rules

  4. List search rules

  5. Rules that involve external sources of information

Global rules

A Global rule is a rule that has no condition placed on it, just one or more actions that are applied to the message depending on the direction: inbound to the LAN recipients or outbound to the Internet. The selected action will always be performed based upon Praetor's determination of the message direction.

For efficiency and safety reasons, there are only three optional actions that can be applied, with two that involve the addition of text to the message.

  1. PREPEND to insert text before the original message body,

  2. APPEND to insert text after the original message body, and

  3. ARCHIVE to save a copy of the message in the Praetor Archive sub-directory.

  4. FORWARD message copy to an email address.

Global rules take precedence over normal rules and are the first items to be executed by Praetor's scripting engine. Thus these actions occur before any others found in conditional rules.

Back to list of rule types

Single-shot rules

These are some of the rules formulated after profiling countless spam samples. They require no maintenance by the administrator, as they are completely self-sufficient, testing for the existence of certain message header fields or comparing one field with the value found in another.

A few examples of such rules that are available by default include tests for:

  1. when the sender and recipient addresses are identical

  2. when the From field is blank or non-existent

  3. when the To and Cc fields are blank or non-existent

  4. when the Message-ID field is missing

Back to list of rule types

String search rules

These are relatively quick string comparisons on a given message header field. The strings are entered via a dialog box shown below.

Also, this type of rule typically has a small number of different strings, and thus those strings can be listed in the details of the rules shown in the bottom window.

Back to list of rule types

List search rules

Rules of this type have to search a pre-defined list that may contain a large number of strings. Thus a rule that involves any of these lists are of this rule type.

The pre-defined lists are for:

  • approved and suspicious domains

  • approved and suspicious sender addresses

  • banned recipient addresses

  • banned subject

  • banned body text

  • banned and suspicious attachment names

The strings in the list are entered through the dialog box that appears after clicking the underlined list name within the rule details (lower) window.

Praetor has one other variation of a pre-defined list, one without selection checkboxes. These apply to the last three pre-defined lists for banned subject, body text, and suspicious attachment names.

For more information on list searching, click here.

Rules involving external sources of information

A few rules may involve external sources of information needed to perform its function. A good example of this is any rule that queries on a DNS server to verify the existence of a domain name. Depending on the response time from the DNS server, this rule may take a long time to complete.

The slowest response time is for domains that are non-existent, typically evident in spam messages that most sites fortunately still find in the minority. The reason for the slow DNS server response time is that typically your ISP's server will not have the fictitious domain name cached. Thus it needs to pass the query on to the next higher domain authority, possibly reaching the top-level DNS server.

For valid domain names, the probability is good that your ISP DNS server has the information needed. Thus the response times for these domain names will be much quicker.

Next to Conditions

Back to list of rule types


Lists

Praetor has one in-line and three different internal system text string lists that are used by various conditions available for your selection with any rule, each with varying degrees of complexity and capabilities:

  • Simple in-line lists

  • Normal string lists

  • Complex checked lists with enable/disable box

  • Weighted words lists with numeric value used for scoring

In addition, each list has different types of searching that may be performed.

Praetor also provides the ability for administrators to create new string lists of the three non in-line type: normal, complex, and weighted. These are used by a special condition that permit you to choose what message header field or body to search and a particular list. Click here to learn how to create your own lists.

For a summary table of Praetor lists with information of what message field(s) are tested, click here.

Populating the lists can be performed using the list import facility either in the administration program or the MODLISTG2 command-line utility.

In-line list

This type of string list is normally associated with conditions bearing the phrase "with specific words". This type provides an easy way for you to quickly create a unique rule that tests for certain strings only associated with that particular condition. Examples include testing for subject matter with a particular string such as confidential code names or terminology in order to perform a very specific action like re-directing the message to a security compliance officer.

While the method of entry has some similarities for data entry to the other two list types, there are some basic differences which can be seen below.

In viewing the above screen, the string entered in the dialog box "ntm-dl.sparklist.com" appears in the rule description. This is a visible difference with the other two list types which don't show the contents as part of the rule description. Had there been more than one string, the list would have appeared on a line as:

with "string-1" or "string-2" or ...

Normal string list

Most lists that are predefined by CMS will appear as a normal list. Visually, the dialog box for this list data entry appears different from that used by an in-line list with the list name that appears as the window name. Furthermore, within the Rule Description area, what appears is merely the list name and not the contents of the list itself.

This list type can accommodate numerous entries, unlike the in-line list which become rather cumbersome when there are more than a handful of entries. By default, Praetor comes pre-installed with several such lists including the following.

  • Approved Message Level Senders

  • Banned Attachments

  • Banned Confidential Information

  • Banned Message Text

  • Banned Profanity

  • Banned Subject

  • Banned Virus Subject Text

  • Bulk Mail Program Signatures

  • Suspected Virus Message Text

  • Suspicious attachments

Complex checked string list

The complex list is the type with an enable/disable checkbox in the data entry dialog box. This type of list allows you to add an entry but temporarily exclude it from the search. This feature is useful for those items that might fluctuate. Like the normal list, this one has the data entry window name that is the same as the list name. Also like the normal list, the Rule Description area refers to the list by name and not by value.

This list type can also accommodate numerous entries, just like a normal list and unlike the in-line list. By default, Praetor comes pre-installed with several such lists including the following.

  • Approved Message Level Domains

  • Banned Senders

  • Banned Domains

  • Banned Recipients

  • Competitors' Domains

  • Former Employees

The available lists are shown on the text list screen.

Weighted words list

This is a new list type introduced in Praetor G2 to give (case-insensitive) words or phrases a weight value. These weights are used to compute an overall score for the message, and if that score exceeds a given threshold set for the list, then the rule condition is triggered. The score is computed by summing each weight multiplied by the number of times the word/phrase was found in the message body.

This type of list includes the following:

  • Drug solicitation

  • Sex-related

  • Nigerian 419 advanced fee fraud

Search Types

Each Praetor list can be searched using a different search type as explained below. Note that each entry is the string that is being searched within the search target field such as subject, message body, etc.

Selecting to match the case will make each search type even more specific.

Search Type

Usage

Substring

When matching the list entry within the target field, a partial match is sufficient to trigger the condition in the affirmative.

Full string

The between list entry and target must be complete, matching character for character.

Match whole word

Like the substring, a match is found if the list entry is part of the target field at the beginning or end or the field, even if there is a preceding or trailing punctuation character as follows:

  • blank space ( )

  • comma ( , )

  • tab

  • semi-colon ( ; )

  • colon ( : )

  • period ( . )

  • question mark ( ? )

  • exclamation point ( ! )

  • back slash ( \ )

  • single quote ( ' )

  • double quote ( " )

  • less than sign ( < )

  • greater than sign ( > )

  • forward slash ( / )

Wildcard

When enabled, this causes the appearance of certain characters in the search entry to be treated as wild. Specifically the characters that are considered "wild" or placeholders for any other character are:

? - represents any single alphabetic character,
# - represents any single numeric digit,
* - represents multiple characters, alphabetic or numeric.

If this type is not enabled, then these special characters are just treated as individual characters that must be found in the target field to cause a match.

If you want to perform a wildcard search for a string that includes these special characters, then you must data escape the special character by preceding it with a back-slash.

Example: "Get yours \*FREE\*"
means: "Get yours *FREE*"
will match on: "Get yours *FREE*"
will NOT match on: "Get yours FREE"

Examples (without requiring to match case)

The 'Y' indicates that the search found a match when the given search type was used to find the entry within the target field.

When search type is enabled

Entry | Target Field or Entry comments if italicized | Sub- string | Full String | Whole word | Wild-card
Thank you | Purely text string |  |  |  |
 | Just wanted to thank you! | Y |  | Y |
 | Thank you | Y | Y | Y | Y
 | Thank you! | Y |  | Y |
 | Please thank your friend for me | Y |  |  |
 | Hi! *THANK YOU* very much | Y |  |  |
 | THANK YOU, it was most kind of you | Y |  | Y |
*Thank you* | Text string with asterisk character preceding and trailing. This character only takes special meaning if wildcard type of search is being performed. For all other search type, the asterisks are just part of the string to be matched. |  |  |  |
 | Just wanted to thank you! |  |  |  | Y
 | Thank you |  |  |  | Y
 | Thank you! |  |  |  | Y
 | Please thank your friend for me |  |  |  | Y
 | Hi! *THANK YOU* very much | Y | Y | Y | Y
 | THANK YOU, it was most kind of you |  |  |  | Y
Thank you* | Text string with trailing asterisk character, which is interpreted as being wild only for wildcard searching. For all other search types, the asterisk is simply another character. |  |  |  |
 | Just wanted to thank you! |  |  |  | See note
 | Thank you |  |  |  | Y
 | Thank you! |  |  |  | Y
 | Please thank your friend for me |  |  |  | See note
 | Hi! *THANK YOU* very much | Y |  |  | See note
 | THANK YOU, it was most kind of you |  |  |  | Y

Note:

The use of wildcards may be a bit confusing, especially when the list entry is "Thank you*" and the target field is "Just wanted to thank you!", "Please thank your friend for me", or "Hi! *THANK YOU* very much". You might think that performing a wildcard search should find a match. The reason it does not is simple - the wildcard search would only find a match if "thank you" were to be found at the beginning of the line due to the lack of a preceding asterisk on the list entry.

So, if your intention is to let "thank you" appear anywhere in the target field, then your list entry needs to start and end with an asterisk when using a wildcard search type.

Warning:

CMS strongly recommends against changing the search type found on the lists dealing with banned attachments and suspicious attachments. The search type should be left as wildcard search on these two lists. Changing the search type to anything other than wildcard may cause Praetor to miss certain attachments, making your site vulnerable to virus infections that get past Praetor!

Summary table of Praetor lists

Note:

Note that lists that use the word "accepted" in its name indicate that it is used by the SMTP protocol level tests before the message is ever received completely. When the list name has the word "approved", it indicates one that is used by the message level rules.

SMTP protocol level

List name (as used by MODLIST tool) | Message field tested | Comments
DNSBL Bypass | session IP | Used to specify IP addresses in spite of being blacklisted by the DNSBL server.
Received header IP | session IP | Used to list trusted IP addresses found in the Received message header lines to determine the first external IP address. This first external IP address will be used for DNSBL testing.

Message level

List name | Message field tested | Comments
_approved_senders | 821 From From Sender | Requires complete email address.
_suspicious_senders | 821 From From Sender | Requires complete email address. This list is used by the message level rule as the equivalent to what the SMTP protocol level test against the _banned_senders list. The rule will quarantine mail sent by the listed address entries.
_competitors_domains | 821 To To Cc | Checks the domain portion of the destination address and is used for outbound mail.
_approved_domains | 821 From From Sender | Checks the domain portion of the sender's address and used to accept the message if it matches an entry in this list.
_suspicious_domains |  | Checks the domain portion of the sender's address and used to quarantine the message if it matches an entry in this list.
_banned_subject | Subject | Checks for inappropriate subject matter. This list is pre-populated by CMS with phrases used in spam.
_banned_msgtext | Message body | Checks for inappropriate message body text. This list is pre-populated by CMS with phrases used in spam.
_banned_recipients | 821 To To Cc | Requires complete email address.
_former_employees | 821 From From Sender 821 To To Cc: | Requires complete email address.
_banned_attachments | Attachment name | Known virus-infected attachment names and name patterns. This list is pre-populated by CMS with known virus attachments.
_suspicious_attachments | Attachment name | Attachment names and name patterns that will be quarantined. This list is pre-populated by CMS with attachments extensions and file name patterns that are potentially harmful.
_banned_profanity | Subject Message body | Inapproriate language that will quarantine. This list is pre-populated by CMS.
_virus_banned_msgtext | Message body | Message body text associated with known virus-infected email. This list is pre-populated by CMS with known virus signatures.
_virus_banned_subject | Subject | Subject text associated with known virus-infected email. This list is pre-populated by CMS with known virus signatures.
_bulk_mail_program_signatures | X-Mailer | Identifiable mailer signatures. This list is pre-populated by CMS.
_banned_confidential_info | Subject Message body | Company confidential words or phrases found will cause message to be quarantined.
_approved_listserver_addresses | 821 From: From Reply-To | Known listserver email addresses to let pass filtering.
_approved_local_address | 821 To | Used as a countermeasure against the reverse NDR attack, this list contains all valid local recipient addresses.
_suspicious_friendlynm_senders | 821 From From Sender | Friendly name found in double-quotes on the address line.


Conditions

Praetor is supplied with dozens of different conditions for you to use alone or in combination. They were created after considering what are the typical conditions you might want to use.

The list below shows the conditions, named as they would appear for selection. Anything requiring further entry (e.g. list or message header field) are shown as in this font and color while comments are shown in this font and color.

In/Out | Condition
Inbound | the From: field address is in the Accepted Senders list This list is from Praetor v1.5 and contains SMTP protocol level white list entries that should be transferred to the message level Approved Senders list
Inbound | the Sender: field address is in the Approved Senders list
Inbound | the From: or Sender: field address is in the Approved Senders list
Inbound | the From: or Sender: domain is in the Approved Domains list
Inbound | the From: or Reply-To: address is in the Approved Listserver Addresses list This list of listserver addresses should be updated to bypass further spam tests
Inbound | the recipient address is in the Approved Local Address list This list is typically used to defend against Reverse NDR attacks
Inbound | the recipient address is NOT in the Approved Local Address list
Inbound | the From: or Sender: address is in the Suspicious Senders list
Inbound | the From: or Sender: friendlyname is in the Suspicious Friendlyname Senders list
Inbound | the From: or Sender: domain is in the Suspicious Domain list
Both | the recipient address is in the Banned Recipients list
Both | the Subject: line contains words in the Banned Subject list
Both | the message field contains words in the specified list Used with new ability to create your own user list as described below
Both | the Subject: line contains words in the Banned Virus Subject list
Both | the message body text contains words in the Banned message text list
Both | the message body text contains Suspected Virus Message Text list
Both | with specific filenames in the Banned Attachment list
Both | with specific filenames in the Suspicious Attachments list
Both | the Subject: line contains words in the Banned Profanity list
Both | the message body text contains words in the Banned Profanity list
Both | the Subject or Body contain words in the Banned Profanity list
Inbound | the X-Mailer: field contains words in the Bulk Mail Program Signatures list Some spammers use off-the-shelf bulk mailing software that set this field
Both | the From:, Sender:, To: or Cc: address is in the Competitor's Domains list
Both | the From:, Sender:, To:, or Cc: address is in the Former Employee Address list
Both | the Subject or Body contain words in the Banned Confidential Information list
Both | the 821 To: address is in the Former Employee Address list
Both | the message body text contains words in the Variable info in message text list
Both | with specific words in the From: field
Both | with specific words in the Sender: field
Both | with specific words in the From: or Sender: field
Both | with specific words in the Reply-To: field
Both | with specific words in the To: field
Both | with specific words in the Cc: field
Both | with specific words in any recipient address
Both | with specific words in any address field
Both | with specific date string in the Date: field
Both | with specific words in the Subject: line
Inbound | with specific words in any Received: field
Both | with specific filenames as attachments
Both | with specific words in the Message-ID: field
Both | with specific words in any Precedence: field
Both | with specific words in any X- field
Both | with specific words in any List- field
Both | with specific words in the message body
Both | with specific words in the Subject: or message body
Both | with specific words in any message header field
Inbound | with failed DNS lookup on From: domain
Inbound | with failed DNS lookup on Sender: domain
Inbound | with failed DNS lookup on Reply-to: domain
Inbound | with DNSBL entry of CIP CIP is the connected IP address of the remote sending mail host
Inbound | with failed DNS lookup on any replyable sender domain
Both | with specific words in the entire message (excluding msg headers)
Inbound | the 822 headers contain 8-bit data
Both | with Banned msg body words in the entire message (excluding msg headers) This condition may be slow if the message is large
Both | the 821 headers contain 8-bit data
Inbound | the Subject or Body contains 8-bit data
Inbound | sender address is suspicious
Both | the Subject or Body contain words in the Weighted sex-related list with threshold of 200 Checks for sexual content
Both | the message body text contains words in the Weighted advanced fee fraud list with a threshold of 200 Checks for fraud content such as Nigerian advanced fee scams
Both | the message body text contains words in the weighted drug solicitation list with a threshold of 200 Checks for content offering discounted prescription drugs
Both | with specific weighted words in the Subject or Body This can be used to check for general content
Both | the Body contains URL domains in the Banned URL domains list This list of domains in spams received by CMS not yet on any DNS blacklist
Inbound | there are no local To: or Cc: recipients This is a typical spam tactic where your local recipient is a Bcc, but it is also used in messages from valid listservers. Get around this by populating the approved listservers list
Both | the From: and To: addresses are the same
Both | the To: field is missing or blank This is a typical spam tactic
Both | the To: field exists
Both | the Cc: field is missing or blank
Both | the Cc: field exists
Both | the From: field is missing or blank
Both | the From: field exists
Both | the Precedence: field has bulk Some spammers use off-the-shelf bulk mailing software that set this field
Both | the Message-ID: field exists
Both | the Message-ID: field does not exist
Both | the Message-ID: field is blank
Both | with a (raw message) size in a specific range
Both | Containing attachments
Both | Containing only 1 To: recipient
Both | Containing no attachments
Both | Containing over 20 RFC822 To: recipients
Both | Containing over 20 RFC821 To: Recipients
Both | Containing a single RFC821 To: Recipient
Both | the message has Bcc recipients
Both | with specific addresses in the 821 From: field
Both | with specific addresses in the 821 To: field
Both | the Subject: field is missing or blank
Both | check EXCEPTIONS only Advanced condition used to filter all except for those in the exception, e.g. as used by the Reverse NDR rule
Inbound | with a connecting IP in a DNS blacklist Connecting IP address of remote sending mail host is blacklisted
Both | the From: friendlyname is in the Expletive Friendlyname list Profanity is found in the sender name
Both | the Subject or Body contain words in the Expletive list Disallow profanity
Both | the Subject or Body contain words in the Spam list
Both | the Subject: line contains words in the Suspicious Characters list Detect spam that contains repeating punctuations or symbols in the subject
Both | the message body text contains words in the Opt-Out list The recently enacted US CAN-SPAM law require spammers to provide some way to opt-out from future mailings. While CMS recommends you don't follow this method since you'll just verify your email address and get more spam, the opt-out instructions are detectable
Inbound | the From: field friendlyname is blank The name exists but blank
Inbound | the msg contains embedded encoded-HTML segments
Inbound | the msg contains an obfuscated URL Obfuscated URLs include those that use IP addresses instead of domains, or try to hide the URL by encoding the characters and digits
Inbound | the msg contains only external references The message only has URLs and gibberish
Both | the msg contains invisible html text Invisible because the font color is almost the same as the background color
Both | the msg contains tiny html text The font size is so small that it is not visible on the screen
Inbound | with a spamicity value greater than specific value Bayesian test for spam
Inbound | with a spamicity value less than specific value Bayesian test for non-spam
Inbound | with a spamicity value in a specific range Bayesian test for unsure

For a table of the various lists used by some of these conditions, click here.

Custom condition

One condition in the above table is called "the message field contains words in the specified list" and is a very special condition. It is the only condition that has two selections, and it allows you to select what field to check against a specified list including any newly-created user list. Thus it is essentially a custom condition that demonstrates Praetor's flexibility to create many different rules.

When this condition is chosen, and you click on the message field selector, the following dialog box appears on your screen.

Once you have selected the field(s), clicking on the list selector in the Rule Description window will then display the following screen.

The drop-down list will show all available lists, and you may choose to display the system-internal or user-created lists. Once a list is selected, the contents are displayed below.

Click the following links for more information on:

  • Search types

  • Creating user lists

If the message field being tested in the condition is an address field, then the appropriate button may restrict the search to the domain portion of the address, or the friendly or displayable name associated with the address.

You may also restrict the search through the list to enforce the case of characters. By selecting All target items must be in the list, you will require that every item found in the field being searched must be found in the list, a very important restriction employed in the defense against the Reverse NDR attack.

Heuristic condition

One condition is used specifically for creating a rule that implements heuristic filtering based upon a score computed using weights for spam characteristics found within the message. This is the condition labeled "Exceeds heuristic threshold of 300" as shown below.

Selection of this condition will set a threshold for the computed heuristic score with 300 as the default value. If the enabled tests cause the overall message to score a value that exceeds this threshold, then the specified action will be taken.

You may change the threshold value by clicking on the link in the lower window and you will be presented with the following screen.

Change the value either by typing the number in the numeric field or moving the horizontal slider bar, and press [image].

Next to Actions


Actions

Praetor has two distinctly different types of actions:

  • Terminal actions

These primary actions are listed in the top-most window. They are mutually exclusive so only one can be selected. For each rule, there must be only one such terminal action chosen. And once the action is performed, Praetor has disposed the message; no further actions can or will be taken on that message.

The terminal actions are:

  • Accept

  • Re-direct

  • Quarantine

  • Return to sender

  • Reject

  • Optional actions

These actions may be selected in any combination. They are performed before the terminal action. The list includes:

  • Archive

  • the message

  • the message to a specific folder

  • the message to training type and training folder

  • Forward,

  • Insert Text at the beginning or end (e.g. disclaimers),

  • Send notification to

  • any email address

  • administrator

  • message sender

  • intended recipient

  • Add or Set X- message header field and its useful variants

  • Flag the message as spam

  • Add the reason why the message was caught

  • Add name of rule that caught the message

  • Prepend a prefix to the subject

Click on the above links for more details about each optional action.

Accept

Terminal

This action will cause the message to be delivered to its ultimate destination, either to the local recipient for inbound messages from the Internet, or to the Internet recipient for outbound messages from the local sender.

Archive

Optional

This action will cause a message file copy to be placed in:

  • Praetor Archive directory whose path is typically C:\Program Files\CMS Praetor G2\Archive.

  • A named path that you can specify.

  • A particular training type (Bad, Good, or Unsure) and training folder (Waiting Review or Ready to Train)

Prepend a prefix to the subject

Optional

This action will cause the specified prefix to be inserted at the beginning of the original subject.

Quarantine

Terminal

This action will cause the message file to be moved to the restricted Praetor Quarantine directory. The full path is C:\Program Files\CMS Praetor G2\Quar.

Reject

Terminal

This action will delete the message and nothing will be sent to its intended recipient. No recovery of the message is possible.

Next


Rule templates

Praetor offers a convenient way to create new rules based on templates with its selected conditions and actions. You can then make variations by changing or adding conditions and actions.

To take advantage of this facility, simply select the specific rule template from the right pane and right-mouse click to open the list as shown above, and select to create a New rule from template. As you see below, the familiar Rule Wizard window will appear with pre-selected conditions and actions from the template rule and you can add your modifications.

Return to Configuring Praetor


Ordering

Ordering the rules

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.

Reject banned attachments

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.

Quarantine suspicious attachments

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.

Order Accept rules first

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.

Order the faster rule types earlier

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.

Place the more specific and precise rules earlier

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.

Summary

Putting all these observations into practice we arrive at the following guidelines as a start.

  1. Single-shot rules for acceptance with specific test first, followed by tests in decreasing specificity

  2. Single-shot rules for rejection with specific test first, followed by tests in decreasing specificity

  3. String search rules for acceptance with specific test first, followed by tests in decreasing specificity

  4. String search rules for rejection with specific test first, followed by tests in decreasing specificity

  5. List search rules for acceptance with specific test first, followed by tests in decreasing specificity

  6. List search rules for rejection with specific test first, followed by tests in decreasing specificity

  7. Rules with external information sources for acceptance with specific test first, followed by tests in decreasing specificity

  8. 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.


Scripting

Scripting the rules (Advanced only)

When you have selected the ADVANCED configurable message-level rule filter, Praetor runs through the rule script for each and every message that it processes. This script is automatically generated from the active (selected) rules in their specified order. Praetor uses the Visual Basic Scripting language that is used by the Microsoft Windows Scripting Host engine.

Note:

Praetor G2 implements scripting differently from previous versions, as many customers have suggested. Changes to the rule script take effect immediately with the next message processed. No stop and re-start of Praetor is needed.

Also, additions and changes to various Praetor lists do not effect the script and take effect as soon as those changes are made.

The main script file used for Praetor filtering is a text file called FilterScript.TXT located in \Program Files\CMS Praetor G2 folder on your local hard drive. This is the result of combining

  • MainScript.TXT - containing the basic preconfigured rule filters (attachments and whitelists)

  • BayesScript.TXT - containing the Bayesian script

  • Your enabled rules

While you can edit this file using your favorite text editor, realize that the Rules Wizard was implemented as a convenient method for creating your custom rules.

If you want to develop the rules by creating custom scripts, please refer to Appendix E for more information on various message objects that are available to your script when it is invoked for each message being processed. Going this route will also mean that you should not use the normal [image] button to save the rules since the automatic script generation will cause your custom rule script to be over-written. Obviously this also means that you use the ADVANCED configurable rule filter method.

You can also view the rule script by selecting the Script File node that appears in the left pane, and the complete script will be shown in the right pane.

Pressing [image] allows you to search through the script file for specific strings and locate the position of your rules and their associated lists.

Return to overview


Licensing Overview

Praetor is licensed on a per-user basis, specifically the number of unique email addresses to be protected by Praetor's filtering. These include:

  • Mailboxes (Users and Software Agents).

  • Public folders receiving inbound mail.

  • Distribution lists receiving inbound mail - do not count list members.

  • Custom recipient/forwarding addresses to non-local domains.

Excluded from this are alias addresses that go to the same mailbox.

There are two types of serial numbers:

  • Base

Primary identifying number for the Praetor installation. It has a matching authentication code and is available for the following number of users:

  • 10

  • 25

  • 100

  • 500

  • 1000

The authentication code will change with each major revision of the Praetor product, e.g. from Praetor v1.5 to Praetor v2.0.

  • Add-on user upgrade

Used to increase the licensed number of users, these add-on user upgrades are available in the following sizes:

  • 5

  • 10

  • 50

  • 100

  • 1000

  • 5000

Price quotes can always be obtained from the CMS website.

Other licensing topics in this section are:

  • Expiration of the 21-day evaluation

  • Upgrading from the 21-day evaluation

  • Adding user licenses

  • Evaluation license agreement

  • Normal, non-evaluation license agreement

Note:

For a discussion of what occurs when your 21-day Praetor evaluation expires please read this FAQ.

An important feature designed in Praetor is its pass-through of messages for any unlicensed individuals. In other words, Praetor does not block messages for those who are not licensed. Instead Praetor will simply pass the messages without performing any checks against those messages. In this way, no message flow interruption will be experienced by the unlicensed individuals or servers. Only the benefits from Praetor's rule-based filtering will be withheld.

Starting with Exchange v5.5, Microsoft has made enhancements that give it the ability to act as a mail relay, as evidenced by the different routing options available for each domain. Also it is possible for non-local recipients to have a local address through the creation of a Custom Recipient entry which appears in the directory of Exchange users. These recipients will count toward the user license for Praetor if you want them to be protected. The same is also true for any public folder you want protected as they also have an associated email address.

Lotus Notes has long had the ability to specify a forwarding address for any Person record. This was made even more friendly in Notes R5 with the drop-down list of the various address types: Notes, cc:Mail, Other Internet Mail, POP or IMAP, X.400, and Other. From a licensing standpoint, these person records are counted toward the licensed users since Praetor will be filtering their messages.

For generic SMTP mailers, many accommodate a similar function by the creation of a .forward address. As in the other two examples, these users would also count in Praetor's licensing.


User-based licensing

Praetor has been designed to automatically and periodically query the Domino, Exchange, or mail server for all the local user mailboxes at the site. Your site is fully compliant when Praetor detects that the actual number of mailboxes is less than or equal to the number licensed. When this is your situation Praetor will process messages faster because every message will be filtered without having to check if the recipient is on the licensed list of users.

You do not have a fully compliant license installation of Praetor when it detects that the number of user mailboxes exceeds the number licensed. In this situation, Praetor must check to see if the intended recipient(s) of every message are on licensed servers. Should they be licensed, the message is processed as normal, filtered through all the rules the administrator has specified. Otherwise, if there is at least one recipient on an unlicensed mail server, Praetor simply cancels the rules filtering at the message level and delivers the message.

Return


Expiration of the evaluation

Expiration of the 21-day evaluation

When the evaluation period has expired, launching the Praetor administration MMC snap-in will display the following screen.

While you can press [image] and still use the administration program, all messages will not be filtered by Praetor even though it is enabled. You will find current event message entries that appear as follows.

As you can infer from this log display, Praetor does not analyze the messages so information about the sender or intended recipient is not available. The messages will simply be delivered without any filtering being performed.

Note:

There will be no way to reclaim the summary information on these messages even after you have upgraded Praetor to a fully licensed version as discussed below. Those messages have been delivered to their intended recipients.

Upgrading the evaluation version

Upgrading from the timed evaluation to a full product version is a simple one that can be performed onto the installed Praetor by following these steps.

1. | Right-mouse click on the main Praetor node in the left pane and view the Properties page.
2. | Change to the License tab and you will find the [image] button.
3. | Press the [image] button and the Register CMS Praetor window appears. Enter the serial number and authorization code obtained from the CMS Sales department.
4. | Press [image] and you will be returned to the View License Information screen on the License tab.

Once Praetor is registered with a valid serial number and matching authentication code, it will no longer have the 21-day expiration. In the above case where expiration has already occurred, your registration will take effect automatically within the next 15 minutes.

You can also manually force the immediate re-activation of Praetor by:

  1. Resetting IIS at a command prompt by issuing the command

    IISRESET

  2. Restarting the SMTP server at a command prompt with the command

    NET START SMTPSVC


Adding additional user license

Adding user licenses

If you have outgrown the original user license and purchased additional user licenses for your Praetor installation, you may perform the upgrade registration by following these simple steps.

1. | Right-mouse click on the main Praetor node in the left pane and view the Properties page.
2. | Change to the License tab and press [image] .
3. | When the Enter License window appears enter the additional user license serial number provided by the CMS Sales department.
4. | Press [image] .

Adding User Licenses into Praetor takes effect immediately.


Praetor License Agreement

License Agreement

This legal document is an agreement between you, the end user, and Computer Mail Services, Inc.

THIS AGREEMENT AND THE ACCOMPANYING SEPARATE PRODUCT CERTIFICATE(S) CONSTITUTES THE COMPLETE AGREEMENT BETWEEN YOU AND COMPUTER MAIL SERVICES, INC. IF YOU DO NOT AGREE TO THE TERMS OF THIS AGREEMENT, PROMPTLY RETURN THE UNOPENED MEDIA ENVELOPE AND THE OTHER ITEMS (INCLUDING WRITTEN MATERIALS, BINDERS OR OTHER CONTAINERS AND HARDWARE, IF ANY) THAT ARE PART OF THIS PRODUCT TO THE PLACE WHERE YOU OBTAINED THEM FOR A FULL REFUND.

GRANT OF LICENSE

In consideration of payment of the LICENSE fee, which is part of the price you paid for this product, Computer Mail Services, Inc. (hereinafter "CMSI"), as Licensor, grants to you, the LICENSEE, a non-exclusive right to use and display this copy of a CMSI software program (hereinafter "SOFTWARE") on a single COMPUTER (i.e. with a single CPU).

OWNERSHIP OF SOFTWARE

As the LICENSEE, you own the magnetic or other physical media on which the SOFTWARE is originally or subsequently recorded or fixed, but CMSI retains title and ownership of the SOFTWARE recorded on the original media copy/copies and all subsequent copies of the SOFTWARE, regardless of the form or media in or on which the original and copies may exist. This license is not a sale of the original SOFTWARE or any copy.

COPY RESTRICTIONS

This SOFTWARE and the accompanying written materials are copyrighted. Unauthorized copying of the SOFTWARE, including SOFTWARE that has been modified, merged or included with other software, or of the or written materials is expressly forbidden. You may be held legally responsible for any copyright infringement that is caused or encouraged by your failure to abide by the terms of this License. CMSI will use every and all remedies available to it under the laws of the United States for infringement of its copyright. Subject to these restrictions, you may make no more than three (3) copies of the SOFTWARE solely for backup purposes.

USE RESTRICTIONS

As the LICENSEE, you may physically transfer the SOFTWARE from one computer to another provided the software is used only on one computer at a time. You may not electronically transfer the SOFTWARE from one computer to another over a network. You may not distribute copies of the SOFTWARE or accompanying written materials. You may not modify, adapt, translate, reverse engineer, decompile, disassemble, or create derivative works based on the SOFTWARE. You may not modify, adapt, translate or create derivative works based on the written materials without the prior written consent of CMSI.

This product can only be used by the purchaser or its subsidiaries and cannot be used by third parties or for the benefit of third parties. For example, an Internet Service Provider (ISP) or Applications Service Provider (ASP) may not use this product to offer message filtering to its customers.

TRANSFER RESTRICTIONS

This SOFTWARE is licensed only to you, the LICENSEE, and may not be transferred to anyone without the prior written consent of CMSI. Any authorized transferee of the SOFTWARE shall be bound by the terms and conditions of this agreement. In no event may you transfer, assign, rent, lease, sell or otherwise dispose of the SOFTWARE on a temporary or permanent basis except as expressly provided herein.

TERMINATION

This License is effective until terminated. This License will terminate automatically without notice from CMSI if you fail to comply with any provision of this license. Upon termination CMSI has the right to demand that you return or destroy written materials and all copies of the SOFTWARE, including modified copies, if any. At that time you must certify in writing that you have not retained any copies of the software.

UPDATE POLICY

CMSI may create, from time to time, updated versions of the SOFTWARE. At its option, CMSI will make such updates available to the LICENSEE and transferees who have paid the update fee and registered the software by notifying CMSI of its use and location. To provide the proper update CMSI will inquire what version of the SOFTWARE is installed.

If the SOFTWARE is an update, you are authorized to use the SOFTWARE only if you are an authorized user of qualifying products as determined by CMSI. When you install the update you must discontinue the use of the copy of the qualifying product.

MISCELLANEOUS

This agreement is governed by and interpreted in accordance with laws of the State of Michigan and the United States. Any terms or conditions of this agreement found to be unenforceable, illegal, or contrary to public policy in any jurisdiction will be deleted, but will not affect the remaining terms and conditions of the Agreement.

LIABILITY

You agree that CMSI's liability for damages to you or to any other party shall not exceed the license fee paid for the software.

ENTIRE AGREEMENT

This agreement constitutes the entire agreement between you and CMSI.

Disclaimer of Warranty and Limited Warranty

THE SOFTWARE AND ACCOMPANYING WRITTEN MATERIALS (INCLUDING INSTRUCTIONS FOR USE) ARE PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. FURTHER, CMSI, DOES NOT WARRANT, GUARANTEE, OR MAKE ANY REPRESENTATIONS REGARDING THE USE, OR THE RESULTS OF THE USE OF THE SOFTWARE OR WRITTEN MATERIALS IN TERMS OF CORRECTNESS, ACCURACY, RELIABILITY, CURRENTNESS, OR OTHERWISE. THE ENTIRE RISK AS TO THE RESULTS AND PERFORMANCE OF THE SOFTWARE IS ASSUMED BY YOU. IF THE SOFTWARE OR WRITTEN MATERIALS ARE DEFECTIVE, YOU, AND NOT CMSI, OR ITS DEALERS, DISTRIBUTORS, AGENTS OR EMPLOYEES, ASSUME THE ENTIRE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

CMSI warrants to the original LICENSEE that the media which the SOFTWARE is recorded is free from defects in materials and workmanship under normal use and service for a period of ninety (90) days from the date of delivery as evidenced by a copy of the receipt. Further, CMSI hereby limits the duration of any implied warranty on the media to the period stated above. Some states do not allow limitations on duration for an implied warranty, so the above limitations may not apply to you.

CMSI's entire liability and your exclusive remedy as to the media shall be, at CMSI's option, either (a) return of the purchase price or (b) replacement of the media that does not meet CMSI's Limited Warranty and which is returned to CMSI with a copy of the receipt. If failure of the media has resulted from accident, abuse, or misapplication, CMSI shall have no responsibility to replace the media or refund the purchase price. Any replacement media will be warranted for the remainder of the original warranty period or thirty (30) days, whichever is longer.

THE ABOVE ARE THE ONLY WARRANTIES OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE MADE BY CMSI ON THIS CMSI PRODUCT. NO ORAL OR WRITTEN INFORMATION OR ADVICE GIVEN BY CMSI, ITS DEALERS, DISTRIBUTORS, AGENTS, OR EMPLOYEES SHALL CREATE A WARRANTY OR IN ANY WAY INCREASE THE SCOPE OF THIS WARRANTY, AND YOU MAY NOT RELY ON ANY SUCH INFORMATION OR ADVICE. THIS WARRANTY GIVES YOU SPECIFIC LEGAL RIGHTS. YOU MAY HAVE OTHER RIGHTS, WHICH VARY FROM STATE TO STATE.

NEITHER CMSI NOR ANYONE ELSE WHO HAS BEEN INVOLVED IN THE CREATION, PRODUCTION, OR DELIVERY OF THIS PRODUCT SHALL BE LIABLE FOR ANY DIRECT, INDIRECT, CONSEQUENTIAL, OR INCIDENTAL DAMAGES (INCLUDING DAMAGES FOR LOSS OF BUSINESS INFORMATION AND THE LIKE) ARISING OUT OF THE USE OF OR INABILITY TO USE SUCH PRODUCT EVEN IF CMSI HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. BECAUSE SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES, THE ABOVE LIMITATION MAY NOT APPLY TO YOU.

This Agreement is governed by the laws of the State of Michigan.

Should you have any questions concerning this Agreement please write to:

Computer Mail Services, Inc.,
20300 Civic Center Drive
Suite 300
Southfield MI 48076.


Evaluation License Agreement

BY CLICKING ON THE Yes BUTTON, YOU ARE CONSENTING TO BE BOUND BY THIS AGREEMENT. IF YOU DO NOT AGREE TO ALL OF THE TERMS OF THIS AGREEMENT, CLICK THE No BUTTON AND THE INSTALLATION PROCESS WILL NOT CONTINUE.

YOU MAY USE THIS SOFTWARE FREE OF CHARGE FOR 21 DAYS ONLY. RE-INSTALLING THE SOFTWARE TO OBTAIN ADDITIONAL TIME IS STRICTLY PROHIBITED AND CONSTITUTES AN UNAUTHORIZED USE OF THE SOFTWARE. IF YOU ATTEMPT TO RE-INSTALL THE SOFTWARE FOR ADDITIONAL TIME WITHOUT CMSI PERMISSION, YOU AGREE TO PAY CMSI THE FULL COST OF THE SOFTWARE BASED UPON THE NUMBER OF USERS AT YOUR LOCATION.

PRAETOR END USER LICENSE AGREEMENT

CMSI grants you a non-exclusive license to use the Software free of charge for the purpose of evaluating for a 21-day period following installation. If you use the Software under this no-charge grant, you are not entitled to receive priority telephone assistance or additional revisions of the Software.

DISCLAIMER OF WARRANTY

The Software is provided on an "AS IS" basis, without warranty of any kind, including without limitation the warranties of merchantability, fitness for a particular purpose and non-infringement. The entire risk as to the quality and performance of the Software is borne by you. Should the Software prove defective, you and not CMSI assume the entire cost of any service and repair. In addition, the security mechanisms implemented by CMSI software have inherent limitations, and you must determine that the Software sufficiently meets your requirements.

This disclaimer of warranty constitutes an essential part of the agreement.

SOME JURISDICTIONS DO NOT ALLOW EXCLUSIONS OF AN IMPLIED WARRANTY, SO THIS DISCLAIMER MAY NOT APPLY TO YOU AND YOU MAY HAVE OTHER LEGAL RIGHTS THAT VARY BY JURISDICTION.

SCOPE OF GRANT

You may:

  • use the Software on any single computer;

  • use the Software on a network;

You may not:

  • modify, translate, reverse engineer, decompile, disassemble (except to the extent applicable laws specifically prohibit such restriction), or create derivative works based on the Software;

  • copy the Software; or

  • rent, lease, grant a security interest in, or otherwise transfer

  • rights to the Software.

  • use the Software to provide a public service, either free or with a fee, that permits customers/clients to exchange messages with the Internet through your installation. These customers/clients must obtain, install and operate their own copy of the Software.

TITLE

Title, ownership rights, and intellectual property rights in the Software shall remain in CMSI. The Software is protected by copyright laws and treaties. Title and related rights in the content accessed through the Software is the property of the applicable content owner and may be protected by applicable law. This License gives you no rights to such content.

TERMINATION

The license will terminate automatically if you fail to comply with the limitations described herein. On termination, you must destroy all copies of the Software and Documentation.

EXPORT CONTROLS

None of the Software or underlying information or technology may be downloaded or otherwise exported or reexported to a national or resident of any country to which the U.S. has embargoed goods; or to anyone on the U.S. Treasury Department's list of Specially Designated Nationals or the U.S. Commerce Department's Table of Denial Orders. By downloading, installing, and using the Software, you are agreeing to the foregoing and you are representing and warranting that you are not located in, under the control of, or a national or resident of any such country or on any such list.

LIMITATION OF LIABILITY. UNDER NO CIRCUMSTANCES AND UNDER NO LEGAL THEORY, TORT, CONTRACT, OR OTHERWISE, SHALL CMSI BE LIABLE TO YOU OR ANY OTHER PERSON FOR ANY INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF GOODWILL, WORK STOPPAGE, COMPUTER FAILURE OR MALFUNCTION, OR ANY AND ALL OTHER COMMERCIAL DAMAGES OR LOSSES. IN NO EVENT WILL CMSI BE LIABLE FOR ANY DAMAGES IN EXCESS OF THE AMOUNT CMSI RECEIVED FROM YOU FOR A LICENSE TO THE SOFTWARE, EVEN IF CMSI SHALL HAVE BEEN INFORMED OF THE POSSIBILITY OF SUCH DAMAGES, OR FOR ANY CLAIM BY ANY OTHER PARTY. THIS LIMITATION OF LIABILITY SHALL NOT APPLY TO LIABILITY FOR DEATH OR PERSONAL INJURY TO THE EXTENT APPLICABLE LAW PROHIBITS SUCH LIMITATION. FURTHERMORE, SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OR LIMITATION OF INCIDENTAL OR CONSEQUENTIAL DAMAGES, SO THIS LIMITATION AND EXCLUSION MAY NOT APPLY TO YOU.

HIGH RISK ACTIVITIES

The Software is not fault-tolerant and is not designed, manufactured or intended for use or resale as on-line control equipment in hazardous environments requiring fail-safe performance, such as in the operation of nuclear facilities, aircraft navigation or communication systems, air traffic control, direct life support machines, or weapons systems, in which the failure of the Software could lead directly to death, personal injury, or severe physical or environmental damage ("High Risk Activities"). CMSI and its suppliers specifically disclaim any express or implied warranty of fitness for High Risk Activities.

MISCELLANEOUS

This Software will automatically contact CMSI on a periodic basis to request update information and to inform CMSI of the version currently in use. Users who obtained the Software for evaluation may only continue to use this software beyond the 21 days evaluation period when authorized by CMS. Such authorization is granted through the issue of a valid extension number from CMSI.

YOU MAY USE THIS SOFTWARE FOR EVALUATION PURPOSES FREE OF CHARGE FOR 21 DAYS, ONLY. RE-INSTALLING THE SOFTWARE TO OBTAIN ADDITIONAL TIME WITHOUT CMSI PERMISSION IS STRICTLY PROHIBITED AND CONSTITUTES AN UNAUTHORIZED USE OF THE SOFTWARE. IF YOU RE-INSTALL THE SOFTWARE WITHOUT CMSI PERMISSION, YOU AGREE TO PAY CMSI THE FULL COST OF THE SOFTWARE BASED UPON THE NUMBER OF USERS/SERVERS AT YOUR LOCATION.

This Agreement represents the complete agreement concerning this license to evaluate the Software. If any provision of this Agreement is held to be unenforceable, such provision shall be reformed only to the extent necessary to make it enforceable. This Agreement shall be governed by Michigan law.


Overview

Log Viewer

Praetor logs a message summary into its database and you can view it in one of two ways. There are also SMTP protocol events that are logged but this happens before any message is actually received. This is covered separately.

First, the Praetor administration program integrates a message log viewer that allows you to conveniently review a list of each message that passed through Praetor in real-time and thus chronological order. Naturally there will be messages that were quarantined by your enabled rules and they are accessible to review the message details and decide how to dispose of them.

Second, Praetor also includes a web browser based access to the inbound message log. This method requires installing the optional web application we call PLGV and provides for filtering options to aid in searching for a particular message. Via this approach, you may allow users to access their own personal quarantine area.

If you do not want to allow users to access their quarantined messages, you may install PLGV just so administrators and select users (e.g. managers) have web browser access to the quarantined messages. In this case, you simply don't inform all your users of its existence. For more security and to prevent the accidental discovery of PLGV, you can choose an authentication method (SQL table) that restricts its use by the administrators and select users.

This section discusses the following:

Setup topics

    • Set up the SQL database if you moved off MSDE to SQL Server

    • Set up the PLGV web application

    • Set up the IIS SMTP log for debugging

Praetor administration

    • Viewing the log and acting upon any quarantined message

    • Searching the log by creating a query report

    • Viewing the protocol log (if protocol DNSBL filtering enabled)

Using PLGV via browser

    • Viewing logs

    • Creating a filtered list of entries


Viewing the log

The message log can be seen by selecting the Current Events container under Message Logs in the left pane of the Praetor administration program component as shown below.

Note:

The displayed list are limited to 32,000 most recent entries taken from the last 48 hours.

Log Viewer opening screen

As you can see, the log shows several columns that summarize each message that passed through Praetor.

  • Disposition icon representing the following:

Informational only, the message was accepted and is no longer available.

Quarantined message, available for review.

Informational only, former quarantined message that has been reviewed and disposed (released or rejected).

Informational only, the message was rejected and is no longer available.

Forwarded message, only summary information is available for review.

  • Date and time stamp

  • Message direction

  • Rule that was triggered

  • Main action event for the rule

  • Sender address (may be fictitious)

  • Recipient address

  • Subject

Note:

Columns may be re-sized by placing the cursor on the vertical title bar separator which then changes the cursor, and dragging it left or right to the desired width. Alternatively, place the cursor on the vertical bar until it changes to the re-size cursor, and double-click causing the column to adjust to the largest size needed for the widest entry in that column.

Since this is a dynamic real-time list of messages handled by Praetor, the view is always in chronological order and the columns cannot be sorted. Use the Find capabilities to narrow your search and provide a static snapshot report. This report allows sorting on specific columns.

To open any message, simply highlight the entry line and double-click. A dialog box will appear that shows you details about your message and which rule, if any, was triggered. This message information includes the following fields:

Field item | Description
Message ID | Unique filename given to the actual message file.
Rule | Name given to the rule which was triggered by the email.
From | From address in the RFC-821 message envelope.
To | First intended recipient in the RFC-821 message envelope.
Subject | Subject line in the RFC-822 message header.
Size | File size of the message in its raw form with any attachments still encoded.
Reason | Information to give more details about the triggered rule that caused the message to be quarantined.

If the message under review was not quarantined, then you will be presented with a summary screen that appears like the following.

Note that the message details area is empty except for "The message file is no longer available.", and all buttons in the Message Actions group box are grayed out. This is due to the fact that the message was not caught by Praetor and it was sent to the intended recipient, so the details are not available.

Note:

If you had set to archive messages, then the details will be displayed since a copy still remains, even though it was accepted and sent to the intended recipient.

If the message entry being double clicked was quarantined and marked with the disposition icon [image] then the display appears with more information available, including the specific reason why the message was quarantined, the connecting IP address of the sending mail host, etc.

Notice the scrollable region in the lower portion of the dialog box. This area contains the details of the actual quarantined message starting with the Internet message headers per RFC 2822. Also notice that the buttons in the Message Actions group are now enabled.

Message actions

Just as in the actions normally associated with Praetor rules, there are several message actions for you to choose in dealing with the quarantined messages. The actions buttons that may be pressed to dispose on the message are mutually exclusive:

  • Accept

Causes Praetor to deliver the message to its intended recipient

  • Reject

Deletes the message

  • Redirect

Delivers the message to a different address than intended

  • Return to sender

Returns the entire message to the sender

Optional training buttons:

  • Train as BAD

Analyzes the message and updates the spam tokens used by the Bayesian filter

  • Train as GOOD

Analyzes the message and updates the non-spam tokens used by the Bayesian filter

The first two actions for accepting and rejecting are self-explanatory. The Redirect and Return to sender requires more information from the person who is reviewing this quarantined message. Click the links provided above to see a discussion on those actions. In fact, returning to the sender takes advantage of pre-existing templates on the Praetor machine. Click here to read how these can be set up, either on the Praetor machine or the remote Log Viewer machine.

Pressing either of the two train buttons causes the message under review to be analyzed, broken into their tokens, and update the Bayesian filter token database by incrementing the token count as spam or ham (non-spam or good messages). These optional training actions do not close the review window and you can still dispose of the message by selecting any one of the four main message actions.

For your convenience, the checkbox Auto advance to next message event is provided so that after viewing and deciding on the disposition of each quarantined message, the next quarantined message is automatically displayed. Thus the navigational buttons do not need to be pressed when this checkbox is selected.

Press [image] when you are done reviewing this message.

Navigation

These navigation buttons will jump to the message according to the type shown as the Message Event Filter. Normally this type is set according to the message being reviewed, though you may change it. The navigation buttons will proceed to the message with that specific event type.

Here are the various meanings for the buttons you see.

First

Previous

Next

Last

Address Options

The Address Options tab page is shown for any message whose details are available. This facility allows you to now add domain and IP addresses to the various lists shown.

Many times quarantined messages may contain sender address or domains, connecting the IP address, or other information that you may want to place into various lists. It is in this window where you may do so by checking the box(es) for your selections and pressing [image].

Pressing [image] in the lower left permits you to check on the IP address of the mail server that sent this message to Praetor. You may perform either a blacklist lookup using the specified DNS Blackhole list servers, or an A record lookup to your normal DNS servers.


Searching the log

Since the normal Current Events view in the Praetor administration MMC snap-in is a running log of all messages processed that is updated in real-time, it would be inconvenient to use this when searching for a particular message to review and release. The administration program provides a search capability that will query the database and generate a report based on specific event criteria and fields.

Upon selecting the event type in the right pane, you will be presented with a selection dialog with two different tabs, with the Event tab shown first to confirm that selection. The Message Date Range group box will be visible in either tab.

If you have message field criteria to query, press on the Fields tab to specify them.

Combined use of the event and the To recipient email address will quickly locate specific messages for your local user.

Note:

The field criteria uses a substring search so a partial entry (e.g. user name portion of the email address) may be sufficient.

Once you have specified the criteria, press [image] to start the query. The report will appear as an additional node under the Find node in the left pane.

The node is named by your criteria using abbreviations for the events according to the following table:

Abbreviation | Action | Action Type
A | Accepted | Terminal
AP | Approved by user or administrator after review | Disposition
AR | Archived | Optional
F | Forward | Optional
N | Send a notification message to a specific address | Optional
NA | Send a notification message to the administrator | Optional
NR | Send a notification message to the recipients | Optional
NS | Send a notification message to the sender | Optional
Qu | Quarantined, unprocessed | Terminal
Qp | Quarantined, processed by user or administrator | Terminal
R | Rejected | Terminal
RD | Redirected | Terminal
RF | Refused by user or administrator after review | Disposition
RSO | Return to sender with original message | Terminal
RSS | Return to sender with summary | Terminal

Note:

The report generated by the Find command is static. It will not automatically update the list of entries in the right pane as new messages are received that match your specified criteria. You can, however, right-mouse click and select Refresh which will cause the query of the then-current database to be performed, as shown below.

Since the result of each query is static, any column can be sorted by pressing on its header title.

Modifying query reports

As a convenience Praetor administration MMC saves into memory the search criteria used to create the report node in the left pane. As long as this administration program is running, you can simply select the node and right-mouse click to select Modify query to change your criteria.

Upon selecting to modify the saved query, you will be presented with the Find By Event dialog box where you can choose between the Events and Fields tabs.

Removing query reports

To remove any report, highlight the node in the left pane and right-mouse click to select to remove it.

Refreshing query reports

If you selected a non-custom date criteria such as Today or Yesterday in the Find By Event dialog box, the query is a moving window which you can easily refresh with recent entries. Simply right-mouse click and select to refresh.


Install Praetor PLGV

Installing the Personal Log Viewer

Warning:

If you have antivirus software running on the Praetor machine, it is imperative that you stop it from operating while you are trying to install Praetor. CMS has found that some antivirus products will prevent successful installation.

Also you must configure it so that it will not scan the Praetor and IIS folders. The paths for these are typically

  • C:\Program Files\CMS Praetor G2,

  • C:\G2-Archive and C:\G2-Quar (for maintenance tasks), and

  • C:\InetPub\mailroot

Antivirus software will cause unpredictable behavior and interfere with Praetor normal operation. You will see errors logged into the Windows Event application log.

The Praetor Personal Log Viewer (PLGV) is an application that runs under the Microsoft Internet Information Services (IIS) web server. Its purpose is to give your users a way to access the messages that Praetor has quarantined by using their web browser. These quarantined messages never reached your mail server, instead residing on the Praetor machine. By giving them access PLGV allows the user to release any message they believe to be incorrectly quarantined, without the help of the Praetor administrator.

This page shows how this PLGV web application is installed. You must make certain that the IIS web server is already installed on this machine.

Note:

Due to the additional resource drain, this capability is not installed by default. CMS recommends that you determine if the Praetor machine has enough available CPU resources before proceeding to install these IIS and Praetor components.

When you first run the installer for PLGV, you will be greeted with the opening screen.

Press [image] to proceed to the folder location screen, allowing you to change the either the location and/or the drive from the default.

Press [image].

At this point, the installer program is ready to begin its process, so press [image].

You will see the above progress bar as the installation process proceeds with the PLGV files placed in C:\inetput\wwwroot\PLGV. When the installation process is completed the following will appear.

Press [image] to close the installer program.

After properly configuring PLGV your users will now be able to use their browser to access their quarantine messages. The URL address will be http://Praetor-IP-address/PLGV.

Next


Configuring PLGV

Configuring PLGV is performed by using the PLGVAdmin tool which can be found in the CMS Praetor G2 program group from [image] as the item PLGV Setup. Running this will display the opening screen below.

This PLGVAdmin tool can be found in the Praetor program group and allows you to control the following items:

  1. Authentication method for logging into PLGV via a browser.

  2. Maintaining the user list, if you are using the SQL table as your selected method of authentication. Or identifying those users who will have administrator capacity for Praetor.

  3. Specifying the SQL Server and its authentication method and connection timeout.

Next


Authentication method

When your user attempts to connect with PLGV via his/her web browser, they will be presented with the login screen that is dependent upon what authentication method you have selected in PLGV Admin. When they supply their credentials, PLGV will

  1. Determine if the credentials can be authenticated

  2. Get their corresponding email address(es) if the authentication is successful

As installed PLGV is designed to first attempt to use the built-in Windows authentication when the URL of http://local-IP/PLGV/ is provided as the address for the browser. If Windows authentication fails, the browser is automatically redirected to http://local-IP/PLGV/Weblogin.aspx which will then perform the authentication shown in the PLGV Administration program opening screen below.

The default is the SQL table authentication method. This means it will check against a user table in the SQL database, which is how the default administrator login exists. You can change the authentication method to use LDAP. Here is information regarding the various authentication methods available.

  • Stand-Alone SQL table

Table-driven method for Lotus Notes/Domino, Novell GroupWise, or any non-Exchange site. The table needs to be set up with:

  • Adding login and password information for each user

  • Adding all email addresses associated with the login

This is conveniently performed using the import facility found on the User tab page.

  • LDAP with Active Directory

This method uses a LDAP query to the Microsoft Active Directory for Exchange 2000 and 2003 servers. While there is very little setup needed, users can only view their own quarantined messages (i.e. to their registered email address) and no others.

In the field provided, enter the IP address of the LDAP server.

If it is necessary to specify an account to perform such queries against your LDAP Server then check the box for Account with Read Access to LDAP Server, and enter that information in the fields provided.

  • LDAP with Exchange v5.5

This method uses a LDAP query to the Microsoft Exchange 5.5 server. While there is very little setup needed, users can only view their own quarantined messages (i.e. to their registered email address) and none others.

In the field provided, enter the IP address of the LDAP server.

If it is necessary to specify an account to perform such queries against your LDAP Server then check the box for Account with Read Access to LDAP Server, and enter that information in the fields provided.

Also, you will need to enter the Exchange information for:

  • your organizational unit name (OU)

  • your organization name (O)

Press [image] to save your authentication settings.

Return to configuring PLGV


User list for PLGV

User access list

When first installed, the PLGV user list is blank as shown below. If you choose to use the SQL table method of authentication, then you will need to populate this list. Choosing the LDAP method means you will not need to populate the list because it will be done automatically via LDAP. Nevertheless, you will need to identify those users who will have the role as administrator.

This page discusses:

  • Populating the user list by importing

    • complete information

    • summary information

  • Manual entry

  • Setting or changing the user password

  • Viewing errors

Populating the user list

There are three different methods of populating this list if you are using SQL table authentication.

  1. Import from a file containing complete user information including login name, first name, last name, password, and a list of email addresses to be used with SQL table authentication.

  2. Import from a summary file containing login name and a list of email addresses to add more email addresses for that user to review. This is typically used to allow an administrative or departmental assistant to review quarantined messages for others.

  3. Enter manually the identity for an individual.

Import complete user information

This is the default File Format selection when importing a file (button for Complete user name format). It performs a bulk import of the detailed user information and is used primarily with the SQL table authentication method when logging into PLGV.

The input file must contain the following comma-separated information, one user per line.

  1. Login name

  2. First name

  3. Last name

  4. Password

  5. Role of either "User" or "Administrator"

  6. One or more email addresses

A sample is provided in the SampleUsers.TXT file found in the PLGV folder that appears when you press [image]. This file has the following entries as examples.

dan,dan,deward,secret,User,dan@acme.com,info@acme.com,sales@acme.com
joe,Joseph,Blowseph,secret,User,joe@acme,joe2@acme

A simple way to obtain this is to use Control Panel's Administrator Tool called Active Directory Users and Computers.

Importing this sample will display the following:

Import summary user information

The File Format selection button labeled User name and email address only format is made when importing a summary user list. It is typically used with LDAP authentication method since much of the login information is automatically populated when the user logs into PLGV. This import format can also used to define more email addresses for individuals such as a departmental or administrative assistant when their login information already exists.

The input file must contain the following comma-separated information, one user per line.

  1. Login name

  2. One or more email addresses

A sample is provided in the SampleEmail.TXT file found in the PLGV folder that appears when you press [image]. This file has the following entries as examples.

joe,joe0000@acme.com,joe0001@acme.com
dan,test@msn.com
dan,xxx@hotmail.com
dan,yyy@yahoo.com

Importing this sample file (after the previous SampleUsers.TXT file) will display the following:

Notice all the additional email addresses associated with the first user.

Manual entry

Entering a new user is simple matter of providing:

  • User name (for login), and their first and last names in the main window

  • The email address(es) associated with the user login, and

  • Role of either "Administrator" or "User". If none is provided, the role is assumed to be "User" by default.

As you enter these values, please remember to use the Enter key when you are done within each of the three windows. This will re-position your cursor onto the next (blank) line. If the cursor is not on the next line, your entry may not be registered.

As an example, the screens below illustrate the entry of each of the items in the three windows for user login information, email address, and roles.

At this point, note that the user line needs to be re-selected and then we can position the cursor to the email address field. Don't forget to press the Enter key after typing the address to get the blank line!

Now the role of "Administrator" or "User" can be entered. If left blank, then "User" is the default.

Again, don't forget to press Enter key to get to the next line.

Press [image] to have the new user entry saved to the Praetor log database. Your user selection will then jump to the very first entry since it re-reads the user table from the database.

Setting or changing the user password

Dealing with passwords is only applicable if you are using the SQL table authentication method since other methods will authenticate using the submitted credentials against the LDAP server or Windows domain controller.

To set or change the password for a user, select the user from the larger window and press [image]. A window appears to prompt for the new password and to confirm it by re-typing the same password.

If the two passwords entered match, then the change occurs immediately even though [image] remains grayed out and unclickable.

Viewing errors

Should this PLGV administrator tool encounter any errors in accessing the database, or discovery any inconsistency with the information, this [image] button will become active and you can press it to see the detailed errors found.

Return to configuring PLGV


SQL Server setup for PLGV

SQL Server setup

The PLGV web application also needs to know the location of the SQL Server that manages the Praetor log database, just like the Praetor filter. This is only significant if you relocated from the MSDE desktop edition to the full Microsoft SQL Server. To make this change, you need to use the PLGV Administration tool on the SQL tab page as shown below.

Here are explanations for each setting on this page.

Server field

Enter the name of the new SQL Server handling the Praetor log database.

Note:

If you installed SQL Server on top of MSDE, you will do so with a named instance. In this case, enter Machine name\Instance name in the Server field.

Use Windows authentication

The authentication on this screen is used by the PLGV web application connecting with the SQL Server. It does not pertain to how your users with authenticate with PLGV as described in the authentication method section. Unless you know otherwise, use the default Windows authentication.

Use SQL authentication

Select to specify that PLGV use SQL authentication to access the Praetor log database. You must also provide the username and password.

Connect timeout

This is the maximum time for PLGV to wait to establish a connection to the SQL Server. The default is 120 seconds.

You may need to increase this if your Praetor is filtering a lot of messages and keeping the SQL Server very busy.

Command timeout

This is the maximum time for PLGV to wait for the SQL Server to complete the query. The default is 300 seconds.

You may need to increase this if your Praetor is filtering a lot of messages and you have many millions of entries in the log database. In such a cases, your users will find PLGV is unresponsive and a SQL command timeout message appears in their browser.

Testing the connection

If you change the SQL Server, you should test the connection by pressing [image]. A Testing SQL Connection String window appears, allowing you to modify the connection string and begin the testing.

If it is successful, a confirmation window will appear very quickly as shown below.

If the test is unsuccessful it will continue for the specified connect timeout period and eventually an error window will appear.

Note:

If you do not test the connection and the server specified is wrong, the next time you try to use this PLGV Administration tool will take a long time because it attempts to connect with your SQL Server until the connection times out.


Log Viewer via browser

An important feature in Praetor G2 is the ability to use a web browser to review inbound messages that were quarantined. It is known as the Praetor Personal LoG Viewer (PLGV). Users can then release any good messages that have been incorrectly quarantined by Praetor's filters.

This is an optional capability and you need not install or use this if you choose not to let your local users to self-administer their quarantined messages or if the machine does not have sufficient resources. If you choose to use it, PLGV is an application web site that must be set up under the Microsoft IIS web server. You will need to install this capability and then configure it.

Note:

CMS has successfully tested PLGV access using Microsoft Internet Explorer (IE). Even then, it is important to note that you cannot do so via a proxy server and PLGV must be directly accessed from your IE or you set up within IE an exception for the PLGV URL to bypass the proxy server. Otherwise you may see the error

You are not authorized to view this page.

This happens even if you try to view the default IIS web server page localstart.asp. Read more about this in the Microsoft KnowledgeBase article Q321488.

For the Mozilla Firefox browser CMS is aware of an incompatibility due to the reliance of IIS web features.

To start this web browser access, use your web browser and enter the URL http://IP-address/PLGV/ for the Praetor machine, either using the numeric local IP address or the machine domain, and followed by the following two possibilities depending on the authentication method.

Authentication method | URL to PLGV login page
Windows (built-in) | http://IP-address/PLGV/
SQL table or LDAP (also used when Windows authentication fails) | http://IP-address/PLGV/Weblogin.aspx

Note:

Windows authentication is built-in, and if it fails, the browser will be re-directed to display the Weblogin page which uses the SQL table as the default method.

If you want to bypass Windows authentication, then tell your users to use the Weblogin URL. Directing the browser to this URL will always prompt for the login information, even if saved. This is the preferred page if the user is trying to log in from a public computer such as one found at an Internet café.

The Praetor Log Viewer sign-on page then appears as shown below for the SQL table authentication method. The login screen is are slightly different for LDAP authentication which adds a domain field, and the Windows login is the same as you see when you log into your computer.

Here the user can enter their login name and password. If their account has been set up to allow access, then the user is granted access to their own quarantined message area. The Log Viewer main home page appears and they can select what period of their personal message log to view the summary entries.

As the screen warns, do not save the sign-in if this machine is used by others.

Note:

The login is case-sensitive.

Also, there are active links in the graphic below to describe the function of the button or field.

From this main PLGV home page the user can do the following:

  • Sign out of the PLGV session

  • Change their password

  • View their inbound message log entries

  • Select message criteria to filter the log entries

  • Reset the message criteria fields

Signing out

Signing out of your PLGV session is important for security purposes, if you use a public computer to access your personal message log. Anyone who tries to use the same machine to access PLGV will then have to provide a valid user login and password.

Changing password

Pressing [image] at the top of the screen will allow you to change the password used for logging into PLGV. This link only appears if you are using the SQL table authentication.

As shown, you must provide the new password twice to confirm it. Press [image] to save the password change.

Viewing entries

After making the appropriate period selection, pressing [image] will then show a summary of all the messages that Praetor processed for that particular user. If the user is an administrator, the log entries shown will be for all messages processed during the period.

The information summarized are:

  1. Action taken with the message

  2. Date and time stamp when Praetor received the message

  3. Buttons to deal with the message:

    • To review the message in detail, or

    • To approve it

  4. Sender address

  5. Subject

  6. Recipient address (who is the user logged in, unless that user is the administrator)

  7. Reason or rule name involved with that message

  8. Similar action buttons as #3 above

Note the use of colors, with lines containing red letters indicating that the message was quarantined and available for release. The yellow highlighted line is one that is selectable. Usually it is enough to see the sender and subject from the above screen, and tell if a quarantined message is non-spam. If that is insufficient, you may click on the summary line to open the message and see the details.

On this message details screen you will find the reason why the message was quarantined along with the message contents in its original and raw form. The raw state of the message displayed in the scrollable window means that attachments will appear in their encoded form so you cannot get infected from viewing any virus in this browser.

The example below cites the reason as being a message whose spamicity or spam probability value is very high, exceeding the threshold set for spam (default is 0.60).

If you want to release the quarantined message, simply press [image]. Praetor will then pass the message for delivery to the mail server and you will receive it in your email client.

Note:

CMS did not put a Reject button because that is just a needless step for users to take that also causes the web server to waste CPU cycles. Instead, you should rely on the automated scheduled maintenance task which will age and purge old quarantined messages.

Resetting fields

Pressing [image] will clear any selection criteria you previously chose to filter the log entries, and return back to their defaults which are:

  • Since last sign-in

  • No message attributes filtered


Filtering log entries

When you have logged into PLGV using your web browser, the main home page displays provides a selection criteria to filter the personal log entries for the inbound messages. Keep in mind that while the primary filtering criterion is the date, the other criteria are "ANDed" together to filter the log entries. Therefore only those entries matching all the selected criteria will be displayed.

Administrators have an additional criterion that allows them to select among the user available login names.

Click on any link in the above screenshots or as provided below.

  • Date and

  • Other attributes

    • From address

    • To recipient (user only)

    • Subject text

    • Praetor action event

    • User Name (administrator only)

Once the filtering criteria has been selected, pressing [image] on the PLGV home page will display all the message summary entries in your personal log.

Date criterion

Selecting the date criterion is the primary filtering method for viewing your message log entries. This filter is active whether or not you have any other filtering criteria based on the message attributes.

For the date selection, you have several choices:

  • Since last login

  • Past several days with a drop-down box for 1 to 3 previous days including today

  • For a particular date range

  • On a specific date for a particular time range

From address

This field allows you to specify the sender address to search through your personal log entries for the specified date criterion. Any entries found matching whose sender address contains the string you specified will be listed.

To recipient (user only)

This field is only significant if the user has been set up to allow reviewing messages destined to more than one recipient email address. The drop-down box will show any other available addresses in ascending alphabetical sorted order. The note adjacent to this field shows how many addresses have been set up for this logged in user.

Typically this feature is used to allow the department manager, administrative assistant or departmental secretary to review quarantined messages for others.

Subject text

This field is used for searching on specific text in the Subject field of the message.

Praetor event

This field selects the specific action that was performed on the message being searched. Available through the drop-down box, the choices are:

  • ANY

All messages

  • ACCEPTED

Messages that Praetor allowed to pass to the Inbox either because:

  1. A rule was triggered with the resulting action to accept the message, or

  2. No triggered conditions were found so the message survived all inbound rules

  • QUARANTINE

Messages with triggered conditions who rule action was to be quarantined

  • REJECTED

Messages with triggered conditions who rule action was to be rejected resulting in its deletion

User Name (administrator only)

This selection criterion allows the administrator to look at all those messages received by a specific local user. Enter the email address for the user or any uniquely identifiable portion of the address.

Note:

You can only find mail summary entries for those users who have successfully authenticated themselves and logged into PLGV once before. This is because until such time, PLGV will not know what email addresses are associated with their login user name.

Next


Protocol log

SMTP Protocol Log

Note:

Starting with the Praetor v2.1 release of April 2005, CMS no longer recommends that you use SMTP protocol level DNS Blacklist Filtering. Instead, this filtering will be performed at the message rule level. The reason for this is the growing frequency that this technique comes under a denial-of-service attack by spammers who have changed their tactics. For more information on this, click here.

Thus by default this node does not appear in the left pane. It will only appear if you have contacted CMS Support to re-enable this technique.

Praetor records SMTP protocol filter events into a separate container from the normal message events. Typically these will be for events when a message is refused by Praetor, such as the case for messages originating from a DNS blackhole listed mail server.

Each unsuccessful attempt by any sending mail server that attempts to send a message to Praetor is shown on a line that provides:

  • Date and time of the failed attempt

  • Event source (type of Praetor filter that refused the message)

  • Connecting IP address of the sending mail server, and

  • Any additional information, such as textual from the DNSBL for listing the IP in its blackhole list

Return


SMTP Server log

SMTP Server log in IIS

IIS provides an SMTP Server log that can record extended information during inbound reception and outbound transmission sessions. This is configured using the IIS Manager or Exchange Administration by viewing the SMTP Server properties.

Make certain that you check Enable logging and select an Active log format of W3C Extended Log File Format. You can also press [image] to select other settings including the location where these log files will be placed.

In the above example, the path to the log file will be C:\Windows\System32\LogFiles\SMTPSvc1 and have the date-based file name of exyymmdd.log. For example, the log entries for June 23, 2004 will be found in:

C:\Windows\System32\LogFiles\SMTPSvc1\ex040623.log

On the Extended Properties tab, please be sure to select all the available properties. This will be useful when the CMS support technician assists you in tracing message delivery problems.


Managing templates

Managing return-to-sender templates

When you are inspecting a quarantined message and choose the Return to sender action, the main Return Message to Sender window appears as shown below. Notice that no template is selected and all the message property fields are blank. You can immediately enter the information to be returned with just this message alone, or you may create templates that can be used for other quarantine messages that are to be returned.

Press [image] to create new templates.

Using pre-created templates is simple — just chose the appropriate one from the drop-down list.

Note:

The templates you see above are merely samples for documentation purposes only. Praetor does not come with any factory-supplied templates and so you will see the following when you press [image].

To manage the available templates that have pre-defined message subject and body text, press [image]. The Manage Templates window appears and lists any templates that have already been created as shown below. Here buttons are available to create a new template (Add), edit (Edit) or delete (Remove) an existing one.

Creating a new template

Pressing [image] creates a blank template where you may enter the template name and define what text should appear in the subject and message body whenever the template is used to return a message to the sender.

Press [image] when you are done entering the information for the new template.

Edit an existing template

To edit an existing template, select it and press [image]. The saved subject and message body text will be displayed and may be edited.

Press [image] when you are done with your changes.

Delete a template

To delete a template, simply highlight the template from the list and press [image].


Overview

Log Analyzer

The Praetor package includes a Microsoft Access database application called the Praetor Log Analyzer. This prLog.MDB file is located in the main Praetor subdirectory, C:\Program Files\CMS Praetor G2 if Praetor was installed on local drive C. You may copy this file to any machine that has Microsoft Access already installed and can access the SQL Server machine where the Praetor log database is found (the Praetor machine in most cases).

This application has several useful reports that were developed to summarize and provide statistics of the email traffic that flowed through Praetor:

  • Overall traffic summary

  • How many messages were rejected, quarantined, accepted, re-directed, or returned to the sender.

  • Sender domain report for email received from the Internet.

  • Destination domain report for email sent to the Internet.

  • Recipient address report for email delivered locally.

  • Destination address report for email delivered to the Internet.

  • Rule report for showing which messages were filtered or accepted.

  • IP addresses of the most frequent sources of reverse NDR attacks.

And many more as you will see in this section. Each report may be sorted alphabetically or by frequency.

After the proper data source has been specified the main screen for this Log Analyzer application will appear.

Main switchboard menu

Proceed to the Configuration page, which will show you how to initially set up the analyzer program with your SQL database server and local domain names. The main sections accessible through the main switchboard menu that you see above are:

  • Events to see what actions were taken on various messages and which rules caught them.

  • Reports to see a summary of various message details such as domain names and recipient addresses.

  • Special reports like the traffic summary and those which are IP-centric such as those for the Reverse NDR.

  • Configuration of your SQL Server data source and defining the local domains

Note:

Unlike the previous Praetor v1.5 there is no need to import the log data because all the entries are now found in a SQL Server database. You also will no longer need to define your local domain names which previously was used to determine message direction; this information is already in the SQL database.


Configuration

As delivered the Praetor Log Analyzer utility is an Access database that is unconnected to the data source and does not know about your local domains. These need to be set up by going into the Configuration menu where you will see the following screen.

Configure Data Source

Pressing this menu item allows you to set the data source to be the SQL database maintained by the MSDE or SQL Server. You will be presented with the following screen asking you to identify the database server.

Assuming your machine with this analyzer application has been properly set up to access SQL Servers in your network, the drop-down list will be populated with all the visible servers. Select the appropriate server and press [image] .

Configure Local Domains

Since Praetor can be configured to accept messages for multiple local domains, some domain-centric reports are available and you may choose from among them. Thus this analyzer needs to know the various domains you have locally. Selecting this menu item will display the following screen.

Enter all your local domains and press [image] in the upper right corner to close the window when you are finished.


Event Overview

Pressing the Event button from the main switchboard will display the Event summary submenu and the following screen.

This submenu allows you to see the details of how Praetor dealt with the messages, both incoming and outgoing. The following selections are available from the various buttons you see above.

  • Events

Full listing of all log entries in tabular form sorted chronologically, just as if viewed from the Praetor Log Viewer application.

  • Event Viewer

Detail view of each log entry, presented one at a time in chronological order.

  • Event Count

Summary by count, organizing the various actions that took place on the messages: accepting, archiving, rejecting, quarantine, etc.

  • Rule Summary

Summary by count of message disposition as organized by the rules that caught them.

Pressing the button for Return to Main Switchboard will return you to the main application menu.


Report overview

This submenu allows you to obtain various reports summarizing the messages that passed through Praetor. Once displayed these reports may be printed.

The following selections are available from the various buttons you see above.

  • Domain Summary

This report shows, in either ascending alphabetical or increasing count order, the source or destination domains for messages that Praetor has processed.

  • Event Summary

This report shows the message count for all the different event results. While similar to the selection under the Event submenu, it differs in that the resulting display is printable and you are not able to get detail view for each event type.

  • Log Entries by Specific Criteria

Use this to create a custom report you based upon your desired date range, event type, and display format.

  • Recipient Summary

This report shows, in either ascending alphabetical or increasing count order, the recipient addresses (local for inbound and destination for outbound messages) found in messages processed by Praetor.

  • Rule Summary

This report shows the message count for all the different active rules in Praetor. While similar to the selection under the Event submenu, it differs in that the resulting display is printable and you are not able to get message detail view for each rule.

  • Sender Summary

This report shows, in either ascending alphabetical or increasing count order, the Internet (for inbound) or local (for outbound) sender address found in messages processed by Praetor.

Pressing the button for Return to Main Switchboard will return you to the main application menu.


Special reports

IP Reports

These reports are all based upon the IP address as the principal criteria. Pressing this report button brings up the following display.

There are several useful reports available, all ordered in decreasing frequency according to the date range specified below. Click on the links provided in the Report column to see a sample of that report.

Report | Description
Reverse NDR attack | Shows the source of spammers using the Reverse NDR attacks to make your mail server into an indirect relay.
Protocol DNSBL | Shows the mail hosts filtered by the SMTP protocol level DNSBL test, if enabled.
Msg-level DNSBL | Shows the mail hosts filtered by the message level DNSBL test, if protocol level is not enabled.
Connecting IPs By Rule | Shows the mail hosts whose messages were caught by Praetor's rules.

Reverse NDR attack

Protocol DNSBL

Msg-level DNSBL

Connecting IPs By Rule

Traffic Summary

This is one of the most useful reports available as it shows the overall statistics for messages organized by the ultimate disposition (accepted, rejected, quarantined, etc.) as its main category, and the rules as the subcategory. Thus, at a glance you can see how much spam you are getting, and how much is being caught by DNSBL or the Bayesian filter.

Pressing this button will display the following selection screen.

From here you can choose the time period and domain for the analysis. Leaving the domain field blank will analyze across all declared domains. Here is a sample excerpt of this report.

In the above sample, 31% of the mail arriving were quarantined and the approved number of 0.03% represents the false positives which are good messages that were caught as spam.

When the Reverse NDR rule enabled, the amount being reported under the REJECTED events (not shown above) with that rule name will indicate if you are under attack. The number reported will be very high if your site was under heavy Reverse NDR attack, and you should use the special Reverse NDR report to determine the source IP addresses that are the major launch points of the attack. That way you can put on your local blacklist in the IIS SMTP Server Connection control settings found on the Access tab of the Default SMTP Server properties.


Overview

Praetor ships with various administrator tools that can be used to manage it. Mostly these are command line programs that are found in the Praetor Tools folder, typically C:\Program Files\CMS Praetor G2\Tools.

Name

Description

  • CFGSAVE

Save Praetor configuration files.

  • Maintenance tasks

Schedule daily task at 2am (default) to save Praetor settings and clean the Archive and Quar folders of old messages by moving those older than 7 days to C:\G2-Quar and C:\G2-Archive. Files older than 30 days will be purged.

  • MODLIST

Access and manage the Praetor lists, which can be used to automatically update them.

  • MOVEQUAR

Age and move old message files in Praetor's quarantine folder based on the specified number of days to another location and/or drive. This tool can also be used on the messages in the archive folder

  • POPTRAIN

Populate the training folder with raw message files, either from Praetor v1.5 or G2 itself.

  • PURGEQUAR

Age and purge old message files in Praetor's quarantine folder based on the specified number of days. This tool can also be used on the messages in the archive folder.

  • SQL Scripts

Several script tools to manage the Praetor SQL database and its contents

  • User list export

Extract the local users' email address to combat Reverse NDR attacks.


CFGSAVE

Program file:

CFGSAVEG2.EXE

Purpose:

To save the Praetor configuration and registry settings into the CFG.ZIP compressed file. This file can then be sent to CMS for investigating any support issue. It can also be used to transfer Praetor settings (stored in the Praetor RULES.DAT, LISTS.DAT, and PraetorScript.TXT files) onto another installation so that identical rules and lists are being used.

Usage:

CFGSAVEG2 <parameters>

where:

/ARCHIVE or
/ARCHIVE:NN

Archives any existing CFG.ZIP before proceeding by renaming it to a filename based on the date and time of the form CFG-YYYYMMDD-HHMMSS.ZIP in the G2\BkpFiles folder,

Example: CFG-20040729-130522.ZIP

If the additional archive parameter NN is specified, CFGSAVE will age and purge those ZIP files older than NN days.

/SHORTLIST

Directory listing showing the contents of Praetor's ARCHIVE and QUAR folders, truncating the listing if needed to prevent the GENERAL.TXT report file from growing too large.

/HELP or /? or ?

Displays this usage info.

Example:

CFGSAVEG2 /Archive:7 /SHORTLIST

Other:

This command is invoked by the daily maintenance scheduled task.

Overview


Maintenance tasks

It is very important that you set your antivirus so that it does not scan the G2-Quar and G2-Archive folders located at the root of the same drive where the Praetor folder can be found. Otherwise, the antivirus scanner may prevent the maintenance task to purge old files and thereby hang the system. You can pre-create these G2-Quar and G2-Archive folders at the root of the drive where Praetor is installed.

If you have Praetor quarantining and archiving messages, eventually you will accumulate many of them. When their numbers become excessive, Windows has a problem dealing with so many files in the Praetor folders. You can see this whenever Windows Explorer takes a long time to display the files in the main Praetor folder (\Program Files\CMS Praetor G2) since it examines one level of subfolders such as Archive and Quar.

To prevent this from happening, Praetor was installed to perform nightly housecleaning of the various folders. This is done by using the native Windows Task Scheduler to do the following at 2am every night:

  1. If needed, create the backup QUAR directory \G2-Quar, the backup Archive directory \G2-Archive, and the backup Training directory \G2-Train on the same drive as where the Praetor files are installed.

  2. Save the Praetor configuration into CFG.ZIP, moving the previous into the Praetor G2\BKPFILES folder and purge all saved configurations older than 7 days.

  3. Moves QUAR, ARCHIVE, and TRAIN messages that are older than 7 days to \G2-Quar, \G2-Archive, and G2-Train, putting each EML file into a subfolder whose name is the date, e.g. 2004-08-25.

  4. Purges subfolders in \G2-Quar, \G2-Archive, and \G2-Train that are older than 30 days.

  5. Purges all SQL database entries that are older than 30 days.

If you want to change the number of days from these defaults simply edit the G2-daily.BAT file accordingly. This file is located in the Tools folder, e.g. C:\Program Files\CMS Praetor G2\Tools.

Note:

The messages moved out of the Praetor Quar folder to C:\G2-Quar will no longer have details accessible via the Log Viewer. To the Log Viewer, these messages are simply gone.

Since the EML filename is visible to the administrator, it is a simple matter of moving that file back into the Quar folder. Once returned, the message details will be visible once more. If you don't want to expend the effort of locating that one EML file, just move all the EML files from the dated folder in C:\G2-Quar back to the Praetor Quar folder. By 2AM the next morning, MOVEQUAR will return all these EML files to its dated folder if any of those messages were not approved by your user.

Overview


MODLIST

Program file: | MODLISTG2.EXE
Purpose: | This tool is used to manage the various Praetor lists. It is invoked from a command prompt or batch file with one or more parameters. If importing new list entries, the change takes effect immediately with the very next message.
Usage: | MODLISTG2 <command> <parameters>. See below.
Other: | You can display a help screen by invoking this program with '?' as the one and only parameter.

Command and parameters

Description

/HELP or /?

Display a command summary.

/SORT: <list>

Sort the items of the specified list.

/CLEAR: <list>

Clear all entries from the specified list.

/CPYITEMS: <source-list>, <destination-list>

Copy all entries from the source to the destination list.

/MOVITEMS: <source-list>, <destination-list>

Move all entries from the source to the destination list; source list is empty.

/EXPLISTS: <summary-file>

Export a summary of the Praetor lists with all their entries into the text file specified.

/SETLISTS: <summary-file>

Restore the Praetor LIST.DAT file with the lists found in the specified summary file. NB: There is no space after the colon.

This command will also backup the original Praetor.DAT file is made before restoring, giving that backup copy a name of the form PRAETOR.<yyyymmdd> where the date is used as a 8-digit extension.

/EXPRULES: <rule-file>
Export a summary of rules to the specified file.

/MODIFY: <list> /INP:<input-file>

Modify the list with entries found in the specified input file. Each line of this file can be one of the following:

+<item> to add the item

-<item> to remove the item

Example:

Line | Comment
+ILOVEYOU.vbs | add the text string "ILOVEYOU.vbs"
+xyz | add "xyz" to the list
-Test.exe | delete "Test.exe"

/ADDITEMS:<list> /INP:<input-file>

Add the items found in the input file into the named list. The input file must have 1 item per line without the need for the '+' or '-' character in the first column position.

For a checked list, you need to have either a space to indicate unselected entry, or a '>' for a selected checked entry.

/DELITEMS:<list> /INP:<input-file>

Delete items in the specified file from the named list. Format of the input file is one entry per line without the need for the '+' or '-' character in the first column position.

MODLIST can be invoked either with individual commands or a single command file can be created with all needed parameters and then invoked with the command file specified as a parameter.

MODLISTG2 command-file

To see the names of the various lists used by Praetor's numerous selectable conditions, click here.

Note:

The underscores in the list names and case are significant and must be used when using MODLIST tool although they appear without underscores in the Praetor administration program. Also, be sure all input-file entries are immediately followed by a carriage return-line feed (CRLF) end-of-line terminator. Any trailing spaces between your entry and the CRLF will be considered as significant and will be imported into the list.

Unintentional trailing spaces are not obvious when the list entry is show on-screen and may cause Unexpected filtering results because the search using that list will fail to match on the entry.

EXAMPLE - manual invocation

Invoke the program twice as follows:

MODLISTG2 /MODIFY: _approved_local_address /INP: manual.txt

MODLISTG2 /SORT: _approved_local_address

where manual.txt contains:

+John.Galt@mydomain.com
+Dagny.Taggart@mydomain.com
+Jerome.Horowitz@mydomain.com

EXAMPLE - automatic invocation

Place these following entries into a file called Auto.txt:

/MODIFY: _approved_local_address
+John.Galt@mydomain.com
+Dagny.Taggart@mydomain.com
+Jerome.Horowitz@mydomain.com

/SORT: _approved_local_address

Invocation:

MODLISTG2 Auto.txt

EXAMPLE - recommended automatic invocation

Combining the concepts introduced in the above two examples, here is the recommended method to use if you can automatically generate the list of entries into a file.

Using the sample manual.txt file, place these following MODLIST commands into a second file called AutoInp.txt.

/MODIFY: _approved_local_address /INP: manual.txt
/SORT: _approved_local_address

Next, using a scheduling program, invoke MODLIST as follows:

MODLISTG2 AutoInp.txt

Overview


MOVEQUAR

Program file:

MOVEQUARG2.EXE

Purpose:

This tool is used to age and move message files in the Praetor\Quar folder to another location and/or drive that are older than the number of days specified.

Usage:

MOVEQUARG2 <Data full path> <Dest full path> <#-of-days-retention>

Data path is the directory location where the *.EML message files can be found.

Example:

MOVEQUARG2 "C:\Program Files\CMS Praetor G2\Quar" "D:\G2-Archive" 5

This invocation will take Praetor *.EML message files found in the folder path C:\Program Files\CMS Praetor G2\Quar and move those that are older than 5 days to the drive D in D:\G2-Archive.

Note:

The destination must already exist! Otherwise MOVEQUARG2 will report this as an error and no files are moved.

You can also use this to purge old files that are in the archive folder by specifying a path of "C:\Program Files\CMS Praetor G2\Archive".

Other:

You can display a help screen by invoking this program with '?' as the one and only parameter.

This command is invoked by the daily maintenance scheduled task.

Overview


POPTRAIN

Program file: | POPTRAIN.EXE
Purpose: | This tool is used to import message files into the training folder. Depending on the commands and parameters, message files can be either in v1.5 *.CMS or G2 *.EML formats, and can be placed either in the GOOD or BAD [image] folder.
Usage: | POPTRAIN -f <message-format> -t <message-type> -d <data-path> Message format number: 1 : v1.5 *.CMS format 2 : G2 *.EML format Message type: 1 : BAD folder 2 : GOOD folder Data path is the directory location where the source message files can be found. Example: POPTRAIN -f 1 -t 1 -d "c:\temp\bad" This invocation will take Praetor v1.5 *.CMS message samples located in the directory c:\temp\bad and populate the Train BAD [image] list.
Other: | You can display a help screen by invoking this program with '?' as the one and only parameter. This command is invoked by the daily maintenance scheduled task.

Overview


PURGEQUAR Age and Purge Tool

PURGEQUAR

Program file:

PURGEQUARG2.EXE

Purpose:

This tool is used to age and delete old message files in the Praetor\Quar folder.

Usage:

PURGEQUARG2 <full path> <#-of-days-retention> [ /FOLDERSONLY ]

Data path is the directory location where the *.EML message files can be found.

/FOLDERSONLY is an optional parameter which tells the program to delete date-style subfolder names at the destination path, and their contents. These subfolders were created by the MOVEQUAR tool.

Example:

PURGEQUARG2 "C:\Program Files\CMS Praetor G2\Quar" 5

This invocation will take Praetor *.EML message files found in the folder path C:\Program Files\CMS Praetor G2\Quar and delete those that are older than 5 days.

PURGEQUARG2 "C:\G2-Quar" 30 /FOLDERSONLY

This invocation will take all date-style named subfolders found at the destination path C:\G2-Quar that are older than 30 days.

You can also use this to purge old files that are in the archive folder by specifying a path of "C:\Program Files\CMS Praetor G2\Archive".

Other:

You can display a help screen by invoking this program with '?' as the one and only parameter.

This command is invoked by the daily maintenance scheduled task.

Overview


SQL Scripts

Praetor installs with several scripts to help manage the growing SQL databases, specifically the PraetorLog database which contains all the message summary log entries. These script files can be found in the Praetor Tools folder and each is described in the table below.

SQL Filename

Description

Attach.SQL

Attach the PraetorLog and PraetorClassify databases to the named SQL Server. If the SQL Server is not local on the Praetor machine, then the invocation needs to provide the server name as follows:

This script also assumes the four Praetor database files (with extensions *.MDF and *.LDF) are located in the main Praetor folder "C:\Program Files\CMS Praetor G2". If your files are located elsewhere you will need to edit this file accordingly.

Del-30d.SQL

Delete all entries that are older than 30 days from the normal event, protocol, and archive tables. This is used in the scheduled daily maintenance task that runs at 2am.

Del-DNSBL.SQL

Delete all event log entries having the rule name "DNS Blacklist messages".

Del-RNDR.SQL

Delete all event log entries having the rule name "Reverse NDR attack solution".

Detach.SQL

Detach the PraetorLog and PraetorClassify databases.

MSDEstats.SQL

Display the frequency of excessive simultaneous access to MSDE which may indicate attaining the limits of MSDE. This does not apply to the full Microsoft SQL Server.

MSDEstats-reset.SQL

Reset the excess simultaneous access frequency count in MSDE.

Each script is invoked manually from a command prompt by using the OSQL database tool supplied with the Microsoft SQL Server or its free counterpart known as the Microsoft SQL Desktop Engine (MSDE). The invocation is as follows unless the SQL Server is not on the same machine as Praetor, or has a different instance name than default.

OSQL -E -i <SQL-script-filename>

If you need to identify the SQL Server, then invoke as follows.

OSQL -E -S <SQL-Server-name> -i <SQL-script-filename>

To have any script performed during the daily schedule maintenance task, add the appropriate invocation line to the end of the G2-Daily.BAT file immediately following the invocation of the Del-30d.SQL script.


Exporting the user list

User List Export

Program file:

ExpEmail.BAT

Purpose:

To export the list of local users email addresses from Domino, Exchange 5.5 and Active Directory (for Exchange 2000 and 2003). Primary method is by performing an LDAP query, though an alternative method exists for Exchange 5.5 sites.

Usage:

ExpEmail <server-type> <IP-address>

where:

<server-type> | ACTIVEDIR, DOMINO, or EXCH55 (all same case)
<IP-address> | IP for the Active Directory, Domino or Exchange server.

Example:

ExpEmail activedir 192.168.0.71
ExpEmail EXCH55 192.168.0.10

This batch file calls upon one of three Visual Basic Script files that query the Active Directory, Domino or Exchange server:

  1. GetActDir.VBS

  2. GetDomino.VBS

  3. GetExch55.VBS

The query is performed using the Lightweight Directory Access Protocol (LDAP) and will extract the list of local SMTP addresses. These exported email addresses are placed into a file AUTO.TXT along with appropriate MODLIST commands to clear the existing Approved_Local_Addresses list, import, and sort the list. MODLIST is invoked by specifying this file as a parameter:

MODLISTG2 AUTO.TXT

Once imported by MODLIST Praetor can effectively neutralize the Reverse NDR attack. Please note that you must enable the Reverse NDR rule and press [image] to put these changes into effect. Other than saving the rules, Praetor does not need to be stopped and restarted.

Recommendations for automating update

Using Control Panel's Scheduled Tasks found in Windows 2000 on the Praetor machine, you can create an automatic task to update the Approved_Local_Addresses list. CMS suggests that you create edit the G2-Daily.BAT file containing to add the following command invocations:

  1. Invoke cscript with one of the three VBS files as the command parameter, choosing the one appropriate for your server type. Example:

    cscript GetExch55.VBS     <IP-address>

  2. Invoke MODLISTG2 to update the Approved_Local_Addresses list:

    MODLISTG2 AUTO.TXT

As long as the Reverse NDR rule is enabled, the update will take effect with the very next message received.

Non-script alternative for Exchange 5.5 sites

The non-script method involves invoking the Exchange 5.5 administration program with command-line parameters. The resulting comma-separated value (CSV) file will then be converted using the utility program called MODPREP.EXE..

Here are the steps for this method, assuming Praetor is co-resident with the Exchange server. If they are not co-resident, then follow the note below.

  1. Create a file called EXPORT.CSV in the Praetor directory which has one line containing the following:

    Obj-Class,E-mail Addresses,Secondary-Proxy-Addresses

    This selects only the relevant items for each recipient in the Exchange Global Address List.

  2. Create an options file called OPTIONS.INI in the Praetor directory which contains:

    [export]
    exportobject=recipients
    informationlevel=full
    subcontainers=yes

    This will cause email addresses associated with distribution lists, local mailboxes, and remote custom recipients to be exported.

  3. From the Praetor directory, invoke the Exchange Administration program (ADMIN.EXE) using the correct path and supply the following parameters:

    <path>\ADMIN /e export.csv /o options.ini

    The path is normally \ExchSrvr\Bin. The export.csv file will contain the various email addresses and the original empty export.csv will be renamed to export.c## with ## starting at "01".

  4. Invoke ModPrep export.csv , specifying export.csv as the input file.

    This ModPrep program is a special utility that is used specifically to process the exported file from the Exchange v5.5 administration program using the OPTIONS.INI file specified in step 2. It will generate a resulting output file that contains only the local users' email addresses, one per line, that can be used as input to the ModList Praetor import/export utility program.

  5. Invoke MODLIST AUTO.TXT to update the Approved_Local_Addresses list.

Note:

Since Praetor is not likely to be on the same machine as the Exchange 5.5 server, simply:

  • Copy the two files created in steps 1 & 2 to the location where the Exchange administration program is located.

  • Invoke the ADMIN.EXE in step 3 from its own directory.

  • Copy the output export.csv file to the Praetor machine and directory.

Proceed with the remaining steps 4 and 5 as described above.

Full details on the command-line parameters and invocation of the Exchange administration program can be found in various Microsoft KnowledgeBase articles:

  • 149447 - How to Perform a Directory Export of the GAL

  • 152300 - ExportObject in Command-Line Export Options File Only

  • 153028 - How to Export Multiple (Secondary) E-mail Addresses

  • 155414 - Bulk Import/Export FAQ

Overview


App A Overview

Protocol level tests

This appendix details the various anti-spam counter-measures that IIS SMTP Server and Praetor will perform at the SMTP protocol level. Those performed by IIS SMTP Server will simply cause the inbound message to be refused or accepted, and Praetor will perform its own filtering based on the message content.

Specifically these use the connecting session IP address of the remote mail host that is trying to connect, and the following filters are available:

1.

Accept based on IP address

Purpose: | Test the sending mailhost source IP address to see if it matches one in the accepted IP address list of the IIS SMTP Server.
Action: | Accept if the IP address of the sending mail host is found in the accepted IP address list and pass on to Praetor for further processing.
Default state: | Accepted IP address list is empty.
False Positive: | This rule is very specific and will not cause any false positives.
Other notes: | - NONE -

2.

Reject banned IP address

Purpose: | Test the sending mailhost source IP address to see if it matches one in the banned IP address list of the IIS SMTP Server.
Action: | Reject if the IP address of the sending mail host is found in the banned IP address list. Thus Praetor will never receive the message.
Default state: | Banned IP address list is empty.
False Positive: | This rule is very specific and will not cause any false positives.
Other notes: | - NONE -

3.

Reject IP address found on DNS Blackhole List

A DNS blackhole list (DNSBL) is an actively maintained list on a DNS server that can be queried to check if an IP address is found in the list. If it is, then it indicates that the associated mail server has been judged abusive for the spam-related criteria of that DNS server. A good example is the original Real-time Blackhole List (RBL) from the Mail Abuse Organization.

Starting in early 2005, CMS began to notice that spammers were changing tactics in response to the SMTP 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. The DNSBL technique is still being used, but using the message level testing will circumvent a possible D-O-S attack.

Purpose: | Test the sending mailhost source IP address by querying the Internet-based DNS Blackhole List (DNSBL).
Action: | Reject if the IP address of the sending mail host is reported found in the DNSBL.
Default state: | Enabled
False Positive: | This rule is very specific and will not cause any false positives unless your trading partner has their mail server improperly blacklisted by the DNSBL.
Other notes: | - NONE -

To see how Praetor is configured to use DNSBL, read this FAQ.

Note:

Any tests performed at the SMTP protocol level will result in actions that are absolute since no message is actually received. The message transfer attempt fails simply because the connection attempt is never established. The sending mail host will simply be given a 500 level SMTP rejection code and the connection is dropped. Thus it is not possible to perform any message level rule-based testing. .


App B Overview

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.

Rule Name

Default Action

Default State

  • DNS Blacklisted messages

Reject

Enabled

  • Reverse NDR attack

Reject

-

  • Banned attachments

Reject

Enabled

  • Suspicious attachment

Quarantine

Enabled

  • Approved From/Sender addresses

Accept

Enabled

  • Approved From/Sender domain

Accept

Enabled

  • Approved listservers

Accept

Enabled

  • Suspicious From/Sender address

Quarantine

Enabled

  • Suspicious From/Sender domain

Quarantine

Enabled

  • Banned recipient address

Quarantine

Enabled

  • Spamicity < 0.30

Accept

Enabled

  • Spamicity > 0.60

Quarantine

Enabled

  • Heuristics

Quarantine

—

  • Invisible HTML ink

Quarantine

Enabled

  • Tiny HTML text

Quarantine

Enabled

  • Var info in msg body

Quarantine

—

  • Obfuscated URL

Quarantine

Enabled

  • Banned profanity

Quarantine

—

  • Only external refs

Quarantine

—

  • Embedded-encoded HTML

Quarantine

—

  • Spamicity is unsure

Accept

Enabled

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:

Every rule is considered absolute in its determination. This means that once a test is satisfied, the resulting required action (accept, reject, quarantine, redirect, etc.) and selected optional actions occur and no further testing is performed on the message.


Attachments

Depending on your site's requirements, you may want to filter out attachments with certain filename patterns or extensions. For example, since video files are usually quite large, you may want to screen out messages containing *.AVI or *.MOV attachments. Of course these tests presume the messages were able to arrive because they did not exceed the value you set as the message size limit.

Reject banned attachments

Purpose:

Check message with any attachment to see if the name matches those found on the BANNED-ATTACHMENT list.

Action:

Reject if attachment filename matches the patterns in the Banned Attachment list.

Default state:

Enabled

False Positive:

This rule is 100% accurate when filenames are explicitly specified. Thus no false positives are expected and this rule should not cause messages to be inappropriately trapped.

Other notes:

Please review this list. As delivered, only the actual known virus filenames are entered into this list. The *.EXE and other wildcard entries are placed into the Suspicious Attachment list which is quarantined.

It is possible to use wildcards such as '?' or '*'. For example to ban all files with the extension of EXE, simply create the entry as:

*.EXE

To ban files like "VIRUS001.VBS", "VIRUS002.VBS", "VIRUSABC.VBS", create the entry as:

VIRUS???.VBS

Due to recent virus incursions, it is strongly recommended that you make certain this is rule #1 on the list order of your enabled rules so that it performs first before any other rules. In that way, it will not be possible for another rule (testing the APPROVED-MESSAGE-LEVEL-DOMAINS or APPROVED-MESSAGE-LEVEL-SENDERS list) to accept the message and allow a virus infected attachment to bypass this banned attachment rule.

Quarantine suspicious attachments

Purpose: | Check message with any attachment to see if the name matches those found on the Suspicious Attachment list. The difference between this and the Banned Attachment list is that these attachment files are less likely to causes disasters. An example might be a *.MOV or *.AVI file.
Action: | Quarantine if attachment filename matches the patterns in the Suspicious Attachment list.
Default state: | Enabled
False Positive: | This rule is extremely accurate when filenames are explicitly specified. Thus no false positives are expected and this rule should not cause messages to be inappropriately trapped. The only way a false positive occurs is if you accept attachments with the extensions listed.
Other notes: | Please review this list. It contains all the wildcard filenames like *.EXE and *.VBS that was excluded from the BANNED-ATTACHMENT list. After review, you may decide you want to move some of these entries to the BANNED-ATTACHMENT list.

Return to Overview


Message sender address

Accept approved From/Sender addresses

Purpose: | Check the message sender's address to see if it is on the Approved Message Level Senders list.
Action: | Accept if the sender address matches on in the Approved Message Level Senders list.
Default state: | Disabled
False Positive: | This rule is 100% accurate without any chance of false positives.
Other notes: | The Approved Message Level Senders list is empty by default. You must provide entries and enable the rule.

Accept approved Listserver addresses

Purpose: | Check the message sender's address to see if it is on the Approved Listserver addresses list.
Action: | Accept if the sender address matches on in the Approved Listserver addresses list.
Default state: | Disabled
False Positive: | This rule is 100% accurate without any chance of false positives.
Other notes: | The Approved Message Level Senders list is empty by default. You must provide entries and enable the rule.

Quarantine suspicious From/Sender address

Purpose: | Check the message sender's address against the Suspicious Sender Address list.
Action: | Quarantine the message if the sender address matches one in the Suspicious Senders list.
Default state: | Enabled
False Positive: | This rule is 100% accurate without any chance of false positives.
Other notes: | - None -

Return to Overview


Message sender domain

Accept approved From/Sender domain

Purpose: | Check the domain portion of the message sender's address to see if it is on the Approved Message Level Domains list.
Action: | Accept if the sender address matches one in the Approved Message Level Domains list.
Default state: | Enabled
False Positive: | This rule is 100% accurate without any chance of false positives.
Other notes: | The Approved Message Level Domains list is populated with Computer Mail Services' domain name, cmsconnect.com.

Quarantine suspicious From/Sender domain

Purpose: | Check the domain portion of the message sender's address against the Suspicious Sender Domain list.
Action: | Quarantine if the sender's address domain matches one in the Suspicious Sender Domain list.
Default state: | Enabled
False Positive: | This rule is 100% accurate without any chance of false positives.
Other notes: | - None -

Return to Overview


Banned recipient

Quarantine banned recipient address

Purpose:

Check the To field to see if the field contains an address that is found in the BANNED-RECIPIENT list.

Action:

Quarantine a To recipient that is found on the Banned Recipient list.

Default state:

Enabled

False Positive:

This rule is highly accurate but there is a small chance of false positives. The source of false positive are senders who compose a message to themselves while including someone in your domain as a blind carbon-copy.

Other notes:

In an attempt to be more sophisticated, many spammers try to avoid the mistakes of their predecessors who use the same address for the To and From fields. Instead, what they do is to use a "To" field that contains an address that indicates some sort of public group (friends@public, member@the_internet, user@internet.com, etc.) which are quite clearly bogus.

Just as in the case with identical To and From addresses, the intended recipient is only listed in the RFC-821 RCPT TO. Once again, such a message has the appearance that the person receiving the message is a blind carbon copy recipient.

See sample below.

Sample:

Received: from giulietta.logikos.it (1Cust226.tnt1.ontario.ca.da.uu.net [208.254.108.226])
by giulietta.logikos.it (8.8.6/8.8.7) with SMTP
id FAA01336; Tue, 22 Dec 1998 05:28:45 +0100
From: fjd8@giulietta.logikos.it
Message-Id: <199812220428.FAA01336@giulietta.logikos.it>
To: user@the-internet.com
Date: Mon, 21 Dec 98 20:13:02 EST
Subject: hi

Do you know what the number one fact is, that will determine whether your business is a success or
:
:
:

Return to Overview


Banned message body

Quarantine banned message body text

Purpose:

Check the message body to see if it contains words or phrases found on the BANNED-MESSAGE list.

Action:

Quarantine if the message body contains words or phrases that matches those found in the BANNED-MESSAGE list.

Default state:

Enabled

False Positive:

Depending on the entries in the BANNED-MESSAGE list, this rule may be very sensitive and generate a number of false positives.

Other notes:

Similar to the banned subject text, many times, spam will contain clearly objectionable phrases within the message body contents. These spammers have learned that many people have subject line filters so they use phrases that gets their junk email to pass undetected ("Info you requested" is one). Thus, Praetor includes a rule to check the message body.

One tell-tale sign of junk email is when the body contains a reference to the pending antispam legislation or the phrases "post-only mailing" and "to be removed."

Due to the likelihood of trapping false positives, choose your BANNED-MESSAGE entries very carefully.

Sample:

From: stock-2000@stock-2000.com
To: jdoe@acme.com
Date: Thursday, January 0021, 1999 03:47:20 o'clock AM EST
Message-Id: <19990121034720.DAF17812@stock-2000.com>
Subject: ADV: Stock-2000 Discovers New Cancer Detection Device

To be removed from our mailing list, simply reply with "REMOVE" in the subject line.

To our dedicated subscribers, we thank you for believing in us and hope you were profitable with our last profile. To our new subscribers, we hope you enjoy and prosper in the future.
:
:
:

Quarantine messages containing banned profanity

Purpose: | Check the message body to see if it contains words or phrases found on the BANNED-PROFANITY list.
Action: | Quarantine if the message body contains words or phrases that matches those found in the BANNED-PROFANITY list.
Default state: | Disabled
False Positive: | False positives can occur if your company policy allows the use of profanity in email messages.
Other notes: | The BANNED-PROFANITY list is separate from the BANNED-MESSAGE list in order to allow you to select different action(s) for the rule.

Return to Overview


Bayesian spamicity

This series of tests perform the Bayesian statistical computations to arrive at the spam probability index called spamicity. By default there are three rules that combine to provide the Bayesian filtering in Praetor. These are explicitly listed for when the ADVANCED filtering mode is set, and implicitly performed if the selection is for the BASIC mode with the pre-configured rule filters. This page explains the three explicit rules that test the Bayesian spamicity value.

Spamicity < 0.30

Purpose: | Check the Bayesian spamicity to see if it is less than 0.30 (default).
Action: | Accept if the value is less than this good message threshold level.
Default state: | Enabled
False Positive: | No, but it can allow spam to be accepted which represents the false negatives.
Other notes: |

Spamicity > 0.60

Purpose: | Check the Bayesian spamicity to see if it is greater than 0.60 (default).
Action: | Quarantine if the value is greater than this bad message (spam) threshold level.
Default state: | Enabled
False Positive: | Low incidence of non-spam messages being rated as spam.
Other notes: | Once you feel confident that this 0.60 threshold has no visible false positives, you may want to change the action to reject.

Spamicity is unsure

Purpose: | Check the Bayesian spamicity to see if it is in the range between 0.30 and 0.60 (default).
Action: | Accept if the value is in this unsure range.
Default state: | Enabled
False Positive: | No false positives, but likely to be the source of some false negatives which are spam that is not caught.
Other notes: | If the threshold values are adjusted to your satisfaction, it may be better to change the action to Quarantine and deal with the fewer false positives.


About CMS

Computer Mail Services, Inc., established in 1982, is a privately held corporation headquartered in Southfield, Michigan. After many years involving electronic mail and external connectivity, we now specialize in developing solutions to email-related problems such as spam.

Corporate headquarters

Address:

Computer Mail Services, Inc.
20300 Civic Center Drive
Suite 300
Southfield MI 48076

Phone:

+1 248 352 6700

FAX:

+1 248 352 8387

Email:

info@cmsconnect.com

Spam:

support@cmsconnect.com - for submitting spam samples to CMS for analysis. (This is not the only reason this email address is used.)

When we receive such samples, the original message headers have already been stripped out. Please try to provide us with these original Internet message headers.

If you use Outlook as the email client, read this page to see how you might include these message headers.

WWW:

www.cmsconnect.com

See also:

  • Sales

  • Technical Support

  • License Agreement

  • Evaluation License Agreement


Reverse NDR attacks

Note:

This rule is left disabled by default because you must first completely populate the Approved local addresses list with your users' email addresses.

Enabling this rule while this list is empty will cause Praetor to reject every single inbound message it processes.

In spite of your efforts to prevent direct attempts to relay mail, we continue to see spammers circumvent what you have done. They take advantage of the fact that most mail systems will attempt to send a non-delivery report (NDR) when a message cannot be delivered as addressed, and returning the original message contents.

Specifically the details are as follows:

  1. A spam message is created with ...

    1. the intended spam victim's address placed in the sender field, and

    2. a random and fictitious recipient at your domain

  2. Thousands of such messages are sent to your mail server.

  3. Your mail server determines that each message cannot be delivered and starts to send NDR email messages back to what appears to be the sender of the original message, i.e. the spam victim.

While it is true that this is an indirect method since the first part of the message contains a non-delivery report, the spam contents are carried intact to the receiving spam victim. Even worse, there is an increased probability that the spam victim will read the message thinking that it is a non-delivery report for email he or she actually sent.

The end result is the spammer has attained a new form of mail relaying. Like the direct approach, it is not the spammer's own mail server that delivers the junk email, but yours. Once again, your server's resources are being stolen to deliver spam.

CMS calls this a "Reverse NDR" attack. Many of our larger customers have experienced this, some so badly that 33% or more of the Internet messages are attributed to this attack. In one extreme case, more than 99% of the 100+ million messages received per day is this spam attack.

Here are some symptoms when you are under Reverse NDR attack:

  1. Sluggish email delivery

  2. Outbound queues full of non-delivery notices

  3. As soon as the outbound queue is cleared, more entries appear upon refreshing the view

  4. Excessive administrator time (hours) to clear outbound queues

Defeating the Reverse NDR attack

Praetor can be used to defeat this indirect relay attack. This is done as shown in the steps below. The countermeasure used by this rule is to validate every single recipient against the entries in Praetor's Approved local addresses list. If any recipient address is not found in this list, the message will automatically get quarantined by Praetor. Eventually you may want to edit the action and change it from quarantine to reject.

Warning:

While this rule is very effective, there is a possible complication. Since this rule will act upon any message that has an invalid recipient that does not exist in the Approved local addresses list, it will also affect those that are incorrectly addressed by a valid sender. You will need to decide if your company is willing to impede such messages from being received. Depending on the existence of this reverse NDR attack on your site and its severity, you may or may not want to activate this rule.

Mitigating this complication, however, is the fact that people who already conduct business with your company typically do so by replying to previously-received messages from your company employees or have their correspondent already in the address book. Thus the real danger in missing valid messages with this rule in place is likely to be from new and valid senders with whom your company has never exchanged any messages before. Even so, it is very likely that they are clicking on a URL on a web page to send an email instead of typing the address manually.

As a suggestion, you may want to include typical addresses that can be anticipated as common mistakes with one or more characters omitted or added when typing it. One such example would be sale@domain.com (singular 'sale') instead of sales@domain.com (plural 'sales').

Populating the Approved Local Address list

A command-line console application called MODLIST has been developed so that you can easily import and populate any Praetor list, especially this one. As a command oriented tool, it is even possible for you to automate this process. Click here to view details about how to export your local user email addresses and use this tool.

Return to Overview


Sales

Contacting Sales

The professional sales staff at CMS is ready and waiting to answer your sales questions Monday – Friday from 9:00 AM. to 6:00 PM Eastern Time.

Contact the sales department for information about the latest products, the Annual Support Subscription plan, upgrade options, prices, and more. If you have a technical question or problem, please contact Technical Support.

Phone: | +1 800-883-2674 (within the continental US) +1 248-352-6700
FAX: | +1 248 352 8387
Email: | sales@cmsconnect.com
WWW: | www.cmsconnect.com

Note:

When sending email, please include your company name, city, state, and country so your request is promptly handled.

Resellers

CMS also partners with a network of authorized resellers, both domestic and international. For more information, please contact us directly at the email address, phone or FAX numbers given above.

See also:

About CMS

Technical Support


Technical Support

Contacting Technical Support

At CMS, we work hard to provide you with high-performance and reliable products to solve your varied LAN messaging problems. Additionally, we try to provide superior online and print documentation, so you can work and learn independently.

But we realize there are still complexities you might face when using Praetor — those that may be site-specific and thus beyond the scope of our documentation. That's why we're dedicated to providing quality technical support services that help you resolve problems quickly and learn the tips and tricks of the daily operation of our product. We also would like to hear from you, especially with suggestions on improvements to our products and services.

Note:

Phone technical support is provided for those trying the 21-day evaluation of Praetor, and registered users who are within the 15-month period after initial purchase of Praetor or who have purchased support beyond this period. Be sure to include your product serial number when you contact us by email, fax, or phone.

Our Customer Support technicians are available Monday through Friday from 9:00am to 6:00pm US Eastern Time, and can be reached by phone, FAX, or Internet email.

Phone: | +1 248 352 8385
FAX: | +1 248 352 8387
Email: | support@praetor.net
WWW: | www.praetor.net
Online Manual: | Click here
Online Updates: | Click here

See also:

About CMS

Sales


AppD Overview

Internet Resources

  • FAQ from Internet newsgroup alt.spam

  • Antispam laws

  • Spam Glossary


alt.spam FAQ or "Figuring out fake E-Mail & Posts". Rev 19990705

Subject: alt.spam FAQ or "Figuring out fake E-Mail & Posts". Rev 19990705

All FAQs in Directory: net-abuse-faq
All FAQs posted in: alt.2600, alt.spam, alt.newbie, news.admin.net-abuse.misc, news.admin.net-abuse.email, news.admin.net-abuse.usenet
Source: Usenet Version

Archive-name: net-abuse-faq/spam-faq
Posting-Frequency: monthly
Last-modified: 19990705
URL: http://ddi.digital.net/~gandalf/spamfaq.html

Greetings and Salutations:

This FAQ will help in deciphering which machine a fake e-Mail or post
came from, and who (generally or specifically) you should contact.

The three sections to this eight portion FAQ (With apologies to Douglas
Adams :-)) :

o Introduction
o Tracing an e-mail message
o MAILING LIST messages
o Reporting Spam and tracing a posted message
o WWW IP Lookup URL's
o Converting that IP to a name
o A list of Usenet complaint addresses
o Fraud on the Internet and The MMF (Make Money Fast) Posts
o Trying to catch the suspect still logged on
o Filtering E-Mail BlackMail, procmail or News with Gnus
o Rejecting E-Mail from domains that continue to Spam
o Misc. (Because I can't spell miscellaneous :-)) stuff
I couldn't think to put anywhere else.
o Origins of Spam
o How *did* I get this unsolicited e-mail anyway?
o 1-900, 1-800, 888, 877 and 1-### may be expensive long distance
phone calls
o How To Respond to Spam
o Revenge - What to do & not to do (mostly not)
o Telephoning someone
o Snail Mailing someone

Introduction
============================================
Please feel free to repost this, e-mail it, put this FAQ on CD's or any
other media you can think of.

The latest & greatest version of this Spam FAQ is found at:
http://ddi.digital.net/~gandalf/spamfaq.html
Or *nicely* HTML'ed at:
http://www.cs.ruu.nl/wais/html/na-dir/net-abuse-faq/spam-faq.html
http://fuzzo.com/spam_faq.htm
or
http://www.netmeg.net/faq/internet/net-abuse/spam-faq/
Or the archive at:
ftp://rtfm.mit.edu/pub/usenet/alt.spam/
ftp://rtfm.mit.edu/pub/usenet-by-hierarchy/news/admin/net-abuse/misc/

This is addition to the most excellent Net Abuse FAQ (posted to
news.admin.net-abuse.misc, alt.current-events.net-abuse etc...),
brought to you by J.D. Falk <jdfalk@cybernothing.org> :
http://www.cybernothing.org/faqs/net-abuse-faq.html
http://samspade.org/d/nanaefaq.html - news.admin.net-abuse.email FAQ

A most excellent book for novices and System Admin's alike, much more
in depth than this FAQ. A full 191 pages of how to fight Spam.
Hopefully if they sell enough then this book will stay updated :
Stopping Spam - Alan Schwartz and Simson Garfinkel ISBN : 1-56592-388-X
- $19.95
O'Reilly & Associates - 90 Sherman St., Cambridge MA 02140 707-829-0515
Or :
http://www.amazon.com/exec/obidos/ASIN/156592388X/albioncom/002-
9724654-4944606

Spam cancellation notice (spam guidelines) :
http://spam.ohww.norman.ok.us/notice.htm
http://www.cm.org for info on NoCeM
http://www.ews.uiuc.edu/~tskirvin/faqs/spam.html

Net abuse jargon:
http://www.ncf.carleton.ca/ip/freenet/subs/complaints/spam/jargon.txt
http://www.deja.com/article/391150606

Software to track the headers / eliminate Spam for you :
http://mirrors.cylink.net/tucows/mac/macintosh.html - Mac software
http://www-oss.fnal.gov/~kschu/fnnews.html - INND PERL spam filter
written by Jeff Garzik (Version 3)
http://www.areianet.gr/IRIX_Spamshield/ - Spam Block for IRIX (SGI)
based on KAI's spamshield 1.40
http://samspade.org/classic/ - Sam Spade WWW Spam tools - Excellent!
http://www.cix.co.uk/~net-services/library/ - Windows Spam Hater
or
TO: bitftp@pucc.princeton.edu
BODY: open ftp.compulink.co.uk
cd /pub/net-services
get spamhl.exe
quit
http://www.exit109.com/~jeremy/news/cleanfeed.html
http://www.julianhaight.com/spamcop.shtml - Spam Cop - Does the header
analysis for you.
http://www.newapps.com/appstopics/Win_95_Anti-SPAM_Tools.html
http://www.neoworx.com/home122share.asp - NEoTrace - helps to find any
IP number, and possibly the name, address, telephone number and
Email contacts of the provider.
http://www.spamhippo.com/
http://www.spammerslammer.com - Works with windows e-mail programs that
uses pop mail
http://www.vipul.net/ricochet/ - automated spam tracing and reporting
agent

Your Daily Spam News:
Spam@MAIL-ME.COM - Web: http://spam.concordia.ca
Subscribe to Spam-News : join-spam-news@mailshield.com
or - nanas-sub@cybernothing.org
http://www.spam-news.com
http://www.spamhippo.com/cgi-bin/newsspam - Top Spam Sites

Spammers and how to stop them :
http://abuse.net/spam-l - Improve your spam-fighting skills
http://come.to/the.lumber.cartel - TINLC - There Is No Lumber Cartel
http://dir.yahoo.com/Computers_and_Internet/Communications_and_Networking/Electronic_Mail/Junk_Email/
http://headlines.yahoo.com/Full_Coverage/Tech/Spam_Wars/ - spam news
http://members.aol.com/bombagirl/freeware/email4u.txt - getit4u.txt has
a Spam section
http://members.aol.com/macabrus/cpfaq.html - CyberPromo Saga
http://members.tripod.com/~cyberstalked/hb140.html - Maryland Anti-
Harassment bill
http://members.tripod.com/~cyberstalked/story.html - Stalked by The
Woodside Literary Agency
http://members.tripod.com/~JOWazzoo/ConsumateSpamLinks666-FAQs.html
Consummate FAQ's page
http://members.tripod.com/~JOWazzoo/ConsumateSpamLinks666.html -
Consummate Spam Links Page
http://morehouse.org/hin - Internet Security
http://persona.www.media.mit.edu/judith/Identity/IdentityDeception.html
http://rvl4.ecn.purdue.edu/~cromwell/lt/468.html - Internet Security
http://spam.abuse.net/spam/
http://spam.abuse.net/spam/howtocomplain.html
http://viper.law.miami.edu/~froomkin/articles/oceanf.htm Regulation of
Computing and Information Technology
http://www-db.aol.com/corp/news/press/view?release=531& - AOL wins
against Spammers
http://www-fofa.concordia.ca/spam/complaints.shtml - Complaint
Addresses
http://www.abuse.net/cgi-bin/list-abuse-addresses - Complaint
http://www.antionline.com/ - Internet Security
http://www.ao.net/waytosuccess/nospam.html
http://www.ao.net/waytosuccess/spamnews.html
http://www.cabal.net/jason/index.html - A spammer tries to sue the
Cabal (TINC)
http://www.cauce.org - Trying to legislate against
http://www.ecofuture.org/ecofuture/jnkmail.html - How to Get Rid of
Junk Mail, and Telemarketers
http://www.claws-and-paws.com/spam-l/ - Improve your spam-fighting
skills
http://www.claws-and-paws.com/spam-l/tracking.html
http://www.coachnet.com/soho__21.htm - Small Office / Home Office
Newsletters Anti-Spam Articles for business
http://www.coachnet.com/soho__22.htm
http://www.coachnet.com/soho__29.htm
http://www.cs.purdue.edu/coast/hotlist/ - Internet Security
http://www.faqs.org/faqs/by-newsgroup/news/news.admin.net-abuse.email.html
http://www.faqs.org/faqs/net-abuse-faq/
http://www.internetwk.com/columns/frezz020199.htm - A good article on
why the Internet should be self governing WRT Spam
http://www.junkemail.org/scamspam/ - "Help stop Scam Spammers!"
http://www.kclink.com/spam/ - A fight to bill Spammers
http://www.looksmart.com/eus1/eus53832/eus53833/eus225492/eus282819/eus
278700/r?l&igv& - Spam link list
http://www.mcs.com/~jcr/junkemail.html
http://www.nags.org/
http://www.onelist.com/subscribe.cgi/anti-spam - Anti-Spam mailing list
http://www.ot.com/~dmuth/spam-l - Maintainer of the Spam-L FAQ
http://www.petemoss.com/
http://www.phase-one.com.au/fravia/pageadvi.htm - Stalking the spammer
Enemy
http://www.spamgirl.com/email.htm
http://www.stanford.edu/~edhou/StanfordSpamFAQ.html
http://www.studio42.com/kill-the-spam/index.html - "I am sick of Spam
and I want it to stop"
http://www.sunworld.com/swol-08-1997/swol-08-junkemail.html - Sunworld
Anti-Spam
http://www.usenet2.org/ - A Usenet with no Spam
http://www4.zdnet.com/anchordesk/story/story_index_19970819.html -
Special Spam Fighting Edition

E-Mail headers and tracing tools FAQs and links:
ftp://info.cert.org/pub/tech_tips
http://crash.ihug.co.nz/~bryanc/ - Mac WhatRoute
http://eddie.cis.uoguelph.ca/~tburgess/local/spam.html
http://home.earthlink.net/~laser3/simon.html - Yet another newbie guide
http://kryten.eng.monash.edu.au/gspam.html
http://members.aol.com/emailfaq/emailfaq.html
http://members.aol.com/emailfaq/resource-list.html
http://t2.technion.ac.il/~s2845543/yanig.html - Also yet another newbie
guide
http://www-fofa.concordia.ca/spam/tools.html - Macintosh Spam fighting
http://www.crl.com/~sjkiii/news-admin-net-abuse.html
http://www.elsop.com/wrc/nospam.htm
http://www.exit109.com/~jeremy/news/antispam.html - Spam Software
http://www.spam-archive.org/ - A collection of email-Spams.
http://www.ultranet.com/~gmcgath/selfdefense.html
http://www.winsite.com/win3/winsock/page6.html - Windows Internet
Utilities
http://www.winsite.com/win95/netutil/index.html - Win 95 Net Utils
http://www.winsite.com/win95/netutil/page11.html - netcop /
netlab95.zip
http://www.deja.com/article/420339665 - Forgery FAQ
http://www.deja.com/article/436881631 - How spammers get your E-Mail
address

Spam Info in other languages:
http://inews.tecnet.it/articoli/aprile98/Netsurfing9804a.html - Italian
Spam info
http://kulichki-lat.rambler.ru/moshkow/SECURITY/stopfash.txt - Russian
http://member.nifty.ne.jp/usr/negi/news.html
http://member.nifty.ne.jp/usr/negi/newsgroup0.html
http://people.frankfurt.netsurf.de/Wolfgang.Kynast/nospam.htm - German
Anti-Spam links ...
http://www.alkar.net/moshkow/html-KOI/SECURITY/stopfash.txt - Russian
Anti-Spam
http://www.despaml.interrob.de/ - German Anti-Spam Mailing List
http://www.droit.umontreal.ca/~labbee/ - French (Canadian)
http://www.ethereal.ru/~avk/anti-ad.html - Russian spam & headers page
http://www.online-recht.de/vorent.html?LGBerlin980514 - German Anti-
Spam and costs
http://www.student.hro.nl/0445746/ - Dutch anti spam site

Translate from/to English French, German, Spanish, Portuguese, Italian
http://babelfish.altavista.digital.com/
http://babelfish.altavista.digital.com/cgi-
bin/translate?urltext=http%3a%2f%2fdigital%2enet%2f%7egandalf%2fspamfaq
%2ehtml&lp=en_de - English to Deutsch
http://babelfish.altavista.digital.com/cgi-
bin/translate?urltext=http%3a%2f%2fdigital%2enet%2f%7egandalf%2fspamfaq
%2ehtml&lp=en_fr - English to French
Or paste the text into:
http://www.unojust.org/html/trans.htm

Or why Netabuse is bad :
http://cnn.com/TECH/computing/9808/10/tastyspam.idg/

Equal time, The spammer's viewpoint (Why Spam is good):
http://www.juicycerebellum.com/spam.htm
http://members.theglobe.com/SpamSucks/spamspeak.html - Spammers Speak
http://x.deja.com/article/484286843 - Gerald Kohler (
gkohler@worldnet.att.net ) argues for spam, with some good rebuttals.
Click on "Thread" then click on message 8 then click on next in thread
to follow the conversation.

What the alt.binaries.slack Organization has done to fight Spam :
http://www.sputum.com/spit/Main.htm
http://www.shreve.net/~cuthulu/sputum/

Proud to be a NetScum (Many anti-Spammers have been added by the
spammers) :
http://www.bostonphoenix.com/supplements/TheNet/fall97/NET_SCUM.html
http://www.algebra.com/~ichudov/images/netscum/
http://www.netscum.org/
http://www.aldeberan.org/netscum/index.html - NetScum Site Recreated

PLEASE email follow-ups, additions / changes to gandalf@digital.net

My news source is OK, but I sometimes miss items.

I accept all and any input. I consider myself to be the manager of
this FAQ for the good of everyone, not the absolute & controlling Owner
Of The FAQ. I do not always write in a completely coherent manner.
What makes sense to me may not make sense to others. If the community
wants something added or deleted, I will do so. I removed any e-mail
and last name references to someone making a suggestion / addition.
This is so that someone doesn't get upset at this FAQ and do something
stupid. If you don't mind having your e-mail in this FAQ (or where it
is required), please tell me and I will add it back in.

First off, before trying to determine where the post or e-mail
originated from, you should realize that (just like the National
Inquirer, or a logical argument from Canter and Siegel) the message
will have *some* amount of truth, but all or most of the information
may be forged. Be careful before accusing someone.

Commands used in this FAQ are UNIX & VMS commands. Sorry if they don't
work for you, you might wish to try looking around at your commands to
find an equivalent command (or I might be able to help out some).
There are programs for the Macintosh and Windows machines that do the
same thing the UNIX commands do, see the above URL's for where to
locate this software.

And no, I am not going to tell you how to post a fake message or fake
e-mail. It only took me about 2 days (a few hours a day) to figure it
out. It ain't difficult. RTFM (or more appropriately, Read The @&%^@#
RFC).

Every e-mail or post will have a point at which it was injected into
the information stream. E-mail will have a real computer from which it
was passed along. Likewise a post will have a news server that started
passing the post. You need to get cooperation of the postmaster at the
sites the message passed thru. Then you can get information from the
logs telling you what sites the message actually passed thru, and where
the message "looked" like it passed thru (but actually didn't). Of
course you do have to have the cooperation of all the postmasters in a
string of sites...

Tracing an e-mail message
============================================

To trace the e-mail you have to look at the header. Most mail readers
do not show the header because it contains information that is for
computer to computer routing. The information you usually see from the
header is the subject, date and the "From" / "Return" address. About
the only thing in an e-mail header that can't be faked is the
"Received" portion referencing your computer (the last received).

You will need to take a look at the headers on the message (if you can)
In PINE (for example) you have to turn on the header option in setup,
then just hit "h" to get headers. In Eudora for the Macintosh or IBM,
just press the button labeled "Blah Blah Blah" and you will get the
header. In Claris E-Mailer under Mail select Show Long Headers.
Programs that do not comply with any Internet standards (like cc-Mail
or Beyond Mail) throw away the headers. You will not be able to get
headers from these e-mail messages.

Aussie tells us that in Pegasus to view the full headers for each
message, use CTRL-H. This will show the full headers for the particular
message, but will not add them to any reply or forward. You need to
cut/paste the message into the reply/forward to send these headers.

Richard tells us with Nettamer, a MS DOS based email and usenet group
reader you must save the message as an ascii file, then the full header
will be displayed when you open the saved file with your favorite ascii
editor.

A URL to help you figure out how to look at the headers:
http://www.concentric.net/~Nvam

A little different description of headers:
http://help.mindspring.com/features/emailheaders/index.htm
http://help.mindspring.com/features/emailheaders/extended.htm
http://www.mcs.net/~jcr/junkemaildeal.html - Another Header Analysis
http://www.stopspam.org/email/headers/headers.html - In depth header
analysis

There is spamming software that sends the e-mail directly to your
computer. This makes only one received line in the e-mail making your
life many times easier. The computer that is not your computer is the
spamming computer.

Also, please look through the body of the message for e-mail addresses
to reply to. Complain to the postmasters of those sites also (see
below for a list of complaint addresses).

Gregory tells us that assuming a reasonably standard and recent
sendmail setup, a Received line that looks like :

Received: from host1 (host2 [ww.xx.yy.zz]) by host3
(8.7.5/8.7.3) with SMTP id MAA04298; Thu, 18 Jul 1996 12:18:06
-0600

shows four pieces of useful information (reading from back to front, in
order of decreasing reliability):
- The host that added the Received line (host3)
- The IP address of the incoming SMTP connection (ww.xx.yy.zz)
- The reverse-DNS lookup of that IP address (host2)
- The name the sender used in the SMTP HELO command when they
connected (host1).

Looking at the below we see 6 received lines. Received lines are like
links in a chain. The message is passed from one computer to the next
with no breaks in the chain. The received lines indicate that it ended
up at ddi.digital.net (my computer) from mail.bestnetpc.com. It was
received at mail.bestnetpc.com from unknown (HELO paul-s.-aiello)
([205.160.183.123]). The last three lines suggests that it was
received at in2.|bm.net from mh.tomsurl|.com and from
reb50.rs41|1date.net. Since none of these computers are in the first
two received lines then we can ignore these lines and every received
entry after this line (this UCE had 4 or 5 more faked Received lines in
it that were deleted for this example). We also know that these lines
are faked because no domain name has a "|" character in the name.
Domain names only have alphabetic or numeric characters in the name.

Do not get confused by the "Received: from unknown" portion. The word
"unknown" can be *anything* and should be ignored, this is whatever the
spammer put in the SMTP HELO command when they connected to the SMTP
server.

Received: from mail.bestnetpc.com (IDENT:qmailr@mail.bestnetpc.com
[205.160.183.3]) by ddi.digital.net (8.9.1a/8.9.1) with SMTP id
CAA10768 for <gandalf@digital.net>; Thu, 26 Nov 1998 02:55:11 -0500
(EST)
Received: (qmail 25259 invoked from network); 26 Nov 1998 08:05:49 -
0000
Received: from unknown (HELO paul-s.-aiello) ([205.160.183.123]) by
mail.bestnetpc.com with SMTP; 26 Nov 1998 08:05:49 -0000
Received: (from uudp@lcl|lhost) by in2.|bm.net (8.6.9/8.6.9) id
CFF569794 for <suppressed>; Thursday, November 26, 1998
Received: from tomsurl|.com (mh.tomsurl|.com [100.257.57.69]) by
m4.tomsurl|.com (8.6.12/8.6.12) with ESMTP id PAA21932 Thursday,
November 26, 1998
Received: from reb50.rs41|1date.net (root@reb50.rs41|1date.net
[256.36.1.176]) by tomsurl|.com (8.6.12/8.6.12) with ESMTP id PBA023891
for <suppressed>;

So we complain to whomever owns unknown (HELO paul-s.-aiello)
([205.160.183.123]). Make sure that you do a nslookup on the IP
address's. I try to verify 205.160.183.123 is paul-s.-aiello. Indeed
paul-s.-aiello does not even exist and 205.160.183.123 does not resolve
to a name when I do a NSLookup. Next would be a traceroute. See
further below for more in-depth tracking on resolving an IP.

IP portion = 205.160.183.123

Traceroute 205.160.183.123 gives us:
Step Host IP
Find route from: 0.0.0.0 to: 205.160.183.123 (205.160.183.123), Max 30
hops, 40 byte packets
<snip>
13 acsi-sw-gw.customer.alter.net. (157.130.128.26 ): 235ms
14 atlant-ga-2.espire.net. (206.222.97.24 ): 272ms
15 206.222.104.37 (206.222.104.37 ): 279ms
16 orland-fl-1-a5-0.espire.net. (206.222.99.7 ): 362ms
17 iag.net.orland-fl-1.espire.net. (206.222.106.6 ): 195ms
18 d1.s0.gw.dayb.fl.iag.net. (207.30.70.38 ): 230ms
19 s0.gw.bestnetpc.net. (207.30.70.254 ): 231ms
20 * * *
21 205.160.183.123 (205.160.183.123): 372ms

See the traceroute section below for how to interpret the "*" (and
other codes) that are returned from a traceroute.

Note - if you see something like the following realize that the only
portion you can trust is within the "([" and the "])". The spammer put
in the (faked) portion "mail.zebra.net (209.12.13.2)" :
Received: from mail.zebra.net (209.12.13.2) ([209.12.69.42])

Kamiel tells us that you might also want to make sure that the IP is
not hosted by an intermediary site. Check it out at:
http://www.arin.net

You should complain to the abuse@ or postmaster@<Last Two or Three
words at the end of the name>. I would complain to abuse@iag.net OR
abuse@espire.net (but NOT both sites) since after looking below at the
list of complaint addresses in this FAQ there are no alternate
addresses for iag.net or espire.net. Unless it is a "major provider"
(someone in the below complaint list) I usually complain to the
upstream provider rather than risk the chance of complaining to the
spammer and being ignored. If you go too far up the chain, however, it
may take quite some time for the complaint to filter down to the
correct person.

Louise tells us that you are entitled to make an 'alleged' accusation
but to prevent yourself from being libel, prefix your statement with:-
"Without prejudice: I suspect you are the culprit of such and such."

The constitutional and legal boundary of 'Without prejudice' exempts
Politician's opinions being spoken publicly and this prefix is often
adopted by Solicitors (English) or Lawyers/Attorneys (USA).

I use :
abuse@XXXXX - Without prejudice I submit to you this Unsolicited
Commercial E-Mail is from your user XXXX. UCE is unappreciated because
it costs my provider (and ultimately myself) money to process just like
an unsolicited FAX. Please look into this. Thank you.

BE SURE to verify the IP address. Windows '95 machines place the name
of the machine as the "name" and place the real IP address after the
name, meaning a spammer can give a legitimate "name" of someone else to
get someone innocent in trouble. A spammer at cyberpromo changed their
SMTP HELO so that it claimed to be from Compuserve. The Received line
looked like the below, but a quick verification of the IP address
208.9.65.20 showed it was indeed from cyberpromo :

Received: from dub-img-4.compuserve.com (cyberpromo.com [208.9.65.20])
by karpes.stu.rpi.edu

The below e-mail was passed to me thru a "mule" (un1.satlink.com
[200.9.212.3]). The Spammer hijacked an open SMTP port to reroute e-
mail to me:
Received: from un1.satlink.com (un1.satlink.com [200.9.212.3]) by
ddi.digital.net (8.9.1a/8.9.1) with ESMTP id GAA06372; Fri, 27 Nov 1998
06:53:20 -0500 (EST)
Received: from usa.net ([209.86.128.234]) by un1.satlink.com (Netscape
Messaging Server 3.54) with SMTP id AAT2FEA; Fri, 27 Nov 1998 08:46:07
-0200

A NSLookup on 209.86.128.234 resolves to
user38ld07a.dialup.mindspring.com, so after I complain to
mindspring.com I also send the postmaster of the open SMTP port the
following :
postmaster@XXXXX - Your SMTP mail server XXXXX was used as a mule to
pass (and waste your system resources) this e-mail on to me. You can
stop your SMTP port from allowing rerouting of e-mail back outside of
your domain if you wish to. FYI only. Info on how to block your
server, see:
http://maps.vix.com/tsi/
Test for server vulnerability :
http://maps.vix.com/tsi/ar-test.html

There are some systems that "claim" to "cloak" e-mail. It is not true.
If you receive one that looks like the following :

Received: from relay4.ispam.net (root@[207.124.161.39]) by
ddi.digital.net (8.8.5/8.8.5) with ESMTP id KAA28969 for
<gandalf@digital.net>; Thu, 26 Jun 1997 10:41:46 -0400 (EDT)
Received: from --- CLOAKED! ---
or
Received: from cerberus.njsmu.com ([204.142.120.2]) by ddi.digital.net
(8.8.5/8.8.5) with ESMTP id HAA06250 for <gandalf@digital.net>; Mon, 25
Jan 1999 07:11:18 -0500 (EST)
From: hostme39@aol.com
Received: from The.sender.of.this.untracable.email.used.MAILGOD.by.IMI

It is still broken down as follows :
- The route the e-mail took originated from one of the systems above
the line marked "cloaked" or the line "untraceable" (in fact this makes
it even easier to trace). There is no magic to it. Complain to that
provider. If you get no response from the site that spammed, you
should ask your provider to no longer allow the above site
[207.124.161.39] to connect to your system.

It has been kindly pointed out to me that there is a "feature" (read
"bug") in the UNIX mail spool wherein the person e-mailing you a
message can append a "message" (with the headers) to the end of their
message. It makes the mail reader think you have 2 messages when the
joker that sent the original message only sent one message (with a fake
message appended). If the headers look *really* screwy, you might look
at the message before the screwy message and consider if it may not be
a "joke" message.

There are also IBM mainframes that do not include the machine that they
received the SMTP traffic from. You have to route the message (with
headers) back to the postmaster at that system and ask them to tell you
what the IP of the machine is that hooked into their system for that
message.

It has also been pointed out that someone on your server can telnet
back to the mail port and send you mail. This also makes the forgery
virtually untraceable by you, but as always your admin should be able
to catch the telnet back to the server. If they telnet to a foreign
SMTP server and then use the "name" of a user on that system, it may
appear to you that the message came from that user. Be very careful
when making assumptions about where the e-mail came from.

Note for AOL users when looking at headers:
If you get double headers at the end of a message (like the below) the
spammer has tacked on a extra set of headers to confuse the issue.
Ignore everything except the last set of headers. These are the *real*
headers.

------------------ Headers --------------------------------
Return-Path: <Gloria@me.net>
Received: from rly-za05.mx.aol.com (rly-za05.mail.aol.com
[172.31.36.101]) byair-za04.mail.aol.com (v51.16) with SMTP; Mon, 16
Nov 1998 19:16:02 1900
Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by rly-
za05.mx.aol.com (8.8.8/8.8.5/AOL-4.0.0) with ESMTP id TAA05189;
Mon, 16 Nov 1998 19:15:53 -0500 (EST)
From: Gloria@me.net
Received: from signal.dk ([194.255.7.40]) by mailb.telia.com
(8.8.8/8.8.8) with SMTP id BAA14174; Tue, 17 Nov 1998 01:15:50 +0100
(CET)
Received: from 194.255.7.40 by signal.dk
viaSMTP(950413.SGI.8.6.12/940406.SGI.AUTO) id AAA28586; Tue, 17 Nov
1998 00:53:13 +0100
Message-Id: <199811162353.AAA28586@signal.dk>
Date: Mon, 16 Nov 98 18:27:19 EST
To: Gloria@papa.fujisankei-g.com.jp
Subject: ATTENTION SMOKERS - QUIT SMOKING IN JUST 7 DAYS
Reply-To: Gloria@papa.fujisankei-g.com.jp

------------------- Headers --------------------------------
Return-Path: <lifeplanner@zcities.com>
Received: from rly-yd04.mx.aol.com (rly-yd04.mail.aol.com
[172.18.150.4]) by air-yd02.mx.aol.com (v56.14) with SMTP; Mon, 11 Jan
1999 23:54:48 -0500
Received: from phone.net ([207.18.137.42])
by rly-yd04.mx.aol.com (8.8.8/8.8.5/AOL-4.0.0)
with SMTP id XAA01327;
Mon, 11 Jan 1999 23:51:03 -0500 (EST)
From: <lifeplanner@zcities.com>
To: <Someone@aol.com>
Date: Tue, 15 Dec 1998 20:54:19 -0600
Message-ID: <13653344018870252@phone.net>
Subject: Life insurance, do you have it?
Mime-Version: 1.0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

MAILING LIST messages
========================================

Stephanie kindly defines MAILING LIST versus LISTSERVER :

A MAILING LIST is a type of email distribution in which email is sent
to a fixed site which holds a list of email recipients and mail is
distributed to those recipients automatically (or through a moderator).

A LISTSERVER is a software program designed to manage one or more
mailing lists. One of the more popular packages is named "LISTSERV".
Besides Listserv, other popular packages include Listproc which is a
Unix Listserv clone (Listservs originated on BITNET), Majordomo and
Mailserve. Most importantly -- not all mailing lists run on
listservers, there are many mailing lists that are manually managed.

You may hear of mailing lists being referred to as many things, some
strange, some which on the surface make sense, like "email discussion
groups". But this isn't accurate either, since not all mailing lists
are set up for discussion.

Istvan suggests "Majordomo software is remarkably funny about headers.
It does not like headers which contain anything odd. All messages the
software receives which do not conform to its rigorous standards are
simply forwarded to the list moderator. It turns out this feature is
effective at stopping between 80 and 90% of spam actually getting to
the list."

Kirk tells us that you can set majordomo up so that new subscribers
have to reply to a subscribe request, thus verifying the address is
legit. Additionally the lists can be configured so that only
subscribers can post. And finally you can put filters on content.
I've got the list I manage configured to reject multipart email and
email which contains html.

Richard mentions "Listserv can be configured to restrict non-members
from sending to a list and can restrict spam based on the headers
similar to Majordomo. I've used both of these features successfully.
You can read more about Listserv capabilities, if you are interested,
at:
http://www.lsoft.com/listserv.stm
http://www.lsoft.com/spamorama.html#FILTER (info on its spam
filter)
I suspect that Listserv's spam filter may be better than Majordomo's
(but I've not managed any Majordomo lists)."

Example Header appears below:
Received: from dir.bham.ac.uk (dir.bham.ac.uk [147.188.128.25]) by
gol1.gol.com (8.7.5/8.6.9) with SMTP id GAA27292 for <XXXX@gol.com>;
Sun, 5 May 1996 06:31:15 +0900 (JST)
Received: from bham.ac.uk by dir.bham.ac.uk with SMTP (PP) using DNS
id <26706-38@dir.bham.ac.uk>; Sat, 4 May 1996 20:56:49 +0100
Received: from emout09.mail.aol.com (actually emout09.mx.aol.com) by
bham.ac.uk with SMTP (PP); Sat, 4 May 1996 21:13:03 +0100
Received: by emout09.mail.aol.com (8.6.12/8.6.12) id PAA29156; Sat, 4
May 1996 15:35:53 -0400
Date: Sat, 4 May 1996 15:35:53 -0400
From: Jeanchev@aol.com
Message-ID: <960504153553_287142426@emout09.mail.aol.com>
Subject: CRaZy Complimentary Offer........

This is a post from Kevin Lipsitz for his "===>> FREE 1 yr. USA
Magazine Subscriptions". The latest information indicates that the
state of New York has told him he should stop abusing the Internet for
a while ... lets hope it is forever. In relation to the Internet he
makes a slimy used car salesman look like a saint.

For more info about "Krazy Kevin" or the Magazine Spam , Tony tells us
the page "Stop Spam!" is available in html format at:
http://www.iac.co.jp/~issho/stop-spam.html

But as David reminds us, There are a million Kevin J. Lipsitz's out
there. All selling magazines, Amway, vitamins, phone service, etc.
All the losers who want to get rich quick, but can't start their own
business.
Like :
http://com.primenet.com/spamking/

That having been said, e-mail from a Listserve can usually be broken
down the same way as "normal" e-mail headers. There are just more
waypoints along the way. As you can see from the above, the e-mail
originated from :

emout09.mail.aol.com

You might with to also direct the listserve owner to look at & ask
questions in news.admin.net-abuse.misc about how to keep spam off the
listserve. It probably won't be all that difficult of a thing to do.

Reporting Spam and tracing a posted message
============================================
If someone posts a message with your e-mail in the From: or Reply-To:
field, it can (and will if you request) be canceled. Please repost the
message to news.admin.net-abuse.misc WITH THE HEADERS (or it will
probably be ignored) so that the message cam be canceled (the message-
id is the most important) with a suggested subject of the following:

Subject: FORGERY <Subject from the Spam message>

Or you can look at the Cancel FAQ at :
http://www.ews.uiuc.edu/~tskirvin/faqs/cancel.html

Try to make sure that the message has not already been posted to
news.admin.net-abuse.misc, news.admin.net-abuse.email or
news.admin.net-abuse.usenet and that it is less than 4 or 5 days old.
Chris reminds us that yes, there are a lot of annoying, off-topic and
stupid postings out there. But that doesn't make it spam. _Really_.
All we're concerned with is _volume_. Don't report any potential
spams unless you see at least two copies in at least 4 groups. The
content is irrelevant. Spam canceling cannot be by content.

For off topic posts, see http://ddi.digital.net/~gandalf/trollfaq.html

The first thing to do is to post the ENTIRE message (PLEASE put the
header in or it will probably be ignored) to the newsgroup
news.admin.net-abuse.misc. Do not reply or post it back to the
original group. A suggested subject is one of the following:

Subject: EMP <Subject from the Spam message>
Subject: ECP <Subject from the Spam message>
Subject: UCE <Subject from the Spam message>
Subject: SEX <Subject from the Spam message>

Please include the original Subject: from the original Spam so that it
can easily be spotted. Thank you.

If the post is particularly amusing (Spammer threat or a postmaster
threat), put C&C in the subject. Seymour tells us it means Coffee and
cats. This originated from a post claiming that a particular outrageous
article had caused spewing of coffee into the keyboard and jumping
while holding a cat, resulting in scratched thighs.

An Excessive Multiple Post (EMP) may exceed the spam threshold and may
be canceled. An Excessive Cross Post (ECP) may not be canceled because
it hasn't reached the threshold. A UCE is for Unsolicited Commercial
Email, SEX is for off-topic sex-ad postings.

Make Money Fast message is immediately cancelable and are usually
canceled already by others, so please do not report MMF posts. See MMF
section below.

Tracing a fake post is probably easier than a fake e-mail because of
some posting peculiarities. You just have to save and look at a few
"normal" posts to try to spot peculiarities. Most people are not
energetic to go to the lengths of the below, but you never know.

Dan reminds us that first you should gather the same post from
*several* different sites (get your friends to mail the posts to you)
and look at the "Path" line. Somewhere it should "branch". If there
is a portion that is common to all posts, then the "actual" posting
computer is (most likely) in that portion of the path. That should be
the starting postmaster to contact. Be sure to do this expeditiously
because the log files that help to trace these posts may be deleted
daily.

If you *really* want to see some fake posts, look in alt.test or in the
alt.binaries.warez.* groups.

A fake post:

Path:
...!news.sprintlink.net!in2.uu.net!news.net99.net!news!s46.phxslip4.ind
irect.com!vac
From: XXX@indirect.com(Female User)
Subject: Femdom In Search of Naughty Boys
Message-ID: <DHLMvE.24H@goodnet.com>
Sender: XXX@indirect.com(Female User)
Nntp-Posting-Host: s46.phxslip4.indirect.com
Organization: Internet Direct, Inc.
X-Newsreader: Trumpet for Windows[Version 1.0 Rev B final beta #1]
Date: Mon, 6 Nov 1995 01:59:38 GMT
Approved: XXX@indirect.com
Lines: 13

This poor lady (Name deleted by suggestion) was abused by someone for a
couple of days in an epic spam. Many messages were gathered. The
message ID was different for several messages. But several anomalies
showed an inept poster.

The headers were screwed up, and when looking at a selection of
messages from several sites, the central site was news.net99.net, where
goodnet.com gets / injects news at. This lead to the conclusion that
either goodnet.com or news.net99.net should be contacted to see who the
original spammer was. I never heard the results of this, but the
spamming eventually stopped.

You can try looking at sites & see if they have that message by :
telnet s46.phxslip4.indirect.com 119
Connected to s46.phxslip4.indirect.com.
200 s46.phxslip4.indirect.com InterNetNews server INN 1.4 22-Dec-93
ready
head <DHLMvE.24H@goodnet.com>
430

Message was not found at that site, so it did not go thru that
computer, or the article has already expired or been deleted off of
that news reader.

If you wish to track a particular phrase, user-id (whatever) take a
look at the URL for getting all the posts pertaining to "X" :

http://www.deja.com/
http://www.altavista.com/
http://www.reference.com/

WWW IP Lookup URL's
=============================
http://www.studio42.com/cgi-spam/nph-traceroute.pl - Traceroute
http://www.studio42.com/cgi-spam/nph-nslookup.pl - NSLookup
http://www.studio42.com/cgi-spam/nph-dig.pl - Dig
Index to Traceroute pages:
http://dir.yahoo.com/Computers_and_Internet/Communications_and_Networki
ng/Software/Networking/Utilities/Traceroute/
http://www.traceroute.org/
http://boardwatch.internet.com/traceroute.html - Traceroute Server
Index
Or Yet Another Traceroute :
http://www.net.cmu.edu/bin/traceroute (watch it trace hop to hop)
SWITCH WHOIS Gateway:
http://www.switch.ch/search/whois_form.html
Or
http://www.networksolutions.com/cgi-bin/whois/whois
http://www.ripe.net/db/whois.html - European countries WhoIs
http://www.apnic.net/apnic-bin/whois.pl - Asian Pacific WhoIs
http://www.arin.net/whois/arinwhois.html - North / South America WhoIs
IP to Lat - Lon (For those times when only a Tactical Nuke will do ;-))
:
http://cello.cs.uiuc.edu/cgi-bin/slamm/ip2ll/
Yet Another IP to name:
http://cello.cs.uiuc.edu/cgi-bin/slamm/ip2name
What do those domain names mean :
http://www.alldomains.com/alltlds.html
http://www.ics.uci.edu/pub/websoft/wwwstat/country-codes.txt - Country
Codes for the last characters in a domain name

Converting that IP to a name
=============================
When all you have is a number the looks like "204.183.126.181", and no
computer name, then you have to figure out what the name of that
computer is. Most likely if you complain to "
postmaster@[204.183.126.181] " it will go directly to the spammer
themselves (if it goes anywhere at all).

Marty reminds us that there are some "special" IP's that are allocated
as private networks. These fall within the confines of 0.0.0.0 to
255.255.255.255 but should be ignored. The addresses are :

Class Start Address End Address
A 10.0.0.0 10.255.255.255
B 172.16.0.0 172.31.255.255
C 192.168.0.0 192.168.255.255

See :
http://www.umnet.umich.edu/groups/UMnet-Routing/UAssignedPrivateIP.html

First off try using NSLookup (there is software for PC's or look at the
URL's at the top of this FAQ). If the NSLookup does not give you a
name then try a Traceroute. Somewhere you will get a "name" and at
that point I would complain to the postmaster@<that name>. See below
for complaint addresses.

To convert that decimal number to a "dotted quad octet" :
http://3438189385/yt/rotten1/

You can put this "strange" number in at :
http://samspade.org/classic/
And you get an answer like:
204.238.155.73

Kirk tells us wsftp and the traceroute that comes with wsftp will take
those number and automatically translate them into the IP addresses.

Or under Widows 95 :
start --> Programs --> Accessories --> Calculator
Choose view --> Scientific
Put in the "strange" number (3438189385) and click on HEX. You get:
CCEE9B49

Then type in each of the two characters in HEX and click DEC after each
number:
CC = 204
EE = 238
9B = 155
49 = 73

Viola ... Your IP is 204.238.155.73

For more general funny URLs, like
http://23123443~32:3758493879/www.samspade.org/10.00.0.1/xxxstuff.html,
try http://samspade.org/t/url.cgi?x

If the site is a IP address like "198.41.0.5", you can do a DNS lookup
to backtrack the site. A DNS lookup or a host command (see example
below) uses the info in a Domain Name Server database. This is the
same info that is used for packet routing. The UNIX command is :

nslookup 198.41.0.5
Commands:
nslookup hostname dns_server
or
dig @dns_server hostname

And you get :
Name: RS.INTERNIC.NET
Addresses: 198.41.0.5, 198.41.0.6

If you are having problems with this, Josh suggests you try :

$ nslookup
Default Server: ddi.digital.net
Address: 198.69.104.2

> set type=ptr
> 181.126.183.204.in-addr.arpa
Server: ddi.digital.net
Address: 198.69.104.2

Non-authoritative answer:
181.126.183.204.in-addr.arpa name = kjl.com

Authoritative answers can be found from:
126.183.204.IN-ADDR.ARPA nameserver = escape.com
126.183.204.IN-ADDR.ARPA nameserver = ns.uu.net
escape.com Internet address = 198.6.71.10
ns.uu.net Internet address = 137.39.1.3

InterNIC is your friend. The InterNIC Registration Services Host
contains ONLY Internet Information (Networks, ASN's, Domains, and
POC's). Please use the whois server at nic.ddn.mil for MILNET
Information. Try :

telnet rs.internic.net
whois 198.41.0.5

If that doesn't work, try the following (UNIX) command to tell you who
owns that "block" of addresses :
whois -h whois.arin.net 198.41.0

Dan has said that the NIC technical contact is the address to contact
if there is a technical problem with the name service records for that
domain. Sending spam notifications to the zone tech contact is an
abuse of the NIC whois records. Sending to the admin contact is
marginally more justifiable, but should only be used after postmaster
has been tried.

Thanx to Leslie, whom to contact about domains that have invalid
contact information :
Internic Registration Services should be contacted by email:
hostmaster@rs.internic.net

To see who the upstream provider is, try :

traceroute ip30.abq-dialin.hollyberry.com

You might get :
traceroute to IP30.ABQ-DIALIN.HOLLYBERRY.COM (165.247.201.30), 30 hops
max, 38 byte packets
1 cpe2.Washington.mci.net (192.41.177.181) 190 ms 210 ms 120 ms
2 borderx1-hssi2-0.Washington.mci.net (204.70.74.101) 100 ms 100 ms
60 ms
3 core-fddi-0.Washington.mci.net (204.70.2.1) 180 ms 130 ms 70 ms
4 core1-hssi-4.LosAngeles.mci.net (204.70.1.177) 150 ms 140 ms 150
ms
5 core-hssi-4.Bloomington.mci.net (204.70.1.142) 180 ms 200 ms 180
ms
6 border1-fddi-0.Bloomington.mci.net (204.70.2.130) 170 ms 290 ms
240 ms
7 internet-direct.Bloomington.mci.net (204.70.48.30) 300 ms 210 ms
270 ms
8 165.247.70.1 (165.247.70.1) 180 ms 240 ms 180 ms
9 abq-phx-gw1.indirect.com (165.247.202.253) 290 ms 220 ms 230 ms
10 * * *

The first column is the "hop" that traceroute is working on. The next
is the "computer" (and IP) of the computer at that hop. The last three
numbers are the milliseconds it took to get an answer from that
computer.

You can get "codes" instead of the milliseconds. An example of a
"code" is the "* * *" for hop 10.

Here is a list of the codes:
* The Traceroute Packet timed out (did not return to you).
? Unknown packet type.
H Host unreachable.
N Network unreachable.
P Protocol unreachable.
Q Source quench.
U Port unreachable.

Humm..... Seems that after abq-phx-gw1.indirect.com we get no response,
so *that* is who I would complain to... or you can just send a message
to postmaster@indirect.com ... If that doesn't work then complain to
MCI.net.

JamBreaker sez : Be sure to let the traceroute go until the traceroute
stops after 30 hops or so. A reply of "* * *" doesn't mean that you've
got the right destination; it just means that either the gateways don't
send ICMP "time exceeded" messages or that they send them with a ttl
(time-to-live) too small to reach you.

Try 'dig' (or one of its derivatives), it is used to search DNS
records :
(For the software :
http://www.rediris.es/ftp/infoiris/red/ip/dns/dig-2.0/ )

yourhost> dig -x 38.11.185.89

; <<>> dig 2.0 <<>> -x
;; ->>HEADER<<- opcode: QUERY , status: NOERROR, id: 6
;; flags: qr aa rd ra ; Ques: 1, Ans: 1, Auth: 3, Addit: 3
;; QUESTIONS:
;; 89.185.11.38.in-addr.arpa, type = ANY, class = IN

;; ANSWERS:
89.185.11.38.in-addr.arpa. 86400 PTR
ip89.albuquerque.nm.interramp.com.

;; AUTHORITY RECORDS:
11.38.in-addr.arpa. 86400 NS ns.psi.net.
11.38.in-addr.arpa. 86400 NS ns2.psi.net.
11.38.in-addr.arpa. 86400 NS ns5.psi.net.

;; ADDITIONAL RECORDS:
ns.psi.net. 86400 A 192.33.4.10
ns2.psi.net. 86400 A 38.8.50.2
ns5.psi.net. 86400 A 38.8.5.2

;; Sent 1 pkts, answer found in time: 64 msec
;; FROM: (yourhostname) to SERVER: default -- (yourDNSip)
;; WHEN: Thu Nov 16 23:30:42 1995
;; MSG SIZE sent: 43 rcvd: 216

A list of Usenet complaint addresses
============================================
O.K... So you have a common site that you can complain to. Good. If
you cannot figure out where the message came from, you can post the
FULL HEADERS (this is *very* important for tracing) to news.admin.net-
abuse.misc, news.admin.net-abuse.email or news.admin.net-abuse.usenet
(see the section entitled Reporting Spam and tracing a posted message).
Usually you can get someone to help with the message.

If you complain (or asked to be removed) to the spammer directly, you
may just be confirming a "real" live e-mail address, which may lead to
even more junk e-mail. I would suggest complaining to the owner of the
site only. You can send e-mail to foo.bar.com@abuse.net (where
foo.bar.com is the provider you are complaining to) and it will get
forwarded to the "best" e-mail address.. See http://www.abuse.net/

There is a list of admins to contact (besides the list contained here):
http://www-fofa.concordia.ca/spam/complaints.shtml

Greg reminds us that if you are complaining to a postmaster about a
week-old post, don't bother. It's not on their server, they can't
verify it. Make sure you use terms correctly. A recent trend is to
call any off-topic post "spam". It's not. I deal with spammers and
off-topic or advertising posters differently. Other providers do also.
Also, try to keep the clutter in your complaints down. I don't need a
copy of the referenced RFC or statute. It doesn't help either of us if
I can't find your complaint in between all the mumbo jumbo.

Send complaint with FULL HEADERS in e-mail to any or all of the below :

abuse@spammer.site.net
postmaster@spammer.site.net

Note : abuse@spammer.site.net is not a "standard" complaint e-mail
address, but I would suggest trying that address first.

Chris tells us :
If you see MMFs or other gross abuses from AOL, MSN, MCI
(_not_internetmci), Primenet, Panix, please do not report them to
news.admin.net-abuse.misc. Just wastes bandwidth. Email your report
directly to the provider:

abuse@aol.com
postmaster@mci.com
postmaster@primenet.com
postmaster@panix.com
abuse@msn.com

By "gross abuses", please try to ensure that it really is likely to be
spam. Not one article cross-posted lots, but lots of articles that you
see yourself.

For the following providers the correct e-mail address is:
1-800-600-0343 # (Some Extension) - abuse@digitcom.net - Digitcom sells
flat rate $19.95 per month services, 100 messages per day. Spammers
love this as it is no muss no fuss flat rate.
1-800-242-0363 # (Some Extension) - abuse@digitcom.net - Digitcom
Nationwide Services
1-800-607-6006 # (Some extension) - webmaster@linkems.com - Associated
with www.linkems.com
1-800-811-2141 Code # (some code number) - anti_spam@topsecrets100.com
A-VIP.com - abuse@netforward.com
ABAC.COM - abuse@ABAC.COM abuse@aplus.net abuse@intercom.net -
http://www.abac.com/use.html
Above.Net - abuse@above.net - http://www.above.net/images/aug.pdf
ABSnet - support@abs.net or abs-admin@abs.net
Access1.net - abuse@access1.net / abuse@mail.access1.net
ACN US Tech - techsupport@acninc.net
AGIS.NET - postmaster@AGIS.NET or abuse@agis.net
AiNET - network-abuse@ai.net - http://www.ai.net/aup.html
Airnet.net - abuse@airnet.net
Alladvantage.com - abuse@alladvantage.com - List of cancelled users
http://www.alladvantage.com/spamlist.asp
Allinfosys.com - abuse@savvis.net - Allinfosys advertises an open SMTP
port at smtp1.allinfosys.com [209.44.59.8]
Aloha.Net - abuse@aloha.net
Alter.net - postmaster@alter.net is forwarded to UUNet
Angelfire.com or angelfire.com - spam@whowhere.com -
http://pages.whowhere.com/internet/nospammers
ANV.NET - abuse@anv.net - http://www.accessnv.com
AOL - abuse@aol.com . Emergency - send complete copies to
atropos@aol.net
APEXMAIL.COM - abuse@APEXMAIL.COM - Mail sent from APEX includes the IP
address in the message header, which appears as X-MAILFROM-IP:
[xxx.xxx.xxx.xxx]
APNIC.net - IP Lookup - whois -h whois.apnic.net <IP address> - APNIC
Does not provide network services. APNIC is the Internet registry for
the Asia and Pacific Rim regions -- we primarily delegate blocks of
addresses to service providers. We do not run a network (other than
our internal network) nor do we have customers or non-staff accounts.
Appliedtheory.net - abuse@appliedtheory.net
Arizonaone.com - abuse@arizonaone.com
AT&T - dial-access.att.net - abuse@att.net
AT&T WorldNet Services - abuse@worldnet.att.net
ATTmail.com - elsaphelp@attmail.com
AudioPhile.com - abuse@netforward.com
Autonet.net - abuse@autonet.net
AXS.net - abuse@axs.net
Bayoucom.net - postmaster@bayoucom.net
BBN.com - abuse@bbnplanet.com
BBNplanet.com - abuse@bbnplanet.com
BCtel.ca Dial-In Users - abuse@bc.sympatico.ca
BCtel.net - abuse@bctel.net - http://www.bctel.net/aup
Bellatlantic.net - abuse@bellatlantic.net
Bellglobal.com - abuse@bellglobal.com
Bellsouth - abuse@bellsouth.net
Best.com - abuse@best.com
BFP.net - abuse@bfp.net
bigfoot.com - postmaster@bigfoot.com
Biglobe.ne.jp - info@biglobe.or.jp / support@bcs.biglobe.ne.jp /
support@biglobe.or.jp
BioGate.com - abuse@netforward.com
Biosys.net - abuse@netforward.com
bitmail.com - abuse@freetradeweb.com
BitSmart.com - abuse@netforward.com
Biznizlist.com - www.biznizlist.com - abuse@psi.com - Spam friendly see
: http://www.biznizlist.com/FAQ/faq.html
Boo.net - abuse@boo.net
BT.net - abuse@bt.net
Businessman.org - support@sitesinternet.com / abuse@sitesinternet.com
(abuse mailbox was full ...)
Cableinet.net - abuse@cableinet.net
Cais.net - noc@cais.com - http://www.cais.com/comp_aup.htm - CAIS
acceptable use
Campus.MCI.Net - postmaster@campus.mci.net
CERF.net - abuse@CERF.net - http://www.ipservices.att.com/policy.html -
AT&T merger - http://www.cerf.net/cerfnet/
Clover.Net - Abuse@Clover.Net - http://www.clover.net
CNX.NET - abuse@cnx.net
coam.net - abuse@coam.net
Codetel.net.do - SysAdmin@auth2.codetel.net.do
Coloradosoft.com - Wrote a mail merge program that used to allow
spamming, has since fixed the code but old versions are still out there
... Please do not complain to them ...
Com.BR - Policy - demi@agestado.com.br security violations write the
list cert-br@listas.ansp.br
Combase.COM - abuse@COMBASE.COM
Come.to - abuse@come.to - AUP http://come.to/abuse.html - Complaint
form at http://v3.come.to/webmaster.html
Commtouch.com - spam@commtouch.com
ComPorts.com - abuse@netforward.com
Compuserve - abuse-mail@compuserve.net : Email "spam"/massmail
complaints - abuse-news@compuserve.net : News "spam" complaints
Compuweb.com - abuse@COMPUWEB.COM
Concentric.net - abuse@concentric.net -
http://home.concentric.net/support/tos.html -
http://home.concentric.net/support/faq/general/aup.html
Connect.ab.ca - abuse@connect.ab.ca
CRL.com - abuse@crl.com / support@crl.com - Send to One and ONLY one
address or it will bounce back to you unsent, and a bug in the software
they have will *not* let you send that complaint to only one recipient
after that first e-mail.
Cryogen.com - abuse@netforward.com
CW.net - Spamcomplaints@cwixmail.com - Cable and Wireless - Security -
http://security.cw.net/
CWI.NET - abuse@cwi.net - Cable & Wireless Internet
CWIX.NET - Spamcomplaints@cwixmail.com
CyberJunkie.com - abuse@netforward.com
Cyberlynk.net - abuse@cyberlynk.net -
http://www.cyberlynk.net/policies.html
Cyberthrill.com - abuse@cyberthrill.com -
http://www.cyberthrill.com/antispam.html
DeathsDoor.com - abuse@netforward.com
DejaNews - abuse@deja.com - http://www.deja.com/help/faq.shtml#abuse -
http://www.deja.com/info/postrules.shtml
Demon.net - abuse@demon.net - http://www.demon.net/connect/aup/
Dhs.org - abuse-<full hostname>@dhs.org Example: abuse-
spam123.dhs.org@dhs.org
Dial-access.att.net - abuse@att.net
Dialsprint.net - abuse@earthlink.net
Digex.net - abuse@digex.net (along with your real name) see
http://www.access.digex.net/~policy/digex-aup.html
DigiCron.com - abuse@netforward.com
Digiweb.com - abuse@digiweb.com
Direct.CA - complaints@direct.ca
DittosRush.com - abuse@netforward.com
dN.NET - abuse@dn.net - http://www.dn.net/aup
DRAGG.NET - postmaster@DRAGG.NET
EarthCorp.com - abuse@netforward.com
earthlink.net - abuse@earthlink.net or spam@earthlink.net
http://www.earthlink.net/about/policies/aupolicy.html - Acceptable use
Eclipse Internet Services - abuse@eclipse.net /
abuse@annular.eclipse.net
efortress.com - abuse@efortress.com
ELI.net - abuse@eli.net (reports to postmaster@eli.net are NOT
forwarded to abuse@eli.net , they are deleted).
Empirenet.com - abuse@globalcenter.net -
http://www.globalcenter.net/launchpad/util/antispam.html
ENI.net - abuse@eni.net
Epoch Internet - ENI.net - abuse@eni.net -
http://www.eni.net/Our_Network/aup.html
Erols.com - abuse@erols.com
Espire.net - e.spire Communications - abuse@espire.net -
http://www2.espire.net/aup498.cfm
evcom.net - abuse@evcom.net -
http://www.evcom.net/services/access/acceptab.htm
excite.com - abuse.support@excitecorp.com -
http://www.excite.com/terms.html
excitecorp.com - abuse.support@excitecorp.com -
http://www.excite.com/terms.html
Exec-PC Inc. - abuse@execpc.com
Exodus.net - abuse@exodus.net -
http://www.exodus.net/corp/about/antispam.html
Fastresponse.net - NetworkTeam@fastresponse.net
Flashmail.com - abuse@flashmail.com
Flashnet - postmaster@flash.net -
http://www.flash.net/~support/esupport/postmast.html
FLIPS.NET - abuse@flips.net http://www.flips.net/terms.html /
http://www.flips.net/spamnote.htm
Forfree.at - abuse@forfree.at http://forfree.at/registration/
Freei.net - freei@freei.net
Freenet.carleton.ca - abuse@freenet.carleton.ca
Freeservers.com - abuse@freeservers.com -
http://WWW.FREESERVERS.COM/policies/abuse.html
Freeyellow.com - abuse@freeyellow.com - http://home.freeyellow.com/tos/
Funtv.com - webmaster@funtv.com
GalaxyCorp.com - abuse@netforward.com
Gate.net - support@gate.net
Genuity.net - abuse@bbnplanet.com
Geocities.com - abuse@geocities.com
gergs_bane.org (does not exist, it is faked) - See UUNET -
help@uunet.uu.net
Getnet.com - Abuse@neta.com - http://www.neta.com /
http://www.getnet.com
Globalcenter.net - spam@globalcenter.net - Takes 10 complaints to kill
a spammer - http://www.globalcenter.net/launchpad/util/antispam.html
GlobeComm, Inc. - GlobeComm is the parent company of iName -
abuse@Mail.com
Globix.net - abuse@Globix.com
GMX.net - abuse@gmx.net
GNN.Com - For help regarding a problem with a GNN member -
GNNadvisor@gnn.com.
Go2net.com - support@go2net.com
Good.Net - goodnet.com - abuse@goodnet.com
GTE.net - abuse@bbnplanet.com
Gulf.net - postmaster@gulf.net - Spam cleanup charges !!!
HK.Super.NET - abuse@HK.Super.NET - http://www.hk.super.net/email-aup
HKnet.com - abuse@hknet.com - http://www.hknet.com/iPage/policy.html
HKU.HK - Hong Kong University - kty@CC.HKU.HK
Holonet.net - abuse@holonet.net - Complaint must contain e-mail
address, real name, address, and day time telephone number
Home.net / Home.com - postmaster@home.net
http://www.home.com/support/aup/ . You must correctly identify the IP
and send it to the correct postmaster (I don't know how you are
supposed to identify home.com's other customers ...). Home.net does
not forward spam. 24.112 or 24.113 should be sent to
abuse@rogers.home.net , any wave.home.com address that begins with
'CS', 24.64, 24.65, or 24.66 should be sent to Internet.Abuse@shaw.ca
Other home.net customers and their avbuse addresses. TCI:
customer.care@tci.net Comcast: service@comcastpc.com Cablevision:
support@optonline.net Cox: datahelp@cox.com Shaw:
internet.help@shaw.wave.ca Rogers: support@rogers.home.com Marcus:
marcus-support@home.com Intermedia: imediasupport@home.com Insight:
Csr-gatekeeper@home.com Jones: Csr-gatekeeper@home.com Century: Csr-
gatekeeper@home.com
Homepage.com / Homepagecorp.com - abuse@homepagecorp.com
Homestead.com - abuse@homestead.com
Hotbot.com - spam@whowhere.com -
http://pages.whowhere.com/internet/nospammers
Hotmail.com - abuse@hotmail.com - http://wy1lg.hotmail.com/cgi-
bin/dasp/tos.asp - Also look for "X-Originating-IP: [xxx.xxx.xxx.xxx]"
in the header to see where the e-mail originated from.
HotPOP.com - abuse@hotpop.com
i.am - abuse@easy.to
IBM Net - abuse@ibm.net - http://help.ibm.net/service/abuse.html
IDT.Net - abuse@idt.net - http://www.idt.net/usage
IMSIS.COM - abuse@IMSIS.COM
iName - iname.com - abuse@Mail.com
Infi.net - abuse@infi.net - http://www.infi.net/policy.html
InfoAve.Net - ABUSE@InfoAve.Net
information4u.com - abuse@Mail.com
Inreach.com - postmaster@inreach.com -
http://members.inreach.com/acceptable.html
INS Info Services (netins.net) - abuse@netins.net
Interaccess.com - abuse@interaccess.com
Intercom.net - abuse@ABAC.COM abuse@aplus.net abuse@intercom.net -
http://www.abac.com/use.html
Intergate.bc.ca - abuse@intergate.bc.ca - AUP is
http://www.intergate.ca/personal/icsa.htm
interramp.com - abuse@interramp.com or psinet-domain-admin@PSI.COM
interserve.com.hk - Mr. K H Lee - khlee@interserve.com.hk.
ISPchannel.com - abuse@mediacity.com
iSTAR Canada (istar.ca, inforamp.net, hotstar.net, magi.com, or
nstn.ca) - abuse@iSTAR.ca
JPS.net - abuse@jps.net - http://www.jps.net/support/spam
Juno.com - postmaster@juno.com
LAKER.NET admin@laker.net or VOICE 1-954-359-3670 FAX 1-954-359-2741
LD.net - webmaster@ld.net / webmaster@cognigen.com for spamming
incidents - http://LD.NET/bizop/bizop.html#nospam -
http://ld.net/6.9/LD1999 - Spammer Canceled
Level3.com - Abuse@level3.com -
http://www.level3.com/services/inter_acc_acceptableuse.html
LI.net - Owned by longisland.verio.net - abuse@longisland.verio.net or
questions@longisland.verio.net
Listbot.com - lbabuse@linkexchange.com
LN.NET - abuse@LN.NET
looksmart.com - spam@commtouch.com
Loop.Com or Loop.net - greg@loop.com
Lycosmail.com - abuse@Mail.com
Mail.com - abuse@Mail.com
Mailcity.com - spam@whowhere.com -
http://pages.whowhere.com/internet/nospammers
Mailexcite.com - spam@whowhere.com -
http://pages.whowhere.com/internet/nospammers
MailMe.net - support@sitesinternet.com / abuse@sitesinternet.com (abuse
mailbox was full ...)
MALIBU - postmaster@pbi.net
Maverick.NET - postmaster@MAVERICK.NET
MCI Net - Spamcomplaints@cwixmail.com - Security
http://security.cw.net/
mckinley.com - abuse.support@excitecorp.com -
http://www.excite.com/terms.html
MCSNet - support@mcs.net
Mediacity.com - abuse@mediacity.com
Members.xoom.com - abuse@xoom.com
MHI Network - abuse@milehigh.net
MicroServe.net - abuse@microserve.net - http://www.microserve.net/aup /
http://www.naispa.org/aup
Mindspring.com - abuse@mindspring.com -
http://www.mindspring.com/~nomorespam
ML.org - abuse@ml.org
money.com or money.now - postmaster@cam.org
Monisys.ca - abuse@monisys.ca
MS.UU.Net - Example CustXX.MaxXX.city.ST.MS.UU.NET and does not have
@msn.com - fraud@uu.net
MS.UU.Net - Example CustXX.MaxXX.city.ST.MS.UU.NET and explicitly
contains an MSN e-mail address (@msn.com) - abuse@msn.com
MSN.com - Abuse@msn.com - http://www.msn.com/aup.htm
MWIS.net - root@mwis.net
myfreeoffice.com - support@myfreeoffice.com /
naispa.org - abuse@microserve.net - http://www.microserve.net/aup /
http://www.naispa.org/aup
Nap.net - abuse@bbnplanet.com
neta.com - Abuse@neta.com - http://www.neta.com / http://www.getnet.com
Netcom.ca - abuse@netcom.ca
Netcom.com or @ix.netcom.com - Put "E-Mail" or "News" in Subject -
abuse@netcom.com - http://www.netcom.com/netcom/aug.html - $200
cleanup fee!!!
Netforward.com - abuse@netforward.com / Postmaster@Netforward.com
Netins.net - abuse@netins.net
NETSCAPE.NET - abuse@netscape.net
Nextel.no - abuse@nextel.no
http://www.nextel.no/kundesenter/hjelp/obs/abuse.html (Norwegian only)
NFmail.com - postmaster@nfmail.com "Any use or exploiting of the
Project Netfraternity (registered) for profit or commercial aims, by
any person or organization, will be pursued by law."
NKN.NET - postmaster@veriotexas.net
NL.net / NL.uu.net - postmaster@nl.net or support@nl.uu.net
Nodewarrior.net - abuse@nodewarrior.net
OnRamp - postmaster@veriotexas.net
Optilinkcomm.net - postmaster@optilinkcomm.net
Orbita.Starmedia.com - postmaster@starmedia.com
OZemail.com.au - abuse@ozemail.com.au
pacbell.net / pbi.net - abuse@pacbell.net -
http://public.pacbell.net/dialup/usepolicy.html : Forged headers =
Automatic account cancellation.
Pagepark.com - abuse@pagepark.com
Pair.com - abuse@pair.com - http://www.pair.com/abuse/
Pipeline.com - postmaster@pipeline.com
PIPEX- postmaster@dial.pipex.com , International - int-sup@pipex.net ,
Unipalm PIPEX - postmaster@unipalm.pipex.com
POBoxes.com - abuse@netforward.com
POBoxes.com - abuse@Netforward.com -
http://www.netforward.com/rules.shtml
popsite.net - postmaster@starnetinc.com - Killed users -
http://www.popsite.net/kill.html
popsite.net - postmaster@starnetusa.net - http://www.megapop.net/
portal.com - support@portal.com
Power-tech.net -abuse@power-tech.net
Powernet.net - abuse@powernet.net
Primenet.com - spam@globalcenter.net
Prodigy - abuse@prodigy.net
PSI Net - abuse@psi.com , net-abuse@psi.com PSI Net policies -
http://www.psi.net/legalinfo/netabusepolicy.html
Psynet.net - abuse@netforward.com
pwrnet - abuse@pwrnet.com
QWest.net - uce@qwest.net
RadioLink.net - abuse@netforward.com
Rain.net - abuse@rain.net
RocketMail - abuse@rocketmail.com -
http://www.rocketmail.com/py/RMailTermsText.py
Savvis.net - abuse@savvis.net
Seanet.com - abuse@seanet.com -
http://www.seanet.com/help/abuse.FAQ.html
Shore.net - support@shore.net
Sitesinternet.com - support@sitesinternet.com / abuse@sitesinternet.com
(abuse mailbox was full ...)
Slip Net - abuse@slip.net - Tech Support
Softaware.com - abuse@softaware.com - http://www.softaware.com/aup.html
Southwindent.com - dave@vcity.net
Splitinfinity.net - abuse@SPLITINFINITY.NET
Splitrock.net - abuse@Splitrock.net (Prodigy uses some Splitrock.net
dialups)
Sprint - abuse@sprint.net
Sprintlink - 800-669-8303 abuse@sprint.net , noc@sprintlink.net . For
sprintmail.com abuse reports send to abuse@sprintmail.com . You can
view Sprint's Policy at http://www.sprintbiz.com/ip/policy.html
Sprintmail.com - abuse@sprintmail.com
Sprynet - abuse@mindspring.net - Now MindSpring
http://www.mindspring.com/~nomorespam
Stargate.net - abuse@stargate.net -
http://www.stargate.net/stargate/policies-terms.html
Starmedia.com - postmaster@starmedia.com
Starnetusa.net - postmaster@starnetusa.net -
http://www.starnetinc.com/support/tos.html
State.net - abuse@state.net -
http://www.state.net/MNonline/Admin/aup.html
State.tx.us - abuse@capnet.state.tx.us
SUMMITPOINT.COM - abuse@state.net - (Merged with State.net) -
http://www.state.net/MNonline/Admin/aup.html
SWBell.net - postmaster@swbell.net -
http://public.swbell.net/faq/spam.html
Tande.com - abuse@netforward.com
TeenWorld.POBoxes.com - abuse@netforward.com
Teleport System Administration - teleport.com - admin@teleport.com
TerraNova.net - abuse@terranova.net -
http://www.terranova.net/policy.html
The18thHole.com - abuse@netforward.com
Thedoghousemail.com - abuse@thedoghousemail.com
Theglobe.com - abuse@corp.theglobe.com
TheGrid - postmaster@thegrid.net
TheGym.net - abuse@netforward.com
TheOffice.net - abuse@netforward.com
Theoffice.net - Postmaster@netforward.com
ThePentagon.com - abuse@netforward.com
Theplanet.net - abuse@theplanet.net
TheWaterCooler.com - abuse@netforward.com
TIAC.net - abuse@tiac.net
tip.net - postmaster@tip.net hh@tip.net
Together.net - abuse@together.net
Topsecrets100.com - webmaster@topsecrets100.com
Total.net - abuse@total.net -
http://central.total.net/centrale/totalnet/usepolicy.shtml (French) -
http://central.total.net/central/totalnet/usepolicy.shtml (English)
Tripod.com - abuse@tripod.com
TSEinc.com - postmaster@tseinc.com
U S West - abuse@uswest.net
UK.uu.net - E-Mail problems - mail@support.uk.uu.net , News problems -
news@support.uk.uu.net , Security problems - security@support.uk.uu.net
ULINK.NET - abuse@ULINK.NET
Ultra.net - abuse@rcn.com
Unbounded.net - abuse@unbounded.net
University of Alberta Canada - abuse@ualberta.ca
University of Pennsylvania - millar@pobox.upenn.edu - For security
matters : security@isc.upenn.edu
USA.Net - abuse@usa.net -
http://netaddress.usa.net/tpl/Info/General?AdInfo=&Referer=&InfoTitle=A
nti-Spamming+Policy&InfoFile=info_spam_body.html -
http://netaddress.usa.net/tpl/Info/SubAgreement
usol.com - postmaster@usol.com
UUNET - E-Mail Spams - abuse-mail@uu.net (just the e-mail and headers,
nothing else), Newsgroup Spams - abuse-news@uu.net . help@uunet.uu.net
- http://www.us.uu.net/support/usepolicy - See Also MS.UU.Net - For
abuse of the open UUNET NNTP port, UUNET will block the site if you
complain. See Gergsbane.org
uunet.ca - abuse@uunet.ca - http://www.uunet.ca/aup.html
UWO.CA - postmaster@julian.uwo.ca -
http://publish.uwo.ca/~reggers/spammers
Valueweb.net - abuse@valueweb.net
VCnet.com -abuse@vcnet.com
Verio.net - abuse@verio.net
WCom.Net - MCI WorldCom Advanced Networks - abuse@wcom.net
Webbernet.net - abuse@webbernet.net - abuse@cartman.webbernet.net
webcrawler.com - abuse.support@excitecorp.com -
http://www.excite.com/terms.html
Webjump.com - abuse@webjump.com
Webmaster.se - postmaster@webmaster.se
Webtv.net - abuse@webtv.net - http://webtv.net/tos.html
Whowhere.com - spam@whowhere.com -
http://pages.whowhere.com/internet/nospammers
Wild.net - abuse@wild.net
WOWmail.com - postmaster@wowmail.com
Writeme.com - Iname.com - abuse@Mail.com
www.idirect.com - spammer@idirect.com
www.tucows.com - spammer@idirect.com
xoom.com - abuse@xoom.com
Yahoo Mail - abuse@yahoo.com -
http://edit.my.yahoo.com/config/form?.form=yahoomail_agree
Zebra.net - abuse@zebra.net
Zippp.com - mike@zippp.com

From : David Jackson (djackson@aol.net) (and this applies to *any*
abuse) :
To report an instance of USENET abuse send mail to postmaster@aol.com -
please remember to include a complete copy of the USENET article,
including all headers, to help us quickly quash the abuse.

Scott reminds us :
It might also be a good idea to remind people that sometimes the
postmaster _is_ the spammer. Joe Spam might have his own domain (since
they _used_ to be free) inside of which they are the postmaster. This
is terrifyingly common with net.twits (kooks, etc.) but seems rare for
spam. A quick note that if the spammer is the admin contact in whois,
notifying the postmaster will surely generate laughs on their end.

In the letter to the postmaster, you might wish to mention Joel's very
good FAQ about advertising on the Internet :

http://www.cs.ruu.nl/wais/html/na-dir/usenet/advertising/how-
to/part1.html
http://www.cis.ohio-
state.edu/hypertext/faq/usenet/usenet/advertising/how-to/part1/faq.html

One company that was suckered in by a bulk e-mail company received 35
responses to the addresses in the body of the message, and 100% of them
were negative. Additionally the ISP that hosted them received 15
complaints asking for them to terminate their service. UUNet received
50+ complaints about this UCE.

And where they *should* advertise :
http://www.cs.ruu.nl/wais/html/na-dir/finding-groups/general.html

Additional business links:
http://www-personal.umich.edu/~jmm/papers.html#efi - Economic FAQ about
the Internet
http://www.si.umich.edu/Classes/555/resources/si555syllabus.html -
Electronic Commerce
http://www.si.umich.edu/Classes/555/resources/addition.html -
Additional Resources

If you don't get a proper response from the postmaster, remember, Whois
- rs.internic.net is your friend. See the section labeled "Converting
that IP to a name" for more information on Internic.

This *should* get you a person to talk to & their personal e-mail
address. If you don't get any response from that postmaster, then you
should try the provider to that site. This gets a little trickier, but
a traceroute should show you the upstream provider, and from there you
can try contacting the postmasters of *that* site.

Any non-profit organization (like a University) should be very happy to
help get rid of a spammer if the non-profit organizations resources are
being used to spam a for-profit business. The IRS can take their non-
profit status away for such things. Talk to the legal council at the
non-profit organization if you don't get a positive response from the
postmaster.

Worst case, a site can be UDP (Usenet Death Penalty) out so that other
sites stop accepting news or even e-mail from that site. They are cut
off from the net. Decisions like this are discussed in the news group
news.admin.net-abuse.misc .

If the spammer site has problems trying to figure out where the spam
came from, they can *always* get help from the denizens of
news.admin.net-abuse.misc, but have them take a look at their logs
first and see if they see something like (Thanks to help from Michael):

My news logs (for INND) are:
$ cd /usr/log/news
$ ls
OLD expire.log news.err unwanted.log
errlog news news.notice
expire.list news.crit nntpsend.log

and here is my syslog.conf:
## news stuff
news.crit /usr/log/news/news.crit
news.err /usr/log/news/news.err
news.notice /usr/log/news/news.notice
news.info /usr/log/news/news
news.debug /usr/log/news/news.debug

but, what they need to remember, is they HAVE TO LOOK QUICK!. INND
expire puts all these logs in OLD, and recycles them, and expires them
at the 7th day (and gzips them), i.e., OLD/:
ls -l news.?.*
-r--r----- 1 news news 181098 May 23 06:26 news.1.gz
...
-r--r----- 1 news news 319343 May 17 06:29 news.7.gz

so... to grep an old log looking for sfa.ufl.edu:
(the {nn} is how many days ago, 1 is yesterday, 2 is 2 days ago, etc)
cd {log/OLD}
gunzip -c news.1.gz | grep sfa.ufl.edu | more

Fraud on the Internet and The MMF (Make Money Fast) Posts
================================================================
A partnership of the National Association of Attorneys General, the
Federal Trade Commission and The National Consumers League :
http://www.fraud.org/
Call 1-800-876-7060 or fill out an on-line scam sheet:
http://www.fraud.org/info/repoform.htm
http://www.junkemail.org/scamspam/ - FTC ScamSpam
The Better Business Bureau has a web site at:
http://www.bbb.org
Hoaxes and scams :
http://ciac.llnl.gov/ciac/CIACHoaxes.html
http://www.abraxis.com/fans/PAGE_7.htm
http://www.scambusters.com/

In the United States :
The U.S. Securities and Exchange Commission web page (stock
solicitations, stock manipulation by sending out spam after buying a
stock to get others to buy the stock and increase the price)
http://www.sec.gov/enforce/comctr.htm or Email:
enforcement@sec.gov
http://www.sec.gov/news/netfraud.htm - SEC prosecutions
Net Securities scam: Report to cyberfraud@nasaa.org
http://www.nasaa.org/whoweare/media/Cyberfraud%20email%20release.htm
The Food and Drug Administration :
http://www.fda.gov/opacom/backgrounders/problem.html
Medical Items:
US Federal Drug Administration - MedWatch - Medwatch@OC.FDA.GOV

Make Money Fast is a pyramid (or Ponzi) scheme where you are in a chain
of people wherein you send money to a few people and try to recruit
others to send money to you. Basically if it even remotely smells like
a MMF scheme it is illegal (even tho' many of the MMF schemes "claim"
to have been looked at by a lawyer or checked by the United States
Postal Authorities).

For a list of countries where Make Money Fast is illegal see :
http://www.stopspam.org/usenet/mmf/mmf_table.html
http://www.stopspam.org/usenet/mmf/
http://ga.to/mmf/
Scams can be found at places like :
http://ga.to/mmf/currency.html

Please, only report MMFs in news.admin.net-abuse.misc if they're spam
and you've seen it in lots of groups and / or the postmaster/user are
defiantly stupid.

MMFs should be reported to the user and their postmaster and the
following :

The law in Australia and where to send complaints to :
http://www.wa.gov.au/gov/mft/pages/mftbn10.html
Ministry of Fair Trading
P O Box 6355
EAST PERTH 6536

In Canada I believe that the applicable Canadian description can be
found at :
http://www.rcmp-grc.gc.ca/html/commerc.htm
And from the Canadian Department of Justice server (
http://canada.justice.gc.ca/ ):
STATUTES OF CANADA, C, Competition - PART VI OFFENSES IN RELATION TO
COMPETITION - Definition of "scheme of pyramid selling" - Section 55.1
EXTRACT FROM THE CANADIAN CRIMINAL CODE
Chain-letters
206. (1) Every one is guilty of an indictable offense and liable to
imprisonment for a term not exceeding two years who . . .
Pyramid Schemes
55.1 (1) For the purposes of this section, "scheme of pyramid selling"
means a multi-level marketing plan whereby ...

United Kingdoms:
Consumer Affairs and Competition Policy Directorate 2
Department of Trade and Industry, 1 Victoria Street, London, SW1H 0ET
Tel: 0171 215 0344
Have a booklet called 'The Trading Schemes Guide' which is very useful
indeed and explains the UK legal details on these things,

In the United States, you should write the Federal Trade Commission Ms.
Broder
( bbroder@ftc.gov ). For more info on pyramid schemes use
pyramid@ftc.gov
To find your nearest postal inspector in the USA, see URL
http://www.usps.gov/ncsc/locators/find-is.html
To forward the MMF to the IRS, send it to:
net-abuse@nocs.insp.irs.gov
California MMF law :
http://www.leginfo.ca.gov/cgi-
bin/calawquery?codesection=pen&codebody=endless

DOES ANYBODY HAVE POSTAL INSPECTOR ADDRESSES FOR OTHER COUNTRIES THAT
PONZI / MMF SCHEMES ARE ILLEGAL IN?

Trying to catch the suspect still logged on
==================================================

If you think you know a machine close to the spammer, you can change
your default DNS lookup server (and get *lots* more info ;-)) by :
$ nslookup
> server wb3ffv.abs.net
Default Server: wb3ffv.abs.net
Address: 206.42.80.130
> ls -d kjl.com
[wb3ffv.abs.net]
kjl.com. SOA kjl.com dns-admin.abs.net. (10
21600 3600604800 86400)
kjl.com. NS ns1.abs.net
kjl.com. NS ns2.abs.net
kjl.com. MX 10 abs.net
kjl.com. SOA kjl.com dns-admin.abs.net. (10
21600 3600604800 86400)

If you are quick enough, you can see if the spammer is still on by :

rusers rust.nmt.edu

And you might get :

kuller ray timbers jweinman timbers john timbers rayzer

Assuming that the spammer is from ingress.com you can expand the
Spammers UserID (some sites have expn / vrfy turned off) by:

> telnet ingress.com smtp
Trying 199.171.57.2 ...
Connected to ingress.com.
Escape character is '^]'.
220 ingress.com Sendmail 4.1/SMI-4.1 ready at Sun, 22 Oct 95 15:13:39
EDT
expn krazykev
250 Lipsitz Kevin <krazykev@kjl.com>

We connect to port 25 (smtp) and issues an expn command. Looks like
krazykev@kjl.com is being used as a maildrop for this user. I'll would
send my complaint to postmaster@kjl.com as well (not that it would do
any good in Krazy Kevin's case... but the reply to your e-mail might
be amusing).

To find out the Mail Exchange records, do a nslookup for the MX records
only. You can then look up the expansion of the postmaster or root to
see who they really are. For example :
% nslookup
> set type=mx
> gnn.com

gnn.com preference = 20, mail exchanger = mail-e1a.gnn.com
gnn.com preference = 10, mail exchanger = mail-e1b.gnn.com

% telnet mail-e1a.gnn.com smtp
220 mail-e1a.gnn.com ESMTP Sendmail 8.7.1/8.6.9 ready at Thu, 11 Jan
1996 12:54:26 -0500 (EST)
expn postmaster
250-<wross@ans.net>
250 <gnnadvisor@mail-e1a.gnn.com>
expn root
250-<mitch@ans.net>
250 <gnn-monitor@ans.net>

You can use the 'host' command. It's really simple:
% host -t any domain.name

This will give you anything your name server can find out.

% host -t ns domain.name

This tells you the name servers. Not all systems have host, but it's a
small program which should be easy to compile (like whois).

The command "last" will tell where the spammer logged on from last, but
it has to be done by a user from that site. For example :

last imrket4u

Would produce :

imrket4u ttypf ip30.abq-dialin.hollyberry.com Fri Sep 15 00:27 -
00:34 (00:06)
imrket4u ttyq8 ip30.abq-dialin.hollyberry.com Fri Sep 15 00:19 -
00:20 (00:01)
imrket4u ttyqc abq-ts1 Thu Sep 14 20:42 - 22:21
(01:39)
imrket4u ttyqc rust.nmt.edu Thu Sep 14 18:39 - 18:41
(00:01)
imrket4u ttypb abq-ts1 Thu Sep 14 17:55 - 17:57
(00:02)

Filtering E-Mail BlackMail, procmail or News with Gnus
=======================================================

Filtering with BlackMail. This is free software that works with
Mailers Smail, Sendmail, Qmail or Fetchmail under the OSes: Aix,
various BSD, Irix, Linux, NeXTStep 3.x, Solaris, SunOs, SVR4:
http://bitgate.com/spam/ - By Ken Hollis (Not me ...)
Or
http://www.jsm-net.demon.co.uk/blackmail/source

Get the procmail FAQ :

http://www.ii.com/internet/faqs/launchers/mail/filtering-faq/
or
http://www.best.com/~ii/internet/faqs/launchers/mail/filtering-faq/

http://www.ii.com/internet/robots/
or
http://www.best.com/~ii/internet/robots/

Procmail ruleset :
http://sepwww.stanford.edu/oldsep/joe/AntiJunkEmail.html

Or read about it when it is posted to :
Newsgroups: comp.mail.misc , comp.mail.elm , comp.mail.pine ,
comp.answers , news.answers
Subject: Filtering Mail FAQ

Bob tells me that Eudora Pro has a good filtering capability. You can
filer based on who you send e-mail to, known spammers, etc. Enough
filters and you may see hardly any Spam. Claris E-Mailer, likewise,
has a filter option.

Brian has a Gnus scorefile from the Internet blacklist :
http://www.cs.ubc.ca/spider/edmonds/usenet/gnus/BLACKLIST

Or his example global scorefile :
http://www.cs.ubc.ca/spider/edmonds/usenet/gnus/SCORE

Many news readers have a "kill" file that will filter out the posts
from either a certain user-id, or posts with certain titles. Each news
reader is unique. You might wish to read the help file on the subject
of kill files.

Rejecting E-Mail from domains that continue to Spam
====================================================
Spamfilters can be found at:
http://www.io.com/~johnbob/jm/index.html
http://www.samiam.org/spam/index.html
http://www-new.hrweb.org/spambouncer/

List of spammers:
http://www.samiam.org/spam/spammers.txt
http://www.idot.aol.com/preferredmail/

Or look at a page on how to block e-mail :
http://www.nepean.uws.edu.au/users/david/pe/blockmail.html

Also how to stop your mail server from being a Spam Relay :
http://maps.vix.com/tsi/

Sendmail patch that permits filtering by envelope sender and recipient
as well as by Received: lines, header recipient (To: friends@public..)
and enables refusing of relaying _before_ transmission of the message:
ftp://ftp.hiss.org/pub/sendmail/

Ask your admin to add the following to their sendmail.cf. This will
reject all mail that continues to come in from domains that only send
out spam. This is a group effort from many admins :
Modify your sendmail.cf in the following way.
1. Setup a hash table with the domains you wish to block:
# Bad domains (spam kings)
FK/etc/mailspamdomains

2. Add the following rules to S98 (be sure that there are three lines
(i.e. the lines are not split up) and be sure to put a TAB character
between the $* and the $#error, not a space) :
### Spam blockage
R$* < @$*$=K . > $*$#error $@ 5.1.3 $: "Your domain has been
blocked due to spam problems. Contact your administrator."
R$* < @$*$=K > $*$#error $@ 5.1.3 $: "Your domain has been blocked due
to spam problems. Contact your administrator."

3. Make your hash table. Here is a very small example :
moneyworld.com
globalfn.com

Mail that comes in from any of these domains will be returned to sender
with the error. If the sender is bogus, it will bother the postmaster
at the bad domain in an appropriate manner.

Keep in mind that *ALL* email from these domains will be blocked. This
is really only a good solution for domains that are setup by spammers
for spamming. Blocking something like aol.com, although it may seem
initially attractive, would cause problems for legitimate users of
email in that domain. Compile your list after careful verification
that these domains fit the above description.

Misc.
=================================
Origins of Spam
======================
The history of calling inappropriate postings in great numbers "Spam"
is from a Monty Python skit (yes, it is very silly... see
http://www.ironworks.com/comedy/python/spam.htm ) where a couple go
into a restaurant, and the wife tries to get something other than Spam.
In the background are a bunch of Vikings that sing the praises of Spam.
Pretty soon the only thing you can hear in the skit is the word "Spam".
That same idea would happen to the Internet if large scale
inappropriate postings were allowed. You couldn't pick the real
postings out from the Spam. See:
http://www.geocities.com/~hkentcraig/HowInternetSpamGotItsName.html

To join a discussion list for Spams, send a message to
listserv@internet.com
In the body of the message type :
subscribe spamad your_name your_affiliation

Or a real mailing list for the discussion on spamming and about what
is and/or isn't possible in dealing with this problem. If you would
like to join the mailing list send mail to majordomo@psc.edu with the
following message in the body :
subscribe spam-list [preferred address]

Black listed Internet Advertisers :
http://math-www.uni-paderborn.de/~axel/BL/ (Europe)

Oldmilk tells us the alt.spam Commandments :
1) Thou shalt not post binaries to a non binary group.
2) Thou shalt not post "sPaM this l00zer" to alt.spam
3) Thou shalt not post to inform us for the thousandth time that this
group was started to discuss the fine spiced ham product from Hormel.
4) Thou shalt not spam this newsgroup.
5) Thou shalt not post on a topic that has nothing to do with spam
fighting.
6) Thou shalt not harass any regular poster here, lest your ass be
spanked to rosy hue.
7) Thou shalt not attempt to make any straw man arguments that spam is
good.
8) Thou shalt read the newsgroup before posting.

First off, the only CORRECT way to "SPAM" the net :
http://www.spam.com/
http://www.spam.com/fc.htm - SPAM Fan Club
http://www.spam.com/ci/ci_in.htm - Spam, SPAM and the Internet ... Use
"Spam" when referring to Internet Unsolicited E-Mail, ONLY use "SPAM"
(all CAPS) when referring to the Hormel Product.
Show SPAM Gifts http://coyote.co.net/spamgift/
Or for the free SPAM recipe Book ($1.00 postage and handling) :
SPAM recipe Book, P.O. Box 5000, Austin, MN 55912
Or for SPAM merchandise and apparel call 1-800-LUV-SPAM

SPAM Sites (the food) / The Church of Spam :
http://pemtropics.mit.edu/~jcho/spam/ - SPAM Haiku
http://www.go2net.com/internet/useless/useless/spam.html
http://www.iconnect.net/home/jstrong/spam.html
http://www.rsi.com/spam/
http://www.rsi.com/spam/spam-recipes.html - SPAM Recipes
http://www.spam69.demon.co.uk/spam.htm
http://www.stampo.com/spam.html

There is also a letter circulating about "dying boy wants postcards"
(Craig Shergold) which is no longer true. Same as with the Blue Star
LSD addicting children hoax. See Urban Folklore FAQ at :

http://www.urbanlegends.com/classic/craig.shergold/craig_nyt.html
http://www.urbanlegends.com/classic/blue.star.tattoos/blue_star_lsd_faq
.html

A complete Urban Legends listings (It is big) :
http://www.urbanlegends.com/afu.faq/index.html

PLEASE read about the Gullibility Virus. This is a very funny
editorial to be passed along to your friends who send you all those
hoaxes :
http://www.sccu.edu/faculty/R_Harris/warning.htm

And why Disney is *not* giving away 13,000 free trips, why Bill Gates
is not collecting e-mail addresses (and many other hoaxes):
http://www.deja.com/article/406150013

There has been some discussion that such things should be canceled
because they exceed the BI 20 index. They are untrue and they waste
bandwidth.

A conversation with a spammer. I was amused. First time I had ever
spoken with one. I also forgot to mention (in our very short
conversation) that his World Wide Web service would be deleted (which
it was) :
Me (7:04 PM):I got your spam. By Monday morning all your accounts
should be canceled. That would be your AT&T account, your Hotmail
account and this AOL account. You are welcome. Bye.
GS711 (7:05 PM):<snip - Expletive Deleted>
Me (7:05 PM):Thank you very much. You should learn how to
advertise correctly on the Internet.
Me (7:06 PM):If you do it correctly than you won't have to run and
hide.
GS711 (7:06 PM):thanks for letting me know who you are
Me (7:06 PM):Who am I? :-) ...
Me (7:06 PM):BTW, all your Spams will be reported by many other
people other than myself ...
(He signed off)

How *did* I get this unsolicited e-mail anyway?
==================================================
Unfortunately just posting a message to a news group can get
unsolicited e-mail. Some spammers "harvest" e-mail addresses by
stripping e-mail return addresses out of messages people post. Try
posting to alt.test a few times. You will get not only a few
autoresponder messages (that is how it is *supposed* to work) but also
a few unsolicited pieces of e-mail. The solution to this is to "mung"
your address when you post by adding in extra characters (like "Spam")
in your return address. You then put in your signature something like
"Remove the word Spam from my e-mail to contact me". See:
http://members.aol.com/emailfaq/mungfaq.html - Address Munging

Another way to get e-mail is to have a World Wide Web page. Some
spammers just start a web spider (a piece of software that just
traverses World Wide Web pages and collects information) going and
collect e-mail that way. To prevent your e-mail from being harvested,
you can "mung" your web e-mail. See:

http://www.powerup.com.au/~mfleming/antispam/webmung.html

A suggestion of some nasty little HTML items to have in your WWW page
(invisible, of course) are :

<A HREF="mailto:root@[127.0.0.1]"></a>
or if your server allows "server-side includes" (and .shtml) :
<a href="mailto:abuse@<!--#echo var="REMOTE_ADDR"--> ">anti spambot</a>

Also you might include a mail to news gateway like the following so
that the Spam is posted to Usenet :

See http://www.sabotage.org/~don/mail2news.html for mail to news
gateways.

<A HREF="mailto:news.admin.net-abuse.email@myriad.alias.net"></a>
Or
<A HREF="mailto:news.admin.net-abuse.misc@myriad.alias.net"></a>
Or
<A HREF="mailto:news.admin.net-abuse.usenet@myriad.alias.net"></a>

Note : You should note on your World Wide Web page that these links
should *not* be followed by Lynx users, as they will see them no matter
how you choose not to display them on a graphical interface. The last
few in the below list are particularly not nice as they execute
commands on a UNIX host. Substitute root@[127.0.0.1] with any of the
following :
postmaster abuse root admin postmaster@localhost abuse@localhost
root@localhost admin@localhost postmaster@loopback abuse@loopback
root@loopback admin@loopback
`cat /dev/zero > /tmp/...`@localhost
;cat /dev/zero > /tmp/...;@localhost
`umount /tmp`@localhost
;umount /tmp;@localhost
`halt`@localhost
;halt;@localhost

1-900, 1-800, 888, 877 and 1-### may be expensive long distance phone
calls
=======================================================================
====
Be very careful when dialing a 1-800 or any "toll free" number you are
not familiar with. It may end up being a very expensive mistake.
Remember to dial these numbers from a phone booth so that your home
phone will never be charged. Another reason to call from a pay phone
is so that the spammer cannot get your home phone number. Even if you
are "Unlisted" when you call a toll free number the spammer gets your
phone number.

All 1-800, 888 or 877 numbers are *not* free. You may be charged for
the phone call. You can tell if the number charges by calling from a
phone booth. If you cannot get through then it charges. See below.

Likewise, numbers that may "look" like they are United States long
distance phone numbers may in fact be out of country and may cost you
$25 or more for a couple of minutes call. These calls are not
refundable. A scam artist trying to get money from the phone calls (he
gets a skim off the top) was dialing random beepers with an out of
country number.

A phone scam can be read at http://webcrawler-
news.excite.com/news/r/990519/07/odd-scam

Some area codes to look for (some may not be active for another year or
two):
(Also see http://www.nanpa.com/number_resource_info/assignments.html )

242 Bahamas
246 Barbados
264 Anguilla
268 Antigua
284 British Virgin Islands
340 U.S. Virgin Islands
345 Cayman Islands
441 Bermuda
473 Grenada
649 Turks and Caicos
664 Monserrat
670 CNMI (Commonwealth of the Northern Mariana Islands?)
671 Guam
758 St. Lucia
767 Dominica
784 St. Vincent and Grenadines
787 Puerto Rico
868 Trinidad and Tobago
869 St. Kitts and Nevis
876 Jamaica

If the ad says "Procall", it is a large service bureau for 1-900
numbers in Arizona. When you call a pay-per-call number, there should
be a recorded intro that will give a customer service number. That
*should* connect with a live person.

I would like to thank Eileen at the FTC for kindly answering my
questions about 1-900 & 1-800 phone numbers.

Paraphrasing what she e-mailed me :
When a 1-900 number is advertised, the price must also be disclosed
(this may be found at 16 CFR Part 308).

When calling a 1-800 number that charges, there must be an existing
subscription agreement between the buyer and the seller

http://www.ftc.gov/ Federal Trade Commission Home Page
http://www.ftc.gov/bcp/telemark/rule.htm Telemarketing Sales Rule
http://www.ftc.gov/bcp/conline/edcams/telemarketing/index.html -
Telemarketing informations / scams
http://www.ftc.gov/bcp/conline/fraud.htm Reporting fraud

(from the "Online Scams page)

How To Respond to Spam
===========================

Howard reminds us :
Note to all: NEVER followup to a spam. NEVER. Express your
indignation in mail to the poster and/or the postmaster@offending.site,
but NEVER in the newsgroups!

Karen asks:
But what about the newbies who look at a group, see lots of spam and
ads, see NO posts decrying them, and conclude that ads are therefore
OK?

Ran replies :
When it gets bad, you'll usually see some "What can we do about this?"
threads. That's a good place to attach a reply that tells people why
it's bad, and what they can, in fact, do.

Austin Suggests:
At the risk of attracting flames, let me suggest an exception to
Howard's law. A followup is allowed if the following 3 conditions
hold.
1) The offending article is clearly a SCAM (for instance, the
*Canada* calls with the Seychelles Islands phone # scam)
2) No one else has followed-up with a posting identifying it as a
scam (in other words, no 'Me too' warnings)
3) It is unlikely to be canceled soon, either because it seems to be
below the thresholds, or it is in a local hierarchy that doesn't get
cancels, or Chris Lewis is on vacation in the Seychelles Islands. If
all three conditions are met, a followup that X's out the contact
information , severely trims the contents and identifies the post as a
scam is exempt from Howard's law.
Bill's and Wolfgang's addition :
4) Follow-ups should be cross posted to news.admin.net-abuse.misc
_and_ the groups of the spam, but Followup-To: *MUST* be set to
news.admin.net-abuse.misc *ONLY*
_or_
post a follow-up and *SET* Followup-To: alt.dev.null.
In the first case change
Subject: Important FREE $$$
to
Subject: Spam (was Re: Important FREE $$$)
and include the original Newsgroups and Message-ID line, so the
professional despammers will immediately find what you're talking
about. Do not post unless you're absolutely sure that you can do all
that properly. Also 1) - 3) do apply.

If you see the same article with different Message-IDs in several
groups, collect the _complete_ headers of each article and check
news.admin.net-abuse.misc if it's already been reported. If not, start
a thread with Subject: Spam (was Re: <original Subject>) in
news.admin.net-abuse.misc or news.admin.net-abuse.usenet . Include all
of the headers and as much of the body of one article as you see fit.

Revenge - What to do & not to do
========================================

No matter how much we hate Spam and how much we dislike what the
spammers to our quiet little corner of the Universe known as the
Internet, Spam is not illegal (yet). If you try anything against the
spammers, please * do not * put yourself in risk of breaking the law.
It only makes them happy if you get in trouble because you were trying
to get back at them.

The reason why spammers use "throwaway" accounts is because they know
the e-mail account will be deleted. They usually provide either
another e-mail address or a name / phone number or postal address so
that prospective "customers" can be contacted. Be sure to complain to
the postmaster of all e-mail names provided to make sure that this
route is inhibited.

Telephoning someone
======================

Calling someone once is fine. If enough people are irritated at the
spammer and they all call the 1-800 number the spammer provides, the
spammer will get the idea (sooner or later) that it is costing them
more in irate people (and most especially loss of business) and it is
not worth it to spam.

Do not dial any phone numbers more than once from your home. Phone
harassment is * illegal * and you * can * be prosecuted in court for
this. Even tho' the caller id blocking code (may be *67 or *71 or some
other code) prevents your number from being displayed on their
telephone at home if they have caller ID, *57 will give the phone
company the number, *69 will dial back the phone number via automatic
call back. If it is a 1-800 number there are two problems. First they
can *always* get your phone number, and secondly it may *not* be a toll
free number. You may be charged for calling a 1-800 number.

Likewise, do not call collect using 1-800-COLLECT or 1-800-CALL-ATT
from home, once again this can be traced.

Austin comments : I would say that calling a listed non-800 number
*once* collect to voice a complaint is not harassment, but justified.
They sent you a postage due message, didn't they? If they don't want
to accept collect calls, they should say so - and if they do, you
should be a responsible person and not do it again.

AT&T Information for 1-800 numbers is 1-800-555-1212, but that only
helps if you know the company name you are trying to call. Also, you
can try searching for a 1-800 number (you do not have to know the
company name) at :
http://www.anywho.com/tf.html

Other telephone search mechanisms:
http://expertx.com/Free/xPhone/Locate.htm - Where that phone number is
located
http://www.zip2.com/
http://www.bigbook.com/
http://www.switchboard.com/
http://www.555-1212.com/

Snail Mailing someone
=======================

Likewise, one well thought out letter sent to the spammer might help
convince the spammer not to do this again. Especially if the spammer
was part of a corporation that didn't realize the detrimental effects
of spamming the Internet.

If you decide to deluge the spammers postal address by filling out one
or two "bingo" (popcorn) postage paid cards in the technical magazines
(by circling a few dozen "product info" requests per card & putting on
printed out self sticking labels with the spammers address), or by
putting preprinted labels on postage paid cards that come in the mail
in the little plastic packages, don't organize a public campaign (that
they can point to) against the spammer in the newsgroup.

Scott also reminds us :
Since this is the "Spam FAQ", I'd like to point this out: You're
basically Spamming the company offering information in a magazine. It
costs companies money, not the one you're spamming. They get a free
pile of junk which is easy to throw out. In other words, this may be
harming third parties more than the intended target. I'm not trying to
be Mr. Nice Guy, just trying to point out an important technicality.

Junk Mail - The Law :
http://www.vtwctr.org/casewatch/
http://192.41.4.29/index.html - 'Lectric Law Library

You should also read Title 47 of the United States Code, Section 227.
There is a FAQ at cornell.law.edu for the text of the law (gopher or
ftp or http://www.law.cornell.edu/uscode/47/227.html ), and you can use
DejaNews to read the USC 47 thread on news.admin.net-abuse.misc to make
up your own mind (it invariably comes up) or you can look at :

http://www.cybernothing.org/docs/code47.5.II.txt

In Washington (State) (for example) fax laws (RCW 80.36.540 -
Telefacsimile messages) define "telefacsimile message" in such a way
that could be interpreted to include E-mail. It was not originally
written to cover E-Mail, but that is for the courts to decide :-).
California regulates it thru Section 17538(d) of the Business and
Professions Code.

A spammer has actually been prosecuted. See:
http://www.oneworld-design.com/nospam.html

In California (Quoted from http://Spam.abuse.net ): Spamming to or from
California e-mail service providers against their policy is now a civil
offense under California Business and Professions Code Section
17538.45. If you run a California-based e-mail service provider, you
need to notify your customers of the law and your anti-spam policy in
order to be eligible to collect damages of $50 per message.

Organizing a campaign against the spammer in a news group could lead to
the spammer trying to get a cease & desist police order against the
organizers.

Disclaimer : I am not a lawyer, 80% of the Internet is bull, free
advice is worth every penny you paid for it :-). Brought to you via
News since November 1995.

------------------------------------------------------------------
Do not meddle in the affairs of wizards for they are subtle and
quick to anger.
Ken Hollis - Gandalf The White - gandalf@digital.net - O- TINLC
WWW Page - http://ddi.digital.net/~gandalf/
Trace E-Mail forgery - http://ddi.digital.net/~gandalf/spamfaq.html
Trolls crossposts - http://ddi.digital.net/~gandalf/trollfaq.html


Spam Glossary

Here is a good place to start to learn the jargon relating to spam.

www.turnstep.com/Spambot/glossary.html


Antispam laws

The information provided can be found at www.spamlaws.com website. Please refer to this site for updated information.

US Federal

  • CAN-SPAM Act of 2003 (S. 877) effective Jan. 1, 2004 and supercedes state laws

  • Pending legislation from 108th Congress (2003-2004)

  • Pending legislation from 107th Congress (2001-2002)

  • Pending legislation from 106th Congress (1999-2000)

US States

The following information can be found at www.spamlaws.com/state/summary.html. Please refer to this site for more current information as the information below was summarized in 2003. Unfortunately many of the state-specific details are preempt by the CAN-SPAM Act of 2003.

More detailed information of what each state has enacted can be found by following the link provided.

State | When enacted
Alabama | None yet as of July, 2002
Alaska | May 2003
Arizona | May 2003
Arkansas | April, 2001
California | September, 1998
Colorado | June, 2000
Connecticut | June, 1999
Delaware | July, 1999
Florida | None yet, though there is a FL bar ruling (Fla. R.P.C. 4-7.6(c)(3)) requiring attorneys to make their unsolicited email clearly marked with a subject line with "legal advertisement".
Georgia | None yet as of 2004
Hawaii | None yet as of 2004
Idaho | April, 2000
Iowa | None yet as of 2004
Illinois | July, 1999
Indiana | April 2003
Iowa | May, 1999
Kansas | May, 2002
Kentucky | None yet, though there exists a KY Supreme Court ruling (Ky. Sup. Ct. R. 3.130(7.09)(3) requiring attorneys to include "THIS IS AN ADVERTISEMENT" in each unsolicited communication to prospective clients.7
Louisiana | July, 1999
Maine | May 2003
Maryland | May, 2002
Massachusetts | None yet as of 2004
Michigan | September 2003
Minnesota | May, 2002
Mississippi | None yet as of 2004
Missouri | June, 2000
Montana | None yet as of 2004
Nebraska | None yet as of 2004
Nevada | July, 1997 and 1999
New Jersey | None yet as of July, 2002
New Mexico | April 2003
New York | None yet as of July, 2004
North Carolina | June, 1999
North Dakota | April 2003
Ohio | August 2002
Oklahoma | June, 1999 and amended in April 2003
Oregon | September 2003
Pennsylvania | June, 2000
Rhode Island | July, 1999
South Carolina | None yet as of July, 2004
South Dakota | February, 2002
Tennessee | June, 1999
Texas | June 2003
Utah | March, 2002
Vermont | None yet as of July, 2004
Virginia | March, 1999
Washington | March, 1998 and amended in May 1999
West Virginia | March. 1999
Wisconsin | June, 2001
Wyoming | March 2003

European Union

  • Various countries

The World

  • Other Countries


AppE Overview

Rule script resources

Praetor provides the rule script developer several facilities for analyzing the message. When the script is called, Praetor will already have scanned the message and built a message object. The object contains

  • properties and

  • functions

Object Properties

These properties are accessible from the message object.

Property | Message header value or description
From | From field value.
FromDomain | The domain name portion from the From field.
Sender | Sender field value.
SenderDomain | The domain name portion from the Sender field.
Subject | Subject field value.
Date | Date field value.
Content-Type | Content-Type field value within a MIME segment.
RuleID | Returns/assigns the Rule ID of the rule currently being processed.
RuleDesc | Returns/assigns the Rule Description of the rule currently being processed. This string can be found in the Praetor log.
LocalDomains | List of domain names that Praetor considers local. Each domain is separated by a vertical bar '|' character.
FileName | The fully qualified filename of the message currently being processed.

Object Functions

These functions are accessible to the script.

Function | Description
Delete() | Terminal action to delete the message currently being processed. This action is mutually exclusive with Accept() and Quarantine().
Accept() | Terminal action to accept the message currently being processed. This action is mutually exclusive with Delete() and Quarantine().
Quarantine | Terminal action to quarantine the message currently being processed, placing it into a special Praetor quarantine directory, Praetor\Quar. This action is mutually exclusive with Delete() and Accept().
Archive | Optional action that makes a copy of the current message, placing it into the Praetor\Archive subdirectory. The message so placed will have an extension of CMS. This optional action must be followed by one of the terminal actions: Delete(), Accept(), or Quarantine().
StringSearch(Source, Key, SearchMask ) | Search through the Source string for the Key string using the searching method defined by the SearchMask. Returns TRUE if the Key is found, FALSE if not found.
LookUp( ListName, Key, SearchMask ) | Search for Key in the list of items named ListName using the search method defined by SearchMask whose value must either be SEARCH_LIST or SEARCH_ELIST. Returns TRUE if found or FALSE if not found.
LookUp2( ListName, Key1, Key2, SearchMask ) | Search for Key1 or Key2 in the list of items named ListName using the search method defined by SearchMask whose value must either be SEARCH_LIST or SEARCH_ELIST. Returns TRUE if found or FALSE if not found.
LookUpObject( ItemType, ListName, SearchMask ) | Searches for an item whose value matches any of the keys specified in the list named by ListName. Searching stops when the first item of one of the types specified by ItemType is found with a match or when all types specified have been searched. SearchMask must include SEARCH_LIST or SEARCH_ELIST. Returns: TRUE or FALSE
LookUpByFieldName( FieldName, Key, SearchMask ) | Attempts to look up an item by its field name rather than item type. This is useful for searching X-fields which are encoded by Praetor as ITEMTYP_XFIELD. Since there can be any sequence of characters after "X-", we would need to use LookUpByFieldName() to specifically search for, say, "X-Priority". Returns: TRUE or FALSE
LookUpByItemType( ItemType, Key, SearchMask ) | Searches for any item specified by ItemType whose value matches with Key. Multiple items can be included in the search by OR-ing multiple item types together. Returns: TRUE or FALSE
LookUpAttachment( FileSpec, SearchMask ) | Determines if the specified attachment filename can be found in the message. Matching the attachment names with FileSpec is done as case-Insensitive substring match. That is, if FileSpec is "EXE", then this will match on filenames of "execution.txt" and "test.exe". Therefore, to search for EXEs, use ".EXE". In MIME attachments, Praetor looks for the "name=" attribute/value component of either the Content-Type: field or Content-Disposition: field. Returns: TRUE or FALSE
SectionSearch( Section, Key, SearchMask ) | Searches through various sections of a message for the key specified. The sections that can be specified are: SECTION_821, SECTION_822, or SECTION_BODY. The different sections can be combined by OR-ing these values together if more than one section needs to be searched in a single SectionSearch() call. Returns: TRUE or FALSE
DNSLookUp( ItemType ) | Performs a DNS look up on the address items specified. If an item type is other than an address, this type is ignored. Different address item types can be searched in one call by OR-ing the types. Returns: TRUE or FALSE
CountByItemType( ItemType ) | Counts the # of items found in the message whose type is one that matches ItemType. Multiple items can be specified by OR-ing the individual ITEMTYP_ values. Returns: # of items found
Size() | Returns the size of the entire message. This is determined by finding out the size of the message file. Returns: # bytes
SizeInRange( Lower, Upper ) | Determines if the size of the message is within a given range (inclusive) as specified by Lower and Upper. Returns: TRUE or FALSE


Object properties

These properties are accessible from the message object.

Property | Message header value or description
From | From field value.
FromDomain | The domain name portion from the From field.
Sender | Sender field value.
SenderDomain | The domain name portion from the Sender field.
Subject | Subject field value.
Date | Date field value.
Content-Type | Content-Type field value within a MIME segment.
RuleID | Returns/assigns the Rule ID of the rule currently being processed.
RuleDesc | Returns/assigns the Rule Description of the rule currently being processed. This string can be found in the Praetor log.
LocalDomains | List of domain names that Praetor considers local. Each domain is separated by a vertical bar '|' character.
FileName | The fully qualified filename of the message currently being processed.


Object functions

These functions are accessible to the script.

Function | Description
Delete() | Terminal action to delete the message currently being processed. This action is mutually exclusive with Accept() and Quarantine().
Accept() | Terminal action to accept the message currently being processed. This action is mutually exclusive with Delete() and Quarantine().
Quarantine | Terminal action to quarantine the message currently being processed, placing it into a special Praetor quarantine directory, Praetor\Quar. This action is mutually exclusive with Delete() and Accept().
Archive | Optional action that makes a copy of the current message, placing it into the Praetor\Archive subdirectory. The message so placed will have an extension of CMS. This optional action must be followed by one of the terminal actions: Delete(), Accept(), or Quarantine().
StringSearch(Source, Key, SearchMask ) | Search through the Source string for the Key string using the searching method defined by the SearchMask. Returns TRUE if the Key is found, FALSE if not found.
LookUp( ListName, Key, SearchMask ) | Search for Key in the list of items named ListName using the search method defined by SearchMask whose value must either be SEARCH_LIST or SEARCH_ELIST. Returns TRUE if found or FALSE if not found.
LookUp2( ListName, Key1, Key2, SearchMask ) | Search for Key1 or Key2 in the list of items named ListName using the search method defined by SearchMask whose value must either be SEARCH_LIST or SEARCH_ELIST. Returns TRUE if found or FALSE if not found.
LookUpObject( ItemType, ListName, SearchMask ) | Searches for an item whose value matches any of the keys specified in the list named by ListName. Searching stops when the first item of one of the types specified by ItemType is found with a match or when all types specified have been searched. SearchMask must include SEARCH_LIST or SEARCH_ELIST. Returns: TRUE or FALSE
LookUpByFieldName( FieldName, Key, SearchMask ) | Attempts to look up an item by its field name rather than item type. This is useful for searching X-fields which are encoded by Praetor as ITEMTYP_XFIELD. Since there can be any sequence of characters after "X-", we would need to use LookUpByFieldName() to specifically search for, say, "X-Priority". Returns: TRUE or FALSE
LookUpByItemType( ItemType, Key, SearchMask ) | Searches for any item specified by ItemType whose value matches with Key. Multiple items can be included in the search by OR-ing multiple item types together. Returns: TRUE or FALSE
LookUpAttachment( FileSpec, SearchMask ) | Determines if the specified attachment filename can be found in the message. Matching the attachment names with FileSpec is done as case-Insensitive substring match. That is, if FileSpec is "EXE", then this will match on filenames of "execution.txt" and "test.exe". Therefore, to search for EXEs, use ".EXE". In MIME attachments, Praetor looks for the "name=" attribute/value component of either the Content-Type: field or Content-Disposition: field. Returns: TRUE or FALSE
SectionSearch( Section, Key, SearchMask ) | Searches through various sections of a message for the key specified. The sections that can be specified are: SECTION_821, SECTION_822, or SECTION_BODY. The different sections can be combined by OR-ing these values together if more than one section needs to be searched in a single SectionSearch() call. Returns: TRUE or FALSE
DNSLookUp( ItemType ) | Performs a DNS look up on the address items specified. If an item type is other than an address, this type is ignored. Different address item types can be searched in one call by OR-ing the types. Returns: TRUE or FALSE
CountByItemType( ItemType ) | Counts the # of items found in the message whose type is one that matches ItemType. Multiple items can be specified by OR-ing the individual ITEMTYP_ values. Returns: # of items found
Size() | Returns the size of the entire message. This is determined by finding out the size of the message file. Returns: # bytes
SizeInRange( Lower, Upper ) | Determines if the size of the message is within a given range (inclusive) as specified by Lower and Upper. Returns: TRUE or FALSE


FAQ Overview

This appendix contains Frequently Asked Questions.

    1. How do messages flow through Praetor?

    2. How do I deactivate Praetor?

    3. How can Praetor be installed with Microsoft Exchange v5.5?

    4. How can Praetor be set up for testing in a production environment?

    5. Adding an X- message header field to tag possible spam for Outlook clients to automatically move spam

    6. How do I change the SMTP port if I use an older version of Domino prior to R5?

    7. How do I configure Praetor to use a real-time blackhole list (RBL) or known spam mailhosts?

    8. Expiration of the 21-day evaluation

    9. Issues with firewalls

    10. Issues with SMTP mail servers

    11. Issues with virus scanners

    12. Error codes found in the Windows application event log

    13. What are the indicators that I have run into MSDE limits?

    14. What are the BASIC pre-configured rules?

    15. How to blacklist IP addresses?

    16. Bayesian training tips


How messages flow through Praetor

Messages flow through Praetor in three simple steps. These have been summarized for the inbound and outbound directions below. Please realize that Praetor distinguishes the direction for the message by looking at the intended recipients' domain. If all recipients' domain are recognized as being local domain(s), then it is considered an inbound message to a local user. Otherwise the message is considered as outbound, and destined to an Internet recipient.

Note:

The folder references on this page use the main Praetor folder as the starting point. While it is shown abbreviated as Praetor in paths below, the full and correct path is C:\Program Files\CMS Praetor G2.

Inbound: Internet --> Exchange

  1. A message from the Internet is received by the Windows SMTP Service (part of Microsoft Internet Information Services) and once it passes any SMTP protocol level tests, Praetor is called to analyze the received message.

  2. Praetor creates a temporary message file in the working OUT folder, determines the message direction and filters according to the inbound rules and Bayesian analysis. One of three possible mandatory actions will occur, depending on the incoming rules you have in effect:

    - Reject: deletes the message file.
    - Quarantine: moves the message file into the Praetor\Quar folder.
    - Accept: notifies the Windows SMTP Server to delivery the message.

    Optionally a copy of the message may be placed into the Praetor\Archive folder.

  3. Windows SMTP Service transmits the message to your mail server.

Outbound: Exchange --> Internet

  1. A message from the local mail server is received by the Windows SMTP Service and Praetor is called to analyze the received message.

  2. Praetor creates a temporary message file in the working OUT folder, determines the message direction and filters according to the outbound rules. One of three possible mandatory actions will occur, depending on the incoming rules you have in effect:

    - Reject: deletes the message file.
    - Quarantine: moves the message file into the Praetor\Quar folder.
    - Accept: notifies the Windows SMTP Server to delivery the message.

    Optionally a copy of the message may be placed into the Praetor\Archive folder.

  3. Windows SMTP Service transmits the message to its destination on the Internet.

Log files in Praetor

Praetor LOG entries are now kept in a SQL database, specifically PraetorLog:

Table | Description
tblEvent | Entries for all messages filtered by Bayesian analysis and active rules.
tblProtocolEvent | Entries filtered at the SMTP protocol level e.g. DNS Blackhole list. Summary information will be limited since no message was ever received for analysis, instead the source IP address was used. Please see this note as SMTP protocol level DNSBL filtering is not enabled due to susceptibility to a denial-of-service attack..

Windows SMTP Server log entries are also available that record SMTP commands and responses during message reception and transmission. This is typically used when tracing message movement, and needs to be configured to record extended information in IIS Manager.


How to deactivate Praetor

If you see the need to temporarily deactivate Praetor and restore your original mail server as the active receiver, it is not necessary for you to de-install it. This is especially true if you are trying to get assistance from CMS technical support. Do not de-install Praetor as re-installing may introduce another problem that masks your original issue.

All you need to do is simply stop the Praetor service from its Microsoft Management Console administration snap-in. This is done by highlighting the [image] icon in the left pane and right-mouse click to bring the action menu.

Select the Stop Praetor menu item.

When Praetor is stopped, email will still be received by the Microsoft virtual SMTP server but Praetor will no longer perform any filtering.

These steps are valid for any mail environment where you use Praetor, whether or not the ultimate server is on the same or different machine.

If Praetor is already disabled, then you can select to re-enable its filtering by selecting the Start Praetor menu item.


How to set up Praetor for testing in a production email environment

It is possible to install Praetor in a test mode with zero impact to your production email environment. This would mean you can turn on/off Praetor at will without any loss of messages, and see how effective it would be for your site.

CMS recommends you test Praetor by doing the following:

1.

Install Praetor on a separate PC with Windows 2000 or XP Professional edition that can be assigned its own exposed static IP address. Praetor works better as a firewall for email than your normal firewall, so it is safe to do this. Just make certain this PC has no other running services except for SMTP.

Note:

If you are trying to put Praetor behind your firewall, it may mean that one key filter may be ineffective. If your firewall accepts inbound email completely and then relays it to Praetor, the querying of the DNS Blackhole List servers will be rendered useless. This is because Praetor uses the IP address of the sending mail server to perform the query, and this IP address will simply be that of your firewall.

Some firewalls such as Cisco's provides for a complete pass-through of the SMTP packets and Praetor is able to get the correct IP address of the mail server sending the message. In such cases, the DNS Blackhole list queries will work.

2.

Configure IIS SMTP Server to route the filtered and acceptable messages to your normal Exchange, Domino or other SMTP mail server.

3.

Enable Praetor.

4.

If this Praetor machine is placed on the unprotected side of your firewall, add a new DNS MX record for this Praetor machine, specifying a preference value that is lower than your existing normal SMTP mail server.

This last step is the critical one that lets you inject this Praetor machine into your production email environment without any drawbacks. Within 24-48 hours this new MX record will have propagated through-out the global Internet and during this transition you will notice Praetor will be receiving an increasing percentage of your normal email traffic. Should Praetor ever be taken off-line, all mail hosts will attempt to connect to Praetor first and, finding no response, they will then connect to your normal and original mail server.


Using the action to add an X- field

Add an X- field to let Outlook clients automatically deal with spam

Praetor has an optional action to add X- fields into the message headers. This ability represents an interesting potential for server-client cooperative processing of email messages. Praetor will first filter the email messages and tag it with an appropriate X- field, then pass it on to the Exchange server. When the recipients' Outlook client email program retrieves the messages, it has its own rules and can enact upon the message to suit the recipients' own needs.

A good example to illustrate this capability would be to modify the anti-spam rules so that, instead of having Praetor quarantine the message, choose to accept the message and add to the message header a new X-field called "X-Praetor-Analysis" with its value set to be "Possible-spam". Then on the recipient side, use the Outlook Rule Wizard to create a rule that automatically moves the message from the normal Inbox into a new subsidiary folder called "Possible spam". This new folder can then be set with a property to be emptied automatically if older than 30 days.

Here are the steps to accomplish this using a sample anti-spam rule that tests for the From address being the same as the single To recipient address.

1.

On the Praetor machine, use the administration MMC snap-in to modify the anti-spam rule and then select the Actions tab. Change the primary action from Quarantine to Accept the message and Flag the message as possible spam as the optional action. You may also want to select Add the reason why the message was caught and Add name of the rule that caught the message action as illustrated below.

Adding the above three optional actions will add 3 lines into the message header in this order:

  1. X-Praetor-Analysis: Possible-spam

  2. X-Praetor-Reason: <text with specific reason how condition was met>

  3. X-Praetor-Rule: <name of rule that caught the message>

The bolded and underlined text will be replaced with the actual reason and rule name.

2.

On the recipient's Outlook client prior to the 2003 version, create a new subfolder beneath Inbox, calling it "Possible spam".

Starting with Outlook 2003, a spam folder already exists off the root node and is called Junk E-mail, so you can skip this step.

4.

Use the Outlook Rules Wizard to create a new rule that applies whenever a message arrives.

5.

For the condition, select "with specific words in the message header".

For the specific words, enter the message header line and value.

6.

Next, specify the action for the Outlook rule — moving it to the specified folder.

Select the destination as the Possible-spam folder that was created in the earlier step or the Outlook 2003 Junk E-mail folder.

7.

Complete the rule by naming it appropriately.

This is a very specific example, but one that is quite useful if you want to give your users the ability to sift through potential spam for the non-spam messages. It also shows the potential to use Praetor as part of a client-server process in dealing with email, specifically in the creation of automated email agents or robots often referred to as 'bots'.

There are several reserved keywords that can be used within the X-header field which represent variables for attributes (Subject, number of attachments, etc.) of the underlying message itself. Click here to see the keyword list.


Changing port for Domino SMTP MTA prior to R5

Starting with Domino R4.6 and SMTP MTA 1.2, Lotus made a change that allowed the SMTP MTA to listen for incoming mail on a different port instead of the standard 25. This change is needed if Praetor is to be installed on the same machine as the Domino server since only one application can be receiving on port 25.

If you have this or a later version of the Domino server and SMTP MTA, you change the port to the suggested 28 used with Praetor by editing the NOTES.INI file and adding the following entry.

SMTPMTA_IPPORT=28

For more information, see the following articles:

  • IBM Domino support services website

  • Internet newsgroup comp.groupware.lotus-notes.admin

If your Domino or Notes server and SMTP MTA versions are even older than R4 and 1.2, then you will not be able to install Praetor to be co-resident on the same machine.


Configuring RBL

Configuring RBL and DNSBL usage

Note:

SMTP Protocol Level DNS Blacklist Filtering

Due to spammers' changing tactics, SMTP protocol level DNSBL filtering is susceptible to a denial-of-service (D-O-S) attack. Thus CMS now believes that DNS blacklist lookup should only be done at the message level, not the SMTP protocol level.

Read more on this issue here.

A DNS blackhole list (DNSBL) is an actively maintained DNS server with a database of IP addresses associated with Internet mail servers judged to be abusive on one or more spam-related criteria: known open relay, dial-up IPs used by spammers, etc. Praetor will use the IP session of the open connection request from a sending mail host to query the DNSBL. If the query response indicates the IP address is listed in the DNSBL database, then Praetor will refuse the connection attempt.

The original DNS blackhole list is known as the Real-time Blackhole List or RBL™. It was created and is actively maintained by the Mail Abuse Organization (visit their Mail Abuse Prevention System or MAPS™ website and learn more about this anti-spam DNS server). When this service was started, it was offered freely and any mailhost could send a DNS query to determine if an IP address was found in the MAPS RBL database. As of July 31st, 2001, RBL was no longer offered as a free service and access would be restricted to those willing to pay their subscription fee. Once the MAPS fee is paid, MAPS will register the IP address of your mailhost that will query the MAPS RBL server. Your mailhost will then be authenticated when MAPS server receives a DNS RBL query from Praetor.

Additional servers are available from MAPS:

  • RSS (Relay Spam Stopper)

  • DUL (Dial-up User List)

  • OPS (Open Proxy Stopper).

These three servers along with the original RBL are all conveniently checked in a single query when you pay the fee to subscribe to the RBL+ service.

Praetor queries a local DNS server

If you have a local DNS server with a subscription to the MAPS service, Praetor will issue the query locally. This takes advantage of the cache in your DNS and makes subsequent access much faster. If the information is not available locally, your DNS server will then forward the query to the MAPS server.

To set up Praetor, simply make sure that the IP address of your local DNS server appears in Control Panel Networking applet, under TCP/IP properties for the DNS servers. Then enter the MAPS domain in the Praetor administration program DNSBL field.

Note:

For those with high messaging volume, it would be even more efficient to enter into a zone transfer subscription with MAPS. Under this arrangement, a copy the entire MAPS databases would reside on your local DNS server that presumably would be far more responsive than a DNS query made to the MAPS servers that are also accessed by their other customers.

Praetor queries MAPS RBL™ or RBL+™ directly

It is possible to configure Praetor and have it directly query MAPS RBL or RBL+. This special configuration is needed because of MAPS subscription which registers the IP address of your machine that will perform queries against their servers. These comments and instructions do not apply to directly querying other (free) DNS Blackhole List servers.

CMS does not recommend you configure Praetor to make this direct MAPS query due to several known limitations:

  1. No other software (e.g. Windows Update, Internet Explorer, etc.) can make DNS queries.

  2. If Praetor is co-resident with your local Exchange, Domino, or other SMTP mail server, then Praetor must be set to filter and deliver all Internet-bound mail. Your mail server will not be able to deliver directly.

  3. Only a single DNSBL can be used.

If, after all these limitations and against CMS recommendation you still want to set Praetor to query the DNSBL server directly, then click here.

Other DNS Blackhole List servers

There are other DNS blackhole list servers available besides MAPS RBL and RBL+, many of which are available without charge. Examples include NJABL (combined.njabl.org) and Spamhaus (sbl-xbl.spamhaus.org).

If you want to use any of them, simply enter their server domain name in the DNSBL field.

Note:

From our experience, these free servers may be available one day only to disappear later without any notice. As free servers, the service they provide might collapse under the weight of their own popularity — without any revenue, the companies that operate the servers are unable to keep the servers responsive to the increasing volume of RBL queries. For example, two such free servers went off-line in 2000, ORBS and IMRSS, and Osirusoft shut itself in protest in 2003.

The very first RBL server was from the Mail Abuse Prevention System (MAPS) organization. It has survived by charging for services beginning in July 2001. MAPS has enhanced RBL to include other databases such as the Relay Spam Stopper (RSS), Dial-Up List (DUL), Non-confirming Mailing List (NML), and Open Proxy Stopper (OPS). You can read more about these services on the MAPS website.

For an exhaustive list of DNSBL servers, see this site - http://moensted.dk/spam/.

If you use any free DNSBL servers, many of them accept donations and could use your support in their efforts against spam.

For more information on other Internet anti-spam resources see Appendix D including a glossary of spam-related terms.


Evaluation expiration

Expiration of the 21-day evaluation

When your Praetor evaluation period expires it will no longer perform filtering. SMTP messages can still be received and sent without the benefit of Praetor monitoring the content of those messages and filtering.

At no time are any messages lost!

Leaving Praetor in a disabled state means that you can simply re-activate it after your purchase and receive the fully licensed serial number and its matching authentication code. All your rules will therefore remain intact and you won't need to re-install the software.

Click here to learn how to disable Praetor.


Issues with firewalls

During the course of supporting our customers, CMS has encountered a number of issues with certain firewalls. Here are the solutions to bypass these issues.

  • Cisco PIX

  • Checkpoint

Cisco PIX

Issue: | Internal machines on the protected side of the firewall are prevented by the PIX firewall from accessing other internal machines if their external IP addresses are used. Thus, if Praetor is set up to transmit accepted inbound messages to your mail server, it will be prevented from doing so if the external IP address is specified in Praetor's Local domains list.
Solution: | Correct the entry for your local mail server in Praetor's Local domains list so that the internal IP address is being used.

Checkpoint

Issue: | When Praetor connects to this firewall, it finds the ESMTP implementation is not compliant by declaring its own system capabilities during the initial greeting in a manner that is out of sequence and improper.
Solution: | Checkpoint has acknowledged this problem. Download an update from Checkpoint and install it per their instructions in Version NG FP2 Release Notes.


Issues with SMTP mail servers

During the course of supporting our customers, CMS has encountered a number of issues with certain older SMTP mail server. Here are the description of the problems and possible solutions.

8bitMIME incompatibility

Some SMTP mail servers do not support the optional 8bitMIME capability described in the Enhanced SMTP (RFC-2822) and various other specifications relating to Internet mail. This capability is advertised by the receiving mail server to allow the sending server to transmit the message using an 8-bit data stream.

Examples of mail servers without this capability include:

  • Microsoft Exchange v5.5 and earlier

  • Lotus Domino R6 and earlier

By default, the IIS SMTP Server used by Praetor has this capability turned ON and advertises this fact in the greeting to any sending mail server that uses the EHLO command when first making its connection. Due to this incompatibility, whenever Praetor approves a message that it received using the 8bitMIME data stream, IIS SMTP Server will be unable to transfer the message downstream to these older mail servers. The result is a non-delivery report being issued about the unsuccessful mail transfer.

Click here to see how to test for compatibility of your downstream mail servers.

The solution is to configure IIS SMTP Server turn OFF and not advertise its default 8bitMIME capability. This will prevent the message from being received using the 8bitMIME data stream. Here are two articles from the Microsoft knowledgebase describing how this is configured, depending on which Windows platform you have:

  • Windows XP, knowledgebase article 286673

  • Windows 2000/2003, knowledgebase article 262168


Issues with virus scanners

CMS has encountered two different types of virus scanners in use with Praetor.

  1. SMTP-based virus scanner

  2. PC-based virus scanner that checks files on the local hard drive

Here are some observations and the issues you might encounter.

SMTP-based virus scanner

This type of virus scanner operates in a manner like Praetor itself. Conceptually it performs its scanning function as a SMTP mail relay, first receiving the message via SMTP and then analyzing the message and its attachments for any viral infection. If the message is found to be free of infection, it will be transmitted to the receiving host.

In this environment, Praetor must be the very first SMTP mail host that receives the message from the Internet, before the virus scanner. There are two possible issues involving Praetor that we have seen to occur when trying to make it coexist with the virus scanner on the same machine.

  1. Port change for the virus scanner is required

Since Praetor is the first mail server, it must receive on the SMTP port 25. This will require the virus scanner to be configured to listen on a different port; we suggest using 28 which is the default port that Praetor will use to send inbound messages to the local mail server.

  2. Improper configuration of the virus scanner to deal with outbound messages may cause a message loop

If your virus scanner is configured to scan and send outbound messages, it needs to be able to distinguish between incoming and outgoing messages. You must configure it to perform DNS queries for sending outgoing mail.

An example of this type of product includes WebShield SMTP from McAfee.

PC-based virus scanner

If you have this type of virus scanner installed and running on the Praetor machine, you will need to exclude that antivirus product from scanning the following directories and all subdirectories underneath them:

  1. C:\Program Files\CMS Praetor G2

  2. C:\InetPub\mailroot

This is needed to prevent a collision between the antivirus product and Praetor/IIS SMTP Server. We have seen collisions on files in the Praetor OUT directory that are the temporary files created as messages are being received. The results are odd operational behavior with application event log entries indicating Praetor's inability to read and write to the message files.

Examples of this type of product include Symantec's Norton Antivirus, McAfee, and other single-user antivirus products from various companies such as Panda Software, Sophos, Norman, etc.

Virus scanner's email protection

Some antivirus products have a 'mail protection' which you need to turn off. The reason is because they are examining the messages for viral content, messages without any virus are getting delivered through the antivirus products' approval. Thus the antivirus product has circumvented Praetor, which has actually quarantined its copy of the very same messages.

Known examples of this is the Mail Protection facility found in Norton's Anti-Virus product.


Event log error codes

Event log errors

The Windows application event log may sometimes contain entries indicating the source was PraetorG2 or its components prLog, prMsg or prXPSink. Viewing the entry's details may show an error code whose meaning are listed below.

Warning:

CMS has observed errors that arise due to the use of antivirus software which make key Praetor system files or message files inaccessible. Please make certain that your antivirus software is not scanning the Praetor or the InetPub\mailroot directory trees. The latter is used by the Windows virtual SMTP server.

General Windows errors

The list provided below was obtained from Microsoft, most of which will not apply to Praetor. They are included only for completeness and left in the same order as the original. Those which are known to come from Praetor are marked by this color.

Code (hex) | Error Description
8000FFFF | Catastrophic failure.
8007000D | The Data is invalid.
80004001 | Not implemented.
8007000E | Ran out of memory.
80070057 | One or more arguments are invalid.
80004002 | No such interface supported.
80004003 | Invalid pointer.
80070006 | Invalid handle.
80004004 | Operation aborted.
80004005 | Unspecified error.
80070005 | General access denied error.
80000001 | Not implemented.
80000002 | Ran out of memory.
80000003 | One or more arguments are invalid.
80000004 | No such interface supported.
80000005 | Invalid pointer.
80000006 | Invalid handle.
80000007 | Operation aborted.
80000008 | Unspecified error.
80000009 | General access denied error.
8000000A | The data necessary to complete this operation was not yet available.
80004006 | Thread local storage failure.
80004007 | Get shared memory allocator failure.
80004008 | Get memory allocator failure.
84009 | Unable to initialize class cache.
8400A | Unable to initialize RPC services.
8000400B | Cannot set thread local storage channel control.
8000400C | Could not allocate thread local storage channel control.
8000400D | The user supplied memory allocator is unacceptable.
8000400E | The OLE service mutex already exists.
8000400F | The OLE service file mapping already exists.
80004010 | Unable to map view of file for OLE service.
80004011 | Failure attempting to launch OLE service.
80004012 | There was an attempt to call CoInitialize a 2nd time while single threaded.
80004013 | A Remote activation was necessary but was not allowed.
80004014 | A Remote activation was necessary but the server name provided was invalid.
80004015 | The class is configured to run as a security id different from the caller.
80004016 | Use of Ole1 services requiring DDE windows is disabled.
80004017 | A RunAs specification must be A RunAs specification must be <domain name>\<user name> or simply <user name>.
80004018 | The server process could not be started. The pathname may be incorrect.
80004019 | The server process could not be started as the configured identity. The pathname may be incorrect or unavailable.
8000401A | The server process could not be started because the configured identity is incorrect. Check the username and password.
8000401B | The client is not allowed to launch this server.
8000401C | The service providing this server could not be started.
8000401D | This computer was unable to communicate with the computer providing the server.
8000401E | The server did not respond after being launched.
8000401F | The registration information for this server is inconsistent or incomplete.
80004020 | The registration information for this interface is inconsistent or incomplete.
80004021 | The operation attempted is not supported.
80040000 | Invalid OLEVERB structure.
80040001 | Invalid advise flags.
80040002 | Can't enumerate any more, because the associated data is missing. Observed when antivirus software collides with Praetor
80040003 | This implementation doesn't take advises.
80040004 | There is no connection for this connection ID.
80040005 | Need to run the object to perform this operation.
80040006 | There is no cache to operate on.
80040007 | Uninitialized object.
80040008 | Linked object's source class has changed.
80040009 | Not able to get the moniker of the object.
8004000A | Not able to bind to the source.
8004000B | Object is static; operation not allowed.
8004000C | User cancelled out of save dialog.
8004000D | Invalid rectangle.
8004000E | compobj.dll is too old for the ole2.dll initialized.
8004000F | Invalid window handle.
80040010 | Object is not in any of the inplace active states.
80040011 | Not able to convert object.
80040012 | Not able to perform the operation because object is not given storage yet.
80040064 | Invalid FORMATETC structure.
80040065 | Invalid DVTARGETDEVICE structure.
80040066 | Invalid STDGMEDIUM structure.
80040067 | Invalid STATDATA structure.
80040068 | Invalid lindex.
80040069 | Invalid tymed.
8004006A | Invalid clipboard format.
8004006B | Invalid aspect0xs.
8004006C | tdSize parameter of the DVTARGETDEVICE structure is invalid.
8004006D | Object doesn't support IViewObject interface.
80040100 | Trying to revoke a drop target that has not been registered.
80040101 | This window has already been registered as a drop target.
80040102 | Invalid window handle.
80040110 | Class does not support aggregation 0xor class object is remote.
80040111 | ClassFactory cannot supply requested class.
80040140 | Error drawing view.
80040150 | Could not read key from registry.
80040151 | Could not write key to registry.
80040152 | Could not find the key in the registry.
80040153 | Invalid value for registry.
80040154 | Class not registered.
80040155 | Interface not registered.
80040170 | Cache not updated.
80040180 | No verbs for OLE object.
80040181 | Invalid verb for OLE object.
800401A0 | Undo is not available.
800401A1 | Space for tools is not available.
800401C0 | OLESTREAM Get method failed.
800401C1 | OLESTREAM Put method failed.
800401C2 | Contents of the OLESTREAM not in correct format.
800401C3 | There was an error in a Windows GDI call while converting the bitmap to a DIB.
800401C4 | Contents of the IStorage not in correct format.
800401C5 | Contents of IStorage is missing one of the standard streams.
800401C6 | There was an error in a Windows GDI call while converting the DIB to a bitmap.
800401D0 | OpenClipboard Failed.
800401D1 | EmptyClipboard Failed.
800401D2 | SetClipboard Failed.
800401D3 | Data on clipboard is invalid.
800401D4 | CloseClipboard Failed.
800401E0 | Moniker needs to be connected manually.
800401E1 | Operation exceeded deadline.
800401E2 | Moniker needs to be generic.
800401E3 | Operation unavailable.
800401E4 | Invalid syntax.
800401E5 | No object for moniker.
800401E6 | Bad extension for file.
800401E7 | Intermediate operation failed.
800401E8 | Moniker is not bindable.
800401E9 | Moniker is not bound.
800401EA | Moniker cannot open file.
800401EB | User input required for operation to succeed.
800401EC | Moniker class has no inverse.
800401ED | Moniker does not refer to storage.
800401EE | No common prefix.
800401EF | Moniker could not be enumerated.
800401F0 | CoInitialize has not been called.
800401F1 | CoInitialize has already been called.
800401F2 | Class of object cannot be determined.
800401F3 | Invalid class string.
800401F4 | Invalid interface string.
800401F5 | Application not found.
800401F6 | Application cannot be run more than once.
800401F7 | Some error in application program.
800401F8 | DLL for class not found.
800401F9 | Error in the DLL.
800401FA | Wrong OS or OS version for application.
800401FB | Object is not registered.
800401FC | Object is already registered.
800401FD | Object is not connected to server.
800401FE | Application was launched but it didn't register a class factory.
800401FF | Object has been released.
80080001 | Attempt to create a class object failed.
80080002 | OLE service could not bind object.
80080003 | RPC communication failed with OLE service.
80080004 | Bad path to object.
80080005 | Server execution failed.
80080006 | OLE service could not communicate with the object server.
80080007 | Moniker path could not be normalized.
80080008 | Object server is stopping when OLE service contacts it.
80080009 | An invalid root block pointer was specified.
80080010 | An allocation chain contained an invalid link pointer.
80080011 | The requested allocation size was too large.
80020001 | Unknown interface.
80020003 | Member not found.
80020004 | Parameter not found.
80020005 | Type mismatch.
80020006 | Unknown name.
80020007 | No named arguments.
80020008 | Bad variable type.
80020009 | Exception occurred.
8002000A | Out of present range.
8002000B | Invalid index.
8002000C | Unknown language.
8002000D | Memory is locked.
8002000E | Invalid number of parameters.
8002000F | Parameter not optional.
80020010 | Invalid callee.
80020011 | Does not support a collection.
80028016 | Buffer too small.
80028018 | Old format or invalid type library.
80028019 | Old format or invalid type library.
8002801C | Error accessing the OLE registry.
8002801D | Library not registered.
80028027 | Bound to unknown type.
80028028 | Qualified name disallowed.
80028029 | Invalid forward reference, or reference to uncompiled type.
8002802A | Type mismatch.
8002802B | Element not found.
8002802C | Ambiguous name.
8002802D | Name already exists in the library.
8002802E | Unknown LCID.
8002802F | Function not defined in specified DLL.
800288BD | Wrong module kind for the operation.
800288C5 | Size may not exceed 64K.
800288C6 | Duplicate ID in inheritance hierarchy
800288CF | Incorrect inheritance depth in standard OLE member.
80028CA0 | Type mismatch.
80028CA1 | Invalid number of arguments.
80028CA2 | I/O Error.
80028CA3 | Error creating unique tmp file.
80029C4A | Error loading type library/DLL.
80029C83 | Inconsistent property functions.
80029C84 | Circular dependency between types/modules.
80030001 | Unable to perform requested operation.
80030002 | %1 could not be found.
80030003 | The path %1 could not be found.
80030004 | There are insufficient resources to open another file.
80030005 | Access Denied.
80030006 | Attempted an operation on an invalid object.
80030008 | There is insufficient memory available to complete operation.
80030009 | Invalid pointer error.
80030012 | There are no more entries to return.
80030013 | Disk is write-protected.
80030019 | An error occurred during a seek operation.
8003001D | A disk error occurred during a write operation.
8003001E | A disk error occurred during a read operation.
80030020 | A share violation has occurred.
80030021 | A lock violation has occurred.
80030050 | %1 already exists.
80030057 | Invalid parameter error.
80030070 | There is insufficient disk space to complete operation.
800300F0 | Illegal write of non-simple property to simple property set.
800300FA | An API call exited abnormally.
800300FB | The file %1 is not a valid compound file.
800300FC | The name %1 is not valid.
800300FD | An unexpected error occurred.
800300FE | That function is not implemented.
800300FF | Invalid flag error.
80030100 | Attempted to use an object that is busy.
80030101 | The storage has been changed since the last commit.
80030102 | Attempted to use an object that has ceased to exist.
80030103 | Can't save.
80030104 | The compound file %1 was produced with an incompatible version of storage.
80030105 | The compound file %1 was produced with a newer version of storage.
80030106 | Share.exe or equivalent is required for operation.
80030107 | Illegal operation called on non-file based storage.
80030108 | Illegal operation called on object with extant marshallings.
80030109 | The docfile has been corrupted.
80030110 | OLE32.DLL has been loaded at the wrong address.
80030201 | The file download was aborted abnormally. The file is incomplete.
80030202 | The file download has been terminated.
80010001 | Call was rejected by callee.
80010002 | Call was canceled by the message filter.
80010003 | The caller is dispatching an intertask SendMessage call and cannot call out via PostMessage.
80010004 | The caller is dispatching an asynchronous call and cannot make an outgoing call on behalf of this call.
80010005 | It is illegal to call out while inside message filter.
80010006 | The connection terminated or is in a bogus state and cannot be used any more. Other connections are still valid.
80010007 | The callee 0xserver [not server application] is not available and disappeared; all connections are invalid. The call may have executed.
80010008 | The caller 0xclient disappeared while the callee 0xserver was processing a call.
80010009 | The data packet with the marshalled parameter data is incorrect.
8001000A | The call was not transmitted properly; the message queue was full and was not emptied after yielding.
8001000B | The client 0xcaller cannot marshal the parameter data - low memory, etc.
8001000C | The client 0xcaller cannot unmarshal the return data - low memory, etc.
8001000D | The server 0xcallee cannot marshal the return data - low memory, etc.
8001000E | The server 0xcallee cannot unmarshal the parameter data - low memory, etc.
8001000F | Received data is invalid; could be server or client data.
80010010 | A particular parameter is invalid and cannot be 0xunmarshalled.
80010011 | There is no second outgoing call on same channel in DDE conversation.
80010012 | The callee 0xserver [not server application] is not available and disappeared; all connections are invalid. The call did not execute.
80010100 | System call failed.
80010101 | Could not allocate some required resource 0xmemory, events, ...
80010102 | Attempted to make calls on more than one thread in single threaded mode.
80010103 | The requested interface is not registered on the server object.
80010104 | RPC could not call the server or could not return the results of calling the server.
80010105 | The server threw an exception.
80010106 | Cannot change thread mode after it is set.
80010107 | The method called does not exist on the server.
80010108 | The object invoked has disconnected from its clients.
80010109 | The object invoked chose not to process the call now. Try again later.
8001010A | The message filter indicated that the application is busy.
8001010B | The message filter rejected the call.
8001010C | A call control interfaces was called with invalid data.
8001010D | An outgoing call cannot be made since the application is dispatching an input-synchronous call.
8001010E | The application called an interface that was marshalled for a different thread.
8001010F | CoInitialize has not been called on the current thread.
80010110 | The version of OLE on the client and server machines does not match.
80010111 | OLE received a packet with an invalid header.
80010112 | OLE received a packet with an invalid extension.
80010113 | The requested object or interface does not exist.
80010114 | The requested object does not exist.
80010115 | OLE has sent a request and is waiting for a reply.
80010116 | OLE is waiting before retrying a request.
80010117 | Call context cannot be accessed after call completed.
80010118 | Impersonate on unsecured calls is not supported.
80010119 | Security must be initialized before any interfaces are marshalled or unmarshalled. It cannot be changed once initialized.
8001011A | No security packages are installed on this machine or the user is not logged on or there are no compatible security packages between the client and server.
8001011B | Access is denied.
8001011C | Remote calls are not allowed for this process.
8001011D | The marshalled interface data packet 0xOBJREF has an invalid or unknown format.
8001FFFF | An internal error occurred.
80090001 | Bad UID.
80090002 | Bad Hash.
80090003 | Bad Key.
80090004 | Bad Length.
80090005 | Bad Data.
80090006 | Invalid Signature.
80090007 | Bad Version of provider.
80090008 | Invalid algorithm specified.
80090009 | Invalid flags specified.
8009000A | Invalid type specified.
8009000B | Key not valid for use in specified state.
8009000C | Hash not valid for use in specified state.
8009000D | Key does not exist.
8009000E | Insufficient memory available for the operation.
8009000F | Object already exists.
80090010 | Access denied.
80090011 | Object was not found.
80090012 | Data already encrypted.
80090013 | Invalid provider specified.
80090014 | Invalid provider type specified.
80090015 | Provider's public key is invalid.
80090016 | Keyset does not exist.
80090017 | Provider type not defined.
80090018 | Provider type as registered is invalid.
80090019 | The keyset is not defined.
8009001A | Keyset as registered is invalid.
8009001B | Provider type does not match registered value.
8009001C | The digital signature file is corrupt.
8009001D | Provider DLL failed to initialize correctly.
8009001E | Provider DLL could not be found.
8009001F | The Keyset parameter is invalid.
80090020 | An internal error occurred.
80090021 | A base error occurred.
800B0001 | The specified trust provider is not known on this system.
800B0002 | The trust verification action specified is not supported by the specified trust provider.
800B0003 | The form specified for the subject is not one supported or known by the specified trust provider.
800B0004 | The subject is not trusted for the specified action.
800B0005 | Error due to problem in ASN.1 encoding process.
800B0006 | Error due to problem in ASN.1 decoding process.
800B0007 | Reading / writing Extensions where Attributes are appropriate, and visa versa.
800B0008 | Unspecified cryptographic failure.
800B0009 | The size of the data could not be determined.
800B000A | The size of the indefinite-sized data could not be determined.
800B000B | This object does not read and write self-sizing data.
800B0100 | No signature was present in the subject.
800B0101 | A required certificate is not within its validity period.
800B0102 | The validity periods of the certification chain do not nest correctly.
800B0103 | A certificate that can only be used as an end-entity is being used as a CA or vice versa.
800B0104 | A path length constraint in the certification chain has been violated.
800B0105 | An extension of unknown type that is labeled 'critical' is present in a certificate.
800B0106 | A certificate is being used for a purpose other than that for which it is permitted.
800B0107 | A parent of a given certificate in fact did not issue that child certificate.
800B0108 | A certificate is missing or has an empty value for an important field, such as a subject or issuer name.
800B0109 | A certification chain processed correctly, but terminated in a root certificate which isn't trusted by the trust provider.
800B010A | A chain of certs didn't chain as they should in a certain application of chaining.

Praetor errors

Code (hex) | Error Description
80049200 | Failure when writing message.
80049201 | Failure when reading message.
80049202 | Failure when resetting internal message object. ???
80049203 | Invalid parameter ??
8004a000 | General ??
8004a001 | File copy failure.
8004a002 | File rename failure.
8004a003 | File delete failure.
8004a004 | Failure on loading the specified text to append.
8004a005 | Failure during read of extra MIME segment.
8004a006 | Problem with accepting a message.
8004a007 | Problem with appending text to the end of a message.
8004a008 | Problem with inserting text to the beginning of a message.
8004a009 | Problem with redirecting a message to a different address than the recipient.
8004a00a | Problem when generating a general notification message.
8004a00b | Problem when generating a notification message to the sender.
8004a00c | Problem when generating a notification message to the administrator.
8004a00d | Problem when returning a message to the sender.
8004a00e | Problem when forwarding a copy of the message.
8004a00f | Problem when generating a notification message to the intended recipients.
8004a010 | Text list being used does not exist.
8004a011 | Invalid arguments used in a call to a method.
8004a012 | Problem with writing message to the Quarantine folder.
8004a013 | Invalid action result.
8004a014 | IP list being used does not exist.
8004a015 | Problem when saving a redirected message.
8004a016 | Problem with approving a message, perhaps due to file permission issues
8004a017 | Problem in appending to the subject
8004a018 | Problem in adding to the beginning of the subject
8004a100 | Problem encountered by the protocol sink when writing the message.
8004a101 | Protocol sink did not find any intended recipient address.
8004a102 | Protocol sink encountered a problem with message construction.


Indicators of MSDE Limits

When the MSDE workload governor is engaged occasionally because of a few times when there are more than 8 concurrent SQL accesses, Praetor's filtering may appear sluggish. Eventually things will return to normal as inbound message volume tapers off. When the workload governor is constantly being engaged, then Praetor filtering may appear to stop because no new entries are being logged into the SQL database.

You should obtain MSDE statistics of the concurrent access limit by using the Microsoft OSQL command line tool. Since Praetor is installed with the MSDEstats.SQL script file in its main folder, invoke the command:

OSQL /E -i MSDEstats.SQL

What appears will be something like the following:

1> dbcc concurrencyviolation(display)
2> go
Concurrency violations since 2004-08-04 09:47:24.060
1 2 3 4 5 6 7 8 9 10-100 >100
19643 5299 3839 1331 1275 1188 1520 2437 2387 25744 25744
Concurrency violations will be written to the SQL Server error log.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

The first row of numbers (in green) are column headings for the number of excess concurrent access beyond the limit of 8. The second row of numbers (in red) show how many times MSDE found that number of excess concurrent access attempts had happened since the date and time of last reset.

The above example was obtained on Aug 6th, only two days after last reset and shows frequencies that are extremely high, especially for the cases in the last two columns on the right for 10-100 and >100. These statistics are telling us that the message volume was so high that MSDE found too many concurrent access over the two-day period. Indeed, the workload governor was delaying Praetor from accessing its database for so long a time that it could not filter the message in the allotted 60-second (default) period as all threads were busy waiting for MSDE. As a result of this situation, the Windows Event Log for applications will have numerous entries from the source prXPSink. Opening any such entry will show the following details describing the unavailability of message submission threads.

Seeing an entire series of such Windows application log entries proves that MSDE is now a severe limiting factor and you need to use SQL Server, not its free desktop edition. To preserve your Praetor log and token databases you will need to migrate them to SQL Server.

If your MSDE is sufficient for your email volume, the frequency shown in red would be low, and they should decrease going from left-to-right, something like the following:

Concurrency violations since 2004-06-23 08:05:22.055
1 2 3 4 5 6 7 8 9 10-100 >100
196 52 38 13 7 11 5 1 1 2 0

These numbers show that there were some spikes in messaging volume, but MSDE would eventually return back to normal. Never did MSDE find so many concurrent accesses as to cause Praetor to wait for very long even as it delayed the fulfillment of the SQL database access.

Statistics reset

You can reset the MSDE statistics by using the file MSDEstats-reset.SQL located in the Praetor G2 folder. Invoke it as follows:

OSQL /E -i MSDEstats-reset.SQL


Pre-Filter Rules

What are the BASIC pre-configured rules?

The BASIC pre-configured rules are preset rules that mostly occur before Praetor's Bayesian statistical filtering. These are performed first in order to eliminate the statistical possibility that:

  • undesirable messages (e.g. suspicious attachments) may be deemed as good, and

  • desirable messages may be detected to have spam characteristics.

The following are the pre-filter rules performed by Praetor, and indicated by log entries that start with "SYS_" in the rule name reflecting its system-internal nature, e.g. "SYS_DNS Blacklisted message".

  1. Reject messages from sources listed on the DNSBL server(s)

  2. Reject messages that contain any attachment found on the banned attachment list

  3. Quarantine messages that contain any attachment found on the suspicious attachment list

  4. Accept messages from senders on the approved address list

  5. Accept messages from senders in any approved domain list

  6. Accept messages from senders on the approved listserver address list

  7. Bayesian filter tests for spam and non-spam based upon the cut-off values for bad and good mail

  8. Quarantine messages containing invisible HTML ink, where the color of the text is so close to the background that the text is not readable

  9. Quarantine messages containing tiny HTML text

  10. Quarantine messages containing obfuscated URLs, or links containing IP addresses instead of domain names or port numbers

  11. Accept messages with computed spamicity in the unsure range, between the two cut-off values.

As these rules are pre-configured, their order cannot be changed. If you want to deviate from this order you will need to select the ADVANCED message level filtering on the configure spam filter screen shown below.

Choosing ADVANCED will allow you to configure the rules in your chosen order which also include the three enabled rules involving Bayesian spamicity tests seen below.

Note:

The default rules supplied with Praetor in the ADVANCED filtering level as shown above duplicate what is in the BASIC pre-configured rules. You now have the ability to re-order them and enable other rules.

Back to FAQ overview


How to blacklist IP addresses

Starting with Praetor G2 which depends on the Microsoft Internet Information Services (IIS), blacklisting IP addresses is controlled by the IIS Administration console. Following steps below to add an IP address or range to the local blacklist.

1. | Use the IIS Administration console and right-click on the Default SMTP Virtual Server node in the left pane and select Properties.
2. | Select the Access tab.
3. | Press [image] to see the connection criteria that control the connections to this SMTP server. By leaving it as shown above, the listed computers will be on a blacklist.
4. | Press [image] and enter the single IP address, range of IP addresses, or a domain name. If you want to enter an IP address range, you need to supply the subnet address and the range. If you need help with this click here for a subnet calculator.


Bayesian training tips

Praetor provides the administrator with the facility to train its Bayesian filter to be more accurate by reducing false positives (non-spam messages that are quarantined) and false negatives (spam messages that are unfiltered because the Bayesian filter is unsure). Your goal is to attain an acceptable level of these classification errors.

A reasonable goal might be a false positive rate of one in 2,000 (0.05%) or lower. This number can be found in the special summary traffic report as the percentage of messages totaled for the approved event group. The sample snippet from this report shows one approved message which original was quarantined because of the rule called "NOT Praetor ZIP files".

Keep in mind that as the user population becomes larger, it will be statistically more difficult to get lower false positive numbers simply because of the wide-ranging message content for the entire population that causes many more conflicting tokens. For example, some people may want jokes-of-the-day messages, and others not, so training on these as spam and non-spam samples will dilute the statistics for the tokens in those messages.

The false negative rate is not as easy to see because it is among the messages whose spamicity are rated unsure, which the Bayesian filter permits to be delivered (default). Most of these messages will be spam and some will be non-spam. To a lesser extent, there will also be spam with low spamicity values. A reasonable goal for the false negative rate is to have the percentage of spamicity unsure to be less than 5% of all inbound messages received.

In discussing false positive/negative rates, realize that these represent counter-opposing forces. If you try to get extremely low false positives, this typically results in more false negatives, and vice versa. Be prepared to see this reflected in your own Praetor Bayesian filtering.

Here are some tips to train the Praetor Bayesian filter in an optimal manner.

Dos:

1. Be sensible in training

You do not need to train excessively with samples numbering in the tens or hundreds of thousands to get good performance with Praetor's Bayesian filter. CMS has found that starting from the default token database, and training selectively (as described below) over short periods of up to one week will get better results.

Going to the trouble to accumulate tens of thousands or more samples may even work against you in the following ways:

  • Good and bad counts on many more will tend to equalize and so won't become significant in the overall spamicity calculation.

  • More tokens require more memory to cache and take longer to initially populate the cache.

  • Having more tokens will also cause more floating point calculations, consuming more CPU resources and slowing down the filtering.

2. Train only on errors

The Bayesian filter is best trained with message samples on which it has made classification errors.

  • Good messages that are quarantined due to the spamicity exceeding the high threshold value, set to 0.60 by default.

  • Good messages that are rated as unsure because the spamicity is between the low and high threshold values, by default from 0.30 to 0.60.

  • Spam messages that are also rated as unsure.

For good messages that are quarantined, the administrator simply uses the Praetor administration program to immediately train on the message before releasing it for delivery.

For messages deemed to be unsure which have been accepted by Praetor and delivered to the intended recipients, the administrator must set the rule to archive a copy of such messages into the TrainUNSURE Waiting Review folder. Follow these steps to archive such accepted messages.

3. Train periodically only when needed

The administrator can use the Praetor Log Analyzer to determine if more training is needed. Just view the special summary traffic report to see if the number of false positives that have been approved is too high.

To a certain degree, the false negatives are also reflected by the number of accepted messages found to have unsure spamicity, but realize that the number shown also includes good messages as well as spam. Of course, it is more likely that your user population will complain if they are still receiving too much spam.

4. Add listserver addresses

Listservers sending newsletters, discount notices, etc tend to have spam-like characteristics so it is a good idea to simply avoid the Bayesian filter by adding their addresses into the Approved Listserver Address list. This can easily be done when reviewing the details of the message and selecting the Address Options tab and then checking the box for the desired list.

Keep in mind, however, that some listservers use a sending address where the portion to the left of the @-sign is auto-generated and containing a string of digits that may identify the newsletter issue number. In such cases, it will not be sufficient to add the entire address unmodified to the Approved Listserver Address list. Instead you may want to simply add an entry to the Approved Domains list.

Note:

CMS has found that people tend to use Praetor to filter out messages from listservers they don't want to continue receiving. Perhaps they are heeding to the warning not to unsubscribe from mailing lists. This warning should not apply to listservers that you voluntarily subscribed to in the past.

As the administrator, you should not comply with user requests to train on such messages as spam. Doing this may cause problems for other users who want to continue their subscription. Simply ask those who don't want to receive such messages from a particular listserver to unsubscribe.

5. Add entries to the whitelist for addresses and domains

If some users request to always accept messages originating from a particular address or domain, then add these to the Approved Senders or Approved Domains list.

Today's email-borne infections usually forge the sender address with something it finds in the local address book on the infected machine so there is a small risk that such an address may be on the whitelist. This risk can be eliminated by Praetor as long as you retain the rule order (default) that puts the rules for attachment tests before the rules for the whitelists.

Don'ts:

1. Don't train spam that is already classified with high spamicity

If your spam threshold is at 0.60 (default) and you see spam messages rated by the Bayesian filter with spamicity of 0.61 or higher, it is pointless to train on such messages just to get that spamicity to be computed even higher. Whether the spamicity will be computed at 0.61 or 1.00 in the future, it will still be caught simply because it exceeds your spam threshold value.

2. Don't train non-spam that is already classified with low spamicity

If your low non-spam threshold is at 0.30 (default) and you find good messages are being rated with a spamicity value less than this, it is pointless to train on such messages just to get the spamicity to be computed even lower. In the future similar non-spam messages, resulting in a spamicity of 0.00 or 0.29, will still be treated as good messages and accepted because their spamicity is below the low threshold value.

Saving unsure messages for training

In ADVANCED filtering mode you will need to configure the additional rule action to save the accepted message into the TrainUNSURE folder by performing these steps in the Praetor administration program.

1. | In the Inbound rules list, highlight the "Spamicity is unsure" rule and double-click to open its properties.
2. | View the tab for the Actions and select to "save message as training type in training folder" as shown below.
3. | In the rule description window, click on the training type and select to "Save message as Train UNSURE".
4. | In the rule description window, click on the training folder and select the default and only valid value to choose the "Ready for Training" folder.
5. | Your rule description should have this optional action to save the message as shown below. Click [image] to complete the rule modification. Don't forget to save your rule set by pressing on [image] on the toolbar and put it into effect.

In the BASIC filtering mode, saving the UNSURE messages is much simpler. Just check the box on the Classify tab of the Bayesian configuration page.

Once captured in the [image] node for [image] you need to review these and queue as good or bad samples and then perform the training. Click here to read more about this process.


What's new

What's new in Praetor

Version 2.1

This manual was updated in June 2005 and corresponds to v2.1 of Praetor which was released in April 2005.

Bugfixes

  • Resource leaks in the Praetor filtering components: prLog and COM+ applications causing memory usage to increase over time. At some point resources would be exhausted and Praetor would no longer be able to log message summary entries into the SQL database.

  • If a triggered rule involved an on-the-fly list with many entries, the logging would fail because the reason text was excessively long. The application and system event logs would show that PrLog.EXE abnormally terminated and restarted.

  • When viewing a quarantined message in the administration program, it was not possible to add the sender address or domain to the appropriate list and caused the program to crash.

  • If a message addressed to multiple local recipients was quarantined, only the first recipient would be able to see it in PLGV. Upon releasing that message for all the recipients, only the person releasing would receive the message.

  • PLGV error when the IIS web server uses a regional date format different from MM-DD-YYYY.

Enhancements

  • Bayesian token database is now cached in memory to speed up filtering almost doubling the message through-put. This also extends the usability of the free Microsoft SQL Desktop Engine (MSDE), allowing it to accommodate more users than previously.

  • Administration program now has additional searching capabilities based on message properties: direction, triggered rule name, From, To, and Subject.

  • Custom condition now allows testing for more fields:

    • RFC-2821 protocol: MAIL FROM, RCPT TO

    • Message header: From, Sender, To, and Cc addresses, subject and message body

Other

  • CMS now recommends the use of message rule level DNS blacklist lookup and filtering instead of the protocol level due to spammers' changing tactics that can simulate a denial-of-service attack.

  • Several tools are provided to help manage the Praetor SQL log database.

  • FAQ on how to add an IP address, range, or domain name to the local IP blacklist.

  • FAQ on Bayesian training tips.

Version 2.0

This manual corresponds to Praetor v2.0 which we call Praetor G2 or just G2, the second generation of our email filtering product.

  • Change of SMTP server to the native Windows server resulting in greater performance.

  • New techniques were added to combat the growing problem with unsolicited commercial email known as spam.

    • Bayesian statistical filtering of the message content

    • Message heuristics based on tests performed on the message header and body

    • Weighted words to test the message body

  • Self-service features so that local users can release their own quarantined messages.

  • Ability to create your own user list for use with a custom condition that allows you to choose what message header to test.

Upgrading from a previous Praetor version

Those upgrading from Praetor G2 v2.0 to v2.x can read about the upgrade process on this page.

If you are upgrading from the older Praetor v1.5 to Praetor G2 you can read about the differences between these versions by clicking here. With the Bayesian statistical processing, Praetor G2 performs numerous computations for each message so the PC requirements are higher. Click here to see our equipment recommendations.


Spam Recycling Center

On May 11, 1999, ChooseYourMail.com in conjunction with the Committee Against Unsolicited Commercial Email [CAUCE], the Forum for Responsible and Ethical Email [FREE] and SAFEeps announced a new consumer assistance web site called the Spam Recycling Center [SRC]. This coalition of private sector businesses and public interest groups share the common belief that Unsolicited Commercial Email [UCE] is invading the privacy of email users and is damaging the growth of e-commerce.

The damage caused by UCE, commonly known as “spam,” manifests itself in a variety of ways. To the average Internet user, the most visible damage is paying access fees to open an email box only to find it clogged with unwanted messages. Consumers are tired of footing the bill for get-rich-quick offers, pornographic solicitations and potential computer viruses that are delivered via unsolicited email message. But with that fear comes distrust. And consumers who distrust a medium are not going to participate in its economic growth.

ChooseYourMail.com believes that it is the obligation of on-line marketing industry and Internet companies on the whole to promote consumer friendly, pro-growth practices that encourage consumer trust, not fear. That is why ChooseYourMail and its coalition partners developed the Spam Recycling Center.

The SRC’s premise is a simple one: to provide Netizens with a place to learn about, and help combat, the problem of UCE while demonstrating an ethical, responsible method of marketing via email. Part of that process was giving Netizens a place to forward their spam messages so that they could be used to develop new tools and new laws to curtail the proliferation of spamming.

Since the first days of operation, the SRC has been receiving thousands of spams a day from Netizens around the world. Those spams have been compiled into a database of over 150,000 messages. For more information go to the ChooseYourMail.com website.


Praetor differences between versions

Praetor G2 is the second generation of the anti-spam, anti-virus email filtering product that CMS originally introduced in 1999. For the most part, many of the features you have grown accustomed to in Praetor are still found in G2, though the administration interface to those facilities has been displaced. The most significant difference is that G2 is based on Windows 2000 or XP, and employs the SMTP server component that is bundled with the operating system. In fact G2 was re-written so that it becomes an extension of the SMTP server.

Other differences are summarized as follows.

Feature / Criterion

Praetor v1.5

Praetor G2

SMTP server

Included third-party SMTP server.

Microsoft-supplied Windows 2000/XP component for the SMTP virtual server.

Technology connecting SMTP server to rule-based filtering

Separate and independent process.

OS-registered protocol and transport event sinks, making G2 an extension of the SMTP virtual server.

Required Windows OS platform

NT, 2000, XP in either the workstation/professional or server editions.

2000, XP Professional editions 2000, 2003 server editions. Windows NT is no longer supported.

Administrator user interface

Control Panel applet.

Microsoft Management Console (MMC) snap-in.

Available anti-spam countermeasures

DNS blacklist,
Local white and black lists,
Rules.

DNS blacklist,
Local white and black lists,
Rules,
Weighted words,
Heuristic scoring of message body and header,
Bayesian statistical sampling.

DNS blacklist access

Multiple queries performed in sequence.

Performed more efficiently in parallel awaiting for first response indicating the IP address is on the blacklist.

Treatment of email from DNS blacklisted mail server

Reject at the SMTP protocol level without ever receiving it.

Reject at the SMTP protocol level or allow the message to be received and defer decision to message level rule.

This means such messages can be quarantined and released if sent by a trading partner whose mail server is blacklisted.

Solution to the reverse NDR attack

Implemented at the message level, requiring the message to be completely received first.

Adds implementation at the SMTP protocol level so that the complete message need not be received before shutting down the connection.

Access to quarantined messages

Administrator only via console or remote Log Viewer application.

Adds web-browser access for both administrator and users. While the administrator can view the entire quarantine area, users can only view their personal quarantined mail.

Ability to create new string lists

None, but you can request CMS to create one.

Yes, the administrator can which will be used with a new custom condition that allows selection of the list for searching various message header fields.

Log entries

Placed into an ASCII delimited file.

Placed into a SQL database.

Log Analyzer

Requires log entries to be imported into a Microsoft Access database.

Natively accesses the SQL database directly.

Click here to see the upgrade process from Praetor v1.5 to G2.

Transferring rules and lists:

Due to the effectiveness of the Bayesian filtering technique and heuristic analysis, many of your old rules will become completely unnecessary. Thus we do not suggest that you transfer any spam-related rules that you created in v1.5, relying instead on using the new G2 filtering techniques.

There are, however, certain exceptions that you will want to transfer such as custom rules and lists you created that are not involved with filtering spam such as those dealing with:

  • Confidential information

  • Competition

  • Approved list of sender addresses, domains, and listservers

  • Lists for banned or suspicious attachments

  • Lists for suspicious senders and domains (formerly v1.5 banned senders and domains)

  • Lists for disallowed profanity

Any custom rules will need to be re-created in G2. As for lists, those internal lists can be bulk exported from Praetor v1.5 by using the MODLIST command line tool when invoked as follows:

MODLIST /EXPLISTS: MyPrLists.TXT

Once exported you can then use the import feature in Praetor G2 list management.

This bulk export from Praetor v1.5 only works for those predefined internal lists. If the rule you created employed on-the-fly lists via a "with specific words" condition, then you will need to export these entries directly from the list. The MODLIST tool will not export these entries. The import into G2 remains the same.


Changing the SMTP port number used by the Domino SMTP MTA

Note:

If you are using Domino version prior to R5, please read this FAQ to see if your SMTP MTA can be set to listen to a different port number.

When Praetor is installed on the same machine as the Domino server, you will need to allow it to be the main reception process of incoming messages. This will require you to set the SMTP component of Domino to relinquish the inbound SMTP port 25 to Praetor. Thus you will need to set Domino to receive on a different port and we recommend that you use port 28.

To change this setting in Domino, use the Administrator program and select the Configuration tab. If the Server object in the left pane is collapsed, expand it and select on the All Server Documents. The screen will appear as follows.

In the right pane, select the Domino server where Praetor will be installed and double-click. When the screen changes to show the properties for that server, select the tabs: Ports, Internet Ports, Mail. The screen will then appear as follows.

The setting that you need to change is the located on the line for the TCP/IP port number, under the column heading of Mail (SMTP Inbound). Change the value from the original 25 to the recommended 28. Leave the Mail (SMTP Outbound) value unchanged at 25.

Press <ESC> to save and close this properties page.

For Domino SMTP server to use this change, it will need to be stopped and restarted. Click here to see how to accomplish this. When this is done, you will also need to stop and restart the SMTP virtual server using IIS Manager since as installed it began and could not obtain access to port 25 that the Domino SMTP server just relinquished.

Note:

Praetor is ready to begin filtering inbound mail items from the Internet, forward them on port 28 to the Domino server. If you also want Praetor able to filter for outbound messages, it is necessary to re-route all outgoing mail from the Domino server back to Praetor. This is accomplished using the Lotus Domino Administrator program and changing the designated smarthost. Click here to read more on how to change this setting from its default state.

Next


Domino re-route of outbound messages through Praetor

When Praetor is installed and the corresponding change to the Domino SMTP server's receive port, your installation will be set up to filter inbound messages to your site from the Internet. In order for outbound messages to the Internet to be filtered by Praetor's outbound rules before being sent, another change to the Domino server's smarthost setting needs to be made. Otherwise, it will simply continue sending to the Internet directly, bypassing Praetor.

To change this setting in Domino, use the Administrator program and select the Configuration tab. If the Server object in the left pane is collapsed, expand it and select on the Configuration. The screen will appear as follows.

The above is a sample installation; you may have other server entries in the right pane. Choose the appropriate entry that you want to update with this change. In our case, double-click on the right pane entry for All Servers object, then selecting the tabs: Router/SMTP and Basics. The screen will appear as shown below when you choose to edit the entries on the page.

The setting that needs to be changed to route to Praetor is the highlighted field shown above accompanying the text Relay host for messages leaving the local internet domain. Enter the IP address of this machine with Praetor.

Note:

The IP address to be used must be the local address visible to the Domino servers within the protected side of your network.

To have this change take effect, you must stop and re-start the Domino SMTP Server task. Click here to see how this is done.


Stopping and restarting Domino SMTP server

Before any SMTP port or smarthost changes made to the settings for Domino SMTP server can take effect, you will need to stop and restart it. This page discusses ways to accomplish this.

Using the Domino Administrator

If you have the Domino Administrator runxning, select the tabs Server and Status to display a list of all operational tasks on the appropriate server.

To open the console window, press the Console button. In the Command field near the bottom, shut down the Domino SMTP server by issuing the command tell smtp quit. Status messages indicating the shutdown process is taking place will appear onscreen as shown below.

Note in the above screenshot that the original TCP port the SMTP server was listening was set to the default 25.

When the shutdown process is complete, you may restart the SMTP server by issuing the command load smtp.

If you have changed the SMTP port number to 28 so that the SMTP server will operate on the same machine as Praetor, issuing the show tasks command will verify that the change is in effect.

Commands entered via the Domino server console

If you have the character-based server console available, entering the Show tasks command at the prompt will display the state of the SMTP server. It is likely to be running and listening on port 25 as shown below, which is why you need to change the port to 28 before you install Praetor.

The first step is to issue the command tell smtp quit to shut down the SMTP server. The result will appear on the console as follows.

To restart the SMTP server, issue the command load smtp and confirm it by issuing show tasks. The screen will then show the SMTP server is listening for incoming messages. If the port was changed to 28 as recommended, it will show that as well.

The Domino SMTP server has now been restarted and is ready to accept inbound messages from Praetor after filtering them.


Global transmitter port

Praetor is dependent upon the Microsoft IIS Virtual SMTP Server which unfortunately uses a single global setting for what port to transmit messages.

Thus if it is set to any non-standard port when Praetor coexists on the same machine as your mail server that will receive filtered messages on port 28, then any Internet-bound messages will also be sent using this same port. Since Internet mail servers are expecting to get mail transmissions on port 28, no outbound messages can be transmitted by the IIS SMTP Server.

Return to overview


IMS re-route of outbound messages through Praetor

To set up IMS such that Praetor filters all Internet-bound messages using the outbound rules, you need to modify IMS settings on the Connections tab page and cause it to route the outbound messages to Praetor. Use the Exchange Admin program and select to administer the Internet Mail Service connector. Once you are presented with the properties for IMS, choose the Connections tab and the following will be displayed.

Exchange Admin IMS Connect page

Within the Message Delivery group box, do not select the Use domain name system (DNS) button as this will cause IMS to bypass Praetor and send out the messages directly to the receiving host. Instead, choose to Forward all messages to host and enter the IP address of the machine running Praetor. If Praetor is on the same machine as IMS, enter the local IP address for itself in your private local subnetwork, not the exposed IP address on the Internet.

Note:

Do not use the generic self-routing IP address of 127.0.0.1. Using this as your IP address entry will cause Praetor to inaccurately interpret the direction of the message flow. This 127.0.0.1 may also cause confusion with message relay attempts that Praetor will block.

It is imperative that the IP address you enter here is the same as that found in the Local Domains list. If these IP addresses do not match, Praetor will mistake all outbound email as incoming messages.

With this change in setting, IMS will forward all outbound messages to Praetor.


Install Praetor Databases

Warning:

If you have antivirus software running on the Praetor machine, it is imperative that you stop it from operating while you are trying to install Praetor. CMS has found that some antivirus products will prevent successful installation.

Also you must configure it so that it will not scan the Praetor and IIS folders. The paths for these are typically

  • C:\Program Files\CMS Praetor G2,

  • C:\G2-Archive and C:\G2-Quar (for maintenance tasks), and

  • C:\InetPub\mailroot

Antivirus software will cause unpredictable behavior and interfere with Praetor normal operation. You will see errors logged into the Windows Event application log. For other caveats involving antivirus products, see this FAQ.

When the Praetor installer begins the installation process for the SQL databases, you will already have the Microsoft SQL server in the form of the free Microsoft SQL Desktop Engine (MSDE) or the full SQL Server 2000 installed on the Praetor machine. Had it detected no available SQL server, the installer will automatically cause MSDE to be installed first since this is redistributed with Praetor.

If your Microsoft SQL server is on a machine of its own, then install the MSDE initially so that the Praetor SQL databases can be temporarily installed, and then you can export it to your SQL server later.

The installer for the Praetor databases will install two SQL databases:

  1. PraetorClassify, the default token database

  2. PraetorLog, an empty database for log entries

It will also add the appropriate identities for database access according to the Windows OS platform for this G2 machine.

When you run the SETUP program you will be presented with the installer opening screen.

Press [image] to proceed to the screen where you may specify where to locate the Praetor databases.

Press the [image] button if you want to select a different location than the default Praetor directory on local drive C:. When you are done with your selections, press [image] to display the screen allowing you to choose the SQL database server and authentication. The default is to use the SQL Server on the local Praetor machine, either the free Microsoft SQL Desktop Engine (MSDE) or SQL Server 2000, and uses the standard Windows authentication method.

When you are done with your selections, press [image] to get to the final screen. Pressing [image] will start installing the Praetor databases.

Upon successful completion, you will see the following.

At this point the two Praetor databases, PraetorLog and PraetorClassify, have been installed but the Bayesian word table in PraetorClassify is empty. Press [image] to proceed populating this word table with the default entries. The screen will indicate that it is installing the Bayesian update.

When this database has been updated with the default Bayesian word list, then the Praetor installer will automatically proceed to install the remaining components.

Next to install Praetor PLGV

Migrating Praetor SQL databases from MSDE to SQL Server

If you have a separate SQL Server or were using MSDE but you determined that its workload governor is a limiting problem for Praetor's smooth operation and want to replace it with SQL Server on the same Praetor machine, then you will need to move the Praetor SQL databases to that SQL Server. You can do this by perform these steps after SQL Server has been installed.

1.

Disable Praetor via the administration snap-in to stop it from operating.

2.

Keep in mind that this will not stop the flow of email but will simply disable filtering. If you want to also stop email flow, then you should simply disable the IIS SMTP Server instead of disabling Praetor.

3.

Detach the Praetor databases from your local MSDE or SQL Server by using the OSQL tool. From the command line invoke as follows:

C> OSQL -E
1> EXEC sp_detach_db @dbname = N'PraetorClassify'
2> EXEC sp_detach_db @dbname = N'PraetorLog'
3> GO
1> QUIT

4.

If your SQL Server is on another machine, move the following four files found in the main Praetor G2 folder (typically in C:\Program Files\CMS Praetor G2) to that SQL Server machine, locating it in a new Praetor folder that you create.

  1. PraetorClassify_Data.MDF

  2. PraetorClassify_Log.LDF

  3. PraetorLog_Data.MDF

  4. PraetorLog_Log.LDF

If your SQL Server is on the same machine as Praetor, skip this step.

5.

Using the Microsoft SQL Enterprise Manager tool, attach the databases as shown below.

The window to choose the database will appear.

Press [image] to browse through the folders and locate and choose the file PraetorClassify_Data.MDF. Normally this is in the G2 folder on the Praetor machine as shown below.

6.

Repeat the previous step but choose the PraetorLog_Data.MDF.

Next you will need to re-configure Praetor and PLGV to specify the SQL Server with these databases. This is discussed below.

Configuring Praetor and PLGV to use the new SQL Server

Moving the database to a new server other than MSDE means you need to tell Praetor and PLGV how to access that SQL Server.

For Praetor you use the administration snap-in in two ways.

  1. For the token database used by Bayesian filtering, you specify this SQL Server on the options tab page, where you can select or enter the new SQL Server name.

  2. For the log database, a similar setting can be found on the log configuration page.

For the Personal Log Viewer you will use the PLGVAdmin tool.

Only after the new SQL Server has been specified can Praetor and PLGV use the databases.

Next to install Praetor PLGV


Install Praetor Filter

Warning:

If you have antivirus software running on the Praetor machine, it is imperative that you stop it from operating while you are trying to install Praetor. CMS has found that some antivirus products will prevent successful installation.

Also you must configure it so that it will not scan the Praetor and IIS folders. The paths for these are typically

  • C:\Program Files\CMS Praetor G2,

  • C:\G2-Archive and C:\G2-Quar (for maintenance tasks), and

  • C:\InetPub\mailroot

Antivirus software will cause unpredictable behavior and interfere with Praetor normal operation. You will see errors logged into the Windows Event application log. For other caveats involving antivirus products, see this FAQ.

After all the Praetor pre-requisite components have been installed (database, Bayesian word list, PLGV), the actual filtering component will be installed. The main installer will launch the InstallShield Wizard and you will momentarily see the following screen.

Initial setup screen

Once the preliminary expansion of Praetor's files is completed, you will see the following welcome screen.

Main Praetor G2 install welcome screen

Press the [image] button to proceed to review the End User License Agreement.

End User License Agreement (evaluation version shown)

After reviewing the license agreement, select the Accept radio button and press [image] to continue. This will display the data entry screen prompting for the email address of your administrator. Enter a valid SMTP/Internet email address.

Administrator's email address

You may also change the default location where Praetor's files will be stored. Press [image] to select a new location or drive. By default, the installation will place the Praetor files in C:\Program Files\CMS Praetor G2.

Once the email address has been entered and you changed the destination location (if desired), pressing [image] will display the following screen allowing you to review and go back to a previous screen.

Final review screen

Press [image] to proceed with installing Praetor files and display a progress bar.

Installing Praetor components

The screen will continue to be updated, and as you near completion, you will see a display indicating the registration of Praetor's components.

Registering Praetor components

After registration has completed, the installer will attempt to check and update any redistributed components from Microsoft, e.g. Microsoft Database Access Component, Visual Basic Run-time, etc.. As this happens, you may see Windows Installer appear and disappear in the task bar when the following screen with the 100% status bar displayed.

After outdated Microsoft components have been updated, the installation process will be completed when you will see the following.

Installation complete

Press [image] to close this final screen.

At this point, Praetor has been completely installed as a 21-day evaluation. It is not operational and you will need to use the supplied administration program (a snap-in for Microsoft Management Console) to configure and start Praetor filtering.


Missing requisites

Sample screen of missing requisites

Return to overview


Using port 28 with Exchange IMS

If your Exchange 5.5 server with the Internet Mail Service (IMS) is installed on the same Windows 2000 machine as Praetor, then you will need to configure IMS to use port 28 when receiving messages. This configuration is made by changing an entry in the ASCII text file called services located in the subdirectory C:\winnt\system32\drivers\etc. When IMS is the receiver of Internet messages, the line is:

smtp 25/tcp mail

The value is therefore changed from 25 to 28.

Of course, IMS will need to be stopped and re-started to make this change take effect.


Administrator email address

Praetor will send messages to the email address declared as the administrator, typically in rules that include the optional action to notify the administrator. This address was originally specified during the installation process for the Praetor filter.

To view or change the email address, right-mouse click on main Praetor node in the left pane and select Properties.

Select the Administrator tab and the following display will appear and you may correct the email address if needed.


Bayesian Options

The Options tab page provides control for several elements used for the Bayesian filtering.

Spam header name

This is the name of the message header that is inserted with classification determination and corresponding spam probability index. By default the header is called X-Spamicity.

Spamicity cut-off values

The Bayesian determination of whether the message being analyzed is spam or ham is based on comparing the computed spam probability index to the cut-off values in the fields shown above.

In Praetor, the following spam probability value ranges are set as the defaults used in classifying the messages using the Good Mail cut-off value of 0.10 and Bad Mail cut-off value of 0.95.

Probability value | Classification | Suggested action
less than 0.30 | Ham or good email | Accept
0.30 ~ 0.60 | Unsure | Accept or Quarantine
greater than 0.60 | Bad email or spam | Quarantine or Reject

At these values, Praetor will be very accurate in its classification of spam and ham such that those classified as ham will definitely be ham, and those classified as spam will also accurately be spam. The potential problem with the wide range for the unsure class will be in ham getting mixed in. Naturally there will also be a lot of spam classified as unsure. Depending on your sensitivity to this situation, it is likely you will want to adjust these cut-off values to narrow the range of such uncertain messages.

SQL Server

This group box allows you to choose on which SQL server the PraetorClassify database resides, which contain the message tokens used for Bayesian classification. If necessary you can also specify the authentication method used to connect to that database server.

Note:

Since this token database has been separated from the normal Praetor log database, it is possible for multiple Praetor machines to share the same database. In this way, the computed spamicity value will be the same regardless which Praetor machine handles the message.

By default, the SQL database resides on the same machine as Praetor G2, implemented using the Microsoft SQL Desktop Engine (MSDE). You can, however, choose a different SQL Server using the drop-down list which will automatically get populated from all the available servers found in your network.

Once the SQL Server has been selected or a name entered, you may choose to use either Windows or SQL Server authentication method. If Windows authentication is selected, then Praetor will use the login originally established when it was installed. If you select SQL Server authentication, you will need to provide the login account and its password.

If your SQL Server is on the Praetor machine, chances are that you installed SQL Server while MSDE was still present. During such an installation you would have been prompted for an instance name and the entry that is needed by Praetor will be in the form MACHINE_NAME\INSTANCE_NAME.


Bayesian Options advanced

Advanced Options

These parameters control the statistical computations used by Praetor.

Minimum deviation

For each token, there is a corresponding frequency found in good and bad. When expressed as a percentage, the difference must exceed this value in order to be counted towards to overall computation of the message spam probability index or spamicity. When the difference is low, this means the token was seen almost as many times in good messages as it was seen in spam so it can be ignored.

In Paul Graham's original proposal, he only used the top 15 or 20 tokens to compute the spamicity value. The approach used by Praetor is different in that we use a minimum difference to weed out the unimportant tokens.

The default value is set to 0.1.

X coefficient

This parameter is the default value to be assigned when a token is encountered for the very first time. Essentially it represents a "first guess" as to its contribution to the overall spamicity score.

This value should be close to 0.5 and the default is 0.415.

S coefficient

If a token is encountered for the very first time, we only have the X coefficient to use, but what if we have see the token before only a few times? Due to statistical variation, using the ratio of two small numbers will be rather unreliable so a compromise is needed between that ratio and the first guess value X.

The S coefficient is used to serve as a weighting factor such that the larger it is, the greater the importance given to X when the token counts are low. Setting S too low is not a good thing because of the situation where the token is seen before for spam but not for ham, or vice versa.

Choosing this value is largely a matter of trial-and-error but studies have shown that it should be in the neighborhood from 0.01 to 0.1. In one test the spamicity computed on a spam sample where ten out of 78 tokens contributed to the calculation, changed the computed result from 0.999 to 0.505 when S went from 0.001 to 0.00000001!

The default is set to 0.01

Return


Bayesian Training Reset

While CMS does not suggest it, if you wanted to use only those tokens that are trained by your samples, it is possible to do so. This does mean that you will clear the default token database provided by CMS, and that you will have to capture your own samples.

To reset the token database and only populate it with your message samples, you will first need to completely clear the PraetorWordList table in the PraetorClassify SQL database. Call CMS Support for instructions on how to blank this table.

In the meantime, before the default token database is cleared, you will need to capture message samples for use in training. In this situation preliminary classification relies entirely on the default rules to identify spam from good messages. Once captured, you then need to verify that messages are classified correctly as spam or non-spam, and then you need to train the Bayesian filter using these samples. Once trained, you can enable Bayesian filtering.

This section discusses:

  • Capturing message samples, and

  • Performing the training

Capturing message samples

To facilitate the accumulation of spam and ham messages for initial bulk training, Praetor provides several novel training options for capturing samples as seen below on the Train tab page of the configuration window.

The only administrator control on this training page is within the Options group box. The other remaining group boxes show information about how many messages are in the various states. Here are the options that you may set:

  • Save GOOD and BAD messages for manual review

Using the default rule-based filters to make the initial classification, Praetor will save a copy of those messages that were quarantined as spam or accepted as ham. This will allow you to review each type for any incorrect classification, removing them as needed. Such messages will be placed on the [image] list of the [image] and [image] nodes.

  • Automatically save for training DNSBL messages as BAD

This selection automatically queues for training as BAD (spam) any message that originates from a known spam mail server whose IP address is on the DNS blacklist.

While it is possible that GOOD email might be incorrectly classified if your trading partner has a blacklisted mailserver, this should happen infrequently if at all. If you detect this in the auto-queued BAD list, you can manually mark the message as Queued for GOOD. Be sure to add their IP address into the DNSBL bypass IP list.

  • Automatically save for training any outbound message as GOOD

This selection will automatically mark messages from local users in your domain that go out to the Internet as ham.

Warning:

The possibility of BAD outbound messages does exist and so it could bias the GOOD frequency table. This could happen if you have a machine in your network that is infected with a mass-mailing worm that spews outbound email to all the people in the local contact list. Another possibility is that you perform broadcasts to customers that is spam-like.

In either of these cases, don't enable this option. Doing so and training upon those messages will likely make your token database 'dirty' and decrease its effectiveness.

  • Stop saving messages when threshold is reached

This selection will cause Praetor to capture a specified number of sample inbound and outbound messages using the existing methods (default Bayesian tables and rules) to classify as GOOD or BAD for review.

CMS suggests that you set a value of at least 1000 messages. Depending on your user population this may give you sufficient diversity of messages indicative of the business correspondence for your site. While a larger sample size tends to show greater diversity and the Bayesian filtering will become more accurate in its discrimination between spam versus ham, keep in mind that it will take you longer to verify that the classification is correct before you perform the training. Also, this larger sample will take longer to process. With a smaller sample size, you can at least get the initial training done so that you can quickly start to see the benefits of the Bayesian filtering.

These Praetor options are convenient ways to accumulate trainable messages. The use of the DNSBL and outgoing samples are especially convenient since these captured messages are not likely to need your review.

For initial bulk training purposes CMS recommends that you check all the above four options, perhaps adjusting the quantity for how many messages to save for training. Click here for a discussion of periodic incremental training.

Note:

If you have placed your Praetor G2 behind an existing Praetor v1.5, then G2 may not be getting any messages to quarantine since v1.5 may have already done so. In this situation it is possible to copy those message samples from the v1.5 QUAR folder and import them into the G2 [image] and [image]. This is performed by using the command line tool to populate this training folder called POPTRAIN.

Other group boxes on this page are:

  • Waiting for Review

show messages that were captured by rule filters that require review to insure they were correctly classified as GOOD or BAD

  • Ready to Train

are those messages you have already reviewed and those automatically captured by DNSBL (BAD) or by outgoing from your own local users (GOOD)

  • Already Trained.

are those messages that have been analyzed and the frequency database has been updated with what tokens were found

Performing the training

Once messages have been captured, the initial training process consists of two steps: review and train.

1.

Review captured messages

Periodically check on the captured BAD messages by selecting the [image] node under [image] on the left pane. Survey the messages you see in the right pane and identify any message that was incorrectly classified as spam by using the sender address or subject as clues.

Right-mouse click on a selected message and you will be presented with the following possible actions.

  1. Train as GOOD

  2. Train as BAD

  3. Queue as GOOD

  4. Queue as BAD

  5. Delete the message from consideration

Choosing either action to train will cause immediate analysis and adjust the appropriate frequency table with the tokens seen. If this action is selected, the message entry will move to the [image] node.

Please note that training on-the-fly in this manner may take some time and will impact Praetor mail reception and filtering. For initial bulk training CMS does not recommend you to perform training; instead you should choose the action to Queue the message or simply Delete it from the list.

When you choose to Queue (recommended for initial bulk training), this will simply mark that message for later training using the training wizard. This choice will also move the message entry to the appropriate [image] node.

Note:

It is possible to highlight multiple entries in the message list and perform the chosen action on all the selected messages.

In case the message summary that is visible from the list is insufficient and you are unable to determine whether it is really GOOD or BAD based on the sender address or subject matter, then you can open the selected message by double-clicking on the entry. This will present you with full message details showing the message header and its contents. The same actions are now available as buttons in the message window that appears.

In a similar manner, periodically check on the captured GOOD messages by selecting the [image] node under [image] on the left pane.

2.

Invoke Training Wizard

Once you have the reviewed the messages that were in the [image] GOOD and BAD, you may begin the training on all the accumulated queued messages that are now in [image] state by running the training wizard.

Pressing [image] displays the review window allowing you to select which class you want to train -- GOOD, BAD, or both.

Note the numbers shown for training are those found in the [image] state for both GOOD and BAD. Press [image] to begin the training.

Warning:

CMS does not recommended performing the bulk training during the business day. The reason this is unwise is that the number of simultaneous accesses to the MSDE SQL Server will likely exceed the limit of 8 and this will cause its workload governor to get engaged. This governor will slow both Bayesian classification of incoming messages and the training.

The training process consists of processing each message to break it down into its component tokens and accumulating them.

After this collection is done, the token database is updated with the addition of new tokens that are found in the training samples.

Depending on how many messages you train, how many tokens are found, and how busy the Praetor machine is, the training process may take some time and a significant amount of CPU resources. Therefore it is a good idea to perform this training during a period when the machine is not busy.

The counter in the above display is only updated periodically so that resources are not wasted for display.

Once the initial bulk training is completed, all the messages once listed as [image] will now be found in the [image] archive list for the GOOD and BAD nodes. You can always check how many messages have been trained thus far by viewing the Train tab page of the Bayesian configuration.

To begin using the Bayesian filter to classify your messages, you will need to make the setting change from training on this page.

Note:

Once training has been performed, the message samples will remain in the TrainBAD or TrainGOOD physical folders on the disk indefinitely. The reason for leaving these message samples is to allow you to re-use them in future initial training after resetting (emptying) the token database. If you want, you may delete these files by using the administration program and highlighting all entries in [image] for the [image] and/or [image] and then right-mouse click and choose to delete them.


Copying a rule

To copy an existing rule (so that you can later modify the copy), simply select the rule from the top list and press the Copy button. You are then presented with a dialog to change the rule name of the copy as shown below.

Dialog to name the new copy of your rule

Simply press OK when you are finished and you will be returned to the rules tab page where you can use the Move Up and Move Down buttons to position your new rule accordingly or press the Modify button so that you can customize the rule.

Return to Rules Settings


Creating a global rule

Global rules are far simpler to create than conditional rules since the only thing to choose besides message direction is what action(s) you want to take place. To start the rule creation process begin by highlighting the appropriate direction under the Global rule node in the left pane of the Praetor administration snap-in program. Right mouse click for the selection to create a new rule.

You will be presented with a single screen for rule creation as shown below.

Give this new rule a name and verify its direction. If the direction is wrong, you will need to cancel this attempt and start again by highlighting the correct direction from the left pane.

You may also decide if you want this rule to be enabled as soon as you are finished creating it. If not then leave the box unchecked and you can enable it later.

As for the various available actions, add them by first selecting one action you want and the pointer will move accordingly. Press the [image] button to add it and your selection appears in the Description field below. On some actions you may add the same action more than once so you will need to enter unique parameters to make each instance different.

The list of available actions are:

Archive | Make a copy of the message file and places it in the CMS Praetor\Archive folder. Only one Archive action may be added.
Archive Final Action | Based upon the final action in disposing the message (Accepted, Rejected, Redirected, or Returned to sender) archive to the specified folder. Multiple actions are permitted, each with a different Final Action value.
Insert text at the beginning or end of the message | Inserts the text from the specified file into the message body, either at the very beginning or very end. The typical use of this action is to include a disclaimer to the every message. You may insert text to the beginning and the end of the message.
Forward | Forwards a copy of the message to another email address, such a compliance officer who deals with such email security issues. Also this may be used as another method to archive messages, treating them as messages instead of raw ASCII files as the ARCHIVE action does. Requires an Internet/SMTP address to be specified and only a single forward action is permitted.
Add X-field | Adds an X-field line into the message header. If one already exists, then append to the end after adding a semi-colon as a separator. If not, then create a new X-field header line. Multiple actions are permitted, each for a different X-field.
Set X-field | Sets an X-field line into the message header. If one already exists, then replace it with the new entry. If not, then create a new X-field header line. Multiple actions are permitted, each for a different X-field.

Tip:

While it is certainly possible to create several global rules for the same message direction, it is more efficient if you collected all your actions into a single rule for the selected direction.

Creating separate rules may be justified if you need to independently deactivate a particular action. Thus with a separate global rule this can be accomplished simply by disabling the rule instead of editing one big rule with multiple actions and deleting an action.

Disabling or Enabling Existing Global Rules

Highlight the appropriate global rule type in the left pane to show the list of available rules and then double-clicking on any listed global rule in the right pane. This will open the properties window for that rule window, and modify the rule including the enable or disable the rule itself.

Press OK when you are completed with the modification and the rule will take effect immediately with the very next message for that direction.

Return to Rules Settings


Deleting a rule

To delete an existing rule, simply select the rule from the top list and press the Delete button. You are then presented with a dialog to confirm this action as shown below.

Dialog to confirm deleting a rule

Simply press OK to delete the rule. You will then be returned to the rules tab page.

Return to Rules Settings


Editing system for Exchange

If you were upgrading from a previous build of Praetor and have it installed on the Exchange

Edit system settings for original Exchange installation


Importing a new RULE.INI

As an on-going effort to support our Praetor customers, CMS periodically updates the product with additional rules or refines existing rules. These updates will be in the form of a new RULE.INI file whose availability will be made known to those customers who subscribe to our annual support arrangement.

When you obtain an updated RULE.INI file, press the Import... button from the Rules settings tab page and you will be presented with a file Open dialog.

File Open dialog

Locate and select the updated file and press Open to import the new rules into your existing configuration. You will see any new rules in the form of additional templates, conditions, and actions when you create a new rule.

Return to Rules Settings


Manage SMTP Sinks

This section of Praetor control is only relevant if

  1. You have installed it on a server platform of Windows since non-server editions do not support multiple SMTP virtual servers.

  2. Your installation has multiple virtual SMTP servers configured.

  3. You want to bind Praetor only on a select number of the configured virtual SMTP servers.

Almost all Praetor installations will not need to configure its binding as it binds to the default SMTP server. The one exception will be any ISP or ASP who will use a single, powerful machine to host several virtual SMTP servers for multiple customers.

If you only have the single default instance of the virtual SMTP server, this control is only useful to temporarily disengage the Praetor filtering software from being called upon by the SMTP server. In that case the server instance number is 1.

Protocol Sink

The (SMTP) protocol sink performs one function within Praetor —DNS blackhole list filtering at the SMTP level. Thus disengaging this sink will prevent Praetor from performing this filtering and Praetor will not be able to refuse inbound messages originating from a sending mail server whose IP address is listed in the blackhole list database.

Transport Sink

The transport sink performs Praetor's message level filtering (Bayesian and rules) so disengaging this will essentially render Praetor incapable of perform these filtering functions.

Advanced options


Ordering the rules

The order in which the message level rules are performed is significant in terms of the impact on Praetor performance and how many valid messages are rejected or quarantined as spam (the so-called false positives). As an administrator, your job is to find a balance for your organization to minimize the false positives while accurately identifying spam and attaining high message processing volume from Praetor.

To understand the balance, consider what happens if the conditions are too general. This would result in better Praetor performance because it will be able to determine whether or not to reject the message as spam very early on, within the first few rules. The price for this, however, is that there may be a large number of false positives, which means the intended recipients do not get many of their messages. In contrast, if the rules were very specific and there were many of them for Praetor to perform against each message, then the number of false positives would be reduced significantly, but Praetor would spend a longer time on each message, checking it against the many rules. Keep in mind that messages that survive the rule filtering must be checked against all the rules. For a discussion on this, please read this.

When you have several rules involving the same condition(s), some are made more specific by adding other conditions. In these situations, the general suggestion is to order the more specific rules to be processed first. You do this by positioning them above others by highlighting the rule you wish to re-position and using the [image] or [image] button on the toolbar accordingly or using the right-mouse click to select the Move up or Move down menu item.

Return to Rules Settings


Relay Filtering

By default the Windows virtual SMTP is set to prevent SMTP relaying. This is done to so that anonymous spammers will be prevented from robbing valuable mail server resources from you and route all of their junk email. Only those mail servers specifically allowed to relay will be permitted to send email via this mail server.

To change your settings run the Control Panel applet that administers the Internet Information Services on this machine. This applet will likely be found in the Administrative Tools folder.

Expand the left pane until you can select the [image] icon in the left pane.

Right-mouse click and select to view the properties of this SMTP Virtual Server and select the Access tab.

Press the [image] button in the Relay restrictions group box.

It is here that you may add access restrictions, either based on IP address, IP address range using a subnet mask, or domain name.

Warning:

It is very dangerous for you to check the radio button for All except the list below since this will effectively disable all protection against mail relaying. This will get your mail server listed on various DNS blacklists.


Renaming a rule

To rename an existing rule, simply select the rule from the top list and press the Rename button. You are then presented with a dialog to change the rule name as shown below.

Dialog to rename the rule

Simply press OK when you are finished and you will be returned to the rules tab page.

Return to Rules Settings


Rule script

Return to Configuring Praetor


Stopping and starting Praetor

Highlighting the main Praetor root node in the left pane and pressing the right mouse button will expose a drop-down list of choices. If the service is marked Enabled on the root node then the Stop Praetor selection is available; if it is Disabled then the Start Praetor selection is available.

Choosing one will cause Praetor to stop or start.


Using VNC

Using VNC to remotely administer Praetor

After downloading the latest version of this free remote control software from AT&T's research labs in the United Kingdom, here are steps to install it on the Praetor PC and using it on a remote machine.

1. | Extract all the files and place them into a single directory.
2. | On the Praetor machine run the VNC SETUP program to install the files. This will prompt you for the directory location for the files to be placed in the local PC's hard disk and ask for a name for the program group (VNC is the default).
3. | Once the files are installed, find the StartUp program group VNC and expand the folder Administrative Tools and then select "Install WinVNC service".
4. | Since this is the very first time you will be prompted to enter a password to be used when viewing this machine remotely.
5. | On the remote client machine, get shared access the Praetor PC and locate and run the VNCViewer.EXE. When prompted enter the Praetor PC's internal IP address with ":0" appended.
6. | Then when prompted, enter the password set up in step 4. The VNC Viewer client will then remote control the Praetor PC. Alternatively, you can use a browser. Just try connecting to the internal IP address and specify port 5800. For the example in the picture, you would use the URL http://192.168.0.103:5800/. Enter the password that was set up in step 4.


Viewing the Praetor log entries

Sample Praetor log entries

For more information on using this Log Viewer application, click here.


Add or Set X- header field

Add X- header field

Optional

This action is used to add a new X- message header field and may be used to provide results from Praetor's analysis that can be tested by client-side rules. If this header field already exists, this action will create new fields with the same name.

You specify the X- header field name and parameter value through the entry screen as follows.

For an example of how this can be used to great advantage and create client-server cooperative processing, see this FAQ #6.

There are reserved names for variable information that can be placed as the value for X-header field. Click here to see the list.

Set X- header field

Optional

This action is used set the value for a pre-existing X- message header field, replacing the original value for that field. When no such header field exists this action will cause a new field to be created, behaving exactly like the Add X- header field action above.

There are reserved names for variable information that can be placed within the X-header field. Click here to see the list.

Reserved names for message variable information to be added

The following case-sensitive keywords may be used to supply variable information from the message in question.

Reserved keyword | Description
%ATTCOUNT% | Number of attachments in the message, excluding embedded messages that might have their own attachments.
%ATTNAMES% | List of attachment names separated by commas.
%DIRECTION% | Direction of the message, either "INBOUND" or "OUTBOUND".
%GUID% | Praetor unique message ID.
%MAILFROM% | The From address taken out of the RFC-2821 envelope.
%REASON% | Reason description as seen in the Log Viewer application and taken from the recorded RSN file.
%RULE% | Rule description that caught this message.
%SIZE% | Message size as occupied in the temporary file with attachment in its raw, undecoded (expanded) size.
%SUBJECT% | Message subject taken from the RFC-2822 message header.
%TODAY% | Today's date. Example: Friday, 13 September, 2002.

Flag the message as spam

Optional

This action automatically adds the following line into the message header:

X-Praetor-Analysis: Possible-spam

This is equivalent to manually using the Add X-field action and setting the fields as shown below.

Add the reason why the message was caught

Optional

This action automatically adds the following line into the message header:

X-Praetor-Reason: <variable text with reason>

This is equivalent to manually using the Add X-field action and setting the fields as shown below, taking advantage of the %REASON% keyword.

Add name of rule that caught the message

Optional

This action automatically adds the following line into the message header:

X-Praetor-Rule: <variable text with the rule name>

This is equivalent to manually using the Add X-field action and setting the fields as shown below taking advantage of the %RULE% keyword.


Create a new list

Introduced with Praetor G2 is the ability for you to create your own string or checked string lists, as you can see from the above. Selecting one will display an entry screen similar to the one below.

Here you can provide a description for the list name and enter the strings that comprise the list. The description can be up to 32 alphanumeric characters in length and the administration program will automatically create an internal list name for use by the rule itself that:

  • Removes disallowed characters (e.g. special symbols, punctuations, etc.)

  • Replaces all spaces with underscores

When you are finished with the list, press [image] to return to the directory of all available lists.

Click here to learn the proper condition that allows you the use the newly-created list.


Exceptions

For every condition listed, a corresponding exception will exist for you to choose. Use them to control your custom rule more precisely such as allowing certain banned attachments if they intended for a recipient who is qualified to handle them.

As Praetor tests each rule and the message under review is triggered on the condition, it will then test check to see if the exception(s) are also met. If the exceptions found to be true then the rule's action will not be performed, and the message will continue to be tested against the other remaining rules.

You may select any exception as long as it is not the same as the corresponding condition.


Forward

Optional

This action causes a completely new message to be created which contains the entire contents of the original message. When the recipient receives the forwarded message, it will appear as though the sender is the Praetor administrator.

By clicking on this address in the Rule Description box you will be presented with the following form where you may complete the destination address, subject keyword, and message text. At a minimum you must provide a destination address in the normal SMTP address format.

Note:

While the above Forward Message to Address window allows for only a single SMTP address to be entered, using an address that represents an Exchange or Domino distribution group will allow multiple recipients to get a copy of the forwarded message.

The entry for the field Append Keyword will be appended to the subject line, which will have the form as shown below from the above example.

Fwd: <original-subject-text> [Found Profanity]

When you have completed this form, press OK to return to the previous screen with the forwarding destination address visible.

Note:

In general you need to exercise some caution when you use an auto-forward mechanism. This doesn't apply directly to Praetor because the Forwarded message it generates has the administrator's email address as the sender. We have received calls from customers to our technical support thinking Praetor is involved in a problem of message loops.

In the cases we have seen, the loop is caused when an Outlook user creates a rule to automatically forward all arriving messages to a mail account on some free email service like hotmail.com or yahoo.com. What they forget is that the free email inbox has some storage limit. Once the limit is reached, no more email can be received and the hotmail or yahoo mail server will send a non-delivery report (NDR) containing the original message back to that very same user. Of course with the user's Outlook auto-forwarding rule still in place, the NDR gets forwarded to the full inbox on that free service, creating the loop.

The best way to prevent such a loop is to educate the users. They need to include an exception with the Outlook auto-forward rule. The exception is to test for NDR from the postmaster address at their email service.

The situation described above specifically deals with Outlook users who have created an auto-forward rule. It would apply to any similar auto-forward capability with a different desktop email client software to an email service with size limits that causes an NDR to be generated.

Next


Importing list entries

Selecting any list in the right pane and double-clicking on it will bring up the properties of the list and show all its entries. The list name is shown as part of the window name, Suspicious Domains, in the example below.

Press [image] to open the File-Open window allowing you to select the source file to be imported.

Once you navigate to the folder where the source file is located, selected it and press [image].

Exported Praetor list file

The easiest method to export the lists on your Praetor v1.5 is to use the MODLIST tool and the /EXPLISTS command. The sample MyPrLists.TXT referred to above was obtained by using the following command on the older Praetor v1.5 installation.

MODLIST /EXPLISTS:MyPrLists.TXT

Once exported simply copy the MyPrLists.TXT file to the new Praetor G2 machine.

When you use the Praetor G2 administration tool and press [image] and the selected input file is recognized as an exported Praetor list file, you will be presented with a comprehensive screen as follows.

In the List Name field window you can select the appropriate source list name to import the entries into the target list that you opened (Suspicious Domains in the above example). The entries are shown in the window to the right. At the bottom you see three different group boxes as explained below.

  • Action

This allows you to determine if the import process will use the source entries to append or replace those entries the already exist.

  • Import

This is only available if the source list is a checked string list in which case you can choose to import only those entries are checked, unchecked, or all.

  • Import As

This is only available if the target list is a checked string list in which case you can choose to cause the entries to be saved either as checked, unchecked, or whatever setting was in the original source.

Make your choices and press [image] to import all the entries, and then [image] to return to the directory of lists.

Simple list entries

If the source list was a simple text file which was not exported from Praetor that you might have edited manually putting a single entry on each line, then the import options are not as comprehensive.

The same Action options as before. For a target that is a checked string list as the Suspicious Domains list, you can only designate whether the list entries to be imported will result in being checked or unchecked.

Make your choices and press [image] to import all the entries, and then [image] to return to the directory of lists.


Insert Text

Optional

This action is used primarily to add a disclaimer to the message body. It is an action that can be used with global rules (that have no condition) sensitive only to the message direction or with individual rules, each with a different disclaimer text.

Note:

Since global rules are distinguished by their direction, you can create a separate disclaimer for each direction. Alternatively you may supplement the global disclaimer with additional text that only apply for particular rule(s).

Insertion of the disclaimer text into the message can be done either at the beginning or end of the original text portion. In either case, you select the appropriate action from the list.

In the Rules Description box, click on file name so that you may select the appropriate file containing the text that you want to insert. A file browse dialog box will appear.

Once selected press the Open button and you will be returned to the previous Rule Wizard screen with the full path and filename appearing in the Rule Description box.

Note:

Praetor is not sensitive to the disclaimer text; it adds whatever you have in the specified file into the message. Thus, if the file contains HTML disclaimer text, and the message was declared to be plain text, Praetor will not convert the message and promote it to become HTML since the original was not HTML.

Praetor is, however, sensitive to the type of the original message body content. If it finds the body is HTML, it will perform a simple conversion of the disclaimer text, inserting <BR> before all end-of-line characters. Outside of this simple conversion it does not do anything else to the disclaimer.

CMS suggests that you keep the text line length at a maximum of 60 characters. This will prevent mail clients on the receiving end to introduce line breaks that will make your disclaimer be sub-optimal in its appearance on-screen.


Notify

Send Notification

Optional

This action causes a notification summary message to be sent. There are three possible destinations and, depending on who is the recipient, will prompt for different pieces of information that is needed. The possible destinations are: any email address, the local administrator, or the original message sender that was caught by this rule being constructed.

Note:

In all cases the default From address is given in the form of an alias for the administrator and the address is #PRAETOR-ADMIN@local-domian, where local-domain is the Internet domain name for your site. The reason this alias is being used (instead of the known administrator's email address) is to insure that any replies will get routed to the current administrator when Praetor receives the reply.

Notification to any address

If the recipient of the notification message is to be any SMTP address, local in your own domain or the Internet, the screen appears as follows.

The phrase this address that appears in the Rule Description box indicates some information needs to be supplied. So upon clicking this phrase you will see the following blank form.

You may then enter the recipient's email address in the To: field, along with a subject for this notice, and any message text. You may also choose one of the Send Options buttons to include either a message summary or the entire original message.

Note:

In the above Notification Message window and similar windows described below, if the From field appears only as "#PRAETOR-ADMIN@" and does not have your local domain name, your Praetor has not been completely setup. The domain portion is derived from the Administrator's email address, and this anomalous situation indicates that the field is not correctly entered. Click here to edit this.

Also, while the To field allows for only a single SMTP address to be entered, you can circumvent this by referencing an Exchange or Domino distribution group so that multiple recipients will get a copy of the notification message. By using such a distribution group, changes to the list of recipients may be made without the need to stop and restart Praetor.

Notification to the administrator

If the recipient of the notification message is to be the administrator, select the appropriate action as shown below.

In the Rule Description, click on administrator and you will get the blank form where you may enter the subject and message text.

The notification message to the administrator will also automatically contain additional information not found in other notification messages. This includes the rule that caught the message, original date, sender, intended recipient, and subject line.

Notification to message sender

If the notification is to be sent to the sender whose message was caught by this rule, then this action is selected as shown below.

Clicking on the sender will bring up an blank form for you to provide a subject and message text for the notice, and to select the Send Options. The sender's address will be automatically entered for you so the To: field is grayed out.

Notification to intended recipients

If the recipient is to be notified of a message caught by this rule, then select this action as shown below.

Clicking on the recipients will bring up an blank form for you to provide a subject and message text for the notice, and to select the Send Options. All the intended recipients addresses originally found in the message will be automatically entered for you so this field is grayed out.

Next


Redirect

Terminal

This action will cause the message to be re-routed to a different address other than the intended recipient. Selecting this will require several pieces of information in order to be valid. Thus when first checking the box for this terminal action, you see the following screen with the description that reflects the selection.

As you can see from the bottom line in the Rule Description box, the address initially is missing and appears as this address. Click on it and the following screen appears with a blank field to enter a valid Internet address, which may also be locally at your own domain.

Note:

While the above SMTP Addresses window allows for multiple addresses to be entered, it may be more efficient and convenient to reference an Exchange or Domino distribution group.

Changes you make will take effect with the very next message processed by Praetor.

Press [image] and then [image] to make your entry effective. You will then see the following in the Rule Description area of the screen to confirm your entry.

The redirected message will be constructed in the following manner.

  1. Replace the RFC2821 MAIL FROM address with #PRAETOR-ADMIN@local-domain.

  2. Replace the RFC2821 RCPT TO address with the redirected address you specified above.

  3. If a Reply-To field does not exist in the RFC822 header, then one will be added and the original RFC2821 MAIL FROM address will be used.

Next


Return to sender

Terminal

This action will take the message and return it to the original sender. Selecting it from the main list of available optional actions will cause the following to be displayed.

By clicking administrator in the Rule Description box, you will then be presented a form allowing you to change the From address and to provide a subject and some message text. The sender's address will be automatically filled in when the return message is created.

Notice the Send Options group box with the two radio buttons allowing the return of the complete original message with any attachment(s), or simply a message summary. In cases of messages containing virus infections, as shown in the above example, CMS recommends that you only send a summary to avoid the propagation of these malicious attachments.

Press [image] to return to complete the rule.

Note:

This action may be used as an auto-reply mechanism when the default No additional text option is selected.

Return to list of Actions


AD export users

Exporting Users in Active Directory

You can use Control Panel's Administrator Tool called Active Directory Users and Computers to export your users with their email address information. To export all the relevant information for use by PLGV, there are three steps to perform:

  1. Change the display columns to only show relevant information

  2. Export the list in comma-separated CSV file

  3. Use ADfilter tool to create the file for importing into the user table

Change the display columns

You must first change the columns and limit them only to export what is needed. From the main menu, select View->Choose Columns and use the Add / Remove / Move Up / Move Down buttons until you see the list on the right as shown below.

It is very important that you arrange the displayed columns in the specific order shown above. Ordered in this way, these columns exactly map directly into the proper PLGV user name format in the following manner.

Active Directory displayed columns | PLGV complete user name format
Name | Discarded
Exchange Alias | Login name
First Name | First Name
Last Name | Last Name
Description | Placeholder for password
Type | Role, either "User" or "Administrator"
Email Address | Email Address

Notes:

  1. Name will be ignored. It is a property that cannot be removed in the Active Directory Users and Computers tool.

  2. The description information is not used, and it only serves to reserve space in the exported list that will later be used for the password.

  3. While the type value of "User" can be found, you will need to manually promote any individual entry to "Administrator" since this string is only a designation used in PLGV. You will notice that even the "Administrator" user in Active Directory will have the type as "User".

Export the list

To export the list, you must highlight the Users container in the right pane, and right-mouse click to select Export List... as shown below. (Note the changed column headings that are displayed matches the above table.)

You will then be prompted to specify the location, filename and file type for this exported list. It is recommended that you save directly to the PLGV folder under C:\Program Files\CMS Praetor G2. Be sure to choose to save the file in the comma delimited CSV format as shown.

The exported CSV will include many entries that are not relevant to PLGV and only those entries with valid email addresses are significant. For example, you will likely find entries with a Type value of "Security Group - Global" or "Security Group - Domain Local", but there are also "User" entries that are not relevant that have no email address such as those for built-in accounts for various processes or applications.

All the entries without any email address need to be deleted and the "Description" field needs to be replaced with a temporary password. If you want to make the temporary password different for each user, then you can manually do this by importing the CSV file into Microsoft Excel.

If the temporary password can be the same for everyone, then use the tool called ADfilter.EXE discussed below.

Use ADfilter tool

The ADfilter tool found in the Praetor Tools folder will use the exported CSV from Active Directory Users and Computers and save only the entries with email addresses. You will see the following screen where you can navigate to the location of the input file and select it. You can also assign a common temporary password.

ADfilter produces its output file in the same location as the source input and preserves the filename but adds .LST as the new extension. You will see that in the output filename field; so if the original file was called ADusers.CSV, the processed output file will be ADusers.CSV.LST. The original input file will be retained.

You can then directly import this into the user table using PLGV Setup.

Return


Message Archive

The message archive node in the left pane will list all active archived areas you have set up within your selected rules where records exist. In the above example, a global rule was set up to archive all rejected messages, so selecting that archive node displays those log entries.


Migrating SQL dBs

Migrating SQL databases

If you find the Microsoft SQL Desktop Engine too limiting, you will need to use the Microsoft SQL Server. CMS recommends that you install the SQL Server onto the same machine, right on top of the existing MSDE as another SQL Server instance.

Note:

If you think you need or want to migrate onto an existing SQL Server that is another machine, please contact CMS Support.

Once you have the Microsoft SQL Server installed, you will need to migrate the Praetor databases to that server. Follow these steps to perform the migration.

1.

Use the Praetor administration tool, temporarily deactivate Praetor. Alternatively you may simply stop the IIS SMTP Server via IIS Manager.

2.

Detach the Praetor databases from MSDE by using the SQL script file found in the main Praetor folder called Detach.SQL. Invoke via a command prompt as follows:

OSQL -E -i Detach.SQL

3.

Using the SQL Enterprise Manager re-attach the two Praetor databases as shown below.

The selection window will then appear allowing you to locate and specify the Praetor database file.

Press [image] and navigate your path to the Praetor G2 folder and select the PraetorLog_Data.MDF file.

Press [image] and then in the field for Specify database owner select the currently logged in administrator account you are using.

Press [image] to complete re-attaching that database.

4.

Repeat step 3 but select the PraetorClassify_Data.MDF file.

Next


Redirect the message

When using the Log Viewer to view the details of a quarantined message, you may sometimes decide to redirect it to a different address. This is easily done by pressing the Redirect button. You will then be prompted to enter the new destination Internet/SMTP address for the message. This address may be any valid email address, even for a recipient address in your network, but only a single address is permitted.

When the redirected recipient gets the message, it will appear as though he or she is a blind carbon copy recipient as all the original SMTP RFC-822 headers are retained. Only the RFC-821 transport delivery address has been changed to the address specified.


Return to sender

When using the Log Viewer to view the details of a quarantined message, you may sometimes decide to return the message. This is done by pressing [image]. You will then be presented with a dialog box that appears as shown below.

Here you may select a template for the response from the drop-down list. This selection will cause the appropriate information for the subject and message body to appear in the fields below. You may then edit this as you want, and this subject and message body will accompany the return of the original message to the sender.

Click here to learn how templates may be created.

The radio buttons at the bottom gives you the option of returning the original message in its entirety with any and all attachments, or to send only a summary of the original message containing original date, sender, intended recipient, and subject. Obviously sending only the summary will be less of a drain on your Internet connection bandwidth than returning a message containing a large attachment.


Security Identities

Setting up proper security identities

Under normal circumstances, installing the Praetor databases will set them and Praetor components to use the appropriate identities so that the IIS web server may use them.

Since the IIS web server is a program not written by CMS, you will need to tell the Praetor component prLog that IIS can launch and access it. If prLog doesn't have these settings, message details cannot be accessed.

Configuring this is performed by using the DCOM configuration tool from Microsoft, DCOMCNFG for Windows 2000 or Component Services for Windows XP and 2003. In any case, you can open this tool by invoking DCOMCNFG from a command window. Depending on your Windows OS, you will see one of the following:

Windows 2000 Professional or Server | Scroll and select the prLog application and then press [image] .
Windows XP Professional or Windows 2003 Server | Expand Computers and My Computer and then select the DCOM Config folder in the left pane. In the right pane, scroll and select the prLog application, right-mouse click and select Properties.

The prLog properties page will be displayed, so select the Security tab.

First edit the Launch permissions to add at least one security identity; we'll do the very same thing for Access permissions later. What needs to be added varies depending upon the Windows operating system is on the Praetor machine. Press [image] and then [image].

Depending on whether you use Windows 2000 or XP you will see one of the following.

Windows 2000 Professional or Server after pressing

Windows XP Professional or Windows 2003 Server after pressing [image] and

Either select the security identities in the field Enter the object names to select or type in the identities shown, below according to your situation. Unless you have Windows 2003 Server, replace MachineName and DomainName with the correct strings for your Praetor machine and network names. The other strings you see in bold like this are static text.

Windows platform for Praetor

prLog security identity to add

Windows 2000 Server stand-alone,
Windows 2000 Professional or
Windows 2000 or XP Professional

  1. MachineName\PG2_MachineName

  2. MachineName\ASPNET

Windows 2000 Server domain controller

  1. DomainName\PG2_MachineName

  2. DomainName\ASPNET

Windows 2003 Server

NT AUTHORITY\NETWORK SERVICE

Next, add the same identities for the Access permissions.


SQL Server setup

The default configuration presumes that Praetor has access to a local SQL Server, either the free Microsoft SQL Desktop Edition (MSDE) or a real SQL Server installed on the same machine. Thus you will need to change this setting you have either of the following situations:

  • You find that MSDE is too limiting and install the Microsoft SQL Server on the same Praetor machine.

  • You want to use a standalone SQL Server.

Assuming you have migrated the Praetor SQL databases to the SQL Server, you can change this by pressing on the Configure link in the right pane as shown below.

The following window will appear.

Once the SQL Server has been selected or a name entered, you may choose to use either Windows or SQL Server authentication method. If Windows authentication is selected, then Praetor will use the login originally established when it was installed. If you select SQL Server authentication, you will need to provide the login account and its password.

If your SQL Server is on the Praetor machine, chances are that you installed SQL Server while MSDE was still present. During such an installation you would have been prompted for an instance name and the entry that is needed by Praetor will be in the form MACHINE_NAME\INSTANCE_NAME.


Domain report

Domain Summary

When you first select the Domain Summary report from the Report submenu, you are presented with the selector screen shown below. This allows you to determine what type of domain report will be created -- for the inbound or outbound direction, the sort criteria, and over what date range.

Note:

On inbound messages, it is the Internet senders' domains that are being reported, while on outbound messages it is the Internet recipients' domains.

A sample report is shown below for inbound messages, sorted by decreasing frequency.

Next


Event Count

This selection from the Event submenu allows you to get a count summary of each different event type: Accepting, Rejecting, ...

Pressing [image] on each line provides a detailed single-entry event view for all the messages of that event type.

The button [image] switches to the same view but for all event types not just a particular one.

Pressing [image] button will switch you to that screen.

Next


Event listing

Events

This selection from the Event submenu allows you to view all the Praetor log entries in a tabular format. Due to our shift to a SQL database, some fields are no longer used and will appear blank.

Next


Event report

Event Summary

Pressing the Event Summary button from the Reports submenu will bring up a selection screen allowing you to choose whether the report is for one specific domain (if you have many domains processed by Praetor), or across all configured domains.

Once selected, a printable report will be displayed that summarizes the number of each event type for all messages that Praetor has processed. This is similar to the Event Count selection from the Event submenu, but no details are available.

Next


Event Viewer

This selection from the Event submenu allows you to view a single Praetor log entry in greater detail. As you can see below, it provides much of the information that is available in the one-line-per-entry tabular form, but expands the column information into a single-page format.

Next


Recipient report

Recipient Summary

When you first select the Recipient Summary report from the Report submenu, you are presented with the selector screen shown below. This allows you to determine what type of recipient report will be created -- for the inbound or outbound direction, the sort criteria, and over what date range.

Note:

On inbound messages, it is the local recipients' addresses that are being reported, while on outbound messages it is the Internet recipients' addresses.

A sample report is shown below for inbound messages, sorted alphabetically.

Next


Rule report

Rule Summary

Pressing the Rule Summary button from the Reports submenu will cause a printable report to be displayed that summarizes the number of each active rule that was applied to messages Praetor has processed. The report is broken down by the sending or receiving domain name and even shows the action taken including the approval of quarantined messages.

This is similar to the Rule Summary selection from the Event submenu, but provides domain-specific information.

Next


Rule Summary

This selection from the Event submenu allows you to get a count summary of each different active rule that you have configured in Praetor.

Pressing [image] on each line provides a detail single-entry event view for all the messages caught by that particular rule.

Return


Sender report

Sender Summary

When you first select the Sender Summary report from the Report submenu, you are presented with the selector screen shown below. This allows you to determine what type of sender report will be created -- for the inbound or outbound direction, the sort criteria, and over what date range.

Note:

On inbound messages, it is the Internet senders' addresses that are being reported, while on outbound messages it is the local senders' addresses.

A sample report is shown below for inbound messages, sorted by decreasing frequency count.

Next


Custom report

Log Entries for Specific Criteria

When you press the button for Log Entries for Specific Criteria you will be presented the following screen so that you may specify selections for your report: date range, event type, and report form type.

Note:

For new event types that are not yet reflected in the Log Analyzer program, the selection of the Custom Event allows you to have a custom report that searches for the new event type string.

You may select how you want to view the results -- in a single-message detail view or a report view as shown in the samples below.

Event Viewer format

The Report button selects a format that may be printed.

Report format

Return


HELO Sending mailhost validation

Sending mailhost validation

At the beginning of a message reception, the sending mailhost attempts to establish a TCP/IP connection with the IIS SMTP Server. If it is accepted by the IIS SMTP Server, then Praetor can perform further testing for DNSBL using IP address of the sending mailhost.

Accept based on IP address

Purpose:

Test the sending mailhost source IP address see if it matches one in the accepted IP address list of the IIS SMTP Server.

Action:

Accept if the IP address of the sending mail host is found in the accepted IP address list and pass on to Praetor for further processing.

Default state:

Accepted IP address list is empty.

False Positive:

This rule is very specific and will not cause any false positives.

Other notes:

Reject banned IP address

Purpose: | Test the sending mailhost source IP address see if it matches one in the banned IP address list of the IIS SMTP Server.
Action: | Reject if the IP address of the sending mail host is found in the banned IP address list. Thus Praetor will never receive the message.
Default state: | Banned IP address list is empty.
False Positive: | This rule is very specific and will not cause any false positives.
Other notes: | - NONE -

Reject IP address found on DNS Blackhole List

A DNS blackhole list (DNSBL) is an actively maintained list on a DNS server that can be queried to check if an IP address is found in the list. If it is, then it indicates that the associated mail server has been judged abusive for the criteria of that DNS server. A good example is the original Real-time Blackhole List (RBL) from the Mail Abuse Organization.

Purpose: | Test the sending mailhost source IP address by querying the Internet-based Real-time Blackhole List (RBL).
Action: | Reject if the IP address of the sending mail host is reported found in the RBL.
Default state: | Enabled
False Positive: | This rule is very specific and will not cause any false positives.
Other notes: | - NONE -

To see how Praetor is configured to use DNSBL, read this FAQ.

Next


MAIL FROM sender address check

Note:

Spammers can easily manipulate this MAIL FROM field.

Reject banned sender

Purpose: | Test the message sender's email address to see if it matches one in the BANNED-SENDER-ADDR list.
Action: | Reject if the address is found in the BANNED-SENDER-ADDR list.
Default state: | Enabled
False Positive: | This rule is very specific and will not cause any false positive.
Other notes: | - NONE -

Accept based on sender address

Purpose:

Test the message sender's email address to see if it matches one in the ACCEPTED-SENDER-ADDR list.

Action:

Accept if the address is found in the ACCEPTED-SENDER-ADDR list.

Default state:

Enabled

False Positive:

This rule is very specific and will not cause any false positive.

Other notes:

Warning:

CMS strongly recommends against putting any entry into this Accepted Senders list. Entering trusted partners into this list will allow any message to be accepted, even a message that is sent by a worm that infected the senders' PC. Instead, we recommend that you simply add them into the rules-based Approved Message Level Domains list.

Next


MAIL FROM sender domain check

If an inbound message from a sending host passes the HELO domain validation tests and the aforementioned <MAIL FROM> address tests, Praetor then begins its gauntlet of <MAIL FROM> domain validation tests. Note that Praetor is not concerned with the originator's address, just his or her domain; the originator's name was validated in the <MAIL FROM> address validation, detailed previously.

Note:

Spammers can easily manipulate this MAIL FROM field.

Accept based on domain name

Purpose:

Test the message the domain portion of the sender's email address to see if it matches one in the ACCEPTED-DOMAIN list.

Action:

Accept if the domain name is found in the ACCEPTED-DOMAIN list.

Default state:

Enabled

False Positive:

This rule is very specific and will not cause any false positive.

Other notes:

Warning:

CMS strongly recommends against putting any entry into this Accept Domains list. Entering trusted partners into this list will allow any message to be accepted, even a message that is sent by a virus-infected PC (e.g. ILOVEYOU bug) at the partner location. Instead, we recommend that you simply add them into the rules-based Approved Message Level Domains list. Entries in this Accepted Domains list should be limited to your own protected internal subdomains.

Reject banned sender domain

Purpose: | Test the message sender's domain name portion of the email address to see if it matches one in the BANNED-DOMAINS list.
Action: | Reject if the domain name portion of the address is found in the BANNED-DOMAINS list.
Default state: | Enabled
False Positive: | This rule is very specific and will not cause any false positive.
Other notes: | - NONE -

Anonymous mailhost test

Purpose: | Perform a DNS lookup using the sender's domain name and verify that it does in fact exist.
Action: | Reject if the domain name does not have a A record entry in the DNS server.
Default state: | Enabled
False Positive: | This rule is very specific and will not cause any false positive.
Other notes: | - NONE -

Next


RCPT TO recipient address check

Assuming that an inbound message passes the IP address validations and the <MAIL FROM> address/domain analyses, the sending mailhost will next issue the <RCPT TO> command to Praetor. This command is sent for every intended recipient of the forthcoming message.

Praetor uses the recipient address to determine if it is local. This is done to prevent message relaying, a common theft of service spammers perpetrate on unprotected mail hosts.

Anti-relay test

Purpose: | Test the message recipient's email address to see if it is a local address within our domain.
Action: | Refuse if the address not local.
Default state: | Enabled
False Positive: | This rule is very specific and will not cause any false positive.
Other notes: | - NONE -


Banned headers

Banned RFC-822 header lines

Quarantine banned subject text

Purpose: | Check the message subject line to see if it contains words or phrases found on the BANNED-SUBJECT list.
Action: | Quarantine if the subject contains words or phrases that matches those found in the BANNED-SUBJECT list.
Default state: | Enabled
False Positive: | Depending on the entries in the BANNED-SUBJECT list, this rule may be very sensitive and generate a number of false positives.
Other notes: | Many times, spam will contain clearly objectionable phrases on the "Subject" line. Common entries include "XXX," "make money fast," "job opportunities," etc. But due to the likelihood of trapping false positives, choose your BANNED-SUBJECT entries very carefully.

Sample:

Date: Sun, 18 Oct 1998 01:47:32
From: <derby@usa.net>
To: <jdoe@acme.com>
Subject: make money stuffing envelopes

Dear Future Associate,

You Can Work At Home & Set Your Own Hours. Start earning Big Money in a short time
:
:
:

Quarantine bulk mail program signatures in the X-Mailer field

Purpose: | Check the RFC-822 X-Mailer line to see if it contains words or phrases found on the search list.
Action: | Quarantine if the subject contains words or phrases that matches those found in the search list.
Default state: | Disabled
False Positive: | It is possible, though unlikely, to get false positives. The source would be anyone who uses the bulk mailer programs for sending messages, typically newsletters to a distribution list and a local recipient is a subscriber.
Other notes: |

Return to Overview


DNS check

Quarantine message on failed DNS lookup of From/Sender/Reply-to domain

Purpose:

Perform a DNS query on the domain found in the address found on the RFC-822 header lines for From, Sender, and Reply-to (if it exists).

Action:

Quarantine if the Message ID field does not exist.

Default state:

Disabled

False Positive:

This rule should not cause false positives since it tests the "reply-ability" of the received message.

Other notes:

Praetor augments the transport level DNS check of the domain found in the message sender with additional tests of various addresses that may be replied to. This may be necessary because the transport level MAIL FROM address is easily manipulated.

Usually the RFC-821 MAIL FROM address is duplicated in either the Sender or From fields.

Due to the typical spammers' method of operation and their need to be unreachable, this set of rules is a very powerful anti-spam tool. After all, most spammers do not want to use a replyable address less they become inundated with nasty messages that are complaints from their victims. Therefore the typical spam will have an address in one of these fields that is fictitious and use a non-existent domain.

While this is an effective rule, enabling it will severely reduce Praetor's message through-put. This is due to the possibly slow response from the DNS server. Enable it with extreme caution. For this reason, it is provided in a disabled state.

Return to Overview


Identical To and From addresses

Quarantine with only 1 To recipient and the From and To are identical

Purpose:

If there is only a single To recipient, check to see if it is identical to the From address.

Action:

Quarantine if there is a single To recipient, and it is the same as the address found on the From field.

Default state:

Enabled

False Positive:

This rule is highly accurate but there is a small chance of false positives. That happens when the sender actually sends the message to him/herself, and the intended recipient on your LAN is actually a blind carbon-copy recipient. Fortunately this is a rather odd manner of sending a legitimate message, but it is one that many spammers do as a convenience.

Other notes:

Many spam messages have been observed to have the same address (ignoring descriptive text for the full name) on the "To" and "From" lines. Thus the intended recipient shows up only as an address in the RFC-821 RCPT TO command, which effectively makes the person receiving the message a blind carbon copy recipient.

This situation arises primarily because the spammers are too lazy to create a separately addressed message for each spam victim. Upon recognizing this condition, Praetor rejects the message and ends subsequent testing.

See sample below.

Sample:

Received: from flashmail.com by www.textiles.org.tw
via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO)
id TAA08399; Tue, 12 Jan 1999 19:48:30 +0800
From: freedomnow@newmail.net
Message-Id: <199901121148.TAA08399@www.textiles.org.tw>
Date: 1/11/99 11:28:24 AM Pacific Daylight Time
Reply-To: freedomnow@newmail.net
To: freedomnow@newmail.net
Subject: $$$$$ MONEY $$$$$

*** $100,000+ FIRST YEAR INCOME ***
:
:
:

Return to Overview


Message body

HTML message body

These tests look at the message body for spammer tricks as described below. For combinations of these individual tests resulting in an overall score for the message that can be tested, read the section on heuristic filtering.

Invisible HTML ink

Purpose: | Check to see if there are characters whose font color is the same or close to the background color, rendering them invisible or very hard to see.
Action: | Quarantine if such characters are found.
Default state: | Enabled
False Positive: | Low incidence of personal messages being rated as spam since people do not resort to such tricks, but some listserver messages may contain nearly invisible characters.
Other notes: | Add listserver addresses to the approved listserver address list to eliminate false positives from their automated system.

Tiny HTML text

Purpose: | Check to see if there are characters whose font size is very small, rendering them nearly invisible.
Action: | Quarantine if such characters are found.
Default state: | Enabled
False Positive: | Low incidence of personal messages being rated as spam since people do not resort to such tricks, but some listserver messages may contain nearly invisible characters.
Other notes: | Add listserver addresses to the approved listserver address list to eliminate false positives from their automated system.

Var info in msg body

Purpose: | Check to see if message contains some variable information defined in the Variable info in Message Text list, such as the email address of the recipient.
Action: | Quarantine if found.
Default state: | Disabled
False Positive: | Usually low incidence, depending on the list entries.
Other notes: | By default, the list entries define what to search for in the message. Examples include the recipient address when preceded by special characters such as slash or equal sign. These are typically used as an identifier opting out of future mailings.

Obfuscated URL

Purpose: | Check to see if links contain IP address instead of domain names, or encoded text.
Action: | Quarantine if found.
Default state: | Enabled
False Positive: | Low incidence of personal messages being rated as spam since people do not resort to such tricks, but some listserver messages may contain nearly invisible characters.
Other notes: | Add listserver addresses to the approved listserver address list to eliminate false positives from their automated system. This test is also performed on non-HTML message body text.

Banned profanity

Purpose: | Check to see message mainly contains profanity as specified in the Banned Profanity list.
Action: | Quarantine if found.
Default state: | Disabled
False Positive: | This may be a cause for false positives since informal and personal email may contain profanity.
Other notes: | None

Only external refs

Purpose: | Check to see message mainly contains URL references with gibberish text.
Action: | Quarantine if found.
Default state: | Disabled
False Positive: | Very low incidence since personal messages never contain encoded HTML segments.
Other notes: | None

Embedded-encoded HTML

Purpose: | Check to see if there Base64 encoded components.
Action: | Quarantine if such characters are found.
Default state: | Disabled
False Positive: | Very low incidence since personal message never contains encoded HTML segments.
Other notes: | None


Message ID

Quarantine when the Message ID field exists and is blank

Purpose:

Check for the Message ID field to see if it exists and ensure it is not blank.

Action:

Quarantine if the Message ID field is present but is blank.

Default state:

Enabled

False Positive:

This rule is extremely accurate with just a slim chance of false positives. Those erroneously quarantined messages may be innocent if generated by a new email-based application.

Another source of false positives are messages from older mail systems on the Internet that do not generate this field properly, i.e. they have no Message ID but leave blank field.

Other notes:

Spam messages are usually generated programmatically and it is likely that such tools will not generate a valid message ID field. Testing for the presence and validity of this field may be useful to screen out spam.

Sample:

Received: from zebra911 (PPPa13-Phoenix7-2R79.saturn.bbn.com [4.11.222.19])
by fujisan.webfujiyama.or.jp (8.6.12+2.4W/3.3W8-01) with SMTP
id KAA13308; Wed, 27 Jan 1999 10:31:42 +0900
Date: Wed, 27 Jan 1999 10:31:42 +0900
From: CharlieEcho15@usa.net
Message-Id:
To: WiseFolk-1@msn.com
Subject: EASILY.... Get 22,000 hits a day on your web site!

***********************************************
Liberty Electronic Press - NEWS FLASH
***********************************************
We all know that to make money with a web site you need lots of
:
:
:

Quarantine when the Message ID field does not exist

Purpose: | Require every message have the Message ID field present.
Action: | Quarantine if the Message ID field does not exist.
Default state: | Disabled
False Positive: | This rule is may cause a lot of false positives because many older email systems do not include this required message header line. Use this rule with caution.
Other notes: | Spam messages are usually generated programmatically and it is likely that this Message ID header line will be omitted. While this may be a useful rule to screen out such spam, we do not recommend using it due to the possibility of catching many valid messages.

Return to Overview


To and Cc addresses

Missing address

Quarantine when both To and Cc fields are missing or blank

Purpose:

Check to see if both the To and Cc fields of the message headers are missing or blank.

Action:

Quarantine if both the To and Cc fields are missing or blank.

Default state:

Enabled

False Positive:

This rule is quite accurate. The only times when a false positive might occur is with messages that are purposely devoid of any address on the To or Cc fields. This is sometimes the case with messages from a listserver who typically have only the comment "Undisclosed recipients of a list" on the To line and no address. (The manager of the unmanaged listserver set it up that way so that replies always go directly to the message authors and not the list.)

Other notes:

Some spam messages completely lack any "To" field or leave it blank. While this is not illegal per the RFC-822, it is highly suspect. Almost all email systems on the Internet will create a message with a To line in the header. This is a tell-tale sign that something is remiss (see the sample below.)

If the message being quarantined is from a list, we recommend you add that domain to the APPROVED-DOMAIN list.

Sample:

Received: from xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Date: Thu, 21 Jan 1999 01:27:01 GMT
From: marketopp@3dmail.com
Message-Id: <199901210127.BAA01535@bart.justresults.net>
Subject: The Ultimate Internet Marketing Tool - ADV:

If you haven't noticed it yet, e-mail is outpacing telemarketing and traditional direct mail (snail mail) as the fastest growing form of business-to-business marketing. Imagine being able to advertise to over two million web site owners!
:
:
:

Return to Overview


No local recipient

Quarantine messages addressed to Bcc recipients

Purpose:

Check the message header RFC-822 (To and Cc) recipient lists to see if there are any address(es) identifiable as a local recipient.

Action:

Quarantine if no local recipient is identifiable in the RFC-2822 recipient lists. Thus the RFC-821 RCPT TO delivery address is to a local blind carbon-copy recipient.

Default state:

Disabled

False Positive:

False positives can occur whenever senders outside your domain send email to a local recipient as a blind carbon-copy recipient. This also occurs with messages from listservers where typically the To line appears as "Multiple recipients of listserver."

Other notes:

Spam typically have this characteristic where the recipient address cannot be found in any RFC-822 message header line. Therefore it appears as though the person to receive the message is only identified by the RFC-2821 RCPT TO address and is a blind carbon copy (BCC) recipient. Of course such use of BCC is highly suspect as the other recipients have nothing to do with your domain.

This rule is included as a convenience but it is disabled. Be forewarned that it can be a source for many false positives.

Sample:

Received: from URimo0F8r ([63.10.97.164]) by news1-lut.server.cableol.net
(Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-0U10L2S100)
with SMTP id AHV11083; Fri, 19 Feb 1999 05:12:51 +0000
DATE: 19 Feb 99 12:05:17 AM
FROM: 7neXy1AAE@uswest.net
TO: wildbill@ekg,med
SUBJECT: EXPLODE YOUR BUSINESS ! ! ! !

Do you need bulk e-mailing services?

If so, we've got some extremely good news for you. As a way of getting the word out about our new company, we are offering guaranteed reliable bulk e-mail services at rock bottom prices.
:
:
:

Return to Overview


Precedence

Quarantine when the Precedence field has bulk

In a full RFC-822 header there can be a Precedence field, typically used to connote the priority (Urgent, Normal, or Low), which is its own optional header field. A precedence field marked "Low" or "Bulk," in our experience, is a characteristic exhibited by many spam.

Purpose: | Check for the Precedence field in the message header.
Action: | Quarantine if the Precedence field has the word "bulk".
Default state: | Enabled
False Positive: | The false positives that might be captured are messages sent by people with this characteristic, which is not likely unless their email client allows them to designate this value. Usually the message priority presented by the email client goes into the Priority field.
Other notes: | None

Sample:

Received: from boomerang.com (scooby.boomerang.com [199.242.204.20])
by miami.boomerang.com (8.8.7/8.8.8) with SMTP id SAA11726
for <info@acme.com>; Tue, 25 Aug 1998 18:07:35 -0700 (PDT)
Date: Tue, 25 Aug 1998 18:07:35 -0700 (PDT)
Message-Id: <199808260107.SAA11726@miami.boomerang.com>
To: info@acme.com
From: alan_fernandez@zd.com
Reply-To: alan_fernandez@zd.com
X-Sender: concierge@boomerang.com
BoomerangID: E9VG0124
Precedence: bulk
Subject: Subject: Are you leading the transition to IP based networking?

Networks are in transition.

Enterprise managers are faced with major issues as they
:
:
:

Return to Overview


Received domain

Searches through the "Received" header lines (which records every mail relay traversed by the message) to determine if domain name is in the BANNED-SENDER-DOMAIN list.

Reject if: the message was handled by a host whose domain name is found in Praetor's BANNED-SENDER-DOMAIN list.

Return to Overview


Sending spam samples to CMS

Microsoft Outlook users have the ability to see the actual Internet message headers. This is done by selecting the View-Options from the main menu.

Normally Outlook will strip out these original Internet headers when forwarding the spam sample to CMS. So, please select, copy, and paste these headers into the forwarded message so that we may examine them and suggest some useful criteria for additional filters.


Item Types

Type | Hex | Decimal
ITEMTYP_UNKNOWN | 0x00000001 | 1
ITEMTYP_NODATA | 0x00000002 | 2
ITEMTYP_CONTINUE | 0x00000004 | 4
ITEMTYP_MAILFROM | 0x00000008 | 8
ITEMTYP_RCPTO | 0x00000010 | 16
ITEMTYP_REPLYTO | 0x00000020 | 32
ITEMTYP_RECEIVED | 0x00000040 | 64
ITEMTYP_MESSAGEID | 0x00000080 | 128
ITEMTYP_FROM | 0x00000100 | 256
ITEMTYP_TO | 0x00000200 | 512
ITEMTYP_CC | 0x00000400 | 1024
ITEMTYP_BCC | 0x00000800 | 2048
ITEMTYP_DATE | 0x00001000 | 4096
ITEMTYP_SUBJECT | 0x00002000 | 8192
ITEMTYP_CONTENTTYPE | 0x00004000 | 16384
ITEMTYP_MIMEVERSION | 0x00008000 | 32768
ITEMTYP_SENDER | 0x00010000 | 65536
ITEMTYP_PRECEDENCE | 0x00020000 | 131072
ITEMTYP_LISTFIELD | 0x00040000 | 262144
ITEMTYP_XFIELD | 0x00080000 | 524288
ITEMTYP_BODYTEXT | 0x00100000 | 1048576
ITEMTYP_MIME | 0x00200000 | 2097152
ITEMTYP_MIMEBODY | 0x00400000 | 4194304
ITEMTYP_MIMEEPILOGUE | 0x00800000 | 8388608
ITEMTYP_UUSEGMENT | 0x01000000 | 16777216

Compound Item Types

      Type

Hex

Decimal

      ITEMTYP_821 =
      ITEMTYP_MAILFROM
      | ITEMTYP_RCPTO

0x18

24

      ITEMTYP_822 =
      ITEMTYP_TO
      | ITEMTYP_CC
      | ITEMTYP_FROM
      | ITEMTYP_RECEIVED
      | ITEMTYP_DATE
      | ITEMTYP_SUBJECT
      | ITEMTYP_MIMEVERSION
      | ITEMTYP_CONTENTTYPE
      | ITEMTYP_MESSAGEID
      | ITEMTYP_SENDER
      | ITEMTYP_LISTFIELD
      | ITEMTYP_XFIELD

0xDF7C0

915392

      ITEMTYP_ANY

0xFFFFFFFF

      ITEMTYP_TOCC =
      ITEMTYP_TO
      | ITEMTYP_CC

0x600

1536

      ITEMTYP_ATTACHMENT =
      ITEMTYP_MIME
      | ITEMTYP_UUSEGMENT

0x1200000

18874368

      ITEMTYP_ALLADDRESSES =
      ITEMTYP_MAILFROM
      | ITEMTYP_RCPTO
      | ITEMTYP_REPLYTO
      | ITEMTYP_FROM
      | ITEMTYP_TO
      | ITEMTYP_CC
      | ITEMTYP_BCC
      | ITEMTYP_SENDER

0x10F38

69432


Search Flags

Searching is specified by 3 levels where the types within each level is mutually exclusive:

Level 1 | Level 2 | Level 3
Normal | Case/No-case sensitive | Substring
CSV |  | Full
List |  | Whole-phrase
Elist |  |

Level 1 specifies what type the source string is.

Level 2 & 3 specifies search modifiers.

A search mask is formulated to represent the type of search desired using bit-flags OR'd together:

Bit# | 6 | 5 | 4 | 3 | 2 | 1 | 0
Search Mask |  |  |  |  |  |  |
 | Assume E-List source | Assume List specified | Assume CSV source | Unused | Whole-phrase match | Full-string match | Case-sensitive

Search Type

      Search Type

Hex

Decimal

      SEARCH_DEFAULT

      Default: No case, substring search

0x0000

0

      SEARCH_NOCASE (Level 2 type)

      Default

0x0000

0

      SEARCH_SUBSTRING (Level 3 type)

      Default

0x0000

0

      SEARCH_CASE (Level 2 type)

      Case-sensitive.

0x0001

1

      SEARCH_FULLSTRING (Level 3 type)

      Must match exactly (not substring)

0x0002

2

      SEARCH_WHOLEPHRASE (Level 3 type)

      Whole word/phrase search

0x0004

4

      SEARCH_CSV (Level 1 type)

      Comma-Separated Value string

0x0010

16

      SEARCH_LIST (Level 1 type)

      List name specified

0x0020

32

      SEARCH_ELIST&#9;(Level 1 type)

      Enable-type list where each list entry’s first char can be:
      '0' à Disabled (ignore entry)
      '1' à Enabled (search entry)

0x0040

64

Searching involves 3 components:

  1. What you want to search for (the search key)

  2. Where to search (the source string)

  3. How the comparison should be done (search modifiers)


Section Types

      Type

Hex

Decimal

      SECTION_821

0x00000001

1

      SECTION_822

      822 headers up to start of body

0x00000002

2

      SECTION_BODY

      Includes: all mime segments except text/plain and all uuencoded sections

0x00000004

4


12-1 Host unavailability

Host unavailability

Why does this happen you ask?

From direct experience we have seen that Microsoft Exchange server will sometimes become available under the following conditions. Similar reasons may also cause Lotus Domino's SMTP MTA to behave this way and become unavailable to receive inbound messages from Praetor.

421 temporarily not accepting mail

If the Exchange IMS Transfer mode group box setting has been changed from Inbound & Outbound to another setting like None(flush queues) as found on the Connections tab page of the IMS properties, then IMS will not receive any inbound messages from Praetor. Make certain that the mode is set for Inbound & Outbound which is the normal setting.

Low disk space condition

The Exchange IMS service will shut down if it detects a low disk space condition. It can only start receiving email when sufficient free space (minimum of 10MB) is available. If Exchange is set to archive all your messages, then this setting is likely to induce the low disk space condition.

Microsoft Knowledge Base article Q189587 discusses this in greater detail.

Scheduled maintenance of Exchange/Domino server

During the normal backup process, some sites will shut down their Exchange or Domino server. When this happens, their SMTP receiver will also stop accepting messages, relying on Praetor to queue all inbound messages. Naturally during this period, Praetor will not be able to deliver any inbound messages and a backlog will exist.

Once the SMTP receivers for those servers are returned to operation Praetor can begin to flush the backlog of messages that have been queued for delivery.


14-1 Checkpoint NG FP2 release notes

Checkpoint NG FP2 release notes


Issues with Windows 2000

Praetor on Windows 2000 issues

Here are some common issues when Praetor is installed on a machine with Windows 2000.

  • Wrong SMTP server listening on port 25

  • Spurious error entries in the Windows event log

Wrong SMTP server listening on port 25

When Praetor is installed on Windows 2000 server, incoming messages are rejected with a 550 error:

550 5.7.1 Unable to relay for User@mydomain.com

This still happens even if your local domain is specified in the Praetor Administration program on the Local Domains list.

The reason for this error is that Windows 2000 server natively includes the Microsoft "Simple Mail Transport Protocol" (SMTP) service. By default this mail server is already started and does not allow Praetor to gain exclusive use of port 25. Thus inbound messages are being received by this service rather than the Praetor service. Because the Microsoft SMTP service is not configured to accept mail for your domain you see the message "550 5.7.1 Unable to relay..."

The solution to this problem is to completely disable the Win2K SMTP service and restart Praetor. You can then look in the Praetor Administration program's log viewer to confirm messages are getting to Praetor. Alternatively you can use telnet to connect to the machine on port 25 and verify that you see the following greeting from Praetor:

220 <Your machine name> Microsoft ESMTP MAIL Service, Version: 5...

Spurious error entries in the Windows event log

If you view the System log in the Windows Event Viewer, you may see an "Error" entry such as that shown below. This may not necessarily mean something bad has occurred with Praetor.


08-1 Configuring RBL direct

Configuring Praetor for direct DNSBL queries

Praetor is able to directly accommodate the new RBL arrangement since it separates the normal DNS queries for outbound mail transmission from those made to the RBL DNS server for checking inbound email. For outbound messages to be transmitted, Praetor uses the DNS server IP address(es) that you see listed on the main System tab page of the administration program. For RBL checks, however, Praetor uses the native DNS servers set up for the Windows OS in Control Panel.

If Praetor is to make the query directly to the MAPS DNS server, you will need to have the Praetor machine's IP address registered with MAPS. You will also need to put the MAPS DNS servers' IP addresses in the Control Panel applet for Network, under the properties for the TCP/IP protocol as shown in the above screenshot.

The final setting is on the System tab, within the RBL group box.

Within the text field, make sure you enter the domain name of the RBL DNS server that will be used to construct a proper RBL query.


How to deliver Quarantined Messages

Manual method to deliver quarantined messages

Note:

This information is retained as an FAQ to serve as a tool in learning about message file movement through Praetor. With v1.5, a Log Viewer utility is provided with Praetor that obsoletes this manual method of dealing with quarantined messages.

It is possible to allow for the delivery of messages that may have been quarantined for inappropriate reasons. You may find that some of the rules you are using occasionally end up trapping messages that for some reason or another are acceptable for delivery to the intended recipient. For example, say that a message was quarantined due to a word in the message body text that was banned. You may choose to simply remove the banned word from the message and then have the message delivered. Or, you may choose to remove the banned word and then run it through Praetor's rule processing to see if the message is quarantined/rejected by yet another rule that is defined.

Clearly, you have two options that will enable delivery:

The first option will bypass any further rules processing and simply pass the message to the intended recipient via the Exchange Internet Mail Service. This can be accomplished by simply moving the *.CMS file into the \Praetor\Out directory and re-naming the file to have a *.OUT file extension. The CMS Router Service will then attempt delivery to the intended recipient.

The second option involves editing/changing the message and then having Praetor run it through the rules processing a second time. This can be accomplished by making the necessary changes and then dropping the *.CMS file into the \Praetor\In directory. The CMS Praetor Service will filter the message at the Message Level a second time and either allow delivery or quarantine/reject again due to other characteristics of the message and or the rule settings you have chosen.


Testing 8bitMIME compatibility

Note:

You can easily test for 8bitMIME compatibility of your mail server downstream from Praetor by using telnet to connect to port 25 of the IP address of your mail server. Just issue the "EHLO test.com" greeting and see the capabilities list that are returned in the reply. If your mail server supports this capability, "8bitMIME" will be one of the returned strings. Enter the "QUIT" command to close the telnet session.

As an example, here is the response when connecting to Praetor with its IIS SMTP Server and the default 8bitMIME setting ON.

In contrast, here is the response from the SMTP server found in Exchange v5.5 where you can see the omission of the 8bitMIME capability.