Adding Disclaimers

For some reason that only lawyers understand, there is a huge demand for a method to add a standard piece of text to outbound messages. These boilerplate text blocks usually say something like this:

This message is intended only for use of the addressee. If this message was sent to you in error, please notify the sender and delete this message. Blue Yonder Airlines cannot accept responsibility for viruses, so please scan attachments. Views expressed in this message do not necessarily reflect those of the company who will not necessarily be bound by its contents.

These disclaimers are largely useless. For starters, they come at the end of the message, so that the recipient doesn’t see the disclaimer until the forbidden content has been read. There’s also the opinion that adding a disclaimer to every message actually lessens the degree of legal protection you can expect (although this varies among jurisdictions). In addition, disclaimers clutter your inbox with a bunch of boilerplate text that no one wants to read. I could write all that, but I won’t, because judging by the number of times I’ve seen people ask how to add disclaimers I reluctantly concede that they’re here to stay. So, how do you add disclaimers?

Getting to the Message

In an ordinary Exchange 2000 server, the SMTP core has the opportunity to touch each message that leaves the server. (Of course, if you’re using X.400 connectors, the Exchange Message Transfer Agent (MTA), or some other transport carries the message so it won’t flow through the SMTP stack.) This gives us a wonderful opportunity to make changes to the outgoing message: all we need is a bit of code that follows the Exchange conventions for a message filter. These filters, more properly known as event sinks, can be called when various events occur, and they can do just about anything to the message in question.

Event sinks get their name from a bit of engineering lingo. You might think that destination is the opposite of source, but in electrical engineering, a sink is what receives the output of something else. An event sink is a piece of code that’s registered with the Exchange event handling system. When the event occurs (say, a new message arrives over SMTP, or a user deletes a message), Exchange loads and calls the sink code, and the sink has the opportunity to inspect (and in some cases modify) the message.

Rolling Your Own Sink

If you’re comfortable with Microsoft Visual Basic or C++, you can easily write your own event sink to add disclaimers to outgoing mail. There are three separate Microsoft Knowledge Base articles that include sample code for sinks: Q288098 includes sample code in C++, Q317327 provides step-by-step instructions and Visual Basic code, and Q317680 shows you how to add a sink using VBScript. All three of these methods share some common features and limitations.

The features are simple: the example sinks take a hard-coded disclaimer and append it to the end of the message. They can append both plaintext and Hypertext Markup Language (HTML) versions. That’s it. Although that might not seem like much, remember that the code samples in these three articles are just that: samples. You can certainly use them as a basis to implement your own disclaimer mechanism, but they’re not intended for production use.

The sample sinks have a few drawbacks. They only work with messages that trigger SMTP transport events—that is, any message that bypasses the SMTP event mechanism won’t get a disclaimer. In particular, messages submitted by Messaging Application Programming Interface (MAPI) clients whose mailboxes are on the same server, or those that originate over foreign connectors, won’t have the disclaimer appended to them. However, if the message eventually transits a server over SMTP, and if that server has the sink installed, the disclaimer will be added. That’s why most disclaimer software ends up installed on the SMTP bridgeheads that connect an Exchange network to the Internet.

Second, the sample sinks use the OnArrival event, so they get called when messages arrive for outbound processing. This might sound good, but OnArrival sinks are synchronous: while the sink code is processing a message, no other sinks can be running. Because SMTP processing depends on a number of internal sinks that Exchange provides, when your OnArrival sink is running, all other message processing must stop. This is less than ideal for busy servers. They don’t do much error handling, either.

Using a Commercial Product

If the sample sinks aren’t suitable for production use (trust me; they’re not), you have two alternatives. You can write your own from scratch, or you can spend some money on a commercial product. There are a wide variety of disclaimer-adding products on the market. Most often, the ability to apply disclaimers is bundled into products that offer other content-management features like keyword scanning and pornography filtering. However, if all you want is disclaimer capability, there are several commercial disclaimer products on the market. Two are worthy of special mention because they combine useful functionality with prices less than $150, which is much cheaper than trying to write and support your own tool:

• Exclaimer (http://www.exclaimer2000.com) offers a simple, flexible tool for applying text or HTML disclaimers to individuals, Active Directory groups, or domains. You can specify custom rules for attaching disclaimers to inbound or outbound mail; one particularly nice feature is the mail-merge-like ability to specify text tags like “[RecipientName]” that are filled in when the disclaimer is included. The included HTML editor is a nice touch, too. As a bonus, Exclaimer can also monitor inbound or outbound mail by copying it to a specified recipient.

• DisclaimIt (http://www.netal.com) provides a Microsoft Management Console (MMC) snap-in and can be managed using the Windows Management Instrumentation (WMI) interfaces; this is a nice feature because it makes disclaimer management completely scriptable. Like Exclaimer, DisclaimIt allows you to specify which SMTP domains should or should not receive disclaimers; DisclaimIt adds the ability to trigger disclaimers based on particular message headers. DisclaimIt runs on the Internet Information Services (IIS) SMTP server as well as on Exchange 2000 servers, so if you have a perimeter SMTP server you might be able to offload disclaimer processing to it.

Either one of these products will do the trick if all you want is disclaimers; if you also need content scanning or other management features, one of the integrated packages discussed later in the chapter might be helpful.