| |
Tech note: Securing Internet Services 7.1
Introduction
There are many issues you may encounter when trying to run server machines connected to the Internet. These issues are a constant threat to the stability and useability of your servers. Defending your servers from Denial of Service (DoS) attacks, viruses, hijacking the server to relay SPAM email, and nuisance email requires a vigilance on the part of every FirstClass administrator. FirstClass Internet Services (IS) has traditionally provided the tools needed to combat these threats. However, with the introduction of Internet Services 7.1 these tools are even more powerful and easier for you to set up and maintain. Before we discuss the specifics of configuring Internet Services, let's look at some general approaches to security that can help you better secure your system's Internet Services.
Physically securing the server machine
The first step in preventing Internet Services abuse is to make sure that unauthorized individuals cannot tamper with the machine on which your Internet Services resides. These abuses include either physically disabling the machine or loading and reconfiguring software in a way that makes it vulnerable to attack. Even though Internet Services stores no data on the server machine's hard drive, thus keeping your data safe, such tampering can still compromise the stability and security of your Internet Services.
Securing the server from network attacks
The next step in preventing Internet Services abuse is at the operating system (OS) level. You should always run your OS vendor's latest security patches to prevent low-level network Denial of Service (DoS) attacks. Next, disable all other network protocols on the Internet Services machine, as any software that accepts network connections is a possible doorway into your system. When Internet Services is running, it should only use those network ports it is configured to serve. File sharing, network logins, network management protocols, and other web servers are all frequently exploited by hackers to gain a foothold on the machine.
Keeping "troublemakers" off your system
If an examination of your system logs reveals that certain IP addresses are testing your security, trying to infect your system with the "Code Red" virus, or "hogging" your system resources, you should consider blocking that IP address. Bad traffic comes from sites with lax security, and these sites are likely going to be the source of inconvenience for some time. It's better to ban them than to let them experiment on your server. Be careful when blocking IPs to be sure that they are not either a site you care about or an IP address handed out temporarily, for example by Dynamic Host Configuration Protocol (DHCP) from a big ISP. There are quite a few good Internet sites that can be used to verify the origin of IP addresses, for example, www.samspade.org.
Clamping down on SMTP relaying
If you don't require SMTP relaying on your machine then don't turn it on. If you need it, turn it on in the most restrictive way possible. Finding an "open relay" is the motherlode for SPAMmers. This is because it "legitimizes" their junk mail by making it appear to be coming from your server and it allows them to use massive delivery lists since it is your bandwidth they are using. SPAMmers are able to do this because many SMTP servers are incorrectly configured, allowing them to "bounce" or relay their SPAM off of a vulnerable system. As a result, efforts to track the real culprits are often thwarted as they move on to use the next unsuspecting system.
If your system is used to relay SPAM email you can expect any, or all, of these things to occur:
- high load on your server as these unwanted messages are processed
- damage to your organization's reputation as questionable material is seen coming from your site
- reduction or denial of your Internet services as ISPs and other Internet organizations begin to recognize you as a SPAMmer.
Remember, unsolicited email uses your precious network bandwidth and server resources to deliver an unwanted, inconvenient, and in many cases offensive experience to your users. Your goal is to try to reject SPAM as early in the process as possible without actually blocking legitimate email.
Security tools available in Internet Services 7.1
As mentioned earlier, Internet Services 7.1 is targeted at making it easier for you to protect your system from abuse. As part of this effort, several of IS's default behaviors have been changed and the UCE/Spam tab on the Basic Internet Setup form has been significantly reworked. All of these changes are intended to make IS more secure "out of the box", to make it easier to stop SPAM from bothering your users, and to make it easier for you to provide "safe" SMTP relaying. Here is a summary of these new and enhanced security tools:
Realtime Blackhole List (RBL) support *NEW*
This feature lets you point IS at an RBL server on the Internet. Whenever SMTP mail arrives, IS will contact this RBL server to see if the sending site is a known source of SPAM. If it is, IS can include a warning header in the message, or reject the message outright.
SMTP AUTH support *NEW*
This feature lets you offer SMTP mail relaying to users who provide their user ID and password when submitting SMTP messages. This provides a simple, and fairly foolproof, way of verifying who is allowed to relay mail on your system. You can configure most POP3 and IMAP4 mail clients
True "No Relay" setting *NEW*
In older IS versions there was a radio button control with a "No Relay" setting. This setting actually meant "relay according to filters". Now, in IS 7.1, there is a a true "No Relay" setting which, when set, prevents your system from being used as an SMTP relay.
Filter documents (SMTP mail rules documents)*ENHANCED*
IS has long supported the idea of filter documents where IP addresses and domain names could be marked as either "trusted" or "bad". This functionality has not changed, but the filter documents have now been further enhanced to allow you to add rules, written in IS Script. These rules can examine the content of incoming SMTP message headers and perform specific actions. These actions include NDNs and injecting additional headers in the message stream. Possible applications of these rules include:
- SPAM scoring
- obscenity checking
- SPAM rejection
- implementing custom JUNK marking rules
- workflow applications.
This feature is especially powerful when combined with the new FirstClass server's mail rules, also available in the 7.1 release. Our goal is to take all of the built in SPAM rules from Internet Services 7.0 and convert them into a rules document that can then be modified by you to suit your system's needs.
NNTP crossposting limits (no functional changes)
This feature lets you reject NNTP messages that are posted to too many alternate newsgroups.
IP connection rejecting (no functional changes)
This feature lets you reject all IP connections from "troublesome" sites.
Reverse DNS lookup (no functional changes)
This feature lets you reject SMTP mail from untraceable sites.
Configuring the new UCE/Spam tab on the Basic Internet Setup form
The UCE/Spam tab form is now divided into three sections: Relaying
 Preventing unwanted access
The primary tool to help control unwanted access to your system is "Reject connections based on Filters".
 This option is implemented at the lowest layer of IS's TCP listener code and simply blocks IP addresses from connecting to your IS on any protocol if they are listed in your Filter documents. Any connections from listed addresses are refused immediately, using the least possible processing power and system resources. This makes IP blocking especially useful for ridding yourself of "troublemaker" machines on the Internet, whether they are trying to hack into your system or deny service to your users. If you already have a hardware firewall, then by all means use it to protect your IS machine, since it offloads the effort to a dedicated resource. But for quick blocking of a troublesome address or for sites that don't run a firewall, this is a good option.
To configure your system to block out unwanted access, all you have to do is:
1) Select "Reject connections based on Filters".
2) Open the Filters folder located in the Internet Services folder on the administrator's Desktop.
3) Create a FirstClass document in your Filters folder listing the addresses you want to block.
For ease of use, we recommend naming the document something like "Blocked IPs" and listing
4) Open the IS monitor form, located in the Internet Services folder on the administrator's Desktop.
5) Do a "Get Config" (or restart IS).
If you need to block any new IP addresses in the future, all you have to do is open this document and add the new IP address or mask. Remember to do either a "Get Config" or restart IS after any additions to your document.
IP blocking syntax in your Filters document
IP blocking lines take one of two forms, either a single IP address per line, or an IP "mask" which can block groups of similar IP addresses. Here is an example Blocked IPs document:
# This is the Blocked IPs document containing the IP addresses we do not want connecting to our system
111.222.111.222 # blocks this IP address 111.222.111.222
111.*.*.* # a mask - this blocks every IP address that starts with 111.
# Note - 111.* is not a valid shorthand for 111.*.*.*.
Preventing unauthorized mail relaying
SMTP mail relaying occurs when your IS receives a piece of email via SMTP that is not destined for a user on your FirstClass system. In this case, IS accepts the message and then passes it on, via SMTP, to another SMTP server somewhere on the Internet. There are two types of scenarios where you may need this type of setup:
- if your IS acts as the Internet contact point for a group of SMTP servers
- if you need to support POP3 or IMAP4 users on your system who send mail outside of your organization.
In IS 7.1 (and later), there are three basic relaying setups:
Your site does not need to relay
If your site does not have one of the two requirements listed above, then you can simply check the "Disable ALL relaying, including SMTP AUTH and trusted IPs" option on the Basic Internet Setup form - UCE/Spam tab.
 After you have checked this option, open the IS monitor form and do a "Get Config" or restart IS.
This setup is easy to administer and extremely secure, and your system allows absolutely no SMTP relaying.
Your site needs to relay for POP3 or IMAP4 users
If you need to support POP3 and IMAP4 users who send mail outside of your organization, then we recommend using SMTP AUTH, which is an extension to the SMTP protocol. This extension means that if a server wants to relay mail off of your SMTP server, then it must provide "credentials" (user ID and password authentication) so that you know it is not a SPAMmer. Unless you've explicitly disabled relaying (as in the first configuration) then IS will do SMTP relaying for those that supply credentials. Since this might be a bit "loose" (especially for sites that support autoregistration), IS allows you to configure which FirstClass features an account must have in order to relay, which you enable on the Basic Internet Setup form - UCE/Spam tab:
 This form lets you limit SMTP relaying to users who you have already entrusted with other "powerful" FirstClass features. After you have checked the features that your relaying users must have to relay off your system, open the IS monitor form and do a Get Config or restart IS. Now your system allows SMTP relaying but only for authenticated users who are enabled with specific FirstClass features.
Your site needs to act as the Internet contact point for a group of SMTP servers.
If your site is in this situation you may find, due to the SMTP server software in use, that SMTP AUTH cannot be used by the hosts you need to support. For this reason, (and for reasons of legacy support) you can configure IS to use "trusted" IP addresses. The idea here is that a document in the IS Filters folder contains a list of "trusted" IP addresses and, for these addresses only, IS will perform SMTP relaying.
This setup is pretty secure (since IP spoofing is pretty tough) but does require a fair amount of effort on your part if you have a large number of "trusted" addresses you need to add to your filter document. Be careful when creating your filter document as a mistake, such as entering the wrong IP address or worse, the wrong IP mask, can open you up to being used as a SPAM relay.
To configure a trusted IP relaying setup:
1) Open the Filters folder in the Internet Services folder on the administrator's Desktop.
2) Create a FirstClass document in your Filters folder listing the "trusted" IP addresses.
For efficiency, we recommend naming your filter document something like "Trusted IPs" and using the document only for "trusted" IP addresses. Other filter
3) Close the document.
4) Open the IS monitor form and do a "Get Config" or restart IS.
You can update your document whenever necessary but always remember to do a Get Config or restart IS to activate the new entries.
"Trusted" IP entries take one of two forms: a single IP address (prefixed with a '+') per line, or an IP "mask" (again, prefixed with a '+') which can trust groups of similar IP addresses. Here is an example Trusted IPs document:
# This is the Trusted IPs document containing the IP addresses we are willing to relay for
+111.222.111.222 # trusts this IP address 111.222.111.222
+111.*.*.* # a mask - this trusts every IP address that starts with 111.
It should be noted that "trusted" IP addresses override blocked IP addresses. If you need to block a group of IP addresses but trust a single IP within, you could do so as follows:
# Blocking a group, while trusting one of them
111.*.*.* # a mask - this blocks every IP address that starts with 111. ...
+111.222.111.222 # ...except for this one! This line trusts this IP address (111.222.111.222) even though it's IP neighbors are bad guys
What if I get "blacklisted" as an open relay?
Because of the proliferation of SPAM and the difficulty in combatting it, there are a number of organizations (including RBL suppliers) who aggressively identify open relay sites and add them to their blacklists. If your site is blacklisted, there are two steps you should perform:
1) Check your relay settings!
You probably got blacklisted because SPAM came from your site. Lock things down using the methods outlined in "Preventing unauthorized mail relaying" and try to isolate the problem. If you can't locate the problem, contact the blocking organization and ask for help.
2) Ask the blocking organization to retest your site after you've located and fixed your relaying problem.
If you follow the directions above you can make your site "relay-proof" and you will pass any well-written relay test. There are some organizations (ORBS being one) that use flawed relay tests that assume your mail host is "sendmail" and will behave like it in testing. If you have relaying clamped down and you still fail their test you have a few options:
- Reconfigure IS to act more like sendmail. The main issue with these tests is that IS absorbs some attempts to relay as if it might be delivering the message, when, in fact, it later delivers an NDN. Since the tests do not wait for the NDN, they are "fooled" into thinking the relay worked. By setting "Aliases only" on the Advanced Directory form, located in the Internet Services folder on the administrator's Desktop, you force IS to reject these efforts as they come in:
 Keep in mind, using this tactic comes at the expense of your need
- Inform the blocking organization that you are not relaying, and prove it to them by having them try to relay off your site to some destination account. The better organizations may respond reasonably to this sort of approach.
- Convince the sites you care about exchanging email with not to use their "flawed" service.
Reducing SPAM
Our approach to controlling SPAM has always been two-pronged: to provide the tools to reject SPAM deliveries and to mark suspicious messages. In Internet Services 7.1 this approach continues, but with more powerful features in both areas. Since these features provide "layers" of protection, we'll describe them in order from the outer layer and work inward to your Mailbox:
Filtering
As a first line of defense, you can add IP masks, IP addresses, domain names, and email addresses to FirstClass filter documents. Email will not be accepted from any sites or addresses listed in these blocking lists. Unlike pre-7.1 IS's, in 7.1 and higher, this feature is enabled automatically. To configure address filtering:
1) Open the Filters folder in the Internet Services folder on the administrator's Desktop.
2) Create a FirstClass document listing the addresses to block.
For efficiency we recommend naming the document something like "Blocked Addresses" and listing in it only the email addresses and domains you wish to block. Other Filters documents can contain blocked addresses, but if you keep them separated like this, it is easier to administer them.
3) Close the document.
4) Open the IS monitor form and do a "Get Config" or restart IS.
You can update your document whenever necessary but always remember to do a Get Config or restart IS to activate the new entries.
The format of the blocking list conforms to that used in various Internet anti-SPAM sites, with one entry per line and domains optionally prefixed with an '@', for example:
# This is a comment line
111.*.*.* # a mask - this blocks mail from every SMTP server who's IP address starts with 111.
123.123.123.123 # an IP block, the SMTP server at 123.123.123.123 cannot deliver mail to us
@spamdomain.com # a domain block, any server that declares itself part of spamdomain.com or any
# user@spamdomain.com cannot deliver mail to us
spamdomain2.com # same as above, slightly different syntax
jill1717@hotmail.com # this particular address appearing in either the SMTP MAIL FROM or RFC-822 From:
# header causes mail to be rejected
Reverse DNS lookup
This feature causes IS to take the IP address of any SMTP server that connects to it and query the configured DNS for an associated domain name. If no domain name is found, IS refuses mail from that server. Since this option relies on querying the DNS server on each inbound SMTP connection, make sure your DNS server(s) is functioning well in order to maintain good performance.
You enable this feature on the Basic Internet Setup-UCE/SPAM tab by selecting the option:
 RBL (Realtime Blackhole List) lookup
This feature causes IS to take the IP address of any SMTP server that connects to it and query the configured RBL host(s) to see if the IP address is a known source of SPAM email. If it is, IS either refuses mail from that server or optionally tags it with an additional Internet header for later processing by the rules system. In general, the reduction in incoming SPAM more than pays for the additional latency of connecting to the RBL host in processing each connection. However, there may be a slight increase in the number of active SMTP inbound connections with this feature turned on. To enable this feature:
1) Open the Basic Internet Setup form UCE/Spam tab.
2) Select "Reject based on RBL host(s)".
 3) Fill in the domain name(s) of the RBL host(s) you want to use.
 4) Enter text in the "Help text".
This field should contain the text you want rejected senders to see in their NDN's, for example,"Your site has been declared a source of SPAM email by myRBLhost.com, please contact them for further information."
 5) Close the form.
If you don't want to reject sites that fail the RBL lookup, you can optionally insert a warning header into the incoming SMTP message instead. To do this, just check the "X-RBL-Warning header instead of NDN" box.
 When operating in this mode, the contents of the "Help text" field are inserted as the data portion of the "X-RBL-Warning" header in the offending message. In this case, you should replace the "Help text" with something that identifies the RBL site that triggered the header, and is easy to parse. By doing this, you will make it easier for end users to write FirstClass server mail rules to process these messages.
NNTP crossposting limit
This feature lets you filter excessively crossposted traffic from any NNTP feeds you are bringing into FirstClass. Crossposting in NNTP newsgroups is considered poor form and is often an indicator that a message is junk mail of some kind. To set a limit, check "NNTP crossposting limit" on the Basic Internet Setup form UCE/Spam tab. We suggest you set a minimum of "10" as your as your limit.
 SMTP mail rules
In IS 7.1, we've introduced a new feature to IS: SMTP mail rules. The idea of this new feature, is that there are new files in the Filters folder distinguished from the normal filter documents by their names, which must start with "rules.". These files provide a scripting and configuration system that allows you to customize your IS's handling of potential junk mail arriving via SMTP. Let's take a look at this new functionality by describing each new file's name and usage:
rules.AttachmentBlock
This file lets you block certain attachment types from arriving via SMTP. When an attachment matches the criteria setup in this file, it is replaced by a text attachment, the content of which also comes out of this file. An example rules.AttachmentBlock file is:
# This file contains a list of unacceptable file name/file type and creator patterns, one per line.
# It also contains some 'helpful' text that replaces the attachment.
#
# The help text is one or more lines that start with a colon.
# The attachment names are case-insensitive, and use the DOS wildcard convention
# of * and ?
# Macintosh file type and creator patterns can be specified as well,
# using the syntax 'TTTT:CCCC' where TTTT is the file type, and CCCC
# is the creator. Use ? as a wildcard character.
#
# The \@ in the help text will be replaced by the file name which triggered the blocking
#
:This message contained an attachment named \@ that has been discarded
:because it's name or type is considered dangerous or unacceptable by the
:Administrator.
#
# block all executable (Windows) types
*.exe
*.scr
*.com
# Macintosh support - standard Mac executables
'APPL:????'
rules.SubjectBlock
This file contains a list of objectionable words and phrases that are compared against the contents of the RFC-822 Subject header using a built in facility of the rules system. The rules document (see below) that ships with IS contains a rule for comparing the content of the Subject header against these words. The format of the file is simple: one word or phrase per line and no comments allowed. An example rules.SubjectBlock is:
Viagra
Hot teen
ADV:
rules.MailRules
This file contains a series of lines that represent RFC-822 headers to examine, a test on the header, and an action to perform if the test succeeds. IS ships with a default rules.MailRules document that provides these features:
- replaces all formerly built-in IS SPAM handling rules
- injects an X-SPAM-Warning Internet header that rates the message as one of: HIGH, MEDIUM, LOW
- injects an X-SPAM-Level header that provides a numeric indication of SPAMiness
- injects an X-SPAM-Tests header that shows which SPAM "tests" this message failed
- controls rules by variables set at the top of the rules file
- controls handling by rules at the bottom of the file
- implements various SMTP crossposting and BCC limits.
The syntax of the mail rules document is based on a combination of IS Script and the HeaderMatch document, and is designed to be comfortable for administrators familiar with these Internet Services facilities. The expression part of IS Script, in turn, is based loosely on C and JavaScript. The mail rules component gives access to the RFC 822 headers as they are being received, and lets you set attributes of the message, change or discard the header, add a new header, or discard or NDN the message. There is also a facility for comparing the words in a header (typically the Subject) against a list of objectionable words and phrases.
Mail rules can be designated to run before any headers are received, when specific headers are received, as each header is received, or when the end of the header indicator is reached. Comments may be placed in the file, and must begin with the # character. Built-in variables give mail rules access to information about the message being processed, but they must be used carefully or misleading or incorrect results will occur, for example, using $#To before the To: header has been received will return zero.
Syntax of the rules.MailRules file:
<header> ":" 1*<sp> <condition> 1*<sp> <action>
where:
<header> ::= '*' means any/all header
::= '^' means before any headers
::= '' (empty) means end of headers
::= <RFC822 header name> (e.g. From)
<sp> ::= ASCII SPACE or TAB
<condition> ::= ["NOT" 1*<sp>] <">simple expression<"> // supports * and ?, case insensitive
::= ["NOT" 1*<sp>] "regexp:" <">complex expression<"> // full regular expression, including tagged groups for replacement
::= "IF" *<sp> "(" <expression> ")"
<expression> ::= ["("] <term> [<relational> <expression>] [")"]
<term> ::= [<not>] <lhs> [<conditional> <rhs>]
<relational> ::= <and> | <or>
<conditional> ::= "==" "!=" "|" "&" "~=" <lt> <gt> <le> <ge>
<action> ::= <set> *[1*<sp> AND 1*<sp> <set>]
::= "SPAM" // shorthand for SET $priority=junk AND $machinegenerated=1
::= "DISCARDMESSAGE"
::= "DISCARDHEADER"
::= "DONE" // stop processing rules for this message
::= "INJECT" <"><header>":" <value><"> (can include replacement groups, e.g. \1, \2)
::= "REPLACE" <"><header>":" <value><"> (can include replacement groups, e.g. \1, \2)
::= "NDN" <errcode> [1*<sp> <string>] // implies DONE
<set> ::= "SET" 1*<sp> <variable> *<sp> "=" *<sp> <value> *[ 1*<sp> "AND" 1*<sp> <variable> *<sp> "=" *<sp> <value> ]
<not> ::= "NOT" | "!"
<and> ::= "AND" | "&&"
<or> ::= "OR" | "||"
<gt> ::= "GT" | ">"
<lt> ::= "LT" | "<"
<ge> ::= "GE" | ">="
<le> ::= "LE" | "<="
<variable> ::= "$" <builtin> or 1<alpha>*<alphanum_>
@inblocklist(<string> or <variable>[, <case>]) // <case> is "yes", "no", "true", "false"
// default is "yes"
@seenheader(<string> or <variable>)
@istrustedip(<string> or <variable>)
@istrustedaddress(<string> or <variable>)
@isspamip(<string> or <variable>)
@isspamaddress(<string> or <variable>)
@islocaladdress(<string> or <variable>)
// the following behave as in IS script statements
@split(...)
@substr(...)
@length(...)
@indexof(...)
@upper(...)
@lower(...)
@rand()
// built in variables
// Name Values Readonly/Readwrite
$MachineGenerated "1", "0" Readwrite
$Priority "Normal", "Urgent", "Bulk", "Junk" Readwrite
$IsNewsArticle "1", "0" Readonly
$IsSpammer "1", "0" Readwrite
$MessageID <contents of Message-ID header> Readonly
$Subject <contents of subject header> Readwrite
$From <contents of From: header> Readonly
$Sender <contents of MAIL FROM:> Readonly
$#To <number of To: recipients> Readonly
$#Cc <number of Cc: recipients> Readonly
$#BCC <number of BCC recipients> Readonly
$HaveReplyTo "1", "0" Readonly
$HaveResentReplyTo "1", "0" Readonly
$SenderIP <IP address of sending SMTP host> Readonly
$MyIP <IP address of this host> Readonly
$Authenticated "1", "0" Readonly
$AuthCanRelay "1", "0" Readonly
Example rules.MailRules file:
# initialize variables
^: if (1) SET $lowspam=25 AND $medspam=50 AND $highspam=75
^: if (1) SET $xpostlimit=25
# rules to set SPAM level
Subject: if (@inblocklist($subject)) SET $spamlevel += 75 AND $spamtests += "SUBJECTBLOCK;"
Subject: " " SET $spamlevel += 85 AND $spamtests += "SUBJ_HAS_SPACES;"
Errors-To: "*" SET $spamlevel -= 20
From: regexp:".*<.*[0-9]+@.+>.*" SET $spamlevel += 25 AND $spamtests += "FROM_ENDS_IN_NUMS;"
Message-ID: not "@" SET $spamlevel += 33 AND $spamtests += "INVALID_MSGID;"
Message-ID: regexp:"^<.+\@>$" SET $spamlevel += 33 AND $spamtests += "INVALID_MSGID_2;"
X-Mailer: "Extractor" SET $spamlevel += 75 AND $spamtests += "X-MAILER;"
X-Mailer: "Floodgate" SET $spamlevel += 75 AND $spamtests += "X-MAILER;"
X-Mailer: "Group Mail" SET $spamlevel += 75 AND $spamtests += "X-MAILER;"
X-Mailer: "Millennium Mailer" SET $spamlevel += 75 AND $spamtests += "X-MAILER;"
X-Mailer: "AutoMail" SET $spamlevel += 75 AND $spamtests += "X-MAILER;"
: IF ($#BCC > 0 && ($#To + $#Cc) == 0) SET $spamlevel += 75 AND $spamtests += "NO_RECIPIENTS;"
#: IF (NOT @seenheader("Subject")) SET $spamlevel += 50 AND $spamtests += "NO_SUBJECT;"
#: IF (NOT @seenheader("Date")) SET $spamlevel += 50 AND $spamtests += "NO_DATE;"
#: IF (NOT @seenheader("Message-ID")) SET $spamlevel += 50 AND $spamtests += "NO_MESSAGE_ID;"
# crosspost limiting rule
:IF (($#BCC + $#To + $#Cc) > $xpostlimit) SET $spamlevel += 75 AND $spamtests += "CROSSPOST_EXCEEDED;"
#rules to deal with SPAM level
: IF ($spamlevel >= $highspam) NDN 550 "Sorry, your message has triggered a SPAM block, please contact the postmaster"
: IF ($medspam <= $spamlevel && $spamlevel < $highspam) INJECT "X-SPAM-Warning: HIGH"
: IF ($lowspam <= $spamlevel && $spamlevel < $medspam) INJECT "X-SPAM-Warning: MEDIUM"
: IF (0 < $spamlevel && $spamlevel < $lowspam) INJECT "X-SPAM-Warning: LOW"
: IF ($spamlevel > 0) INJECT "X-SPAM-Level: $spamlevel"
: IF ($spamlevel > 0) INJECT "X-SPAM-Tests: $spamtests"
: if ($spamlevel > 0) INJECT "X-FC-Icon-ID: 2"
FirstClass server mail rules
Any FirstClass user with the appropriate privilege can now program their own mail rules for their mailbox and any conferences they own. All messages that make it through the various IS-SPAM blocking facilities will now be tagged with 'X-SPAM-xxxx' headers. Users can test these headers using their own mail rules, allowing users to file or discard messages they believe are SPAM. Here is an example of a personal rule:
  Creating these types of rules empowers your users with the ability to prevent SPAM from arriving in their Mailbox while taking advantage of the system rules created by you, the administrator.
SPAM Logging
Whenever the Internet Services UCE/SPAM rules take effect and block a message from arriving in a user's Mailbox, an entry is added to your server statistics file:
Spam 27 10/22/2001 12:27:54 PM localhost 127.0.0.1 terry@127.0.0.1 Sender Extra
^ ^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | | - extra information **
| | | | | | | - reason code *
| | | | | | - email address
| | | | | - IP address
| | | | - host name
| | | - time
| | - date
| - FC user ID
- Stat keyword - for these entries, always "Spam"
* reason code is one of: MailRule, Sender, RBL, ReverseDNS, Host, RelayReject***
** extra info will contain: 1) for MailRule type - any NDN text sent
2) for RelayReject type - the address being relayed
*** RelayReject is not logged when all relaying is disabled
Document History
Version 0.1 - original
Version 0.2 - Form updates & D.M. changes
Version 1.0 - A.S. edits and some touch ups
Version 1.1 - J.G. edits and more A.S. edits
Version 1.2 - T.W. edits to the wording just before the ABNF syntax description
Tech note: Proper setting of SMTP relay options for FC 7 and earlier
Unsolicited email (SPAM) is a big problem on the Internet. The people who generate this unwanted traffic are able to do so because many SMTP servers are incorrectly configured to allow them to "bounce" or relay this SPAM email off of their system. As a result, efforts to track the real culprits are often thwarted as they move on to use the next unsuspecting system.
If your system is used to relay SPAM email you can expect any of the following things to occur:
1) high load on your server as these unwanted messages are processed
2) damage to your organization's reputation as questionable material is seen emanating from your site
3) reduction or denial of your Internet services as ISP's and other Internet organizations begin to recognize you as a spammer
Internet Services (IS) provides many features to help you keep your site from being part of the problem. These features are controlled using the adman form located on your Adman Desktop->Internet Services folder->Basic Internet Setup form->UCE/Spam tab. The first set of relay options take the form of a radio button group labeled "SMTP message relay" which work as follows:
1) Do not relay messages - an excellent choice, this prevents all message relaying except in cases where "trusted" IP addresses override it (see below). If you do not relay mail for other mail servers (i.e. act as the Internet contact point for a group of internal SMTP servers) or need to support POP3 users sending mail outside of your organization, then you should choose this option without reading any further. This may still be the right option for you, even if you do want to do some relaying, but the setups get a little more complex.
2) Relay messages from domains served by this system - this option will allow relaying to occur, but only for messages from people who's domain name is server by this system. This choice is not highly secure, since Spammers can lie about who they are during the SMTP conversation, but this can be effective when used in combination with the "Reject based on domain name" check box (see below).
3) Relay all messages - this is a very dangerous choice, and should only be used by servers that are secure within the firewall of their own organization.
There are also 2 check box fields on this form (in the Filtering section) that can also affect mail relaying. The first is "Reject based on junk mail list". This option activates the files in the Admin Desktop->Internet Services->Filters folder, which can be used to specify email addresses, domain names, and IP addresses or masks that should be explicitly treated as either Spammers or "trusted" addresses (see below). The second option is called "Reject based on domain name" and it causes IS to reject all mail from sites who's IP address cannot be resolved to a domain name.
Since the Filters folder plays an important role in all of this, it needs to be described here. The Filters folder (inside the Internet Services folder on the admin desktop) can contain an arbitrary number of text files (either FC documents or uploaded text files) of arbitrary name. At IS startup time these are used to create a table of SPAM addresses/domain names/email addresses as well as a table of "trusted" addresses/domain names/email addresses. The file(s) can contain the following types of entries:
# a comment
111.222.333.444 # blocks this IP address
111.*.*.* # blocks every IP address in this mask
spamdomain.com # blocks this domain
user1@piratedomain.com # blocks this email address
+111.111.111.111 # makes this address trusted, email from here will not be marked as junk or rejected, relaying allowed
+happyplace.com # makes this domain trusted, email will not be marked as junk, no relaying effect (only IP masks have this effect)
+ goodguy@spamdomain.com # overrides earlier spamdomain.com block, just for this address, no relaying effect
There are a lot of ways you can combine these features to set up a host that is secure from unauthorized relaying, but I'll give 3 examples that should work for most sites:
Method 1 is easy and foolproof: 1) check "Do not relay messages" 2) done. This method will work for everyone that doesn't need to relay mail, which is actually a large number of FirstClass sites.
Method 2 is easy and provides a slight but real risk of some SPAM getting through: 1) choose "Relay messages from domains served by this system" 2) tick "Reject based on domain name" 3) Set DBG_SMTPCon = 1 (use IS menus or config/inetsvcs.cf file). This method allows you to relay pretty safely. The only case that it will let through is the site which claims to be your domain and can be reverse DNS looked up to another domain name. If this does happen, your IS console log will contain entries that read "spammer.com claims to be this domain.com". Using these entries you can contact the ISP of the Spammer and have them punished. For the most part, those who are trying to use your site for unsolicited relaying will not have a "reverse DNS-able" IP address and will be rejected.
Method 3 is a bit of work and foolproof:1) check "Do not relay messages" 2) tick "Reject based on junk mail list" 3) add the IP masks of your local POP3 users (and/or any SMTP's you want to relay for) in one of the SPAM filter files as trusted IP addresses. This will allow only those users at the IP addresses specified to relay from your site, which will stop all unauthorized relaying through your system.
As you can see, IS has many options to help you secure your site from being used as a SPAM relay site. For your own good, as well as that of the Internet, we encourage you to use these options to secure mail relaying at your site.
If you would like to see additional features by the author of this article, click here.
|