InsectNation

there is no significant risk to your health


Using email "properly"

This article was principally written when I was the computing officer for Churchill College MCR and sadly hasn't been updated (or finished) since then. I still think that most of the contents are valid, if not brilliantly described, but also of interest for all things email-related is Infinite Ink. Take a look.

There are many aspects of using email which are not well-known but which make it significantly more effective and pleasant; I describe some of these aspects in this guide. The main issues are the ettiquette that should be observed in using email, technical restrictions that your recipients may encounter (and of which you should be aware) and some useful `extra features' of email of which you may not already be aware.

Receiving and sending email

  • IMAP/POP
  • Outlook/Eudora/Evolution/Pine
  • Webmail
  • Connection speed and location

General Messaging Ettiquette

There are lots of things that people should do to make their emails more readable but they tend to be rarely used! Here's a run-through a few of the things you should try and check in each part of your email messages to make them more readable (and hence join the ranks of the technologically self-righteous :-)

Content

  • Top-posting
  • Indiscriminant forwarding
  • Virus warnings
  • Spam and filtering

Make sure you write clearly and accurately in emails: just because it's not a paper letter doesn't mean that your recipient doesn't want to receive a well-written and coherent message. Please capitalize and punctuate properly!

Be careful with use of angry or sarcastic language — even as a joke. Without seeing your face or listening to your voice it can be hard to tell whether contentious comments are meant seriously or not and arguments can result. These are sometimes called `flame-wars' when they become extensive and occur in public forums such as mailing list or newsgroups.

Smilies and frownies (written as :-) or :-() and their many variations can be used to indicate your mood but be aware that writing and interpreting them is not an exact science and interpretations may vary. Other notations, such as writing <rant> before letting rip and </rant> when you're done can also be useful ways of expressing tone in email, with obvious extension to moods other than ranting. In case you're wondering, the angle bracket and slash notation is derived from the HTML language used to write Web pages. Be aware, however, that emotion and tone have been available to good writers in much more satisfying and subtle ways for many generations — these are shortcuts rather than ways to produce good writing!

You may periodically receive jokes, chain mails and virus warnings by email; a common `misuse' of email is to forward these on to all your friends or, just as often, everyone in your address book. In general, don't do this — jokes should only be sent to people who you know will appreciate and enjoy them, chain-mails are considered a scourge and often don't correspond to any `real' petition and virus warnings are very often hoaxes. The last of these is the most damaging: virus warnings, if real, will be sent to everyone in danger by computing administrators. Forwarding or starting unofficial virus reports just makes more work for computer officers.

Replying and forwarding

  • forwarding, bouncing
  • reply to all
  • top posting

Message Body

In general, mail programs will `wrap' the body text such that it fits in the screen but for many systems this is not guaranteed to work: there are often errors with line-wrapping when sending mail from a Windows PC to be viewed via the Hermes login system. It is advised that all email posts be line-wrapped at a width of 80 characters as this is a fairly standard width for a UNIX terminal.

The variation between the text-based remote systems and the graphical UI approach to accessing email (as mentioned above) means that you often have to be careful when sending email to a range of people: unless you know that the systems used by your mail's recipients can definitely deal with graphics or styled text (aka `HTML email') then it's best to steer clear of them.

If you're replying to an email then there is a convention for placement of the reply relative to the original message: make individual replies to the points made in the original message placed under the point in question. Replying above the message or as a single block of reply to several questions is a less ideal method of returning an email as it is harder to establish context in these formats. I would advise, though, that if you end up in a chain of emails then follow whatever convention is being used by your correspondant: if one of you makes replies above the previous message and the other places the replies below then your train of argument will be very hard to follow!

Also in the case of replies or message forwarding, try to strip out non-essential text on replying. Don't just let the email size `snowball'! This will make your conversation much easier to follow and importantly reduces the download time of the email; including a huge amount of irrelevant information from a previous email is very annoying. When you already have that information from the original email then you don't need to get it again (and again and again!)

Signatures

Many email programs allow a `signature' to be automatically placed at the bottom of all emails and many email users make use of this facility. However, there are some guidelines to good use of signature files:

  1. Keep your signature short and to the point: 4 lines of content is a sensible maximum, more than 6 is starting to get silly. If putting address info in your sig, lay it out horizontally rather than in standard vertical format: it takes up less space this way
  2. Don't put your email address in your sig: if they've got your email with the sig in then they've got all the info needed to reply anyway! Redundant information like this is rarely a good idea.
  3. Use `sigdashes' -- these are a very useful feature that is considered a requirement by many of the more technically aware email users on the CUDN as it allows automatic stripping of signatures when replying to the messages in which they are included. To use sigdashes, just make the first line of your signature "-- " (i.e. two dashes and a space). In some mail programs (Pine is possibly the best example here) there are configuration options to use sigdashes (and to use them to strip sigs from messages as you reply). Once you've used them you won't go back!

Attachments

Attachments are a contentious element of emailing since they're just about the single most misused aspect of the technology! If you feel that email is a useful way to send large files (photos or video clips, perhaps?) to friends or you think that sending Word files out to a mailing list is a good way to distribute information then please read this section!

The problems with attachments can be broken down into three rough categories:

  1. Attached file(s) size
  2. Necessity
  3. Universality

The first of these is perhaps the most obvious one: attaching a file to an email is often regarded as a good way to transfer files between people, which is ok as long as you're doing it with a small number of recipients who are expecting the file to be transferred in this way but sending large attachments to a list who don't want or expect it is very bad nettiquette. When someone receives an attachment it's a very `opt in' process...you have to download the attachment to find out you didn't want it, which is very painful on a slow connection with a large attached file: I've seen 50Mb attachments sent indiscriminately to a mailing list of hundreds before! Also bear in mind that most Cambridge email folders are very small — the Hermes ones are of order 10Mb: if you send large attachments then you may well get bombarded with `inbox full' overflow messages, which are neither pleasant for you or the unfortunate recipient. A final point is that Hermes will not actually process emails larger than 3Mb, so large attachments may not even work at all.

The second point, necessity, is rather more subtle: it all comes down to asking yourself the question `Do I need to send this information as an attachment?'. This has two interpretations: can the information be sent more efficiently as plain text in the message body and will everyone on your recipient list really appreciate receiving your info as an attachment. In most cases, the information involved can be represented just as well as plain text in the message body, especially in situations like sending a Word document full of text as an attachment — see the next para for more on this sort of situation. In cases where the file cannot be rendered into a plain text form, see if you can publish the file on the web or on an FTP server somewhere rather than attaching it to an email: this will make viewing the file an opt-in process one rather than the much more controversial opt-out type (opt-out unsolicited emailings are typically regarded as spam).

Another (!) good reason to be careful about attachments is that from the word `universality': I've bundled this with `necessity' above since if a file is not universally readable by your recipients then it's certainly not `necessary' to send it — anything but, in fact! The major issue of this kind at the moment is the ubiquitous use of closed Windows file formats such as Microsoft Word documents to store completely generic textual information: if you have a Word file whose contents you want to make known to people via email, then copy the text out of the file and paste it into your email's body rather than attach the file: there is a good chance that your recipients will be users of UNIX systems (or similar) and will be unable to read the file at all. Word and Excel files also fall into the category of unnecessarily bulky files as they are often orders of magnitude larger (and thus slower to download) than a text file containing the same information: if you send files like this then expect to get some rude messages in reply!

If the `recipients will benefit from not receiving attachments' argument doesn't appeal to you then maybe a less selfless one will: if you want people to read the information that you're sending then attachments are a bad approach to take. For example, a user on a text-login Hermes account will receive an email declaring that you've sent an attachment and in order to view it will have to use a separate FTP client to download the file from the Hermes server and finally run a separate program in order to view it: this level of complication, although not hard to do, is enough to dissuade users from viewing any but the most important attachments.

If you must send an attachment (and please think long and hard about how you can avoid doing it, first!) then make sure you describe what it is in the message body as well. A blank message with an attached file is uninformative and very rude!

Posting to mailing lists and large groups

bcc to large groups; dummy address in To: field

Security: spam and viruses

  • Encryption: PGP and GPG keys
  • signing and encryption
  • SSL, SSH
  • Spam
  • Viruses (and virus warnings)