Dieser Inhalt ist in Ihrer Sprache leider nicht verfügbar. Im Folgenden finden Sie die englische Version.

Microsoft Exchange Server 2007 Edge Transport and Messaging Protection

How Microsoft IT Prevents Spam, E-Mail Viruses, Directory Harvesting, and Other Attacks

Technical White Paper

Published: January 2009

The following content may no longer reflect Microsoft’s current position or infrastructure. This content should be viewed as reference documentation only, to inform IT business decisions within your own company or organization.


Download Technical White Paper, 3.35 MB, Microsoft Word file




Products & Technologies

The increasing complexity and prevalence of spam, e-mail viruses, and other messaging threats challenge Microsoft, in terms of both lost productivity and associated costs. Solutions for blocking harmful messages must work with a high level of precision, because blocking legitimate messages can have an adverse business impact.

Microsoft IT used the features available in 0Exchange Server 2007 with SP1 to optimize the existing messaging environment at all levels, including messaging protection against harmful messages and threats. The solution relies on Edge Transport servers in the perimeter network, Mailbox servers in the internal network, and security configurations for client computers inside and outside the corporate environment.

  • Increased accuracy of spam filtering decreases unwanted messages and false positives.
  • Automated maintenance of filter configurations and updates ensures that spam filtering and antivirus scanning remain accurate as new threats and challenges emerge.
  • Increased security in the perimeter network provides better protection of internal resources such as Active Directory.
  • Processing overhead on internal messaging servers is reduced through spam and virus blocking at the earliest possible point.
  • Delivery of messages from trusted business partners, based on Safe Senders lists, is guaranteed.
  • Windows Server 2003 and Windows Server 2008
  • Active Directory
  • Microsoft Exchange Server 2007 with SP1
  • Microsoft Forefront Security for Exchange Server
  • Microsoft Office Outlook 2007
  • Microsoft SmartScreen
  • Antivirus scanners
  • Intelligent Message Filter


Dd405377.arrow_px_down(en-us,TechNet.10).gif Executive Summary

Dd405377.arrow_px_down(en-us,TechNet.10).gif Messaging Protection Prior to Exchange Server 2007

Dd405377.arrow_px_down(en-us,TechNet.10).gif Exchange Server 2007 Messaging Protection

Dd405377.arrow_px_down(en-us,TechNet.10).gif Exchange Hosted Filtering Services

Dd405377.arrow_px_down(en-us,TechNet.10).gif Deployment of Edge Transport Servers

Dd405377.arrow_px_down(en-us,TechNet.10).gif Best Practices

Dd405377.arrow_px_down(en-us,TechNet.10).gif Conclusion

Dd405377.arrow_px_down(en-us,TechNet.10).gif For More Information

Executive Summary

According to a recent study buy Ferris Research, spam costs companies between $500 and $800 USD per user, per year, in lost productivity. A messaging environment with more than 100,000 users, such as the one the Microsoft Information Technology (Microsoft IT) group maintains, would therefore lose between $50 million and $80 million per year without spam filtering. Ferris Research suggests that with spam filtering, the costs decrease to $120 to $150 per user, per year—a savings of approximately 80 percent. Accordingly, fighting spam and e-mail–borne viruses is a top priority for Microsoft IT and has been for many years.

Microsoft Exchange Server 2007 with Service Pack (SP) 1 enables Microsoft IT to increase security and messaging protection in the corporate messaging environment and to reduce the number of legitimate messages incorrectly identified as spam (false positives) beyond the level achievable with Microsoft Exchange Server 2003 with SP2. Exchange Server 2007 with SP1 increases security because the Active Directory Application Mode (ADAM)–based deployment of Edge Transport servers eliminates the requirement for installing perimeter resources as part of the corporate Active Directory forest. Microsoft IT currently uses the Windows Server 2003 operating system, but Exchange Server 2007 with SP1 is fully Windows Server 2008 compatible and uses Active Directory Lightweight Directory Services (AD LDS), which is the new name for ADAM. The accuracy of spam filtering increases and the number of false positives decreases through new features available on Edge Transport servers, such as open proxy detection, automatic spam signature, Internet Protocol (IP) reputation, content filter updates, safe-list aggregation, and Microsoft Office Outlook E-mail Postmark validation.

The efficiency of virus scanning at the transport level also increases with the deployment of Microsoft Forefront„¢ Security for Exchange Server on all Edge Transport and Hub Transport servers. By using Edge Transport servers that are running Forefront Security for Exchange Server, Microsoft IT stops spam, viruses, and other harmful content before it reaches the corporate production environment. With protection implemented at multiple layers, including the edge network, the Hub Transport servers, and the mail clients, Microsoft IT has a true defense-in-depth strategy. In short, Microsoft IT takes full advantage of the security and messaging-protection features available in Exchange Server 2007 with SP1. The result is that despite increasingly sophisticated attack schemes, Microsoft employees continue to work without the annoyance of spam or viruses contained in e-mail messages.

This technical white paper discusses how Microsoft IT designed and implemented messaging protection in the corporate environment by using Exchange Server 2007 with SP1 Edge Transport servers and Forefront Security for Exchange Server. The implemented design defends primarily against external threats from incoming e-mail messages. Furthermore, Microsoft IT uses the Edge Transport features to defend against directory harvest attacks and denial of service (DoS) attacks at the Simple Mail Transfer Protocol (SMTP) layer.

The first section, "Messaging Protection Prior to Exchange Server 2007," contains a brief review of message routing and protection strategies that Microsoft IT implemented prior to the rollout of Exchange Server 2007. Microsoft IT continues to use several of these message routing and protection strategies with Exchange Server 2007. This review provides the context for explanations of new technologies and options that influenced Microsoft IT's decisions for messaging protection with Exchange Server 2007.

The second section, "Exchange Server 2007 Messaging Protection," highlights the security features that Microsoft IT implemented by using Exchange Server 2007 and Forefront Security for Exchange Server. Microsoft IT uses an in-depth approach that includes Edge Transport servers, Hub Transport servers, Mailbox servers, and client computers. Microsoft IT implements the majority of the defense mechanisms by using Edge Transport servers in conjunction with the capabilities provided by Forefront Security for Exchange Server for Edge servers—principally, protection against malicious software.

The third section, "Exchange Hosted Filtering Services," shows how Microsoft IT uses Exchange Hosted Filtering Services to provide messaging protection to a subset of Microsoft users. This section is brief and conceptual, because Microsoft IT does not manage the Exchange Hosted Filtering Services environment. Exchange Hosted Filtering Services is a separate Internet-based service that provides antispam, antivirus, policy filtering, and disaster recovery services.

The fourth section, "Deployment of Edge Transport Servers," explains how Microsoft IT deployed Edge Transport servers in the perimeter network. This section discusses configuration tasks that Microsoft IT performed to secure Edge Transport servers, such as eliminating unused services and opening only necessary ports.

The fifth section, "Best Practices," highlights the lessons learned and the best practices that Microsoft IT developed during the rollout of Exchange Server 2007 in the corporate production environment. Finally, the "Conclusion"section summarizes the key points of this paper.

This white paper assumes that the reader has a working knowledge of Windows Server 2008, Exchange Server, TCP/IP, and SMTP. A high-level understanding of the new features and technologies included in Exchange Server 2007 for messaging protection, spam filtering, and virus scanning is also helpful.

Note:For security reasons, the sample names of forests, domains, internal resources, organizations, and internally developed security file names used in this white paper do not represent real resource names used within Microsoft and are for illustration purposes only.

Messaging Protection Prior to Exchange Server 2007

Although the history of viruses attacking messaging systems goes back to the earliest days of the Internet (in 1988, the Morris worm devastated the Internet), it was not until the second half of the 1990s that spam and e-mail–borne viruses became imminent threats. By 1998, the problem had escalated to a level that required Microsoft IT to deploy dedicated non-Microsoft antivirus solutions for messaging protection. Since then, Microsoft IT has kept the messaging environment and security controls continuously updated to stay ahead of attackers, scammers, and spammers who use increasingly sophisticated methods, such as fishing for bank account information, credit card details, and passwords (phishing); domain name hijacking; and distributed denial of service (DDoS) attacks.

Routing of Incoming Messages

One of the most basic strategies for increasing the security of a computer network revolves around the concept of bastion hosts. A bastion host is a heavily fortified server computer designed to limit exposure of internal resources by forcing Internet traffic through a single channel. Channeling all Internet access to the internal production environment through a single computer (or small number of computers) enables a concentration of defense mechanisms and centralized security administration.

In the world of e-mail messaging, Internet mail gateway servers typically assume the role of bastion hosts. For example, with Exchange Server 2003, Microsoft IT concentrated the incoming message traffic from the Internet through six Internet mail gateway servers in Redmond, Washington, and Silicon Valley, California. This distribution across two data centers prevented a single point of failure and established multiple physical and logical paths through which Internet messages could reach recipients at Microsoft. These six Internet mail gateway servers received up to 13 million daily message submissions from the Internet, blocking over 10.5 million of these as not legitimate. The number of message submissions received from the Internet increases continuously.

Internet Mail Routing Topology

As depicted in Figure 1, the six Internet mail gateway servers running Exchange Server 2003 in Redmond and Silicon Valley were the main points of contact between the Internet and the corporate messaging environment. Internet mail gateway servers also existed in Dublin and Singapore, but these servers were for outgoing messages only.

Exchange Server 2003 with SP2 message routing topology at Microsoft

Figure 1. Exchange Server 2003 with SP2 message routing topology at Microsoft

Internet Mail Flow

During the Exchange Server 2003 time frame, when an Internet mail gateway server in Redmond or Silicon Valley received mail from the Internet, it performed a series of antispam and other filtering checks (for example, sender and recipient filtering) before routing the mail to one of the four Routing Hub servers, as shown in Figure 1. To avoid the overhead associated with virus scanning, Microsoft IT did not deploy antivirus solutions on the 32-bit Internet mail gateway servers. Virus scanning was the task of the Routing Hub servers. The Routing Hub servers in the corporate production environment ran Microsoft Antigen for SMTP. Antigen is an antivirus solution that integrates with the SMTP service as well as the Exchange Information Store service to perform virus scanning at the transport and store levels. Microsoft IT implemented virus scanning at the transport layer by using Antigen for SMTP and at the client level by using a non-Microsoft antivirus solution.

Microsoft IT performed virus scanning at the transport level of the SMTP service on the Routing Hub servers. If Antigen determined that the messages were not infected, the Routing Hub server passed the messages on to their final destination in the corporate environment. The destination was either a Mailbox server in Redmond or another hub server in one of the regional data centers in Dublin, Singapore, or Sao Paulo, which then passed the messages to the final Mailbox server.

Note: With Exchange Server 2003, Microsoft IT did not perform virus scanning on Internet mail gateway servers. This design changed with the migration to Exchange Server 2007. Now, all Exchange Server 2007 servers involved in message transfer, including Edge Transport servers, perform virus scanning.

bMessaging Protection Through Exchange Server 2003

Microsoft IT established the routing topology shown earlier in Figure 1 with the deployment of Exchange Server 2003. Microsoft IT used the Exchange Server 2003 rollout project as an opportunity for substantial site and server consolidation. Among other activities, Microsoft IT replaced all older antivirus systems with Routing Hub servers running the Antigen for SMTP antivirus solution, which lowered total cost of ownership (TCO). The resulting topology enabled Microsoft IT to eliminate unauthorized and harmful messages before they reached Mailbox servers.

Exchange Server 2003 SP2 represented the last important update prior to Exchange Server 2007. SP2 included advanced technologies for antispam, antiphishing, and content filtering, which Microsoft IT deployed on the Internet mail gateway servers. Figure 2 shows the resulting sequence of antispam and antivirus processing when an Internet message reached the Exchange Server 2003 with SP2 environment at Microsoft. The overall protection strategy relied on antispam controls at the Internet mail gateway servers; virus scanners and attachment filters at the Routing Hub servers; junk e-mail processing based on Spam Confidence Level (SCL) at the Mailbox servers; and additional attachment blocking, spam filtering, and virus scanning at the client computers.

Exchange Server 2003 with SP2 messaging protection

Figure 2. Exchange Server 2003 with SP2 messaging protection

Following are short descriptions of the 13 elements shown in Figure 2. Many of these elements are also relevant for the messaging-protection strategy that Microsoft IT decided to implement by using Exchange Server 2007.

  1. Connection filtering. Approximately 88 percent of all Internet message submissions that Microsoft receives daily originate from known sources of spam and virus e-mail messages. Microsoft IT categorizes these sources as harmful and unconditionally blocks all their connections by using global deny lists and non-Microsoft real-time block lists. Microsoft IT also uses global allow lists to accept e-mail messages from trusted senders, such as business partners.
  2. Sender filtering. Approximately 5 percent of the messages that remain after connection filtering come from list servers and similar sources. Microsoft IT prefers not to receive messages from these entities because the messages are not relevant for business, and it uses sender filtering to block their submissions. Microsoft IT also uses sender filtering as a countermeasure against mail flooding attacks from specific sender addresses or SMTP domains or against messages with invalid or missing sender information.
  3. Recipient lookup. Microsoft IT validates all recipient information from non-authenticated sources and refuses to accept messages to invalid or nonexistent recipients. Blocking messages with invalid or nonexistent recipients saves resources, because it reduces the number of messages that Microsoft IT would otherwise have to accept, attempt to deliver, and then return with a non-delivery report (NDR). Approximately 40 percent of remaining messages are filtered based on recipient lookups.
  4. Recipient filtering. Microsoft IT uses recipient filtering to block incoming messages addressed to aliases commonly used by spammers and specific valid recipients, such as unmonitored mailboxes and global distribution groups. Recipient filtering also enables Microsoft IT to protect against or reduce the impact of targeted mail flooding attacks. Recipient filtering filters approximately 1 percent of remaining messages.
  5. Sender ID lookup. Sender ID is a countermeasure against spam and phishing attempts that rely on forged sender information. If an SMTP host sends messages that claim to originate from a domain and if there is no Sender ID record that the SMTP host has authority for the domain, these messages likely contain forged sender information. Microsoft IT does not reject messages if the Sender ID check fails but stamps the messages with status information before passing them on to the Intelligent Message Filter (IMF) for further processing.
  6. Intelligent Message Filter. Microsoft IT blocks approximately 95 percent of all incoming Internet message submissions through connection filtering, sender filtering, and recipient filtering. The remaining 5 percent reach the IMF, which evaluates the message content based on keywords, phrases, custom word weights, and Sender ID status. The IMF assigns an SCL rating to each scanned message that corresponds to the likelihood that the message is spam. Microsoft IT rejects all messages with an SCL rating of 8 or higher. This conservative threshold enabled Microsoft IT to maintain a low rate of false positives by using Exchange Server 2003 with SP2.
  7. Attachment removal (stripping). Microsoft IT performs attachment removal based on file type to minimize the amount of data that the antivirus software must scan. Attachment removal also helps to protect against unknown or new viruses for which antivirus signatures have not yet been developed or deployed.
  8. Virus scanning. Microsoft IT chooses to delete infected attachments because of the sheer number of messages received daily. If an incoming message from the Internet contains a virus, the antivirus solution removes the attachment, and then forwards the message to the recipient. Microsoft IT does not notify the external sender, because the sender information might be forged and the notification might disclose sensitive information. For outgoing messages to the Internet, however, Microsoft IT notifies the internal sender so that the sender can check the local computer for viruses.
  9. Store threshold and user Safe Senders and Blocked Senders lists. Microsoft IT relies on two features available on Mailbox servers to fight spam: store threshold and user Safe Senders and Blocked Senders lists. Based on the message's SCL rating and the configured store threshold, the Mailbox server delivers the message to the user's Inbox or Junk E-mail folder. Microsoft IT uses a value of 5 for the store threshold, which means that the Mailbox servers route messages with an SCL rating between 5 and 7 to the Junk E-mail folder. Users can override filtering of junk e-mail according to their individual preferences through the Safe Senders list and the Blocked Senders list.
  10. Outlook client version control. The Safe Senders list and Blocked Senders list, in addition to the Microsoft SmartScreen filter and security hotfixes, are available to users of Microsoft Office Outlook 2003, Microsoft Office Outlook 2007, and Microsoft Office Outlook Web Access. To ensure that users can take advantage of the security features built into the latest versions of Office Outlook, Microsoft IT enforces client version control in its messaging infrastructure by proactively blocking older versions of Office Outlook clients.
  11. Client-side spam filtering. In addition to the Safe Senders list and Blocked Senders list, users can customize settings for filtering of junk e-mail. The Office Outlook feature for filtering of junk e-mail analyzes messages upon their arrival at the client. Users can choose the level of protection they want, ranging from no protection to allowing messages from safe senders only. Office Outlook moves messages identified as spam to the Junk E-mail folder.
  12. Attachment and Web beacon blocking. To achieve an additional level of protection, Microsoft IT uses attachment and Web beacon blocking, available in Office Outlook. Attachment blocking at the client level helps to prevent virus propagation within the internal messaging environment. Web beacon blocking helps to protect messaging privacy. Office Outlook prevents Web beacon access by automatically blocking external content.
  13. Antivirus software. Microsoft IT requires all client computers in its managed environment to have non-Microsoft antivirus software installed, configured, running, and kept up to date. Consistently enforcing client-layer antivirus defenses through technical controls and policies also enables Microsoft IT to eliminate virus-related threats from non-messaging sources. For example, antivirus software on users' computers helps prevent file-level infections and viruses that propagate through network connections.

Exchange Server 2007 Messaging Protection

The in-depth defense strategy that Microsoft IT implemented by using Exchange Server 2003 with SP2 achieved effective messaging protection to the extent that user impact from spam, phishing, and virus attacks was minimal. However, like many large companies, Microsoft continues to receive increasingly sophisticated security threats. Consequently, Microsoft IT must continuously revise its strategies, implementations, and procedures for combating spam, viruses, and other e-mail attacks.

Exchange Server 2007 with SP1 provides further opportunities for Microsoft IT to increase the efficiency of its in-depth defense strategy through new features available on Edge Transport servers and new solutions such as Forefront Security for Exchange Server. The technologies available with Exchange Server 2007 provide the following key advantages for Microsoft IT:

  • Increased security through a perimeter network. By deploying Edge Transport servers with Forefront Security for Exchange Server in a perimeter network that is separate and not trusted or internal to the corporate environment, Microsoft IT can reduce the risk of internal resources' exposure and compromise. Edge Transport servers do not need to access Active Directory domain controllers. Via the EdgeSync service, Hub Transport servers communicate pertinent recipient and configuration information in encrypted form to Edge Transport servers. Edge Transport servers maintain this Active Directory Domain Services (AD DS) information in encrypted form locally on the server. Furthermore, Edge Transport servers fully integrate with the transport permissions model of Exchange Server 2007. Anonymous SMTP hosts on the Internet are not trusted. Accordingly, Edge Transport servers remove message headers that contain internal information before sending the messages to the Internet and stamp all messages received from the Internet as anonymous.

    Forefront Security for Exchange Server installed on the Edge Transport servers provides edge protection from both viruses and spam. Forefront Security for Exchange Server augments the Edge role by providing the maximum level of protection in the most efficient and secure manner. For more information about how Microsoft IT deployed Edge Transport servers, see the section "Deployment of Edge Transport Servers" later in this white paper.

  • Adaptive filtering. Edge Transport servers proactively respond to new messaging threats and spam campaigns. For example, sender reputation functionality enables Edge Transport servers to identify and block sources of spam and harmful messages automatically for a configurable period. In addition, Microsoft IT configured Exchange Server Edge Transport servers to perform additional spam detection. The Exchange Server 2007 IP reputation filter uses a frequently updated IP Block list to block traffic from known spam sources. SmartScreen performs advanced heuristic detection in addition to checking against known spam signature data. All of these capabilities receive updates automatically multiple times per day through the Microsoft Update service. Forefront Security for Exchange Server enables Forefront Antispam Automatic Updates, an update service that performs frequent checks to Microsoft Update for spam signature data and Microsoft IP Reputation Service data instead of checking for updates for all applications on the host computer, which is the way the native Exchange Server 2007 signature update process works. Because of the time sensitivity of spam signatures and the spam signatures' frequent modification, the Forefront Antispam Automatic Updates service ensures that the spam filtering that Exchange Server provides is always current. Updating this information several times per day ensures a high accuracy of connection filtering in addition to content filtering capable of recognizing even the most recent campaigns.
  • Fewer false positives. Edge Transport servers can decrease the number of e-mail messages incorrectly identified as spam (false positives) through new features and technologies, such as aggregation of safe-list information and Office Outlook 2007 E-Mail Postmarks. By propagating safe-sender and recipient information of Office Outlook users to the Edge Transport servers, the Edge Transport servers can include this user-based information in the content-filtering process, which increases the precision of spam filtering. If the originator of a message uses Office Outlook 2007, the receiving Edge Transport servers can also analyze the postmark that the Office Outlook 2007 client added to the message in the form of a custom message header. The presence of the postmark indicates that the message is likely to be legitimate and should be delivered to the recipient's Inbox folder.
  • Lower TCO. Microsoft IT lowers direct and indirect costs by using Exchange Server 2007. For example, after replacing the 32-bit Internet mail gateway servers with more-powerful 64-bit Edge Transport servers running Forefront Security for Exchange Server, Microsoft IT can perform attachment removal and virus scanning directly in the perimeter network. The Routing Hub servers that performed these tasks in the Exchange Server 2003 environment are no longer necessary. Decommissioning these servers leads to direct cost savings because of lower maintenance requirements.

    Indirect cost savings relate to reduced administrative overhead associated with server deployment and configuration. Indirect cost savings also relate to increased system resilience and dependability through advanced features, such as connection tarpitting, SMTP backpressure, open proxy discovery, harmful-message detection, and Extensible Storage Engine (ESE)–based message queues, as explained later in this paper.

  • Lower administrative overhead. Edge Transport servers provide new features to simplify system administration and maintenance. For example, Microsoft IT updates most of the settings on Edge Transport servers automatically through Forefront Security for Exchange Server and Microsoft Update or through one-way replication of AD DS data through EdgeSync. In addition to the intuitive user interface (UI), Exchange Management Shell scripts make efficient enterprise configuration possible. Microsoft IT uses custom Windows PowerShell„¢ scripts to build new Edge Transport servers in a consistent and rapid way. The scripts configure the basic transport settings, receive connectors, and antispam features. Subsequently, Microsoft IT uses EdgeSync to complete the configuration.
  • Multilevel virus scanning. Microsoft IT deploys Forefront Security for Exchange Server not only on Edge Transport servers but also on all Hub Transport servers in the corporate production environment. The Edge Transport servers in the perimeter network scan all incoming messages from the Internet and stamp the messages by adding a security-enhanced antivirus header, so that Hub Transport servers do not have to scan the messages a second time. The same principle applies to outgoing message transfer. Hub Transport servers scan all outgoing messages before the messages reach the Edge Transport servers. Based on the security-enhanced antivirus header, Edge Transport servers can recognize that an outgoing message does not require an additional virus scan, which avoids processing overhead while maintaining an effective level of antivirus protection for all incoming, outgoing, and internal e-mail messages. It also enables Microsoft IT to deploy the Exchange Server 2007 Mailbox servers without Forefront Security for Exchange Server. Microsoft IT decided not to deploy Forefront Security for Exchange Server on Mailbox servers to avoid the processing overhead associated with real-time virus scanning at the level of the Exchange Information Store. A lack of antivirus scanning on the Mailbox servers does not introduce an internal virus vulnerability. All messages are sent to a Hub Transport server for categorization even if the originator and recipient of an e-mail message reside within the same database on a Mailbox server. Because scanning is enabled on the Hub Transport server, all traffic is scanned regardless of whether the destination is internal or external to the organization.

Spam and Virus Filtering Through Exchange Server 2007

Figure 3 shows how Microsoft IT optimized messaging protection by using Exchange Server 2007. The Edge Transport servers now perform the bulk of the antispam and antivirus processing. Hub Transport servers do not rescan messages that the Edge Transport servers already stamped as scanned by using the antivirus header, but they perform message processing based on transport rules and journaling policies to enforce regulatory compliance. The antispam and antivirus mechanisms on Exchange Server 2007 Mailbox servers and Office Outlook clients remain largely unchanged. Elements that Microsoft IT did not change from Exchange Server 2003 to Exchange Server 2007 have a gray background in the figure.

Exchange Server 2007 messaging protection at Microsoft

Figure 3. Exchange Server 2007 messaging protection at Microsoft

Transport Agents on Edge Transport Servers

Exchange Server 2007 introduces the concept of transport agents, which are managed software components that perform tasks in response to SMTP transport or routing events. The Edge Transport process (EdgeTransport.exe) invokes the agents during the SMTP session and afterward, prior to message routing.

Installation of Transport Agents

Exchange Server 2007 includes 10 Edge Transport agents. Additional agents can be installed for advanced processing, such as antispam and antivirus. For instance, Forefront Security for Exchange Server adds an agent to the Edge Transport server named FSE Routing Agent. The FSE Routing Agent integrates the antivirus solution with the Edge Transport subsystem to scan messages in Multipurpose Internet Mail Extensions (MIME) and UNIX-to-UNIX Encoding (UUENCODE) formats. Table 1 lists the transport agents installed on Edge Transport servers and their functions.

Table 1. Transport Agents on Edge Transport Servers at Microsoft

Agent name



Connection Filtering Agent

Performs host IP address filtering based on IP Allow lists, IP Allow list providers, IP Block lists, and IP Block list providers.

Exchange Server 2007

Address Rewriting Inbound Agent

Modifies recipient SMTP addresses in incoming messages based on predefined address alias information. Address rewriting can be useful in scenarios where an organization wants to hide internal domains.

Exchange Server 2007

Edge Rule Agent

Processes all messages received over SMTP to enforce transport rules defined on the Edge Transport server.

Exchange Server 2007

Sender ID Agent

Determines whether the sending SMTP host is authorized to send messages for the SMTP domain of the message originator.

Exchange Server 2007

Recipient Filter Agent

Verifies that the recipients specified during the SMTP session through the RCPT TO: command are valid and not on the list of blocked SMTP addresses and domains.

Exchange Server 2007

Sender Filter Agent

Verifies that the sender specified in the MAIL FROM: command and in the message header is valid and not on the list of blocked SMTP addresses and domains.

Exchange Server 2007

Content Filter Agent

Uses SmartScreen technology to assess the contents of incoming messages to assign an SCL rating for junk e-mail processing based on transport and store thresholds.

Exchange Server 2007

Protocol Analysis Agent

Interacts with Connection Filtering, Sender Filtering, Recipient Filtering, and Sender ID agents to determine the Sender Reputation Level (SRL) rating and to take action based on rating thresholds.

Exchange Server 2007

Attachment Filtering Agent

Filters messages based on attachment file name, file name extension, or MIME content type to block potentially harmful messages or remove critical attachments.

Exchange Server 2007

Address Rewriting Outbound Agent

Modifies sender SMTP addresses in outgoing messages based on predefined address alias information. Address rewriting can be useful in scenarios where an organization wants to hide internal domains.

Exchange Server 2007

FSE Routing Agent

Connects to the Transport stack to ensure that the FSCTransportScanner process scans messages prior to delivery to Hub Transport servers.

Forefront Security for Exchange Server

Configuration of Transport Agents

By default, all transport agents are enabled on Edge Transport servers. However, at the time of the initial Exchange Server 2007 deployment, Microsoft IT did not perform address rewriting, because Microsoft employees use the same SMTP domain name internally and externally (such as microsoft.com and exchange.microsoft.com). Accordingly, Microsoft IT disabled the corresponding transport agents. The following output of the Get-TransportAgent cmdlet shows the configuration of transport and routing agents that Microsoft IT uses on Edge Transport servers.

Identity Enabled    Priority
-------- ------- --------
Connection Filtering Agent True 1
Address Rewriting Inbound Agent False 2
Edge Rule Agent True 3
Content Filter Agent True 4
Sender Id Agent True 5
Sender Filter Agent True 6
Recipient Filter Agent True 7
Protocol Analysis Agent True 8
Attachment Filtering Agent False 9
Address Rewriting Outbound Agent    False 10
FSE Routing Agent True 11

Processing of Transport and Routing Events

The Get-TransportAgent cmdlet lists all registered agents in the order of their priority. However, this priority does not reflect the order in which the Edge Transport process invokes the transport and routing agents. The order depends primarily on the sequence of SMTP transport and routing events for which the agents are registered. For example, the SMTP OnConnectEvent event occurs before the OnEhloCommand event, so agents registered for OnConnectEvent run before agents registered for OnEhloCommand. The priority determines only the order within each event category. If multiple agents are registered for the same event, the priority determines which agent runs first, next, and last when this event fires.

The following listing outlines precisely the sequence of events that occur when an Edge Transport server receives a message from the Internet, in addition to the agents registered to process these events.

Event TransportAgents
----- ---------------
OnConnectEvent {Connection Filtering Agent}
OnHeloCommand {}
OnEhloCommand {}
OnAuthCommand {}
OnEndOfAuthentication   {}
OnMailCommand {Connection Filtering Agent, Sender Filter Agent}
OnRcptCommand {Connection Filtering Agent, Recipient Filter Agent}
OnDataCommand {}
OnEndOfHeaders {Connection Filtering Agent, Sender Id Agent, Sender Filter Agent, Protocol Analysis Agent}
OnEndOfData {Edge Rule Agent, Content Filter Agent, Protocol Analysis Agent}
OnHelpCommand {}
OnNoopCommand {}
OnReject {Protocol Analysis Agent}
OnRsetCommand {Protocol Analysis Agent}
OnDisconnectEvent {Protocol Analysis Agent}
OnSubmittedMessage {FSE Routing Agent}
OnRoutedMessage {}

Note: The Get-TransportPipeline cmdlet lists all transport and routing agents on Edge Transport and Hub Transport servers in the order of the events for which they are registered.

Connection Filtering

The Microsoft IT approach to connection filtering on Edge Transport servers uses the same principles applied for the messaging defense strategy for Exchange Server 2003 with SP2. As shown in Table 2, Microsoft IT classifies incoming SMTP hosts based on their IP addresses and performs appropriate actions, such as denying the incoming connection or bypassing all further antispam checks.

Table 2. SMTP Host Classification and Connection Filtering Action





Trusted sources

IP Allow list

Bypass spam filtering

SMTP hosts in this category belong to partners, vendors, or other types of business associates whose messages are always trusted.

Non-trusted sources

Not listed in any block or allow list

Perform spam filtering

Messages from unauthenticated SMTP hosts must pass through the pipeline of transport agents for spam filtering to reduce the number of unwanted messages that enter the corporate messaging environment.

Offensive sources

IP Block list or IP Block list provider

Block connection

These are known spammers or sources of phishing messages, viruses, or other harmful content.

The following sections explain the Microsoft IT approach to connection filtering in more detail.

Connections from Trusted Sources

Microsoft IT uses the IP Allow list on Edge Transport servers to exempt the IP addresses of SMTP hosts from partners and other business associates from spam filtering. This configuration helps to decrease the number of false positives, because messages from these sources are supposed to reach the recipients' Inboxes regardless of the spam characteristics the messages may have.

Microsoft IT also uses the IP Allow list as a temporary measure to support legitimate senders who are accidentally placed on a block-list provider's list. For example, a block-list provider might list a legitimate sender as a spammer if the sender's SMTP host is configured as an open relay. Depending on the responsiveness of the block-list provider, removal of the incorrect IP address entry from the block list may take some time. Accordingly, Microsoft IT grants temporary exceptions that automatically expire after 30 days by using the Add-IPAllowListEntry cmdlet. Self-expiring IP Allow list entries lower administrative overhead.

Note: Messages from SMTP hosts on the IP Allow list bypass the antispam agents in the SMTP transport pipeline but not the FSE Routing Agent. The FSE Routing Agent performs virus scanning after the SMTP engine passes the messages to the categorizer (OnSubmittedMessage event).

Connection Blocking

Microsoft IT uses the administrator-defined IP Block list and real-time block lists from non-Microsoft providers to identify SMTP hosts from which Edge Transport servers should deny message transfer, as follows:

  • Administrator-defined IP Block list. Microsoft IT uses this list to combat mail flooding and other forms of messaging attacks that originate from a single IP address or range of IP addresses. New in Exchange Server 2007 is the Sender Reputation feature, which Microsoft IT uses to maintain entries on the IP Block list dynamically. If a sender's reputation level exceeds the configured block threshold of 8, the Edge Transport server adds the sender to the IP Block list for 24 hours. Edge Transport servers continuously evaluate the sender's reputation for all incoming messages. In addition, Microsoft provides a globally managed list of known senders and their reputations to Exchange Server 2007 customers through Microsoft Update. The "Protocol Analysis" section later in this white paper discusses the Sender Reputation feature in more detail.
  • Real-time block lists. Microsoft IT uses multiple non-Microsoft real-time block lists to check the sending SMTP host's IP address against a database of known spammers by using a Domain Name System (DNS) query. If the DNS query receives a positive response from a block-list provider, the Connection Filtering Agent rejects the connection. If the first block-list provider does not identify the host as a spammer, Edge Transport servers check the second provider, and so forth. Using multiple non-Microsoft block-list providers increases the reliability of connection filtering. Table 3 lists the criteria that Microsoft IT uses to select appropriate block-list providers.

Table 3. Microsoft IT Selection Criteria for Real-Time Block-List Providers




Quality refers to the probability that an IP address on the list is a true spammer. Block-list providers have varying processes for determining which IP addresses to add to their lists. Some use a single verification process that adds IP addresses immediately to the block list when the sender appears to be a risk. Some providers require additional verification or multiple steps before adding an IP address to the block list. With multiple verifications, the chance of false positives decreases, which is why Microsoft IT prefers these providers.

Quality also refers to the ease of removal when a provider incorrectly adds an IP address to the block list. Microsoft IT evaluates the complexity of the delisting procedure, the responsiveness of the provider, the type of proof the provider requires, and whether the provider offers service level agreements (SLAs) that control the listing and delisting of IP addresses.


Microsoft IT compares costs among block-list providers to determine the value gained for the price paid for the subscription. Some block-list providers are more expensive than others and may offer extra services that Microsoft IT does not require.


Microsoft IT prefers block-list providers that support Exchange Server 2007 natively and make it easy for Microsoft IT to report false positives.

DNS zone transfer

Real-time block lists rely on DNS queries. Because of high message volume, Microsoft IT's Edge Transport servers perform approximately 50,000–100,000 DNS queries per hour on average. Accordingly, Microsoft IT must use block-list providers that support incremental DNS zone transfers, so that the Edge Transport servers can use a local copy of the block-list database.

A common recommendation is for large organizations with SMTP gateways that perform 250,000 or more block-list queries per day to use block-list copies maintained on local DNS servers through zone transfers.


The effectiveness of connection filtering depends to a certain degree on the reliability and availability of the block-list provider's DNS infrastructure. Microsoft IT considers various aspects, such as geographic location, diversity of DNS servers, number of DNS servers, bandwidth and connection failover, and load distribution. Ideally, the block-list provider offers SLAs that define the availability level.

Customized Error Message on Connection Blocking

If an incoming SMTP host is on a block list, the Edge Transport server returns a 550 5.7.1 SMTP error and a customized error message to tell the sending host why Microsoft refused the connection and what steps the sender can take to resolve the problem. For example, the sender might want to contact the block-list provider to request delisting of the blocked IP address.

The following is an example of a custom error message that Microsoft IT returns to incoming SMTP hosts listed in the real-time block list of spamhaus.org. It is important to note that Microsoft IT specified an SMTP address as an exception in the configuration of the real-time block list so that the sender can contact Microsoft despite the fact that the sender's SMTP host is on the block list.

    550 5.7.1 E-mail rejected because 213.2xx.xx.x is listed by spl-xbl.spamhaus.org.
    Please see http://www.spamhaus.org/lookup.lasso for more information.

Sender Filtering

When Microsoft IT faces spamming situations during which senders transmit large numbers of unwanted e-mail messages, sender filtering provides a means to block these messages. Microsoft IT blocks spammers who engage in deliberate campaigns to deluge Edge Transport servers by placing senders, domains, or subdomains on the Blocked Senders list.

The Sender Filtering Agent implements the sender block-list functionality by checking the data that senders specify after the SMTP MAIL FROM: command and in the FROM: SMTP header, which contains the sender's e-mail address and domain. If the sender's address is blank, the Edge Transport server drops the connection. Otherwise, the Sender Filtering Agent checks the sender's e-mail address and domain against the Microsoft IT–configured sender block lists on the Edge Transport server. For those senders on the list, the Edge Transport server rejects the message and drops it, generating a protocol error and no NDR. This is the case even if senders are on the Office Outlook Safe Senders list.

Recipient Lookup

For e-mail messages that come from non-authenticated, external sources, Microsoft IT uses the Recipient Lookup feature of Edge Transport servers to verify that the specified recipients exist before accepting messages. This lookup feature requires information about valid recipients to be available on the Edge Transport servers. The Exchange EdgeSync service, running on the internal Hub Transport servers, replicates this recipient information in the form of encrypted hash values to the ADAM instances on Edge Transport servers.

ADAM Dependencies

The ADAM instance on Edge Transport servers stores AD DS information in a security-enhanced manner. The Exchange EdgeSync service replicates only the most vital AD DS data, such as hashed recipient information, to Edge Transport servers. To enable ADAM in the production environment, Microsoft IT configured network and Exchange Server settings, including the following:

  • Edge Subscription. Each Edge Transport server requires an individual Edge Subscription to populate ADAM with AD DS data from the internal corporate forest to enable recipient lookup and safe-list aggregation. The subscription helps to reduce the administrative overhead of managing each individual Edge Transport server, and it ensures that all Edge Transport servers use the same configuration. The Exchange EdgeSync service replicates the following data over an encrypted channel from AD DS to ADAM: send connector configuration, Hub Transport server list, accepted domains, remote domains, message classifications, Safe Senders lists, and recipient information.
  • Synchronization. Synchronization occurs at fixed intervals to ensure that Edge Transport servers have the latest AD DS data. The Exchange EdgeSync service replicates configuration changes every hour and changes to recipient information every four hours. These intervals are not configurable. If changes to configuration data must be available on Edge Transport servers immediately, Microsoft IT uses the Start-EdgeSynchronization cmdlet to trigger a manual synchronization cycle and Test-EdgeSynchronization (new in Exchange Server 2007 with SP1) to validate the state of the synchronization for both user and connector modifications.
  • Firewall ports. Exchange Server ADAM uses nonstandard Lightweight Directory Access Protocol (LDAP) ports on Edge Transport servers for EdgeSync communication. Unsecured LDAP connections use TCP port 50389, and secured LDAP connections use TCP port 50636. To enable secured EdgeSync communication, Microsoft IT opened TCP port 50636 from the internal network to the perimeter network firewall that separates the Edge Transport servers from the Hub Transport servers in the corporate production environment.

Note: Although Microsoft IT uses the Windows Server 2003 platform for the Edge Transport services, Windows Server 2008 is fully supported and uses AD LDS instead of ADAM.

Connection Tarpitting

In combination with Recipient Lookup, Microsoft IT uses connection tarpitting on Edge Transport servers to slow SMTP responses when the SMTP reply code is a 5yz error. According to the SMTP standard, messaging hosts reply with 5yz errors if the received command was not accepted and the requested action did not occur (such as "550 Requested action not taken: mailbox unavailable").

During a regular SMTP session, after the sender passes sender filtering and submits the RCPT TO: command, Recipient Lookup checks the validity of the recipient. For invalid recipients, the Edge Transport server returns a 550 reply code to inform the sending SMTP host that the message will not be delivered. Spammers can misuse this procedure to verify e-mail addresses. During a directory harvest attack, spammers iterate through all possible combinations by using a brute force method and store valid recipients for later spam campaigns. Slowing SMTP 5yz responses based on a tarpitting interval of five seconds helps Microsoft IT render directory harvest attacks impractical for spammers.

Recipient Filtering

In addition to Recipient Lookup, Microsoft IT uses recipient filtering on incoming mail to block messages addressed to specific recipients. Edge Transport servers determine which recipients are valid, either based on an administrator-defined Recipient Block list or based on the results from Recipient Lookup. Messages addressed to the following types of recipients are blocked:

  • Nonexistent recipients. Microsoft IT blocks delivery to recipients who are not in the global address list (GAL).
  • Restricted distribution groups. Microsoft IT blocks delivery to distribution groups that only internal employees use.
  • Outgoing-only mailboxes. Microsoft IT blocks incoming messages addressed to mailboxes that should never receive messages from the Internet.

During recipient filtering, the Edge Transport server returns one of two possible responses to the sending Internet host based on the nature of the recipient, as shown in Table 4.

Table 4. Recipient Filtering Responses




550 5.1.1 User unknown SMTP session error

  • Incoming message contains a recipient who is on the Recipient Block list
  • Incoming message contains a recipient who does not match any recipients in Recipient Lookup

Block message

250 2.1.5 Recipient OK SMTP response

  • Recipient is not on the Recipient Block list and is in Recipient Lookup

Send message to the next antispam agent for processing

Sender ID

Edge Transport servers implement the latest version of the Sender ID framework to prevent spoofing, in which a malicious sender impersonates another sender or domain. Spoofed mail is an e-mail message that has a modified sending address, which appears as if it originates from a sender other than the actual sender of the message.

The Sender ID framework enables IT organizations to evaluate the credibility and identity of remote Internet mail hosts for incoming messages and to maintain the credibility and identity of their Internet mail hosts for outgoing messages. For example, to maintain credibility and enable recipients to verify the identity and authority of Microsoft outgoing servers, Microsoft IT configured DNS records to comply with the Sender ID framework. Only the Edge Transport servers in the perimeter networks of Redmond and Silicon Valley and the outgoing Edge Transport servers in Dublin and Singapore are authorized to send messages to Internet destinations for Microsoft. Accordingly, Microsoft IT configured DNS sender policy framework (SPF) records for all of these authorized Edge Transport servers.

The Sender ID Agent on Edge Transport servers attempts to verify that every incoming message originates from the Internet domain from which it claims to have been sent. When outgoing messages arrive at the Edge Transport servers, the receiving servers determine the domain name or IP address from the Institute of Electrical and Electronics Engineers (IEEE) Request for Comments (RFC) 2822 message headers (Resent-Sender, Resent-From, Sender, and From) or based on the information specified after the IEEE RFC 2821 MAIL FROM: command if none of the message headers is present. The servers then compare it against a registered list of servers that the domain owner has authorized to send messages. Sender ID does this by querying the DNS SPF records to determine what action to take on an incoming message.

The Sender ID evaluation process results in a Sender ID status for the message. Microsoft IT currently accepts all messages, regardless of Sender ID status. Accepting all messages helps Microsoft IT maintain low false positives. Table 5 shows the actions that Microsoft IT takes based on the Sender ID status.

Table 5. Microsoft IT Sender ID Status Actions

Sender ID status




The IP address for the Purported Responsible Address (PRA) is in the permitted set.



A fail status is returned when the domain does not exist, the sender is not permitted, there is a malformed domain, or no PRA is found in the header. Regardless of the cause, the IP address for the PRA is in the not-permitted set.


Soft Fail

The IP address for the PRA may be in the not-permitted set.



Published Sender ID data is explicitly inconclusive.



The receiving server encountered a transient error, such as an unavailable DNS server.



There is an unrecoverable error, such as an error in the record format.



No Sender ID records are published in DNS for the domain.


The Sender ID Agent adds the Sender ID status to each message in the form of an antispam stamp (X-MS-Exchange-Organization-SenderIdResult message header) to preserve this information for later processing. The Connection Filtering Agent and the Junk E-mail Filter in Office Outlook 2007 use the Sender ID status as part of the SCL rating calculation to determine the likelihood that the message is spam.

Protocol Analysis

Microsoft IT relies on the Protocol Analysis feature on Edge Transport servers to reduce administrative overhead associated with maintaining IP Block lists to stop disreputable senders and prevent DoS attacks. Edge Transport servers can identify spammers and other malicious senders based on several characteristics and block their connections. For example, by using open proxy discovery and sender reputation analysis, Edge Transport servers can identify and block possible sources of spam automatically.

Figure 4 shows the architecture of the Protocol Analysis Agent. The Protocol Analysis Agent gathers IP address and domain information about the sender at the SMTP protocol layer and uses this information to compute an SRL, which the agent maintains together with the sender's IP address in a local sender reputation database. The Protocol Analysis Agent automatically puts offensive senders with a low reputation on the IP Block list for the Connection Filtering Agent. The Content Filter Agent also uses the SRL as part of the SCL rating calculation.

Protocol Analysis Agent architecture

Figure 4. Protocol Analysis Agent architecture

To supplement local reputation data, Microsoft IT uses IP reputation updates from the Microsoft Technology Care and Safety team, which also contain sender IP addresses and associated SRLs. The Protocol Analysis Agent receives the latest filtering and IP reputation definition files through the Microsoft Update client. A Protocol Analysis background process incorporates the data into the local sender reputation database and places entries with a low reputation on the IP Block list.

Calculation of Sender Reputation Level

The SRL is a numerical value from 0 through 9 that represents the likelihood that a specific sender is not legitimate (for example, is a spammer, a botnet, or a dictionary attack). If the Protocol Analysis Agent assigns a sender an SRL value above a configurable SRL threshold value or if the SRL rating is determined to be above the threshold based on the IP reputation definitions provided through Microsoft Research, the sender appears on the IP Block list and the Edge Transport server refuses further connections from this sender. The default SRL threshold value is 7.

To calculate the SRL, the Protocol Analysis Agent uses the following data in its calculation logic:

  • Sender SCL rating analysis. The Protocol Analysis Agent communicates with the Content Filter Agent and uses the SCL rating to help determine an SRL rating. Like the SRL, the SCL is a numerical rating from 0 through 9, where a higher number indicates a higher probability of spam. The Protocol Analysis Agent uses three pieces of data about the sender SCL to help determine the SRL. First, the agent checks the number of messages in the past that had a low SCL rating. Second, the agent checks the number of past messages that had a high SCL rating. This information is combined to produce a ratio. The ratio helps determine an average of the SCL rating of messages from the sender. Third, the agent calculates the number of messages that had a high SCL rating in the previous 24 hours, and it recalculates the overall SCL data to help assign an accurate SRL. The previous 24 hours are important, because sender servers can become compromised and subject to a spam campaign.
  • Reverse DNS lookup. Both the Sender ID Agent and the Protocol Analysis Agent perform DNS lookups. The Sender ID Agent prevents spoofing by checking the DNS SPF record to verify that the sending server is listed in DNS. The Protocol Analysis Agent queries DNS on the IP address to get the domain name. After the reverse DNS query returns the domain associated with the originating IP address, this domain is compared to the domain submitted during the HELO or EHLO command. When domains do not match, a greater chance exists that the sender is malicious or a spammer.
  • Open proxy test. Proxies are intermediary servers between two other devices. They relay packets, often hiding the original IP address. Open proxies differ from other proxy servers in their configuration. Open proxies are configured to accept all connections from anyone and forward them to the requested destination. Although some proxies are configured as open proxies, most of the time, an open proxy results from a poor configuration or a compromised server. Botnets, spammers, and malicious attackers often use open proxies to hide the originating IP address.

    To check for an open proxy, the Protocol Analysis Agent on an Edge Transport server sends an SMTP request to the proxy and attempts to make a connection back to the Edge Transport server. To accommodate the many proxy protocols, the agent supports protocols such as SOCKS 4, SOCKS 5, Hypertext Transfer Protocol (HTTP), Telnet, Cisco, and Wingate. If the proxy receives the SMTP request and sends back a response, the agent has verified that the proxy is open. At this point, the Protocol Analysis Agent collects this data and uses it in combination with the SMTP command check to calculate an SRL rating.

  • SMTP command check. In SMTP protocol communication, when a sender submits the HELO or EHLO command, the sender specifies the originating domain or IP address. Spammers use many strategies at this point to bypass filters. Examples include submitting a local domain as originating, using an IP address that is different from the originating IP address, using a domain that is different from the one assigned to the IP address, and providing a different unique HELO or EHLO identifier for each message in a short period. There is a greater chance that the sender is malicious or a spammer when HELO or EHLO submissions like these occur. The Protocol Analysis Agent assigns a higher SRL in such cases.

Header Filtering

Microsoft IT deployed Edge Transport servers in the perimeter network not only to provide a high level of security for AD DS data communication through ADAM, but also for security-enhanced message property propagation through header filtering. The Edge Transport server architecture includes transport components, such as a header firewall, in the send and receive connectors that provide security for message properties. By using the header firewall, Edge Transport servers remove sensitive message headers from messages addressed outside the organization.

Edge Transport servers distinguish between two scenarios for outgoing message flow:

  • Authenticated communication. Trusted, authenticated communication for Edge Transport servers occurs when known participants communicate over an encrypted channel. For example, Edge-to-Edge or Edge-to-Hub communication is trusted and authenticated when the Edge Transport servers subscribe to the internal Active Directory domain and authenticate through Transport Layer Security (TLS). In both cases, the SMTP connectors that are involved recognize the communication as trusted and allow transmission of all headers.
  • Unauthenticated communication. Non-trusted, unauthenticated communication for Edge Transport servers occurs when Edge Transport servers transmit e-mail messages to external SMTP hosts. Before sending messages to external hosts, Edge Transport servers remove all internal information from the headers.

Header Content

Hub Transport and Edge Transport servers use custom message headers to stamp messages with diagnostic information about spam and virus filtering. Although Edge Transport servers remove these stamp headers when messages leave the organization, incoming messages transferred from Edge Transport servers to Hub Transport servers and messages sent within the organization retain the header data. Detailed information about antispam stamps is available in the Exchange Server 2007 online documentation at http://technet.microsoft.com/en-us/library/bb124558.aspx.

Microsoft IT uses the following antispam stamps on incoming messages to determine what actions to take if messages are incorrectly identified as legitimate (false negatives) or incorrectly identified as spam (false positives):

  • Antispam report. The Content Filter Agent provides a summary report of the antispam filters applied to a message in the form of a message header: X-MS-Exchange-Organization-Antispam-Report: DV:<DATVersion>;CW:CustomList;PCL:PhishingVerdict <verdict>;P100:PhishingBlock;PP:Presolve;SID:SenderIDStatus <status>;TIME:<SendReceiveDelta>;MIME:MimeCompliance.
  • Phishing confidence level (PCL) stamp. The Office Outlook Junk E-mail Filter stamps each processed message with a PCL rating according to the likelihood that the content represents a phishing attempt. The PCL stamp is displayed as a custom header as follows: X-MS-Exchange-Organization-PCL:<status>.
  • SCL stamp. When the Content Filter Agent evaluates message content to assign an SCL rating, that rating persists in the e-mail message as an SCL header stamp: X-MS-Exchange-Organization-SCL:<status>. Microsoft IT uses this stamp for the content filtering threshold on Edge Transport servers and the store threshold on Mailbox servers.
  • Sender ID stamp. When the Sender ID Agent evaluates a sending mail host, as explained earlier, the agent stamps the message with the following header to persist the status information: X-MS-Exchange-Organization-SenderIdResult: <status>. Microsoft IT relies on the Sender ID stamp when calculating SCL ratings.

Rule Processing

Edge Transport servers can process incoming and outgoing messages through Edge Rule Agent and transport rules. A transport rule defines conditions based on message subject and body characteristics and actions to perform when a message matches the conditions, such as to drop or redirect the message. Microsoft IT validated the transport rule feature during pilot deployments under the premises of a zero-day virus outbreak and DoS attacks. Although Microsoft IT does not use transport rules on Edge Transport servers in the corporate production environment during normal operation, the Edge Rule Agent might be used specifically to address the following types of message threats:

  • New viruses. When new viruses attack the corporate messaging network, virus definitions are not typically instantly available (zero-day virus outbreak). As a result, there is a window where the antivirus filters may not filter out infected messages. A transport rule can delete the messages whose properties match those of the latest known viruses.
  • DoS attacks. Most DoS attacks based on e-mail messages have commonalities that the Protocol Analysis Agent can recognize. Sender reputation is the basis on which to add offensive senders automatically to the IP Block list for the Connection Filtering Agent. However, DoS attacks that use a large number of compromised computers on the Internet might still be able to bypass the connection filtering. Based on common characteristics, such as certain text in the subject line or message body, transport rules can minimize the impact of a DoS attack on the messaging environment.

Content Filtering

After eliminating roughly 95 percent of attempted incoming message submissions through connection, sender, and recipient filtering, Edge Transport servers perform content filtering to assess the probability that an incoming message is legitimate or spam. Specifically, the Content Filter Agent performs various calculations by using key words and phrases, weighted words, sender reputation, and Sender ID status to arrive at an SCL rating between 0 and 9 for each message. The Content Filter Agent implements the latest version of the IMF based on patented machine-learning technology from Microsoft Research.

Based on the SCL rating, the Edge Transport servers can perform actions such as deleting or rejecting messages. Microsoft IT prefers not to delete messages silently (that is, delete messages that exceed the delete threshold without a response to the sending host). Rather, Microsoft IT rejects all messages with an SCL rating of 7 or above, and the sending host is informed.

Exchange Server 2007 also supports a quarantine message threshold, which Microsoft IT evaluated and validated during pilot deployments. However, in the corporate production environment, Microsoft IT does not yet quarantine messages on Edge Transport servers because of the administrative and Helpdesk overhead associated with managing quarantined messages. Messages with an SCL rating of 6 or below reach the Mailbox servers, where the store threshold and the recipient's safe-list information determine whether the message appears in the Inbox or the Junk E-mail folder.

Note: Microsoft IT employs a strategy with the Connection Filtering Agent in Exchange Server 2007 similar to the one that it used with the Exchange Server 2003 IMF, except that Microsoft IT updates spam signatures and sender reputation information much more frequently by using Microsoft Update, as explained earlier in this paper.

Outlook E-Mail Postmark Validation

In addition to the IMF, the Content Filter Agent implements Office Outlook E-Mail Postmark validation. The E-Mail Postmark is a computational proof that Office Outlook applies to outgoing messages to help recipient messaging systems distinguish legitimate e-mail from junk e-mail. Microsoft IT uses it as an added tool to reduce false positives. With postmark validation, the Content Filter Agent parses the incoming message for a postmark header. The presence of a valid, solved computational postmark header in the message indicates that the client computer that generated the message solved the computational postmark.

Computers do not require significant processing time to solve individual computational postmarks. However, processing postmarks for numerous messages may be prohibitive to a malicious sender. Anyone who sends millions of spam messages is unlikely to invest the processing power that is required to solve computational postmarks for all outgoing spam. If a sender's e-mail contains a valid, solved computational postmark, the sender is unlikely to be malicious. In this case, the Content Filter Agent lowers the SCL rating. If the postmark validation feature is enabled and an incoming message does not contain a computational postmark header or the computational postmark header is not valid, the Content Filter Agent does not change the SCL rating.

Safe List Aggregation

Safe List Aggregation is a feature in Exchange Server 2007 that helps to decrease the number of e-mail messages incorrectly identified as spam on Edge Transport servers. Safe List Aggregation consolidates the Safe Senders list, Safe Recipients list, Blocked Senders list, and external contacts that reside in the user's mailbox. For each entry for a safe sender and safe recipient, the feature can compute a 256-bit hash value by using the Secure Hash Algorithm (SHA)-256 algorithm, and it stores the resulting array sets as binary large objects (BLOBs) in the msExchangeSafeSenderHash and msExchangeSafeRecipientHash attributes of the user's AD DS account. After the information resides in AD DS, the Exchange EdgeSync service can replicate the information to the ADAM instance running on each Edge Transport server so that the Content Filter Agent on the Edge Transport server can include this information in the content filtering process. The Content Filter Agent can then pass safe e-mail messages, such as those from business partners and personal contacts, to the user's mailbox without additional processing by other spam filters. The messages arrive at the user's Inbox folder even if certain message characteristics would identify these messages as spam.

To perform safe-list aggregation, Microsoft IT uses the Update-SafeList cmdlet. This cmdlet can update the msExchangeSafeSenderHash and msExchangeSafeRecipientHash attributes in AD DS for the specified user if the user's safe-list collection has changed. However, in Exchange Server 2007, the Content Filter Agent does not act on safe recipients' data. For this reason, Microsoft IT uses the Update-SafeList cmdlet only to update the msExchangeSafeSenderHash attribute, which corresponds to the default behavior of the cmdlet. Updating only the msExchangeSafeSenderHash attribute ensures that only relevant data is pushed into AD DS and replicated to Exchange Server ADAM.

Because the process of updating safe-list information can generate a significant amount of replication traffic, Microsoft IT runs the Update-SafeList cmdlet on a scheduled basis during non-peak hours. Each data center with Mailbox servers (that is, Redmond, Dublin, Singapore, and Sao Paulo) uses a separate schedule to perform regional updates at 16:00 local time. In this way, the updates do not interfere with other local mailbox or network maintenance processes, while AD DS replication and EdgeSync replication have enough time to transfer the updates to the Edge Transport servers before the start of the next business day.

Attachment Filtering

Prior to scanning attachments for viruses, Microsoft IT minimizes the processing work that antivirus software performs by removing certain attachments based on size, file type or file name extension, and MIME content type. Edge Transport servers running Forefront Security for Exchange Server can take one of the actions indicated in Table 6 to filter attachments.

A critical capability in any antivirus or antispam solution is to have separate message processing based on whether the message is incoming to or outgoing from the organization or whether the message flow is internal in the organization.

Microsoft IT uses Forefront Security for Exchange Server to develop directionally aware antivirus rules and policies based on where the message originates and its destination. As an example, Microsoft IT blocks all executable file attachments incoming to Microsoft, because these types of files are common carriers for Trojan attacks. But Microsoft IT may allow these files to be sent internally to aid in the development of new software.

Table 6. Attachment Filtering Actions

Filtering action

Result for sender

Result for recipient

Block message and attachment

The sender receives a delivery status notification (DSN) message, which states that the message contains an unacceptable attachment. The sender can attempt to resend the message.

The recipient receives no notification of delivery failure.

Remove attachment and allow message

The sender assumes that the e-mail transmission is successful unless the recipient indicates otherwise. Microsoft IT uses this setting.

The attachment is not received. The recipient can request that the attachment be resent or delivered through other methods. Microsoft IT uses this setting.

Silently drop

The sender receives no notification of delivery failure.

The recipient receives no notification of delivery failure.

Antivirus Protection

Microsoft IT chose Forefront Security for Exchange Server to help protect the corporate messaging environment from viruses because of its close integration with Exchange Server 2007 with SP1. By using Forefront Security for Exchange Server on Edge Transport and Hub Transport servers, Microsoft IT can avoid the performance overhead related to virus scanning on Mailbox servers. This is possible because Forefront Security for Exchange Server supports antivirus stamps in message headers. Forefront Security for Exchange Server does not rescan a message that contains an antivirus stamp. Because Microsoft IT uses the antivirus stamp process, most messages are free from viruses when they arrive at a Mailbox server, requiring little additional processing.

Performing antivirus checking for all message flows helps protect the organization by checking all incoming and internal mail, and it helps protect contacts and the organization's reputation by checking all outgoing mail. This again highlights the importance of correctly detecting the direction of mail flow if the organization applies different rules.

As shown in Figure 5, incoming messages to the organization receive both antispam and antivirus checking at the Edge Transport server. After the message is scanned, it is marked as safe to avoid duplicate antivirus checking at the Hub Transport server. When the Hub Transport server delivers the message to a Mailbox server, the message's safe flag is cleared so that when the message is resent or forwarded, it is scanned again. The same process applies to outgoing mail; messages are scanned at the Hub Transport server, marked as safe, and then forwarded to the Internet through the Edge Transport server without duplicate checking.

Message scanning process

Figure 5. Message scanning process

For antivirus, all messages are scanned. If malicious software is detected, the appropriate action occurs. Forefront Security for Exchange Server has multiple options for dealing with infected content. The message can be rejected in its entirety, the attachment can be cleaned of malicious software, or the attachment can be removed. Microsoft IT chooses to simply delete the offending attachment rather than spend the processing time to clean the attachment of malicious software. Microsoft IT can therefore ensure that the recipient of the message receives it and is notified of the antivirus action taken.

Forefront Security for Exchange Server has advanced capabilities for detection of malicious software, which includes the ability to check files that are stored within archive stores such as .zip and .cab files. When a virus is found in a file, a text attachment replaces the original attachment with a description of the malicious software found. This text attachment also applies to malicious software found in archived files; a text file replaces the problem file in the archive.

To help protect the integrity of the organization, Microsoft IT does not sent security notifications to external originators of traffic that contains malicious software. Only the internal party is notified of malicious-software detection and actions. This lack of notification to external parties is important for several reasons:

  • Providing security notifications about threat detection gives malicious parties an understanding of the organization's threat-detection mechanisms and may help them exploit the organization in future attempts.
  • Originator e-mail address information is often spoofed in virus-infected spam, which means that notifications may not reach the correct recipient.
  • Notifications that a large number of virus-infected e-mail messages trigger might cause a DoS to a legitimate sender whose address was spoofed.

Forefront Security for Exchange Server integrates several partner antivirus engines, including Computer Associates, Sophos, and Kaspersky Labs.

With multiple antivirus engines, a new threat that a specific engine may not detect is likely to be identified by one of the other configured engines. Each engine maintains its own specific signature files or proactive detection methods, reducing exposure and providing maximum certainty that messages are virus free. Using multiple engines means that if a single engine experiences a problem and goes offline, the remaining engines will continue scanning (a process called bias certainty). In this way, protection continues during scheduled maintenance, such as an engine updating its virus signature information. Microsoft IT uses the maximum number of antivirus engines (five), selected based on each engine's individual strengths for specific types of protection. Microsoft IT sets the bias to Max Certainty to ensure that all engines can evaluate each message for potential threats.

For Microsoft IT, when an engine updates itself, messages will queue to ensure that all engine providers have the opportunity to scan the message for threats. The environment is scaled to ensure that all five engines can conduct antivirus scanning for every message, and that the scanning will not degrade the overall messaging flow. Forefront Security for Exchange Server provides maximum protection through its "block on fail" design, which means that if an enabled engine cannot open or scan the payload of a message, the message is blocked.

In addition to the messaging-level protection that Forefront Security for Exchange Server offers for the Edge Transport, Hub Transport, and Mailbox servers, Microsoft IT maintains file-level antivirus protection on all aspects of the environment to protect the infrastructure element of the messaging environment. Correct configuration ensures that harmful scanning does not occur on structures that the file antivirus mechanism does not understand, such as the Exchange Server databases and log files. In addition, many antivirus engines can scan processes, which again can be problematic. Therefore, Microsoft IT excludes specific processes. For detailed information about the exclusion configuration for Exchange Server 2007 and its specific role services, see "File-Level Antivirus Scanning on Exchange 2007" at http://technet.microsoft.com/en-us/library/bb332342%28EXCHG.80%29.aspx.

Client-level protection is also critical, because messaging is just one aspect of a complete solution for defeating malicious software. Microsoft IT implements Office Outlook–aware client antivirus engines and updates them regularly in conjunction with a firewall solution, which is centrally configured through technologies such as Group Policy.

Spam Detection on Mailbox Servers

When messages arrive at the Mailbox server for delivery to recipient mailboxes, the various filters, agents, and scans have eliminated the vast majority of spam. Some messages, however, fall in the middle between known spam and legitimate messages. For example, messages may come from a legitimate sender addressed to a valid recipient but contain questionable text that the IMF evaluates as having a 50 percent chance of being spam. Microsoft IT allows users to determine what to do with these messages by using the store SCL threshold, as shown in Figure 6.

Mailbox server messaging protection

Figure 6. Mailbox server messaging protection

The store SCL threshold on Mailbox servers follows the delete, reject, and quarantine thresholds. When the store driver attempts to make a delivery to a user's mailbox, the Mailbox server must determine the rating of the message and place it in either the user's Inbox or Junk E-mail folder. Microsoft IT sets the store SCL threshold to 5. Mailbox servers deliver messages that exceed the threshold to the recipient's Junk E-mail folder and all other messages to the Inbox.

Microsoft IT configures Exchange Server to perform antispam checking for incoming mail only. Microsoft has specific capabilities that employees can use for large-scale sending, such as newsletters, and employees are implicitly trusted not to send out spam; therefore, outgoing spam detection is not required.

Forefront Security for Exchange Server provides flexible handling of messages that are found to be spam or that contain malicious software. With the advanced spam-detection technology and the high confidence in the accuracy of detection, Microsoft IT does not enable the quarantine capabilities of Forefront Security for Exchange Server. These quarantine capabilities enable users to be notified of the messages that were found to be spam and if the users have administrative permissions they have access to the quarantine area. The amount of spam that Microsoft receives makes quarantining spam time-ineffective and would carry significant operational cost when applied to the nearly 200,000 mailboxes that Microsoft maintains. If organizations require user-accessible Web-based quarantine, they should consider Exchange Hosted Filtering Services, which is described in the "Exchange Hosted Filtering Services" section later in this document.

Client Protection

Microsoft IT's goal was to focus antispam and antivirus processing on one server role that is segregated from the internal network. Nevertheless, in keeping with the policy to use multiple levels of protection, Microsoft IT also uses the following features and strategies at the client level to combat spam and viruses:

  • Junk E-mail Filter. Based on SmartScreen technology, the Junk E-mail Filter evaluates factors such as message time, content, and structure to rate the likelihood of a spam message. Microsoft IT enables users to flag messages by using the Junk E-mail Filter and delete or move messages to the Junk E-mail folder.
  • Attachment and Web beacon blocking. Both Office Outlook 2003 and Office Outlook 2007 support attachment and Web beacon blocking. Microsoft uses these features to help protect users from internal viruses, phishing, and spammers who attempt to validate e-mail addresses through Web beacons.
  • Outlook version control. Edge Transport servers automatically retrieve Safe Senders and Blocked Senders lists only from clients running Office Outlook 2003 or Office Outlook 2007, including Outlook Web Access. Microsoft IT blocks Office Outlook clients from accessing mailboxes earlier than Office Outlook 2003.
  • Real-time desktop virus scanning. Microsoft IT uses non-Microsoft antivirus software on all client computers. The antivirus software scans all files continuously in real time and retrieves updated virus definitions automatically. Through logon scripts and update checks, Microsoft IT ensures that all employees run the latest version of the antivirus software, along with updated virus definitions, on the corporate network. If a user does not run the antivirus solution or uses outdated virus definitions, Microsoft IT notifies the user to install or update the antivirus software within a specified time frame. If the user does not install antivirus software within the specified time frame, Microsoft IT denies access to the network until the user runs up-to-date antivirus software and virus definitions.

Exchange Hosted Filtering Services

Whereas Edge Transport servers perform spam filtering and virus scanning for recipients in the microsoft.com domain, Microsoft IT uses Exchange Hosted Filtering Services to add e-mail security to the windows.microsoft.com and winse.microsoft.com domains. Exchange Hosted Filtering Services is a fully managed service that provides antispam, antivirus, policy filtering, and disaster recovery to e-mail domains. Using Exchange Hosted Filtering Services does not require installation or deployment of any software or hardware. Only a Mail Exchanger (MX) record change is required to route all incoming e-mail for a domain to the Exchange Hosted Services network for filtering. Similarly, outgoing e-mail can be routed to Exchange Hosted Filtering Services for virus scanning and policy enforcement, although Microsoft IT does not use this option. Exchange Hosted Filtering Services updates spam and virus signatures multiple times each day and uses multiple antivirus engines to help protect organizations from spam and viruses.

Figure 7 shows the flow of e-mail with Exchange Hosted Filtering Services used as a component of e-mail security. Incoming e-mail is scanned for spam, viruses, and policy violations based on policy rules that the e-mail administrator creates. Filtered business e-mail is delivered to the organization's e-mail server or servers as specified in the Exchange Hosted Filtering Services administration console. If the destination server is not available, Exchange Hosted Filtering Services queues the e-mail and attempts to resend queued e-mail every 20 minutes until the delivery is successful.

Microsoft IT Exchange Hosted Filtering Services mail flow

Figure 7. Microsoft IT Exchange Hosted Filtering Services mail flow

For more information about Exchange Hosted Filtering Services or any of the services in Exchange Hosted Services, see the Microsoft Online Services article "Protection & Preservation for E-Mail" at http://www.microsoft.com/exchange/services. For details on hosted filtering, see the Microsoft TechNet article "Stopping Junk E-Mail with Exchange Hosted Filtering" at http://technet.microsoft.com/en-us/exchange/bb676292.aspx.

Deployment of Edge Transport Servers

Before deploying a messaging-protection system based on Edge Transport servers, Microsoft IT considered many factors and asked questions about both the business and technical requirements. For example, to determine business requirements, Microsoft IT gathered statistical data about messaging trends, such as the number of spam e-mail messages per day. To determine technical requirements, Microsoft IT translated business requirements to messaging capacity in terms of server size and performance requirements in terms of message processing capacity.

Project Stages

By using the Microsoft Operations Framework (MOF) as a basis for designing and implementing a messaging-protection solution, Microsoft IT planned to implement the Edge Transport servers in stages to evaluate the existing environment, understand the requirements, plan a strategy, deploy systems, and maintain the new environment. For more information about MOF, go to http://www.microsoft.com/technet/itsolutions/cits/mo/mof/default.mspx.

To simplify organization and clarify communication among teams, Microsoft IT used the following four-stage approach in the Edge Transport deployment project:

  1. Planning. The planning phase entailed gathering business requirements, translating them to server and network needs, and purchasing the necessary hardware to deploy. At this point, the project leads also estimated the necessary time to complete the deployment.
  2. Testing. Microsoft IT deployed test builds of software in a small production environment. After testing, Microsoft was confident enough in the Exchange Server 2007 Beta 2 release to deploy it in the corporate production environment.
  3. Rollout. During the rollout phase, Microsoft IT systematically replaced Internet mail gateway servers with Edge Transport servers. The deployment progressed in several stages. Microsoft IT first focused on the servers located in Redmond, followed by the servers in Silicon Valley and in regional data centers. While deploying the new Edge Transport servers and retiring the Internet mail gateway servers, Microsoft IT deployed Forefront Security for Exchange Server. Microsoft IT thus maintained a hybrid model with the Routing Hub servers running Antigen for SMTP until the last Internet mail gateway server was decommissioned. As mentioned earlier in this paper, Microsoft IT eliminated the Routing Hub servers with the deployment of Exchange Server 2007 and now runs Forefront Security for Exchange Server on all Edge Transport and Hub Transport servers in the production environment. Running Forefront Security for Exchange Server lowers administrative overhead and increases the effectiveness and efficiency of antivirus protection.
  4. Maintenance. After deployment, Microsoft IT fine-tuned settings to ensure optimal performance of the messaging-protection solution. By using EdgeSync and custom setup scripts, Microsoft IT ensures that all Edge Transport servers use the same configuration. Furthermore, Microsoft IT deployed and configured Microsoft Systems Management Server (SMS) 2003 Desired Configuration Monitoring (DCM) version 2.0 to maintain the desired configuration and report settings that do not comply with the optimal configuration.

Design Considerations

To meet the project goals of protection at multiple layers while decreasing exposure of internal resources and AD DS data, Microsoft IT decided to implement Edge Transport servers in a perimeter forest, as shown in Figure 8.

Conceptual design of Microsoft IT Edge Transport and messaging defense

Figure 8. Conceptual design of Microsoft IT Edge Transport and messaging defense

Implementing Edge Transport servers in the perimeter forest offers the following advantages for Microsoft IT:

  • Forest and AD DS segregation. The isolated network is physically and logically separate from the corporate production environment. The forest is not trusted or joined to the corporate forest. Any necessary AD DS data is published securely to the perimeter environment through the Exchange EdgeSync service and limited to a small subset of overall data.
  • Network layer protection. Two firewalls, limited open ports, and logical network segregation provide protection to the corporate production forest. Microsoft IT restricts the ports on the external firewall and internal firewall as follows:
    • External firewall. For communication from the perimeter network to the Internet, Microsoft IT opened port 25 for SMTP, port 53 for DNS resolution and reverse DNS lookups, and port 80 for antivirus signature and protocol definition updates. For communication from the Internet to the Edge Transport servers, only port 25 is necessary to support SMTP.
    • Internal firewall. For communication from the corporate network to the perimeter network, Microsoft IT opened port 25 for SMTP, port 3389 for Terminal Services, and port 50636 for the Exchange EdgeSync service. For communication from the perimeter network to the corporate environment, only port 25 is necessary to support message transfer from Edge Transport servers to Hub Transport servers through SMTP.
  • Streamlined administration. By using Systems Management Server DCM 2.0 and Microsoft Operations Manager (MOM) 2005 in the perimeter network, Microsoft IT automates configuration management audits and system monitoring of Edge Transport servers. For example, Microsoft Operations Manager alerts inform Microsoft IT if an Edge Transport server performs atypically so that Microsoft IT can respond quickly to resolve the problem and restore the normal level of operation. This ability helps to ensure a high quality of service for legitimate message submissions. Forefront Security for Exchange Server is also fully monitored by both Microsoft Operations Manager and Microsoft System Center Operations Manager 2007 through management packs that Microsoft provides. These management packs contain in-depth information about key metrics for Forefront Security for Exchange Server performance and preemptive troubleshooting capabilities.
  • Reduced attack layer. With servers hardened against attacks and with limited and encrypted corporate AD DS data, fewer attack points are available, and corporate network resources are not exposed.
  • Security. In the perimeter network, Microsoft IT deploys all servers with only the necessary services and open ports. Server hardening for Edge Transport servers is explained later in the section titled "Security Configuration of Edge Transport Servers." This details the best practices for the service and port configurations applicable to Exchange.

Configuration of Server Hardware

According to the message volumes that Microsoft IT noticed in the past during DoS attacks and because Edge Transport servers perform virus scanning in addition to spam filtering, Microsoft IT decided to retain six servers for incoming Internet mail—the same number as with Exchange Server 2003. Four additional servers in regional data centers provide outgoing message transfer for users not located in North America. This arrangement supports efficient outgoing message transfer without compromising security, provides load balancing for incoming traffic, and avoids single points of failure in the perimeter networks of Redmond and Silicon Valley.

For the individual Edge Transport servers, Microsoft IT based the hardware requirements on performance testing, product group recommendations, and future growth expectations. After comparing the available options, Microsoft IT chose two dual-core microprocessors and 8 gigabytes (GB) of memory. This design was based on Exchange Server 2007 Beta 2 requirements, months before the exact specifications were known for the final release. Anticipating higher requirements in the final build, Microsoft IT also allowed for extra memory and storage capacity. Table 7 lists the exact server specifications that Microsoft IT decided to use for the initial deployment of Edge Transport servers.

Table 7. Edge Transport Server Hardware and Details

Hardware or requirement

Details and assumptions

Reasons for decision


  • Two dual-core AMD Opteron 2.2 gigahertz (GHz)


  • 8 GB
  • Extra capacity for future growth.

Disk input/output (I/O)

  • Queue database size should not exceed 12 GB (250,000 messages; 50 kilobytes [KB] per message), which is less than 10% of the redundant array of independent disks (RAID) volume. In this condition, disk array will be capable of more than 500 write operations per second—enough to facilitate a throughput of about 200 messages per second, so the disk subsystem will not be a bottleneck.
  • ESE-based queues rely on transaction logs and database files so that no messages are lost if an unexpected server outage occurs. Database and transaction logs reside on separate sets of disks.
  • ESE-based queues are capable of holding up to 1 million messages.
  • Harmful-message detection is a safeguard against messages that cause processing failures on Edge Transport servers.


  • Two 72-GB disks in a RAID 1 configuration for operating system and transaction logs—50 GB used for the operating system and 20 GB used for transaction log files.
  • Four 146-GB disks in RAID 0+1 for a total of 292 GB for Exchange Server files.
  • By design, an Edge Transport server does not keep messages in its queue database after successful message delivery. Database could grow during spam or DoS attack to a certain level, but SMTP backpressure mitigates the issue. Expected to be less than 12 GB (250,000 messages, 50 KB per message).
  • SMTP backpressure is a means of controlling the receipt rate of incoming messages during high-volume message transmissions.
  • Excess disk capacity supports the ability to perform mail-flow troubleshooting for two weeks of mail.

Implementation of Edge Transport

After Microsoft IT considered the risks and dependencies, analyzed business needs, and calculated server hardware requirements, the Edge Transport implementation team moved forward with the deployment and configuration of Edge Transport servers.

The primary implementation concern was security. Edge Transport servers communicate with anonymous Internet hosts and process millions of e-mail messages daily. In this role, they are a primary target for attacks at the SMTP level in addition to spam and viruses. Furthermore, Edge Transport servers communicate with internal Hub Transport servers. In this role, they must shield the corporate production environment from DoS and other forms of attacks. Edge Transport servers must not create direct visibility to the protected production environment by bridging otherwise separate networks.

Another consideration was the mix of filtering agents and thresholds to use. When a spam filter existed in Exchange Server 2003, Microsoft IT relied on those settings as a basis for the Exchange Server 2007 configuration. Other settings were tested and fine-tuned according to internal Microsoft requirements.

In many cases, the default configuration settings on Edge Transport servers proved sufficient. In the default configuration, all spam-filtering agents are enabled on Edge Transport servers to provide a very high level of messaging protection out of the box. Moreover, a Microsoft Security Configuration Wizard template is available on the Exchange Server 2007 installation media to automate security best practices for reducing the attack surface of Exchange Server 2007 servers. Microsoft IT used the Security Configuration Wizard template to harden the Edge Transport server configuration. Additionally, Microsoft IT worked with the operations, security, and engineering teams to design a security-enhanced configuration of Edge Transport servers. In the security review, Microsoft IT audited the configuration for threats and tested the proposed server hardening approach against messaging issues such as DoS attacks, spam, spoofing, and viruses.

Microsoft IT created a systematic approach to deploying Edge Transport servers that included the following steps:

  1. Definition of perimeter network. The first step that Microsoft IT performed in preparation for the deployment of Edge Transport servers involved the preparation of the existing perimeter network. Specifically, Exchange Server 2007 enabled Microsoft IT to reduce the attack surface of the internal firewall, because Edge Transport servers need to establish connections to only selected Hub Transport servers by using TCP port 25 for SMTP.
  2. Hardware provisioning and installation. Microsoft IT provisioned rack space and IP addresses, purchased the server hardware, and then deployed the Edge Transport servers. Microsoft IT did not immediately replace the existing Internet mail gateway servers. During a period of coexistence with Exchange Server 2003, Edge Transport servers acted as gateway servers, along with Exchange Server 2003 Internet mail gateway servers. This staged deployment enabled Microsoft IT to ensure availability and fine-tune settings for optimum performance.
  3. Security review. After network and server installation, Microsoft IT reviewed security settings and reduced the attack surface, as explained in the section "Security Configuration of Edge Transport Servers" later in this white paper.
  4. Firewall configuration. To enable Edge Transport servers to accept communication from the Internet and communicate with the internal servers in the corporate production environment, Microsoft IT configured the following resources:
    • Router access control list (ACL) entriesf or message transfer between the perimeter network and the corporate network, so specific Edge Transport servers can communicate with specific Hub Transport servers.
    • A virtual IP address on the external firewall for each Edge Transport server, so the firewall can accept traffic from the Internet directed to the virtual IP address and send it to the corresponding Edge Transport server in the perimeter network. The virtual IP address is a public IP address assigned to the public network interface on the external firewall. The Edge Transport server uses a private IP address. A server-publishing rule on the external firewall maps the public virtual IP address to the private IP address of the Edge Transport server. Because Microsoft IT uses six Edge Transport servers for incoming message transfer (three in Redmond and three in Silicon Valley), six virtual IP addresses had to be provisioned (three on the external firewall in Redmond and three on the external firewall in Silicon Valley) to support the Edge Transport servers for incoming messages.
    • Secure network address translation (SNAT) for outgoing message transfer to the Internet on the external firewall. SNAT provides a security-enhanced mechanism for translating the private IP address of each Edge Transport server into its corresponding virtual IP address. Internet clients are not aware of the address translation. Internet clients see the public IP address as the source address in the IP packets. However, for Edge Transport servers to act as SNAT clients, the internal IP address of the external firewall must be specified as the default gateway address in the TCP/IP properties of the Edge Transport servers.
    • Certificates for Edge Transport servers to establish security-enhanced message paths with business partners over the Internet. Microsoft IT is planning to use mutual TLS authentication for Domain Security. Mutual TLS authentication requires the use of X.509 certificates from a trusted certification authority (CA). Each Edge Transport server requires a separate certificate. For more information about Domain Security and TLS, see the topic "Managing Domain Security" in the Exchange Server 2007 online documentation at http://technet.microsoft.com/en-us/library/bb124996.aspx.
  5. Monitoring. Microsoft IT uses Microsoft Operations Manager servers in the perimeter network to monitor all aspects of the environment, such as to track mail flow and gather statistics. Accordingly, Microsoft IT performed a manual deployment of Microsoft Operations Manager agents on all Edge Transport servers and approved these manual installations in the Microsoft Operations Manager Administrator console. In addition, Microsoft IT configured Systems Management Server DCM 2.0 to centrally monitor the configuration settings on all Edge Transport servers.
  6. Edge Transport configuration. To associate Edge Transport servers with the internal Exchange Server organization, Microsoft IT created an Edge Subscription for each Edge Transport server in the AD DS site of Redmond to perform one-way replication of AD DS data to Exchange Server ADAM. The configuration procedure that Microsoft IT used followed recommendations of the product development group, but it relied on manual processes to create messaging connectors through Windows PowerShell scripts. The scripts gave Microsoft IT more control over the configuration, which was especially important during the phase of coexistence with Exchange Server 2003, because all messages needed to pass through dedicated Routing Hub servers for virus scanning. Greater control over the connector configuration is also the reason why Microsoft IT continues to use script-based processes without Exchange Server 2003 in the environment. For more information about the Edge Transport configuration, see the section "Configuration of Send and Receive Connectors" later in this paper.
  7. Testing. After configuring hardware, mail settings, and monitoring, Microsoft IT tested incoming and outgoing mail flow and verified that message transfer and system monitoring functioned properly.
  8. DNS update. To complete the deployment, Microsoft IT published MX and host (A) records for the new Edge Transport servers so that Internet hosts can establish connections and transfer messages. Furthermore, Microsoft IT updated the SPF records in DNS to identify the Edge Transport servers as authorized messaging hosts according to Sender ID requirements. For detailed information about the DNS configuration of MX and A records, see the section "Redundancy and Load Balancing" later in this paper.

Configuration of Edge Transport Agents

Whereas SMTP connectors perform messaging-protection functions such as tarpitting and SMTP backpressure, transport agents filter message connections and content. Many agents work with the default settings and do not require additional configuration on the Edge Transport servers. For example, Sender ID relies on domain administrators to configure their SPF records in DNS correctly. Microsoft IT configures other agents on an automated or as-needed basis. The following sections summarize general agent settings that Microsoft IT configured on all Edge Transport servers.

Configuration of Connection Filtering

Microsoft IT uses IP Block list providers and locally maintained IP Block lists and IP Allow lists for connection filtering. By using the Protocol Analysis Agent and IP reputation updates from Microsoft Research, Edge Transport servers maintain the IP Block list entries automatically. Microsoft IT specifies IP Allow list entries on an as-needed basis by using the Add-IPAllowListEntry cmdlet to grant self-expiring exceptions, as explained in the section "Connection Filtering" earlier in this white paper.

Settings that relate to the connection-filtering configuration include:

  • IP Block List Providers. Microsoft IT specified the configuration settings according to information from the non-Microsoft block-list provider.
  • IP Allow List Providers. Not specified.
  • Sender Reputation Level. Microsoft IT uses the default configuration to perform an open proxy test when determining the sender confidence level, blocks senders with an SRL of 7, and adds these senders to the IP Block list for 24 hours.

Configuration of Recipient Filtering

Microsoft IT enabled the settings Block messages sent to recipients not listed in the recipient list and Block the following recipients in the properties of the Recipient Filtering Agent on all Edge Transport servers and specified the e-mail addresses for which Microsoft does not want to receive messages from anonymous Internet sources. Microsoft IT blocks messages to invalid recipients and to mailboxes and global distribution lists (DLs) that are for internal use only.

Configuration of Content Filtering

Apart from establishing the EdgeSync subscription on each Edge Transport server, Microsoft IT configured SCL thresholds for the Content Filter Agent on the Edge Transport servers and the Mailbox servers. Table 8 summarizes the configuration settings.

Table 8. Filtering Thresholds

Configuration setting



Delete messages

Not specified

Microsoft IT does not delete messages in the perimeter network.

Reject messages


A value of 7 represents a high probability that the message is spam. Microsoft configures the reject threshold at 7 and informs senders that message delivery failed. Senders can resend messages if necessary.

Quarantine messages

Not specified

Microsoft IT does not quarantine messages in the perimeter network.

Store threshold


Microsoft IT configures the store threshold globally for the Exchange Server organization by using the following command:

Set-OrganizationConfig -SCLJunkThreshold: 4

Accordingly, Exchange Server 2007 delivers messages with an SCL rating of 5 or higher to the recipient's Junk E-mail folder for later review. Messages with a rating of 4 or lower appear in the recipient's Inbox.

Attachment Filtering

Both Exchange Server 2007 and Forefront Security for Exchange Server include capabilities for filtering critical attachments. Critical attachments are those that correspond to Level 1 file types, blocked by default in Office Outlook 2007. For example, the Attachment Filtering Agent (enabled by default on Edge Transport servers) can detect critical attachments in e-mail messages based on file type or MIME content type. Forefront Security for Exchange Server, however, provides advanced features that are not available in the default Attachment Filtering Agent. For example, Forefront Security for Exchange Server can detect blocked file types within a container file (for example, .zip, .gzip, .jar, .tar, or .bin), even if the critical attachment has an arbitrary file name extension.

Because all Edge Transport servers run Forefront Security for Exchange Server, Microsoft IT uses Forefront Security for Exchange Server file filtering to remove critical attachments from e-mail messages. For a detailed listing of the Level 1 file types, see the topic "Attachment File Types Restricted by Outlook 2007" in the 2007 Office Resource Kit at http://technet2.microsoft.com/Office/en-us/library/bc667b4c-1645-42be-8dc0-af56dc11ef5b1033.mspx.

By using Forefront Security for Exchange Server, Microsoft IT reduces the workload on Edge Transport servers that are associated with virus scanning, because Forefront Security for Exchange Server removes the attachments before scanning the messages. Attachment filtering is also an effective countermeasure against zero-day viruses and other malicious code for which virus signatures do not yet exist in the definition databases on the Edge Transport servers.

Security Configuration of Edge Transport Servers

Through security audits and vulnerability analysis, Microsoft IT determined the steps necessary to provide security for Edge Transport servers—a procedure called server hardening. During the server-hardening process, Microsoft IT configured the following components:

  • Permissions for shares and the NTFS file system. Microsoft IT removed the Everyone group from all shared folders. All shares must have the security groups applied that contain only the users who need access to the shares. Microsoft IT does not apply open security groups—such as Authenticated Users, Domain Users, or Everyone—to shares.
  • Account management. Account passwords must be 15 characters or more and meet strong password requirements.
  • Patch management. Edge Transport servers must have all current security updates and Microsoft IT–created installation packs (IPAKs) installed. IPAK is an internally developed packaging tool for updates, hotfixes, and service packs. Microsoft IT creates IPAKs twice per year and monitors the installation of security updates and security configurations on server platforms by using Microsoft Baseline Security Analyzer (MBSA).
  • Virus protection. At the level of the operating system, Microsoft IT requires a file-level antivirus solution on all server platforms, updated to the current version, to help protect the server against conventional virus infections. The file-level antivirus solution scans the files on the hard disk and in computer memory. To avoid conflicts between the file-level antivirus solution and Exchange Server processes, such as by locking a transaction log or database file, Microsoft IT excludes all resources that Exchange Server 2007 uses from file-level virus scanning. Forefront Security for Exchange Server implements the Exchange Server–aware protection against e-mail–borne viruses.
  • Network adapter. Edge Transport servers use separate network adapter for communication with Internet hosts (external) and Hub Transport servers (internal). To provide an extra layer of port filtering, Microsoft IT configured the external network adapter to accept traffic only on TCP port 25, disabled NetBIOS over TCP/IP, and removed the binding for File and Printer Sharing for Microsoft Networks and Client for Microsoft Networks.
  • Services. Microsoft IT uses the Security Configuration Wizard to reduce the attack surface on Edge Transport servers further. For example, Microsoft IT disables all unnecessary services, such as Internet Information Services (IIS).

Redundancy and Load Balancing

To distribute the incoming Internet messages to all six of the Internet mail gateway servers, Microsoft IT uses DNS round robin and MX records that have the same preference value of 10. Microsoft DNS servers return MX records that have the same preference value in a random order to facilitate load balancing. However, Internet clients are not required to choose the first entry from the result set. Because all records have the same preference value, Internet clients can select any one of these MX records at random.

To ensure that load balancing occurs no matter which MX record an Internet client selects, Microsoft IT registered two A records for each MX record. The selected MX record points the Internet client to a specific mail host. The A records map the host name to two different IP addresses. The first IP address (131.107.xxx.xxx) refers to an Edge Transport server in Redmond, and the second IP address (205.248.xxx.xxx) refers to an Edge Transport server in Silicon Valley. The result is round-robin load balancing of incoming message traffic between the data centers.

The following name server lookup (nslookup) response shows the configuration of the public DNS zone for microsoft.com that Microsoft IT established for the Edge Transport servers.

    microsoft.com  MX preference = 10, mail exchanger = maila.microsoft.com

    microsoft.com  MX preference = 10, mail exchanger = mailb.microsoft.com 

    microsoft.com  MX preference = 10, mail exchanger = mailc.microsoft.com 

    maila.microsoft.com  internet address = 131.107.xxx.xxx

    maila.microsoft.com  internet address = 205.248.xxx.xxx

    mailb.microsoft.com  internet address = 131.107.xxx.xxx

    mailb.microsoft.com  internet address = 205.248.xxx.xxx

    mailc.microsoft.com  internet address = 131.107.xxx.xxx

    mailc.microsoft.com  internet address = 205.248.xxx.xxx

Note: Microsoft IT manages subdomains, such as windows.microsoft.com, exchange.microsoft.com, and winse.microsoft.com, for testing, for development, and for hosting users who participate in pilot deployments and sustained engineering. The DNS configuration for a subset of these subdomains differs from the preceding listing to route the corresponding Internet messages through Exchange Hosted Filtering Services, as explained earlier in this white paper.

Configuration of Send and Receive Connectors

To establish transfer paths for incoming and outgoing messages, Microsoft IT configures all Edge Transport servers with two receive connectors and four send connectors. The first receive connector faces the Internet and accepts incoming SMTP connections on TCP port 25 from unauthenticated sources and partner servers. Session authentication determines the permissions of the remote host on the receive connector for sending messages. The second receive connector faces the corporate production environment. The second receive connector accepts messages only from Hub Transport servers and uses Exchange Server authentication.

Three of the four send connectors that Microsoft IT uses enable Edge Transport servers to communicate efficiently with different types of messaging hosts on the Internet. The first send connector is dedicated to encrypted communication with remote domains that support TLS. Microsoft IT configures the second connector to communicate with destinations that do not support Extended SMTP. By forcing this connector to send the HELO command instead of the EHLO command, Microsoft IT avoids an unnecessary sequence of "EHLO, Failure Response 500, HELO"messages when establishing SMTP connections to these destinations. The third send connector is a general Internet connector that Edge Transport servers use for all destinations that do not match the address space definitions of the TLS and HELO connectors. Edge Transport servers use the fourth send connector to transfer incoming messages to Hub Transport servers in the corporate environment.

As shown in Figure 9, Microsoft IT uses different sets of send connectors on the Edge Transport servers in Redmond and Silicon Valley. The source server configuration parameter determines which servers a particular connector belongs to. The configuration of the send connectors is almost identical between the data centers, with the exception that the address spaces of the send connectors in Redmond have lower connector costs to establish a preferred route for outgoing messages through the Edge Transport servers in Redmond.

Send connector configuration on Edge Transport servers

Figure 9. Send connector configuration on Edge Transport servers

Microsoft IT performed the following steps to deploy the send and receive connectors on Edge Transport servers:

  1. After installing the Edge Transport servers, Microsoft IT removed all default connectors from the server configuration and manually created two receive connectors. Microsoft IT used the New-ReceiveConnector cmdlet to accept messages from the Internet and the corporate production environment separately.
  2. Microsoft IT created an Edge Subscription for each new Edge Transport server without automatic creation of send connectors. The New-EdgeSubscription cmdlet provides two parameters for this purpose, CreateInboundSendConnector and CreateInternetSendConnector. When running the New-EdgeSubscription cmdlet on the Hub Transport servers to import the Edge Subscription file, Microsoft IT sets both of these parameters to $false.
  3. By using the New-SendConnector cmdlet on a Hub Transport server, Microsoft created two sets of four send connectors. By using the SourceTransportServers parameter, Microsoft IT associated the send connectors in each set with the desired Edge Transport servers in Redmond or Silicon Valley. Send connectors to the Internet use DNS for message routing. HELO connectors have the ForceHELO parameter set to $true, and TLS connectors have the RequireTLS parameter set to $true. The mail routing configuration of the send connectors to the corporate environment specifies to forward all incoming messages to the Hub Transport servers in the Active Directory site of Redmond.
  4. By running the Start-EdgeSynchronization cmdlet, Microsoft IT replicated the send connector configuration to the new Edge Transport server. After the synchronization processes finish, Microsoft IT verifies that the connector configuration is available on each Edge Transport server.

Best Practices

Processing more than 20 million messages per day for nearly 200,000 mailboxes requires tremendous coordination, planning, administration, and monitoring. Microsoft IT used the Beta 2 release of Exchange Server 2007 to incorporate new goals and improvement ideas into a new strategy for messaging protection. From its experiences, Microsoft IT developed the following best practices that an organization can use when planning for and deploying Edge Transport servers and an overall solution for messaging protection:

  • Plan sufficiently. For businesses and messaging environments of all sizes, it is important to analyze the risks, dependencies, technical requirements, and trends for proper provisioning, hardware sizing, and workflow. Through planning, Microsoft IT was able to migrate 1,000 mailboxes per day from Exchange Server 2003 to Exchange Server 2007.
  • Use a perimeter network. A perimeter network helps protect internal network resources and gives administrators the capability to disable incoming mail flow easily in case of severe attacks. Servers on the perimeter network can be severely restricted in terms of open ports, services, permissions, and users. If servers are compromised, protective measures remain on corporate AD DS data. Microsoft IT decided to use a perimeter network for these reasons and to prepare for expansion to accommodate business growth.
  • Test before production. Microsoft IT deploys sample configurations and software builds in a test environment, and then tests configurations against typical loads to determine stability and analyze results. By testing Edge Transport servers before putting them in a live environment, Microsoft IT can minimize problems and their impacts on users.
  • Use multiple layers of protection. Microsoft IT filters out more than 95 percent of incoming messages because they are spam, contain viruses, or are otherwise not legitimate. That filtering success is the result of using multiple filtering layers, using multiple strategies for messaging protection, and enforcing protection at multiple levels in the organization.
  • Scan for spam before employing antivirus software. Microsoft IT examined its messaging statistics and discovered that most viruses that enter through messages come through spam messages. To reduce server processing and workload, Microsoft IT decided first to filter out all spam messages, thereby filtering out the majority of message-based viruses.
  • Update virus and reputation databases. New viruses and the constantly changing nature of spammer origins necessitate constant updates to spam signatures, IP reputation databases, and virus definitions. Microsoft IT configured the Edge Transport servers to receive updates to spam signatures and IP reputation information automatically. Microsoft IT also configured Forefront Security for Exchange Server to update virus definitions for the individual scanning engines daily.
  • Reject illegitimate messages. When connection filtering, recipient filtering, or sender filtering marks a message as illegitimate, it is best to reject the message and not quarantine it, because the confidence level in these types of filtering stages is very high. Microsoft IT configures custom SMTP replies to inform the sending host why the Edge Transport server refused the requested action.
  • Configure thresholds. As messages undergo more complex filtering, such as content filtering, additional variables might mistakenly identify a legitimate message as unwanted. To help lower false positives, Microsoft IT configures thresholds to quarantine mail and make it available for later administrative retrieval.
  • Remove attachments. Certain attachments, such as executable files and code, have the potential to damage recipient computers and can spread across the network. New viruses and other malicious code can cause damage because virus definitions may not be up to date. Filtering out specific attachments in the perimeter network reduces the chance that malicious attachments will cause damage.
  • Harden servers. Microsoft IT trusts Edge Transport servers to face the Internet because they sit behind a firewall and are restricted to the absolute essentials, thus limiting the attack surface. Only vital ports, services, and permissions, are enabled.
  • Use block and allow lists. To reduce processing, known illegitimate senders can be blocked and known legitimate senders can be allowed to pass through. Additionally, maintained real-time block lists provide updated information about known illegitimate senders. Filtering based on lists enables messages to be rejected early in the filtering process, minimizing server load and infrastructure impact.
  • Enforce client antivirus. Using logon scripts to enforce antivirus software configuration and keeping virus definitions updated help protect clients against viruses that come from messages and other sources.
  • Implement virus scanning for outgoing and incoming messages. Microsoft IT discovered that although keeping viruses out of the organization is crucial, so is dealing with viruses inside the organization. Virus scanning at the client desktop level controls viruses in general but not necessarily viruses present on outgoing messages. Therefore, it is important to scan for viruses on Edge Transport servers and Hub Transport servers.
  • Use multiple antivirus engines. Forefront Security for Exchange Server integrates multiple antivirus engines from industry leaders and can use up to five concurrently. Microsoft IT uses more than one engine in its implementation so that external parties cannot take advantage of weaknesses in a specific engine.
  • Do not send security notifications to Internet senders. Spammers often try to validate the identity of recipients or attempt to discover more about the network or settings of an SMTP server. By not sending notifications to Internet senders, Microsoft IT helps protect internal configuration data and reduces server load.
  • Configure antivirus to be aware of mail direction. Incoming messages from the Internet often are spam or contain viruses. Outgoing messages and internal messages typically are free from viruses. Microsoft IT configures different options for virus scanning based on e-mail direction. Therefore, antivirus software must be aware of e-mail direction.
  • Reduce server load for known illegitimate senders. Exchange Server 2007 features such as connection tarpitting and SMTP backpressure slow down connections to ensure that legitimate incoming and outgoing messages are processed.
  • Verify sender identity and reputation. Spammers and other illegitimate senders often hide their identities through open proxy servers, try to spoof their identities, or provide false identity information. By verifying sender IP and domain and keeping a reputation database through Edge Transport servers in Exchange Server 2007, Microsoft IT blocks and rejects unwanted connections.


Spam, viruses, malicious code, and other messaging issues cost companies money. The impact can include hard costs, such as increased server load and bandwidth use, and soft costs, such as employee productivity. For many years, Microsoft has used a system that effectively helps protect against messaging issues. With Exchange Server 2007 Edge Transport servers, the messaging-protection solution at Microsoft meets the latest business and technical demands to defend against new viruses, spam, phishing, and other messaging exploits.

Microsoft IT used the principle of multilayer, multistep messaging protection and developed a systematic approach to reducing unwanted messages. First, Microsoft IT helps protect internal network resources from the outside through a perimeter network. Second, Microsoft IT uses Edge Transport servers and their many filters to block as many unwanted messages as possible from entering the internal messaging environment. Third, Microsoft IT helps protect the internal environment by enforcing antivirus policies and enabling users to specify safe and blocked senders.

In deploying the Exchange Server 2007–based solution for messaging protection, Microsoft IT used features of Edge Transport servers and Forefront Security for Exchange Server to block, delete, reject, or quarantine unwanted messages. To further increase security, Microsoft IT hardened servers and audited them for vulnerabilities to ensure readiness for Internet visibility.

The many steps that Microsoft IT took to design a network environment, combined with the messaging-protection features of Exchange Server 2007, resulted in greater flexibility, fewer false positives, and reduced TCO. Microsoft IT continues to monitor the solution to optimize settings and is constantly vigilant against unwanted messages.

For More Information

For more information about Microsoft products or services, call the Microsoft Sales Information Center at (800) 426-9400. In Canada, call the Microsoft Canada Information Centre at (800) 563-9048. Outside the 50 United States and Canada, please contact your local Microsoft subsidiary. To access information through the World Wide Web, go to:



The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.


Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred.

© 2009 Microsoft Corporation. All rights reserved.

Microsoft, Active Directory, Forefront, Outlook, SmartScreen, Windows PowerShell, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

All other trademarks are property of their respective owners.