Exxhange SQL And IIS- P89 pot

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

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

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

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

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

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