GroupWise SpamJunk Mail Solutions | Novell GroupWise 7 Administrator Solutions Guide

GroupWise Spam/Junk Mail Solutions

The following are actions you can take in GroupWise in an effort to control spam and junk mail. Let's cover the GWIA-based solutions first:

Reject the mail if the sender's identity cannot be verified
Protect against mail bombs
Implement access control
Utilize blacklists

In terms of client-based solutions, you can also implement a junk-mail handling procedure within GroupWise.

Implementing GWIA-Based Spam Solutions

The following sections cover features of the GWIA that can be used to combat spam.

Reject Mail If Sender's Identity Cannot Be Verified

In the SMTP protocol, an SMTP host that is trying to transmit to another SMTP host identifies itself with a DNS name. Spammers' SMTP hosts often identify themselves incorrectly or do not identify themselves at all.

The GWIA can be configured to test the identity of an SMTP host. This configuration setting is called Reject Mail If Sender's Identity Cannot Be Verified. This configuration feature is available on the Security Settings property page under the SMTP/MIME tab on the GWIA gateway.

What actually happens is that whenever your GWIA is prompted for a connection with another SMTP server, it reads the IP number of this other server. The GWIA then accesses the DNS to do a reverse address lookup, using the IP address to find the hostname for this other server. The GWIA then compares this information with the hostname as presented in the session and rejects the connection if these names don't match.

There is a downside to this setting, however. Many legitimate SMTP hosts on the Internet will not identify themselves or at least will not identify themselves correctly. This is a common issue with many SMTP hosts on the Internet. So if you enable this feature, be prepared for the fact that you might reject legitimate mail.

Mailbomb Protection

Mailbomb Protection is another setting on the GWIA's Security Settings property page. This setting is generally a safe setting to implement. Mailbombs are generally different from spam. The nature of a mailbomb is that SMTP HostA contacts SMTP HostB and sends messages to HostB in rapid succession. Generally, the goal of a mailbomb is for HostA (the mailbomber) to overpower HostB, causing the SMTP HostB to be overwhelmed by the volume of mail, and perhaps crash because of the volume. Most spammers are not trying to make SMTP hosts crash, so they do not use mailbomb techniques.

Access Control

The features available under the Access Control tab are the most effective tools you have in GroupWise to curtail spammers. The most important feature is called Prevent Message Relaying, as shown in Figure 25.1.

Figure 25.1. The Prevent Message Relaying feature on the GWIA

Spammers are constantly searching the Internet for SMTP hosts that will allow the spammer to relay its messages. Relaying is a part of the SMTP protocol that allows HostA to relay a message it wants to get to HostC through HostB. HostB then sends the message to HostC. If you were to allow message relaying, your GWIA could be used like HostB in this example. The impact to you might be that other SMTP hosts on the Internet might identify your host as a spamming host. Because of this, your SMTP host might become blacklisted. (Blacklists are discussed later in this chapter, but in short, being on a blacklist means that many other SMTP hosts on the Internet will not receive messages from your site.)

The GWIA will allow POP3 or IMAP4 users to relay through the GWIA, if they have already authenticated to the GWIA for a POP/IMAP session, prior to trying to relay off of the GWIA. If you have POP3/IMAP4 users, this kind of relaying is fine. It requires that a client that wants to relay through your GWIA have a mailbox within your system, and be authenticated to that mailbox, in order for the GWIA to allow the client to relay. It's important that your users configure their POP3/IMAP4 clients to authenticate before trying to relay. For example, in a popular POP3 client such as Microsoft Outlook Express, this is what you must do to enable authentication before relaying messages:

Select Tools, Accounts.
Highlight the Server definition/connection that represents the GWIA.
Click the Properties button.
From the Properties page, click the Servers tab.
Select the option My Server Requires Authentication.

These steps force Outlook Express to authenticate via the POP3 or IMAP4 credentials that the user has provided, each time the users tell their Outlook client to relay off of the GWIA.

You might have other devices in your organization that need to relay off of your GWIA but are not sophisticated enough to authenticate. For these scenarios, it is often best to set up a special-purpose GWIA within your firewall. This GWIA can send messages out on the Internet, but no hosts on the Internet can contact this GWIA. This GWIA would be configured to Allow Message Relaying. With this type of a configuration, only hosts on your intranet would be able to relay off of the special-purpose GWIA.

Creating Blacklists

TheGroupWise GWIA supports the use of blacklists or RBLs (realtime blacklists). There are a couple of kinds of blacklists. Those relevant to the subject of spam are spam blacklists and open relay blacklists (relaying was covered earlier in this chapter). Blacklists are lists compiled by hosts on the Internet that indicate which DNS addresses and IP addresses have SMTP hosts that are or could be used as spamming hosts on the Internet. Here is an explanation of how the GWIA utilizes RBLs:

HostA on the Internet contacts the GWIA and asks for an SMTP session.
The GWIA determines the IP address of HostA.
The GWIA queries its own DNS server for the reversed IP address of the sender appended to the blacklist server's DNS name. For example, if your GWIA was configured to use the blacklist server of BL.SPAMCOP.NET and if the IP address of HostA were 134.55.65.213, the DNS query would look like this:
```
213.65.55.134.bl.spamcop.net
```

If the DNS system does not return a response to the request for the reversed IP address, that indicates to the GWIA that the address is not on that specific blacklist.

If a response for the DNS request is returned, the GWIA knows that the host has been blacklisted.

What's clever about this architecture is that it does not require any special configuration of your local DNS server. This makes RBL checking compatible with virtually any DNS system.

To enable blacklists on your GWIA, you must go to the Blacklists property page under the Access Control tab of the GWIA object in ConsoleOne. Click the Add button, and add the correct host for a blacklistfor example, BL.SPAMCOP.NET, as shown in Figure 25.2.

Figure 25.2. A configured RBL

You can configure your own blacklist entries and "whitelist" entries if need be. On the Access Control tab on the GWIA object, if you select the Settings property page, you can edit the Default Class of Service profile. When you do so, there are two entry areasone is titled Allow Messages From and the other is titled Prevent Messages From. In this area you can indicate Internet domains that you do not want messages from. In the example shown in Figure 25.3, the GWIA has been configured to reject messages from the Internet domains named spamrus.com and micromonopolysoft.com. The bob@deals.com domain cannot send messages, and the SMTP host at 131.107.3.124 cannot send into the GWIA.

Figure 25.3. Configuring custom blacklists and whitelists

The Internet host acme.com was blacklisted by SPAMCOP accidentally. ACME is in the process of getting itself off the blacklist, and in the meantime the WorldWide Widgets administrator added acme.com to the whitelistwhich is the Allow Messages From field. This allows the GWIA to accept messages from acme.com even though it's blacklisted at the moment.

An important thing to note here is that you can override entries that your RBL hosts are saying should be blacklisted. You do this by creating an entry for the Internet domain in the Allow Messages From box.

Our Experience with Blacklists

RBL filters are easy to configure and can be part of your spam solution. However, in our own testing in a live customer environment, only about 1 in every 800 spam messages was caught by the spam RBL that we configured, which was caught via DNS queries to bl.spamcop.net. We had a spam solution in place that scanned for words that meant the message was spam after the messages came into the GWIA. Although the GWIA was doing RBL lookups on the messages, the GWIA in conjunction with SPAMCOP was able to detect only a small fraction of the messages that were spam. One thing to note, however, is that you can subscribe to multiple RBL servers. You will need to do your own research to determine which RBL services work the best for you. There are also free RBL services, as well as subscription RBL services available for use.

Implementing Client/Mailbox-Based Spam Solutions

The capability for users to filter unwanted mail within their mailbox is built into the GroupWise client. It's called the "Junk Mail" folder, not the spam folder. For the sake of this discussion, let's classify two kinds of unwanted mailspam and junk mail. Spammers send spam mail, and they generally do so from random bogus Internet email addresses and/or Internet domains. It's generally useless for users to use the junk mail feature in the GroupWise client in an effort to prevent these kinds of messages. They will never get a message from that spammer again, with the same email address or Internet domain. If GroupWise users do use the junk mail feature in GroupWise on spam messages, they are really creating more processing overhead on the POA for no good reason. The cumulative effect of hundreds of users on a large post office using the junk mail feature with hundreds (maybe thousands) of junk mail filters in each user database will drag the POA down over time.

Junk mail is a different kind of a message. Junk mail is when you go to a store, such as Sears, and you give them your email address. Suddenly you start getting weekly mail messages from Sears. With the junk mail feature you can identify weeklyoffers@sears.com as a user whose messages you consider junk mail. This is the kind of scenario that best fits the junk mail feature in the GroupWise client.

You can control the junk mail feature from ConsoleOne, and perhaps even take the feature away from users. We are of the personal opinion that you should not enable this feature for users unless you have implemented a solution at your SMTP entry point or even at the domain or post-office level that first filters out spam. We already established that spammers rarely use the same identity. So if you have not implemented a spam solution prior to the messages getting to the user's mailbox, don't allow them to flag the spam using the junk mail feature. Perhaps the feature will make the user feel good, but in general this feature does not do anything for spam mail; but it does drag down the POA needlessly. The junk mail feature should be used for junk mail, not for spam.

To disable the junk mail feature, you can do the following:

1.	In ConsoleOne, highlight a GroupWise domain.
2.	Select Tools, GroupWise Utilities, Client Options.
3.	Select Environment and uncheck the Enable Junk Mail Handling setting.
4.	Click the padlock to the right of this setting, which will make this setting apply to all post offices under the domain.
5.	Perform this action on all domains in your GroupWise system.

Figure 25.4 shows junk mail handling disabled.

Figure 25.4. Disabling junk mail handling is done through Client Options in ConsoleOne

After you have implemented a server-based spam solution, whether it is SMTP-based or domain- or post office-based, and you are comfortable that the spam solution is filtering out about 95% of your spam, only then should you enable the junk mail handling feature.

It is important to note that junk mail handling is an option only for mail that comes in through your GWIA. Users are not able to "junk" mail that they receive from internal sources. The way that the POA knows whether the mail came through the GWIA is if the view name on the message is Internet. There might be a few customers out there who have changed the view name for inbound Internet messages. You can find out what the view name is for your inbound Internet messages by looking in the GWIA.CFG file for your inbound GWIA(s). Look for the section that says

/MailView-Internet

If your /MailView- switch says something other than Internet, users will not be able to use the junk mailing feature at the client.

So how does the POA process junk mail? The POA will perform several checks on the message to determine whether it matches settings that the user defined through junk mail handling. The POA uses the following algorithm to determine whether a particular Internet message should be junked or blocked based on the user's junk mail settings:

The POA looks for the sender's UserID to determine whether it's on the junk list or block list. If this field is not found, the POA will combine the sender's UserID field with the sender's Internet domain field and check both of these for a match.
Next, it examines the FROM_TEXT field and looks up that address in the junk or block lists.
If no matches are found, the POA continues by looking for the domain name in the junk and block lists.
The POA checks the contents of the sender's Internet domain field against the spam lists. It also checks shorter versions of the domain name by trimming off the left portions of the name and trying each shortened name until there are only two segments left in the name.

For example, if the IDOMAIN was pinball.games.microsoft.com, the spam checker would first search for pinball.games.microsoft.com, and then for games.microsoft.com, followed by microsoft.com.

The spam checker tries to be fairly robust, checking all the versions of the address it can get its hands on.

You should be aware that there are limitations to the Junk, Block, and Trust lists that are integral with junk mail handling. None of the lists can have more than 1,000 addresses. So you can have up to 1,000 addresses in the Junk List, 1,000 addresses in the Block List, and 1,000 addresses in the Trust List. Furthermore, there is another limit. Of the 1,000 addresses in any of the three lists mentioned, no more than 500 Internet domains can be represented in a list.

Using X-Spam Headers with the Junk Mail Folder

The GroupWise 7 GWIA can be configured to act on X-spam headers. As such, if a message has an X-spam header that matches the X-spam headers that you define on the GWIA, the message will be routed to the recipient's Junk Mail folder. Here's how X-spam headers work:

A message comes in from the Internet to a spam-enabled appliance or solution.
The spam solution determines that the item is spam, and adds an X-spam header to the received SMTP message; for example: X-SPAM:YES.
The spam solution sends the message into the GWIA.
The GWIA reads the X-spam header, and compares the syntax of the header with the X-spam header examples in its xspam.cfg file.
Assuming that the syntax of the X-spam header matches the syntax with a line in the xspam.cfg file, the GWIA flags the message as a Junk Mail item.
When the message is delivered to the recipient's post office, the message is automatically moved to the recipient's Junk Mail folder.

The whole X-spam solution requires that you have some other solution in place that will flag a message as X-spam. The GWIA has no logic that enables it to determine that a message is actually spam. Some other entity must add the X-spam header. GWAVA 3.x has X-spam logic, and other solutions also exist.

To configure the GWIA's X-spam features, you edit the GWIA object in ConsoleOne and add X-spam header lines from the Junk Mail page. This will create the xspam.cfg file in the domain\wpgate\gwia directory. Each line of the xspam.cfg file identifies an "X" header field that your antispam service is writing to the MIME header, along with the values that flag the message as spam. The Internet Agent examines the MIME header for any field listed in the xspam.cfg file. When a match occurs, the message is marked for handling by the GroupWise client junk mail handling feature. The configuration option in ConsoleOne is shown in Figure 25.5.

Figure 25.5. Defining the X-spam headers that the GWIA should look for