Note: This document was published in 1995 and appears here for historical purposes. Information contained in this document is likely out of date, incomplete and references information that may not exist at the URL specified. The report was commissioned by the Committee of Australian University Directors of Information Technology. The original document was lost and the text below is a recreation from various sources.
This report was created to address the issue of document exchange using Electronic Mail or Email. This report describes the processes required to transfer a document from sender to recipient and the translation that may occur after the transfer.
When a document is exchanged using Email, the document is encoded on the senders' machine, attached to an Email message and transferred to the recipient. The Email message is decoded and the attachment is saved on the recipient's machine. After translation, the document is available to the recipient.
The main problem experienced by Email users is the lack of an automatic process to detect and decode the attachment. The "MIME" standard has been developed to enable automatic detection of attachment encoding types. This report will recommend that MIME is adopted amongst CAUDIT members.
A secondary problem is the difficulty encountered when translating a document between different application file formats. This report will recommend that documents are transferred in their native file format and translation is undertaken at the recipient's end.
Many users may be familiar with translating documents from one application to another but most have trouble identifying the encoding standard used in a particular Email message. If the automatic decoding used in their Email package fails, users are at a loss to understand what has happened and how they can resolve it. Most of these problems could be solved by adequate training for users.
This report could not have been completed without the assistance of the following people: Des Thornton, Ian Hill, Jo Winship, John Winship, Mark McInerney, Rob Phillips, Rod Kevill, Steve Maddocks, the Internet community and support people from around Australia.
A special note to Nick Jenkins who patiently explained the use of the English language.
This report was written to address the problems associated with the exchange of information using Electronic Mail (Email). The report deals with the mechanisms in use around the world for information exchange using Email, the compatibility of those mechanisms, problems encountered when using them, as well as future developments.
1.1 What is in this report?
This report describes the processes and procedures necessary for document transfer using Electronic Mail (Email) on the Internet. This report investigates the most effective way of exchanging a binary document between two people.
The scope of the report is limited to Email transfer only. The issue of verifying the accuracy of the exchange between word processors and spreadsheets by different vendors is too complex to be covered in the time set for this report.
The report covers the file formats in use for the various platforms and the encoding standards developed to overcome their respective idiosyncrasies with respect to the transfer of binary documents across the Internet.
The decoding stage of the transfer and methods for standardising the transfer and the automatic decoding of an attached document are described. The translation between various applications and platforms is addressed from the perspective of both sender and recipient.
Alternative delivery methodologies that the Internet offers are described.
Implementation issues, such as cost and training are addressed.
The most common method of information exchange across the Internet is Electronic Mail or Email. A message containing unformatted text can be transmitted across all Email platforms. Simple messages can easily be sent from one person to another without any complicated formatting.
Email was designed specifically to send simple text messages, all other enhancements have been added onto the existing system. When more complicated information needs to be exchanged, for example a word processed document, spreadsheet, picture, sound, video, etc, the Email system needs to encode information. An Email message that contains such an encoded piece of information is said to contain an attachment or enclosure.
A document is attached to an Email message using an encoding scheme; the message, (including the attachment) is sent to the recipient and the attachment decoded on arrival.
The encoding and decoding schemes used are mostly platform dependent because of different internal storage methods for the various operating systems. Standards exist for the most common encoding schemes.
After a document is successfully transferred between systems the format of the document becomes an issue. If the applications used by sender and recipient are different, the document needs to be translated from one application format to the another. This report does not in any way describe the process of the actual transmission across the Internet.
When a document is attached to an Email message, a complex process comes into play. The mail program reads the document and encodes it. The result of attaching a document to the Email message is that the message contains the text that's being sent as well as a copy of the encoded document that's attached (referred to in this report as "the attachment").
The Email message containing the attachment is then sent to the recipient through a number of local and/or remote gateways. Finally it is received in by the recipient's mail system. The recipient's mail program then reads the Email message and attempts to decode the message. After decoding the attachment, the recipient should have an identical copy of the sender's document.
The process of attaching a document should be invisible to both sender and recipient. The encoding and decoding of attachments would not be a problem if everybody used the same Email package to send and receive mail.
Although the actual transfer of documents across the Internet is mostly platform independent, the successful decoding of an attachment on the recipient's computer depends on the method used to encode the document. Encoding schemes have been developed to address specific issues related to the various platforms.
There are many more platforms connected to the Internet than the three documented below. Within Australian Universities however, the following three are the most prevalent.
Macintosh files contain a resource fork and a data fork. In the case of most document files, the resource fork is empty and the data fork contains the information that makes up the document.
The Macintosh resource fork is normally only used in application programs, where it contains the programming code, icons, etc.
In addition to the presence of the two different forks, every file on a Macintosh contains a Type and Creator mnemonic. This makes it possible for the operating system to work out what sort of file it is (a plain text document, an application, an Excel spreadsheet, etc.). Examples of the Type and Creator mnemonic are (MSWD-WDBN) for a Word 5.1a document and (XCEL-XLS4) for an Excel 4 spreadsheet.
Because the Macintosh is the only system that uses this file format, information is generally lost when files created on the Macintosh are used on other platforms.
In the case of PC files, there is no difference between documents and applications in the way the data is stored. The file extension of a file does not mean different formatting; it just helps to identify the file type.
Extensions are informally used to describe the contents. Examples are ".doc" for Word documents, ".xls" for Excel spreadsheets. (More details are given in Appendix C .) Extensions are used as a naming convention only and have nothing to do with the actual physical format of the file.
Files stored on a Unix system contain similar information to that contained within IBM PC compatible machines.
The extensions used on a Unix system are just as standardised as those in use in the PC world. As with PC's, extensions are used as a naming convention only and have nothing to do with the actual physical format of the file.
The limitations for the transmission of information across the Internet are mostly of historical origin.
Some links, gateways and Email systems on the Internet are only capable of faithfully relaying 7 bit data. This means that if an Email message containing an 8 bit byte was sent across the Internet without any precautions, the information could get lost, garbled or even disrupt the mail system.
A number of encoding standards are used to exchange information across the Internet. ASCII, UUENCODE, BINHEX and MIME are the most common.
The characters used in a word processing document use a standard called ASCII (American Standard Code for Information Interchange, pronounced "as-ski"). An example is the letter "A" that has the byte value 65. Only the first 128 byte values, or 7 bits out of an 8 bit byte are used. The other 128 have different meanings on different systems. An example is the value 229. On the Macintosh it looks like this: "Â". The same value on the PC looks like this: "╣".
An advantage that ASCII has over all encoding schemes is that it is widely used across the Internet. All recipients can read the alpha-numeric text, but formatting information cannot easily be sent.
ASCII is used across all Email systems and is the basis of the vast majority of encoding standards across the Internet.
UUENCODE (pronounced "you you encode") was created in the Unix environment. It encodes the 8 bit bytes in a document into 7 bit bytes. In the case of PC and Unix files, no information is lost. However, in the case of Macintosh files, the resource fork is lost, as well as the Type and Creator information.
There are some exceptions to this, where Email gateways preserve Macintosh resource and data forks as well as Type and Creator information, even where the attachment is UUENCODEd. An example of this type of mail handling is the QuickMail Internet gateway.
UUENCODE is supported by all Unix systems, a large number of PC Email programs and some Macintosh Email programs.
UUENCODE was developed by Unix programmers and has been adopted by others. It has never been made into a standard and several incompatible versions of UUENCODE exist.
The BINHEX (pronounced "bin heks") standard was specifically created for Macintosh computers. It retains both the data and resource forks, as well as the Type and Creator of a Macintosh file. A PC file can also be BINHEXed without loss of information.
BINHEX is supported by a large number of PC and Macintosh Email programs, but support in the UNIX area is limited.
BINHEX was developed by Apple Computer and has been adopted in the Apple Macintosh developer community. It has not been ratified as an international standard.
MIME, the Multi-purpose Internet Mail Extensions, is a freely available specification that offers a way to interchange text in languages with different character sets, and multimedia Email among many different computer systems that use Internet mail standards.
MIME supports not only several pre-defined types of non-textual message content, such as uLaw audio, GIF image files, and PostScript programs, but also permits definition of custom types of message parts.
The ability to create Email messages with audio and other non-textual content has been available for some time, but usually as part of a vendor-specific solution. For example both Macintosh QuickMail and Sun Mailtool users each have the ability to exchange audio and video attachments. However, a Mailtool user cannot read a QuickMail video attachment or vice versa.
MIME was carefully designed to survive many of the most bizarre variations of mail transport protocols, some of which transform, modify and delete (parts of) the headers and bodies of Email messages.
A major problem with transferring attachments is that mail programs do not have a common standard for describing the beginning, the end, the document type and the encoding standard used. MIME solves this problem by defining standard header types describing Email message content-parts. A further description of decoding of Email messages is found in section 2.3.2.
A MIME Email message could contain a text part, a PostScript part and a Microsoft Word part. Each recipient would be able to extract the part that they could use. All other standards only provide a method to exchange one type of document. If one recipient of a message has access to an ASCII-terminal, but has a PostScript printer, they would be able to print the document in the original format. If only the text was important, they could read the text part.
An advantage of MIME is that it is an extensible encoding standard.
Encoding standards assume that the recipient's mail program is capable of automatically decoding the information when it arrives in their mailbox.
Some mail packages can decode and save BINHEXed attachments automatically, others can decode and save both UUENCODEd and BINHEXed information.
Incompatibilities exist between mail programs in the method used to describe the attachment type and its encoding standard. An Email message contains a header and a body. The header describes where the message came from, what the subject is, etc. It also describes the content type of the message. There is no single standard to describe the content type. Mail programs need to make educated guesses at the encoding method used. Normally human intervention can point at the encoding standard used, but most mail packages do not allow the user to manually decode the message using a particular standard.
The recipient of an Email message that was not decoded successfully needs to extract, or save the contents of the mail attachment as a file on their machine and then use the appropriate program to decode the information. One example for Unix, Macintosh, PC platforms is Mpack.
If a document is BINHEXed on a PC and then decoded using a Macintosh, the decoded file will still be without either type and creator information or resource fork, since this did not exist at the time the document was encoded.
Another approach to decoding Email attachments encoded with different standards is to use a system-wide decoding utility, such as Emil.
Emil, a program created by the Swedish University Network, is a Unix based solution that allows for translation of Email messages to and from many encoding standards. When installed it can operate as a command line tool, or it can become part of the mail-server's operation, ensuring that all messages sent from that host are encoded using a particular standard.
EMIL can be used as a tool to convert messages to and from any given standard.
It should be noted that developments on the World Wide Web are rapidly making this solution obsolete.
Similar in function to Emil, this product is installed on a central Unix Email system and converts Email and attachments as it arrives.
Each user is set up with an address book entry containing their application details, such as Wordprocessor, Spreadsheet and Email package used. Based on the application suite available on the recipients machine, Compatibility Server will translate files from one format to another.
This product was released on November 20th, 1995 and has currently not been tested.
After document is encoded, attached and sent across the Internet, it arrives on the recipient's computer, where it is detached and decoded. When this process is successfully completed, an identical copy of the authored document exists on the recipient's computer.
Following a successful transfer between systems the format of the document becomes an issue. If the applications used by sender and recipient are different, a document needs to be translated from one format to the other.
An example of document transfer is the use of packages like Microsoft Word 6 for Windows, which is able to save documents in Macintosh Word 5 format. Word 5 is unable to read documents of this type if they contain embedded objects like graphics or spreadsheet-tables.
This report ignores the actual document sent and assumes that the word processors and spreadsheet programs, used by both sender and recipient, are capable of reading multiple formats. For example, Microsoft Word is capable of reading WordPerfect files and vice versa.
Initial studies examined RTF for word processing and WKS and SYLK for spreadsheets as a means of standardising information exchange between packages. With the continual modification of the standards, it is very difficult for software manufacturers to reliably create software to translate RTF and WKS, therefore this is not a recommended solution. For example, Microsoft has updated the RTF solution several times and various software developers are unable to keep up with the changes. The WKS and SYLK formats do not cover extended features, such as buttons in spreadsheets, borders, document links, etc.
Another aspect of the translation of documents to an intermediate format is that neither author, nor reader has control over the translation process. At best the author will be able to read the intermediate format and compare visually the differences, at worst the conversion the author sees may not be the conversion the reader sees.
A better approach is to utilise a binary transfer of the author's document and let the reader choose to use a conversion tool, or to acquire the application that the author used.
To enable the recipient to read the contents of a document prepared by another application other than the one used by the author, involves the successful translation of the document by the recipients application.
For example, the two most popular word processing packages, Microsoft Word and WordPerfect, available on both IBM and Macintosh platforms, are capable of reading each other's document formats.
All comments made about word processors in this section are applicable to documents saved by spreadsheet programs and other applications.
Send a Microsoft Word document and let the WordPerfect user translate it.
The Author creates the document in Microsoft Word and sends a copy of the document to the WordPerfect user. The WordPerfect application needs to translate the document using translators available within WordPerfect.
The translation happens on the recipient's system.
This is by far the best option. It allows users to have access to the original document at the time of receipt. If the recipient's software is unable to read the document, they still have the option to purchase the software used by the sender to have full access to the content of the document.
Translate the Microsoft Word document to WordPerfect and send it.
The Author creates the document in Microsoft Word and saves a copy from within Word as a WordPerfect file. The WordPerfect user can read the document without translation.
The translation happens on the sender's system.
This method allows for the recipient to read the document in their own format, however, the WordPerfect document saved is not a WordPerfect document. It is a document created by Microsoft Word, attempting to convert its internal format to that used by WordPerfect.
The biggest disadvantage of this method is that the original document information is lost before the document is sent. There are also incompatibilities between Microsoft Word's implementation of WordPerfect files. This method also assumes that the sender has prior knowledge of the word processing application that the recipient uses.
Translate the Word document to an intermediate standard, send it and let the WordPerfect user translate it.
The Author creates the document in Microsoft Word and saves a copy in the intermediate standard from within Word (for example RTF). The recipient then reads the intermediate file and translates it into WordPerfect.
Two translations occur, one on the sender's and one on the recipient's system.
At first glance this method seems the best solution. Each application developer could read and write their documents in this intermediate standard and for most purposes it should be the best solution.
Finding an intermediate standard that supports all document features without loss of information is a large problem. Each translation, either to the intermediate standard, or from the intermediate standard may involve loss of document attributes.
As soon as a new version of an application appears, the standard will have to be revised. A further description of the intermediate standards, RTF, SYLK and WKS is found below in section 2.4.1.1.
An Internet development called HTML, described in section 2.5.2.2, addresses this problem from a different perspective.
Few solutions exist to translate a document into an intermediate format to enable another application to read the content. For word processing, one standard is called RTF. For spreadsheets, two common standards are SYLK and WKS.
RTF, or Rich Text Format was designed by Microsoft as a solution to exchange information between the various versions of Microsoft Word. Other application developers have implemented the ability to save documents in this format.
RTF has seen numerous enhancements and version changes. It is not a standard, but rather a solution to a problem which Microsoft had transferring documents from one version of Word to another version.
The RTF solution is not a viable one as a recommendation for exchanging documents. It has never been ratified as a standard and can only be viewed as a Microsoft proprietary solution.
From a historic perspective the available interchange formats for spreadsheets are: SYLK and WKS.
VisiCalc and Lotus 1-2-3, the world's first two spreadsheet programs, could exchange documents using these SYLK and WKS. Today's Microsoft Excel also has the ability to read and write these formats.
Functionality in the first generation of spreadsheet programs is far removed from current implementations. Graphs, Buttons, Borders, Links and other enhancements are not covered by these formats so they are no longer appropriate.
When transferring documents across a network, size of the document is relevant to some extent. Compression algorithms exist to reduce the size of the transmitted document.
Many users will compress their attachments using compression tools, such as PKZip, and StuffIt. These documents are transferred across the mail system as any attachment.
At the recipient's end a document needs to be decoded, decompressed and perhaps translated for a successful transfer of the document.
Compressing a document before attaching it to an Email message adds one layer of complexity to the attachment decoding.
Developments on the Internet allow for other means of exchanging documents electronically. The oldest standard is FTP, but developments since the 1991 introduction of the World Wide Web or WWW, have moved the Internet into a much friendlier environment to exchange information.
The basic difference between Email and the methods described below is that Email arrives on the recipients desktop without their intervention. The methods described below, FTP and WWW, ask that the recipient retrieves the message at their leisure.
FTP and WWW are easy to ignore - Email is not.
Email security is based with the recipient - FTP and WWW security with the sender.
As a result, Memo's should be sent via Email, but reports can be distributed using FTP and WWW.
When a document is transferred using Electronic Mail, an encoded copy of the document is sent across the Internet to all recipients of the message. Another possibility is to make a copy of the document available without having to worry about the conversion in the Email package.
FTP, or File Transfer Protocol, allows for users to log into a remote machine and retrieve a document from that machine. The transfer should be made as a binary file and both parties, the author and the reader, will have an identical copy of the document.
Every reader needs to retrieve a copy of the document. If the author is sending a document to a mailing list, one person has to do the task of attaching and sending, once. Using FTP, every reader on the list will have to retrieve the document separately.
In addition, each recipient may have to be issued with a Username and Password to ensure the privacy of the document.
When making Macintosh documents available for FTP from a non-Macintosh platform, the document needs to be encoded to maintain the data and resource-fork integrity. There are two encoding schemes available to do this, BINHEX and MacBinary.
This method of exchanging information is much like when the postman leaves a note in a mailbox saying that there is a package to be collected at the post office. The recipient walks to the post office, where they receive the package.
When a document is exchanged using either Email or FTP, the document ends up on the recipient's computer. An alternative is to only view a copy of the document, leaving the original located on a server at the Author's site. The Internet is ideal for this method of exchange.
An implementation of this publishing mechanism is called the World Wide Web or WWW.
The WWW is an Internet client-server Hypertext distributed information retrieval system which originated from the CERN High-Energy Physics laboratories in Geneva, Switzerland.
Client programs or browsers, such as Netscape, Mosaic or Lynx, run on the user's computer. They provide two basic navigation operations: to follow a link, or to send a query to a server.
Electronic Mail works with a method called "Store and Forward". If the recipients machine is not available at the time that a person is sending mail, the message gets stored and forwarded at a later time. However, FTP and the Web need to have direct connection at the time of retrieval. If either sender or recipient lives at the end of a telephone connection, these exchange methods might not be a solution.
If an Author chooses to distribute the information contained in their document using either FTP or the World Wide Web, the recipient will have to copy and paste the location information for the document into their web browser.
However with the continuing development of smarter and smarter software, a new trend seems to be developing. If a reader clicks on a URL (A Uniform Resource Locater: a method of describing the type of service, the location of the service and the location of the document on the service) in the middle of the document they are reading, the application will launch a Web browser and go to that location.
The latest beta version of Netscape, 2.0b2 includes a MIME compliant mail program. All URLs mentioned in Email stored with Netscape become click-able links.
This means that the major disadvantage of using the Web or FTP as a distribution method disappears. Since the reader will already have to click or select the attachment, there is no reason why that attachment could not still be on the author's machine - provided that Username and Password access has been given since most documents are not for public access.
Applications create documents with contents. Each application stores the content in a proprietary internal format. Each internal format is different. Translation between formats is a problem. Solutions for intermediate formats are further described in section 2.4.1.1.
A different approach to the problem has been created with the advent of the World Wide Web and the language to describe documents on the WWW, called HTML, or Hyper-Text Markup Language. A document is described using a standard document description language, readable by numerous browsers. Documents on the WWW become containers for other documents of any electronic type imaginable.
A quick look at any given web server will show a text based document with links to other web documents, support for different character sets for different languages, embedded graphics, links to other services such as mail, News, FTP, Gopher, embedded sounds, video and so-on.
Currently there are few mail programs available that are able to read HTML documents. There are no word-processors available to author HTML documents. HTML can at the moment only easily be created in either a programming environment or as part of an automatic conversion process. Several applications exist to convert RTF (Rich-Text-Format) documents to HTML.
There are no conversion problems with images, sound and video, since the Web browser takes care of this. However, World Wide Web because documents are viewed using a browser, each reader will have a slightly different view of the same document. A browser is created for every type of machine, including some fledgling developments for hand held devices, such as the Apple Newton. The systems used are disparate. For example, the Newton does not have colour, a Unix text terminal does not have graphics.
Depending on the implementation of the browser, different views of the same document may not be a problem where the content is more important than how many words are viewed on a line.
All universities in Australia were asked a number of questions about Email on their campus. Below are the results of the survey.
Although nearly half of the surveyed population has access to Email, only a quarter actually uses the facilities. (A survey within Curtin shows that the general response is: "I don't need Email for my work.") Education and Training will increase the number of Email users in this area.
See Appendix B for more details.
To move toward a MIME based mailing solution means to change the way things are done currently. The physical costs will be limited to the purchase of MIME compliant software and in most cases that will be free.
However, hidden costs of training and support will initially increase to then taper off and eventually decrease to a level below the one currently incurred.
Below is a summary of the conversion that users would need to make. On the left is a column of current Email solutions and on the right the suggested migration to a MIME compliant Email solution.
Finding software tools to resolve the problem of sending electronic documents across Email systems is only one part of the solution. At present most mail systems do their job adequately. There are still times when even the best software is confronted with a problem that it cannot solve without intervention from a human user.
If an inexperienced user with the correct tools and installation is confronted with an unexpected difficulty related to an attachment in an Email message, technical assistance to that user will be necessary.
As long as a user is made aware of the issues involved in getting a document from sender to receiver, a majority of the problems will disappear.
At Curtin the Computing Centre has been running a series of training seminars. Each seminar takes two hours and covers the basics of Electronic Mail use, the addressing, the concepts and attachments. A session is attended typically by 10 to 20 staff and post graduate students. There is no cost to attendee's, however budget needs to be allocated to cover trainers and facilities.
Support for Email at present is mostly concerned with the decoding of messages and the translation. Questions about encoding standards have to be answered and central directory services need to be maintained.
The recommendations set out in this report reduce some support issues. Initially there will be increased load, but after training has been completed, decoding should become less of an issue. Encoding standards questions will reduce.
However, the translation issues will remain. The maintenance of central directory services will increase because of the increased use of Email.
The recommendations set out in this report are changing as new developments become available. A new SMTP server based solution called "Compatibility Server" was announced on November 20, 1995. It purports to decode, translate and re-code on the fly to specific user set up needs.
Email and its current use will evolve into a more integrated communications solution to allow central directory services, calendar with scheduling facilities and platform independent viewing of documents.
MIME is the only Email encoding standard that has been ratifies by the Internet community. It is extensible and used not only in Email transfers, but is widely used on the WWW. More and more MIME tools are becoming available and as such this standard will be used well into the next decade.
The recommendation for exchange of electronic documents through Email is to use MIME as the method of attaching documents to Email messages.
Users who are using personal computers to initiate terminal sessions on central Unix and VMS computers should use Eudora or Pegasus mail to POP mail off the central mail system. Users using QuickMail and Microsoft Mail will need to use EMIL until the Internet gateways for those products are MIME compliant.
Experiments show that there are problems with the Macintosh Pegasus Mail implementation of MIME and currently it is not recommended as a MIME compliant mail solution.
When sending an Email message, attach only one document to the message. This ensures that a manual decode will be much easier to complete if the recipients mail package is unable to decode the attachment.
This message contains a Word 5.1a document that has been stuffed (.sit) and sent as a MIME attachment. It is formatted for use on a LaserWriter, with A4 paper.
Documents attached to this Email are Macintosh Word 5.1a and Excel 5 formatted for A4 LaserWriters.
predominant character set encoding of present-day computers.
".hqx" usually indicates a BINHEX format file.
contains any information that an application wishes to store.
digitised images, defined in 1987 by CompuServe.
text file, sound, image, submenu or other Gopher object type.
host                The name of a computer on the Internet.
to encode binary data into base 64 using a subset of ASCII.
deal with a given part.
decentralised information utility in existence.
having to recompile the source-code.
sendmail            A Unix program that sends mail between hosts on the Internet.
(the Tape ARchiver) and then compressing the result.
associated with its creating program.
the intensity of the sound pressure wave at that instant.
used. The encoding may be linear, logarithmic or ulaw.
Email and posting to USENET newsgroups etc.
CERN High-Energy Physics laboratories in Geneva, Switzerland.
used to transfer hyper-text documents.
A survey of Email packages in use was conducted among the Universities. This followed on from the survey conducted by Mike Steel, Information Technology Manager of University of Western Sydney.
The survey asked people on the CAUDIT mailing list, the User-services list and the Curtin support list a number of questions about mail used in their organisation. There were responses covering 25 organisations. In those organisations, 15 different packages were used.
Questions were asked about the size of the organisation, the number of staff, students and post-graduate students. Respondents were asked how much of the population had access to Email and how many people actually used it.
Of the people working and/or studying in those organisations, 49% has access to Email and 22% actually use it regularly. Most responses expect a growing usage and greater access in the future.
The respondents were asked to supply information about each mail package used in their organisation, the capabilities of those packages and whether it could deal with text, UUENCODE, BINHEX, MIME and other attachment types.
The most frequently named application was Eudora (76% of organisations use it) which is available for both Macintosh and PC and comes in a Public Domain version and also in a Commercial version. The Public Domain version handles the BINHEX and MIME encoding schemes and apart from some user-interface enhancements the only addition to the commercial version is the handling of UUENCODEd attachments.
The package with the most users was Elm. It covers more than 26% of users, followed by Eudora (20%) and Pegasus Mail (19%). Elm is used on Unix machines and the latest versions are MIME compliant with helper applications, and can also handle UUENCODEd attachments. Elm is available in the Public Domain.
The other two most used and named applications were Pegasus Mail and PINE (14%). Pegasus Mail is available for DOS, Windows and Macintosh. PINE is available for Unix and VMS. Both support MIME and UUENCODE. In addition, Pegasus Mail supports BINHEX. Both are available in the Public Domain. Pegasus Mail's author sells the manual to cover development costs.
60% of total responses mentioned Elm, Pegasus Mail, Eudora and PINE and these were used by 80% of the population.
A large number of people using Email on Unix and VMS systems are not able to read Word or Excel documents. This means, that even if the attachment is successfully decoded, it's still unreadable for users of those systems.
45% of respondents were using a personal computer to read mail. 53% were using some kind of terminal based service on either Unix or VMS.
A trial was conducted in two stages.
The first stage incorporated extensive testing in the user-services area of the Curtin Computing Centre. Users moved to MIME compliant mail packages, including Macintosh and PC versions of Eudora, Mailtool, Elm and PINE.
The trial showed that compatibility between Word 5.1a for the Macintosh and Word 6 was an issue. MIME attachments were decoded with no problems.
Pegasus Mail for the Macintosh claims to be MIME compliant, but currently only sends MIME messages. It is unable to decode the MIME attachment.
Single MIME users in a non-MIME environment have continual compatibility problems with mail packages which are not able to decode MIME attachments.
List servers will have to be configured to enable MIME headers. A message can be sent to members of the list that is not recognised as MIME by the mail programme.
The trial results reflect the complex nature of testing Email packages. Users had little problem once their mailer was configured for MIME use. A much larger aspect of the trial reflects associated issues, such as compatibility with printers and software. These issues fall outside the scope of this report.
"I received this PageMaker document, but I couldn't open it in Word."
Results show that if the mailer used is MIME compliant, the message came through in most cases. Some users showed that if the mail attachment was large, their mail platform had problems. This is more a set-up issue than one of compatibility.
The trial showed as a side effect that Microsoft Excel and Word were the more commonly used productivity tools and that WordPerfect was not used much in the trial sites.
The trial shows that users with terminals, rather than Macintosh or PC, were unable to use the documents, even though their mail package successfully decoded the attachment, some users commented on this.
Below is the survey form that was sent out to all Australian Universities using the CAUDIT Email list.
The list below contains the document details that were used to trial MIME as a transport mechanism. The documents were sent to participants using the platform indicated.
Below is a list of the participants in the project.
Upgrade path:       Upgrade to the current version.
Out of 25 organisations, 8% use cc:Mail. The number of cc:Mail users across all organisations is 1% of the total user community.
Had no problems sending MIMEd attachments to organisations using MIME.
It is limiting in terms of formatting messages.
The [mail] database is in a single file and is easily corrupted with local pc and system crashes.
Availability:       Believed to be in the Public Domain.
Out of 25 organisations, 44% use Elm. The number of Elm users across all organisations is 26% of the total user community.
Not graphical, used as a simple Email package.
Availability:       Version 2.x is commercially available.
UUENCODE:  Only supported by the commercial version.
Out of 25 organisations, 76% use Eudora. The number of Eudora users across all organisations is 20% of the total user community.
Excellent interface and set up capabilities. Looks the same on Windows & Mac, user configurable, handles SLIP easily.
Upgrade path:       Convert to Elm or Pine.
Out of 25 organisations, 4% use Mail/mailx. The number of Mail/mailx users across all organisations is 1% of the total user community.
Out of 25 organisations, 16% use Mailtool. The number of Mailtool users across all organisations is less than 1% of the total user community.
Out of 25 organisations, 12% use MH. The number of MH users across all organisations is 1% of the total user community.
Out of 25 organisations, 16% use Microsoft Mail. The number of Microsoft Mail users across all organisations is 2% of the total user community.
Good front end, slow in peak periods, needs more than adequate resources to run well.
Out of 25 organisations, 40% use Pegasus Mail. The number of Pegasus Mail users across all organisations is 19% of the total user community.
Viewing of MIME graphics/video/sound is not done natively by the program. Each site must set up external programs to view - Pegasus Mail merely identifies the MIME type and passes the attachment to the external program you associate with the MIME type.
Out of 25 organisations, 40% use Pine. The number of Pine users across all organisations is 14% of the total user community.
This package is identical from a user's perspective under VMS and Unix. Set up is automatic.
Upgrade path:       Convert to Pegasus Mail or Eudora.
Availability:       Current versions are in beta development.
Out of 25 organisations, 12% use Popmail. The number of Popmail users across all organisations is 1% of the total user community.
The University of Minnesota is not developing this software any further. Currently there is a beta version of Minuet available. Minuet has the same functionality as Popmail with mail support but includes Gopher, News, Telnet, FTP and Finger support.
Out of 25 organisations, 8% use QuickMail. The number of QuickMail users across all organisations is less than 1% of the total user community.
Internet Gateways for this package are not robust and expensive.
Upgrade path:       Convert to Eudora.
BINHEX:  Yes, with StuffIt Compression if chosen.
Out of 25 organisations, 4% use Versaterm-link. The number of Versaterm-link users across all organisations is less than 1% of the total user community.
Integrated mail, news, FTP, directory etc. Reasonable remote access, average GUI.
Upgrade path:       Convert to Pine.
Availability:       Comes with VMS 6.1.
Out of 25 organisations, 24% use VMS mail. The number of VMS mail users across all organisations is 10% of the total user community.
Out of 25 organisations, 8% use Winqvt. The number of Winqvt users across all organisations is 1% of the total user community.
Out of 25 organisations, 8% use Zmail. The number of Zmail users across all organisations is less than 1% of the total user community.