Email line lengths
Thu, 8 Oct 1998 15:05:02 +0930 (CST)
> Carriage-Returns/Line-Feeds were a necessary feature of
> the mechanical / electro-mechanical typewriter and telex.
> They were carried into the computing era because the
> original 'terminals' (early-mid 1960s) were 'glass
> teletypes' - you always invent the future using concepts
> and tools from the past, etc.
> So *I* reckon it's a problem to have to use a line-feed to
> end a para., and to create space between paras.; and it's
> an even worse problem to have to use one to end a line!
Well get another e-mail client.
Basically, SMTP is a 1960's mail protocol. So it uses the
1960's end of line conventions. Note that the standard is
quite specific about what EOL conventions are acceptable, so
there is no problem about sending e-mail between machines
with different conventions -- only with people that attach
text files as binary attachments (and they should have a
look at their .mime.types file).
There is no need for all of this to make its way up to the
mail client. I am pressing the key marked Return at the end
of each paragraph, not at the end of each line.
My mail client also re-wraps quoted text and removes .sigs
when quoting. Naturally, it also runs the spell checker
over the message before sending it. All sent messages are
automatically archived for a month, as are all deleted
messages. Sent and received messages can be automatically
filed -- thus Link appears in its own folder, and messages I
send to my friend email@example.com is automatically filed in
opens an e-mail window for each mailing list folder that has
received new mail.
Now this is all this written in a Emacs LISP package called
VM, basically written over five years by Kyle Jones. Surely
vendors with their much larger programming teams can
implement the same functionality (as opposed to glitz)?
The problem with line wrapping from LAN packages is with the
gateway into SMTP, which fails to convert the body of the
message into SMTP conventions. Actually, most gateways do
have a line wrap option, but they are usually defaulted to
IMHO, sending an e-mail line longer than 70 characters is
non-portable, as it won't be able to be editted nicely on an
IBM 3270-series terminal. I reduce the line length even
more to allow a reasonable amount of quoting. Longer
lengths just limit your audience.
> So I think we'd be putting a puny finger in an
> ever-enlarging gap in a bloody big dam if we were to try
> to restrict email to fixed line-lengths.
Not at all, as users complain to the authors of the LAN
packages, they will adapt their software to come into line.
A concrete example. Our help desk used to be on the far
side of a cc:Mail gateway. It was slow and didn't wrap
lines. Our users ridiculed the help desk for sending
unreadable e-mail about faults that occurred ages ago. So
we moved them to an IMAP client. All e-mail clients are
bascially the same, so the retraining was minimal. Lotus
lost customers, and Netscape gained them. An advantage is
that if the Netscape user interface falls behind, then there
is no infrastructure change required to change the e-mail
client -- no folder migration, no new server software, etc
Given this, I don't understand the attractiveness of
non-IMAP e-mail servers. 
This addresses the original sender's problem. If the e-mail
from the organisation doesn't have wrapped lines, then it
loses effectiveness. It would annoy my manager, but he may
very well persevere where other people would simply delete
the message unread.
Given the huge amount of futzing spent tuning paper
documents to be easy on the eye, not to do even a minor
amount of neat presentation for e-mail that is designed to
persuade is foolish. As you would expect, the conventions
for paper and screen are different -- it is just that paper
has been around long enough to be codified in books like the
 Being able to run multiple clients is a huge
advantage. For example, our e-mail system has a HTML
IMAP reader. So I can read my e-mail from a web
browser at any Internet cafe. And I can use the IMAP
reader built into a PDA, as well as the IMAP reader on
my desktop. All without scattering my e-mail archives
across dozens of machines.
Glen Turner Network Specialist
Tel: (08) 8303 3936 Information Technology Services
Fax: (08) 8303 4400 The University of Adelaide 5005
Email: firstname.lastname@example.org South Australia