There are two strategies typically used in filtering unwanted mail. There is the brute-force approach that eliminates all mail incoming from certain domains know to host spam. This filtering eliminates mail from specific domain names and/or IP blocks from certain ISPs. The lists generated are huge, very difficult to keep up to date, and quite slow to process. While not ruling out their use in the future, the Sambar Server does not presently support this form of filtering.

The second approach, implemented in the Sambar Server, is to filter mail that contain characteristics that distingiush it from "regular" mail. The spam filters are fairly aggressive and are comprised of three elements:

• Built-in filtering rules.
• External rules-based (regular expression) header filtering.
• Whitelist rules (regular expressions) that over-ride overly aggressive built-in and external rules.

In the near future, a third approach, user whitelists will be available for a more sophisticated filtering mechanism.

Built-in Filtering
If spam filtering is enabled, the first routing rules enforced are the built-in rules that perform the following tests:

• Message does not contain a From: line.
• Message does not contain a To: line.
• Message contain "Apparently-To:" in the header lines.
• SMTP server has flagged the message as spam (see SMTP SPAM Check below).

SMTP Spam Check
If enabled, the SMTP server will flag mail as spam if the message meets any of the following tests:

• IP address of sender has an invalid inverse DNS.
• Sender failed to specify a syntatically valid domain name in HELO/EHLO.
• Domain name specified in HELO/EHLO is not resolvable via DNS.
• Sender supplies a MAIL FROM whose domain part is not DNS resolvable (A record or an MX record).
• The message matches any rule in the mail/mbox/spam.flt file (if present), and does not match any rule in the mail/mbox/whitelist.flt file (if present).

The SPAM Check flag can only be enabled if the MTA is enabled on the server. In addition, to run properly, the DNS Primary and Secondary must be configured so that MX and DNS lookups function properly.

Important! Identifying mail as SPAM that comes from clients whose inverse DNS cannot be resolved can result in blocking large numbers of mail servers simply because the inverse DNS is not properly configured (or configured at all in many cases).

External Rules
The mail/mbox/spam.flt file (if present) is used to identify spam using regex pattern matching (Note: the pattern matching rules differ from the pattern matching wildcarding used in routing rules. Traditional regex pattern matching is used to allow the use of anti-spam rules from other mail systems.) The default rules specified are common filters used by several systems to block known spamming products. Both the mail/mbox/spam.flt and mail/mbox/whitelist.flt files are cached at startup by the mail server. The following is a sample mail/mbox/spam.flt rules file:

# The famous 'Comments: Authenticated sender' line
#
Comments?: Authenticated send.?
# cyberpromo
#
cyberpr.?
savetrees.?
^Message-Id:.Mach.10
^X-Mailer:.*(Aristotle Mail|WorldMerge|Extractor Pro|Floodgate Pro|Emailer Platinum.*Internet Marketing)
^X-Advertise?ment:.*
^Message-Id:.*>.*>
^Received:.*(-(0600|6000|0400) \(EST\)|-0700 \(EDT\))
^Received:.*\<with .*\<with\>
^Received:.*000\.000\.000\.000
^X-Sender:.*Yourdora
# look for empty message IDs
#
^Message-Id: *<[^@]*>
# some added insurance against cyberpromo sneaking through
#
^(Received|X-).*\<cyberpromo\>
^(Received|X).*\<infowatch\.net\>
^X-Distribution:.*(bulk|mass|moderate)
# too many $$$ on the subject is probably spam
#
^Subject.*\$\$
^Subject.*FREE
^X.*(cyberp|Cyber-Bomber|cybertize-email.com)
^X-PMFLAGS
^Message-ID: <>
^X.*(iemmc.org|name removal)
^Message-ID:( +|     +)<.* (.*)?>
one.time(.only)? (mailing|message)|reply.*remove|(e-?)?mail.*remove
relay.comanche.denmark
^To:.Friend@public.com
name=.*\.(scr|vbs|shs|bat|com|exe|pif|ocx|wsf|chm|vbe|hta)

Because of the variety of spam subjects, Subject header parsing is difficult to filter on. Basic filtering on money, free, $$ and a few other common subject lines are provided in the default list, but Subject filters will tend to only catch a few messages.

In addition to the mail/mbox/spam.flt file, the granularity of checking can be restricted to just the mail header or mail body. To accomodate this more restrictive checking, the presense of the mail/mbox/header.flt and/or mail/mbox/body.flt can be used to trigger this checking (along with configuration changes.) Important! The header and body spam filtering is not as effective as the "standard" spam.flt as they require the content be separated properly. To efficiently process the content, this cannot always be guaranteed.

Whitelist Rules
The mail/mbox/whitelist.flt file (if present) is used to identify mail that should not be blocked by the spam filter. This file is only evaluated if the message has been flagged as spam. Important! There is a built-in rule that flags mail as "whitelist" messages if the mail is From a user in the Local Domain; the assumption is that anti-spam message relaying is enabled and, hopefully, Require AUTH is enabled. This file is cached at startup by the mail server.

#
# The following whitelist rule allows all mail from "bar.com" 
# to pass regardless of the spam filtering.
#
^From:.*@bar.com

Blocking Unwanted Attachments
Many viruses come in through malicious attachments. The following routing rules demonstrate how to automatically delete mail with attachments that can carry viruses:

delete "" CASEI body *name=*.exe*
delete "" CASEI body *file:*.exe*
delete "" CASEI body *name=*.com*
delete "" CASEI body *file:*.com*
delete "" CASEI body *name=*.scr*
delete "" CASEI body *file:*.scr*
delete "" CASEI body *name=*.pif*
delete "" CASEI body *file:*.pif*
delete "" CASEI body *name=*.bat*
delete "" CASEI body *file:*.bat*
delete "" CASEI body *name=*.vbs*
delete "" CASEI body *file:*.vbs*
delete "" CASEI body *name=*readme.eml*
delete "" CASEI body *file:*readme.eml*

Note: If the SPAM Check SMTP rule is enabled, these checks are automatically enabled and result in mail being moved into the user's spam folder.

SPAM Check vs. Global Routing Rules
There are a few differences between the SPAM Check funcitonality and blocking unwanted spam using Global Routing Rules:

• The SPAM Check SMTP filter happens in "real-time" at the SMTP server.
• If you do not want to 'reject' the mail outright you can move the mail to the the recipient's SPAM folder.
• The routing.flt functions when the user opens their inbox.new mailbox and operates much later in the process than the real-time SMTP SPAM Check. In addition, global routing rules only operate on the first 2K of the mail message body whereas the SPAM Check spam filter operates on the entire body of the message.
• The mail/mbox/spam.flt SPAM rules are only loaded once at server startup, whereas the global routing rules are loaded for the delivery of each mail message.

The strategy recommended is to reject spam at the SMTP server via the SPAM Check, but keep the mail/mbox/spam.flt rules tuned to anti-virus checking (such as mail attachments). Then use the mail/mbox/routing.flt rules for more fine-grained, realtime blocking of new threats.

DNS Black List
The Sambar Server supports the use of one or more DNS black list servers for identifying SPAM senders. DNS black list lookups attempt to determine if a mail server is likely sending spam. This is done by taking the IP address of the sender, reverse it, and query a DNS zone to come up with something like "2.0.0.127.relays.example.com". If the mail server is listed in the spam database you queried, it will return an answer indicating it believes the server to be a spammer and the mail message can be rejected, deleted or placed in the recipients 'spam' folder via the Spam Check option selected.