E-mail Tips and Tricks

Electronic mail is a wonderful invention. It allows people to stay in touch and exchange thoughts virtually instantaneously, regardless of the physical distances involved. As with any great invention, though, it takes a bit of getting used to in order to get the most out of it. This page intends to sum up some of the tips, tricks and good ideas I have seen during my years as a netizen (Internet citizen). Everything is listed without any particular order, and this page by no means claims to be complete. If you have a suggestion, feel free to get in touch with me.

Many of these tips and tricks are equally applicable in Usenet news as well as on web-based discussion forums.

Table of Contents

• Use descriptive Subject lines
• Decide on a language, and do not invent your own
• Trim what you send
• Avoid HTML mail like the plague
• Avoid using UPPER CASE LETTERS
• Learn the convention
• Avoid proprietary file formats for attachments
• Start a new thread when starting a new discussion
• Keep your signature short
• Send your e-mail to the proper person
• Stop forwarding virus warnings!

For those who are lazy, the short summaries may be enough. For more in-depth discussions about the rationale behind each of these tips, see below.

Other recommended reading

There are plenty of web pages and more or less authoritive documents available on the Internet that discuss how to use e-mail in an appropriate way. This list is not and can never be exhaustive, but is intended to point interested readers to documents I have found particularily interesting or well written.

• HTML Email: Turn It Off! talks about the issue of HTML e-mail as well as addressing the issues of quoting, trimming and some other matters. A local copy is available. Also references RFC 1855.

Use descriptive Subject lines

A lot of people seem to forget what the word subject means. In this context, it means summary – that is, a few words that summarize the longer textual content of the e-mail. This is also clearly laid out in RFC document number 2822, section 3.6.5 on informational fields in the Internet message format, which says in part:

The "Subject:" field is the most common and contains a short string identifying the topic of the message.

What does this mean, in practice? Well, for one thing, it outrules the fairly common subject of hello, except in very special circumstances where the word hello actually describes what the rest of the e-mail is about. This is especially important when posting to mailing lists or reflectors – I see all too many mailing list posts with a subject of HELP!!!! or It DOESN'T WORK!!!, which force the reader to open the mail and read it through to determine if it is something that they might be able to help with. (Also see below on excessive use of uppercase on the Internet.) For busy people, it is the e-mails with such non-descriptive subject lines that are most likely to get overlooked or even simply deleted. The definition above also implies that a subject of here are the files you asked me to send is inappropriate – that kind of information belongs in the body of the message.

With so many don'ts, are there no dos to the art of subject lines? Certainly there are. In the last example above, a good subject line might be Requested files, explaining in the body of the message why you are sending them. (Here are the files you asked me to send during our phone conversation.) Of course, this can be made as formal or informal as you wish, and you would probably use a more relaxed writing style if you are sending a quick note to a family member, than if you are writing a business partner about a contract.

Make the Subject line stand out on its own. It is the first piece of information, along with the sender, which the recipient has in order to judge what e-mails to take care of first, and which ones can wait. You want your e-mail to be read as soon as possible (that's why you are sending it in the first place, isn't it?), while at the same time not taking the recipient's time if there are other more important e-mails that need to be taken care of first. Also, not all mail clients will display mail priorities: if a message is particularily urgent, state so in the subject line, but avoid excessive capitalization as IT MAKES IT SEEM AS THOUGH YOU ARE SHOUTING, even if that is not your intention. It also makes your letter harder to read.

Decide on a language, and do not invent your own

While this may seem like strange and unnecessary advice, I often encounter e-mails where the sender decides to save a few keystrokes at the expense of the person reading the message – often on mailing lists. A classic example might be i tried what u said and it didnt work what do you suggest i do now. (Yes, there are worse examples than that.) This is annoying because it tends to break the reading flow, especially for those who are not very fluent in the basic language (in this case English). Not everyone speaks every language they use natively.

This is equally important in the body of the message and in the headers, especially the Subject header, and also applies to so-called 1337 speak.

Trim what you send

In software design, this is considered sound engineering practice and known as be conservative in what you send, and liberal in what you accept (some variations exist, so you may hear a slightly different version). What this means is simply: only send what you need to, and don't complain unnecessarily about what you receive, especially not in public (or, in a way that affects the user of the software, unless you want it to, as if the user has to decide what to do with the superflous information). In the case of e-mail, this is most often a problem with mailing list replies: it is not uncommon for active threads to gather up a few pages of redundant information: quotes of quotes of quotes, mailing list footers, and so on. Trim the excessive information, making sure to leave enough so that someone who is just getting into the discussion can still get the context. This is particularily important on mailing lists but applicable in personal e-mail as well. Of course there are exceptions, like if you are discussing a deal with a company and more than one person can be expected to deal with those e-mails. In that case you might want to leave the entire content, and only add to it as appropriate.

Another case of this is mails that get forwarded to a lot of people. These letters often include a considerable number of e-mail addresses after being forwarded a few times. Besides being invasive to the other recipients' privacy, it also takes up unnecessary space and provides an easy way for e-mail-borne viruses to gather more e-mail addresses to target. Remove the names and addresses of previous recipients when passing something on, and use the Bcc (Blind Carbon Copy) field if you are sending to more than a few people who all know each other.

The last thing a large mailing list needs, however, is a dozen people commenting on the list about the inappropriateness of including excessive information or quoting (often, in the process, forgetting to trim their own messages thus adding insult to injury). Let the moderator or list owner handle such issues, or write a polite note to the offender personally, and never to the list.

Avoid HTML mail like the plague

Over recent years, HTML mail has become a considerable problem. HTML is the markup language created for use on the World Wide Web, and it was never designed to be used for e-mail – and certainly not the way most people do. It has happened more than once that I have got a message saying at the top my changes are in red below and then quoting a few pages of what someone else has written, with minor changes interspersed in the text. Besides the size penalty – HTML e-mail easily gets two to three times as large as the equivalent plain text e-mail, and as is illustrated by the screen shot can get much larger than that – this also presents a lot of users with practical problems. For myself, it means having to invoke a program that is completely separate from my mail reader (the web browser) to see what was sent to me. Replying to such letters is pure horror with a mail client that does not understand the concept of fonts and colors, nor web bugs or other techniques to track what e-mails (often spam) people look at.

Most (all?) e-mail clients can be configured to send plain text e-mails only. Those mails might not look as spiffy without the 50 KB background image and compulsory music as someone opens them, but they will not bog down the recipient's computer needlessly. The key question when adding anything to an electronic mail message is: does it add to the content, or make the message easier to understand for the recipient? The way HTML mail is most often used, all it adds is unnecessary bloat. Most people can probably live without that, and especially the large majority of Internet users who are still using dial-up connections, often paying by the minute (and thus per kilobyte of data they are forced to download).

On Usenet, posting in HTML is akin to signing your own death sentence. You only get to do it once. After that one mistake, you should probably consider yourself lucky if your Internet service provider does not terminate your account due to excessive incoming e-mail traffic.

Avoid using UPPER CASE LETTERS

Writing in UPPER CASE on the Internet has for long been the accepted way of expressing that you are shouting. This is probably not what you want. Besides that, excessive amounts of text written in upper case only is exceedingly difficult to read.

There are situations when you want to draw attention to something, make the reader slow down and perhaps read something twice, or intend to show that you are shouting. In cases like that, writing a few words using upper case letters may well be appropriate. However, limit it to just that: a few words. There are no hard-and-fast limits, but if you have to turn on Caps Lock to be able to write it without getting tired in the finger holding down the Shift key, it is definitely too much.

Learn the convention

Internet e-mail was long limited (although some would not consider it a limitation) by the fact that only plain text could be transferred, and many still frown on receiving e-mails in anything but plain text. (Also see the part about HTML e-mails.) Learn the conventions that developed out of this: instead of using bold face type, you *surround text with asterisks*. Italic type is usually replaced with /something like this/, the slashes showing that the text is written on a slant. Underscores are sometimes used in roughly the same way, to put emphasis on _certain words_.

Adopting this writing style will allow you to get your message across more effectively both to people who use graphical e-mail clients as well as those who for some reason use alternatives based on plain text, or even just prefer the plain text version of an e-mail over a bloated and often spam-ridden HTML version.

Make regular line breaks, even if your mail client does automatic word wrapping in the composition window. Not everyone wants to read your entire e-mail on one long line. Between 70 and 80 characters per line is usually appropriate, and you certainly shouldn't exceed 80 characters on one line unless you have a very good reason. (For example, content that cannot be split up correctly, like long web site addresses.) The easiest way on most systems to find out if your e-mail client is doing soft word wrapping is to enlarge the message window slightly. If the word wrapping changes, you need to add manual line breaks. Also, it is good practice to add blank lines here and there, for the same reason why you would not write an entire essay in a single paragraph.

Also, know where your recipient is expecting to find your reply. Many who are using Windows tend to write their replies at the top of the message, while people who come from a Unix background (including Linux), often prefer to put their replies at the bottom of the message. Again there are no real hard-and-fast rules about which is right and which is wrong, and such discussions tend to get almost religious in nature. In the case of personal correspondence, it is mostly a matter of the people conversing agreeing on where to put their replies to achieve a reasonable degree of consistency. On mailing lists, it's good to go with the flow, as people will be accustomed to that and know where to expect to find a reply. If the majority is top-posting, try to follow that convention. Conversely, if most people are writing their replies below the original content, it is advisable to not top-post (so write your reply or comment below the original message, like everyone else). A common argument in favor of top-posting is that it means one does not have to scroll through a lot of unnecessary text to find the reply; I personally see this as an excellent argument for trimming the message instead.

Avoid proprietary file formats for attachments

Not everyone is using the same software as you do. Yes, that is right. While a large number of people run Microsoft Office on Windows and are happy with that, there are also a lot of people who for various reasons do not. They may feel uneasy spending large amounts of money on products from a company that has not changed its practices noticably since being found a monopoly in court, they may not have the most modern computers (recent versions of Microsoft software require pretty recent hardware to be usable), or it is possible that Microsoft's products just do not let them perform the tasks they need in their daily work. Whatever the reason, there are people on the Internet who do not use the most recent version of Microsoft Office or even use Microsoft Office at all, and there are lots of those people.

This is of course equally true for any software package, but documents created in Microsoft Office are common in e-mail attachments, and have been so for a long time already. It is time to change that. While people believe that since they see a representation of a paper on the screen in Word, everyone will see the document exactly as they do, this assumption is completely wrong. Not only that, proprietary formats (such as Word) tend to add a lot of completely unnecessary bloat to the actual content, a phenomenon that generally gets worse as the content gets shorter. In February 2004, I received a short evaluation form as an e-mail attachment from a person who shall remain nameless. It contained a total of 421 characters, including line breaks, and no formatting that could not easily have been accomplished with simple HTML. The file was saved as a Word document, which was 22528 bytes in size. Encoding this so that it could be sent over e-mail added another 30% or so. The file as sent was over 70 times larger than what was necessary to get the information across, and had been completely useless to me had it not been for the heroic efforts of the OpenOffice.org team in reverse engineering the Microsoft Office file formats.

Unless you really have to do things differently, or are working within a small group where you know that everyone is using the same software as you, the best way to send textual content in electronic mail is to simply paste it into the body of the message. Tabulated content of significant length can be attached as what is known as a Comma-Separated or Tab-Separated Values (CSV or TSV) file, which just about every database and spreadsheet software can work with, not to mention that it is also possible for mere mortal humans to read without any particular software (a simple text editor and a bit of patience is enough). For textual content which requires some formatting, if HTML mail is not an option, attaching a HTML file (most word processors today can save to HTML, or you can create your content in HTML originally) is often quite sufficient. In cases where the formatting is critical, such as brochures, file formats like PDF (Portable Document Format) and plain or compressed Postscript (the latter is especially common among users of Unix-style operating systems) are reasonably easy to work with and, even more importantly, portable across hardware, software and time barriers. All of these formats, with the possible exception of PDF, are well understood, widely implemented and unlikely to change in the foreseeable future.

Contrary to that, proprietary file formats change much and often. A document saved using Microsoft Word with the most recent version available just fifteen years ago was found to be near unusable today in a test conducted by a member of and reported on the Electronic Frontier Norway mailing list in January 2004. Most of the content was completely unintelligable, and what was usable looked very strange to the reader. While this particular test focused on Microsoft Word, other software using proprietary file formats often suffer from the same problem: file formats change, and there is often no reliable way of accessing old documents with new software. Also, the lack of documentation of these formats means that people who are for some reason not using the same software as the person who created the document, will be at a great disadvantage in opening and reading these documents. This has the potential of also including people who might be interested in the document in the future.

Any file format will evolve; it is when such evolution makes reading old documents with new software close to impossible that we need to stop and think about especially the long-term consequences. With much commercial, proprietary software, long-term seems to mean two or three releases ahead.

The Internet was designed to be a means of sharing information. We should keep to that basic design goal, and one of the easiest ways for persons just like you and me to do that is to use standardized and public, not proprietary, formats for exchanging information. Not only will it ensure that the information can be read by the recipient regardless of the computer platform he or she is using today, it will also be much easier to preserve the information for the future. (For whatever it is worth, this web site is also equally usable, albeit not as spiffy, with a web browser supporting only HTML 2.0, which is the first formally specified version of HTML. The only requirement is that the browser follows the standard of ignoring markup tags it does not understand.)

There is another discussion about this in the context of software interoperability available.

Start a new thread when starting a new discussion

It is not always easy to use a mail client that does proper threading when participating on mailing lists. A large part of the reason for this is that many, especially newcomers, start new discussions by opening a previous post, replying to it, and then clear out the body and subject and then write what they want to say, or ask. (Some people don't even go through the trouble of cleaning it out, simply adding their own content, which is even worse.) The problem is, that does not start a new thread, as is illustrated by the screenshot from my e-mail client. If I were uninterested in the Slackware disaster thread and deleted it without looking any further, I would never have seen the post about Tab Size in VI editor????. Deleting entire threads is quite common on busy, often technically oriented mailing lists, which means that this behavior significantly reduces your chances of getting a reply from a knowledgable person.

To understand this problem, it is important to understand that there is information, mostly meta-information, that gets stored with each e-mail that is not normally displayed in an editable form. The two most important pieces of such information in this case is the message ID and references. While very rarely displayed by user agents, these two fields control how messages are displayed in relation to each other by thread-aware clients.

When replying to an e-mail, the new e-mail will reference the message ID of the e-mail you are replying to. This is fine and even desirable when continuing a previous conversation, but means that a post on a new subject, even if you change the Subject line, may very well get buried under several layers of other posts. Besides being a distraction to those who are interested in the original discussion, this also means that there is a good chance that people who might otherwise have been able to answer your question will never get to it, because for one reason or another they were not interested in the discussion you sent it as a follow-up to.

So, to start new threads, always start with a new, blank e-mail. Otherwise, it is not a new thread.

Keep your signature short

Some people love to use long signatures, adding more and more content to them until the signature is, at times, several times the length of the e-mail content. This is not by any means appropriate, however, and often tends to irritate people. Generally, an e-mail signature should be kept below four or five lines long – anything over ten lines is definitely excessive.

While brief, however, a signature should include some basic information. Depending on who you are and how you use your e-mail account, it may include such things as your name, what department you work on, e-mail address, PGP key information, or an inspirational quote that you particularly agree with. One thing that is clearly not appropriate in a signature unless under very special circumstances is ASCII art: drawing pictures using various letters, numbers and symbols.

Especially if you plan on posting on technically oriented mailing lists, you should begin your signature with a single line containing two dashes followed by a space (-- ). This tells clients that are aware of this convention where your signature begins, so they can strip it out easily. Quoting signatures, especially on mailing lists, is definitely not appropriate and this saves the user one step in preparing his e-mail while costing you very little.

Send your e-mail to the proper person

Very few e-mails are as annoying as the ones that cannot be automatically filtered out, but were not intended for you. I recently received a letter from someone who wanted me to forward it to another person, based on the fact that apparently, this person and I have the same surname and we live in the same country. I can only speculate where the sender got my e-mail address and information – it cannot have been from my web site, or that person would surely have noticed that it violated at least one long-standing point above.

Before sending an e-mail, ask yourself: am I sending this to the proper recipient? If not, ask yourself why you are sending it to the person you are, instead of where it should be going. While one huge use of the Internet is message forwarding (electronic mail), this does not mean that individuals should have to work on getting your e-mail to its recipient. That is your job, not someone elses.

Stop forwarding virus warnings!

I do not know how many times I have received e-mails with warnings of the latest, most dangerous virus ever that, after a quick Google search for one or two key words turns out to be a hoax. Some particularly nasty ones even say that I would rather receive this a dozen times than not at all. Actually, it is the other way around.

Suppose that an average Internet service provider (ISP) has 10,000 customers, 10% of which (that's 1,000) receive such an e-mail ten times each. Also suppose that this e-mail adds up to a total of around four kilobytes (4,000 characters) of data, including headers and the technobabble known as envelope data. That's 10,000 * 4,000 = 40,000,000 bytes or almost 40 MB of data. Multiply that by a few hundred ISPs and spread the traffic over a few days, and it becomes more clear why this is a problem that clogs up the wires that make up the physical Internet. End sites also often have a relatively limited bandwidth, which makes things even worse – if they receive a large number of such virus warnings, the real e-mails may not get through in a timely fashion or sometimes not at all. This is also the exact reason why Internet-spreading viruses (that really are not viruses at all, but most often worms – though very few understand the technical difference) not only affect vulnerable systems, but also the Internet as a whole.

Before forwarding any virus warning, use your favorite search engine, pick out a few key words from the text and perform a search on them along with words such as 'virus warning'. If it comes up as a hoax, do not pass it on but instead send a reply to the original sender only telling them to do the same. Maybe some day, if people start using their common sense, we can get rid of these very irritating e-mails. Anything that tells you to forward it to as many as possible, should ring a big warning bell.