5.4 Suppressing Web beacons and attachment handling

---

Web beacons are code inserted in HTML messages as an invitation for users to transmit a "heartbeat" or indication that they have received a message back to the originator. Beacons began as very small transparent graphics included in HTML pages that are hard to notice. Web designers used beacons for a laudable purpose to track the number of visitors to a page by counting the number of downloads for the beacon's graphic file.

Today, the most common implementation of a beacon is as a URL included in a message that links back to a graphic file on an Internet site. When you open the message, the client responds to the HTML commands for the beacons and connects to the site to download the graphics. Programmers can exploit these links to send back information about you when you view the graphic, and spammers often use this technique to separate real email addresses from the guesses that they often use to populate their distribution lists. Once they know that they have a real email address, they can include it in other distribution lists that they sell, and you end up getting more spam. Links to view graphic content are implicit links, because you cannot do anything about them if you want to view the graphic. Links to other sites labeled, for example, "Click Here for more information" are explicit, because you have the choice to click or not.

Outlook 2003 and OWA 2003 both include Web beacon suppression. However, the two clients take slightly different approaches. Outlook can work offline, so it assumes that any content from intranet sites is OK and allows you to specify whether you automatically download pictures from trusted sites. The very nature of OWA is to work online always, so if it encounters links inside message content, they might be Web beacons, even from known sites. Therefore, OWA always suppresses this content and leaves it to you to decide whether you want to view it.

Figure 5.13 illustrates the story. A new message has arrived in the Inbox and OWA displays it in the reading pane. OWA detects that the message contains some content that could be a Web beacon, so it suppresses the display and flags this in the message header. Clicking on the warning tells OWA to fetch the suppressed content and display the message in a separate window. We can then view the HTML source to see where the problem might be, although at this point the data has already gone back to the originator if a programmer included the necessary instructions in the source. Note that the message has both implicit and explicit links. (See Table 5.2.)

Figure 5.13: OWA and Web beacons.

Table 5.2: Options to Control How OWA Processes External Content

Key	Meaning
FilterWebBeacons	0: List external content in OWA options and let the user decide (the default as shown in Figure 5.14) 1: Force filtering and remove the UI 2: Disable filtering and remove UI
WebBeaconFilterMode	0: Display filtered images as broken images 1: Display filtered images as clear GIFs (default)

Figure 5.14: User interface to control how OWA handles external content.

The description so far is how OWA works OOTB. As in so many places in Exchange, a number of DWORD registry values exist that you can create at HKLM\System\CurrentControlSet\Services\MSExchangeWeb\OWA to modify behavior.

Attachments can also cause great damage if they contain malicious code and sneak past your organization's antivirus barriers. OWA 2003 implements the same type of attachment handling as Outlook and splits attachment types into three levels:

Level 1: OWA blocks all access to these attachments.

Level 2: OWA allows users to save the attachment, but they cannot open the attachment without first saving it.

Level 3: OWA processes the attachment using whatever method is available.

OWA identifies attachment types by their file extension and their MIME type. It is relatively easy to imagine the attachment types that you want to block from users, including EXE (executables) and BAT (Windows batch files). Other attachments are potentially dangerous if users execute them without thinking-VBS (Windows scripts) and URLs are usually in this category. Normal office files such as Word documents (DOC) and Excel spreadsheets (XLS) are usually in level 3.

Once again, you can see how OWA deals with attachments through some registry values at:

HKLM\System\CurrentControlSet\Services\MSExchangeWeb\OWA

OWA does not apply attachment blocking for every possible attachment that you might want to stop, so you have to configure a server if you want to implement these blocks. Table 5.3 lists the registry values that you can use.

Table 5.3: Configuring Attachment Blocking for OWA

Key	Meaning
Level1FileTypes	String value containing comma-separated list of blocked attachments-for example: EXE, COM, BAT
Level1MIMETypes	String value containing the MIME types of blocked attachments-for example, to block Macromedia Shock and Director files, input (or add to the existing list): application/x-shockwave-flash,application/futuresplash, application/x-director
Level2FileTypes	String value containing comma-separated list of potentially dangerous attach- ments-for example, the list to block Macromedia Shock and Director files is: swf,spl,dir,dcr
Level2MIMETypes	String value containing the MIME types of potentially dangerous attachments- for example: text/html
DisableAttachments	DWORD value set to: 0: Respect values defined in File and MIME attachments 1: Block all attachments no matter what their type 2: Only block attachments when client accesses the mailbox through a front-end server
AcceptedAttachmentFrontEnds	String value containing comma-separated exception list for front-end servers to ignore when you set DisableAttachments to 2. This allows you to configure some front-end servers that permit attachments, probably for use in an internal network.

---