Electronic mail: clients

Mail headers

In the message display above we saw only a selection of the mail headers that a message might contain. Sometimes it's interesting to look at them in more detail, especially if you're having mail problems. To look at the complete headers, press the h key. Figure 26-9 shows the complete headers of our message 52.

увеличить изображение
Рис. 26.9. Complete headers

• The first line shows the name of the sender and the date it arrived at this machine. The date is in local time. In this case, the name of the sender is a mailing list, not the original sender.
• The next line (Return-Path:) is used to indicate the address to which error messages should be sent if something goes wrong with delivery. The FreeBSD mailing lists specify the list owner to avoid spamming senders with multiple error messages, which can easily happen when you send messages to a large mailing list.
• The Delivered-To: header specifies the user to whom the message was delivered.
• The next group of headers shows how the message got from the source to the destination, in reverse chronological order. There are a total of 11 Received: headers, making up more than half the total number of lines. This is because it went via a mailing list. Normal mail messages have only one or two Received: headers.

  The first Received: header is split over three lines. It shows the most recent step of the message's journey to its destination. It shows that it was received from mx2.freebsd.org by wantadilla.lemis.com, and that wantadilla.lemis.com was running postfix. It also shows the time the message arrived at wantadilla, Sat, 21 Sep 2002 at 10:23:04. The time zone is 9,5 hours ahead of UTC, and the message ID is 195CC81743.
• The following Received: headers trace back to the origin of the message, via hub.freebsd.org, where it went through three transformations. Before that, it went through mail1.thinkburst.com, mailgate.thinkburstmedia.com, sigma.geocomm.com and dhcp00.geocomm.com. By pure coincidence, every one of these systems was running postfix. Each header contains a message ID, the name of the server and its IP address. In one case, though, the name looks different:

  Received: from mailgate.thirikburstmedia.com (gateway.thirikburstmedia.com [204.214.64.100])
  

  The first name is the name that the server claims to be, and the second is the name returned by a reverse DNS lookup of the server IP address.
• The next five headers are the "normal" headers: sender, recipient, copied recipients and date. This example shows why they are in color; they can appear in a large number of different places.
• We've just seen eleven different message IDs. So why the header Message-Id:? That's exactly the reason: the other eleven IDs are local to the system they pass through. The line beginning with Message-Id: gives a definitive message ID that can be used for references.
• The next three headers relate to MIME and describe the version and the manner in which the message has been encoded (7 bit plain ASCII text).
• The next four headers start with X-. They are official custom headers, and we'll see more below. The RFCs deliberately don't define their meaning. Clearly these ones are used by Microsoft software to communicate additional information, including the fact that the MUA that created this mail message was Microsoft Outlook.
• The In-Reply-To: header shows the ID of the message to which this is a reply. mutt uses this field to thread the messages in the index.
• The next two fields, Importance: is also not defined by the standards. It may be a Microsoft ''extension''. This is not an abuse of the standards: the RFCs allow use of any undefined header, and the X- convention is only provided to make certain that a specific set of headers remains undefined.
• Next comes the Sender: header is the address of the real sender. Although this message is From: Jaime Bozza, it was resent from the FreeBSD-stable mailing list. This header documents the fact.
• The following List- headers are also not defined by the standards. They're used as comments by the mailing list software.
• X-Loop is used by the mailing list software to avoid mailing loops. The mailing list software recognizes an X-Loop header with its own name to mean that it has some how sent a message to itself.
• The Precedence: header is used internally by sendmail to determine the order in which messages should be sent. bulk is a low priority.
• The X-Spam-Status: header is added by spamassassin, which is used to detect spam. This message has been given a clean bill of health.
• The final headers are added by mutt when it updates the mail folder, for example when it exits. Other MUAs add similar headers.

  The Status: fag is used by the MUA to set fags in the display. The letters each have their own meaning: R means that the message has been read, and O means that it is old (in other words, it was already in the mail folder when the MUA last exited).
• The Content-Length: header specifies the approximate length of the message (without the headers) in bytes. It is used by some MUAs to speed things up.
• The Lines: header states the length of the message in lines.

How to send and reply to mail

In the impersonal world of the Internet, your mail messages are the most tangible thing about you. Send out a well thought out, clear and legible message, and you leave a good impression. Send out a badly formulated, badly formatted and badly spelt message, and you leave a bad impression.

So what's good and what's bad? That's a matter of opinion (and self-expression), of course. We've seen some of the following things already:

• Unless there's a very good reason, avoid proprietary formats. Most MUAs can handle them nowadays, but some can't. For example, some people set up Microsoft MUAs to use HTML as the standard format. Many other MUAs have difficulty with HTML, though mutt can display it with the help of a web browser. Microsoft MUAs are also often configured to send out mail in Microsoft Word format, which is illegible to just about anybody without a Microsoft system.
• When sending "conventional" mail, ensure that you adhere to the standards. Again, Microsoft mailers are often bad in this respect: without telling you, they may either transform paragraphs into one long line, or they break lines into two, one long and one short. The resulting appearance of the message looks like (taking this paragraph as an example):

  When sending "conventional" mail, ensure that you adhere to the standards.
  Again, Microsoft mailers are often bad in this respect: without telling you, 
  they may either transform paragraphs into one long line, or they break li nes into two, 
  one long and one short. The resulting appearance of the messa ge looks like 
  (taking this paragraph as an example):
  

  When sending "conventional" mail, ensure that you adhere to the standards.
  Again, Microsoft mailers are often bad in this respect: without telling you,
  they may either transform paragraphs into one long line, or they break lines
  into two, one long and one short.   The resulting appearance of the message looks
  like (taking this paragraph as an example):
  

  This can happen to you without you knowing. If you get messages from other people that appear to be garbled, your MUA may be reformatting them on arrival, in which case it is possibly reformatting them before transmission.
• When replying, ensure that you use a quote convention as shown above. Place your reply text directly below the part of the text to which you are replying.
• Messages tend to grow as more and more replies get added. If large parts of the original text are irrelevant, remove them from the reply.
• Leave an empty line between the original text and your reply, and leave a space after the > quote character. Both make the message more legible. For example, compare these two fragments:

  >rdkeys@csemail.cropsci.ncsu.edu writes:
  >>Not to pick at nits.... but, I am still confused as to what EXACTLY 
  >>is the "stable" FreeBSD.  Please enlighten me, and tell me the 
  >>reasoning behind it.
  >OK, I'll take a shot at this. To really understand what 2.2-STABLE is, 
  >you have to have some idea of how the FreeBSD team uses 'branches'. In 
  >particular, we are talking about branches as implemented by the CVS
  

  >rdkeys@csemail.cropsci.ncsu.edu writes:
  >> Not to pick at nits.... but, I am still confused as to what EXACTLY 
  >> is the "stable" FreeBSD.    Please enlighten me, and tell me the
   >> reasoning behind it.
  >
  >OK, I'll take a shot at this. To really understand what 2.2-STABLE is, 
  >you have to have some idea of how the FreeBSD team uses 'branches'. In 
  >particular, we are talking about branches as implemented by the CVS
  
• What about salutations? You'll see a lot of messages out there that don't start with "Dear Fred", and either aren't even signed or just have the name of the author. This looks rather rude at first, but it has become pretty much a standard on the Net. There's a chance that this will change in the course of time, but at the moment it's the way things are, and you shouldn't as some any implicit rudeness on the part of people who write in this manner.
• At the other end of the scale, some people add a standard signature block to each message. You can do this automatically by storing the text in a file called ~/.signature. If you do this, consider that it appears in every message you write, and that it can get on people's nerves if it's too long or too scurrile.
• Make sure that your user ID states who you are. It doesn't make a very good impression to see mail from foobar@greatguru.net (The greatest guru on Earth), especially if he happens to make an incorrect statement. There are better ways to express your individuality.

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 communities 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, most of which are default for Microsoft MUAs.

• Use HTML attachments only for web pages. Many MUAs 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 that 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 MUAs for images. If the recipients don't have this software, they can't use the attachment.
• Don't send multiple copies in different formats. Some MUAs send both a text/plain and a text/html attachment bundled up in a multipart/alternative attachment. This wastes space and can cause a lot of confusion.
• 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 MUA can use this to display the attachment correctly. If you specify it, say, as text/plain, the MUA displays it with all the formatting characters, which doesn't improve legibility. If you send a .gif image as image/gif, the MUA can display the image directly. Other wise the user needs to save the message and perform possibly complex conversions to see the image.

Microsoft-based MUAs frequently make this mistake. You may receive attachments of the type application/octet-stream, which really describes the encoding, not the content, but the name might end in .doc, .gif or .jpg. Many MUAs assume that these attachments are Microsoft Word documents or GIF and JPEG images respectively. This is contrary to the standards and could be used to compromise the security of your system.