The appearance of a mail message is the first thing that people notice, and it's one of the most important. It has a strong influence on the impression that you make on people you have never met. In this section, we'll look at the following topics:

• Message layout
• Using MIME attachments
• Correct time and time zone

Message layout

A lot of badly formatted messages come from bad mailers or badly configured mailers. The following mailers are known to send out badly formatted messages without you finding out about them:

cc:Mail
Eudora
exmh
Microsoft Exchange
Microsoft Internet Mail
Microsoft “Outlook”
Netscape

As you can see, the mailers in the Microsoft world are frequent offenders. If at all possible, use a UNIX mailer. If you can't, the following links make suggestions about how to set up Microsoft “Outlook” or Netscape Communicator.

Since Microsoft discovered the Internet, it has introduced a number of changes to mail formatting which contravene the standards. Apart from the fact that Microsoft mailers are non-standard, the changes are also bad. Let's look at some of the more common problems:

• We saw in the Internet Standards that there are two basic standards for message bodies: RFC 2822 and MIME (RFC 2045). The default format is the RFC 2822 format, and it is called text/plain in the MIME standards. Mail readers must display it exactly as transmitted.

This may seem a funny requirement. To understand the reasoning, consider the following message:

If the reader is allowed to wrap the message, it could end up looking like this:

Clearly, there must be some way of specifying that the message text should not be wrapped. That's text/plain. There are special MIME attachment types which allow wrapping, although I still think that this is a bad idea. If you specify that your message may be wrapped, you're making an assumption about what the receiver's screen looks like. Even if you're right some of the time, you can't be right all of the time. For example, one person may have a screen 200 characters wide in order to be able to display long log file entries, but he won't want to see his text that long.

When sending conventional mail, Microsoft mailers often send text that doesn't look like what they display on the screen. Without telling you, they either transform paragraphs into one long line, or they break lines into two, one long and one short. The resulting message looks like:

This example shows the elm mail reader. This kind of message comes from a mailer which expects the receiving end to do paragraph wrapping. This is an invalid assumption and violates the spirit of MIME. In addition, RFC 2822 limits line lengths to 998 characters. It's easy to exceed this limit in a paragraph. The results may be truncated messages or gratuitous line breaks after 998 characters.

Microsoft themselves recently supplied an excellent example of this breakage. Since they explicitly allow verbatim reproduction, here it is.

Alternate long and short lines:

This kind of message comes from a mailer which wants to know better than you where the line should end. Typically, it could be the same mailer as before (Microsoft “Outlook” is a good example), but configured to limit the line length. For example, you might have specified a line length of 65 characters, but you write a line of 70 characters before hitting the “Enter” key. The mailer remembers the end of your line, but it decides it's too long, so it splits it into two lines, the first (long) with as many words as will fit in 65 characters, and the second with the rest.

The insidious thing about these conversions is that you may not be aware of them. If you get messages from other people which appear to be garbled, your mailer may be reformatting them on arrival, in which case it is possibly reformatting them before transmission.

As if that weren't enough, consider what happens with “quoted text”. As we will see in Message layout issues, when you reply to a mail message, it's good practice to include relevant parts of the text to which you reply, so that your partner can remember what the discussion is about. This is especially important for people who go through a lot of mail--200 messages a day are not uncommon.

The standard way to quote text is to include a > character at the start of each line of quoted text. The problem is that this makes the line longer, especially if you include a space after the > for legibility's sake. The results can look like this:

Here, the text has been quoted multiple times. The mailer (Microsoft Internet Mail Service (5.0.1458.49)) has tried to wrap the lines, but it has not understood that it is wrapping text with four levels of quotes, and only puts a single quote on the continuation lines. After a couple of cycles of this kind of mutilation, the message is completely illegible.

This example shows the more normal case with single character quotes. Microsoft offers other alternatives with “Outlook” as well. In particular, you can quote with a tab. After a couple of times, this gives results that look like this:

I don't think there's anything more to be said about such mutilation. I personally don't use Microsoft products, but I know a lot of clever people who do. None has been able to tell me how to configure “Outlook” to avoid these problems. If you know, please contact me and tell me how. I'll then include it in my next update.

Using MIME attachments

MIME allows you to attach all sorts of data to a mail message, including images and sound clips. It's a great advantage, but unfortunately many people refuse to use it, perhaps because the UNIX community haven't got their act together. Credit where credit's due, this is one area where Microsoft is ahead of the UNIX crowd.

Nevertheless, you can do a lot of things wrong with MIME attachments. Here are some of the more common ones:

• Use HTML attachments only for web pages. Many mailers allow you to send messages in text/html format by default. HTML is not an appropriate format for mail messages: it's intended for the Web. Of course, if you want to send somebody a web page, this is the way to do it.
• Don't use proprietary attachments. From time to time, I get attachments which assume that I have the same software as the sender. Typical ones are application/octet-stream with Microsoft proprietary formats (for example, one of the Microsoft Word formats), and application/mac-binhex40, which is used by Mac mailers for images. If the people you are sending to don't have this software, they can't use the attachment.
• Don't send multiple copies in different formats. Some mailers send both a text/plain and a text/html attachment. This makes no sense at all.
• Specify the correct attachment type. If you send a web page as an attachment, be sure that it is specified as text/html. The receiving mailer can use this to display the attachment correctly. If you specify it, say, as text/plain, the mailer displays it with all the formatting characters, which doesn't improve legibility. If you send a .gifimage as image/gif, the mailer can display the image directly. Otherwise the user needs to save the message and perform possibly complex conversions to see the image.

Correct time and time zone

When did you send your message? The answer is in the Date: header. Here are some typical examples:

Date: Wed, 11 Mar 98 11:29:05 +1030
Date: Tue, 14 Apr 1998 18:56:18 -0400

The exact layout of this header is defined in RFC 2822, but most of the fields are relatively easy to understand. The time is in the 24 hour clock. The field after the time specifies the Time Zone. Together with the time it defines the real time that you sent the message. This is more important than you may realize: if you're following a complicated exchange on a subject, it's very convenient to have the messages sorted in the order in which they were written, and most mail readers allow you to sort messages this way. If your time or your time zone is wrong, your messages will be sorted in the wrong place. This annoys many experienced mail users, and causes them to look down on you.

The first two digits of the offset specify the number of hours, the second two digits the number of minutes offset, so -0400 means “four hours behind UTC”. +1030 means “ten and a half hours ahead of UTC”. UTC is very close to, but not identical to, Greenwich Mean Time, or GMT, the time in England in the Winter. Just to make this more confusing, this is exactly the other way around from the convention that UNIX System V uses: System V considers EDT, the time zone on the East Coast of the USA in the summer, to be 4 hours ahead of UTC.

The older RFC 822 standard also allowed abbreviations like CST or EDT to represent US specific time zones only. RFC 2822 requires that the mail software must understand these format, but it shouldn't generate them.

Where do you set your time zone? That depends on your operating system.

• If you have a BSD UNIX based system, the system has files which define all the world time zones, including all transitions to daylight savings time. You just copy the appropriate time zone information file to the file /etc/localtime. The files are named after a prominent city in that time zone. For example, if you are in Lanzhou, you would look in the directory /usr/share/zoneinfo/Asia and find a file Shanghai. For some reason there's no file Beijing. Copy the file with:

  # cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
  

  You only need to do this once when you enter a new time zone.

• If you have a UNIX System V based system, you set the time zone, including all transitions to daylight savings time, as an environment variable in the file /etc/TIMEZONE. See the man page for the exact syntax. For example, if you live in Western Europe, where the time is one hour ahead of UTC in the Winter and two hours ahead in the Summer, you would set the time zone like this:

  	  TZ=MET-1MST-2
  	

  Note that the offsets are the other way round from in mail messages: they specify the number of hours to add to the local time to get UTC.

• To set the time zone with Microsoft products, I'm told that you proceed as follows:

  • Go to the control panel (Start Menu->Settings->Control Panel) and select the Date/Time applet.

  • Select the tab “Time Zones”, and you will see a map of the world under a drop-down listbox.

  • Select your timezone out of the listbox, hit OK, and voilà!

  Thanks to Christopher Wood for this bit of information.