Internet message formats are global policies that define the formats that every Exchange 2000 Server system in the organization uses to send SMTP messages to specific domains. Message delivery properties, also global in scope, let organizations set limits on incoming and outgoing message sizes, configure the maximum number of recipients allowed on a message, and filter out messages from specific users. You can use Exchange System Manager (ESM) to set Internet message formats and message delivery properties at the organization level so that you don't need to configure every individual SMTP connector (which you must do with the Exchange Server 5.5 Internet Mail Service—IMS).
Internet Message Formats
The Internet message formats that you define within your organization can be as granular as you want. At one end of the spectrum, you could define one default format that Exchange uses whenever it sends messages to another SMTP domain, such as compaq.com, microsoft.com, or hp.com. At the other end, you could define a separate format for each SMTP domain that your organization communicates with. Few organizations need the latter level of granular control over message formats, and as the world of messaging becomes less heterogeneous because of SMTP's widespread acceptance as the de facto standard for message interoperability, the ability to exert such a level of control becomes perhaps even less important. However, you still might run into situations in which your servers can't exchange messages with a domain until you define a separate message format for that domain to enforce a particular setting.
After you install the first server in an organization, only the default message format is active. You need to either update this basic default format or add domain-specific formats to achieve the highest possible degree of interoperability with other email domains. To work with message formats, open the ESM console, select the Global Settings node, then select the Internet Message Formats node, as Figure 1 shows. ESM then lists all the message formats currently defined for the organization. To work with an individual format, right-click it, and select Properties.
Figure 2 shows the most important settings for two typical message formats defined in an enterprise-class organization. You access these settings through the Advanced tab. The left screen shows the properties of a format that allows full interoperability with a domain that supports all the Exchange features. The domain might be a legacy Exchange organization served by the Exchange 5.5 IMS or another Exchange 2000 organization that receives messages through an SMTP connector. (Note that you don't have to set up a message format for your own Exchange organization because Exchange assumes, quite rightly, that all the servers in your organization can accept a message that any of them generates.) The format sends messages to the domain in Exchange Rich Text Format (RTF), and it doesn't wrap the text at a set column position. The format allows the full range of delivery and nondelivery notifications, including auto-forward to an alternative recipient. If you set the Exchange rich-text format option to Never use, Exchange converts messages to plain text, which an external mail system that doesn't support RTF or HTML messages might require.
The right screen in Figure 2 shows the default message format that Exchange uses if you don't define domain-specific formats. This message format lets users specify in their email client the format that Exchange uses for the message text. The default message format disables automatic SMTP reply and forward messages because you don't know where messages will go and whether the servers that eventually receive the messages will be able to understand their content. However, the format allows out-of-office notifications, delivery and nondelivery reports (NDRs), and the presentation of the sender's display name.
Many organizations implement far more restrictive message formats. For example, they suppress display names because recipients can learn details of an organization's structure, such as division names, job titles, or locations, from display names. To limit the number of spam messages sent to the organization, administrators also often restrict out-of-office replies and delivery reports for domains such as hotmail.com, aol.com, and msn.com that offer free email accounts. Spam senders often rely on delivery reports to verify that an email address they've sent mail to is valid. When spammers discover a valid email address, they add the address to all the lists they maintain.
The Properties dialog box's Message Format tab allows further control over messages that Exchange sends to nonMessaging API (MAPI) clients, such as an Outlook Express client that uses IMAP4 to connect to a server. Figure 3 shows appropriate settings for a well-known UNIX domain, sun.com. The MIME and UUEncode settings apply only to MAPI clients. If you select Apply content settings to non-MAPI clients, Exchange converts messages submitted by non-MAPI clients to the specified formats by translating content first into MAPI, then into the specified encoding format before transmission. In a perfect (Microsoft) world of MAPI, this approach makes sense. In today's heterogeneous messaging environment, it simply slows down message throughput by introducing the need for an additional format conversion.
You can assume that the sun.com domain has few, if any, MAPI clients and, because of sun.com's focus on UNIX, that the vast majority of this domain's clients use POP3, IMAP4, or HTTP to connect to their mail server. I've selected UUEncode encoding because it's likely to guarantee the highest degree of compatibility with UNIX clients and let UNIX clients understand attachments. Note that you can pass messages in BinHex format, which some earlier Macintosh email clients require. You could opt to use MIME encoding and pass messages to non-MAPI clients in plain text format because almost all email clients can understand plain text. Later email clients, such as Outlook Express 5.0 and later, also support HTML format messages, but you might encounter problems with earlier clients if you select this option. You can select Both, meaning that Exchange will generate separate body parts for the message in both plain text and HTML, but doing so will at least double the overall size of the message.
Sending HTML format messages to an Internet mailing list is considered rude because some of the recipients on the list might not be able to read the message. You can create a specific message format for the list address (e.g., groups.yahoo.com) and define that message format to use plain text format.
For sending messages from your Exchange email domain to other Exchange domains, MIME encoding is best because you can reasonably assume that most clients connected to Exchange understand MIME. Select Provide message body as plain text if the receiving domain uses a mixture of clients and you aren't sure that all the clients support a more advanced format such as rich text or HTML. If you're positive that the receiving domain's clients are all Outlook Express 5.0 and later or Outlook 98 or later or use Microsoft Internet Explorer (IE) 5.0 or later for Outlook Web Access (OWA), you can select Provide message body as HTML.
HTML is rapidly becoming the de facto format for email messages. Some administrators don't like their Exchange installations to receive HTML messages because attackers can insert malicious code in the HTML source. However, recent antivirus software and the ability of Outlook Express, Outlook, and OWA to block access to suspicious code should prevent potential attacks. In large enterprises whose employees send email messages to many email domains (both internal and external) that use different servers and clients, the pursuit of total message fidelity leads to a large number of message formats.
Message Delivery Settings
Like Internet message formats, message delivery settings are global settings that affect how Exchange deals with messages. As with message formats, you access these settings in ESM under the Global Settings node. Message delivery settings let you set default values for the size of incoming and outgoing messages, specify the maximum number of recipients, and implement some primitive antispam controls through message filters.
The default values for message delivery permit unlimited message sizes and set a 5000-recipient limit. Most organizations impose stricter limits. To change the limit, right-click Message Delivery, select Properties, and go to the Defaults tab. Figure 4 shows 5MB limits set for incoming and outgoing messages. Note that the default values are just that—defaults. An administrator can override the defaults by setting explicit values for message sizes on the Messages tab of an SMTP virtual server's Properties dialog box. The logic here is that messages come and go through SMTP virtual servers, so the properties of a specific SMTP virtual server always take precedence over global settings.
Defining Message Filters
Microsoft doesn't pretend that Exchange 2000's message filtering delivers the same range of functions as full-fledged content management products such as those from Clearswift. Third-party products, which can protect enterprises against spam, inappropriate content, and loss of confidential information, are designed for large enterprises. Exchange's message-filtering capability has traditionally been designed to provide some protection, especially for small companies.
However, you should know that Exchange Server 2003 delivers a huge upgrade in this area through the provision of connection filters (which can link to a list of blacklist providers such as the one at http://www.mailabuse.org), recipient filters, and sender filters. The combination of these filters, which you apply to the SMTP virtual servers that handle incoming SMTP traffic, can block a lot of spam. Outlook 2003 also includes a new junk email filter that users can configure themselves to filter out any spam that gets through the corporate filters.
The important thing to recognize is that Exchange and Outlook are gradually establishing serious defenses against spam, and those improvements are a welcome development. Exchange 2003 is so much better than Exchange 2000 in combatting spam that you might want to consider an early deployment of Exchange 2003 on the servers that host SMTP connections for your organization. That way, you can take advantage of the new filters to protect the organization while you prepare to upgrade the rest of your servers.
In Exchange 2000, you enable message filtering in two steps. First, you use the Message Delivery Properties dialog box's Filtering tab, which Figure 5 shows, to establish a global message filter policy that performs the following actions:
- Filters out messages that show a blank sender. Many spam originators send messages that don't include the sender's name. Thus, you can stop a certain proportion of spam by blocking messages with a blank sender.
- Accepts messages without notifying the sender. Spam originators sometimes depend on nondelivery or other notifications to know whether their messages are getting through. Your policy can accept messages and move them into a virtual black hole so that the originator doesn't know whether your mail server has filtered out the message or delivered it to a user mailbox.
- Archives filtered messages. To learn how successful your filtering policy is, you can capture copies of filtered messages in .tmp files in the \filter directory of the SMTP virtual server's working directory (for the default virtual server, the full specification is exchsrvr\mailroot\vs1\filter). On any reasonably busy server, .tmp files will quickly accumulate in this directory, so you shouldn't archive filtered messages for an extended period. Use the archive to test the effectiveness of your policy, then disable archiving.
- Creates a filter list. Figure 5 shows a simple filter for a specific user, but you can also use the wildcard (*) character to set up filters such as *@hotmail.com (which blocks all hotmail messages) or *guy*@aol.com (which blocks any message from aol.com users with the word guy in their username).
After you've set up the global message delivery filtering policy and are waiting for Exchange to replicate details of the change to the Microsoft IIS metabase, you must enable filtering on any SMTP virtual server that you want to protect. If a message arrives at a server before you enable filtering, Exchange will process it as before.
To enable filtering on an SMTP virtual server, right-click the server in ESM and select Properties. On the General tab, click Advanced. Then, for each IP address that you want to filter (typically, a server has a default IP address), select the address, click Edit, and select the Apply Filter check box, as Figure 6 shows. (Remember that an SMTP virtual server can be bound to multiple IP addresses.)
After you enable filtering on an SMTP virtual server, you can test the effectiveness of your global message delivery filtering policy by using Telnet to connect to port 25 (or whatever port is bound to the SMTP virtual server) and to create and send a message from an address that you've set the policy to filter. Figure 7 shows such a Telnet session. If the filter is successful, Exchange captures the message in a .tmp file in the \filter directory. Figure 8 shows the contents of a sample .tmp file.
Global settings let administrators set standards for an organization. Although this capability might be more important for large installations than for small ones, every administrator should be aware of the ability to set global properties for message formats and message delivery. You can use these global properties to give Exchange 2000 servers some spam protection, but Microsoft has added major spam-fighting improvements in Exchange 2003, so consider using this version if you want to take blocking action against spam.
