Configuring Filtering and Controlling Spam

 

Controlling spam is a challenge, but there are some methods that you can use to reduce spam:

  • Use Exchange 2003 filtering features.   Microsoft® Exchange Server 2003 offers connection filtering, recipient filtering, and sender filtering to reduce the amount of spam that is sent to users in your organization.

  • Educate your users not to respond to or forward spam.   Instruct your users not to click any "remove" links included in the mail because the links are often used to verify addresses.

In Exchange Server 2003, you can configure and enable filtering on your SMTP virtual servers to restrict access to the virtual server. Filtering is configured in Exchange System Manager under Global Settings in Message Delivery Properties. Although you configure filtering at the global level, you must enable it on each individual virtual server.

Use filtering to block incoming e-mail messages that are sent to your SMTP virtual server in the following ways:

  • Connection filtering allows you to block messages that are sent to your organization based on the Internet Protocol (IP) address of the connecting SMTP server. You can configure global accept lists for IP addresses from which you always want to accept messages and global deny lists for IP addresses from which you always want to reject messages. You can also subscribe to a third-party block list provider, and verify that the connecting IP address is not on their list of blocked IP addresses.

    Note

    If you want to block a particular IP address from sending to your SMTP virtual servers, you can add these IP addresses by using the Connection button on the Access tab of your SMTP virtual server properties. You should configure these restrictions on your gateway SMTP virtual servers.

  • Recipient filtering allows you to block messages that are sent to a specific recipient address within your organization.

  • Sender filtering allows you to block messages that are sent by a specific sender. If your organization repeatedly receives spam from the same sending addresses, you can choose to block these senders from sending mail to your organization.

Connection Filtering

Exchange Server 2003 supports connection filtering based on block lists. Connection filtering takes advantage of external services that list known sources of spam, dial-up user accounts, and servers that are open for relay (based on IP addresses). Connection filtering complements third-party content filter products. This feature allows you to check an incoming IP address against a block list provider's list for the categories that you want to filter. Furthermore, you can use several connection filters and prioritize the order in which each filter is applied.

With connection filtering, you can also do the following:

  • Configure global accept and deny lists.   A global accept list is a list of IP addresses from which you will always accept mail. A global deny list is a list of IP addresses from which you will always deny mail. You can use global accept and deny lists with or without using a block list service provider.

  • Configure a recipient address as an exception to all connection filtering rules.   When mail is sent to this address, it is automatically accepted, even if the sender appears on a block list.

How Connection-Filtering Rules Work

When you create a connection-filtering rule, SMTP uses the rule to perform a DNS lookup to a list that is provided by a third-party block list service. The connection filter matches each incoming IP address against the IP addresses on the third-party block list. The block list provider issues one of two responses:

  • host not found   Indicates that the IP address is not present on its block list.

  • **127.0.0.**x   A response status code indicating that a match for the IP address was found in the list of offenders. The x value can vary, depending on your block list provider.

If the incoming IP address is found on the block list, SMTP returns a 5.x.x error in response to the RCPT TO command (The RCPT TO command is the SMTP command that the connecting server issues to identify the intended message recipient.)

You can customize the response that is returned to the sender. Additionally, because block list providers usually contain different offender categories, you can specify the matches that you want to reject. Most block list providers screen for three types of offenders:

  • Sources of spam   These lists are generated by scanning unsolicited commercial e-mail messages and adding the source address to the list.

  • Known open relay servers   These lists are created by identifying open relay SMTP servers on the Internet. The most common reason for an open relay server is a configuration mistake by the system administrator.

  • Dial-up user lists   These lists are created from either existing Internet service provider (ISP) lists that contain IP addresses with dial-up access, or from the inspection of addresses that indicate a probable dial-up connection.

How Block List Providers Match Offending IP Addresses

After you set up your connection filter, when an e-mail message is sent to your organization, Exchange contacts the block list provider. The provider checks for the existence of an A (host) record in its DNS. Exchange queries for this information in a specific format. For example, if the connecting address is 192.168.5.1, and the block list provider's organization is contoso.org, Exchange queries for the existence of the following record:

<reverse IP address of the connecting server>.<dns name for the block list organization> IN A 127. 0.0.x

which, in this case, is:

1.5.168.192..contoso.org

If this IP address is found on the provider's list, the provider returns a 127.0.0.x status code that indicates an offending IP address and the type of offense. All block list providers return a response code of 127.0.0.x, where x indicates the type of offense. The x value varies, depending on the block list provider.

Understanding Block List Provider Response Codes

As mentioned earlier, if a block list provider finds a match, the provider always returns a status code of 127.0.0.x. The status code is either an explicit return code or a bit mask, which is a multifunctional return code. If your block list provider returns a value, you can specify which values you want to filter against. However, if your block list provider returns a bit mask, you must understand how a bit mask works to specify the matches that you want to filter.

A bit mask is a method that is used for verifying that a particular bit is set for an entry. A bit mask differs from a traditional mask in that it checks for a specific bit value, as opposed to a subnet mask, which checks for a range of values. Consider the following example.

For each match in its block list, assume a block list provider returns the status codes that are listed in the following table.

Examples of block list status codes

Category Returned status code

Known source of spam

127.0.0.3

Dial-up user account

127.0.0.2

Known relay server

127.0.0.4

However, if an IP address is a member of two lists, the block list provider adds the values of the last octet. Therefore, if an IP address is on the list of known relay servers and known sources of spam, the block list provider returns a status code of 127.0.0.7, where 7 is the combined values of the last octet that is returned for the known sources of unsolicited commercial e-mail status code and the known relay servers status code.

If you want to filter against only known sources of unsolicited commercial e-mail, enter a bit mask value of 0.0.0.3; the block list then filters against any of the possible values, in this case, 127.0.0.3, 127.0.0.5, 127.0.0.7, and 127.0.0.9.

The following table lists the bit mask values that are associated with each of the example status codes.

Examples of block list status codes and corresponding bit mask values

Category Returned status code Bit mask value

Known source of spam

127.0.0.3

0.0.0.3

Dial-up user account

127.0.0.2

0.0.0.2

Known relay server

127.0.0.4

0.0.0.4

Known relay server and dial-up user account

127.0.0.6

0.0.0.6

In the last category in this table ("Known relay server and dial-up user account"), the bit mask 0.0.0.6 returns a match for an IP address only if it appears on both the known relay server and dial-up user account lists. It does not return a match if the IP address appears on only one of the two lists. You cannot use a bit mask to check for a single match in multiple lists.

Note

A bit mask checks only against a single value. If you set a bit mask value that is returned when an IP address appears on two lists, the mask matches only IP addresses that appear on both lists. If you want to check for an IP address on either of two lists, enter the status codes for these settings.

Specifying Exceptions to the Connection Filter Rule

You can allow message delivery to specific recipients, regardless of whether they appear on a block list. This exception is useful if you want to allow legitimate organizations to communicate with your administrators by contacting the postmaster account. For example, if a legitimate company has a server inadvertently configured to allow open relaying, e-mail messages from this company to your users would be blocked. However, if you configure connection filtering to allow message delivery to the postmaster account in your organization, the administrator in the blocked company could send mail to your postmaster account to communicate their situation or inquire as to why their mail was rejected.

Enabling Connection Filtering

To enable connection filtering, perform the following steps:

  1. Create the connection filter by using the Connection Filtering tab on the Message Delivery Properties dialog box. For detailed instructions, see How to Create a Recipient Filter.

  2. Apply the filter at the SMTP virtual server level. For detailed instructions, see How to Apply a Recipient Filter to an SMTP Virtual Server.

Each of these steps is detailed in the following sections.

Configuring Connection Filtering

To configure connection filtering, perform the following tasks:

  • Create global accept and deny lists.

  • Create connection filtering rules.

  • Create exceptions to the connection filtering rules.

For detailed instructions about creating global accept lists and global deny lists, see the following topics:

For detailed instructions on creating exceptions to the connection filtering rules, see the following topic:

Applying the Connection Filter to the Appropriate SMTP Virtual Servers

After creating the connection filter and any exceptions for the filter, you must apply it to the appropriate SMTP virtual servers. Usually, you apply the connection filter to the SMTP virtual servers that exist on your gateway servers that accept inbound Internet e-mail messages. Use the following procedure to apply a connection filter to an SMTP virtual server.

For detailed instructions, see How to Apply a Connection Filter to An SMTP Virtual Server.

Recipient Filtering

With recipient filtering, you can filter messages that are sent to nonexistent recipients in your organization, or add specific recipient addresses that are often targeted by senders of spam.

Enabling Recipient Filtering

To enable recipient filtering, perform the following steps:

  1. Create the recipient filter by using the Recipient Filtering tab in the Message Delivery Properties dialog box.

  2. Apply the filter at the SMTP virtual server level.

Each of these steps is detailed in the following sections.

Sender Filtering

Sender filtering functions in the same way in Exchange Server 2003 as it did in Exchange 2000 Server; it allows you to filter messages that are sent by a specific sender. You can block messages that are sent by any users in a domain or by a specific sender.

Enabling Sender Filtering

To enable sender filtering, perform the following steps:

  1. Create the sender filter by using the Sender Filtering tab in the Message Delivery Properties dialog box in Global Settings.

  2. Apply the filter at the SMTP virtual server level.

Understanding How Enabled Filters and IP Restrictions Are Applied

Exchange 2003 supports the following filters and IP restrictions:

  • Connection filtering

  • Recipient filtering

  • Sender filtering

  • IP restrictions on a virtual server basis

Although connection filtering, recipient filtering, and sender filtering are all configured in Message Delivery Properties, they must be enabled on individual SMTP virtual servers. In contrast, IP restrictions are configured directly on each SMTP virtual server.

This section shows the order in which IP restrictions and filters, when configured and enabled, are checked during an SMTP session.

  1. An SMTP client attempts to connect to the SMTP virtual server.

  2. The IP address of the connecting client is checked against the SMTP virtual server's IP restrictions (configured on the Connection button on the Access tab of the SMTP virtual server Properties):

    • If the connecting IP address is on the list of restricted IPs, the connection is immediately dropped.

    • If the connecting IP address is not on the list of restricted IPs, the connection is accepted.

  3. The SMTP client issues an EHLO or HELO command.

  4. The SMTP client issues a MAIL FROM: command, similar to the following:

    MAIL FROM: ted@contoso.com

  5. The IP address of the SMTP client is then checked against the global accept list (configured in Exchange System Manager on the Connection Filtering tab in the Message Delivery Properties dialog box).

    • If the connecting IP address is on the global accept list, the global deny list is not checked. The process skips Step 6 and proceeds to Step 7.

    • If the connecting IP address is not on the global accept list, Steps 6 and 7 are performed.

  6. The IP address of the SMTP client is checked against the global deny list (configured in Exchange System Manager on the Connection Filtering tab in the Message Delivery Properties dialog box).

    • If the IP address of the SMTP client is on the global deny list, the connection is dropped.

    • If the IP address of the SMTP client is not on the global deny list, the session continues.

  7. Sender filtering checks the sender that is specified in the MAIL FROM command against its list of blocked senders (configured in Exchange System Manager on the Sender Filtering tab in the Message Delivery Properties dialog box).

    • If the sender appears on the blocked senders list, one of two actions occur, depending on how sender filtering is configured:

      - If sender filtering is configured to drop the connection, the connection is dropped.

      - If sender filtering is configured to accept messages without notifying the sender, the session continues; however, mail is sent to the Badmail directory and not delivered to the intended recipient.

    • If the sender does not appear on the sender filtering list, the SMTP virtual server issues a response similar to the following:

      250 2.1.0 ted@contoso.com...Sender OK

  8. The connecting SMTP server issues a RCPT TO command similar to the following:

    RCPT TO: kim@example.com

  9. The connection filtering rules check the connecting IP address against any block lists that are provided by their block list service providers.

    • If the IP address of the SMTP client is in the accept list, the connection filter rules are bypassed. The process proceeds to Step 10.

    • Connection filtering checks each service provider's block list in the order that is configured in connection filtering. If connection filtering finds a match on a provider's block list, the SMTP virtual server returns an error code and then sends the customized error message that is configured for the connection filtering rule. After a match is found, no other service provider lists are checked.

    • If the IP address of the SMTP client is not on a block list service provider's block list, the session continues.

  10. Connection filtering checks if the intended recipient is on the connection filtering exception list.

    • If the recipient is on this list, the communication is accepted, and no other checks are applied at the RCPT TO command. The process skips Steps 11 and 12 and proceeds to Step 13.

    • If the recipient does not appear on the exception list, the recipient is checked against other filters.

  11. If the recipient does not appear on the exception list that is configured in connection filtering, the recipient is then checked against any blocked recipients that are configured in recipient filtering.

    • If the recipient is a blocked recipient, the SMTP virtual server returns an invalid recipient error.

    • If the recipient is not a blocked recipient, the session continues.

  12. If the recipient is not a blocked recipient, Active Directory is checked to ensure that the intended recipient exists in Active Directory.

    • If the intended recipient is not a valid recipient that exists in Active Directory, the SMTP virtual server returns an invalid recipient error.

    • If the recipient is a valid recipient that exists in Active Directory, the session continues.

  13. For each additional recipient that is specified in a RCPT TO command, Steps 10 through 12 are applied.

  14. The connecting server then issues a DATA command that is similar to the following:

    DATA

    To: Kim Akers

    From: ted@contoso.com<Ted Bremer>

    Subject: Mail Message

  15. Sender filtering then checks that the From address does not match a blocked sender.

    • If the sender that is specified in the DATA command is a blocked sender, one of two actions occur:

      - If sender filtering is configured to drop the connection, the SMTP virtual server returns a 5.1.0 Sender Denied error and drops the connection.

      - If sender filtering is configured to accept messages without notifying the sender, the session continues; however, mail is sent to the Badmail directory and not delivered to the intended recipient.

    • If the sender that is specified in the DATA command is not a blocked sender, the message is accepted and queued for delivery.

Identifying Spoofed Mail

You can educate your users on how to identify spoofed mail. Unlike Exchange 2000, Exchange 2003 does not resolve anonymous e-mail messages to their display names in its default configuration. Therefore, when mail is sent from a forged address, Exchange 2003 does not resolve the sender's e-mail address to its display name in the global address list.

To understand how Exchange 2003 prevents spoofing, suppose that you have an internal user named Ted Bremer, and he sends mail internally from your domain example.com. The e-mail message shows his sending address as Ted Bremer, which is the display name that is configured in Active Directory for ted@example.com. (This is because when Ted Bremer sends mail, he is an authenticated user.) Exchange then verifies that Ted Bremer has "send as" permissions under his credentials and then resolves his e-mail address to his display name in Active Directory. Spoofing occurs when an unauthorized user pretends to be Ted by forging this address and then sends mail to another user in your domain.

Exchange 2003 does not resolve e-mail addresses that originate externally. Therefore, when an anonymous user attempts to send mail spoofing Ted's identity, Exchange will not resolve the sending address in the From line to its display name. Instead, ted@example.com will appear in the From line of the e-mail. If your users understand this difference, they can at least identify spoofed mail.

However, Exchange 2000 servers do resolve anonymous e-mail by default. If your organization contains Exchange 2000 servers, and they resolve an anonymous e-mail message and send it to an Exchange 2003 server, the address resolves to its display name in the GAL. To prevent this, configure your Exchange 2000 servers so that they do not resolve anonymous mail.

For detailed instructions, see How to Verify That Exchange 2003 is Configured to Not Resolve Anonymous Mail and How to Configure Exchange 2000 to Not Resolve External Email Addresses.