Exxhange SQL And IIS- P89 pot

Managing the Edge Transport Server • Chapter 7 417
An RBL is an Internet-based service that tracks systems (and then adds those systems’
IP addresses to a public list) that are known to send or suspected of sending out spam.
In addition to specifying IP Block list providers, you can also enter a custom error message that
should be returned to the blocked SMTP server. Last but not least, there’s an Exceptions tab where
you can specify IP addresses to which e-mail messages shouldn’t be blocked, regardless of the
feedback from the RBL.
Sender Filtering
When the Connection Filtering agent has processed the SMTP connection, the next fi ltering agent
involved is Sender Filtering, which will check the e-mail address of the sender against the list of
e-mail addresses or domains you have specifi ed under the Sender Filtering Properties page
(see Figure 7.35).
The Sender Filtering agent lets you reject individual e-mail addresses, single domains, or whole
blocks of domains (that is, a domain and any subdomains). When the Sender Filtering agent rejects an
e-mail message, a “554 5.1.0 Sender Denied” message is returned to the sending server. The agent
also lets you reject any e-mail messages that don’t contain a sender.
In addition to rejecting e-mail address and/or domains specifi ed on the Blocked Senders list on
the Sender Filtering Properties page, you can also choose to stamp messages instead of rejecting them
(done under the Action tab). When you choose this action, the metadata of the message will be
updated to indicate that the message was sent by a blocked sender. The stamp will then be used when
the Content Filtering agent calculates the spam confi dence level (SCL) of the message.
Bear in mind that the Sender Filtering agent overrides the Outlook Safe Senders list (which we
will talk about later in this section), which means that senders specifi ed on the Block Senders list will
be rejected even though they are included on a Outlook Safe Senders list.
NOTE
You can read more about what RBLs are as well as how they work at http://en.
wikipedia.org/wiki/DNSBL. In addition, you can fi nd a list of the most popular RBLs
at www.email-policy.com/Spam-black-lists.htm.
418 Chapter 7 • Managing the Edge Transport Server
Recipient Filtering
When a message has been processed by the Sender Filtering agent and hasn’t been rejected, it will be

handed over to the Recipient Filtering agent. (Well, this isn’t exactly true; the Connection Filtering
agent will run once more, before doing so.) This will check the recipient of a given e-mail message
against the Recipient Block list. As you can see in Figure 7.36, you can block recipients based on
their e-mail addresses (that is, the SMTP address in the RCPT TO: fi eld) as well as messages sent to
recipients not listed in the Global Address List (GAL). The edge transport server can only check
whether a recipient is in the GAL if you use EdgeSync subscription; otherwise, recipient data will not
be replicated from Active Directory to ADAM.
Figure 7.35 Blocked Sender List on the Sender Filtering Properties Page
Managing the Edge Transport Server • Chapter 7 419
NOTE
Any SMTP addresses entered on the Blocked Recipients list will only be blocked for
senders located on the Internet. Internal users will still be able to send messages to
these recipients.
Figure 7.36 The Blocked Recipients List on the Recipient Filtering Properties Page
420 Chapter 7 • Managing the Edge Transport Server
If an external sender sends an e-mail message to a recipient that is either listed on the Blocked
Recipient list or not present in the GAL, a “550 5.1.1 User unknown SMTP” session error will be
returned to the sending server.
It worth noting that the Recipient Filtering agent works for only domains for which the
Edge Transport server is authoritative. This means that any domains for which the Edge Transport
server is confi gured as a relay server won’t be able to take advantage of Recipient Filtering. Diagrams
of the Edge Transport Server with the Recipient Filtering Agent disabled and enabled are shown in
Figures 7.37 and 7.38, respectively.
SOME INDEPENDENT ADVICE
As mentioned earlier in this chapter, the EdgeSync service will replicate recipient data
from Active Directory to ADAM every fourth hour. With this in mind, be aware that
any new recipients created on your mailbox server on the internal network won’t be
able to receive e-mail messages from external senders before the EdgeSync service
has taken place hereafter.
The Recipient Lookup feature also includes a SMTP Tarpitting feature that helps

combat directory harvest attacks (DHAs). A DHA is a technique spammers use in an
attempt to fi nd valid SMTP addresses within an organization. This is typically done
with the help of a special program that is capable of generating random SMTP
addresses for one or more domains. For each generated SMTP address, the program
also sends out a spam message to the specifi c address. Because the program will try
to deliver a message to each generated SMTP address, an SMTP session is, of course,
also established to the respective edge transport server (or whatever SMTP gateway
is used in the organization). The program can therefore collect a list of valid SMTP
addresses, since the SMTP session will either respond with “250 2.1.5 Recipient OK”
or “550 5.1.1 User unknown,” depending on whether the SMTP address is valid
or not.
This is where the SMTP Tarpitting feature comes into the picture. This feature
basically delays the “250 2.1.5 Recipient OK” or “550 5.1.1 User unknown” SMTP
response codes during an SMTP session. By default, the SMTP Tarpitting feature on
an Edge Transport server is confi gured to a delay of 5 seconds (but the value can be
changed for each Receive connector), which should help make it more diffi cult for a
spammer to harvest valid SMTP addresses from your domain.
Figure 7.37 The Edge Transport Server with the Recipient Filtering Agent Disabled
Spammer
Perimeter Network
Edge Transport
Firewall
Spammer Performs a
Directory Harvest Attack
Edge Transport Server
Responds as Fast as it Can
Managing the Edge Transport Server • Chapter 7 421
Sender ID Filtering
When an e-mail message has been processed by the Recipient Filtering agent and still hasn’t been
rejected, it will be handed over to the Sender ID Filtering agent.

The Sender ID is an e-mail industry initiative invented by Microsoft and a few other industry
leaders. The purpose of Sender ID is to help counter spoofi ng (at least to make it more diffi cult to
spoof messages), which is the number-one deceptive practice used by spammers. Sender ID works by
verifying that every e-mail message indeed originates from the Internet domain from which it was
sent. This is accomplished by checking the address of the server sending the mail against a registered
list of servers that the domain owner has authorized to send e-mail.
If you don’t have any experience with Sender ID, it can be a bit diffi cult to understand, so let’s
take a closer look at how it works.
An organization can publish a Sender Policy Framework (SPF) record on the public DNS
server(s) hosting their domain. The published SPF record contains a list of the IP addresses that
should be or are allowed to send out messages for a particular domain. If a particular organization has
published a SPF record and someone at that organization sends a message to a recipient behind an
Edge Transport server in another organization, the Edge Transport server will examine the SPF record
to see whether the SMTP server that sent the message is listed there (see Figure 7.39).
SOME INDEPENDENT ADVICE
The SMTP Tarpitting feature was originally introduced in Exchange Server 2003.
In Exchange 2003 the administrator had the option of specifying a tarpit value in
which he or she could defi ne the number of seconds to delay a response to the
RCPT TO command during an SMTP session. The problem in Exchange 2003 was that
this value was fi xed, which enabled spammers to detect this behavior so they could
work around it. A common practice was to have the spam application establish
a new SMTP session, if it detected it was being tarpitted. To solve this problem, the
edge transport server uses a random number of seconds, making predictions much
harder. Even if the spam application reconnects, it won’t be in better shape; the
edge transport server will know it’s the same sending server, so it will retain the
tarpit state.
Figure 7.38 The Edge Transport Server with the Recipient Filtering Agent Enabled
Firewall
Perimeter Network
Spammer

Spammer Performs a Directory
Harvest Attack
Edge Transport Server Responds
with a Delay (Default 5 Seconds)
Edge Transport