How to correctly quote e-mails and news posts

Programs that help - Configuring mail clients - Examples

Introduction

If you want to reply to a message on Usenet or by regular mail, you should learn about a number of rules to make the message as readable as possible.

As soon as you hit the reply button your mail application will most likely place "> " before the original message.
The purpose of these quotemarks is to let other readers know what has been said before.
Please stick to that standard even if you know how to change it. Lots of newsreaders have very nice features that only work if "> " is used.

Although this document is meant for Usenet its rules work as well for e-mail and mailing lists. The essence of a message is to have clear communication. A poorly constructed message is not only harder to read for the direct recipient but also for other people that would like to join the discussion. A well quoted message will show question and response in the natural reading direction, which will make the message much easier to read.

Let me show you step by step how quoting is done.

Remove the unnecessary parts of a message

It is recommended that you remove as much unnecessary information as possible from the original message. Like the 'hello' and 'goodbye' lines. They are a common form of politeness but do not add to the essence of the message.
Just like the signature. It's a nice decoration but not when you reply to someone, remove it.

Respond below the questions

It is recommended that you reply below the topics. Just as with questions from readers in a magazine, the journalists respond below the question to follow the natural reading order.

In this way people won't have to read down and later on go back to the top of the message. Remember that most people on Usenet read many messages every day. And the responses mostly appear much later, so they cannot always remember the exact message. It is also much easier for the next person who wants to respond to your answer.

Reply below each paragraph

Digital texts have another big advantage: You can split the text and respond below single lines and subjects. Examples of this can be seen below

Summaries

Sometimes people need many words to describe their question. In this case it is a good idea to make a summary. To let the readers know it is a summary construct them like this:

[snip: Lots of complains about service]

Examples

Now lets have a look at some examples.

All examples are based on this mail/news message
Hi,

I am looking for a decent hotel in Paris, not to expensive, preferably
near the center and easy reachable with public transport. I am also
looking for a car-rental company in Paris.

Cya, Erik


Lets say we respond to this message, there are lots of methods to use, lets try the one most people use.
Hi Erik,

Hotel 'xxx' is a good one, I have been there myself. Car rental-company 'yyy'
is around the corner, couldn't be more perfect.

Cya, Peter.


Erik wrote:
> Hi,
>
> I am looking for a decent hotel in Paris, not to expensive, preferably
near
> the center and easy reachable with public transport. I am also looking for
a
> car-rental company in Paris.
>
> Cya, Erik

While this may look like a good method, compare it to this

Erik wrote:
>
> I am looking for a decent hotel in Paris, not to expensive, preferably
> near the center and easy reachable with public transport.

Hotel 'xxx' is really good, I have been there myself.

> I am also looking for a car-rental company in Paris.

Rentalcompany 'yyy' is around the corner. That's also very practical.


Cya, Peter.

This way you know exactly what you are responding to and can also leave out any explaining text about references etc.

Lets assume that Erik wasn't looking for car-retals
Erik wrote:
>
> I am looking for a decent hotel in Paris, not to expensive, preferably
> near the center and easy reachable with public transport.

Hotel 'xxx' is really good, I have been there myself.


Cya, Peter.

This mail is excellent, it's precise and to the point.
It offers helpful information without being full of unnecessary text, thereby making it easy to read

Another example

This example shows how to reply to multi line quotes
Assume that you have to quote something which doesn't make sense without bringing in previous conversations.
Consider this example
Pete wrote:
> Erik wrote:
>
> > I am looking for a decent hotel in Paris, not to expensive, preferably
> > near the center and easy reachable with public transport.
>
> Hotel 'xxx' is really good, I have been there myself.

I agree, but they are also often occupied. I would also recommend hotel 'zzz'.

> > I am also looking for a car-rental company in Paris.
>
> Rentalcompany 'yyy' is around the corner. That's also very practical.

Traveling with a car in Paris is terrible if you don't know the road.
I would always travel with a cab.

//Rick

Notice how we included the "X wrote:" lines, this is of cause to distinguish the level of quotes and it's author

Quoting long messages

Often you'll want to quote large messages, it is therefore good practice to isolate the part of the messages you are in fact replying to.
Consider this long messages (You don't need to read it)
Hello All,

This note is intended to jump start a discussion of where
Mozilla Tech Evangelism stands today, and what we can do to
make it more effective in the future.

Mozilla Tech Evangelism is an effort designed to help increase
support for Mozilla and it's related browsers on the web and
inside of corporations.

The graphs at
< http://www.mozilla.org/projects/tech-evangelism/site/status-graphs.html>
show that while we have seen positive movement in terms of
resolved issues with sites we continue to have an ever
increasing number of Tech Evangelism bugs with a decreasing
effort being applied to contacting sites. Today there are over
2500 open Tech Evangelism bugs out of almost 38000 open bugs in all
of bugzilla.

Evangelism is a thankless task that has few rewards. I would
like to publicly thank everyone who has reported or triaged a
Tech Evangelism bug or contacted a site with an Evangelism
problem. None the less, we have seen a decrease in the numbers
of people who have been actively contacting sites and need to
recruit more people to help, make their efforts more efficient
and drive the number of open Evangelism issues down to Zarro.

What is the goal of the Mozilla Tech Evangelism effort? I
believe it is to make the use of Mozilla and other Gecko-based
browsers relatively easy for anyone who chooses to use it. In
order to accomplish this goal we must convince web site and
web application business owners, administrators, and
developers that it is in their best interest to support
Mozilla and Gecko. Simply evangelizing Standards is
insufficient if the site can not economically justify the
costs involved in updating their content.

What tactics can we use?

I. Increase market share (and pressure) of Mozilla and other
Gecko-based browsers.

Sites and developers will not expend the resources necessary
to support Mozilla/Gecko if they do not see the potential loss
of customers or income. We need to get Mozilla/Gecko's share
above the current 2-5% in order to get their attention.

A related need is to get web site analytic software to report
total Gecko percentages and not just specific branded versions
of Gecko. By splitting our reported percentages across the
multitude of browsers based upon Gecko we artificially
decrease our reported market share.

In the past we have relied upon the Tech Evangelism effort to
contact sites, to educate them concerning the error of their
ways and convince them to update their content to support us.
This reliance on a small group of people to accomplish this
has not been as effective as we might have wished.

A more effective course of action would be for large numbers
of customers to complain to sites/developers regarding their
products. We have continually seen responses from sites where
they say "We do not support Mozilla. It is not used by a
significant percentage of our users." They may say this to the
first, second or tenth person to complain however after the
hundredth or thousandth complaint they might change their
position. We need to leverage our users to contact sites and
complain while we dedicate our evangelism resources to more
productive efforts of helping organizations support
Mozilla/Gecko. How can we do this?

I believe that most of the people who are likely to adopt
Mozilla or other Gecko-based browsers without effort on our
part have done so. In order to increase the share of
Gecko-based browsers we must be proactive in reaching out to
new users.

New demographic targets for Mozilla/Gecko are high schools,
colleges/universities, corporations and governments
world-wide. Mozilla and Gecko have many advantages for these
potential users such as the ability to run on a variety of
operating systems, customization, localization and security.

By promoting alternative operating systems such as Linux we
also promote Mozilla and Gecko as the premier browser on those
platforms. How would we approach the effort of demonstrating
to schools, corporations and governments the
cost effectiveness of adopting free, open source operating
systems where we have dominance?

By providing the means for customizing Mozilla for
distribution to specific target audiences we provide a another
potential benefit of adopting Mozilla in an organization. The
Client Customization Kit (CCK) has much potential to help
distribute Mozilla to internal users of schools, corporations
and governments. The CCK needs to be improved and extended to
work in other operating systems than Windows. How can we get
the work on the CCK moving?

We need to ease the transition from content designed for
fourth generation browsers. While the focus for many of us is
the promotion of the use of standards, we can not expect
organizations to expend significant resources to adapt their
existing content in these difficult economic times.
Development of compatibility libraries which would allow sites
to continue to use existing web applications with little
modification would help to convince them that standardizing on
Mozilla/Gecko is economically viable. For example, can we
contribute to http://layeremu.mozdev.org/ ?

If an organization wishes to transition from using Netscape
Communicator 4.x to Mozilla/Gecko what guidance can we give
them? What are the issues these organizations face related to
Email/Profile migration issues, Plugin compatibility issues,
Security, etc. What organizations can we use as examples and
case studies for the migration from Netscape Communicator 4.x
(or even Internet Explorer) to Mozilla/Gecko?

Many organizations will not consider switching to Mozilla or
other Gecko based browsers without some level of technical
support available. What can we do about providing support? Are
there reliable, respected organizations which can take
advantage of this business opportunity?

II. Develop support oriented documentation

Once a site, developer or organization decides to support
Mozilla and Gecko we need to have the documentation resources
they need available for them to use. This includes guides to
developing modern standards based web applications, technical
notes on specific issues in various releases of Mozilla/Gecko,
guides to adopting Mozilla/Gecko in organizations etc.

I tried to get an effort started for using existing Tech
Evangelism bugs as sources for identifying issues which could
be documented as technical notes which would help web
developers. David Baron agreed that these technical notes
could be hosted inside of the docs/web-developer directory
inside of a technotes subdirectory. Although I began
identifying potential technotes and formats for them, I failed
to follow through with the idea and it has stagnated. One of
the common objections I received was the lack of a means of
organizing and searching technotes. I still believe the
development of a "knowledge base" for our web developers is a
good idea. How do we go about getting this effort off the
ground?

How can Tech Evangelism and the Documentation projects work
together to identify and produce the documentation that our
web developers need?

III. Tech Evangelism Bugs

Tech Evangelism Components are currently organized by
language/region and are geared towards triaging reported
issues, contacting sites and convincing them to update their
content. Many of the original owners and qa assignees for Tech
Evangelism bugs are no longer available to handle these bugs.
The current situation is summarized in
< http://www.mozilla.org/projects/tech-evangelism/components.html>.

Is this organization appropriate? Should we combine
components? Add new components? Who is available to take over
the components in need of owners and qa assignees?

IV. Cooperation, Communication and Management.

The Tech Evangelism effort does not exist in a vacuum. It
involves coordinating work between the Tech Evangelism
project, the Documentation project, the Mozilla University
project, developers and others. How can we work together to achieve
our goal of making Mozilla/Gecko the premier browser on the
web?

Who can take on the responsibilities for managing and leading
the Tech Evangelism project?

Conclusion

This note outlines some of the ideas I have concerning Tech
Evangelism. I hope that you will reply and help refine these
ideas, volunteer to help implement them and get involved in
the Tech Evangelism project. Please reply to this email in
netscape.public.mozilla.general and come to #evangelism on
irc.mozilla.org if you wish to discuss this in real time.

Thanks,
Bob

 

The correct way to respond to this message:

Eric wrote:
> To focus on one point only : I'm dutch and our Tech Evang bugs go into
> Europe-West...as will the German bugs, the french, some english,
> norwegian, swedish, english etc. Right now, all these
> countries/languages share ONE QA contact and default assignee. From a
> languague point of view it might be convenient to have language
> -specific contacts. Lately i've been query'ing ".nl" Tech Evang bugs
> and sorting those out. Perhaps more people can focus on Tech Evang
> bugs in their own country? If you need someone for ".nl" i herewith
> volunteer :)

Great! I have added you to my "volunteer list". When we get a new
Europe: Central owner you can coordinate with them. I agree that people
with specific language skills should work the bugs where they can make
contact in the site's native language.

> In addition, perhaps a repository of Tech Evang contact letters to
> web-site owners can be set-up containing translated letters.

We have a beginning of translated "form" letters however they will
probably need to be updated soon. See
http://www.mozilla.org/projects/tech-evangelism/site/letters/

> Furthermore, quite often when contacting a site you hit a brick wall,
> called "help desk" [there's an oxymoron if any ;)]
>
> These people are instructed to kindly inform you that the DECISION was
> made only to support IE and that if you want to use their site, you
> have to switch browser and if necessary even OS.
>
> Point being, contacting the web site via the web-site's contact
> information, typically is not very succesful. Either because you don't
> reach the actual site builders and most definitely won't reach the
> people responsible for the decision to "optimize the site for Internet
> Explorer".

Right. I have seen this many times before which is why I think
encouraging our users to complain to sites directly will help more than
just one or two people contacting them. They will ignore 1 or 2 messages
but not 1000.

> One thing i can never understand is that companies seemingly try very
> hard to keep their company accessible for all [making accomodations
> for all sorts of inabilities etc. etc.] but can make a CONSCIOUS
> DECISION to lose out on 2-5% of possible revenue by choosing to
> support only a particular browser.

Stupid people do stupid things. Stupid businesses go out of business.
Let's raise our share to a level that they can not ignore.

> So much more than contacting companies through their web sites, these
> organizational layers [builders, help desk] should be skipped and the
> people who make these decisions should be contacted and re-educated.

It is difficult to find such contacts but yes I agree we should contact
the highest level person in the organization who can change the decision
to not support us.

Perhaps a contact database although I would not want to be the source of
email addresses for spammers. We need to keep high level contacts
private and confidential so that companies will feel free to discuss
issues with us.

Regards, Michael

This example is clearly showing how correct quoting, is helping people read replies faster and with better understanding.
Imagine if there had been no quoting and Michael would have to write the same response. He would be required to include lots of explanations of what he was referring to and people would be forced to read the original message once again to know what Bob is in fact talking about.

Optimizing clients

Most mail clients are aware of the guidelines to correct quoting on usenet. Clients like Mozilla Mail, 40tude Dialog etc. always shows a reply dialog ready for correct quoting. Mail clients like Outlook Express does not offer many options to make quoting easier, nor does it support things like wrapping.

This choice of mail client is in the end, a crucial component in having good Netiquette

Wrapping

Most mail clients offer the feature of wrapping mails at a certain amount of characters.
The default wrap size is 72 chars. The method of wrapping is however very different from client to client.

This is an example of bad quoting by the mail client
I just came back from Paris and I wanted to tell everyone how
happy
I am with your excellent advice. Hotel 'xxx' was not occupied,
it
was very clean and the service was excellent. I also want to
tell
that I met a person in that hotel who went to the same congress
as
me and he offered me a ride all the time so I never had to
worry
about the transport.

Compared to quoting made by a good mail client (in this case Mozilla Mail)
I just came back from Paris and I wanted to tell everyone how happy I am
with your excellent advice. Hotel 'xxx' was not occupied, it was very
clean and the service was excellent.

I also want to tell that I met a person in that hotel who went to the
same congress as me and he offered me a ride all the time so I never had
to worry about the transport.

// Erik

Mozilla Mail/Thunderbird

By default Mozilla mail does not colorize quoting-levels, this can be changed by going to userContent.css and adding the following lines (This is my personal preference)
blockquote[type=cite] {
     color: navy !important;
}
blockquote[type=cite] blockquote {
     color: maroon !important;
}
blockquote[type=cite] blockquote blockquote {
     color: green !important;
}
blockquote[type=cite] blockquote blockquote blockquote {
     color: purple !important;
}
blockquote[type=cite] blockquote blockquote blockquote blockquote {
     color: teal !important;
}

These preferences will help you appreciate good quoting by your fellow usenet posters

 

Links to useful resources

Here are some links to useful resources on the net to either modify your client to handle quotes better or learn more about correct quoting

About this page

Partly written by Tom Sommer (mail) - (tsn.dk) - (dreamcoder.dk) - (blog)
Some copyrights are reserved (2003), please mail before copying the content of this page. Comments and ideas are highly appreciated.

Spread the word, teach people to quote correctly!