Common Mistakes in Email Messages and Usenet Postings and How to Avoid Them

This page discusses some of the most frequent and relatively obnoxious mistakes made when writing email messages and Usenet postings: This page mainly discusses these issues in the context of Usenet postings, but they also apply to emails.

I generally skip postings that exhibit these mistakes; I have killfiled (permanently) at least one guy because of these mistakes. I have unsubscribed groups where the fraction of broken postings was too high. There are too many interesting and properly formated postings around, I don't need to waste my time on broken stuff. I doubt I am alone in this view.

How to Quote

Let's say another poster (let's call him/her P) makes a posting 
statement A
statement B
statement C
statement D
and you want to comment on B and D; then the right way to quote is

Right: 

In <...>, P wrote:
>statement B

comment on B

>statement D

comment on D
Frequently sighted mistakes follow:

Wrong: 

comments on B and D

In <...>, P wrote:
>statement A
>statement B
>statement C
>statement D
Wrong: 
In <...>, P wrote:
>statement A
>statement B
>statement C
>statement D

comments on B and D
Wrong: 
comments on B and D
Why are these wrong? They make it harder for the reader to understand the context and understand what you are writing.

But my newsreader places the cursor at the top

That's so that you can go through the quoted material from top to bottom, delete what you are not commenting on, keep what you are commenting on, and insert your comments at the right places. If the newsreader placed the cursor at the bottom, this would encourage the second kind of mistake above.

Fine points

When you quote a message that quotes another message, make sure to preserve the attributions for all the included quotes. There is a slight problem if you start with a shallower quote: 

In <...>, P writes:
>In <...>, Q writes:
>something written by P

...

>>something written by Q
...
Some people complain that the attribution here is misleading. You may want to move the attribution for Q to the first quote of Q's text. OTOH, readers usually look at the top of the article to find out who wrote something. One way to reduce the chance of misleading readers is to put an ellipsis after the attribution. 
In <...>, P writes:
>In <...>, Q writes:
...
>something written by P

Line Breaks

You should break lines after about 70 characters; you should indicate paragraph breaks by an empty line. You may be breaking this rule without even noticing, so read on.

Common mistakes are: 

Lines that are simply too long (>80 characters), making them not only hard to quote, but also hard to read;

Lines that are just a little too long, making them simply too long when quoted;

And the comb design of alternating long and short lines; This
probably
arises from breaking lines twice, the second time automatically
with a
shorter desired line length than the first time.  This automatic
line
breaking is particularly bad when applied to quoted material.
You may not notice if you make such a mistake, because newsreaders that encourage these mistakes reportedly reformat paragraphs on display, thus hiding the damage they cause.

So you need to see your postings as many others see it. There are several ways to do this: use a newsreader that keeps the formatting; get the Message-Id of your posting (from the message header), then type telnet newsserver nntp, then article message-id; or look up your posting on Google and click on "Original Format". Note that you should do test postings in test groups, not in discussion groups.

Shouldn't all newsreaders reformat paragraphs when displaying, making this issue moot? No, there are many contents where the format must be preserved, e.g., postings containing tables, ASCII graphics, program source code, or poetry.

The reasons for the 70-characters rule are:

In general you should keep the original line breaks in quoted text. If the original text has broken line breaks, it may be ok to reformat them, but make sure you put the quote characters in the right place.

Content-Type

A posting in a discussion group or mail should be text/plain, not multipart/alternative, not text/html, or anything else (and certainly not application/binary with a filename ending in .doc). While Usenet seems to have repulsed this attack, it is still going on in Email.

Why is this a mistake? Many people use software and/or hardware that cannot display HTML and other junk formats in the way you envisioned. Now you may think that multipart/alternative with one alternative being text/plain may be the way to go. But if you can express the idea you want to convey in text/plain, why provide the alternative format? Also, with HTML, the problem is: Which HTML? If you want HTML, you certainly also want several of the latest plug-ins; but even if you have enough sense to stick with HTML 2.0, the next guy certainly will have other ideas and will produce messages that your browser won't display as intended.

Also, these other formats often take many times the space (and, consequently, bandwidth) of plain text, leading to increased costs for mail and news servers, and shorter expiration times for news servers (mail servers that expire the mail also may be affected).

Note that, as with the line lengths, this mistake may be hard to notice with the newsreader that you used to make it, and again, you should look at the original format of the message.

Related pages

Anton Ertl