10.9 Helping users to do a better job

---

Every email client has its unique features set. You have to manage them if optimum use is to be made of available system resources such as disk space and network bandwidth. In this section, we discuss some common issues that administrators should consider to help users optimize system resources, including:

• How to reduce the network load generated by clients

• How to limit the size of messages generated by clients

• Whether to add legal disclaimers to outgoing messages

Your company has a work culture of its own, so some give and take is required to achieve a balance between the perfectly managed systems valued by the administrators and the desire of the users to send messages without interference.

10.9.1 Eliminating bad habits to reduce network and storage demands

Every Exchange design pays a lot of attention to the number of servers deployed and how best to connect the servers together, along with plans to control public folder and directory replication. We often give less attention to the traffic generated by clients and how to reduce network demand, yet this aspect can be a very important part of a deployment project.

Users generate network load through their normal activities, such as sending and reading messages. Benchmarks such as LoadSim typically use standard messages ranging in size from 1 KB to approximately 10 KB that contain text, some attachments, and maybe a meeting request or two. However, real-life activity is always different from simulations and this is the reason why designs often demonstrate flaws when exposed to real-life pressure. People are very curious and use software in ways you could never imagine. If you do not educate users to respect the need to preserve network resources, they are unlikely to consider the ramifications of, for example, dragging and dropping a large PowerPoint presentation to a message and sending it to a distribution list.

Some of my personal dislikes regarding bad email habits are discussed in the following text.

Complex, object-ridden, auto-signature files

Because I work across low-bandwidth network links so often, bloated auto- signature files are the bane of my messaging life. The difference in connect times across 28.8-Kbps connections that results because people send messages that contain 2 KB of useful data but end up at 50 KB to accommodate a spinning, 3D, or other form of graphic-intense logo is annoying when you have just one message. The degree of annoyance becomes infuriating when 20 percent or more of the messages in your Inbox is similarly bloated. Apart from absorbing valuable bandwidth and slowing user ability to process email, graphics soak up storage and create pressure on mailbox quotas. It would be interesting to analyze the content of some Exchange Mailbox Stores to try to determine just how much graphics and other useless data they contain. We should calculate how much work administrators do daily to take backups of that data, not to mention the expense required to provide and manage the storage that the data occupies. For example, if you include a 50-KB graphic in your signature, then after you send 100 messages, your mailbox contains 5 MB of redundant, duplicated graphics. Would you or any other user accept a voluntary reduction of 5 MB in a mailbox quota? Yet many users cheerfully accept this overhead without thinking! Moreover, if you scale this up for 1,000 users on a server, you end up with 5 GB of useless data.

Auto-signature files convey some information about a message's sender; this feature appeared first in sendmail-based UNIX email systems. Normally, you add some auto-signature text to each message to provide details of your return email address, telephone and fax numbers, and perhaps some witty "thought of the day." Text-based data does not occupy much space and no one can really complain about auto-signatures until encountering some of the crazy ones that circulate today. Everyone is aware that cut and paste allows you to insert objects into message bodies, and it did not take people long to discover that they can do the same thing for auto-signatures. We can clearly see the intention behind auto-signature files in RFC 1855, which covers netiquette:

If you include a signature, keep it short. The rule of thumb is no longer than four lines. Remember that many people pay for connectivity by the minute, and the longer your message is, the more they pay.

RFC 1855 appeared in 1995 and focused on a world where dial-up connects were the de facto standard, and people worried about paying telephone companies by the minute, a feature of life outside the United States. The authors probably did not foresee a time when users could cheerfully include a spinning, multicolor, 3D logo into their email signatures.

If you are determined to use a graphically rich auto-signature, it is easy to include your favorite logo (which may not be the approved version of the corporate logo). Before you begin, find the logo you want to use and save it to a local directory. For Outlook, click on Tools and then Options to access the "Mail Format" properties, and then click on the Signatures command button. You can create a new signature or edit an existing signature file. When Outlook places you in the signature editor, you can click on "Advanced Edit" to force Outlook to launch an HTML editor. Usually, Outlook launches Microsoft FrontPage (Outlook 2000, 2002, and 2003) and you can paste the logo directly into the HTML content. After the logo is in the signature file, you can use the standard editor to change text information, such as your phone numbers, but you must use the advanced editor to make any change to the graphics. Outlook stores signature files in the C:\Documents and Settings\UserName\Application Data\Microsoft\ Signatures directory.

I once inserted a digital picture of myself at the Microsoft Exchange Conference (2000) into my auto-signature, as shown in Figure 10.43. The net effect is that I added 250 KB of graphics to every outgoing message! Even with Outlook 2003's compression algorithms brought into action to reduce the size of the graphic, the outgoing messages are still 80 KB. If you must include a logo in your auto-signature file, then use a low-resolution GIF file to reduce the impact of the logo to an acceptable limit. For example, HP recommends users include a 1.11-KB GIF file in their auto-signatures. This is much better for all concerned than the other variations of corporate logos that are usually designed to be used in advertising or other graphically rich situations. Of course, even after providing a reduced graphic and making it known that the graphic is available to use, people still use whatever bloated graphic they can find.

Figure 10.43: Adding an outrageous graphic to an auto-signature file.

Users often do not realize that email gateways might negate the desired effect of the logo on external correspondents if the gateways strip out graphics in message bodies (not attachments) as messages pass through. Companies are rightly concerned about viruses, and it is possible to hide a virus behind a graphic or embed instructions to launch a virus in a graphic, so it is also possible that antivirus scanners will remove the logos. Therefore, the result is that the only people you share the logos with are internal recipients, who probably already know what your company's logo looks like.

Another issue is the impact on recipients. While it may be acceptable for you to let everyone else in the company know what the current corporate logo looks like, it is a different matter when you send excessive data to other companies, because you are now consuming their network bandwidth, their time, and their storage to hold whatever you care to transmit. People already complain about spam, because these messages absorb resources that they have to pay for. Why would they not treat your graphically intense messages in the same light?

Apart from logos, trademarks, and other public information, such as a URL to the company's Web site, it is unwise to include corporate information in an auto-signature file. Titles and the name of your group are acceptable, as long as they make sense to the recipient, but if you send this information outside the company, you always have to be aware that recruiters or other people who want to learn about the company's organization for their own purposes could use the information. In addition, the GAL already contains all of the information you may want to transmit, so it is available to internal recipients. If required, they can click on the name of the sender or a recipient in the message header and view the properties of their entries in the GAL to discover details such as phone numbers, assistants, and even reporting relationships. Of course, the GAL is sometimes out-of-date, but it is usually the most reliable source of corporate information. Outlook 2003 makes things even easier by using smart tags (Figure 10.44), so you can click on a recipient to find out whether he or she is online (through instant messaging), available for a meeting (by checking free and busy information), and what his or her office phone number is (from the GAL).

Figure 10.44: Outlook smart tags.

Mail storms generated by "Reply All"

I'm sure that some sophisticated research into user interfaces has been conducted by messaging vendors over the years, but maybe they made the "Reply All" function a little too easy to use. The fact is, it is just too easy to reply to everyone while being blissfully unaware that thousands of people were circulated on the original memo. In addition, when many people add their own "me too," "good idea," or "I agree" contribution to the discussion, and reply to everyone else, we then have a fully fledged mail storm. With respect to bandwidth, two problems exist here. First, we have to deal with the sheer volume of messages generated by the contributors. Fortunately, there is an easy solution to this problem, because you can use the delete key to remove all the "me too" responses from your mailbox. I find that turning on the "View.AutoPreview" function in Outlook allows me to quickly scan my Inbox and identify candidate messages for instant culling.

The second issue is more invidious. Users tend to accept default options and do not want to mess too much with client settings in case they break things. By default, Outlook inserts the text of the original message into a reply, so you end up with messages that gently swell in size as Outlook adds each reply (short as it might be) to the thread. You can get rid of the "me too" replies by deleting them unseen, but this technique isn't so useful when the reply actually contains something meaningful and there is no real option except to download the full message, complete with the original text. As an example of the potential impact on message size generated by the "reply all syndrome," let us consider what happens in a typical email exchange.

• User A sends a message to seek opinions from ten colleagues. The original message is 5 KB.

• User B uses "Reply All" and includes User A's original text. This message is 10 KB.

• User C now responds with "Reply All" and includes the text from User B's message along with comments. The message has grown to 20 KB.

The cycle continues until everyone has contributed, and the final message that holds the complete thread might now be 100 KB. At this point, everyone involved probably has ten messages occupying 200 KB or more in his or her mailbox. The single-instance storage model in the Exchange Store helps to reduce the impact of this duplication, but you could end up with up to 2 MB of wasted space if the recipients' mailboxes are in different Stores. While tidy users will clean up and only keep the last message in a thread, many users only remove messages when forced to by reaching their quota and not being able to send any further email. The result is a lot of redundant information that is stored from here to the end of eternity, unless you use an automated tool such as the Mailbox Manager to clean up the mess.

There is no harm in inserting the original text in a reply, providing you use the text to add context or as the basis for edits. There is simply no case for including the original text just because it is there, so it is best practice to take the time to remove extraneous text before sending messages.

Attaching large files

We live in a drag-and-drop world. Users expect to be able to drag a document to their email client and drop it onto a message. Unless you compress an attachment, Outlook and Outlook Express take no further action to minimize the impact of sending large files with messages. This situation changes with the combination of Exchange 2003 and Outlook 2003, where compression techniques are used.

There is no doubt that the average size of messages has grown steadily over the last decade. Ten years ago, most corporate email accounts were on "green screen email" systems and the average message contained less than a page of text. Thus, fetching a message from the server generated no more than 4 to 6-KB traffic and we happily used 9.6-Kbps modems. If you track statistics from Exchange servers over a period, you will invariably find an increase in the average message size—to well over 100 KB in some companies. While messages with large multimegabyte attachments are the chief culprit, the reasons why today's email systems handle much larger messages include the following:

• The power of the drag-and-drop paradigm implemented in software such as Windows Explorer and Outlook makes it so easy to add an attachment to a message that people add attachments without thinking.

• People use graphics more extensively to convey ideas, so documents, presentations, and spreadsheets are full of diagrams, charts, and pictures.

• A wider range of software is used and few packages compress data.

• Especially in the United States, network bandwidth is more plentiful and far cheaper, so people take less care about bandwidth absorption.

• Users have better message editors (including Word), so they can include graphics in message content.

• Storage is also far cheaper, so the ever-growing size of files does not have a huge cost impact; users can have larger mailbox quotas, so they do not see the need to change the way they handle attachments.

You can try to educate people to use compression utilities such as Win- ZIP to process large attachments before adding them to messages. Word and basic graphic files such as bitmaps compress well, but compression utilities are less successful in reducing other file types (e.g., PowerPoint). However, users often forget to compress attachments, and the additional step makes the email system harder to use. In addition, administrators need to distribute copies of the chosen utility to all desktops.

If you are not able to deploy Exchange 2003 and Outlook 2003, you can still trade CPU cycles (to process the messages) against bandwidth and storage by installing an add-on product. For example, the Max Compression product from http://www.c2c.co.uk/ automatically compresses and decompresses attachments as users send and receive them through Outlook. Modules of the same product are available for Outlook Web Access working against both Exchange 5.5 and Exchange 2000 servers.

Examples of good email habits include the following:

• Because many people use smartphones, PDAs such as the BlackBerry, and Pocket PCs to read their email, it is best to write short messages or at least place the key points up front so that readers can under-stand what you want to say without going through multiple screens. It is also a good idea not to have important points or questions at the bottom of messages, because readers may never see them.

• To reduce the number of messages, do not respond immediately to a request if you do not have all the necessary information. Instead, wait until you have the information and then send a complete answer.

• The volume of email continues to rise, so it is helpful to use clear subjects so that recipients can pick the most important messages out of their Inboxes. Spammers pay a lot of attention to creating compelling message subjects and maybe this is something we can learn from them. If the topic being discussed changes during a message thread, alter the message subject to reflect the new discussion.

• Never use Word to compose a message and then send it as an attached document. Instead, use the advanced features of the message editor to format your text. Sending unnecessary attachments occupies valuable network bandwidth, ties up disk space, and makes the message hard for users of smartphones and hand-held devices to view.

The final point may save your job, or at least stop you from angering someone. It is always a good idea to compose the world's most cutting and sarcastic response to the inept ideas expressed in a message you receive, but it is even better to save your response as a draft. You can then come back to it a few hours later when some mature reflection may convince you that it is a bad idea to send the text as written. Outlook offers the option to recall a message, but given the speed with which Exchange delivers email across most networks, recipients may already have read your message before you attempt to recall it.

10.9.2 Abusing disclaimers

The legal profession loves words. It especially loves words that establish a strict limitation of liability in as many circumstances as possible. Given the high profile of recent court actions that have featured email as exhibits, including the Arthur Andersen/Enron affair and the action taken by the U.S. Department of Justice against Microsoft, it is reasonable to assume that companies around the world have consulted their lawyers in an effort to restrict corporate liability for the actions of their employees.

The appearance of disclaimer text on the bottom of every outgoing message is evidence that managers are listening to the lawyers, but I often wonder whether this text has any effect. While the original disclaimers were blunt and to the point, some of the disclaimers are now bigger than the average size of messages they seek to protect. Apart from making messages larger, the disclaimers make messages harder and less friendly to read, especially if you insert the disclaimer into every reply as well.

On a purely facetious note, you might consider that implementing policies of this nature is a much-loved tactic of the PHB class. The real questions that we need to ask are whether recipients take very much notice of the dire legal warnings contained in the disclaimer and whether the warning has any legal meaning whatsoever in some of the places where people read the message. A legal warning that is valid in the United States is probably not effective in Eastern Europe, so all it does is keep managers and lawyers happy. On a more fundamental point, email is not like a fax, which someone can read as it arrives on a machine shared by a department or a complete building. Usually, email has a more precise delivery mechanism, since messages go to a known recipient who presumably must authenticate to a server before he or she can access the mailbox to pick up messages. However, these arguments do not usually hold much water when presented to the legal community. Your mileage will vary and policies differ from company to company.

As an illustration, here is a real-life example of a disclaimer seen in messages posted to the Internet mailing list for Exchange. I have removed the company name to protect the innocent. Of course, you have to question the wisdom of sending any message marked "confidential" to a public mailing list, but that is another matter.

This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, you have received this email in error. Any use, dissemination, forwarding, printing, or copying of this email or any file attachments is strictly prohibited. If you have received this email in error, please immediately notify "Company Name" by telephone at 999 999 9999 or by reply email to the sender. You must destroy the original transmission and its contents.

"Company Name" has implemented antivirus software, and, while all care has been taken, it is the recipient's responsibility to ensure that any attachments are scanned for viruses prior to use.

-------------------------------------------------------- 

Products such as Clearswift's MimeSweeper (www.clearswift.com) include features to add disclaimers on all outgoing messages. Alternatively, you can write your own SMTP transport event to do the job, remembering that you may have to install the event on all servers that handle email.

10.9.3 Out of office notifications

Out of office notifications (otherwise known as OOF) inform correspondents that a recipient will not be able to deal with their messages for some reason. As the name implies, the most common reason is that someone is traveling and will not have access to email for an extended period. Given the ability of people to reach their email via dial-in connections when they are on the road, out of office notifications are most useful when they tell you that someone is away on vacation. To be effective, the text of a notification should tell correspondents:

• A brief reason why the recipient won't be able to respond

• The next time the recipient is likely to be able to process email

• An alternate person they can contact for specific reasons, such as management of a project or to provide information on a product, together with contact details (email addresses and phone numbers)

Properly used, out of office notifications are very useful. The issue is whether to allow Exchange to send OOFs outside the company. You can control OOF transmission on a domain-by-domain basis by creating a separate Internet message format for specific domains or by amending the default "*" format if you use it. Once you make the decision to transmit OOFs, the trick is to get users to include the right information, as outlined previously. Unfortunately, short of creating a script to send messages to every user in the organization and collate what comes back, there is no automated way to check user OOF information. Best practice is to create awareness within the user community regarding the effect a sloppy, unin- formative, or overly informative OOF can have.

In Exchange 2003, you have another tweak that you can apply to control OOF notices by inserting a registry setting to limit OOF generation back to the originator only if the recipient is explicitly mentioned as a TO: or CC: for the message. In other words, an originator will not receive any notices from messages going to non-Exchange distribution lists such as Internet mailing lists or even distribution lists that exist in another Exchange organization. To suppress the notices, add the "SuppressOOFs- ToDistributionLists" parameter as a DWORD value to the registry at the following location:

HKLM\System\CurrentControlSet\Services\MSExchangeIS\ ParametersSystem

Set the value to 1 to suppress OOFs, or leave it at 0 for normal behavior. You need to add this parameter to all mailbox servers before it becomes 100 percent effective.

10.9.4 Some other bad email habits

There are many other smaller points of email etiquette that cause people grief. These include:

• Replying to a message that you received as a BCC recipient when the author really would prefer you not to

• Forwarding a message to a new set of recipients without permission of the original author. This becomes an especially grievous fault if you send the message to external recipients, because you may disclose corporate information that should stay inside the company.

• Using an auto-reply (OOF) message where you do not give useful information to the recipient. It is nice to know that people are enjoying themselves on holiday, but it is even better to know where to go (preferably with a telephone number and email address) in their absence. Obviously, you need to balance informing internal correspondents with the requirement not to provide sensitive company information to external people who receive the OOF.

Minor breeches of etiquette usually cause frustration only and do not absorb additional resources. However, the frustration level can be intense, especially if you inadvertently tell someone about something he or she should learn about in another manner. For example, telling someone that you have heard that he or she is about to be promoted when you are not the boss is possibly acceptable, but telling a person that he or she is going to move to another job is not.

---