Results from Questionnaire on the Future of E-mail

Report on future features expected soon in e-mail based on a questionnaire to a few IETF e-mail experts

By Jacob Palme, e-mail: jpalme@dsv.su.se, at the research group for CMC (Computer Mediated Communication) in the Department of Computer and Systems Sciences at Stockholm University and KTH. Last update: 5 December 1999.

Table of contents

Summary
Who answered the questionnaire?
How did people fill in the questionnaire?
The following instructions were given in the questionnaire on how to fill it in
Table of full questionnaire results

Links

This document is available at the following URLs:
In RTF format: http://dsv.su.se/jpalme/ietf/e-mail-q-results.rtf
In HTML format: http://dsv.su.se/jpalme/ietf/e-mail-q-results.html
The original questionnarie at URL: http://dsv.su.se/jpalme/ietf/e-mail-q-questionnaire.rtf
Books about e-mail at URL: http://dsv.su.se/jpalme/e-mail-books-survey.html
More about e-mail standards at URLs: http://dsv.su.se/jpalme/e-mail-book/additions.html
More about IETF work on e-mail standards at URLs: http://dsv.su.se/jpalme/ietf/jp-ietf-home.html and http://domen.uninett.no/apps
The full paper about the future of electronic mail

Summary

A questionnaire was answered anonymously by 9 e-mail experts at two IETF meetings. The questionnaire asked which features they expected will be implemented in the next 1-4 years in e-mail software.

One can conclude that the following features will soon (in one year or less) be implemented in those e-mail systems which do not already support them: Commands to scan threads (find from a given message which message it is a reply to, and which messages are replies to it), the ISO 10646 or Unicode character sets, messages in html and text/enriched formats (allowing richer formatting and graphics in messages), forwarding of incoming messages as separate body parts, showing separate body parts inline and not only as attachments, sending collections of e-mail messages as digests, security features (encryption, digital signatures, digital seals) using PGP (but not PEM or MOSS, unfortunately I forgot to include SMINE in the questionnaire), better support for folders, receipt notifications (senders are told if their messages have been read) and combined clients for e-mail and netnews.

The following features will probably be supported in 2-4 years from now: Supersedes links between messages, alternate versions of the same text in different formats, better search facilities and delivery notifications (senders are told if their messages have been delivered).

Some existing mailers split paragraphs into lines before sending them, others send each paragraph as one long line. This difference between mailers will continue, but future mailers will better be able to cope with incoming messages in either of these two formats. (My guess is that sending paragraphs as one long line will ultimately win, since the main reason against it is that some mailers cannot handle incoming such messages very good today. It has the obvious advantage that the ugly effect of lines being split more than once will disappear.)

It is interesting to note that even though delivery notifications have had an IETF standard since the beginning of 1996, while the receipt notification standard will be ready in the end of 1997, implementors say they will implement support for receipt notifications earlier than for delivery notifications. The reason for this is that many existing mailers already support receipt notifications in non-standard ways (only between mailers of the same type). Some did maybe answer the questionnaire by describing non-standard and not standard receipt notifications.

Who answered the questionnaire?

On the IETF meetings in April and August 1997 I distributed a questionnaire on which e-mail features exists today or were expected in the future. The questionnaire was distributed during meetings with the DRUMS IETF Working Group, a group working on the e-mail standards. The questionnaire was filled in by 9 e-mail experts. Four of these said that they were currently developers of e-mail or netnews software, three were not, two did not say.

How did people fill in the questionnaire?

When the result table below shows less than 9 answers, this is probably because some people answering the questionnaire were not sure and therefore did not fill in a prediction for this feature. It can also be because some respondents only answered what was in their committed plans for new products, while most respondents guessed at features later in the future, for which final decisions have not been taken yet.

The following instructions were given in the questionnaire on how to fill it in

Please fill in this form and give it to me or put it on a chair by the door after the end of DRUMS or MHTML working group meetings. The results will be computed and reported in a document available on the web. I will send a short note with the URL of the report to the mailing lists mailext@list.cren.net, drums@cs.utk.edu and ietf@cnri.reston.va.us. No individual replies will be reported, only statistics. I will not divulge to anyone what each person answered on this questionnaire. Your reply will not be interpreted as any promise to develop this function, just a guess what you believe will happen. The questionnaire is mainly oriented towards user functions, not towards functions only visible to technical experts. If you filled in this form and gave it to me at the April meeting, you need not do it again now during the August meeting. Notes on how to fill in the questionnaire:

If you do not like or want a feature, mark it as > 5 years or never.

Table of full questionnaire results

Technical basis User feature

Is/will be available within

No.

Today

1 year

3 years

5 years

> 5 or never

From: + Sender:

Facility to send what someone else has written

6

 

1

 

1

1

Millennium problem

Four-digit years

7

 

 

 

 

2

Bcc:

Each Bcc recipient is shown only to that recipient himself

4

 

 

 

3

3

(two implementation choices)

The list of Bcc recipients is shown only to all the Bcc recipients

1

 

 

 

6

4

Message-ID:

Generate globally unique Message-ID for all messages

8

 

 

 

 

5

Add Message-ID for relayed messages which lack it (controversial)

3

 

 

 

3

6

Use Message-ID to find, at receipt, duplicates of the same message

2

1

1

 

3

7

In-Reply-To:, References:

Commands to scan thread up and down, i.e. find replied-to and replying messages easily

3

3

3

 

 

8

Supersedes:

Generate Superseding messages

 

2

1

2

1

9

Help user who receives Superseding messages in a suitable way

 

2

1

2

1

10

Keywords:

Search facility to find messages with a certain keyword

6

1

 

 

1

11

charset=iso-8859-1

Facility to send in this format

7

 

 

1

 

12

(Western Europe)

Facility to receive and display it

7

 

 

1

 

13

charset=iso-8859-2

Facility to send in this format

6

1

 

1

 

14

(Eastern Europe)

Facility to receive and display it

6

1

 

1

 

15

ISO 10646=Unicode

Facility to send in this format

2

3

2

1

 

16

character set

Facility to receive and display it

2

3

2

1

 

17

Other character sets like Cyrillic,

Facility to send in this format

5

2

 

1

1

16

Hebrew, Arabic, Japanese

Facility to receive and display it

5

2

 

1

1

17

MIME header encoding

Facility to handle other than US-ASCII in message headers

7

2

 

 

 

18

text/enriched

Facility to send in this format

4

2

 

 

2

19

Facility to receive and display it

6

1

 

 

1

20

message/rfc822

Facility to forward in a body part in this format

4

3

 

 

 

21

Facility to receive and display it

5

2

 

 

 

22

message/partial

Facility to send large messages in this format

2

2

1

 

1

23

Facility to receive and combine parts

2

2

1

 

1

24

message/external

Facility to send in this format

2

5

 

 

 

25

Facility to receive and display it so that the recipient can easily read the full message

2

5

1

 

 

26

Content-Disposition

Can set "inline" or "attachment" on body parts in sent message

4

4

 

 

 

27

multipart combined with

Facility to send in this format

4

3

 

 

 

28

content-disposition: inline

Facility to display parts "inline" for text bodies

4

4

 

 

 

29

Facility to display parts "inline" for image (picture) bodies

3

5

1

 

 

30

multipart combined with

Facility to send in this format

6

1

 

 

 

31

content-disposition: attachment

Attachment only shown at request

6

1

 

 

 

32

multipart/digest

Facility to send in this format

1

4

1

 

 

33

Facility to read all in sequence

1

4

 

 

 

34

Read each part as a separate message

3

3

1

 

 

35

multipart/alternative

Use when sending messages in formats all recipients cannot display, such as text/enriched or text/html

3

3

1

 

 

36

Receive and show only best alternative

3

2

2

 

 

37

application/msword, /rtf, etc.

Facility to send in this format

4

 

 

 

3

38

Facility to receive and display it (may be by forwarding it to a suitable helper, user can configure the list of helpers)

5

 

 

 

2

39

Multipart/related & Text/html

Facility to send in this format

1

5

 

 

1

40

Facility to receive and display it, also when the HTML-message contains inline links to other body parts

2

5

 

 

1

41

Authentication of sender

Using PGP

4

3

 

 

1

42

Using PEM or MOSS

 

1

1

1

4

43

Encryption of message text

Using PGP

3

3

 

 

1

44

Using PEM or MOSS

 

1

1

1

4

45

Electronic seal (protection against

Using PGP

4

3

 

 

1

46

modification in transit)

Using PEM or MOSS

 

1

1

1

4

47

Forwarding

Using Resent-headers

3

 

 

1

4

48

Using MIME encapsulation

5

1

1

 

1

49

Filtering and folders

Messages from a particular mailing list can be filtered into a particular folder

8

1

 

 

 

50

"Kill file", command to say "I do not want to read any more messages on this topic within this folder (mailing list)".

5

2

 

1

1

51

Command to scan through all new messages, even though they have been filtered into separate folders

3

4

1

 

1

52

Ability to designate the personally preferred order in which folders with new messages are scanned

1

4

1

 

1

53

Spam control

 

5

2

 

1

54

Search

Facility to search through some or all folders to find messages

7

 

 

 

 

55

- on words in the subject

7

2

 

 

 

56

- on words in the body

6

3

 

 

 

57

- on date

5

2

1

 

 

58

- on from/sender/to/cc/bcc headers

6

2

1

 

 

59

- on seen/unseen status

5

2

1

 

 

60

Combinations of the above, such as "all messages from A between Date-X and Date Y with the subject Z"

4

1

1

1

 

61

- search result shown, saved or printed all matches in one file

3

4

1

1

 

62

- search result shown one at a time

6

1

 

1

1

63

Encoding

Sending in Base64 or Quoted-printable

9

9

 

 

 

64

Receipt of Base64 and Quoted-printable

9

9

 

 

 

65

Word-wrapping

Outgoing text is wordwrapped with max. 80 characters/line

5

 

 

 

2

66

Outgoing text is sent with each paragraph as one long line (using MIME encoding of long lines)

4

 

 

 

2

67

Word-wrapping of incoming text if more characters in a line than fits in the window

7

 

 

 

1

68

Reply with "> " quote marks, which works also when incoming message had the quoted paragraph as one long line

 

7

 

1

1

69

Delivery Status Notification

Ability to request it

2

2

1

 

3

70

Ability to receive them and show them in user-friendly way

2

2

2

 

2

71

Ability to ask for a report on all notifications received for a particular sent message

 

2

3

 

3

72

Receipt Notification

Ability to request it

5

1

1

 

2

73

Ability to receive them and show them in user-friendly way

4

2

1

 

2

74

Ability to ask for a report on all notifications received for a particular sent message

1

3

2

 

3

75

POP, IMAP, NNTP

Can download messages for local browsing in the user workstation

8

1

 

 

 

76

NNTP & e-mail

Same client can be used both for sending and reading e-mail and sending and receiving newsgroups

4

2

 

 

1

77

Same user interface for newsgroups as for mailing lists

3

2

1

 

2

78

When a newsgroup article is forwarded as e-mail, change "Newsgroups" header to "Posted-To".

 

1

2

 

4

79

Any comments on the questionnaire or features I should have included but did not include?

Several respondents commented that SMIME should have been included in the questionnaire.