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:
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:
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.
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.
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.
Nevertheless, you can do a lot of things wrong with MIME attachments. Here are some of the more common ones:
Date: Wed, 11 Mar 98 11:29:05 CST Date: Tue, 14 Apr 1998 18:56:18 -0400 (EDT)
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. But what about the field or fields after the time? They specify the Time Zone. Together they define the real time that you sent the message. These are 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.
So this can't be too difficult, right? Well, no, but there are some hidden traps that you may not expect. Setting the time is easy: all mailers use the system time, so all you need to do is to set it correctly.
The time zone is more complicated. First, Microsoft systems don't use the concept of a time zone internally, so you could set it up wrong and not notice any problems. Secondly, the format of the time zone is somewhat bizarre: in this point, RFC 2822 shows its age.
You can specify the time zone as a character abbreviation (CST in the first example), or as a numeric offset from UTC, Universal Coordinated Time. UTC is very close to, but not identical to, Greenwich Mean Time, or GMT, the time in England in the Winter.
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''. 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 to be 4 hours ahead of UTC.
But what does CST mean? It stands for Central Standard Time, a time zone in the United States of America which is 6 hours behind UTC. It also stands for China Standard Time, which is 8 hours ahead of UTC. It also stands (again!) for Central Standard Time in Australia, which is 9½ hours ahead of UTC in the Winter, and 10½ hours ahead in the Summer.
So which does it really mean? The correct answer is: the US time zone. RFC 2822 allows only US time zone abbreviations. If you live in Adelaide or Alice Springs, Australia, or Lanzhou, China, your time zone is CST, but you must specify your time zone as +0930 (+1030 in the summer in Adelaide only) or +0800 respectively. You may put the time zone abbreviation in parentheses after the offset, like in the second example, but it is treated as a comment.
Where do you set your time zone? That depends on your operating system.
# cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtimeYou only need to do this once when you enter a new time zone.
TZ=MET-1MST-2Note 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.
Thanks to Christopher Wood for this bit of information.