Good Email Use ou Les Bons Usages Du Courriel

stanislav shalunov: Good Email Use

The standardization of email address space and ability to reach
majority of people was great. I wonder if anything else good has
happened to email since 1971. Email becomes harder and harder to use
with the spread of broken mail user agents and bad habits.

Sending messages in such a way that everybody can easily read,
index, browse, and store them is a good goal to pursue. A checklist:

Reply feature

• (At least) two ways to reply: followup (reply-all) and individual reply
  (basic functionality, finally not a problem).
  
  
• Mail user agent pays no attention to Sender: and
  MAIL From: (envelope sender) when composing replies
  (these are machine-generated addresses; they are used for bounces and
  other delivery notices, not for replies).
  
  
• In-Reply-To: header is created and contains
  Message-ID: of the original (this helps to catch direct
  replies to your messages).
  
  
• References: is preserved (or created), and
  
  Message-ID: of the original is appended (this is required
  for threading to work and is especially important for mailing lists).
  
  
• Reply-To:, Mail-Reply-To:, and
  Mail-Followup-To: are to be honored.
  

Quoting

• It's not always necessary at all!
  
  
• Quoted text appears with a greater than sign in the beginning of
  each line.
  
  
  
• Quoting complete messages is usually unnecessary. If your
  recipient wants to read the message to which you are replying they can
  do just that. (Exception: adding recipients so that your
  reply will go to people who have not seen the original.) A few
  sentences to which you are writing a direct reply or simply a sentence
  or two to provide context is enough.
  
  
• If several sentences need to be quoted to make clear to what
  you're replying, but they are separated with text you don't wish to
  include, a common practice is to elide them by replacing them with an
  ellipsis in brackets.
  
  
• Answers to questions or concerns go after the (quoted) questions
  or concerns.
  
  
• Quoting signatures (unless replying to them) is not very
  considerate for the readers.
  
  

Format

• ASCII. Plain text.
  
  
• HTML isn't plain text.
  
  
• Sending both plain text and HTML is probably one of the
  most annoying abilities mail user agents give one. Resist the urge to
  use it.
  
  

Paragraph formatting

• Text is formatted to fit 80-column screen (for robustness, leave
  space for one or two levels of quoting without need of paragraph
  reformatting, too).
  
  
• This includes quotes (the fact that the original wasn't formatted
  properly is not an excuse).
  
  
• text/flowed is a typo. It should actually read
  text/flawed (MIME-hater insider joke;
  text/flowed is a way to indicate that text lacks line
  breaks).
  
  
• Alternating full lines and lines of one or two words are not fun
  to read, especially if the full lines are quoted and the short
  aren't.
  

Attachments

• Avoid, unless really necessary.
  
  
• If you can put stuff up on the web, do so and send just a URL.
  
  
• If it's confidential, include a dozen random characters in the
  file name. This is arguably better protection than sending it as an
  attachment anyway.
  
  
• If it can be said in plain text, please do so. This includes
  replacing 2MB Excel spreadsheet with a dozen lines each containing
  five fields by the corresponding dozen lines of text (few hundred
  bytes, and immediately visible to the recipient).
  
  
• If you absolutely must use it, don't use proprietary formats. No
  PPT, no Excel, no Word, please. Please. Use text (or PDF, if you
  must), text (or CSV, if you must), text (or HTML, if you must)
  instead, respectively.
  
  

Subject:

• When originating a message, use a descriptive subject line
  (examples of bad ones: "a question", "software", none, etc.).
  
  
• When changing subject, change the subject line.
  
  
• Don't pollute it: Re: FW: [Fwd: Re: Re[2]: AW: Hello
(fwd)] is a PITA to read. Don't add any of that funky stuff.
  Add a Re: in front when replying, if it's not already
  there.
  
  
  

Signature

• Append it separated by a line containing two dashes and a space.
  (A standard signature separator lets people hide all signatures if
  they don't wish to see them, and only look at signatures of people
  they don't know.)
  
  
• Make it fit into four lines (or less) shorter than 80 characters.
  
  
• VCARDs aren't signatures. They are attachments. Don't send them,
  for the sake of humanity.
  
  

How do I do all this?!

Actually, it's fairly simple. Your mail user agent is responsible
for most of the items on the checklist.

Mail user agents to avoid:

• Lotus Notes. (Absolute disaster, violates virtually every rule in
  the most bizarre fashion imaginable; actually, no: ways impossible to
  imagine are implemented, too.)
  
  
• Microsoft Outlook. (Surprisingly enough, it actually can
  be configured to do things right. But why not use a program that
  comes with sensible defaults?)
  
  
• Eudora. (Breaks threading; and it's much worse than just omitting
  References:--somehow it manages to insert messages in
  random places into the thread, puts your
  In-Reply-To: into its References:,
  etc.)
  
  
  
• cc:Mail. (I guess it was so broken, that even other
  cc:Mail users couldn't read messages sent by it without trouble. It
  seems I don't get any cc:Mail mutants in my mailbox anymore.)
  

An example of what happens when people use broken mail clients:
RJ Atkinson, while complaining about an ITU document sent as a Word
attachment, writes in message
<5.1.0.14.2.20011207125204.00a03dc0@10.30.15.3>
(sent CC public mailing list ietf@ietf.org), excerpt:

--=====================_9343662==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
At 11:18 07/12/01, Ostap Monkewich wrote:<br><br>

<blockquote type=cite class=cite cite><font face="Arial, Helvetica" size=2>&lt;&lt;SDL
Demo Announcement.doc&gt;&gt; <br>
</font><br>
<font face="Arial, Helvetica" size=2 color="#0000FF">At IETF-52 in Salt
Lake City, </font></blockquote><br>

Sending email in fancy text, rather than plain-text,<br>
and sending proprietary format binary attachments<br>
(in this case MS-Word)...sigh.<br><br>
Those are two clear indicators that the sender of the email <br>
doesn't understand the IETF culture or have respect<br>
for those of us who live behind low-bandwidth links<br>

and don't happen to use the Microsoft applications...<br><br>
Email in text/plain format only would have gotten a lot<br>
better reception in a lot of folks' mailboxes.<br><br>
Ran<br><br>
</html>

--=====================_9343662==_.ALT--

The irony of the last sentence should be obvious. The MUA in question
identifies itself as QUALCOMM Windows Eudora Version 5.1. The user
insisted that his message contained no HTML (and indeed his other
messages don't containt HTML), so Eudora hides what it sends well from
the sender; I guess it sends HTML messages when a reply to an HTML
message is composed. (The message in question also had broken
In-Reply-To, missing References, and not
guaranteed to be unique Message-Id. Need I say more?)

Sensible mail user agents exist in numbers. On Windows or
Macintosh, your best bet is likely to be Netscape (configure it to
send plain text only, wrap at 72th column, always 8-bit, no vcard).
On Unix, there are a lot of good choices, Mutt is probably the easiest
to handle. (I use Gnus on Emacs.)

And then, don't use attachments and don't quote it
all. That's about it.

On peut essayer de lire la traduction presque illisible par Google ici : http://www.google.com/translate?u=http%3A%2F%2Fshlang.com%2Fgood-email-use.html&langpair=en%7Cfr&hl=en&ie=UTF8
Si vous voulez bien traduire ce texte pour moi... poster la traduction en commentaire et je la publierai ensuite...