Email sending checklist

by R.M. Schneider
Last Update: 15 Nov 2009

Under Construction

Is the message easy to read? Good use of white space will help. Do not overuse UPPER CASE LETTERS.  It is considered to be "shouting".  Spammers us this format  and some spam-filter software may delete your email before it reaches the intended recipient.

Does this message fit the expectations of the recipients)? What are they expecting to receive from you?

Does the message suit email or is a visit or phone call more appropriate? This is especially the case when there's bad news to convey to colleagues

Will you annoy, offend, or confuse anyone with this message? It's hard to read body language in an email and so it's very easy to misinterpret.

Were you angry when you wrote the message? If so, then don't send it. Wait until you've calmed down and then send...

 Was your message composed with thought and purpose? There's nothing worse than reading an email diatribe.

Who might read the message and what might their impressions be? Remember that those that read the email may not be the people that you sent it to.

How many emails do the recipients usually receive, and what will make them read this message? Some people are receiving 100+ emails per day. Why should they read a mail from you over others? A well thought out subject will help.

Did you identify yourself and make it easy for the recipient to contact you? If I can't see who a mail's from it may not get read. What's worse is reading an email and wanting to respond directly, but not having any contact details. An automatic signature is the easiest way to do this.

It is best to avoid using attachments if possible. However, if you must use an attached file, will they be able to open and read any attachments? Note that most corporate and free email systems artificially limit the size of attachments. 2MB or less is very common. Hotmail users are especially susceptible to this. 

 Have you ensured you have actually attached the attachment? I've lost count of the number of times I've been asked to comment on an attachment that doesn't exist...

 Have you provided sufficient background for them easily to understand the message? This is especially important when bringing a new recipient into an email conversation. You can include the text of the original email if it is relevant.

Will the message seem important to the receiver or will it be seen as a waste of time? Only send useful emails.

Do you expect a response and have you made this clear? "For information only", "fyi", "for info" etc are all indicators that no reply is necessary - so don't expect one.

Does the email have a meaningful subject? "Read this" is not helpful and to some will be seen as spam.

Is the email spell checked? Their is nithing wurse than bad speling becuase it simply it can be easily avoided.  Note that words can be spelled correctly, yet wrong, e.g. the use of the word "Their" in the previous sentance.

 Have you checked that the correct recipients are on the mail? Accidentally pressing “reply to all” could be very embarrassing!

Inserting recipients using the address book can often lead to confusion. Ensure you use the correct “Elaine”… I have a name similar to a client's customer. At least once a month I get their email...

Check the e-mail addresses that you hold regularly including your contacts with organisations. Make sure that there is enough information to separate out the different 'Elaines'

Consider using the tracking options in the e-mail (Read and Delivery receipts) these will give you a very good indication of whether the message arrived and whether it was read by the recipient, and therefore whether you can expect a response. (This is especially important if the recipient is an Action Addressee).

If using a mailing list which you do not want to divulge to all the world, make sure that the messages are sent individually, or via the BCC method, and not with the entire mail list at the top of each recipients copy.

Backups

There are only two sorts of people who do backups. Those who have lost data, and those who will do. Backups must be tested, as it is too late to try your recovery process on a live system.

In general the maximum estimate for backups is between 24 and 48 hours because:

• It is not viable to try and recreate more than this amount of information. Therefore it will never be done and will be lost for ever.
• The time taken to recover the information must therefore be less than this if it is not to have a fundamentally detrimental effect on the business. Therefore hardware and recovery must all be replaceable in this timescale, and the backup devices/media must be portable between the target hardware.

We had a situation where a professional services organisation were not verifying the backup on a Unix System, and did not realise that there was a corrupt section on the tape. This tape was the weekly backup to a series of incremental backups and the result was a complete weeks worth of data/work was lost. This was totally unacceptable! But nothing could be done!

Why Email in HTML Format is Not Desirable

The following was posted on a blog that I read.  I agree with what Charlie says, and am unable to say it better:

by Charles Stross at http://www.antipope.org/charlie/blosxom.cgi

1. When you sent me email, you are requesting access to my eyeballs. Access is granted only on my terms. I choose to read my mail in monospaced 10-point text in a terminal window. I don't care if you want to use blinking underlined boldface or WingDings, it will be read in monospaced 10-point text in a terminal window or not at all.
2. HTML is not an RFC standard for email text. (Go here if you don't know what an RFC is.)
3. HTML allows you to embed links, and inline images stored on a web server. I often receive and process my email offline. I do not want to open your missive on my Palm Pilot and have to wait ten years while it goes online via my cellular phone and downloads your precious letterhead or stupid snapshot at 9600 baud.
4. Images can be sized to one pixel by one pixel, and made transparent. IMG SRC tags can point to server-side programs that log the client that sent a request for the one-by-one invisible image. The IMG SRC request can carry data such as the email address to which the mail was sent. This confirms that the email has been received. This is known as a web-bug, and it is a favourite technique of spammers for verifying that an email account is valid and there's someone there to receive their spam. I don't like spam, thank you very much.
5. Javascript (or rather, ECMAScript) is untrusted third-party code that can be executed on my computer if I read your HTML email. Sorry, but I don't run untrusted code -- and that includes scripts of unknown origin arriving in my mailbox.
6. HTML email is bloated -- typically to at least double the size of the plain text. (And that's without images or script content.) Repeat after me: "consuming someone else's bandwidth without their prior content is wrong." Especially if you don't know whether I'm going to read your missive using a cable modem or a cellphone making an international dialup call at 9600 baud.
7. Through force of habit I use an email client called Mutt. Mutt is an extremely powerful non-graphical UNIX-based tool that runs in a terminal window. Mutt is small and fast, in large part because Mutt is not a web browser. I am not going to switch to reading my email in a web browser just to stroke your ego.
8. SpamAssassin, the discerning netizen's spam trapping tool of choice, thinks that HTML email with no plain text accompaniment is spam. That's a good heuristic -- almost all spam email is HTML-only. I do not read spam.
9. Long experience shows that those mail clients most vulnerable to worms, viruses, and other stupid infections invariably default to using HTML instead of plain text. There's a reason for this (see #5 above). By using an email client that doesn't process HTML, you can drastically cut the risk of picking up a nasty infection.
10. Long experience shows that people who persistently send HTML email are often not aware that they are doing so. This is symptomatic of a marked lack of situational awareness -- they haven't bothered to find out just what the internet is, what the conventions surrounding its use are, and how to configure the tools they are using. Merely pleading ignorance is no defense -- did you expect to get behind the wheel of a car and drive it without learning what the controls do and what the rules of the road are? In general, I have found that people who persistently send HTML email rarely have anything of interest to say. It indicates a preoccupation with style over substance, ignorance over experience -- which is why it goes straight in the trash.