For those of you who saw my similar document dated back in 1998, I guess I never realy explained it well to you. I started writing it when I was irritated and it was supposed to have a satirical tone which I realized, even then was lost--especially since it wasn't even consistent.
This version I hope will remain consistent, and will be a good example for talking to other people, not just me. I ask that, if you wish to talk to me, that you follow the suggestions listed here. Thank you.
Only quote the relevant portion of the document to which you are replying--the shorter the better, as long as it conveys enough information.
nb: It used to be that it was suggested that people "err on the side of caution" in that they quote more than they need to. So many people simply quote an entire message that many, including myself, have trouble offering this same wisdom. Consider the text you quote, is the context clear? If not, quote more--otherwise don't.
Don't.
Only do this if you're reporting SPAM or in extreme circumstances which require it.
The best I can do here is to point you to the Jargon file. For those who'd rather listen to me:
Use a common symbol. The link above suggests a few, though I suggest you stick with the traditional '>' (greater-than) symbol.
The placing of quoted text after a response is counter-intuitive. Logically, it makes sense to see the original statement/question, and then the response.
Unless there is a need for all recipients to see each other's addresses, use the BCC: field in your mail client. Some clients hide this field by default, but almost all of them have it.
This protects the privacy of your recipients, and might also reduce your own headaches. I have seen on multiple instances a recipient of an email sent using To's instead of Bcc's responding to everyone with a critical essay of a class/professor/TA.
Do not write your message in HTML (or any other markup language). Not all clients are capable of displaying HTML. Some people use such clients either out of preference, convenience, or necessity.
Also note that "in-line" HTML in a normal ASCII ("text/plain") email doesn't do anything special, eg, it will look just like <a href="somewhere">this</a>
Do not include attachments unless the recipient(s) is(are) expecting them. It is impolite to do otherwise. Many people are on slow connections, and many people pay for their connection either by the second or by the byte which means that attachments can be costly. DO NOT send an attachment when there is no need, for instance, when the contents of the attachment could be included in the message body.
DO NOT send me non-standard documents if you want me to read them. Usually, a safe bet is Portable Document Format (PDF), PostScript (PS), HTML, RTF, or ASCII for text documents. These formats are pretty much universal.
DO NOT send me documents for programs in Microsoft Office. I do not have he ability to view Microsoft Office formats on most of my computers, and they must be converted on whatever computers I do have the ability.
If you violate this rule, be prepared when you receive whatever format I decide to use.
DO NOT send "VCards" or "digital business cards" unless invited to do so. You are NOT invited to do so.
Signatures (text at the end of a message) should be no longer than four lines (specified in RFC 1855) and should be preceded by two dashes followed by a space and a newline:
"-- "
see this page for more information.
Just say NO.
It is generally a good idea to tell people with whom you normally communicate that you have changed your email address. Be sure to update any PGP keys you have to include this new address, and unsubscribe from mailing lists if you will no longer be using the old email address.
Don't use it. It looks stupid and immature.
Try to use correct punctuation and spacing, it really makes things easier. Don't flame someone if they are lazy though, and you're good friends ;)
There was a time when terminals only displayed capital letters--judging by Usenet posts, apparently AOL has been ported to these ancient systems.
Using all caps is considered shouting and should be avoided. If you happen to use one of the aforementioned computers, you might want to try putting a disclaimer in your signature--or buying a cheap 386-early pentium which you could very well get for free in many places.
Use spell check when it's available. When it isn't, proof read.
Can't you tell?
nb: this holds true for almost all online communication.
If you do not sign your email with your private key (and let me know where to get your public key) I will have no reason to doubt the validity of emails that someone claims are from you.
I almost always sign my emails (though not always with the key for the address I sent it from, often it is from my main address). If you receive an email claiming to be from me but is unsigned, or does not verify, do not trust it. My key can be found at http://matt.wronka.org/pgp/pgp.key.
If you do not use my public key I will assume unilateraly that all email I receive is public by default, and in general encrypted email I will assume by default is private/confidential (there are always exceptions). My mail is stored remotely which also means that all mail I have is subject to the whims of the system administration staff. See prior statement. If you want to make me happy, encrypt mail sent to me.
The purpose of this page is not to rant against Microsoft, or to belittle their prodcuts. However, as over half of the clients that send me email use some Microsoft email client, and over 25% of the emails I receive are from Outlook Express, I have decided to add this section because these clients refuse to play nicely, and wish to remain anti-social.
RFC 1855 defines various things that are considered "polite" on the Internet, known in the vernacular as "netiquette".
Outlook (or at least Outlook Express) does not seem to understand what a "new line" is. RFC 1855 specifies that text should be wrapped at 65 characters, though it is commonly accepted to use slightly more (72-76 is normal). Note that some people have mentioned that the popular email client, Pine, has trouble with line lengths greater than 74.
Maximum line length is specified in RFC 1855 because many people use terminals to check their email, via Telnet or SSH for instance, and are limited to an 80 character wide window. Using 76 characters permits nested quoting of messages without forcing text to the next line.
Outlook decides to append the entire message being replied to at the end of the outgoing message (Pine has a similar problem by default). This is not the best practice, as discussed above.
Outlook Express refuses to include a "In-Reply-To" header which indicates the message to which the current message is in reply to. This confuses several clients including, I am told, the popular mutt. Outlook proper is not broken in this respect.
The idea of a Blind Carbon Copies is that nobody else is supposed to be aware of recipients of BCCs. Certain versions of Microsoft's email clients put the entire list of BCC recipients inside a header that is sent to all receivers, rendering the concept useless.
This probably applies to corporate email systems in general, but most recently I received an email from a user of Outlook which tried to "Recall", i.e. call back a message he had already sent. I was quite confused when I saw a message stating that:
Name would like to recall the message Subject
(Name and Subject changed...). Please understand the abilities and limitations of your system, or you might end up in trouble.
Likewise, Out-of-Office replies/Auto-responses are often annoying and only add to the noise of unwanted traffic.
I have had at least two people, Microsoft Outlook Express users, complain that they were receiving blank emails and curious as to why my message was being sent in an attachment.
Now, this is not broken behavior--technically--from what I understand in the RFC, as it is up to the client as to whether it wants to be nice to its user or not. Though it should display the message inline, it is not required to. If you don't like your client being mean, switch. What (might) be broken is that the client sometimes ignores the "inline" directive, and continues to display things that should be inline as attachments--I cannot confirm this as I do not have Outlook/Outlook Express.
The specific RFC which specifies the format of the data I was sending in these instances is RFC 3156.
Apparently some email I thought was spam was actually just an Outlook virus sending itself to me. By the time I found out it was a virus, the user I received it from had already been killed in my filters (all messages ignored) and, frankly, I don't have a reason to remove the ban at this point.
On the other hand, for those who would take such actions yourselves, realize that many of these virii claim to be from members of a person's address book, and not the actual user themselves.
--