There are many deployment topologies used to deploy Exchange services to the Internet. These topologies can vary in complexity, cost, and level of security. This document assumes a simple design topology (which is often the most effective). These design principles can be used in any environment where ISA Server 2004 is publishing Exchange.

This document assumes that ISA Server is placed as a second layer firewall between the perimeter network (also known as DMZ, demilitarized zone, or screened subnet) and the Internal network, and is a member of the internal Active Directory directory service domain. ISA Server is very effective in this position because it adds layer 7 firewall security at the edge of the internal local area network (LAN) with good connectivity for authentication purposes. It is also assumed than a traditional layer 4 packet filtering firewall is placed between the Internet and the perimeter network. However, this is not an explicit requirement. ISA Server 2004 can also operate effectively as the only firewall layer where two layers are not required.

The following network addresses are used in the examples for this document:

• Perimeter network (ISA Server External LAN): 10.0.0.0/8
  
• Internal network (ISA Server Internal LAN): 192.168.0.0/24
  

This guide assumes that the Exchange front-end server is placed on the Internal network along with the Exchange back-end servers and not in the perimeter network. This design is a recommended scenario in the Planning an Exchange Server 2003 Messaging System guide. For additional security, it is also appropriate to place the Exchange front-end and back-end servers on a separate network with an ISA Server computer separating them from the internal LAN. This way, Exchange servers also benefit from the ISA Server remote procedure call (RPC) filter to protect the mailbox servers.

For smaller Exchange deployments where only a single back-end server exists, it is not required to install an Exchange front-end server. In these scenarios, publish the Exchange back-end server through ISA Server. We still recommend using an SMTP relay in front of the back-end server. This could even be installed on the ISA Server computer along with the ISA Server Message Screener.

For information about how to deploy Microsoft Office Outlook Web Access for Exchange Server 2003, see Planning an Exchange Server 2003 Messaging System at the Microsoft TechNet Web site.

Various rules are required to provide access to all the features of Exchange. The New Mail Server Publishing Rule Wizard can bundle many of the features into a single rule. However, this removes the ability to provide granular security to each Exchange feature because the HTTP filter settings are applied on a per-rule basis. To achieve granular security, each Exchange feature should be published in a separate rule.

Each of the Exchange features described in the following table will be published using separate ISA Server rules.

Exchange feature	Description
Outlook Web Access	Feature rich Web browser-based access
Outlook Mobile Access	Simple access using a mobile device, for example, Wireless Application Protocol (WAP)
Exchange ActiveSync	Synchronize directly with Microsoft Windows mobile-based devices
RPC over HTTP	Microsoft Office Outlook 2003 remote connectivity without a virtual private network (VPN)
SMTP	Send and receive Internet e-mail

A key feature of ISA Server is the ability to pre-authenticate incoming connections by using delegation. In this configuration, ISA Server can test the validity of the provided credentials before they are sent to the published resource. This is done in a seamless way such that users only have to log on once, but they are actually logging on to the ISA Server computer and the published server. We recommend that pre-authentication be used when deploying ISA Server to protect Exchange. This prevents anonymous traffic from reaching the Exchange server, with the exception of SMTP.

ISA Server is able to natively validate authentication requests against Active Directory or to other directory services by using Remote Authentication Dial-In User Service (RADIUS). The ISA Server in this guide is a member of the internal Active Directory domain, and thus it has the required access to the domain controllers to perform pre-authentication. RADIUS implementations of ISA Server are less flexible than domain joined scenarios. A key sacrifice is the ability to assign permissions by using group membership. Joining ISA Server to the domain is a recommended approach.

Two types of authentication are used in this guide, Basic authentication and forms-based authentication. The following table lists the Exchange features to be published, including the protocol and recommended pre-authentication types used in this document.

Exchange feature	Protocol	Pre-authentication type
Outlook Web Access	HTTPS (HTTP over SSL)	Forms-based or Basic
Outlook Mobile Access	HTTPS (HTTP over SSL)	Basic
Exchange ActiveSync	HTTPS (HTTP over SSL)	Basic
RPC over HTTP	HTTPS (HTTP over SSL)	Basic
SMTP	SMTP	None (Anonymous)

When forms-based authentication is used, a minimum of two external Internet Protocol (IP) addresses are required on the ISA Server computer, one for forms-based authentication and one for Basic authentication. This is because ISA Server 2004 does not support both forms-based and Basic authentication types on a single Web listener, so two IP addresses and two listeners are required.

When ISA Server uses the forms-based filter, it receives the user credentials in plain text into the logon page form. ISA Server then validates the credentials against an authentication source (for example, Active Directory) and then replays the credentials using Basic authentication onto the Exchange server. Basic authentication transmits the username and password using Base64 Encoding, which is easily reversed and should be considered to be plain text. For this reason, Secure Sockets Layer (SSL) should always be used between the client and the ISA Server computer, and either SSL or Internet Protocol security (IPsec) encryption used between the ISA Server computer and the Exchange server to secure the users credentials in transit.

To enable SSL connections for the Exchange Web-based services, a Web server certificate is required. Each SSL Web server certificate is tied to a specific Domain Name System (DNS) name (unless an SSL wildcard character certificate is used). Because two IP addresses are required to publish the Exchange services when forms-based authentication is used, and each IP address has to be resolved by a different DNS name, two SSL Web server certificates are also required on the ISA Server computer. An additional SSL certificate will be required on the Exchange front-end server to provide end-to-end encryption.

If you are familiar with SSL certificates and DNS name resolution, it is possible to use the same SSL certificate on the ISA Server computer as on the Exchange front-end server. However, separate certificates are used in this guide for clarity. Some certificate providers have extra licensing requirements if the certificate is to be used on multiple machines, please check with your provider before purchasing or deploying their certificates to ensure all requirements are met.

The ISA Server must trust the SSL certificate on the Exchange server. If the certificate on the Exchange server has been internally generated, the root certification authority (CA) certificate must be imported into the Trusted Root Certification Authorities store on the ISA Server. This can be done manually or by using Active Directory, if ISA Server is a member of Active Directory. We recommend purchasing the SSL certificates for the ISA Server computer from a trusted third-party provider so that external clients automatically trust them.

This guide uses the names and IP addresses shown in the following table in the instructions.

Server placement	Certificate common name	DNS A record	IP address
ISA Server	mail.contoso.com	mail.contoso.com	10.0.0.1
ISA Server	owa.contoso.com	owa.contoso.com	10.0.0.2
Exchange front-end server	frontend.contoso.com	frontend.contoso.com	192.168.0.1

For more information about digital certificates for Outlook Web Access on ISA Server, see Digital Certificates for ISA Server 2004 at the Microsoft TechNet Web site.

In this scenario, the external DNS Mail Exchanger (MX) record for the contoso.com domain resolves to mail.contoso.com. In this way, the SMTP service will be published on the 10.0.0.1 address.

This deployment scenario uses a split DNS infrastructure. The host records mail and owa, and the MX record must be resolvable by external clients. The host name frontend must be resolvable internally by ISA Server. ISA Server can be configured to resolve this name by adding it to the internal Active Directory DNS zone or by entering it in the local Hosts file. Separate DNS namespaces can also be used if required.

Two Web listeners will be created, one for the Exchange Web-based services with Basic authentication and one for Outlook Web Access with forms-based authentication.

Procedure 1: Create Web Listener with Basic Authentication

Procedure 2: Create Web Listener with Forms-Based Authentication

To create a rule for Outlook Web Access:

1. In the console tree of ISA Server Management, click Firewall Policy:
   
   1. For ISA Server 2004 Enterprise Edition, expand Microsoft Internet Security and Acceleration Server 2004, expand Arrays, expand Array_Name, and then click Firewall Policy.
      
   2. For ISA Server 2004 Standard Edition, expand Microsoft Internet Security and Acceleration Server 2004, expand Server_Name, and then click Firewall Policy.
      
2. On the Tasks tab, click Publish a Mail Server to open the New Mail Server Publishing Rule Wizard.
   
3. On the Welcome page, type a name for the rule, such as Exchange – Outlook Web Access, and then click Next.
   
4. On the Select Access Type page, select Web client access: Outlook Web Access, Outlook Mobile Access, Exchange Server ActiveSync, and then click Next.
   
5. On the Select Services page, select only Outlook Web Access, and then click Next.
   
6. On the Bridging Mode page, select Secure connection to clients and mail server, and then click Next.
   
7. On the Specify the Web Mail Server page, enter the name of your Exchange front-end server (in this case: frontend.contoso.com), and then click Next.
   
8. Note that the name specified here must match the name in the SSL certificate placed on the Exchange front-end server.
   
9. On the Public Name Details page, in Accept requests for, select This domain name. In Public name, type the external name for Outlook Web Access (in this case: owa.contoso.com), and then click Next.
   
10. Note that the name specified here must match the name in the SSL certificate placed on ISA Server that was selected during the creation of the Web listener for forms-based authentication.
    
11. On the Select Web Listener page, select the Exchange - Forms Web listener, and then click Next.
    
12. On the User Sets page, click All Users, and then click Remove. Click Add, click All Authenticated Users, click Add, click Close, and then click Next.
    
13. Note that instead of selecting All Authenticated Users, you can click New and use the New User Sets Wizard to create a custom set of users who are allowed to use Outlook Web Access from the Internet.
    
14. Click Finish to close the wizard.
    
15. In the details pane, double-click the new rule to edit it.
    
16. On the Traffic tab, select Require 128-bit encryption for HTTPS traffic check box, and then click Apply. Click OK.
    
17. Click Apply to apply the settings.
    

To create a rule for Outlook Mobile Access:

1. In the console tree of ISA Server Management, click Firewall Policy:
   
   1. For ISA Server 2004 Enterprise Edition, expand Microsoft Internet Security and Acceleration Server 2004, expand Arrays, expand Array_Name, and then click Firewall Policy.
      
   2. For ISA Server 2004 Standard Edition, expand Microsoft Internet Security and Acceleration Server 2004, expand Server_Name, and then click Firewall Policy.
      
2. On the Tasks tab, click Publish a Mail Server to open the New Mail Server Publishing Rule Wizard.
   
3. On the Welcome page, type a name for the rule, such as Exchange – OMA, and then click Next.
   
4. On the Select Access Type page, select Web client access: Outlook Web Access, Outlook Mobile Access, Exchange Server ActiveSync, and then click Next.
   
5. On the Select Services page, select only Outlook Mobile Access, and then click Next.
   
6. On the Bridging Mode page, select Secure connection to clients and mail server, and then click Next.
   
7. On the Specify the Web Mail Server page, enter the name of your Exchange front-end server (in this case: frontend.contoso.com), and then click Next.
   Note that the name specified here must match the name in the SSL certificate placed on the Exchange front-end server.
   
8. On the Public Name Details page, in Accept requests for, select This domain name. In Public name, type the external name for Outlook Mobile Access (in this case: mail.contoso.com), and then click Next.
   Note that the name specified here must match the name in the SSL certificate placed on the ISA Server computer that was selected during the creation of the Web listener for Basic authentication.
   
9. On the Select Web Listener page, select the Exchange - Basic Web listener, and then click Next.
   
10. On the User Sets page, click All Users, and then click Remove. Click Add, click All Authenticated Users, click Add, click Close, and then click Next.
    Note that instead of selecting All Authenticated Users, you can click New and use the New User Sets Wizard to create a custom set of users who are allowed to use Outlook Web Access from the Internet.
    
11. Click Finish to close the wizard.
    
12. In the details pane, double-click the new rule to edit it.
    
13. On the Users tab, select the Forward Basic authentication credentials (Basic delegation) check box, and then click Apply.
    
14. On the Traffic tab, select the Require 128-bit encryption for HTTPS traffic check box, and then click Apply. Click OK.
    
15. Click Apply to apply the settings.
    

To create a rule for Exchange ActiveSync:

1. In the console tree of ISA Server Management, click Firewall Policy:
   
   1. For ISA Server 2004 Enterprise Edition, expand Microsoft Internet Security and Acceleration Server 2004, expand Arrays, expand Array_Name, and then click Firewall Policy.
      
   2. For ISA Server 2004 Standard Edition, expand Microsoft Internet Security and Acceleration Server 2004, expand Server_Name, and then click Firewall Policy.
      
2. On the Tasks tab, click Publish a Mail Server to open the New Mail Server Publishing Rule Wizard.
   
3. On the Welcome page, type a name for the rule, such as Exchange – ActiveSync, and then click Next.
   
4. On the Select Access Type page, select Web client access: Outlook Web Access, Outlook Mobile Access, Exchange Server ActiveSync, and then click Next.
   
5. On the Select Services page, select only Exchange ActiveSync, and then click Next.
   
6. On the Bridging Mode page, select Secure connection to clients and mail server, and then click Next.
   
7. On the Specify the Web Mail Server page, enter the name of your Exchange front-end server (in this case: frontend.contoso.com), and then click Next.
   Note that the name specified here must match the name in the SSL certificate placed on the Exchange front-end server.
   
8. On the Public Name Details page, in Accept requests for, select This domain name. In Public name, type the external name for Exchange ActiveSync (in this case: mail.contoso.com), and then click Next.
   Note that the name specified here must match the name in the SSL certificate placed on the ISA Server computer that was selected during the creation of the Web listener for Basic authentication.
   
9. On the Select Web Listener page, select the Exchange - Basic Web listener, and then click Next.
   
10. On the User Sets page, click All Users, and then click Remove. Click Add, click All Authenticated Users, click Add, click Close, and then click Next.
    Note that instead of selecting All Authenticated Users, you can click New and use the New User Sets Wizard to create a custom set of users who are allowed to use Outlook Web Access from the Internet.
    
11. Click Finish to close the wizard.
    
12. In the details pane, double-click the new rule to edit it.
    
13. On the Users tab, select the Forward Basic authentication credentials (Basic delegation) check box, and then click Apply.
    
14. On the Traffic tab, select Require 128-bit encryption for HTTPS traffic check box, and then click Apply. Click OK.
    
15. Click Apply to apply the settings.
    

The New Mail Server Publishing Rule Wizard does not have an option to configure RPC over HTTP. You will use the Exchange ActiveSync instructions described in the previous procedure, and then edit the minor differences.

To create a rule for RPC over HTTP:

1. Create a rule using the Exchange ActiveSync instructions, or copy and paste the previously created Exchange - ActiveSync rule to create a duplicate.
   
2. In the details pane, double-click the new rule to edit it.
   
3. On the General tab, change the rule name to Exchange – RPC over HTTP, and then click Apply.
   
4. On the Paths tab, edit the path generated by the wizard. Click /Microsoft-Server-ActiveSync/*, click Edit, type /rpc/*, and then click OK. Click OK again.
   
5. Click Apply to apply the settings
   

To create a rule for SMTP:

1. In the console tree of ISA Server Management, click Firewall Policy:
   
   1. For ISA Server 2004 Enterprise Edition, expand Microsoft Internet Security and Acceleration Server 2004, expand Arrays, expand Array_Name, and then click Firewall Policy.
      
   2. For ISA Server 2004 Standard Edition, expand Microsoft Internet Security and Acceleration Server 2004, expand Server_Name, and then click Firewall Policy.
      
2. On the Tasks tab, click Publish a Mail Server to open the New Mail Server Publishing Rule Wizard.
   
3. On the Welcome page, type a name for the rule, such as Exchange – , and then click Next.
   
4. Note that the New Mail Server Publishing Rule Wizard will append the string SMTP Server onto the rule name you specify, resulting in the rule name being Exchange – SMTP Server.
   
5. On the Select Access Type page, select Server-to-server communication: SMTP, NNTP, and then click Next.
   
6. On the Select Services page, select only SMTP, and then click Next.
   
7. On the Select Server page, enter the IP address of the Exchange front-end server (in this case, 192.168.0.1), and then click Next.
   
8. On the IP Addresses page, select the External network and click the Address button. Do the following:
   
   1. Select Specified IP addresses on the ISA Server computer in the selected network.
      
   2. Click the first IP address (10.0.0.1) in the Available IP Addresses list, click Add to add the IP address to the Selected IP Addresses list, and then click OK. Click Next.
      
9. Click Finish to close the wizard.
   
10. Click Apply to apply the settings.
    

Apply all the settings from the table to the rules. Each column corresponds to a respective rule. To apply settings:

1. In the ISA Server Management Firewall Policy details pane, right-click each rule, and then select Configure HTTP at the bottom of the drop-down list.
   
2. Apply the settings described in the table to each rule.
   

Setting and rule	Outlook Web Access	Outlook Mobile Access	Exchange ActiveSync	RPC over HTTP
General tab
Maximum headers length	32768	32768	32768	32768
Maximum payload length	10485760	10485760	65536	Any
Maximum URL length	16384	319	1024	16384
Maximum query length	4096	13	512	4096
Verify normalization	Yes	Yes	Yes	Yes
Block high bit characters	No	Yes	Yes	Yes
Block responses containing Windows executable content	Yes (Note 1)	Yes	Yes	Yes
Methods tab
Allow only specified methods	BCOPYBDELETEBMOVEBPROPPATCHDELETEGETMKCOLMOVEPOLLPOSTPROPFINDPROPPATCHSEARCHSUBSCRIBE	GETHEADPOST	OPTIONSPOST	RPC_IN_DATARPC_OUT_DATA
Extensions tab
Action taken for file extensions	Block specified extensions (allow all others)	Allow only specified extensions	Allow only specified extensions	Allow only specified extensions
Extension list	.asax.ascs.bat.cmd.config.cs.csproj.dat.dll (Note 2).exe (Note 1).htr.htw.ida.idc.idq.ini.licx.log.pdb.pol.printer.resources.resx.shtm.shtml.stm.vb.vbproj.vsdisco.webinfo.xsd.xsx	. (dot).aspx	. (dot)	.dll
Block requests containing ambiguous extensions	No	Yes	Yes	Yes
Headers Tab
Blocked headers	None	None	None	None
Signatures Tab
Blocked signatures:Request URL	./\.. (Note 3)% (Note 3)& (Note 3)	./\..%&:	./\..%:	./\..%&

RFC 821 is the original specification for SMTP mail with which all SMTP servers should be compliant. Section "4.5.1 Minimum Implementation" in RFC 821 (http://www.ietf.org/rfc/rfc0821.txt page 41) shows that seven minimum SMTP commands are required for communication:

• HELO
  
• MAIL
  
• RCPT
  
• DATA
  
• RSET
  
• NOOP
  
• QUIT
  

RFC 821 (and others) have been superseded by RFC 2821, which is designed to be a more appropriate specification for the Internet usage of SMTP. According to section "3.5.1 Minimum Implementation" in RFC 2821 (http://www.ietf.org/rfc/rfc2821.txt page 53), there are nine minimum SMTP commands required for communication:

• EHLO
  
• HELO
  
• MAIL
  
• RCPT
  
• DATA
  
• RSET
  
• NOOP
  
• QUIT
  
• VRFY
  

The new RFC introduced the EHLO command to replace the HELO command. This new command was designed to allow for extensions beyond the original SMTP specification. The EHLO command is also designed to list the SMTP extensions that the host supports.

A common SMTP extension that is used that is not mentioned in RFC 2821 is the AUTH command. The AUTH command allows for authenticated SMTP sessions and is described in RFC 2554 (http://www.ietf.org/rfc/rfc2554.txt). The only dependency the AUTH command has is the use of the EHLO command, although many mail systems will also accept AUTH requests in conjunction with the HELO command.

RFC 1830 introduces the concept of transmitting large and binary messages more effectively by specifying the length and size of the message, instead of the receiving server scanning the input for the carriage return/line feed (CR/LF) sequence.

This RFC makes use of the EHLO command and a server supporting RFC 1830 may advertise support for CHUNKING. The BDAT verb is used in place of the DATA verb when CHUNKING is used.

For more information about CHUNKING and BDAT, see RFC 1830 (http://www.ietf.org/rfc/rfc1830.txt).

There are many RFCs to support SMTP that introduce numerous commands and verbs for different purposes. This is further complicated by various interdependencies and version compatibility levels.

Although a minimum set of commands are described in the preceding RFCs, the following commands are not typically used in Internet SMTP communication:

• RSET
  
• NOOP
  

They may be required in situations where the SMTP server you are publishing is designed to relay large number of e-mail messages. These two commands do not require any variable inputs and should not pose a threat to the system when enabled.

In contrast, the following two new commands introduced in RFC 2821 can be used to reveal extra information about an SMTP server or the messaging infrastructure behind it:

• EHLO
  
• VRFY
  

Modern mail systems have removed the majority of the VRFY functionality because it had become a useful tool for spammers to retrieve valid SMTP addresses from an organization. The command VRFY * would typically list all the valid e-mail addresses in the organization.

The EHLO command can also be used for information gathering purposes to determine details about the mail system. However, the value of this information is negligible and could easily be determined by other means.

We recommend that string lengths be enforced with ISA Server to help prevent abuse of the SMTP server and protect against buffer overflow attacks. ISA Server has default string length restrictions that should be used.

RFC 2821 section 4.5.3.1 indicates some size limitations. However, these limitations are generically large and are not specific to each command. A general restriction of 512 characters is stated in the RFC, however, ISA Server 2004 enforces stricter command lengths for added security. Commands that do not require variable input, for example RSET and DATA, are limited to six characters (four for the command and two for the <CRLF> character). These restrictions should not impact normal functionality.

RFC 2554 explicitly states "The BASE64 string may in general be arbitrarily long" regarding authentication commands. It also states that "Clients and servers MUST be able to support challenges and responses that are as long as are generated by the authentication mechanisms they support." The authentication limitations imposed by ISA Server 2004 by default are in line with the length requirements of Internet Information Services (IIS), SMTP, and Exchange.

The following table lists the common SMTP commands and which RFC they are listed in as a minimum requirement. You may want to enforce a specific RFC or combine various RFCs.

Command	RFC 821	RFC 2821	RFC 2554	RFC 1830	Config #1	Config #2
EHLO		X	X	X		X
HELO	X	X			X	X
MAIL	X	X			X	X
RCPT	X	X			X	X
DATA	X	X			X	X
RSET	X	X				X
NOOP	X	X				X
QUIT	X	X			X	X
VRFY		X
AUTH			X
BDAT				X		X

The Config #1 column in the preceding table lists the minimum requirements for SMTP communication and is a subset of the original RFC 821.

The Config #2 column lists a recommended set of commands that will provide better compatibility with most SMTP systems and is fully compliant with RFC 821. Config #2 should pose no additional threat to the SMTP server but will disclose some information using the EHLO command.

To configure the ISA Server computer:

1. In the console tree of ISA Server Management, click Add-ins:
   
   1. For ISA Server 2004 Enterprise Edition, expand Microsoft Internet Security and Acceleration Server 2004, expand Arrays, expand Array_Name, expand Configuration, and then click Add-ins.
      
   2. For ISA Server 2004 Standard Edition, expand Microsoft Internet Security and Acceleration Server 2004, expand Server_Name, expand Configuration, and then click Add-ins.
      
2. Select the Application Filters tab, and then double-click SMTP Filter.
   
3. Select the SMTP Commands tab, and disable the commands that are not required as described in the preceding table. To disable a command, click the command and then click Edit. Clear the Enable SMTP command check box, and then click OK.
   
4. When complete, click Apply to apply the changes, and then click OK.
   
   

Even though ISA Server will block unwanted SMTP verbs, we also recommend stopping the SMTP server from advertising Extended Simple Mail Transfer Protocol (ESMTP) services that are blocked by ISA Server. This is to prevent ISA Server from inadvertently disconnecting valid SMTP sessions. For example, a sending SMTP server may use EHLO to obtain a list of supported ESMTP services. It may then try to use a verb that the SMTP server is advertising (such as BDAT, a CHUNKING alternative of the DATA verb), which ISA Server may be blocking. If the sending server tries to use an advertised verb, which ISA Server is blocking, ISA Server will terminate its session and the mail will not be received. The sending server will continually attempt to deliver the message unsuccessfully until it is regarded at undeliverable and returned to the sender.

There are two methods that can be used to resolve this problem. Either enable the advertised commands in the SMTP filter and allow them through ISA Server, or remove support for the verbs from the SMTP server.

For details about disabling SMTP verbs on IIS and Exchange, see the Microsoft Knowledge Base article 257569,"How to turn off ESMTP verbs in Exchange 2000 Server and in Exchange Server 2003".