 |
| |
Handling spam
There are individuals or sites that may try to deliver spam to your system on a consistent basis. Since this may pose a threat to you by clogging up your system with unwanted mail, FirstClass has tools that you can use to manage this problem.
Using filter documents and the Internet Services Filters folder
Filtering unwanted IP addresses and domain names is one of the most important steps you can take to fight spam and abuse. You do this by using and creating filter documents in the Filters folder, located inside the Internet Services folder on the administrator’s Desktop. If you wish to use filter documents to block addresses, you must enable "Reject connections based on Filters" on the Connections tab.
 Warning Enabling the "Reject connections based on Filters" option blocks all connections to Internet Services, not only SMTP connections.
This folder holds filter documents (and rules documents) that can contain exact IP addresses, IP masks (groups of similar IP addresses), mail addresses, and domain names from individuals or sites you wish to trust or block, as well as protocols. Coupled with enabling the "Reject connections based on Filters" on the Connections tab on the Basic Internet Setup form's UCE/Spam tab, this is FirstClass's primary feature to help control unwanted spam on your system.
You can update your filter documents whenever necessary.
The Filters folder overrides any other site configuration. For example, if you have enabled RBL lookups on your site and your RBL service finds an IP address trying to connect to your system on their "bad" list, Internet Services will accept the connection if you've placed that address in your Filters folder as a trusted site.
Alternately, if you've blocked a site in your filter document the connection is 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.
Below are examples of the proper syntax to use in your filter documents.
Syntax for blocked IP addresses, domain names, email addresses, protocols
You can create filter documents in either FirstClass format or as simple text files and upload them to the folder. The format of a filter document conforms to that used in various Internet anti-spam sites, with one entry per line and domains optionally prefixed with an @. In all cases, begin your comments with #. Here are some examples of the proper filter
syntax:
• 123.123.123.123
#This blocks mail from 123.123.123.123.
• 123.123.12.*
#This subrange blocks mail from every SMTP server whose IP address starts with 123.123.12
• 111.*.*.*
#This mask blocks mail from every SMTP server whose IP address starts with 111.
• 123.123.12.123/130
#This range blocks IP addresses from 123.123.12.123, 123.123.12.124, .... 113.123.12.130.
• 123.123.12.123 - 123.123.12.130
#The same block as the previous example but in a different format.
• @spamdomain.com
#This domain block refuses mail from any server that declares itself part of the spamdomain.com domain or any user@spamdomain.com.
• spamdomain2.com
#The same as above with slightly different syntax.
#This email block refuses any email from this address if it appears in either the SMTP MAIL FROM or RFC-822 From: header.
• *.badplace.com
#This wildcard allows you to block any subdomain of badplace.com. This format is the same format used in the rules.SubjectBlock document.
• regexp:[bB][pP][0-9*\badplace\.com
# This blocks any subdomain of badplace.com that starts with "bp" or "BP" and has zero or more digits (for example, bp.badplace.com, bp1.badplace.com, bp12345.badplace.com, and so on)
• pop3,imap:192.168.123.234
#This blocks only pop3 and imap connections from 192.168.123.234.
Syntax for trusted IP addresses, domain names, email addresses, and protocols
You can make an IP address or domain name trusted by placing a "+" sign in front. If you have the address trusted, Internet Services will not apply any mail rules to the message. Trusted IP addresses override blocked IP addresses. If you need to block a group of IP addresses but trust a single IP address within the range, make sure
you trust that particular IP address or domain name.
Trusted IP entries take one of two forms: a single IP address per line or an IP mask:
• +111.222.111.222
# This trusts mail from 111.222.111.222.
• +111.*.*.*
# This mask trusts every IP address that starts with 111.
• +*.goodplace.com
# This trusts any subdomain of goodplace.com or user@goodplace.com.
• +smtp:192.168.123.123
#This trusts only smtp connections from 192.168.123.123.
Customizing built-in mail rules
Along with the filter documents, the Filters folder contains these rules files: rules.MailRules, rules.AttachmentBlock, and rules.SubjectBlock files. You can use these files to control and manage SPAM and junk mail, delete or block unwanted attachments, and stop messages containing illegal phrases or words. For an indepth discussion about these files, see the Working with SMTP mail rules section of the Internet Services online help, starting with About SMTP mail rules.
AttentionThe rules.MailRules file is a heavily coded document and may be confusing to understand at first. We highly recommend that you become familiar with this document and specifically read the included commented lines before you customize the Mail Rules subtab or change any values in the rules.MailRules file.
The rules.MailRules file examines the content of incoming SMTP message headers and performs specific actions to score and reject spam deliveries and mark suspicious messages (see Understanding spam scoring).
You can control how the rules.MailRules scores spam by setting specific parameters on the Mail Rules subtab on the UCE/SPAM tab. By default, the rules.MailRules file contains code that picks up the values set on this tab and performs an appropriate action in response to the set values and how you've configured the rest of the tab.
Doing RBL/SURBL lookups on SMTP connections
You can query the IP address of any SMTP server that connects to your site using a Realtime Blocklists (RBL) service and Spam URI Realtime Blocklists (SURBL), to see if the IP is a known source of spam mail.
RBL lists check to see who is connecting to your server. A RBL service compiles lists of IP addresses responsible for spam and from sites whose servers are hijacked for spam relay.
SURBL lists check the domain names inside of messages sent to your server. If a spamming domain is detected, the shipping rule.MailRules document adds 101 to the spam score and SPAM_LINK to the spam tests. Internet Services caches both RBL and SURBL lookups to reduce the load on your system. SURBL is especially useful, if you have a front end on your system. If you enable services, you should not notice a significant amount of extra load on your system.
These services inform you of bad and questionable IP addresses during the SMTP connection phase and let you deal with them as you see fit, using the available Internet Services options.
Choosing the right services for you
There are many RBL services from which to choose. Some are better than others and most have different degrees of aggressiveness, specialization, and cost. Before you enable RBL, you need to do some legwork to decide which services best suit your organization's needs. Many RBL services also offer SURBL lookups.
We can't recommend one service over another, but we do recommend taking a look at these web sites for a comparative analysis of different RBL hosts:
This site compares different blacklist services and suggests a few used by the author.
This site provides lists of blacklist services that specialize in blocking different kinds of spam and open relays.
We also recommend choosing two or three services, as no one service lists all the potential "bad guys" on the web.
Although only you can determine which setup is best for your site and your users, here are a few thoughts to keep in mind:
• use a RBL service that is good at identifying the source of the SPAM that you receive
• keep an eye on the RBL section of the Internet Monitor (see below)
• replace RBL services that don't seem to detect much SPAM
• educate your users on how to create useful personal mail rules.
Enabling RBL/SURBL on your site
After you've chosen your services, configuring the RBL feature is easy.
 Note Any IP addresses or domains that you have trusted in a filter document always overrides anything you've enabled in your RBL options. This means that if an incoming IP address is identified as a spammer by one of your RBL services but you've also listed it as trusted in a filter document, Internet Services will still pass it to the server for processing.
To enable RBL/SURBL:
1 Select "Enable RBL lookups" or "Enable SURBL lookups" on the RBL subtab on the Basic Internet Setup form.
We recommend enabling both options. Internet Services caches lookups to reduce the load on yoru system.
2 Fill in the domain names of the RBL/SURBL hosts you want to use.
3 Type in your preferred text in "NDN text".
This field should contain the text you want rejected senders to see in their NDNs. For example, "You have been tagged by our RBL service. Message not delivered. Please contact myRBLhost.com for further information."
 In this configuration, if an incoming IP address is found on a service's RBL list (and it is not listed as trusted in one of your filter documents), Internet Services will refuse the message from that server. Since the listed RBL services are checked in order from top to bottom, as soon as an address is found on a list the checking stops. For example, if a message passes the first entry (rbl.spamcop.org) but is tagged by the second entry (sbl.spamhaus.org) no further checking is done.
The reduction in incoming spam makes up for the additional load on your server of having to connect 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 enabled. To further help reduce the load on your system, Internet Services has a built-in feature that caches RBL lookups, which eliminates the need for repeated lookups.
What if I don't want to reject a sender immediately?
If you don't want to reject sites that fail the RBL lookup, you can insert a warning header into the incoming message instead. To do this, select "X-RBL-Warning header instead of NDN" on the RBL subtab on the Basic Internet Setup form:
 NoteIf you use this header option, you still need to select "Enable RBL lookups" on the RBL subtab on the Basic Internet Setup form.
If you select this option, the contents of "NDN text" are inserted as the data portion of the "X-RBL-Warning" header in the offending message. In this case, you should replace the "NDN text" with something that identifies the RBL site that triggered the header and is easy to parse. This will make it easier for your users to write FirstClass server mail rules to process these messages. Also, if a user is unfamiliar with a sender who's been identified as possibly "bad", and doesn't want to continue to receive mail from them, you have the option of rejecting the IP address in your filter documents.
If you go with this option, your users must choose the View > Show Internet Header option from the FirstClass menu to see if a message has been tagged in their incoming mail.
This is part of the Internet header of a message:
 In what order should I list my RBL services?
The order in which you list your RBL services depends on the type of spam your site normally receives. If the majority of your spam is from a particular type of spammer (for example, medical or financial) you should choose a couple of good RBL services that specialize in identifying these perpetrators and place these services first and second on the RBL list. You can then place a service that specializes in other types of spam (or even a more generic type of service) to catch any remaining spam that hits your site.
If you want to reject (NDN) all tagged connections, use an aggressive RBL service. This guarantees that Internet Services will not pass spammers to the server. However, you also run the risk of NDNing legitimate messages. This is a very strict setup but, if your site is getting spammed to death, it may be necessary. If you are concerned about being overly aggressive, you can choose a more forgiving service.
Remember, the earlier a RBL service identifies a spammer the less work for your system. For example, if your first service does not tag a message, Internet Services goes to the next available service entered in the list. This uses more resources and may slow down your system. Whereas, if your first service identifies a message as spam, Internet Services stops the hunt chain and no more work needs to be done.
If you choose to inject the X-RBL-Warning header instead of automatically rejecting a connection, ordering the RBL services from least aggressive to most aggressive puts a choice into the hands of your users. They can set personal mail rules to handle mail tagged by the RBL services to sort through manually at a later time in containers other than their Mailboxes.
Only you can determine which setup is best for your site and your users. A good approach is to
• use a RBL service that is good at identifying the source of the SPAM that you receive
• keep an eye on the RBL section of the Internet Monitor
• replace RBL servers that don't seem to detect much SPAM.
How and where do I track RBL activity on my system?
You can track your RBL activity and make decisions based on this information using the Security tab on the Internet Monitor, located in the Internet Services container on the administrator's Desktop.
 The information displayed in this section of the form lets you know:
• which RBL services are active
• how many times the services have been accessed
• how many addresses the services have detected on their lists
• the percentage of lookups to identified addresses (this indicates the effectiveness of your RBL services)
• the number of times a service did not respond to a lookup
• average response time of a lookup
• longest response time of a lookup.
The Off buttons let you temporarily disable lookups on the RBL service without having to permanently remove them from the Basic Internet Setup form. This is useful for testing purposes or if one of your RBL services is under a DoS attack. The Reset button will reset your RBL statistics.
What if I get blacklisted as an open relay?
Because of the proliferation of spam and the difficulty in stopping it, there are a number of organizations (including RBL suppliers) who aggressively identify open relay sites and add them to their lists. If your site is blacklisted, do the following:
1 Check your relay settings (Internet Services and user privileges).
You probably got blacklisted because spam came from your site. Lock things down using the methods outlined in this section 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.
3 Check the trusted IP addresses in your filter documents.
There are some organizations, for example ORBS, that use flawed relay tests that assume your mail host is "sendmail". If you have configured your system correctly and you still fail their test you should try these options:
• reconfigure Internet Services to act more like sendmail
The main issue with these tests is that Internet Services 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 choosing Aliases only at "Inbound mail addressing" on the Advanced Directory form, you force Internet Services to reject these efforts as they come in:
 Using this option comes at the expense of your need to manually configure aliases (or set up automatic aliasing) for your Internet mail users on the Advanced Directory form.
• 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.
Querying incoming IP addresses of SMTP servers
You can query (reverse DNS lookup) the IP address of any connecting SMTP server that tries to connect to your site for an associated domain name. If no domain name is found, Internet Services refuses mail from that server. To select this feature, choose "Reject unknown domain names" on the Junk subtab on the Basic Internet Setup form.
 Since this task relies on querying the DNS server on each inbound SMTP connection, you may find that it puts an extra load on your system. Make sure your DNS server (see The role of the Domain Name Server) is functioning well in order to maintain good performance.
| ||