|
|
|
|
The Microsoft Exchange Server Internet Mail Connector
Last Updated 2/3/2009 3:42:58 PM
Abstract
This chapter explores the differences between the Internet Mail Connector in Exchange 4.0 and Exchange 5.0.
EXCHANGE SERVER 5.0
There are several differences between the Internet Mail Connector in Exchange 4.0 and Exchange 5.0. The most obvious difference is the name change to the Internet Mail Service (IMS), as you can see in Figure E.1.
The IMS is implemented natively to the server and is installed with the Internet Mail Wizard by choosing New Other from the File menu. The wizard makes installing the IMS much simpler and eliminates a number of the problems experienced by Exchange 4.0 users. The native implementation is said to result in faster performance, though we have not yet seen any benchmark test results.
Besides these changes, the IMS differs from the IMC in three ways: the IMS generally provides more support for RFCs, it includes new routing features, and it supports new security features. We will consider each of these differences in greater detail.
RFC SUPPORT
The IMS supports more Internet RFCs than the IMC, including
- RFC 1870, SMTP Service Extension for Message Size Declaration
- RFC 1891, SMTP Service Extension for Delivery Status Notifications
As well as supporting more RFCs, Exchange Server 5.0 supports additional functionality in RFCs 1521 and 1522 regarding MIME (see Chapter 2) and includes additional character sets.
The press release for Exchange Server 5.0 describes the function of some of these new features very well. Discussing RFC 1870, the press release (available at http://www.microsoft.com/exchange/inetmail.htm) indicates:
|
Many products today have provided a way for the Administrator to enforce the size of messages they wish to send or receive from their hosts. Microsoft Exchange Server does this today. The problem with this approach has been that there is no way to communicate the limit to the sending host before the message transfer is initiated. Hence messages are rejected after a certain amount of data has been transferred, tying up system resources unnecessarily. RFC 1870 allows the receiving host to indicate the maximum size of a message they can accept, and therefore other conforming hosts will not send any data on the wire if this size is exceeded. This is a recommended protocol, and any SMTP message host should implement it fully in order to manage Internet bandwidth. |
For example, in Chapter 6 we discussed the process for limiting the size of messages that can be transferred by the gateway (see Figure 6.9). In Exchange Server 5.0, the process for negotiating a message used by the server lets it reject a message before getting even the first byte, provided that the originating mail server also supports RFC 1870.
Discussing RFC 1891, the press release points out that:
|
Historically on the Internet there was no way to verify if a message had been received or read at its destination. While a few products tried to implement this capability using non-standard methods, not every host supported these methods so the result was uneven. Using RFC 1891, Exchange Server provides the ability to request a delivery status notification for any recipient on a message. Email users will get delivery status notification across the Internet from other Exchange Server 5.0 host, or from other messaging systems that support this standard. |
Lack of delivery receipts for Internet messages has long been a complaint of users, and Exchange Server 5.0 supports the new standards that make delivery receipts possible. Note again, however, that these receipts will be received only if the recipient's mail system supports the RFC as well. Some of the additional fields specified in RFC 1891 are not supported yet.
ROUTING TAB
As indicated in Chapter 6, Exchange Server 5.0 has added a couple of tabs to the property pages for the Internet Mail Connector/Service. The first of these two is the routing tab, as shown in Figure E.1, above. In Chapter 7, we mentioned that Exchange Server 4.0 included an extension DLL that lets the server act as a mail relay agent for routing messages to other domains (see page 158). This routing capability is integrated into the IMS in Exchange Server 5.0 and is configured through the routing tab. If you have a domain for which you need to route mail, click on Add from the window in Figure E.1 and add the domain name to the Routing Table Entry dialog box, as shown in Figure E.2.
In this case, we have indicated that any mail received for a recipient in the sakellariadis.com domain should not be processed by the connector in the usual way; rather, it should be rerouted immediately to whatever host handles mail for the sakes.com domain. When you click OK, this entry appears in the list in the Routing tab (Figure E.3).
Thus, the Routing tab enables the Internet Mail Service to act as a smart host that can route messages between the Internet and other SMTP hosts without the need to define custom recipients in Exchange Server. For incoming mail, the Help file has a very useful table, reproduced here as Table E.1, that explains the use of this feature.
For example, if you want Exchange Server to be the single point of entry into your organization and you have mail recipients on a third-party system (for example, a Unix host running Sendmail), you could use the Routing tab to route mail to that system. Without this feature, to keep the incoming mail from being rejected, you would need to either do a directory synchronization between the Exchange organization and the third-party system or add custom recipients manually into the Exchange Global Address List.
SECURITY TAB
The second new tab in the IMS is the Security tab (Figure E.4).
One of the biggest concerns about the Internet is security, and Exchange Server 5.0 gives you several mechanisms by which to protect SMTP messages sent over the Internet. The Microsoft press release expresses the concern in this way:
|
One of the single biggest concerns on the Internet is security. Most if not all SMTP communications occur in the clear, since there was no agreed upon mechanism to encrypt the session. This is still an area of concern on the Internet, and a number of people are thinking about the right solutions. Realizing that our customers need this functionality today, we have implemented support within the SMTP framework to encrypt sessions between consenting hosts. |
The Security tab in the Internet Mail Service lets you specify two related features that increase the security between consenting hosts.
The first feature, “Show in each message whether that message comes from the Internet,” is a header that Exchange Server 5.0 adds to messages passing through the connector, compliant with the various RFCs for the Header fields for SMTP messages. You can see this header by manually viewing the headers (if you are looking at the message through a sniffer, for example) or using the Exchange 5.0 client. The header of the message will then show whether the message traveled through the IMS in its journey from the sender to the recipient. This information could be of value to the recipient, because the possibility always exists that the message was tampered with or viewed en route.
The second feature, Secure Outbound Connections, lets the Exchange administrator limit the IMS to talking to remote connectors in Windows NT sites over trusted connections. For example, if you are connecting remote sites of the same organization via the IMS, this feature lets you ensure that a hostile agent is not impersonating (spoofing) the identity of the remote site.
The security feature that concerns many users of Internet mail in general is that messages are transmitted in 7-bit ASCII, so that most text messages are entirely legible to any unintended recipient of the message. Starting with version 4.0, Exchange Server includes a security feature called the Key Management server that lets users send mail that is encrypted over the wire but only to users within the same organization (that is, to users who have the same Key Management server). Exchange Server 5.0 lets you send encrypted messages to users in different organizations.
When you implement Advanced Security in an Exchange organization, the user can encrypt or digitally sign a message simply by clicking on an icon in the toolbar or by selecting Encrypt (Seal) from the Tools menu. The recipient of an encrypted message sees a lock icon by the message in the Inbox and can only decrypt and read the message if that recipient is the actual intended recipient of the message. Recipients demonstrate their identity by their network login and by entering a private key/password into a decryption dialog box that comes up when they try to read the message. Any unintended recipients of the message cannot read the message.
The end-user process for encrypting and decrypting messages sent with the Exchange client is very user friendly, and the messages themselves are encrypted using CAST 40, DES (56), or CAST 60 algorithms. Note, however, that the purpose of the process is to encrypt messages sent over the Internet to users only in Exchange organizations.
Exchange Server 5.0 provides one more facility to secure SMTP messages sent over the Internet, in the form of encrypting messages downloaded with the POP3 protocol. If you enable POP3 support for a mailbox, you have the option of allowing three types of authentication:
- Basic
- Windows NT Challenge/Response
- Secure Sockets Layer (SSL)
If you pick the SSL method of authentication for the mailbox, all POP3 sessions will encrypt both the authentication session and all subsequent data traveling over the wire. This feature provides, therefore, an encrypted and secure method for transmitting SMTP messages from a server to a client.
|
Page:
1 |
|
|
|