Microsoft Exchange Server 2007 Edge Transport and Messaging Protection

Transcription

1 Microsoft Exchange Server 2007 Edge Transport and Messaging Protection How Microsoft IT Prevents Spam, Viruses, Directory Harvesting, and Other Attacks Technical White Paper Published: January 2009

2 CONTENTS Executive Summary... 4 Messaging Protection Prior to Exchange Server Routing of Incoming Messages 6 Messaging Protection Through Exchange Server Exchange Server 2007 Messaging Protection Spam and Virus Filtering Through Exchange Server Transport Agents on Edge Transport Servers 14 Connection Filtering 17 Sender Filtering 20 Recipient Lookup 21 Recipient Filtering 22 Sender ID 22 Protocol Analysis 24 Header Filtering 26 Rule Processing 27 Content Filtering 27 Attachment Filtering 29 Antivirus Protection 30 Spam Detection on Mailbox Servers 32 Client Protection 33 Exchange Hosted Filtering Services Deployment of Edge Transport Servers Project Stages 36 Design Considerations 37 Configuration of Server Hardware 38 Edge Transport Implementation 39 Edge Transport Agent Configuration 42 Security Configuration of Edge Transport Servers 43 Redundancy and Load Balancing 44 Configuration of Send and Receive Connectors 45 Best Practices... 47

3 Conclusion For More Information... 50

4 Situation The increasing complexity and prevalence of spam, 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. Solution Microsoft IT used the features available in Exchange 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. Benefits Increased accuracy of spam filtering decreases unwanted messages and false positives. Automated maintenance of filter configurations and 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 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 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 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 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 Microsoft IT continues to use several of these message routing and protection strategies with Exchange Server This review provides the context for explanations of new technologies and options that influenced Microsoft IT's decisions for messaging protection with Exchange Server Microsoft Exchange Server 2007 Edge Transport and Messaging Protection Page 4

5 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. Microsoft Exchange Server 2007 Edge Transport and Messaging Protection Page 5

6 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 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 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. Microsoft Exchange Server 2007 Edge Transport and Messaging Protection Page 6

7 REDMOND DUBLIN REDMOND Perimeter Internet Mail Gateway Servers Routing Hub Servers Hub Servers Mailbox Servers Outbound Internet Mail Internet SILICON VALLEY Perimeter Internet Mail Gateway Servers Routing Hub Servers Hub Servers SINGAPORE Hub Servers Mailbox Servers SAO PAULO Outbound Internet Mail Administrative Group Mailbox Servers Routing Group Hub and Mailbox Server Messaging Connectors 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 Now, all Exchange Server 2007 servers involved in message transfer, including Edge Transport servers, perform virus scanning. Microsoft Exchange Server 2007 Edge Transport and Messaging Protection Page 7

8 Messaging Protection Through Exchange Server 2003 Microsoft IT established the routing topology shown earlier in Figure 1 with the deployment of Exchange Server 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 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 processing based on Spam Confidence Level (SCL) at the Mailbox servers; and additional attachment blocking, spam filtering, and virus scanning at the client computers. Internet Mail Gateway Server Routing Hub Server Mailbox Server Outlook 2003 Client Internet ` 1. Connection Filtering Allow/Deny IP lists Real time block lists 2. Sender Filtering 3. Recipient Lookup 8. Virus Scanning 7. Attachment Stripping For example:.dll,.exe,.cmd,.com,.js,.wsf, and.vbs 9. User Safe/Blocked Sender Lists and Store Threshold Inbox Junk 13. Antivirus Software Real-time scanning 12. Attachment and Web Beacon Blocking 4. Recipient Filtering 11. Client-Side Spam Filtering 5. Sender ID Lookup 6. Intelligent Message Filter 10. Outlook Client Version Control 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 Connection filtering. Approximately 88 percent of all Internet message submissions that Microsoft receives daily originate from known sources of spam and virus 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 Exchange Server 2007 Edge Transport and Messaging Protection Page 8

9 Microsoft IT also uses global allow lists to accept 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. Microsoft Exchange Server 2007 Edge Transport and Messaging Protection Page 9

10 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 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 folder. Users can override filtering of junk 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 . The Office Outlook feature for filtering of junk 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 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. Note: For detailed information about the messaging defense strategy Microsoft IT implemented with Exchange Server 2003 with SP2, see the technical white paper "Messaging Hygiene at Microsoft: How Microsoft IT Defends Against Spam, Viruses, and E- Mail Attacks" at Microsoft Exchange Server 2007 Edge Transport and Messaging Protection Page 10

11 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 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 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 Microsoft Exchange Server 2007 Edge Transport and Messaging Protection Page 11

12 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 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 userbased 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 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 Microsoft Exchange Server 2007 Edge Transport and Messaging Protection Page 12

13 protection for all incoming, outgoing, and internal 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 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 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. Microsoft Exchange Server 2007 Edge Transport and Messaging Protection Page 13

14 Exchange ADAM EdgeSync Active Directory Hashed Recipient and Safe Senders Information Safelist Aggregation Safe Recipients Lists, Safe Senders Lists, and External Contacts Edge Transport Server Hub Transport Server Mailbox Server Outlook 2007 Client Internet ` 1. Connection Filtering 2. Sender Filtering 14. Virus Scanning 13. Message Journaling 15. User Safe/ Blocked Sender Lists and Store Threshold 19. Antivirus Software Real-time scanning 3. Recipient Lookup 4. Recipient Filtering 12. Rules Processing Inbox Junk 18. Attachment and Web Beacon Blocking 5. Sender ID Lookup 17. Client-Side Spam Filtering 6. Protocol Analysis 7. Header Filtering 16. Outlook Client Version Control 8. Rule Processing Postmarks 9. Content Filtering 10. Attachment Filtering 11. Virus Scanning 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. Microsoft Exchange Server 2007 Edge Transport and Messaging Protection Page 14

15 Table 1. Transport Agents on Edge Transport Servers at Microsoft Agent name Function Product Connection Filtering Agent Address Rewriting Inbound Agent Edge Rule Agent Sender ID Agent Recipient Filter Agent Sender Filter Agent Content Filter Agent Protocol Analysis Agent Attachment Filtering Agent Address Rewriting Outbound Agent FSE Routing Agent Performs host IP address filtering based on IP Allow lists, IP Allow list providers, IP Block lists, and IP Block list providers. 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. Processes all messages received over SMTP to enforce transport rules defined on the Edge Transport server. Determines whether the sending SMTP host is authorized to send messages for the SMTP domain of the message originator. 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. 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. Uses SmartScreen technology to assess the contents of incoming messages to assign an SCL rating for junk processing based on transport and store thresholds. 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. Filters messages based on attachment file name, file name extension, or MIME content type to block potentially harmful messages or remove critical attachments. 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. Connects to the Transport stack to ensure that the FSCTransportScanner process scans messages prior to delivery to Hub Transport servers. Exchange Server 2007 Exchange Server 2007 Exchange Server 2007 Exchange Server 2007 Exchange Server 2007 Exchange Server 2007 Exchange Server 2007 Exchange Server 2007 Exchange Server 2007 Exchange Server 2007 Forefront Security for Exchange Server Microsoft Exchange Server 2007 Edge Transport and Messaging Protection Page 15

16 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 {} Microsoft Exchange Server 2007 Edge Transport and Messaging Protection Page 16

17 OnEhloCommand {} OnAuthCommand {} OnEndOfAuthentication {} OnMailCommand {Connection Filtering Agent, Sender Filter Agent} OnRcptCommand {Connection Filtering Agent, OnDataCommand {} Recipient Filter Agent} 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 OnRsetCommand OnDisconnectEvent OnSubmittedMessage {Protocol Analysis Agent} {Protocol Analysis Agent} {Protocol Analysis Agent} {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. Microsoft Exchange Server 2007 Edge Transport and Messaging Protection Page 17

18 Table 2. SMTP Host Classification and Connection Filtering Action Category Criterion Action Comments 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 Exchange Server 2007 Edge Transport and Messaging Protection Page 18

19 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 Criterion Quality Costs Usability Comments 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. Microsoft Exchange Server 2007 Edge Transport and Messaging Protection Page 19

20 Criterion DNS zone transfer Availability Comments Real-time block lists rely on DNS queries. Because of high message volume, Microsoft IT's Edge Transport servers perform approximately 50, ,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 blocklist 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 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 rejected because 213.2xx.xx.x is listed by splxbl.spamhaus.org. Please see for more information. Sender Filtering When Microsoft IT faces spamming situations during which senders transmit large numbers of unwanted 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 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 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. Microsoft Exchange Server 2007 Edge Transport and Messaging Protection Page 20

21 Recipient Lookup For 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 securityenhanced 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 To enable secured EdgeSync communication, Microsoft IT opened TCP port 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"). Microsoft Exchange Server 2007 Edge Transport and Messaging Protection Page 21

22 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 Response Conditions Action User unknown SMTP session error Recipient OK SMTP response 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 Recipient is not on the Recipient Block list and is in Recipient Lookup Block message 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 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 Microsoft Exchange Server 2007 Edge Transport and Messaging Protection Page 22

23 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 Description Action Pass Fail Soft Fail Neutral TempError PermError None 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 notpermitted set. 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. Accept Accept Accept Accept Accept Accept Accept 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 Filter in Microsoft Exchange Server 2007 Edge Transport and Messaging Protection Page 23

24 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. Remote SMTP Host Edge Transport Server Blocked IPs SRL Logic Content Filter Signatures Content Phishing Protocol Analysis Verbs Content Reputation Open Proxy Content Filter Updates Microsoft Update Client IP Reputation Updates Microsoft Update Service Content Filter DAT IP Reputation DAT Updates Sender Reputation Database Protocol Analysis Background Process Microsoft Research 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 Microsoft Exchange Server 2007 Edge Transport and Messaging Protection Page 24

25 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. Microsoft Exchange Server 2007 Edge Transport and Messaging Protection Page 25

26 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 securityenhanced 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 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 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 Microsoft Exchange Server 2007 Edge Transport and Messaging Protection Page 26

27 <verdict>;p100:phishingblock;pp:presolve;sid:senderidstatus <status>;time:<sendreceivedelta>;mime:mimecompliance. Phishing confidence level (PCL) stamp. The Office Outlook Junk 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 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 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. Microsoft Exchange Server 2007 Edge Transport and Messaging Protection Page 27

28 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 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 Postmark Validation In addition to the IMF, the Content Filter Agent implements Office Outlook Postmark validation. The Postmark is a computational proof that Office Outlook applies to outgoing messages to help recipient messaging systems distinguish legitimate from junk . 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 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 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 Microsoft Exchange Server 2007 Edge Transport and Messaging Protection Page 28

29 this information in the content filtering process. The Content Filter Agent can then pass safe 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. Microsoft Exchange Server 2007 Edge Transport and Messaging Protection Page 29

30 Remove attachment and allow message Silently drop The sender assumes that the e- mail transmission is successful unless the recipient indicates otherwise. Microsoft IT uses this setting. The sender receives no notification of delivery failure. The attachment is not received. The recipient can request that the attachment be resent or delivered through other methods. Microsoft IT uses this setting. 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. Microsoft Exchange Server 2007 Edge Transport and Messaging Protection Page 30

31 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. Microsoft Exchange Server 2007 Edge Transport and Messaging Protection Page 31