Electronic mail: clients

Разбить на страницы

Показывать лекцию целиком

Electronic mail, usually called email, e-mail or simply mail, is a method of sending messages to other people on the Net. As with other network services, there are two parts to mail software:

The user interface to the mail system is the client, the Mail User Agent, or MUA. It interacts with the user and handles incoming and outgoing mail. People frequently use the word mailer when referring to MUAs. In this chapter we'll look at my favorite MUA, mutt, and we'll briefly touch on what others are available.

The server part is the Mail Transfer Agent, or MTA. As the name suggests, it is responsible for moving mail from one system to another. We'll look at MTAs in the next chapter, Chapter 27, Electronic mail: servers.

Mail formats

Email is defined by a number of Internet standards, the so-called . Here are the most important ones.

RFC 2821 is a recent update to the venerable RFC 821, which dates from the early 1980s. It defines the Simple Mail Transfer Protocol or SMTP. It specifies how to send mail round the network. For most people it's not very interesting, but it does impose some restrictions such as the basic line length limit. Apart from this problem (which Microsoft abuses), most mail systems adhere to SMTP.

Similarly, RFC 2822 replaces RFC 822. It defines the basic format of a mail message. It defines the headers (To:, Cc:, Subject: and so on) and a simple body made up of US-ASCII text, the message itself. This was fine for when it was written, but it can't handle the more complex formats used now days, such as images, binary files or embedded messages. It also can't handle non-US character sets, which causes problems in particular in countries like Russia, Israel and Japan.

RFC 2045, RFC 2046, RFC 2047, RFC 2048 and RFC 2049 together describe the Multipurpose Internet Mail Extensions, better known as MIME. They define how to encode non US-ASCII text and attachments so that they can be represented in ASCII and hence sent by RFC 2822, and also how to divide the single RFC 2822 body into multiple parts using ASCII separators.

A number of UNIX MUAs have inadequate MIME support. Find one which does the job properly. On the other hand, if your target audience typically does not use MIME-aware MUAs, a void sending MIME messages.

Mail user agents

A mail user agent is a program that interfaces between the user and the mail system. It allows the user to read, forward and reply to incoming mail, and to send his own mail. It usually has facilities for creating and maintaining folders, where you can keep received mail messages. For most UNIX MUAs, a folder is the same thing as a file, but some MUAs keep mail messages as individual files, and the folder corresponds to a directory.

mail

The oldest MUA you're likely to meet is mail. It's a very basic, character-oriented program, but nevertheless it has its advantages. You can use it in scripts to send mail. For example, if you have a job running and producing copious output, where you want to save the output, you might normally write something like:

$ longjob 2>1 > logfile

This command runs longjob. The sequence 2>1 redirects the error output to the standard output, and the > writes them to the file logfile. While this is a good way to solve the problem, you might find that you have a lot of such jobs, or that you tend to forget the log files and leave them cluttering up your disks. An alternative is to send mail to yourself. You can do this with the following command:

$ longjob 2>1 | mail me

In this case, me is your user ID. When the job finishes, you get a mail message with the output of the commands. cron (see page 151) uses this method to send you its output.

Other MUAs

mail has a number of limitations: it doesn't deal very well with long mail messages, it's difficult to keep an overview of large quantities of mail, like most people seem to accumulate, and it can't handle MIME.

Many more sophisticated MUAs have been written since mail. Some of the more popular ones, which are also available in the Ports Collection, are:

elm is one of the oldest full-screen MUAs. Its age is showing: it has a few annoying problems that make it less desirable now that there's a choice.

pine is not elm—that's what the acronym stands for. It's quite like elm, none the less.

mutt is also similar to elm and pine. It's my current favorite, and we'll look at it in the next section.

exmh is built on Rand's mh MUA. Some people like it, but it seems relatively easy to configure it to mutilate messages.

xfmail is an X-based MUA, which you might prefer to the text-based MUAs we're talking about here.

sylpheed is a more recent X-based MUA. You may prefer it to xfmail.

Files, folders or directories?

There are two schools of thought about how to store mail:

Traditional MUAs represent folders as files. They store all the messages in a folder in that single file. This is sometimes called the mbox method. mail, elm and pine do it this way.

Other MUAs, including exmh, xfmail and sylpheed, represent a folder as a directory. Each message in the folder is then a file by itself.

mutt can use either method, but the default is the mbox method.

Which method should you use? Both have their advocates. The directory and file approach is more robust (if you trash a file, you only lose one message, not all of them), and it enables you to have the same message in multiple folders. On the other hand, it also imposes a lot higher overhead. Current versions of ufs, at least on FreeBSD, have a default block size of 16 kB and a fragment size of 2 kB. That means that all files have a length that is a multiple of 2 kB, and so the average waste of space is 1 kB. In addition, each file uses an inode. If you have a lot of mail, this can add up to a lot of wasted space. For example, I currently have 508,649 saved mail messages, which take up a total of 2.1 GB, almost exactly 4 kB per message. If I stored them in a directory structure, I would lose about another 500 MB of space, or 25%. The file system on which the messages are stored is 9.5 GB in size and has 1.2 million inodes; nearly half of them would be used for the mail messages.

mutt

In this section, we'll take a detailed look at mutt. Start it by typing in its name. Like most UNIX MUAs, mutt runs on a character-oriented terminal, including of course an xterm. We'll take a look into my mailbox. By default, when starting it up you get a display like the one shown in Figure 26-1 .

(рис 26.1) mutt main menu

mutt sets reverse video by default. You can change the way it displays things, however. On page 481 we'll see how to change it to the style shown in one shown in Figure 26-2 .

(рис 26.2) mutt main menu

The display of Figure 26-2 shows a number of things:

The line at the top specifies the name of the file ("folder") that contains the mail messages (/var/mail/grog), the number of messages in the folder, and its size. It also states the manner in which the messages are sorted: first by threads, then by date. We'll look at threads further down.

The bottom line gives a brief summary of the most common commands. Each command is a single character. You don't need to press Enter.

The rest of the screen contains indexlines, information about the messages in the folder. The first column gives the message a number, then come some flags:

In the first column, we can see r next to some messages. This indicates that I have already replied to these messages.

In the same column, N signalizes a new message (an unread message that has arrived after the last invocation of mutt finished).

The symbol D means that the message has been marked for deletion. It won't be deleted until you leave mutt or update the display with the $ command, and until then you can undelete it with the u command

The symbol + means that the message is addressed to me, and only to me. We'll see below how mutt decides who I am.

The symbol T means that the message is addressed to me and other people.

The symbol C means that the message is addressed to other people, and that I have been copied.

The symbol F means that the message is from me.

The symbol * means that the message is tagged: certain operations work on all tagged messages. We'll look at that on page 481.

The next column is the date (in international notation in this example, but it can be changed).

The next column is the name of the sender, or, if I'm the sender, the name of the recipient.

The next column is the name of the recipient. This is often me, of course, but frequently enough it's the name of a mailing list. You'll notice that this is a column I have added; it's not in the default display.

The next column gives the size of the message. The format is variable: you can specify number of lines (as in the example), or the size in kilobytes.

The last column is usually the subject. For messages 56 to 61, it's a series of line drawings. This is threading, and it shows a relationship between a collection of messages on the same topic. Message 56 was the original message in the thread, message 57 is a reply to message 56, and so on. Messages 60 and 61 are both replies to message 59. mutt automatically collects all messages in a thread in one place.

You'll notice in the example that the lines are of different intensity. In the original, these are different colors, and they're a matter of personal choice; they highlight specific kinds of message. I use different colors to highlight messages on different topics. If you're interested in the exact colors, see http://ezine.daemonnews.org/200210/ports.html, which contains an early version of this text.

The index line for message 52 appears to be in reverse video. In fact, it's in white on a blue background, a color I don't use for anything else. This is the cursor, which you can position either with the cursor up and cursor down keys, or with the vi-like commands j (move down) or k (move up). In the default display, it is in normal video (i.e. not reversed, or doubly reversed). You can also move between pages with the left and right cursor commands. Many commands, such as r (reply) or Enter (read), operate on the message on which the cursor is currently positioned. For example, if you press Enter at this point, you'll see a display like that in Figure 26-3 .

(рис 26.3) mutt message display

Here, the display has changed to show the contents of the message. The top line now tells you the sender of the message, the subject, and how much of the message is displayed, in this case 50%. As before, the bottom line tells you the most common commands you might need in this context: they're not all the same as in the menu display.

The message itself is divided into three parts: the first 6 lines are a selection of the headers. The headers can be quite long. They include information on how the message got here, when it was sent, who sent it, who it was sent to, and much more. We'll look at them in more detail on page 484.

The headers are separated from the message body by an empty line. The first part, which mutt displays in bold, is quoted text: by putting a > character before each line, the sender has signalized that the text was written by another person, often the person to whom it is addressed: this message is a reply, and the text is what he is replying to. Normally there is an attribution above the text, but it's missing in this example. We'll see attributions below in the section on replying.

If the message is longer than one screen, press SPACE to page down and - (hyphen) to page up. In general, a 25 line display is inadequate for reading mail. On an X display, choose as high a window as you can.

Creating a new message

To create a new message, press m. mutt starts your favorite editor for you. How does it know which one? If you specify the name of the editor in your .muttrc file, or set your EDITOR environment variable to the name of your editor, it starts that editor; otherwise it starts vi. On page 481 we'll look at what to put in .muttrc.

In this case, we start emacsclient. emacsclient isn't really an editor at all: it simply finds an Emacs process and latches on to it. This is much faster than starting a new instance of Emacs: it's practically instantaneous, whereas even on fast modern machines, starting Emacs causes a brief delay. To exit the client, you use the key combination c-x c-#.

(рис 26.4) Creating a new message: initial state

Fill out the name of the intended recipient in the appropriate place, and enter the text of the message below the headers, leaving one line of space. Apart from this, most of the actions involved in sending a new mail message are the same as those in replying to an existing message, so we'll look at both activities together in the next section.

Replying to a message

To reply to a message, in this case the message shown in Figure 26-3 , simply press r. Before entering any text, the editor screen looks like Figure 26-5 .

(рис 26.5) Replying to a message: initial state

You'll notice that mutt automatically "quotes" the text. The original text started with:

>I think I now understand the problem here.  Try the following patch
>and tell me if it solves the problem:
>
>--- vinumio.c     2 May 2002 08:43:44 -0000   1.52.2.6
>+++ vinumio.c     19 Sep 2002 05:10:27 -0000
Tried patch. System no longer reads ad0h/ad2h, but after the second
'vinum start', the system shows 0 drives ('vinum ld' lists nothing.)

This message itself starts with quoted text, which indicates that it was written by somebody else. There should be a line at the top stating who wrote it, but it's missing here. The text from the submitter starts with Tried patch. When you reply, however, all this text is quoted again. The first line attributes the text below. You'll notice that this reply also includes a selection of headers for the outgoing message. This can be very convenient if you want to tailor your headers to the message you're sending, or just to add other recipients.

This is a reply to a technical question, so I change the for more details.

(рис 26.6) Replying to a message: after editing

In this example, I reply with the r (reply to sender) command. I could also do a group reply with the g key, which would include all the original recipients, so it wouldn't be necessary to add the mailing list again.

Next, I leave the editor with c-x c-# and return to the screen in Figure 26-7 . Here I have another opportunity to change some of the headers before sending the message. You'll note what seem to be a couple of additional headers in this display: PGP and Fcc:. In fact, they're not headers at all. PGP states what parts of the message, if any, should be encrypted with pgp or gpg. In this case, Clear (the default) means not to encrypt anything.

Fcc: is also not a header. It specifies the name of a folder in which to save the outgoing message. We'll look at folders in the next section.

After making any further changes to the headers, I send the message with the y command, after which I return to the previous display.

(рис 26.7) Replying to a message: ready to send

Using folders

mutt can handle multiple folders. It defaults to your incoming mail folder, sometimes called an inbox. On BSD, it is a single file in /var/mail with the same name as your user ID. We saw that above at the top of the index screen: mine is called /var/mail/grog.

mutt stores other folders as single files in the directory ~/Mail, in other words a subdirectory of your home directory. Many MUAs use this method, but not all of them: some use the directory ~/mail instead. By default, when you write a mail message, the outgoing message gets copied to a file in this directory. In the previous section, the Compose menu contained the pseudo-header Fcc: =jbozza. This refers to the file ~/Mail/jbozza: mutt uses the shorthand = to refer to the mail directory.

To keep incoming mail, you use the s (save) command, which sets a default folder name from the name of the sender, the same name as when saving sent messages. You can thus reply a message, saving a copy in the folder, then save the original message, without explicitly mentioning a folder name at all.

To read messages in a folder, you can tell mutt to read it directly on startup:

$ mutt -f =fred

Alternatively you can change folders with the c command.

Deleting messages

Once you've finished reading a message, you may want to delete it. You can do this by entering d. The D fag appears on the left of the line, but nothing much else happens. The message doesn't get deleted until you exit mutt, or until you enter $.

When you save a message to a folder, it is automatically deleted from the current folder. If you don't want to do that, or if you have accidentally deleted a message, you can undelete it by entering u.

Finished reading a thread? You can delete the entire thread by entering ^D (Control-D) .

Tagging messages

We've seen that you can delete an entire thread with a single keystroke. What about other operations on multiple messages? There are a couple of useful possibilities. You select the messages under the cursor by entering t. In the example above, messages 51 and 64 are tagged. You can reply to all tagged messages in one reply by pressing ;r. In this case, mutt ignores the message under the cursor and replies only to the tagged messages, reply to all people on the To: headers of each message. Similarly, you can do a group reply to all the tagged messages with ;g, and you can delete thcode all with ;d.

Configuring mutt

We've already see that there are a lot of things that you can change about mutt's behavior. They are described in a file ~/.muttrc (the file .muttrc in your home directory). Here are a few of the more interesting entries in my .muttrc:

source /usr/local/etc/Muttrc

The file /usr/local/etc/Muttrc contains the default definitions for running mutt. Put this at the top of your .muttrc file so that the following definitions can override any previous definitions. This file also contains a large number of comments about how to set each variable, and what it does: it's over 3,000 lines long.

source ~/.mail_aliases

~/.mail_aliases is the name of an alias file, a file with abbreviations for frequently used mail addresses. We'll look at them on page 484.

set alternates="greg.lehey®auug.org.au|groggy®|grog@|auugexec@|core@free"

This string is a regular expression that mutt uses to determine whether mail is addressed to me. If it matches, it sets one of the fags discussed above: + if the message is sent only to me, T if I am mentioned on the To: header, and C if I am mentioned on the Cc: header.

my_hdr Organization:  LEMIS, PO Box 460, Echunga SA 5153, Australia
my_hdr Phone: +61-8-8388-8286

These lines and more become headers in messages I send; you can see them in the examples above.

set editor=emacsclient

This line overrides the default editor in EDITOR. We've already seen the use of emacsclient.

set pager_index_lines=10

This tells mutt to keep ten lines of the index when displaying a message. Figure 26-8 shows what the display looks like when this is set. Clearly this isn't much use with a 25 line display. If, on the other hand, you have a larger X display, it can be very convenient to have a selection of the index at the top of the screen.

set hdr_format="%4C %Z %{%d-%m-%Y} %-20.20L %-15.15t (%4l) %s"  # format of the index
set status_on_top  #put the status bar at the top
set sort=threads
set date_format="%A, %e %B %Y at %k:%M:%S %Z"

These variables tell mutt how to display the message index. They account for the difference in layout (but not color) between the default screen and the custom screen. hdr_format is a printf-like format string that describes the layout, status_on_top reverses the information lines at the top and bottom of the display, sort=threads sets a threaded display by default (you can change it by pressing o), and date_format is set to international conventions.

(рис 26.8) Reading a message with pager index lines set

set edit_hdrs  #let me edit the message header when composing
set fast_reply  #skip initial prompts when replying
set attribution="On %d, %n wrote:"
set charset="iso-8859-15"  #character set for your terminal
set sendmail_wait=-1

These variables specify how to write and reply to mail messages:

edit_hdrs tells mutt to include the headers in the message you write, as shown in the preceding examples.

fast_reply tells mutt not to prompt for a number of the headers. This is faster, and it's not necessary when you have the headers in the message you're writing.

attribution describes the format of the attribution at the beginning of a reply, the text On Friday, 20 Septcodeber 2002 at 8:13:44 -0500, Jaime Bozza wrote: in the example above.

charset specifies the character set to use for the message. This should correspond to the character set of the fonts on your display, otherwise things may look strange. ISO 8859-15 is the new Western European character set that includes the character for the Euro. You'll still see many message with the older Western European character set, ISO 8859-1, which is otherwise very similar.

Finally, sendmail_wait tells mutt whether it should wait for the mail to be sent before continuing. This can take some time if your MTA has to perform numerous DNS lookups before it can send the message. Setting this variable to -1 tells mutt not to wait.

ignore *
unignore   From: Date: To: Cc: Subject: X-Mailer: Resent-From:
hdr_order  Date: From: To: Cc: Subject: X-Mailer: Resent-From:

These specifications tell mutt to ignore all headers except for specific ones, and to sort them in the order specified, no matter what order they occur in the message.

Colors in mutt

Finally, .muttrc contains definitions to describe the color of the display. Many of these are personal preferences, so I'll just show a couple. Each definition specifies the foreground color, then the background color:

color normal black white

This is the basic default color, overriding the reverse video shown above.

color hdrdefault brightblack white
color quoted brightblack white

This tells mutt to highlight headers and quoted text in bold.

color status black yellow

This tells mutt to display the status bars in black on a yellow background.

color index blue white FreeBSD

This tells mutt to display any messages with the text FreeBSD in blue on white, like messages 48 and 49 in the example above.

There are many more variables you can set to customize your mutt display. Read /usr/local/etc/Muttrc for more details.

Mail aliases

You'll find that some people have strange mail IDs: they are unusual, confusing, or just plain difficult to type. Most MUAs give you the option of setting up aliases, short names for people you often contact. In mutt, you can put the aliases in the ~/.muttrc file, or you can put them in a separate file and tell mutt when to find them in the ~/.muttrc file, as illustrated above. The aliases file contains entries like this:

alias questions FreeBSD-questions@FreeBSD.org (FreeBSD Questions)
alias stable FreeBSD Stable Users <FreeBSD-stable@FreeBSD.org>

The format is straightforward:

First comes the keyword alias. Aliases can be placed in ~/.muttrc,so the word alias is used to distinguish them from other commands.

Next is the alias name (questions and stable in this example).

Next comes the mail ID in one of two forms: either the name followed by the mail ID in angle brackets (<>), or the mail ID followed by the name in parentheses (()).

In mutt, you can add aliases to this file automatically with the a command, which offers default values relating to the current message.

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.

Страницы:

Записаться