Abstract

Table of contents

• Introduction
• Fetch versus news mode of getting information
• Standards and global messaging
• Message format
• Alternative text
• HTML fill-in forms
• Decision support
• Not including all in a message
• Multipart messages
• Groupware
• Storing and searching
• Purging and archiving
• Filters and spam control
• Deleting already sent messages
• Notifications
• Security
• Word wrapping and quote marks
• Newsgroups header
• Character sets
• Forwarding of messages
• Very large messages
• Millenium problem

Introduction

World Wide Web (HTML and HTTP) is the mostly used communication mode on the Internet. But e-mail and messaging are not far behind. If you count the number of people using various Internet services, e-mail is larger than the World Wide Web. In spite of this, most discussion about the Internet is about the World Wide Web. And the World Wide Web has been developing new features at a more furious speed than e-mail. Much will however happen with e-mail in the next years.
   This article is based on a questionnaire to e-mail experts at IETF meetings and on the author's experience from twenty years of development, research and standards work in the e-mail area.

Back to table of contents

Fetch versus news mode of getting information

Information exchange on the Internet can be done in real time (the giver and taker of the information are connected at the same time), like video conferencing and chat systems. But more than 90 % of all information exchange on the net is in non-real time (you read information which was stored earlier by someone else). There are three major modes for information exchange, the fetch, news mode and the push mode.
    With the fetch mode, a user finds and fetches information which is already available on the net. Information is mainly found by following hyperlinks, by using search engines or by using bookmarks. The typical softwares in the fetch mode are web browsers, the most common protocols are HTTP and FTP.
    With the news mode, new information is distributed to recipients. The recipients download and read newly arriving information. Very important in the news mode is that the computer knows what you have seen and not seen, and will help you find the new, unseen messages. You can of course also go back and fetch already seen messages. Software for the news mode usually has much stronger features for knowing what is new for you than software in the fetch mode. This feature is called news control. Typical softwares in the news mode are e-mail, Usenet News and groupware systems like Netscape Collabra, Lotus Notes and Softarc First Class.
    An important difference between the fetch mode and the news mode is that with the fetch mode, the information you are searching for is usually already there, stored on some computer for you to fetch. With the news mode, new information is regularly or irregularly sent and distributed. With the news mode, you get a reply to a question by sending the question to one person or a group of people, and waiting for the reply. The information you search for is stored in the brains and personal archives of the people you send your question to, and you get it from them, not from information already stored in the Internet.
    There is no sharp limit between e-mail, Usenet News and groupware, as seen from the user. Often all three services are combined and intertwined in the same software. Often messages are sent to both, or are moved by gateways between these systems. This will be even more common in the future. It is therefore not possible to write an article about e-mail alone, and this article is about the future of the combined services of e-mail, Usenet News and non-real-time groupware. (Similar predictions have been made by the groupware expert David R. Woolley in his paper "The Future of Web Conferencing" at URL http://thinkofit.com/webconf/wcfuture.htm). His paper looks at this from the groupware viewpoint, my paper from the e-mail viewpoint, but our predictions are similar.)
    When you send a message, you usually address the message either to one or more people, or to one or more groups of people, or both. When you send a message to a group of people, you need not list each member, you just give the name of the group. The messages are then distributed to those who subscribe to this group. Note that this is exactly the same for e-mail mailing lists, for Usenet News newsgroups and for groups, sometimes called forums or computer conferences, in groupware software. People are interested in the service provided by the network, not in the techniques behind. Most people prefer one single user interface for all messaging. They do not want to use different commands for reading news from a mailing list than for reading news from a Usenet News server or groupware server. They do not want to use different commands to send a message to a group, if the group is a mailing list, than if the group is a newsgroup. They do not want to use different commands to subscribe and unsubscribe from mailing lists than from newsgroups or groupware forums. Because of this, the client software in the future will more and more be combined clients for e-mail, Usenet News and groupware systems.

Back to table of contents

Standards and global messaging

Many local messaging systems and groupware systems provide advanced services which are only available if the sender and recipients of messages all use the same software. If a feature is to be used by people using different software, the feature must be standardized, and the standard must be widely accepted. This is a major obstacle to getting new features into e-mail. However, there is a lot of work going on with standards development in the messaging area. The rapid pace of development of new features in the World Wide Web has been helped by the fact that one single manufacturer, Netscape, dominates the market so much. The only serious contender, Microsoft Explorer, has chosen to closely copy the features of Netscape. More and more people are using their web browser also for e-mail, news and groupware, and this means that the choices of features made by the people responsible for developing web browsers might begin to control what happens in the mail area in the same way as it has done in the World Wide Web area. This may cause faster global acceptance of new features in e-mail, as it already has in the WWW area.

Back to table of contents

Message format

Below is an ordinary, plain text message:

Letter in plain ASCII format

From: Jacob Palme <jpalme@dsv.su.se>
To: Mary Dawkins <mdawkins@foo.bar>
Subject: Thursday meeting
Date: Mon, 8 Dec 1997 12:58:58 -0500
MIME-Version: 1.0

Welcome to the decorating committee meeting on Thursday,
December 10 at 9:00 a.m.
Location: Electrum building, Kista.
Please confirm that you can come.
:-) And please bring your new red dress,
it brightens up the meeting.

--------------------------------------------------------------
Jacob Palme                  Stockholm University
Professor                    and KTH Technical University
E-mail: jpalme@dsv.su.se     WWW: http://www.dsv.su.se/~jpalme
Snail mail: Skeppargatan 73  Personal phone: +46-8-16 16 67
S-115 30 Stockholm, Sweden   Personal fax: +46-8-783 08 29

The same letter in HTML format

Welcome to the decorating committee meeting on Thursday, December 10 at 9:00 a.m.

Location: Electrum building, Kista, see map.

Figure 1: An e-mail message as it might look with and without use of HTML

When you look at a web page, you see graphics, color, neatly formatted pages. When you read an e-mail message, today you usually just see lines of typewriter-style text with very little formatting. One reason for this is that a web page usually has more readers than an e-mail message. And if there are more readers, then it is cost-effective to spend more work on producing a neatly formatted document. Neatly formatted documents with graphics and typography saves time for the reader, but increases time for the writer, and is thus more cost-effective with more recipients. Because of this, many e-mail messages will continue to stay as plain text with no fancy formatting.
    The larger acceptance of editors which makes it almost as easy to write a HTML document as a plain text document will, however, cause more messages to be in HTML format.
    Formatted text will rapidly become more common. And the format for formatted text in e-mail is going to be HTML, the same format that is used in the World Wide Web. With HTML, you can have various sizes of fonts, bold and italics, lists, graphics, tables and forms. Reading an e-mail message will then be similar to reading a web page. The response times, however, must be faster. The average time a person spends on each incoming e-mail message is only about thirty seconds. It is then not acceptable if downloading the message takes many seconds, as is common with many ordinary web pages today.
    When the e-mail client is not built into the web browsers, there are two ways in which e-mail clients can display HTML. One way is to do the generating of the screen in the mail client, the other way is to use a separate web browser. Many mail clients will be able to show common and simpler HTML themselves, but turn the text over to a web browser for more complex pages. This will not be very noticeable for the users, since modern object linking features means that a web browser can format text in a subwindow which to the user appears as inside the e-mail client.
    Many mail systems today support an alternative to HTML called text/enriched. Text/enriched is more limited than HTML, and will probably be replaced by HTML as the format for sending "rich text" in e-mail.

Back to table of contents

Alternative text

A problem with new features is the transition period before all software can handle the new feature. One way of solving this problem is available in the MIME e-mail standard. The methods is called "multipart/alternative". With this method, the same text is included more than once in the message, for example once in plain text format and once in a more advanced format, like HTML. A mail client which understands multipart/alternative will show only one of the two identical parts to its users. If it can display HTML, it will usually show that part and not the plain text part.
    It may sound inefficient to send the text twice, but actually the texts of e-mail messages are usually very short and this inefficiency does not cost very much. The bulky attachments need not be included more than once.
    Multipart/alternative, with one plain text and one HTML version will probably be very common for some years, until HTML in e-mail becomes generally accepted. A disadvantage is the increased download time to download two copies of each message. The IMAP protocol for downloading mail, however, has facilities to download only one of the two alternatives for these kind of messages.

Back to table of contents

HTML fill-in forms

Figure 2: Structuring of message exchanges as speech acts (From Winograd-Flores 1986)[1]

Speech acts are common types of utterances. Many utterances belong to a few basic speech acts. Examples are:

• Please do this for me
• I promise to do the following
• I report that I have done the following
• I want to know something
• Here is what you wanted to know

Some people claim that by marking messages with explicit speech act symbols, electronic communication can be more effective. This is a somewhat controversial area, but the speech acts can be seen as extensions to the well-known smileys (like ":-)") used in e-mail to counteract the lack of emotional cues like body language and voice inflection.

Figure 3: Travel expense account as an example of workflow through e-mail

    By workflow is meant the exchange of specially formatted messages to support a particular multi-user task. A common example is the handling of travel decisions, which has several stages:

1. The employee asks for permission to make a journey.
2. The boss approves the journey.
3. Tickets are ordered.
4. Tickets are delivered.
5. The employee submits a travel cost invoice.
6. The travel agency submits a bill.
7. The bills are paid.

In each stage, the message can have fixed fields and fixed control on who can change which fields. Different people have different roles. The roles definition control what they are allowed to do, for example who can approve a journey. The same person may use different roles at different times.

Back to table of contents

Decision support

   HTML will allow more sophisticated decision support than ordinary voting. This is needed, because it is wellknown that electronic dicussions often have a problem in achieving resolutions of items discussed.

It is wellknown from much research on the social and organisational effects of electronic mail that there are certain activities which are difficult to perform through e-mail. It is difficult to make decisions through e-mail in complex issues with many differing opinions. There is a tendency that discussions get stuck and do not advance towards results, repeating the same arguments over and over. One way of overcoming this problem is to use face-to-face meetings for the actual decisions. Face-to-face meetings, however, can be very expensive, and also have their problems. If you get a new idea, or want to check some fact, it may be too late in a face-to-face meetings. When discussing through e-mail, you have more time to think and look up facts and sleep on the issues.
    E-mail may in the future be used more for decisions, if e-mail is extended with features to aid decisions. Such a feature could involve a structured description of the issues and alternatives, maintained by the moderator and available via both e-mail and the WWW. Participatants can add their evaluations of the alternatives in the issue list, on a scale such as "very bad, bad, maybe, good, very good". They might also store how sure they are of their evaluation, on a scale from "not very sure" to "entirely convinced". The computer need not compute any decisions automatically, just summarize statistics of the opinion in the group. People should be allowed to change their already made evaluations whenever they like.
    The use of HTML forms in e-mail will make it much easier to design such features.
    One special decision task, which can be made much easier using HTML is special kinds of decisions like booking a time for a meeting. An HTML form could supply choices and participants could reply with their preferences for each of the alternative choices.
    When you fill in an HTML form, your filled in form will often be sent through e-mail, not as is common today through HTTP. Sending filled-in forms through e-mail has the advantage that you do not have to wait for evaluation, and you can send them even if the processing computer is temporarily down. Sending filled-in forms through HTTP, on the other hand, has the advantage that you get an immediate response. A disadvantage with sending filled-in forms through e-mail instead of HTTP is that it does not work very well on multi-user workstations. The reason for this is that the web browsers are designed to assume that there is a single user on each workstation, so the e-mail address of this user is stored in the preferences file of the web browser.

Back to table of contents

Not including all in a message

Sometimes you may want to send a message without including all in the message you send. The recipient will then be able to retrieve the additional information when reading the message. There is a special e-mail standard for this, called "message/external-body", but I do not think it will ever be popular. Instead, people will simply include URLs in the text of their messages, which can be done in both plain text and HTML-formatted messages.

Back to table of contents

Multipart messages

The MIME standard allows a message to consist of several different parts. The common way of using this feature today is to add one or more file attachments to messages. Attachments are listed when you read a message, but not opened until you click on them. Another, less common feature is to have so-called inline parts. An inline part is different from an attachment in that it is shown directly when you read the message. Inline parts will be more used in the future in the following cases:

• Forwarding one or more messages with a comment. You can put the entire forwarded message as one inline part, and add a comment before or after it as a separate part.
• When you send HTML, inline parts are needed for pictures, applets, etc.

Back to table of contents

Groupware

For many people, a majority of their time using e-mail is spent reading and writing group messages. By a group message is meant a message where the sender need not list the names of all the recipients. The sender just sends the message to a group, like a mailing list, where the list redistributes it to the members of the list.
    This kind of communication is called group communication. It can be done through e-mail and mailing lists, or it can be done by special groupware software, such as First Class, Lotus Notes, Web4Groups, Usenet News, etc. Such groupware software often stores the messages in a central store (which is sometimes replicated, copied, to several servers). But mailing list software often includes a so-called archive, a central store where you can find old messages sent via the list. And many modern groupware systems can be accessed through e-mail. When this is done, the groupware systems looks, to its e-mail users, the same as a mailing list system. Thus, the border between e-mail with mailing lists and groupware is getting more and more blurred. One particular groupware system is Usenet News. Particular about Usenet News is its size, with millions of users and tens of thousands of groups, and that it does not have very good support for closed groups. A closed group is a group, to which not everyone has access. Closed groups will be more common in the future, because the growth of the Internet has caused large problems with popular open groups in Usenet News: Too much is written, the quality is not high enough, people with a special zeal misuse groups (in the opinion of others).
    Since Usenet News has not very good support for closed groups, and since more and more group communication will be done in closed groups, it is possible that e-mail with mailing lists will get a increasing share of the group communication. (Another option is that Usenet News is extended to support closed groups better than today.)
    Mailing lists is one major cause of information overload in e-mail (another cause is spamming, which is discussed separetely later in this article). The reason for this is simple. People write about 10 times slower than they read. Thus, if all messages were personal messages sent to one single recipient, people would spend 90 % of their e-mail time writing and 10 % reading. This would make information overload almost impossible except for a few very popular people, to whom many other people write. If, however, a message is sent to 100 people through a mailing list, the total reading time for all the recipients will be ten times the writing time. Now, information overload can occur.
    There are many tools for handling information overload. Many of these tools are basic to groupware systems including Usenet News, but they are not today so common in e-mail. These tools are:

• Instead of putting all incoming messages in one large inbox, messages from each mailing list is put into a separate folder. The advantage with this is that the recipient can read one group at a time, and choose to read the more important groups before the less important groups. Some systems make this even easier by providing a command to read all new messages, group by group, in a priority order chosen by the user. A user with overload problems can also leave a group, or skip all discussion in a group during a certain time period.
• Messages are further organised into threads. A thread is a set of messages which are replies, directly or indirectly, to one original message. Groupware systems often provide tools for reading messages thread by thread, and for a user to skip the rest of a thread with a simple command. Many Usenet News clients have a command by which a user can not only skip existing messages from a certain thread, but also skip future, forthcoming messages from the same thread.

E-mail software will in the future much more often contain this kind of support. The problem has been that some old mail software did not send the information with a reply which is needed to know which thread it belongs to. But this is becoming less and less common. There are two ways in which a mail system can recognize that messages belong to the same thread. One of them is explicit links between messages, conveyed through In-Reply-To and References headers in the reply. The other is the Subject line. A reply usually has the same subject as the message it replies to, except that the four charcters "Re: " are added if they were not already there. In Usenet News, this is standard, but the same custom is more and more widely used also in e-mail. When a person wants to change the subject in a thread, a convention which is sometimes used is to give the new message a subject like this:
    Subject: This is the new subject (was: This is the old subject)
    A disadvantage with this convention is whether the word "was" is appropriate in a non-English message. "Subject:" and "Re " are of course also English, but an embedded English word in the middle of a sentence in another language is more confusing. The "References" header is a better way of keeping a thread together, and IETF will probably make it a standard to use this method also in e-mail, in the same way as it has been used in Usenet News.
    Some mail systems today provide filters, and filters can be used to filter, automatically, all messages from a certain mailing list to a certain folder. Filters can also be used to skip threads you are not interested in. The problem with filters is that they are too difficult to set up for many e-mail users who are not technical experts.
    Using mailing lists today is more difficult than using groupware like Usenet News. You have to know how to setup filters to sort messages from each list to a separate folder. You have to know how to recognize that a message came from a certain mailing list. You have to know the specific commands to subscribe, unsubscribe and post to each mailing list.
    Future mail software will make this much easier. The mail client will know which commands to send in order to post, subscribe and unsubscribe to different groups. It will know which e-mail addresses are mailing lists, and if you are subscribed or not to each list. It will automatically sort each mailing list to a folder. The user will be able to use commands built into the graphical user interface of the e-mail client to find a mailing list, subscribe or unsubscribe from it, post to it. Even though the actual commands sent to the mailing list software is different for different e-mail software, this will be hidden from the user. The e-mail client will translate the commands given by the user into the right command sent to each mailing list.
    If your name is Mary Smith and you write a message to a mailing list Tropical Flowers, and someone else answer to this message, the answer will usually have the following header:
    To: Mary Smith <msmith@foo.net>, Tropical Flowers <trop-flow@foo.net>
    This means that with most existing mail software today, you will get two copies of the reply, one to your personal address, one through the mailing list. In the future, you will be able to avoid this. Your mail software will know that you are a member of the list, and will send you (if you so prefer) the replies only through the mailing list.
    In the future, more e-mail software will be able to automatically recognize duplicates of the same message, and correlate them, instead of showing them twice to you as separate messages. By correlation is meant that instead of seeing two identical messages with different recipients, you will see one combined message with both recipients.
    Usenet News clients today usually have much better facilities for handling large volumes of messages than e-mail clients. In the future, e-mail clients will get many of the features which today are available in Usenet News. In fact, news and e-mail will be integrated, so that you can use the same commands for both news and mail, to perform actions like:

• Find mailing lists/newsgroups.
• Subscribe to, and unsubscribe from mailing lists/newsgroups.
• Post to mailing lists and newsgroups.
• Read new messages, one group/list at a time in your own personal priority order.
• Be able to read and skip messages by thread.
• Be able to access archives of old messages from a list/newsgroup.
• rapidly read new messages, one at a time, with just a single keyboard command to get from one to the other.

All this will make messaging software much easier to use. People who are not technical experts are not interested in the fact that Usenet News, E-mail and other groupware use different protocols. They are interested in the service of group communication, not how it works behind the scenes.

Back to table of contents

Storing and searching

More and more of the information flow is done through e-mail. The increasing use of e-mail and of mailing lists will increase the volume of information even more than today. An important part of the knowledge base of people is their personal archive of old e-mail messages. Most e-mail software today allows the sorting of messages into folders, sometimes nested folders (folders within folders).
    Future e-mail software will provide much more powerful tools to store the large volumes of information. Most people today store their messages on their personal computers. It is possible, that in the future messages shared by several people, such as mailing list messages, will be stored in common storage areas, so-called archives. More probable is that such messages will both be stored in archives and in personal folders on the personal computers of some of their members.
    Search will be more powerful. You will be able to make search commands, for example, to find all messages between October 1, 1995 and June 27, 1998, to any of the mailing lists Tropical Flowers or Tropical Insects, written by Mary Smith and containing the word "orchid".
    Some e-mail software presents the search results one at a time, other create a temporary folder with all the found messages. In the future, you will probably be able to use both alternatives. And you will have commands to print out the text of all the found messages on paper.

Back to table of contents

Purging and archiving

An important problem with large volumes of information is when and how to remove old messages. This activity is called purging. For most e-mail software, purging is a manual process, the user has to specify which messages to purge. Many users handle purging by moving older messages to special folders instead of deleting them. E-mail software of the future will make this activity more automatic. Maybe you will be able to get old messages in certain folders automatically moved to special folders for old messages.

Back to table of contents

Filters and spam control

Many e-mail systems also support filters, which can sort incoming and outgoing messages automatically into folders. Filters, however, are often difficult to set up. In the future, it will be easier to specify some very common kinds of filters, like filtering out a thread you do not want to see, or filtering a mailing list to a separate folder for that list.
    One type of filter which will be more common in the future is collaborative filtering. In collaborative filtering, data bases are stored of which messages other people liked, and these data bases can be used to filter your own messages.
    One particular area, where collaborative filtering may be the solution, is spam control. The collaborative filtering data bases will tell you which message is a spam and help you filter them out.
    The filtering needs are different in different areas, even for the same user. For your personal mail, you want one kind of filter, for messages through important mailing lists, you want another kind of filter than for messages through less important lists. For less important lists, it is acceptable for you if the filter actually deletes messages of less interest. For personal mail and important lists, it is important for you that you can trust the filter to not by mistake removing anything important. Filters will thus work different depending on how you got a message.
    Another possible solution to spam control in the future may be legislation. The international nature of the Internet makes legislation problematic - the offenders can move their activities to convenience-flag countries with less legislation. But maybe legislation will be able to solve the problem.

Back to table of contents

Deleting already sent messages

Most e-mail users will sometimes by mistake send a message to the wrong recipients, or send a message with a silly error which they afterwards want to correct. It would then be very useful to be able to delete or replace your message with a new corrected message. However, recipients may not always like if people can go into their mailboxes and delete messages or modify them.
    The solution to this problem will probably be that you cannot delete already sent messages, but you will be able to send new messages which are marked as "Supersedes" of the old message. If the recipients have not yet read the old message, they will be shown only the superseding message. But probably they will see that it has a supersedes link, and be able to use this link to see the old version if they so wish. Supersedes, however, will not be generally used in e-mail until in 2-4 years from now.
    Usenet News has a cancel command, which physically deletes old messages from the data bases. E-mail will probably not get such a powerful command. Instead, e-mail will use supersedes, and perhaps also collaborative filtering, as more soft tools to delete old messages.

Back to table of contents

Notifications

Notifications are special kinds of messages which are usually sent automatically by software and inform you of different things. Examples of notifications:

• Your message has been put into the mailbox of the recipient. This is called delivery status notification.
• Your message could not be put into the mailbox of the recipient. This is called non-delivery status notification.
• The recipient has read your message (or at least displayed its text on a screen or printed it on paper). This is called receipt notification.
• A new member has subscribed to a mailing list or a member has signed off from it.
• A person wants to become a member of a closed mailing list, which you are the moderator of, and you are asked to accept or reject this request.

You may not want to see all such notifications as separate messages. For example, you may want the software to store delivery and reciept notifications automatically when they arrive. Then when you look at a message you have sent, you can see the status of delivery for each recipients. Many mail systems have these features for intranet messages, but not for internet messages. There is however an Internet standard for notifications now, so in the next years, we will see these facilities also for Internet messages even when the sender and the recipient use different mail software.
    For notifications with requests of membership to mailing lists, you may want a command to your mailer to approve or disapprove the request, and the mail client will automatically send the right command to perform your decision.

Back to table of contents

Security

Most Internet e-mail software today provides very bad security. Some people claim that normal e-mail today has no security at all. It is, for example, very easy to write faked messages in any person's name. It is surprising that e-mail works so well in spite of the bad security.
    There are a number of ways in which strong security can be added to e-mail. Strong security uses cryphtographic methods, so that someone interecepting the communication between client and server cannot sidestep security. The most common functions which users will see in e-mail will be:

• Digital envelopes: Encryption of text so that no one except the recipient can see a message.
• Digital Authentication: Check who you are, before you can read your mail. Today, most mail systems used simple passwords for this, which is not secure against someone intercepting the communication between client and server. Strong authentication need more secure authentication methods.
• Digital signatures: Authentication that a message came from the specified sender.
• Digital seals: Checks that a message has not been modified in transit.

The most common way to provide these services uses so-called certificates. Digital signatures and seals require that you have the certificate of the sender. Digital envelopes requires the certificate of the recipient. Encryption requires that the sender and the recipient share a secret key. This secret key is often exchanged using digital enveloping based on the recipient's public key. If you have a falsified certificate or a faulty public key, the security services are not secure any more. Because of this, very important is to have secure methods of verifying that the certificates of the people you communicate with are not falsified. Only if you have securely validated certificates, do you get the high security needed. Many people put their certificates on their home pages in the WWW. Downloading such certificates using ordinary web access does not securely verify that the certificate is correct. A recipient who wants strong security, must therefore verify the correctness of the certificate in some other way.
    Many proposals have been made at different times for how to get high security in e-mail using the methods described above. The proposals are known under names like PEM (Privacy Enhanced Mail), PGP (Pretty Good Privacy), MOSS (Mime Object Security Extensions) and S/MIME. Some of these proposals have been around for a long time, but have still not become widely used. The most successful of the methods is PGP, but S/MIME may become the accepted method of secure messaging in the future. Legally, the PGP method may not be exported outside of the U.S.A., but since it is widely known and used all over the world this is more of a formality.
    The reason why PGP has been more successful is that it does not require a system of certificate authorities to distribute the certificates. The establishment of a secure such system has been a problem for the other proposals. This also means that PGP is less secure than the other proposals. Note, however, that PGP can be combined with a secure system for distributing certificates, and will then be as secure as the other proposals.
    In the next year or two, more and more mail systems will have built-in support for PGP and/or S/MIME. This means that you will be able to send encrypted messages, and give digital signatures and seals on the messages you write. This will greatly enhance security. The presently used methods can however not be used to encrypt messages which you send through mailing lists.

Back to table of contents

Word wrapping and quote marks

By word wrapping is meant how words are moved from line to line in a paragraph to give a neat display of text. Word wrapping is an area which many existing mail systems have problems with. One source of the problem is that some mail systems are based on the model that paragraphs should be split into lines before the message is sent, other systems are based on the model that paragraphs should be word wrapped immediately before display to the recipient.
    There is not going to be any consensus about this for many years to come. However, more and more mail systems will be able to cope better with both kinds of messages than they can today. Thus, the occurences when you get badly word wrapped messages will be less common in the future.
    A related problem is the common method of marking quotes by putting "> " first in each line. This method is not well supported in many current e-mail clients. They can sometimes not handle word wrapping correctly for such paragraphs, and there is also often problems if the text you are quoting is in another character set or encoding format than the text you are writing. This should not be a problem for correctly written software, and mail system developers can be expected to handle this better in the future.
    With HTML, the accepted practice is to mark quotes with the <BLOCKQUOTE TYPE=CITE> element, which is shown to users as a black line in the border to mark the quotation. All mailers today do not yet handle this well, but future mailers will.

Back to table of contents

Newsgroups header

Another difficult problem, which seems to be hard to reach a consensus on, is the meaning of the "Newsgroups" header in e-mail messages. Different systems use it in two non-compatible ways:

• To indicate that this message is a personal reply to a message in a newsgroup.
• To indicate that this message was also sent to this newsgroup.

Because this is a controversial issue, it may not be solved soon. The best a user can do is to ignore the Newsgroups header, if it appears in an e-mail message.

Back to table of contents

Character sets

If you want to send text in non-English languages, or text containing special symbols like mathematical symbols, you need richer character sets than provided by the old US-ASCII alphabet. Most mail systems today support the somewhat richer ISO 8859-1 alphabet. This alphabet is enough for most Western European countries and contains characters like Ä for German, É for French or ¿ for Spanish. It is not enough for other languages like those spoken in Eastern Europe and Asia. Some mailers today claim support for these languages, but the support does not always work very well. For example, if you quote text in one character set when you reply to a message in another character set, many of today's mail systems get it wrong. We can hope that this will improve in the future. Most mail software manufacturers are in English-speaking countries, but many of them understand that they can increase revenue and sales by supporting other languages than English.
    In a couple of years, most computers and mail software will support the Unicode or the almost identical ISO 10646 character sets. Whether this will give us better support for non-English text is something we can hope for, but not be sure of. The problem with Unicode is that it has so very many characters, that many computers will only be able to handle a subset, and if the sender and the recipient has computers supporting different subsets of Unicode, messages may be garbled.

Back to table of contents

Forwarding of messages

Very large messages

The MIME e-mail standard has a feature to send very large messages. Even if your mail system does not allow messages larger than for example one megabyte, larger messages can be split into parts in separate messages. These are automatically combined at receipt. This MIME feature is not widely supported, and it is difficult to predict whether it will become more supported in the future or not.

Back to table of contents

Millenium problem

The so-called millenium or Y2K problem with two-digit years in the twenty-first centure is not expected to be much of a problem for e-mail. Most e-mail today uses four-digit years, and the Internet e-mail standard have required four-digit years since 1989.

Back to table of contents