## MS BackOffice Unleashed

- Internet Integration Options
  - Connecting Exchange Clients over the Internet
  - Connecting to the Internet for E-mail
  - Connecting Exchange Sites over the Internet
- Using Exchange Public Folders for Listserver Messages
  - Subscribing a Public Folder to a Mailing List
- Exchange Server and Internet Security
  - Security Measures in Windows NT
    - Windows NT Logon Security
    - Windows NT RPC
  - Microsoft Exchange Server Advanced Security
  - Microsoft Exchange Server Internet Mail Connector Security Options
    - Accept/Reject by IP Address
    - Message Size Limit
    - Disabling Auto-Replies to the Internet
    - Delivery Restrictions
  - Microsoft Exchange Client Security Features
- Future Enhancements
- Summary

#
— 26 —

##
Exchange Server and the Internet

Internet—a word that excites the imagination and conjures up images of millions of users interacting on a vast global network. The Internet we know and love today is vastly different from the Internet of a few years ago. Millions of new users are being added every year, and domain name registrations are topping 50,000 per month. Businesses are now actively embracing the Internet to solve many business requirements, but are leery of the security risks involved in connecting to such a large public network. It is hard to find a company that does not have Internet e-mail connectivity or a home page to establish its presence for marketing purposes and customer relations.

Even though the Internet supports e-mail, this is only a small part of its total offerings. Users can participate in newsgroups, research various topics using vast search engines, download software, and browse the World Wide Web (WWW), all from the comfort of their living room or office cubicle. The sheer volume of information available on the Internet can be overwhelming and confusing at times, but new technologies are being created every day to make the Internet more user friendly. The various search and retrieval services on the Internet are quickly replacing many proprietary methods for information disbursement that companies have used to interact with their customers. Business requirements are driving new technologies that will help make the Internet friendly for doing business.

Messaging and Groupware systems must embrace the Internet if they want to survive in such a dynamic and competitive environment. Microsoft is determined to provide Internet interoperability across its full line of products, and Exchange Server includes connectivity options such as the Internet Mail Connector (IMC) to allow companies to build Internet solutions with minimal time and effort. Future releases of Exchange will extend these capabilities to include support for "light" client access through IMAP4 specifications, newsgroup downloads and hosting from public folders, Web browser access, and directory access through Lightweight Directory Access Protocol (LDAP) specifications.

This chapter covers the options available in Exchange to interoperate with the Internet. It also discusses the procedures used to subscribe a public folder to a listserver to reduce message storage requirements and replicate the information throughout the organization. Security and encryption are very important features for any messaging system connected to the Internet, so this chapter covers the options and features available in the Exchange messaging server to address security issues. It briefly discusses how future releases will add new functionality to Exchange's integration with Internet technologies.

###
Internet Integration Options

Even though e-mail is a very small part of the services the Internet provides, messaging systems must be able to seamlessly send and receive messages with the millions of other SMTP-based hosts throughout the Internet. Simple Mail Transfer Protocol (SMTP) is the standard method for all message transfer on the Internet, which is defined in RFCs #821 and #822, published in 1982. These RFCs define the handshaking and keywords to use when a host initiates mail transfer using TCP/IP port 25, and the format for the plain-text message body and encoded attachments within e-mail messages. Domain Name Services (DNS) allows hosts to look up and resolve the IP address for the destination host computer, and it can be used for reverse lookups to authenticate another host.

The Internet Mail Connector is the Exchange component used to provide messaging connectivity to the Internet and other SMTP-based messaging systems. It fully supports the SMTP standards for mail transfer, and it encodes and decodes attachments and message body parts using MIME or UUENCODE. The IMC operates as a "smart" host performing lookups in DNS, and can act as a message relay agent for a fully qualified domain name (FQDN) external to Exchange. When determining what type of connectivity your company will need to the Internet, note that the following options are available:

- Microsoft Exchange clients can access their mailboxes on Microsoft Exchange Servers in your site across the Internet, using secure RPC connectivity.
- The Microsoft Exchange IMC can provide general SMTP e-mail connectivity between your messaging system and external SMTP-based messaging systems, such as the Internet.
- You can connect Microsoft Exchange sites within your organization over the Internet using the Microsoft Exchange Internet Mail Connector.

####
Connecting Exchange Clients over the Internet

Having users access the Exchange Server across an unsecured connection, such as the Internet, could make any network manager's skin crawl. Some options within Exchange, such as encryption and static port assignments, will make this a much more viable solution. If you combine the security and connectivity options in Exchange with a good firewall or proxy solution, or both, this type of connectivity is viable for many businesses' messaging requirements.

The first step in getting the clients to connect to an Exchange Server over the Internet is to set up name resolution. Because the Internet does not incorporate WINS services, and your users will not be able to connect to the WINS servers on your corporate LAN, the clients will need to be set up for DNS or host files. You could choose to hard-code the IP address of the server in the Exchange client profiles for the users, but you might have too much fun changing them all when you decide to change the server's IP address in the future. Name resolution can be performed in one of three ways for the Exchange client:

- Add an entry to the LMHOSTS file of the workstation for the Exchange Server and a domain controller(s); use the #PRE option for speed.
- Put an entry in DNS for the Exchange Server with an FQDN such as exchangesrv.company.com, and make sure that it can be resolved from the Internet.
- Set up a WINS server on the hot side of your firewall, and use this entry as the primary WINS server when clients connect to the Internet.

The solution of using the LMHOSTS file means that the name resolution occurs locally, and it can be maintained by an update process that runs when clients logon to the network in case the addresses change. Placing an entry in DNS enables clients to resolve the address for making the connection, but it exposes your Exchange Server's address, as well as Web indexing software for many search engines, to the world. Putting your own WINS server on the Internet gives you automatic name resolution and registration but opens the NT Server running the services to attack by hackers wanting to test NT's security. Choose the name resolution method that best fits your short-term messaging goals, because future releases of Exchange will support POP3 and "light" client access.

The Exchange Server requires the user to be authenticated by an NT before he can have access to mailbox or messaging resources. This is done through the built-in authentication process for Remote Procedure Calls (RPCs). You can increase the level of security for all information transmitted over the Internet by encrypting the data from the client. To configure an Exchange client to encrypt RPC traffic over dial-up or network connections, follow these steps:

1. From the client, select the Services option from the Tools pull-down menu.
2. Select the Microsoft Exchange Server service provider with the mouse, and click the Properties button.
3. Click the Advanced tab to display the advanced properties page.
4. Select the appropriate checkboxes under the Encrypt Information section for connections to the network and dial-in connections.
5. Click OK twice, and then stop and restart the Exchange client.

Just enabling the client for encryption of all RPC traffic does not give you a completely secure connection. All Exchange clients initially connect to TCP/IP port 135, which is the Windows NT RPC End-Point-Mapper service. This service in turn assigns a dynamic port for the client to use for continued connectivity. This process would create a problem for your firewall's packet filter because such a broad range of ports would need to be opened for Internet access. It would also open a larger security hole that attackers could leverage to compromise mailboxes or messaging resources.

You can configure the Exchange Server to always use a series of static ports, allowing the firewall's packet filter to "close the hole" of ports that attackers could use. You can do this by adding the values of the ports you want to enable as a REG_DWORD value to the following registry keys:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeDS\Parameters\TCP/IP port

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\TCP/IP port

After restarting the Exchange Server, you need to set up the packet filter on the firewall to allow access to the ports listed previously, as well as port 135 for the End-Point-Mapper service. You are not limited to using these features just for Internet-based connections, because they add an extra level of security to your local network. The overhead needed for the encryption process is negligible, and the End-Port-Mapper process will always be used in a dynamic fashion regardless of whether you specify static port assignments. Setting up static RPC ports is also helpful if you use the IMC to connect two Exchange sites over the Internet.

####
Connecting to the Internet for E-mail

Connecting Exchange to the Internet for message transfer is the main purpose of the Internet Mail Connector. The IMC is fully compliant with most standards adopted within the Internet community for message transfer. Interoperability options within the IMC properties pages allow customized per-connection configurations to control how and what type of messages are sent. As you configure the IMC, you must consider the least-common-denominator message options for the other domains your users will regularly send messages to. Some of the domains you will exchange messages with will support rich-text and MIME attachment encoding, whereas others will support only basic text and UUENCODE/UUDECODE for message attachments.

The IMC can be configured for two types of outbound delivery: direct to a host through DNS lookup, or via forwarding of all messages to a specific relay host regardless of destination. Inbound messages are automatically accepted by the IMC on port 25, unless specifically set up to allow message reception only with specific hosts. Each IMC instance on a specific server within a site can be set up to handle inbound, outbound, both, or queue messages only. This feature is helpful if you want to control where messages are received from the Internet but want to allow outgoing delivery from multiple Exchange Servers, such as on a per-site basis.

When the IMC is configured for outbound delivery via DNS lookup, it needs access to all hosts on the Internet direct through port 25. It also requires a DNS server to resolve domain names and Mail Exchange (MX) records for Internet-based hosts. This technique allows for non-delivery reports (NDRs) and informational messages, such as retries, to be generated by the IMC rather than another SMTP host. Messages are more easily tracked because the IMC and the host receiving the message are the only parties involved in the message transfer. This can pose a security risk because the address of your Exchange Server must be registered and will be known to anyone on the Internet.

The IMC can also be configured to forward all outgoing messages to a specific host by name or IP address. Any SMTP-type messages that need to be transferred outside the Exchange site are relayed to this sendmail relay host. This allows the use of a firewall to perform the actual message delivery process, removing the burden of the DNS lookup and message transfer from the Exchange Server. The host or firewall specified as the SMTP relay host needs adequate storage for outbound messages, reliable and secure connection to the Internet, and the capability to perform DNS lookups for external domains and hosts. This will prove to be the most secure type of outbound mail transfer because only the firewall will be exposed to the Internet on outbound deliveries, and it should be used for any inbound deliveries as well. For inbound deliveries an alias table will need to be maintained on the firewall or sendmail host, and the Exchange recipients will need Secondary Proxy Addresses for inbound delivery.

Inbound message transfer can be handled directly by the Exchange IMC, or by another host with a list of aliases for the recipients on Exchange. The IMC accepts any allowed inbound message transfer request and can also perform the relay functionality if it is the primary domain contact with custom recipients for other local SMTP host mailboxes. Using another sendmail host, such as a firewall or UNIX server, with a list of aliases to Exchange recipients is the best configuration for Internet connectivity. In this configuration the firewall accepts the incoming messages and forwards them to the Exchange Server through a lookup in an alias table maintained locally. If you do not want the maintenance headache of an alias file or the additional security of a firewall, you can make the Exchange Server the primary contact for the domain with custom recipients for aliasing to other sendmail hosts.

As previously mentioned, you should configure the default interoperability options to cover the broadest number of hosts that messages might be transferred to. UUENCODE is the best option for the default outbound attachment encoding method, because most hosts accept this type of transfer if they are RFC #822–compliant. As you determine e-mail domains that support MIME or have Exchange recipients, you can specify overrides for these domains in the Specify Message Content By E-Mail Domain option on the Internet Mail property page for the IMC. The interoperability button is available for the default and per-domain connections allows configuration of message word wrap, rich text, automatic replies, and out-of-office responses. The word wrap option is only available when MIME is selected, and will control at which character place a line will be wrapped. Since rich text is normally only supported by Exchange clients, this option should be disabled for any domain that does not have Exchange recipients to eliminate the winmail.dat file being transmitted. The out-of-office and automatic replies can be disabled for SMTP recipients so that persons outside your organization will not accidentally receive confidential information from an Inbox Rule or know that an employee is on vacation.

> > Have you noticed that messages sent to people over the Internet have a file named WINMAIL.DAT attached? This file is created by a user sending a message to a recipient who has the Send in Exchange Format option checked in her personal address book. It contains rich-text formatting and attachments for use by a client that can support rich-text formatting. This option sounds great, but it will prove to be useful only if the recipient is using Exchange or MS-Mail. As an administrator, you should disable all Rich Text functionality for all default connections through the interoperability options in the IMC. Then use the Specify Message Content By E-Mail Domain option on the Internet Mail property page to "register" domains that have Exchange or MS-Mail recipients. When the list of Exchange-enabled e-mail domains gets too large to manage, set the interoperability defaults to support rich text, switching those domains that do not support rich text set to disabled by specific e-mail domain name.

####
Connecting Exchange Sites over the Internet

Does your WAN budget have fewer digits than a three-toed sloth? Are you searching for an inexpensive way to connect your home office to a branch location? Are you willing to trust your messaging data to a public network that has no guaranteed delivery? If you answered yes to all three questions, you will probably want to connect your Exchange sites over the Internet with the Internet Mail Connector. This functionality is available because the IMC has the capability to handle the special "EX" address type that is necessary for the directory replication connector.

You might be wondering how much security is available in this type of connection. The IMC, as well as SMTP hosts, do not encrypt the messages as they are transmitted from host to host. The message header information is transmitted in free-form text; the message body might or might not be encoded with MIME or UUDENCOE, but is still in the form of ASCII characters. To ensure that messages are securely transmitted between users at each site, you should install and configure advanced security. This task involves a simple installation of the Key Server component, and then a two-step procedure to set up the private encryption keys for each user. The end-users need to complete the setup of advanced security to make this a viable option. Users must then set their default send options to always send messages in encrypted format to ensure that messages sent to IMC-connected sites will be encrypted and secure.

> > Many of you just read the preceding section and probably decided not to connect your company's sites over the Internet because of the security concerns. As this chapter was being written, Windows NT 4.0 will be available in stores by the time you read this. Windows NT Server 4.0 includes a Point-To-Point Tunneling Protocol (PPTP) that enables a network manager to create virtual private networks over unsecure public networks. This new option in NT 4.0 makes connecting two sites over the Internet via the IMC much more appealing, because all traffic is encrypted over the PPTP virtual network.

These are the steps to connect two Exchange sites over the Internet using the Internet Mail Connector:

1. Set up the IMC to connect to the Internet and test e-mail and DNS name resolution functionality. Make sure that you can send a messages between the sites using the FDQN for a test user account, such as testuser@sitea.company.com to testuser@siteb.company.com.
2. On sitea open the properties for the IMC, and click the Connected Sites tab to bring up the Connected Sites properties page.
3. Click the New button, and you should be prompted for the organization and site name on a general properties page. The organization field is already filled in with your current organization name, which is required for two sites to connect. Enter the name of the site you want to make a connection to, keeping in mind that these names are case sensitive and must be spelled correctly.
4. Click the Routing Address tab to enter the type of SMTP, enter the routing address of @siteb.company.com, and assign an appropriate cost to the connection. Click the OK button to save. Multiple IMCs can be used with various costs if you have multiple connections to the Internet or would like fault tolerance.
5. Next, set up a directory replication connector for the site you just connected to replicate the directories from this site.
6. Perform steps 2 through 5 for siteb to complete the connection between the two sites.

After directory replication has completed, users at sitea should see users from siteb in their global address list and vice versa. When users at sitea send messages to users at siteb, the messages are routed through the IMC at sitea, transmitted through a series of SMTP hosts over the Internet, received at the IMC at siteb, and delivered to the intended recipients. Seems simple enough, unless the messages transmitted between the two sites are caught in a "traffic jam" or just end up as road kill on the information superhighway.

###
Using Exchange Public Folders for Listserver Messages

If you had some information that a group of people would be interested in, how would you go about getting that information to them? We are all familiar with the current tactics used by the marketing departments of many companies: junk mail. Every one of us has gotten on the mailing lists of one of these companies and has had our names and addresses sold and resold to hundreds of companies. Wouldn't it be nice if you could control who had your address and what information they sent to you? Luckily, the Internet has just this feature, called listservers, and so far it has not had a major insurgence of electronic junk mail.

Mailing lists are the electronic version of a well-maintained "little black book." Listservers maintain a mailing list of the users who have subscribed to receive information about a common interest. When someone sends a message in a specific format to the listserver address, it records her e-mail address in the master list. When the listserver owner mails a message to the mailing list, all the subscribed users receive a copy of the message. The list owner is also responsible for keeping the listserver in running order and must intervene when problems occur.

Subscribing and unsubscribing to a listserver is as simple as sending a message to an address with the word SUBSCRIBE or UNSUBSCRIBE within the message body. Usually, one address is used for subscriptions, and another is used to post messages to all the members of the list after those messages have been screened by the list owner. After a user has subscribed to a listserver, he receives in his mailbox any messages sent to the mailing list. This functionality works well if the number of users within your company is small, but it increases messaging traffic on your IMC every time a new message is sent to the list if a large number of "subscribed" users exist within your company.

There is a better way to coordinate and manage listserver message traffic: by subscribing a public folder to the mailing list. This technique reduces the traffic from the listserver to just a single message any time a new mailing is sent to the list. The messages then can be organized by various folder views and replicated throughout your organization for use by users at other sites. These are the advantages of using a public folder instead of receiving the messages at individual mailboxes:

- Users in your organization can "join" or browse the messages from a listserver by adding the public folder to their favorites folder on their server-based mailbox. This method enables them to read the messages at any time, instead of wading through many messages in their personal mailbox.
- Messages from the list are delivered to a public folder rather than a user's inbox. Many users subscribe to more than one list, which can flood their inbox with a large volume of messages if the listservers are very active. Users might try to use inbox rules to organize the incoming messages into a series of folders, but most users do not have the time to read all messages, and many messages are subsequently deleted.
- Valuable storage space and messaging traffic bandwidth are used more efficiently. One message sent from a listserver to 100 users has 100 instances of the message. A listserver message sent to a public folder has only one instance with 100 users pointing to that message, or multiple instances if the folder is replicated throughout the organization.
- The public folder can be set up to send an "update" message to a distribution list to alert specific users that new messages have been received. This informational message is stored as a single message instance on each server, still saving valuable storage space.

Because some users might want to be able to post new messages to the list, you need to set the proper folder permissions to allow the users to send-on-behalf of the public folder. Then users can use the From field when composing a message to set the sender address to that of the public folder. The easiest way to configure this functionality is to create a group on the NT domain for the user accounts, and then give this group the Send as permission for the public folder. This action is not necessary if the mailing list is deemed open (will accept messages from anyone) or if the users will not be posting any messages to the listserver.

####
Subscribing a Public Folder to a Mailing List

The process of subscribing a public folder to the mailing list of a listserver is relatively simple. Because every object in the Exchange directory has proxy addresses for the default address types, all public folders will have a valid SMTP address that can be mailed to over the Internet. To subscribe a public folder to a listserver, perform the following steps:

1. From the Exchange client create the public folder with a descriptive name the users will associate with the listserver that messages will be received from.
2. Set the proper permissions for the folder by using the Permissions page of the folder properties. The default permissions must include the capability to create items or else an NDR report will be sent to the message originator every time a new message arrives. This is not the way to win friends and influence people in the Internet community.
3. Create a default view for the folder that will organize the messages by conversation topic. Create any additional views that will be helpful to the users, such as views by send date or message size.
4. Originate the message that will subscribe the public folder to the list. Some listserver allow a message from any address with the command subscribe list e-mail address, in which list is the list name and e-mail address is the SMTP address of the public folder. To get the SMTP address of the public folder, open the properties pages for the folder, and click the Add to Personal Address Book button on the administration page.

Some listservers require that the subscription message originate from the user who is subscribing to the list. This limitation is designed to keep your buddies from subscribing your account to all sorts of weird listservers as a joke, which would require you to take the time to unsubscribe from each listserver manually. This task requires the administrator or folder owner to send a subscription message on behalf of the public folder. The following steps lead you through subscribing a public folder to this type of listserver:

1. Open the folder properties from the administrator program, click the Permissions tab, and give the NT user account you will use the Send as permission.
2. Start the Exchange client and log on to a mailbox that has the NT account from step 1 as its primary account. To make sure that you have the proper permissions to the folder, open its properties pages and you should see all the folder tabs.
3. Capture the SMTP address of the public folder by opening the properties for the folder in the Exchange client and clicking the Add to Personal Address Book button on the administration page.
4. Compose a new message from the Exchange client, and enable the From field by selecting the From option from the View menu.
5. Click the From button and select the public folder address from your personal address list. Enter the subscription address on the To field in SMTP format, such as listserv@domain.com.
6. Enter the subscription command for the listserver in the message body. This is usually something like SUBSCRIBE LIST NAME.
7. Send the message to the listserver by clicking the Send Now button. The message delivery can be tracked via the Track Message feature in the administrator program. Most listservers send a confirmation message that should show up in the public folder to verify that it is subscribed.

The public folder should now start receiving new messages sent to the mailing list. Test the folder views to make sure that they are working correctly and that they will provide users with valuable sorting and viewing capabilities. You might also want to limit the number of messages within this folder by setting an age limit from the Age Limits properties page of the public Information Store on each server. You should also check the storage limits for this folder from its advanced properties page to make sure that the listserver will not receive NDR messages when the folder is over its limit.

The folder should be frequently checked to ensure that it is still receiving updates because some listservers require frequent subscriptions to keep the e-mail address in the list. You should notice a renewal-type message in the folder indicating that it is time to resubscribe the folder to the mailing list. Also, the folder owner should browse the content frequently to look for messages that might be objectionable to the users. When you decide to remove the public folder, be sure to unsubscribe it from the list first. Otherwise, nondelivery reports will be returned for every new message sent to the folder, requiring administrator intervention to unsubscribe the folder from the mailing list.

###
Exchange Server and Internet Security

Internet security is first and foremost on the minds of administrators when it comes to connecting their company to the public network. This type of connection can open their business data to attacks from various types of individuals, often collectively called hackers. The term hacker, however, should be reserved for individuals who find new ways to circumvent security measures to obtain a "trophy," proving to their friends that they were able to obtain access to a specific network or computer. Hackers normally are not trying to damage anything, but they might inadvertently cause problems in their search for the trophy. Attackers are much more dangerous, because they are trying to steal information or destroy computer resources. You must take measures to protect your Exchange messaging system from these types of individuals, because you risk losing confidential data or suffering unnecessary downtime.

These are the types of attacks you should protect your network and messaging systems from:

- E-Mail spoofing of messages in which an attacker can make it appear as if a message came from someone else. This technique can be used to trick users into revealing sensitive data or to spread false information.
- Theft or corruption of data through the use of "sniffing" software to intercept messages in transit. The attacker can use this method to obtain sensitive documents to be used for illegal or immoral purposes.
- E-Mail spamming of your messaging system. The invader overwhelms the servers with thousands of messages, using valuable processor and bandwidth resources.
- Spreading viruses within e-mail messages. Users might unexpectedly infect their machines with viruses by clicking on attachments to messages. This has become a serious problem with the addition of macro viruses that live in documents, such as the word prank macro virus that has been wreaking havoc even within Microsoft's messaging system.
- Exploiting weaknesses within the network operating system to gain access to services and resources that will give the attacker valuable information. This will be their "ticket" into the system later, when you might not be watching.

Attackers are dreaming up new ways to infiltrate your messaging system and network every day. As messaging technology advances, so do the methods used to break into these new systems. I like to use the "car alarm" approach to ward off potential attackers. If you put enough security measures on your system to increase the risk that intruders will be found, they will pass over your system for a less risky target. If there is one thing hackers and attackers fear the most, it is being identified for all to see. Many Web sites publish the names of attackers and information about them that administrators can use to help protect their networks.

Even though administrators fear the problems associated with external attacks on their messaging systems, most problems are created by the inadvertent actions of users. A user could accidentally send a sensitive document to a distribution list that has a similar spelling to a user's name, or could send a very large message to the Everyone distribution list, tying up valuable resources. You can protect against these types of problems by using the option to restrict who can mail to distribution lists, and by establishing maximum message sizes for MTAs and connectors.

####
Security Measures in Windows NT

Windows NT Server is built on a very solid security platform currently listed in the NCSC's C2 Evaluated Products list. Exchange Server leverages the security features of the NT Server product to provide secure access to all messaging resources. Each object in the directory has properties that map to accounts in the NT security database. This tight integration allows Exchange to do what it does best, messaging, and NT to do what it does best, security. A user must have the proper security clearance before accessing objects such as mailboxes and public folders.

#####
Windows NT Logon Security

The heart of the advanced security within NT is the Challenge/Response method of authentication. When the user logs on to the network or accesses a mailbox resource, the server issues a challenge request to the client. The client networking software then sends a response to the server with the password as the encryption key. The server then decrypts the response to validate that the client knows the correct password. Because the password is never transmitted over the network in an un-encrypted format, it is nearly impossible for an attacker to get a password through packet sniffing.

NT Server also uses a distributed accounts database that is replicated from the Primary Domain Controller (PDC) to all Backup Domain Controllers (BDCs) so that account information is easily accessed from remote sites. When an administrator changes information for a particular user account, that information is automatically replicated from the PDC to all BDCs in two-minute intervals. If an unauthenticated user attempts to access a mailbox on the Exchange Server, she is automatically prompted to supply her domain logon account and password. This challenge can be processed by a BDC, eliminating the need to communicate with a PDC that might be a few network hops away.

#####
Windows NT RPC

Windows NT provides RPC services to support the security needs of Exchange Server, as well as the NT administrative tools such as Server Manager and User Manager for domains. The RPC service within NT uses the RC4 40-bit encryption algorithm from RSA Data Security, Inc., to encrypt traffic sent over networks. Because RPC allows an application to execute remote procedures on the server, it is very important that a high level of secure access be maintained. The RPC services support the challenge/response authentication method to eliminate the capability of a program to spawn a remote process via RPC if the user is not authenticated by an NT domain.

####
Microsoft Exchange Server Advanced Security

The capability to securely encrypt and digitally "sign" messages is definitely required when sensitive or private information is sent to any recipient. This is the only way to guarantee that the message can be seen only by the intended recipient, and it enables the user receiving the message to validate the sender. Microsoft Exchange Server includes an advanced security option, the key management server, that provides this level of security to end-users and administrators.

After the key management server service is installed, the advanced Security properties page becomes available for all the mailboxes within the site. The security administrator is someone who knows the advanced security password chosen when the key server was initially installed. That person has the ability to create new public and private keys for users from the Security properties page of any mailbox. This creates a security "token" that the administrator must give to the user to enter when setting up security within the client. The administrator should use a secure method to get the user his unique security token, such as via voice mail or by delivering it in person. When the user sets up advanced security from the Exchange client, he must supply a password that is used to encrypt the security file and must supply it each time advanced security options are used.

Within an organization one primary key server maintains the security database, and secondary servers are located at each of the other connected Exchange sites. The secondary key server forwards any security requests to the primary key server, which is the first key management server installed within the organization. Management of the key server involves enabling security for mailboxes, revoking security certificates, recovering security keys, and forgetting the remembered password. Users must renew their security once every year, and they are prompted when this time is near expiration.

For bulk encryption of message content, the key management server supports both the DES and the CAST algorithms with 56- and 64-bit key lengths in the United States and Canada only. CAST encryption with 40-bit keys is available worldwide due to U.S. government regulations on the export of encryption technologies. The key server automatically encrypts messages sent to international versions of Exchange using 40-bit encryption keys. Digital signatures and bulk encryption key exchange uses 512-bit public keys using encryption from RSA Data Security, Inc. All the advanced security options available with key management server are based on the X.509 standard certificate format, which allows for more security options in future versions of Exchange.

If a user attempts to send a signed message to a recipient who is not on a Microsoft Exchange Server, or who is in another Exchange organization, the message can be read but is not verifiable. Sealed or encrypted messages can be received only by recipients who are also enabled for advanced security. The Exchange client prompts users when they attempt to send an encrypted message to an unsecure recipient, and it gives them the options of sending the message unencrypted or canceling the message. I suggest that administrators create a security request form that users can mail to a public folder for requests to have advanced security enabled, thus providing a history of requests that can be used to track which users are using this level of security.

####
Microsoft Exchange Server Internet Mail Connector Security Options

The Exchange Internet Mail Connector has options that can increase the security of SMTP-based messaging and provide limits on the capability to attack your messaging system either directly or inadvertently. These options should be used with care, because they can create message delivery problems if not properly understood. Most of these features are best used when connecting your company's Exchange messaging system to the Internet, but they could also be used in a private network.

#####
Accept/Reject by IP Address

After an initial installation, the Exchange IMC is configured to accept incoming SMTP connections from any host or IP address. If you are using a firewall or sendmail relay host, you might want to configure the IMC to allow only connections from those hosts. This option is configured on the Connections property page for the IMC and is enabled by selection of the Accept or Reject by Host option. You must click the Specify Hosts button to specify which hosts can or cannot make connections to this server. If you want to reject messages only from specific hosts, ones that are not reliable or might be rogue, use this same option to reject by IP address or host name.

#####
Message Size Limit

By establishing message size limits on the messages on incoming and outgoing connections, administrators can prevent users and attackers from tying up the system with large message attachments. This technique might seem useful for incoming message transfer, but it is also practical for any outgoing messages. Because all message attachments must be encoded before they are transmitted, a large message could tie up your server for hours. There are also practical size limitations for Internet-based mail because the Internet is not designed for bulk file transfer. If your users need to transmit or receive large files, they should use FTP instead because it is built to handle these types of bulk transfers. This option also protects against external attack in which an attacker might send a large message to tie up the system to keep administrators busy while they look for security holes.

#####
Disabling Auto-Replies to the Internet

The Exchange client has the capability to create auto-replies with inbox rules or the out-of-office assistant. Most companies do not want this type of information to leave the confines of the corporate messaging system, because it could provide an attacker with an account to hack that they know will not be used for a specific amount of time. Inbox rules to forward messages to external recipients also might inadvertently transmit confidential information that can be intercepted on the Internet. Even worse, what if an auto-reply was accidentally sent to a mailing list? Auto-replies are disabled from the interoperability button on the Internet Mail properties page for the IMC and can be configured for all default connections or on a per-domain basis.

#####
Delivery Restrictions

Many corporations want the capability to control which users have access to Internet mail for security or tracking purposes. By using the Delivery Restrictions properties page for the IMC, administrators can specify which users or distribution lists have permission to send mail through the IMC. The best way to configure this option is to create a distribution list named Internet Mail Users to add members whom you want to be able to send Internet mail. This option can also be used to deny messages from specific recipients, such as known attackers/hackers or junk mail listservers. Use this option with care; all administrators should be aware that this option is being used so that they do not attempt to troubleshoot problems that are actually delivery restrictions.

####
Microsoft Exchange Client Security Features

Most users are unaware of the security risks associated with Internet-based messaging, and they might inadvertently send sensitive data to an attacker if they do not verify the address of the person they are replying to. The Exchange client always displays the "friendly" name and e-mail address of any sender in the message header section of the view message window. Users can also examine the headers of any message by selecting the Message Properties from the File menu, then clicking the Headers tab for display. You should publish a security document to all your users, advising them of the security risks and the steps they can take to protect their messages from attackers and hackers. I like to configure a public folder to publish all the company's messaging policies and set up a rule to remind users to review the documents regularly.

###
Future Enhancements

Exchange Server is a very robust and secure messaging system, with many options for connectivity to the Internet. The current version does fall short in a few key areas, mostly dealing with enhanced Internet services and access by "light" clients. By the time this book is published, the beta of Exchange 4.1 should be well underway. This updated version promises to bring new features to the table, especially in the area of Internet value-added services. The following bulleted items outline those new features. This text is taken from the document "Microsoft Exchange Server Features Native Internet Protocol Support," available on Microsoft's Web site at the URL www.microsoft.com/exchange:

- Using POP3 clients to access the mail services of Microsoft Exchange Server. POP3 is a basic client-server protocol for extracting messages from a mail drop. With POP3 support on Microsoft Exchange Server, any commonly available POP3 client, such as Eudora, Pegasus Mail, or the Microsoft Exchange Inbox with Internet Mail Service Provider, can be used to access mail.
- Using Web browsers to access Microsoft Exchange Server. The World Wide Web is a dramatically growing phenomenon on the Internet, and Web browsers have already become ubiquitous. Many large organizations are implementing Webs on intranets to distribute corporate information internally. Users running Microsoft Internet Explorer, Netscape Navigator, Mosaic, and so on will have live read/write access to Microsoft Exchange Servers. They will be able to send/receive mail, browse the directory, access private and public folders, and even have some access to Schedule+ calendars without requiring any additional software.
- Accessing the Microsoft Exchange Server directory using LDAP-compliant e-mail clients and Web browsers. LDAP is a Lightweight Directory Access Protocol used to access X.500 directories. Users will be able to choose from a wide variety of "light" e-mail clients and Web browsers to access directory information in Microsoft Exchange Server. In addition, LDAP support in Microsoft Exchange will potentially enable directory synchronization with other LDAP-compliant systems for increased interoperability.
- Making Internet newsgroup data available to Microsoft Exchange Server users. NNTP News feeds can be downloaded to Microsoft Exchange public folders. The capabilities of public folders can then be leveraged to replicate and control access to the information within an organization. Items within a newsgroup are assembled by conversation topic, which is the view preferred by most discussion groups. Users can then utilize Microsoft Exchange client software to read the articles and post replies that can be sent back to the Internet newsgroups.
- Using NNTP (newsreader) clients to access Microsoft Exchange Server. NNTP clients will be able to access information stored in Microsoft Exchange Server public folders.
- Using IMAP4-compliant clients and Web browsers to access Microsoft Exchange Server. IMAP is an emerging Internet standard mailbox access protocol. It enables synchronized online/offline mailbox access by "light" clients.

I took these descriptions directly from Microsoft's publicly published document on the Web because I would not want to misquote any of the features slated for a version of Exchange that will ship in the near future. I also am currently under a standard nondisclosure agreement that restricts me from discussing features of a beta product. Many critics have claimed that products from Microsoft suffer from "feature creep," which might be true for previous product offerings. Exchange Server has provided almost all the features promised in early 1991, which might explain why the product took longer to develop than originally planned. The next version will bring tight integration with these new Internet-based services to put even more information at the user's fingertips.

###
Summary

The Internet seems to ignore the laws concerning calendar time, with minutes spanning years of technological advancement. The constant change within this electronic world creates many challenges for businesses that are trying to develop solutions to solve common business needs. Connection costs and security risks might keep some companies away initially, but eventually they must get connected just to match their competition. Electronic mail is the core service offered by the Internet, but many value-added services such as search engines, newsgroups, and Web browsers are extending its value to users and companies. The massive volume of information contained within the Internet makes it a very valuable source for information storage and retrieval.

Exchange Server has tight Internet integration options to enable it to transfer messages to any of the almost 30 million recipients who connect up regularly. The Internet Mail Connector is the core Exchange component that uses standards such as SMTP and MIME to transfer messages to any of the millions of hosts on the Internet. Security options enable the IMC to communicate only with a restricted list of hosts, allowing it to seamlessly fit into any firewall solution your company might have. The Exchange client supports complete encryption of all data sent over an RPC connection, and it has advanced security options that enable users to digitally sign and encrypt confidential messages.

Even though the current version of Exchange Server supports the core messaging protocols for Internet-based mail, the next version will add features for services such as POP3 and IMAP4 access for light clients. New protocol support for NNTP News feeds and HTML publishing will extend the functionality of public folders, allowing data exchange with newsgroups and Web clients. These new features will allow Exchange to take the meaning of Groupware to the next level, enabling users on an Exchange messaging system to collaborate with the millions of users on the Internet.