SMTP filtering

 

The Simple Mail Transfer Protocol (SMTP) filtering layer, also known as the protocol filtering layer, performs several functions. At a high level, this layer checks the fidelity and integrity of the SMTP transaction. More specifically, sender and recipient filtering can be configured, and incoming email volume (on a per-sender basis) can be configured. Additionally, the core transport stack functionality can help thwart denial-of-service attacks, can allow you to configure filtering at the individual user level. Lastly, the protocol filtering layer can provide protection against backscatter spam.

Details are covered in the following sections.

Sender filtering

During the SMTP transaction, the sender filtering agent rejects incoming messages from senders that exist on the sender or sender domain block lists. It also rejects messages without a valid sender address.

Note

If a sender has been explicitly added to a safe list, messages from that sender are excluded from antispam processing. However, each message from that sender is still scanned for malware. For detailed instructions on configuring sender filtering, see Configuring sender filtering.

Recipient filtering

The recipient filtering list blocks email messages sent to addresses that you specify. For example, if you add stuartr@contoso.com to your blocked recipients list, any messages sent from the internet to that address are blocked. However, messages sent from inside the organization to the recipient are not blocked.

You can also configure FPE to block messages sent to any invalid recipient in your organization (meaning any email recipient that does not exist in your global address list).

For detailed instructions, see Configuring recipient filtering.

Sender ID

The Sender ID filter checks to ensure that the IP address of the mail transfer agent (MTA) initiating the messaging transaction has legitimate rights to send email from the originating domain. If Sender ID verification fails (meaning that the connecting IP address does not have legitimate rights to send e-mail on behalf of the domain it claims to be from), which typically happens when the mail is “spoof” mail, the message can be rejected, stamped, or deleted.

This protection is important for “zero-day attacks”, where an attacker sends spoofed mail to your organization before definitions for your antivirus and antimalware are updated, exploiting the time between the detection of the security vulnerability and the release of a new antivirus definition from the antivirus vendor. In this scenario, Sender ID protection is effective to stop this type of spam.

Note

The Sender ID filter rejects or deletes a message only if it is an identified spoof.

For detailed instructions, see Configuring sender ID filtering.

SMTP tarpit interval

Note

The following is a feature of Exchange, but it is mentioned here in connection with FPE because of its usefulness in preventing spam attacks.

The SMTP tarpit feature is one of the most useful tools to protect organizations from directory harvesting attacks (DHAs). A directory harvesting attack is an attempt to discover existing email addresses at a domain by guessing valid email addresses through use of common user names. Malicious spam creators can take advantage of recipient validation to programmatically iterate through a directory in a very short time. To counter this type of attack, the receiving server can slow each response to the client and limit the number of non-existing-recipient errors allowed for a particular IP address. By default, the tarpit interval, or time before a response, is five seconds, and the error limit is five.

To modify the tarpit interval in Exchange, or number of errors allowed, you can use the Get-ReceiveConnector cmdlet and the Set-ReceiveConnector cmdlet. The steps for doing this are explained in the white paper called Forefront Protection 2010 for Exchange Server Antispam Framework, located at the white papers page of the Forefront Protection 2010 for Exchange Server website.

Message submission rate

Note

The following is a feature of Exchange, but it is mentioned here in connection with FPE because of its usefulness in preventing spam attacks.

By default, an Exchange server in the Edge Transport role is set to accept 600 messages from a single IP per minute. However, if your organization is under spam attack, it is effective and practical to lower the submission rate, thus reducing the number of incoming spam messages, and reducing load on your Exchange infrastructure. The steps for doing this are explained in the white paper called Forefront Protection 2010 for Exchange Server Antispam Framework, located at the white papers page of the Forefront Protection 2010 for Exchange Server website.

Safe lists

Note

Safe lists are a feature of Outlook. The feature is explained here because safe lists can be used with FPE to provide effective spam protection.

Safe lists allow an end user to designate as safe or blocked a specific sender or domain.

The Safe Senders list is available through Outlook’s Junk E-mail Options dialog. For more information about configuring junk email settings, see Configure junk e-mail settings in Outlook 2010 (https://go.microsoft.com/fwlink/?LinkId=209712).

Backscatter Filtering

Backscatter spam consists of non-delivery reports, or NDRs, that are sent to users, even though the user never sent the original message. This type of spam is the result of spam attacks using a spoofed sender address. It is important to block backscatter spam, because these spam messages can contain malware. Forefront Protection 2010 for Exchange Server has the ability to block this type of spam, based on tokens that are added to outbound mail from your organization. The backscatter filtering feature makes use of an outbound mail agent that stamps outgoing messages with a token that contains information about the original sender, including the sender’s address, the time of the message event, and a key. Subsequently, inbound messages are checked for the token, and once it is verified for integrity, the message is allowed to pass. If the incoming token is not validated correctly, the incoming message is rejected.

If you want to learn how to enable backscatter filtering, you can watch the following video, Spam Filtering in Forefront Protection 2010 for Exchange Server. The white paper Forefront Protection 2010 for Exchange Server Antispam Framework goes into further detail about the programmatic details of backscatter filtering. It is located on the white papers page of the Forefront Protection 2010 for Exchange Server website.

See Also

Concepts

Connection filtering
Content filtering
Capacity planning for Forefront Protection 2010 for Exchange Server