9.14 Global messaging settings

---

Exchange allows administrators to establish global messaging settings that apply throughout the organization. These settings avoid the previous situation in Exchange 5.5, where administrators had to agree on settings across an organization and then apply them on individual servers and SMTP connectors. The value here is that you have consistency throughout an organization for the formats Exchange uses when it generates outgoing messages, originators that can send messages to the organization, how Exchange blocks spam, and so on. The global settings are:

• Internet message formats, which define the formats that Exchange uses when it sends SMTP messages to specific domains.

• Global message delivery settings, which define limits for the size of incoming and outgoing messages as well as any filters that you want to apply to incoming messages. Exchange 2003 offers far more sophisticated filter capabilities for incoming email.

• If you run Exchange Instant Messaging in an Exchange 2000 organization, you can set global parameters for IM here.

• On Exchange 2003 servers, you can define global settings for Mobile Access, such as whether you even want to support mobile devices.

This section explains how you can exploit global messaging settings in an enterprise implementation.

9.14.1 Internet message formats

The range of Internet message formats defined within an organization can be as granular as you wish. At one end of the scale, it is possible to define a single default format that Exchange uses whenever it sends messages to any other SMTP domain, such as compaq.com, microsoft.com, hp.com, and so on. At the other end, you can define a separate format for each of the SMTP domains with which the organization communicates. Few organizations find the need to achieve quite such granular control over message formats, and, as the world of messaging becomes less heterogeneous through the widespread acceptance of SMTP as the de facto standard for message interoperability, it is perhaps less important to be able to exert such a level of control. That is, until you meet a situation where servers cannot exchange messages until you change a particular setting for just one domain by defining a separate message format for that specific domain.

After you install the first server in an organization, only the default message format is active. As you can imagine, the default message format is very basic, and you need either to update the default format or add domain-specific formats to achieve the highest possible degree of interoperability with other email domains. Figure 9.50 illustrates two typical message formats defined in an enterprise-class organization. The left-hand screen shows a format that allows a limited set of interoperability with a domain that we know probably does not support all of the Exchange features. This domain could be a legacy Exchange organization served by the Exchange 5.5 Inter- net Mail Service, or another mail system that receives messages through an SMTP connector. The messages to this domain are in Exchange rich text format and always go in plain text; the text wraps at a set column position. The format purposely sets a lowest common dominator bar to ensure that recipients in the domain can read our messages, while allowing for the full range of delivery and nondelivery notifications. However, we suppress information contained in out of office replies.

Figure 9.50: Internet message formats.

The right-hand screen in Figure 9.50 shows the default format that Exchange uses if you do not define domain-specific formats. In this instance, we allow users to specify the format Exchange sends the message in, according to an option set through the client. Because we do not know where messages will go, automatic SMTP reply messages are disabled. However, we allow out of office notifications as well as delivery and nonde- livery reports, and we allow the display of the sender's display name.

Many organizations implement far more restrictive default message formats. For example, delivery reports and out of office messages are blocked and display names are suppressed, because it is possible that a recipient can learn some confidential details of an organization's structure if division names, job titles, or locations are included in display names. Administrators often restrict this type of information for "free" email domains, such as hotmail.com, aol.com, and msn.com, to try to limit the amount of spam sent to the organization. Spammers often use delivery reports and out of office notifications to validate the email addresses that they use. Once they know that an email address is valid, a spammer is happy to add the address to every list he or she maintains and sell it to other spammers, which then leads to an increase in incoming spam.

You can also see that we have blocked automatic mail forwarding in both cases illustrated in Figure 9.50. This means that users are not able to set up rules that forward new messages to addresses in the SMTP domains covered by these formats. The logic why is easy to understand, as you probably do not want users to forward messages outside the company without thinking about why they are taking this action. After all, it is all too easy for confidential information to escape through forwarded email. Under some circumstances, you may want to allow specific users to automatically forward email. For example, someone may be travelling and want to read their email but is not going to be able to access the corporate network. You set up a rule to automatically forward specific messages to another email service but you do not want to grant open access for everyone to forward messages to this domain. To get around the problem, you can create a mail-enabled contact that points to the target email address. Then, use the Delivery Options (on the Exchange General property page) to update the user's own AD account to add the new contact as a forwarding address and set the option to have Exchange deliver copies of the message to both their mailbox and the forwarding address. Remember to hide the new contact so that users do not see it in the GAL and to turn off the forwarding when the user returns from their trip.

The Message Format property tab allows further control for messages that Exchange sends to non-MAPI clients, such as Outlook Express connecting to a server via IMAP4. Figure 9.51 shows the settings for a well- known UNIX domain, sun.com. Because of its UNIX heritage, we can anticipate that this domain has few-if any-MAPI clients, and the vast majority of clients use POP3, IMAP4, or HTTP to connect to their mail server. The Uuencode coding standard is likely to guarantee the highest degree of compatibility and allow older UNIX clients to understand attachments, so it is good to select this setting for this domain. Newer UNIX clients are happy with MIME, so the choice depends on the client mix you have to support. Note that you can pass messages in BinHex format, required for some older Apple Macintosh clients. You could opt to use MIME encoding and pass messages in plain text format, since almost every email client is able to understand plain text. Newer Internet-style clients, such as Outlook Express 5.0 or later, also support HTML format messages, but you may encounter problems with older clients if you select this option. You can select both, meaning that Exchange will generate separate body- parts in plain text and HTML, but this will at least double the overall size of the message. Some users consider it rude to send HTML format messages to Internet mailing lists, because some of the recipients on the list may not be able to read the message. In this case, you can create a specific message format for the address of the list (e.g., msexchange.swynk.com) and define that messages for this domain go in plain text format.

Figure 9.51: Message Format properties for a typical UNIX domain.

Because it is reasonable to expect that the majority of clients connected to Exchange understand MIME, you can usually specify MIME for messages sent to other Exchange email domains. However, you should select plain text if you know that the other domain supports a mixture of clients, including some older versions that cannot read MIME messages. You can also elect to use HTML, if the clients are all late-generation Outlook Express (5.0 or later), rich-mode OWA, or Outlook (98 or later). The MIME and Uuencode settings only apply to MAPI clients. If set, the "Apply content settings to non-MAPI clients" forces Exchange to convert messages submitted by non-MAPI clients to the specified formats by first translating content into MAPI and then into the specified encoding format before transmission. In a perfect world of MAPI, this approach makes sense. In today's heterogeneous messaging environment, it does not, since it simply slows down message throughput by introducing the need for an additional format conversion. In large enterprise deployments, such as HP's (Figure 9.52), where messages are sent to many different email domains (both internal and external) that use different servers and clients, the pursuit of total fidelity leads to a large number of message formats.

Figure 9.52: A selection of Internet message formats used at HP.

9.14.2 Global message delivery aettings

Global message delivery settings allow administrators to set default values for the size of incoming and outgoing SMTP messages, the number of recipients in a message header, and to implement some primitive antispam protection through message filters.

The default values for message delivery permit unlimited message sizes and set a 5,000 recipient limit, which allows users to send messages with huge attachments, such as the famous 25-MB Star Wars trailer. Accordingly, most organizations impose stricter limits. For example, Figure 9.53 shows 5-MB limits set for incoming and outgoing messages. Note that the default values are just that-default. An administrator can override the default by setting explicit values for message sizes through the "Messages" property page of an SMTP virtual server. The logic here is that messages arrive and go through SMTP virtual servers, so the properties of a specific SMTP virtual server always take precedence. Note that these settings only affect messages that flow through SMTP virtual servers. Messages sent within an organization, whether across a routing group connector or via the MTA, do not respect these limits.

Figure 9.53: Message delivery properties.

Global settings allow administrators to set standards for an organization. While this capability is not important for small installations, it becomes increasingly essential as the number of Exchange servers in the organization grows.

---