Understanding Recipient Filtering

  • Article

 

Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2

The Recipient Filter agent is an anti-spam agent enabled on computers running Microsoft Exchange Server 2010 that have the Edge Transport server role installed. The Recipient Filter agent relies on the RCPT TO SMTP header to determine what action, if any, to take on an inbound message.

When you configure anti-spam agents on an Edge Transport server, the agents act on messages cumulatively to reduce the number of unsolicited messages that enter the organization. For more information about how to plan and deploy anti-spam agents, see Understanding Anti-Spam and Antivirus Functionality.

The Recipient Filter agent blocks messages according to the characteristics of the intended recipient in the organization. The Recipient Filter agent can help you prevent the acceptance of messages in the following scenarios:

  • Nonexistent recipients   You can prevent delivery to recipients that aren't in the organization's address book. For example, you may want to stop delivery to frequently misused account names, such as administrator@contoso.com or support@contoso.com.

  • Restricted distribution lists   You can prevent delivery of Internet mail to distribution lists that should be used only by internal users.

  • Mailboxes that should never receive messages from the Internet   You can prevent delivery of Internet mail to a specific mailbox or alias that's typically used inside the organization, such as Helpdesk.

The Recipient Filter agent acts on recipients stored in one or both of the following data sources:

  • Recipient Block list   An administrator-defined list of recipients for which inbound messages from the Internet should never be accepted.

  • Recipient Lookup   Verification that the recipient is in the organization. Recipient Lookup requires access to Active Directory information provided by EdgeSync to Active Directory Lightweight Directory Services (AD LDS).

For more information about Recipient Block lists and Recipient Lookup functionality, see "Recipient Data Sources" later in this topic.

When you enable the Recipient Filter agent, one of the following actions is taken on inbound messages according to the characteristics of the recipients. These recipients are indicated by the RCPT TO header.

  • If the inbound message contains a recipient that is on the Recipient Block list, the Edge Transport server sends a "550 5.1.1 User unknown" SMTP session error to the sending server.

  • If the inbound message contains a recipient that doesn't match any recipients in Recipient Lookup, the Edge Transport server sends a "550 5.1.1 User unknown" SMTP session error to the sending server.

  • If the recipient isn't on the Recipient Block list and the recipient is in Recipient Lookup, the Edge Transport server sends a "250 2.1.5 Recipient OK" SMTP response to the sending server, and the next anti-spam agent in the chain processes the message.

Looking for management tasks related to anti-spam and antivirus functionality? See Managing Anti-Spam and Antivirus Features.

Contents

Configuring AD LDS for Recipient Lookup

Recipient Data Sources

Tarpitting Functionality

Configuring the Tarpitting Interval

Multiple Namespaces

Configuring AD LDS for Recipient Lookup

One of the most effective ways to reduce spam is to validate recipients before accepting inbound messages from the Internet. Therefore, it's a good idea to configure the AD LDS instance that runs on the Edge Transport server to synchronize with Active Directory. By default, AD LDS is installed and configured on the Edge Transport server. However, you must configure AD LDS to communicate with an Active Directory domain-joined global catalog server. Most of the time, you must also configure your firewall to enable specific ports to communicate with AD LDS. For more information, see Understanding Edge Subscriptions.

After you configure AD LDS to replicate a Recipient Block list from Active Directory, you must then enable blocking of messages sent to recipients who aren't present in the Exchange organization. You enable message blocking on the Blocked Recipients tab of the Recipient Filtering Properties page in the Exchange Management Console (EMC). You can also enable message blocking by using the Set-RecipientFilterConfig cmdlet in the Exchange Management Shell. For more information, see Set-RecipientFilterConfig.

Return to top

Recipient Data Sources

As mentioned earlier, the Recipient Filter agent references two data sources when it compares recipients on inbound messages: the Recipient Block list and Recipient Lookup.

Recipient Block List

The Recipient Block list is maintained by the Edge Transport server administrators. The Recipient Block list data is stored in the Edge Transport server instance of AD LDS. You must enter blocked recipients on each Edge Transport server computer.

You can enter the recipients that you want the Recipient Filter agent to block in the EMC on the Blocked Recipients tab of the Recipient Filtering Properties page. You use the Set-RecipientFilterConfig cmdlet in the Shell to enter recipients. For more information about how to configure the Recipient Filter agent, see Configure Recipient Filtering Properties.

Recipient Lookup

One benefit of the Recipient Filter agent is the ability to verify that the recipients on an inbound message are in your organization before Exchange 2010 transmits the message into your organization. The ability to verify recipients in your organization relies on a recipient data source available to the Edge Transport server. Because the Edge Transport server isn't an Active Directory domain-joined computer and could be segregated from the organization by a firewall, you must configure a Recipient Lookup data source for the Edge Transport server to use.

The Edge Transport server role uses AD LDS for configuration and data storage. For more information, see Understanding Edge Subscriptions.

Return to top

Tarpitting Functionality

Recipient Lookup functionality enables the sending server to determine whether an e-mail address is valid or invalid. As mentioned earlier, when the recipient of an inbound message is a known recipient, the Edge Transport server sends back a "250 2.1.5 Recipient OK" SMTP response to the sending server. This functionality provides an ideal environment for a directory harvest attack.

A directory harvest attack is an attempt to collect valid e-mail addresses from a particular organization so that the e-mail addresses can be added to a spam database. Because all spam income relies on trying to make people open e-mail messages, addresses known to be active are a commodity that malicious users, or spammers, pay for. Because the SMTP protocol provides feedback for known senders and unknown senders, a spammer can write an automated program that uses common names or dictionary terms to construct e-mail addresses to a specific domain. The program collects all e-mail addresses that return a "250 2.1.5 Recipient OK" SMTP response and discards all e-mail addresses that return a "550 5.1.1 User unknown" SMTP session error. The spammer can then sell the valid e-mail addresses or use them as recipients for unsolicited messages.

To combat directory harvest attacks, Exchange 2010 includes tarpitting functionality. Tarpitting is the practice of artificially delaying server responses for specific SMTP communication patterns that indicate high volumes of spam or other unwelcome messages. The intent of tarpitting is to slow down the communication process for such e-mail traffic so that the cost of sending spam increases for the person or organization sending the spam. Tarpitting makes directory harvest attacks too costly to automate efficiently.

If tarpitting isn't configured, Exchange Server immediately returns a "550 5.1.1 User unknown" SMTP session error to the sender when a recipient isn't located in Recipient Lookup. Alternatively, if tarpitting is configured, SMTP waits a specified number of seconds before it returns the "550 5.1.1 User unknown" error. This pause in the SMTP session makes automating a directory harvest attack more difficult and less cost-effective for the spammer. By default, tarpitting is configured for 5 seconds on Receive connectors.

To configure the time before SMTP returns the "550 5.1.1 User unknown" error, use the EMC or the Shell to set the TarpitInterval value on the Receive connector. For more information about how to administer and configure Receive connectors, see Understanding Receive Connectors.

Return to top

Configuring the Tarpitting Interval

As explained in Understanding Recipient Filtering, you can configure the Receive connectors that process inbound messages from the Internet to slow down the SMTP response. Make sure that you enable tarpitting functionality on the Receive connectors, especially if you have enabled the Recipient Lookup feature of recipient filtering. If you don't enable tarpitting, and you have enabled the Recipient Lookup feature, you are exposing your organization to a directory harvest attack. A directory harvest attack will likely cause more spam.

When you specify a tarpitting interval time on a Receive connector, tarpitting is enabled. The default value is 5 seconds. We recommend that you start with a value of 5 (seconds). Use caution if you decide to change this value. An overly long interval could disrupt ordinary mail flow, whereas an overly brief interval may not be as effective in thwarting a directory harvest attack. If you change the tarpitting interval value, do so in small increments.

If you are running a version of Exchange Server earlier than Microsoft Exchange Server 2010 Service Pack 2 (SP2), you can set the tarpitting interval on the Security tab of the Receive connector property pages in the EMC, or you can use the Set-ReceiveConnector cmdlet in the Exchange Management Shell. For more information about how to use the EMC to configure the tarpitting interval, see Configure Receive Connector Properties.

If you are running Exchange Server 2010 SP2, or a later version, you set the tarpitting interval by using the Set-ReceiveConnector cmdlet in the Exchange Management Shell.

Return to top

Multiple Namespaces

Some organizations accept e-mail messages for multiple domains. For example, one organization may accept messages for both the Contoso.com and the Woodgrovebank.com domains. Sometimes organizations are authoritative for all the domains for which they accept messages. In the context of SMTP, the organization is authoritative for a domain if the organization hosts and manages the mailboxes for that domain. This relationship extends to the Edge Transport server. An Edge Transport server may accept messages for multiple domains, but it may not be authoritative for all the domains. For example, an Edge Transport server can be configured to be authoritative for all recipients in the Contoso.com domain, but the Edge Transport server still accepts and forwards messages for the Woodgrovebank.com domain.

When you enable the Recipient Filter agent, the Recipient Filter agent performs recipient lookups only for the domains specified as authoritative in the transport server configuration. If an Edge Transport server accepts and forwards messages on behalf of another domain, but the Edge Transport server isn't configured as authoritative, the Recipient Filter agent doesn't perform a recipient lookup. However, if a recipient that's not authoritative is specified in the Recipient Block list, the recipient will still be blocked.

Return to top

 © 2010 Microsoft Corporation. All rights reserved.