You have probably been referred to this page because you've
sent an email to myself or a mailing list I run, probably
containing a question, which was difficult to deal with.
I'm perfectly happy to answer your question and help you out,
but in return I'd like you to make life easy for me by sending
normal email which is nice and easy for me to deal with.
I'm sorry if that sounds rude or lazy, but I seem to spend most
of my life in front of an email client, and although I'm happy to
help I'd really prefer not to have it made more difficult than is
To this end, I've reproduced on this page a few items of
"Netiquette" which describe normal behaviour
among Internet users, but with which some newcomers sometimes have
difficulty. It starts with general email-related advice, and moves
on to things which are more specific to Linux kernel problems.
If you have accidentally transgressed one or more of these
guidelines and been referred to this page, your mail may have been
rejected from the mailing list or have ended up in the spam
folder, or I may have replied simply with the URL to this page.
In that case, please fix whatever was wrong and try again.
- Use the archives
please look at the mailing list archives for an answer. If
you've downloaded the code and it doesn't compile out of the
box, it's a fairly safe bet that you're not the first. The
solution will be in the mailing list archives. If you're doing
_anything_ that you expect others have tried, and having trouble
with it, try the archives before asking the same questions
- Don't send private mail unless
Don't send mail to me privately if it's about
something which doesn't need to remain private, and if there's
any chance that someone else might learn from the
answer. Obviously I don't answer publicly to private mail, so
nobody gets to benefit from the answer but you. I don't mind
answering questions, but if everyone just mails me the
same questions privately and I can't just give one answer on the
list which enlightens everyone, then it's a complete waste of my
- Ensure your references are
The email standard (RFC 2822) says
that all replies should have References: and
In-Reply-To: headers which contain the unique message
identification of the message to which the reply is made. There
are two ways in which this is generally abused:
- Some broken mail programs will
send a reply with no References: or
In-Reply-To: header, causing threading information
to be lost.
- Sometimes people have been
observed to select an existing message on the mailing list,
reply to it but modify the subject in an attempt to start an
entirely new thread. If their email client is behaving
correctly, the References: and
In-Reply-To: headers mean that their message is
_not_ a new thread as they intended, but appears as a
continuation of the original thread.
- Quote selectively
replying to a message, do not quote any more of it than is
completely necessary for understanding the context of your
reply. Make sure you delete any parts which aren't important to
- Quote clearly
quoting a previous message or messages, make sure it is clear
which part was said by whom. The most common method of quoting
is to add a single '>' character and a space at the
left-hand-side of the quoted text, which makes it clear what is
quoted and what is your own original text. Since most people
follow this convention, it follows that '> > ' is a quotation
from part of a message which itself quoted from a previous
message. Ensure that attributions are correct for all such
levels of quotation.
- Place your reply below the
If you do need to quote any of the original message in your reply,
your own followup should go below the text which you quoted.
Do not under any circumstances quote the entire original message
and place your entire reply at the top. You will simply be ignored.
- Do not send HTML encoded
HTML messages are larger and slower to
download, generally slower to render on-screen, and are
displayed differently to normal messages, which makes them
immediately harder to read. Send plain text only -- the only
people who need to use HTML for email are those sending spam,
which is why many people send HTML mail straight to the spam
- Make your mail readable by formatting it correctly
Email should have no more than 80 columns per line of text. Many
email clients, when presented with long lines, will assume that the
sender intended there to be no line break there, and will
display the email with a horizontal scrollbar required to see the
right-hand side of the lines. When coupled with broken email
clients which send each paragraph in a single line, this makes
mail very difficult to read.
- Include all relevant
If you want someone to help you, don't make
them guess. Some of them may be remarkably good at
guessing, but that doesn't mean you should make them do it. So
if you're reporting a problem, include all the relevant
information about what you did and what went wrong. As long as
it remains readable, it's better to include slightly too much
information than too little.
- Decode all kernel
As a specific example of the above, if you are
reporting a kernel 'oops', make sure it's completely decoded so
that it refers to particular functions and is usable, rather
than just having a bunch of random numbers which are only
relevant to your particular kernel build.
- If you send patches, test them
Many people seem to send patches to a mailing
list with broken mail programs which eat whitespace or introduce
line breaks where they shouldn't be. If you aren't 100% sure
that your mailer doesn't do such things, test it for
yourself first -- send the patch to yourself, then
save the mail you receive and try to apply the patch. Don't just
send it to busy people and hope.
Last modified: Sun Feb 9 11:16:11 GMT 2003