OITC's
|
|
|
|
OITC's rules data base has been built to attempt to help mail admins manage and select the contextual filtering rules appropriate to there own facility.
The Rules Set Data Base for Simple Text Filter version 1.2 and below are presently available online in a database at Common Ground Softworks or downloadable in Excel format with expanded information at OITC's EIMS Information Area. If you cannot support Excel and do not wish to use the online database, please contact us at STFRules@oitc.com
The data base is organized first by worksheet tabs.
This area holds our current selection for preferences and macros. We recommend that you update all macros to meet your local needs. Also update your selection of Simple Text Filer's preferences. Please note the highlighted areas change depending upon prefs or macros. You should copy in two steps to eliminate the problem of an ending \t\r instead of a \r
This area holds a portion of our current set of whitelisted addresses. Depending upon your selection of rules, rule types and confidence you may or may not need a number of these entries. The key entries are EIMS and STF lists as well as your own contact address (we use as postmaster [RFC2821/4.5.1] and abuse [RFC2142]). The reason that the whitelist is larger than I would have normally liked is that there are a number of mass mailers (Type: EmailMarket) that don't care where their addresses come from or who accept contracts from unethical people.
This area holds a portion of our DNS Filter Exclusions whitelist. Depending upon your selection of rules, rule types and confidence you may or may not need a number of these entries. The key entries are Spamcop, EIMS and STF lists.
This area holds our current set of anti-virus rules. These rules protect you from the major viruses and worms for the PC, *nix, and Mac. It stops virus such as Nimda, Sircam, BadTrans, Snow White, Happy99, etc. The way the database is currently configured is to bouce all PC executable attachments with an error message to resend after "zipping" or contact the postmaster. This is the safest setting on the virus rules and we recommend that you seriously think about your risk before changing or eliminating these virus rules.
This area holds our current set of anti-spam rules dealing with an email's format. This includes detection of invalid header information, improper scripts, spamware, undotted quads, languages, etc. It also includes some of the larger, longer lived spam houses like Monsterhut and Instant Empires. A more detailed explanation of these rules can be found below. This is part of our original area labled SPAM
This area holds our current set of anti-spam rules dealing with an email's content. This includes mass bulk email, gambling, financial scams, removes, fake justifications, redirectors, email marketing companies, free emails and hosts associated with spam, drugs, get-rich-quick and pyramid schemes, and just plain spam. It also includes some identified IP blocks that are not filters by DNSbl systems. A more detailed explaination of these rules can be found below. This is part of our original area labled SPAM
This area holds our current set of anti-spam rules that seem to be good for 30 - 45 days. These rules focus on From and Return-Path email addresses primarily but do factor in other such as content rules where the ISP is reasonably quick is terminating spamvertised sites. These are typically throwaway but seem to last about 30 days or a little over in spams being sent before they are retired.
This area holds our current set of anti-spam rules dealing with an email's last IP. These IP blocks have been reported via spamcop; their owners' either don't care or their email bounces; they fail open relays checks but continue to send spam. When an IP block meets this criteria, it is added to this rule set. Some of your might want to convert many of these STF rules to router or firewall rules. However, one must also consider that IP block will eventually change, esp. from a spamhaus, and the reject message we use with STF allows new IP owners to resolve the block.
©2001-2002 by OITC. All rights Reserved, USA and Worldwide