<ip> is the IP address of the sending MTA.
<lastused> is the time the sender last sent mail.
Entries can be manually added to this file with a <lastused> time of 0,
indicating they should persist indefinitely.
Mail Spam Filtering
The Sambar Mail Server includes an anti-spam/anti-virus filter that can
be enabled on a per-mailbox basis or across all mailboxes. The filter
is enabled or disabled using the global SPAM Check SMTP rule or via
Webmail Routing Rules interface
(users need not use WebMail for reading their mail, but do to
access the SPAM folder.)
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,
mail/mbox/header.flt or mail/mbox/body.flt files (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).
SMTP Reject Rules
The SMTP server will reject any mail (immediately) if the mail message
matches a rule found in the mail/mbox/reject.flt (if this file
exists). This check overrides any authentication, whitelist or anti-spam
checks and immediately terminates a message that matches a regex rule
found in the reject.flt file. This functionality is designed to reject
mail containing viruses as soon as they are discovered.
Having a lot of dirt being thrown at our domain I started playing with
the various .flt filter options.
By way of example, Ron Hartendorp noted that some spammers were addressing
email to users with exactly 15 lowercase characters in front of his domain
name, e.g.
To: <lpkaxxwaroshunv@*************.nl>
These spammers were blocked with the following reject.flt rule:
^T(O|o).*\<([a-z]{15})\@yourmaildomain.com\>
The only time this filter will kill valid mails is if you have a user
mail address with exactly 15 characters only (without numbers, dots, dashes
or underscores). In your smtp.log, rejections are logged as:
[2006-03-17 15:08:47] FAILED [32343536] [217.98.71.16] [DATA] [325 B] ... {BAD-MAIL identified by reject rule ^T(O|o).*\<([a-z]{15})\@*************.nl\>}
Another example is to block mail from an entire domain. For example, some
users are overwhelmed by spam with a From address of verizon.net. To reject
all mail from this domain, you could add the reject.flt rule:
^From.*verizon.net
External Rules
The mail/mbox/spam.flt, mail/mbox/reject.flt,
mail/mbox/header.flt and mail/mbox/body.flt files
(if present) are 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.
The mail/mbox/spam.flt, mail/mbox/reject.flt,
mail/mbox/header.flt, mail/mbox/body.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.)
Use of the header.flt file rather than the spam.flt file
will significantly reduce the CPU load on the server because less of the
content has to be scanned with the pattern matching software. When there
are many rules in the spam.flt file, the CPU load can be significant
when processing files with large attachments.
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.
In addition, a local DNS blacklist (mail/dnsbl.dbx) file can be
configured that is searched at the time the remote mail server connects
to the SMTP server. This feature operates just like the [smtpdeny] list
in the config/security.ini except that the file is read dynamically
so other processes can append IP address to this file. Lastly, if
the build DNSBL spam option is enabled, all mail servers who are added
to the block list for invalid requests (i.e. too many invalid addresses) are
automatically added to this file as well.
HTML Email
A growing number of spammers are sending HTML formatted email messages.
HTML email messages are a terrible idea for a couple reasons, the most
significant being that HTML messages are often used to stage cross-site
scripting attacks. To eliminate, or at least mark as spam, all
HTML email messages, you can use a "global routing rule" to "delete"
mail with "headers/body" which "contains" "Content-Type: text/html".
Thanks to Dave Culbertson for providing this tip.