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.
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:
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:
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:
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 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.
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:
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.
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:
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.
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:
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:
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.
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:
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
