Document Exchange using Electronic Mail
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.
In summary the recommendations of this report are:
A special note to Nick Jenkins who patiently explained the use of the English language.
Onno Benschop - December 1995
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.
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.
In addition to Electronic Mail, developments on the Internet, such as FTP and the WWW offer an alternative transmission medium. (See section 2.5 for further discussion.)
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.
Below is an overview of the process.
fig 1: Overview of process
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.
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.
The Macintosh resource fork is normally only used in application programs, where it contains the programming code, icons, etc.
However, some applications use both. (For example the Nisus word processor.)
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.
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.
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.
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.
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.
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.
A document attached and send from a non-Macintosh platform can be successfully decoded by the Email program. The decoded document does not contain Type and Creator information and the Macintosh operating system cannot open the document. Some mail programs read the DOS file extension and allocate a Type and Creator accordingly. (For example, Eudora for the Macintosh will recognise Word and Excel document extensions.)
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.
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.
The MIME standard defines Email messages containing the following parts:
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.
MIME is used across a wide range of platforms. It has been created as an extensible standard and has been ratified in various international standards by the Internet community. (See Appendix G for further references.)
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.
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.
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.
The following areas impact on the successful translation of a document:
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.
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.
A document saved in a non-native format loses information, or may be subject to translation and interpretation errors. If for example a Microsoft Word document was sent to a user with WordPerfect, there are three alternatives:
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.
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.
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 126.96.36.199.
An Internet development called HTML, described in section 188.8.131.52, addresses this problem from a different perspective.
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 current version of RTF is 1.3 and it is available from:
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.
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.
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.
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.
The implications of these major difference are:
As a result, Memo's should be sent via Email, but reports can be distributed using FTP and WWW.
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.
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.
On the WWW everything (documents, menus, indices) is represented to the user as a Hypertext object in HTML format. Hypertext links refer to other documents by their URLs. These can refer to local or remote resources accessible via FTP, Gopher, Telnet or News, as well as those available via the HTTP protocol used to transfer Hypertext documents.
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.
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.
It should be noted that MIME supports this type of attachment description in the form of FTP-able file pointers. (Although not many mail programs implement this feature.)section 184.108.40.206.
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 many examples of Web documents available. The Curtin Computing Centre has, for example, made its HowTo documentation, traditionally printed on paper, available on the Web. To access these documents, go to:
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.
Across the 25 organisations who responded, the following Email packages were in use:
Number of sites % Number of Users % user sites 1 Eudora 76% 1 Elm 26% 2 Elm 44% 2 Eudora 20% 3 Pegasus Mail 40% 3 Pegasus Mail 19% 4 Pine 40% 4 Pine 14% 5 VMS mail 24% 5 VMS mail 10% 6 Mailtool 16% 6 Microsoft Mail 2% 7 Microsoft Mail 16% 7 mail/mailx 1% 8 MH 12% 8 cc:Mail 1% 9 POPMail 12% 9 MH 1% 10 cc:Mail 8% 10 POPMail 1% 11 Quick Mail 8% 11 WinQVT 1% 12 WinQVT 8% 12 Quick Mail <1% 13 ZMail 8% 13 Mailtool <1% 14 mail/mailx 4% 14 ZMail <1% 15 VersaTerm-Link 4% 15 VersaTerm-Link <1% Other Mailer's 16% Other Mailer's 3%The first four packages in either column are identical. This means that most sites have this and the majority of users use these Email packages. These four packages are MIME compliant. (It should be noted that most sites use multiple packages.)
When users were asked about the encoding/decoding method of their Email package:
%pkg UUENCODE 76% MIME 63% BINHEX 53%The following packages claim to be MIME compliant:
Software Platform Elm Unix Pegasus mail DOS, Windows, Macintosh Eudora Macintosh, Windows Pine Unix, VMS cc:Mail DOS, Windows, Macintosh MH Unix Mailtool Unix Zmail UnixFrom the responses, we can also find out what percentage of users uses a PC users versus the number of users with terminal (emulation) access:
Personal Computer 45% Terminal Services 53%Totals:
Number of Organisations: 25 Number of Packages: 15 Access to e-mail: 49% Use of e-mail: 22%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.
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.
Current solution MIME based solution Mail/mailx convert to Elm or Pine Mac Pegasus mail convert to Eudora Popmail convert to Pegasus mail or Eudora Versaterm-link convert to Eudora VMS mail convert to Pine Winqvt convert to Pegasus mail or Eudora Microsoft Mail install EMIL, Compatibility Server or MIME gateway QuickMail install EMIL, Compatibility Server or MIME gateway Elm upgrade to Elm with MIME extensions Pine upgrade to Pine with MIME extensions cc:Mail stay with cc:Mail Eudora stay with Eudora Mailtool stay with Mailtool MH stay with MH PC Pegasus mail stay with PC Pegasus mail Zmail stay with ZmailTable 1. Email Package Conversion Process
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.
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.
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.
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.
In the body of the Email message describe the document and it's encoding scheme in such a way that the person receiving can manually decode and translate the document, if necessary. For example:
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.
This could be achieved by inserting a line in the signature at the end of the Email message like:
Documents attached to this Email are Macintosh Word 5.1a and Excel 5 formatted for A4 LaserWriters.
ASCII American Standard Code for Information Exchange. The predominant character set encoding of present-day computers. The modern version uses 7 bits for each character, whereas most earlier codes (including an early version of ASCII) used fewer. This change allowed the inclusion of lower case - letters a major win - but it did not provide for accented letters or any other letter forms not used in English (such as the German sharp-S or the ae-ligature which is a letter in, for example, Norwegian) BINHEX A Macintosh format for representing a file in text form. The file is converted to lines of letters, numbers and punctuation. Because BINHEX files are simply text they can be sent through most Electronic Mail systems and stored on most computers. However the conversion to text makes the file larger, so it takes longer to transmit a file in BINHEX format than if the file was represented some other way. The suffix ".hqx" usually indicates a BINHEX format file. browser A program which allows a person to read hyper-text. The browser gives some means of viewing the contents of nodes and of navigating from one node to another. Mosaic, Lynx and W3 are browsers for the World-Wide Web. They act as clients to remote servers. data fork Part of a file on a Macintosh file system. A file consists of two parts, the data fork and the resource fork. The data fork contains any information that an application wishes to store. (Also see resource fork.) FAQ A document provided for many USENET newsgroups which attempts to answer Frequently Asked Questions which new readers often ask. These are maintained by volunteers and posted regularly to the news group. FTP File Transfer Protocol: A client-server file transfer protocol which allows a user on one computer to transfer files to and from another computer over a TCP/IP network. Also the client program the user executes to transfer files. It is defined in STD 9, RFC 959. GIF Graphics Interchange Format, a standard for compressed digitised images, defined in 1987 by CompuServe. GNU A recursive acronym: "GNU's Not Unix!". The Free Software Foundation's project to provide a freely distributable replacement for Unix. The GNU Manifesto was published in the March 1985 issue of Dr. Dobb's Journal but the GNU project started a year and a half earlier when Richard Stallman was trying to get funding to work on his freely distributable editor, Emacs. Gopher A popular distributed document retrieval system which started as a Campus Wide Information System at the University of Minnesota. Many hosts on the Internet now run Gopher servers which provide a menu of documents. A document may be a plain text file, sound, image, submenu or other Gopher object type. It may be stored on another host or may provide the ability to search through certain files for a given string. Gopher is defined in RFC 1432. helper application A program that can deal with a specific data-type. Examples are programs that display GIF's, play sounds, show QuickTime movies, decode BINHEX, etc. host The name of a computer on the Internet. HTML Hyper-Text Markup Language. Document format used by the World-Wide Web. MIME A standard for multi-part, multimedia Email messages on the Internet. MIME provides the ability to transfer non-textual data, such as graphics, audio and fax. It is defined in RFC 1341. It is also used on the World-Wide Web. It uses mimencode to encode binary data into base 64 using a subset of ASCII. MIME part A mail message sent using MIME contains segments. Each segment is called a part. Each part contains type, name and content. A MIME capable program can either deal with each part itself or alternatively launch a separate "helper-application" that can deal with a given part. News Short for USENET News. A distributed bulletin board system supported mainly by Unix machines and the people who post and read articles thereon. Originally implemented in 1979 - 1980 by Steve Bellovin, Jim Ellis, Tom Truscott, and Steve Daniel at Duke University, it has swiftly grown to become international in scope and is now probably the largest decentralised information utility in existence. PostScript PostScript is an interpreted, stack-based language (like FORTH). It was used as a page description language by the Apple LaserWriter, and now many laser printers and on-screen graphics systems. Its primary application is to describe the appearance of text, graphical shapes and sampled images on printed or displayed pages. The language was developed by Adobe. resource fork Part of a file on a Macintosh file system. A file consists of two parts, the data fork and the resource fork. The resource fork contains programming code and resources that are not directly part of the program. It was implemented to allow Macintosh software to be localised. A process that translates elements seen on the screen into different languages without having to recompile the source-code. RFC Request for Comment. The internet community defines standards using a request for comment, which turns into a standard after due processing. RTF Rich Text Format, an interchange format from Microsoft for exchange of documents between Word and other document preparation systems. sendmail A Unix program that sends mail between hosts on the Internet. tar To create a transportable archive from a group of files by first appending them together with a Unix program called tar (the Tape ARchiver) and then compressing the result. Type and Creator A description of file type and application that created the mnemonic file on a Macintosh file system. It allows a document to be associated with its creating program. uLaw Computers (and audio compact discs and digital audio tape) handle sound by storing a sequence of discrete samples. The continuous sound waveform from the original source is sampled tens of thousands of times a second. Each sample represents the intensity of the sound pressure wave at that instant. Apart from the sampling frequency, the other parameter is the digital encoding of each sample including the number of bits used. The encoding may be linear, logarithmic or ulaw. URL Uniform Resource Locater, previously "Universal". A draft standard for specifying an object on the Internet, such as a file or news group. URLs are used extensively on the World-Wide Web. They are used in HTML documents to specify the target of a hyperlink. UUENCODE Unix program for encoding binary data as ASCII. UUENCODE was originally used with UUCP (Unix to Unix copy) to transfer binary files over serial lines which did not preserve the top bit of characters but is now used for sending binary files by Email and posting to USENET newsgroups etc. Web Short for World-Wide-Web, an Internet client-server hyper-text distributed information retrieval system originating from the CERN High-Energy Physics laboratories in Geneva, Switzerland. In WWW everything (documents, menus, indices) is represented to the user as a hyper-text (hyper-media) object in HTML format. Links between documents take the form of URLs. These can refer to local or remote resources accessible via several different network protocols apart from the basic http protocol used to transfer hyper-text documents.
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.
In the second stage, a trial was conducted with a group of users from a number of organisations. (See Appendix D for details) Documents with different formats were attached to mail messages using the recommendations set out in this report. The files ranged in size from 10 Kb to 4.7 Mb. (See Appendix C for details)
The trial confirmed that the recommendation to use MIME was correct, given the constraints set out in this report. It also identified the following issues:
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.
Some side issues which were discovered during the trial were:
The mailer I use is capable of:
Yes No UUENCODE 76% 22% MIME 63% 34% BINHEX 53% 44%Totals:
Number of 25 Organisations Number of Packages 15 Access to Email 49% Use of Email 22%PC users versus terminal users:
Personal Computer 45% Terminal services 53%Number of sites that use:
Eudora 19 76% Elm 11 44% Pegasus Mail 10 40% Pine 10 40% VMS mail 6 24% Mailtool 4 16% Microsoft Mail 4 16% MH 3 12% POPMail 3 12% cc:Mail 2 8% Quick Mail 2 8% WinQVT 2 8% ZMail 2 8% mail/mailx 1 4% VersaTerm-Link 1 4% Other Mailer's 4 16%Number of users per package:
Elm 17532 26.13% Eudora 13686 20.39% Pegasus Mail 13018 19.40% Pine 9233 13.76% VMS mail 6670 9.94% Microsoft Mail 1142 1.70% mail/mailx 950 1.42% cc:Mail 840 1.25% MH 750 1.12% POPMail 550 0.82% WinQVT 450 0.67% Quick Mail 290 0.43% Mailtool 258 0.38% ZMail 40 0.06% VersaTerm-Link 5 0.01% Other Mailer's 1692 2.52%Below is the survey form that was sent out to all Australian Universities using the CAUDIT Email list.
Number of people with access to Electronic Mail:
Attachments that the package supports are
Formats that the package supports are
File Name Format Pages Size Platform Sent from btw7.pm5 PageMaker 5 for 4 4,983,7 Macintosh Eudora Macintosh 90 v1.5.1 calc.xls Excel 4 for Macintosh 2 68,434 PC Eudora v1.4.4 chart.xls Excel 4 for Macintosh 1 12,637 Elm v2.4 PL24 example.wp5 WordPerfect 5.2 for 1 32,944 PC Pegasus Mail Windows v1.2.1 example.wp6 WordPerfect 6 for 1 55,385 Pine v3.91-VMS Windows struct.wp6 WordPerfect 5.2 for 4 9,379 Macintosh Eudora Windows v1.5.1 struct.wp6 WordPerfect 6 for 4 19,366 Elm v2.4 PL24 Windows waterm.wp6 WordPerfect 6 for 1 45,551 Pine v3.91 Windows word2.doc Word 2 for Windows 20 4,577,2 Macintosh PMail 80 v2.1.2 word6.doc Word 6 for Windows 20 4,616,1 Pine v3.91 92
Participants in the Email survey. Participants in the Electronic Document Transfer Trial. Antarctic Division Curtin University of Technology Australian Defence Force Academy Deakin University Australian National University James Cook University Australian Vice-Chancellors La Trobe University - Bendigo Committee Curtin University of Technology Macquarie University Deakin University Murdoch University Edith Cowan University Northern Territory University Griffith University Royal Melbourne Institute of Technology James Cook University The University of Adelaide La Trobe University - Bendigo University of South Australia Lincoln University University of Western Sydney Macquarie University Massey University Murdoch University Northern Territory University Queensland University of Technology Royal Melbourne Institute of Technology The University of Adelaide The University of Sydney University of New South Wales University of Otago University of South Australia University of Southern Queensland University of Western Sydney Victoria University of Wellington
Package: cc:Mail Upgrade path: Upgrade to the current version. Current Version: Mac: 2.1.1 PC: 4.02 Win: 2.10 Author: Lotus, Innosoft Availability: Commercial cc:Mail supports the following attachment methods: UUENCODE: Only as a MIME part BINHEX: None MIME: Yes, supports: text/plain, text/rtf, application/octet-streamOut 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.
Package: Elm Upgrade path: Upgrade to the current version. Current Version: Unix: 2.4 PL24 PC: 2.3 Author: Usenet Community Trust Availability: Believed to be in the Public Domain. Elm supports the following attachment methods: UUENCODE: Yes BINHEX: Only with helper applications MIME: Yes if MIME version is installedOut 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.
Runs well, needs large spooling area
Package: Eudora Upgrade path: Upgrade to the current version. Current Version: Mac: 1.5.1 2.1.1 Commercial Win: 1.4.4 2.0 Commercial Author: Qualcomm Availability: Version 2.x is commercially available. Eudora supports the following attachment methods: UUENCODE: Only supported by the commercial version. BINHEX: Yes MIME: Yes, supports: BINHEX, Base64Out 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.
Package: Mail/mailx Upgrade path: Convert to Elm or Pine. Current Version: Unix: 5.0 Author: Berkley Availability: Believed to be in the Public Domain. Mail/mailx supports the following attachment methods: UUENCODE: Yes BINHEX: Yes MIME: NoneOut of 25 organisations, 4% use Mail/mailx. The number of Mail/mailx users across all organisations is 1% of the total user community.
Package: Mailtool Upgrade path: Upgrade to the current version. Current Version: Unix: 3.3 Author: Sun Availability: Believed to be in the Public Domain. Mailtool supports the following attachment methods: UUENCODE: Yes BINHEX: Only with helper applications MIME: YesOut of 25 organisations, 16% use Mailtool. The number of Mailtool users across all organisations is less than 1% of the total user community.
Package: MH Upgrade path: Upgrade to the current version. Current Version: Unix: 6.8 Author: UCI Availability: Believed to be in the Public Domain. MH supports the following attachment methods: UUENCODE: Only with helper applications BINHEX: Only with helper applications MIME: Yes, simple to define new typesOut of 25 organisations, 12% use MH. The number of MH users across all organisations is 1% of the total user community.
Package: Microsoft Mail Upgrade path: An example of a MIME gateway is: http://www.ep.se/ep/eng/mimetic/mimetic.htm Current Version: Mac: 3.1 Win: 3.2a Author: Microsoft Availability: Commercial Microsoft Mail supports the following attachment methods: UUENCODE: Yes, if using the SMTP gateway. Uses internal file format for exchange within a Microsoft Mail network. BINHEX: No MIME: NoOut 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.
Package: Pegasus Mail Upgrade path: Upgrade to the current version. Current Version: Mac: 2.1.2 PC: 3.22 Win: 1.21 Author: David Harris Availability: Public Domain. Manuals are available for purchase. Pegasus Mail supports the following attachment methods: UUENCODE: Yes BINHEX: Yes MIME: The Macintosh version can send MIME mail, not receive it. The PC version, supports: UUENCODE, BINHEX, Base64, GIF, JPEG, MPEG, Audio (AU), PostScriptOut 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.
Package: Pine Upgrade path: Upgrade to the current version. Current Version: Unix: 3.91 VMS: 3.89 Author: University of Washington Availability: Believed to be in the Public Domain. Pine supports the following attachment methods: UUENCODE: Yes BINHEX: None MIME: YesOut 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.
Package: Popmail Upgrade path: Convert to Pegasus Mail or Eudora. Current Version: PC: 3.2.2 PC: Beta version 3.2.3 (Supplanted by "Minuet") Author: University of Minnesota Availability: Current versions are in beta development. Popmail supports the following attachment methods: UUENCODE: Yes BINHEX: Yes MIME: NoOut 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.
Package: QuickMail Upgrade path: Install EMIL to convert messages to and from MIME. Current Version: Mac: 3.0 Win: 3.0 Author: CE Software Availability: Commercial QuickMail supports the following attachment methods: UUENCODE: Yes BINHEX: None MIME: NoneOut 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.
Package: Versaterm-link Upgrade path: Convert to Eudora. Current Version: Mac: 1.1.1 Author: Ablebeck Software Availability: Commercial Versaterm-link supports the following attachment methods: UUENCODE: None BINHEX: Yes, with StuffIt Compression if chosen. MIME: NoneOut 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.
Package: VMS mail Upgrade path: Convert to Pine. Current Version: VMS: 6.1 Author: Digital Corp. Availability: Comes with VMS 6.1. VMS mail supports the following attachment methods: UUENCODE: Only with helper applications BINHEX: Only with helper applications MIME: NoneOut of 25 organisations, 24% use VMS mail. The number of VMS mail users across all organisations is 10% of the total user community.
Package: Winqvt Upgrade path: Convert to Pegasus Mail or Eudora. Current Version: Win: 3.9.8 Author: QPC Software Availability: Shareware Winqvt supports the following attachment methods: UUENCODE: Yes BINHEX: No MIME: NoOut of 25 organisations, 8% use Winqvt. The number of Winqvt users across all organisations is 1% of the total user community.
Package: Zmail Upgrade path: Upgrade to the current version. Current Version: Unix: 2.1 Author: Z-Code Software Corp. Availability: Commercial Zmail supports the following attachment methods: UUENCODE: Yes BINHEX: No MIME: YesOut of 25 organisations, 8% use Zmail. The number of Zmail users across all organisations is less than 1% of the total user community.
.123 Lotus Spreadsheet .arc File compressed using Arc .bat Batch file with DOS commands .com Application .dbf dBase database file .dbt dBase memo fields file .dic Microsoft Dictionary file .dll Dynamic Link Library .doc Microsoft Word document .dot Microsoft Word Template file .drv Driver file .exe Application .gif Graphic Interchange Format file .hlp Help file .hqx File encoded using BINHEX .idx dBase index file .inf Set up information file .ini Program initialisation file .jpg JPEG encoded file .lzh File compressed using LHA .mov Video file .mpg MPEG encoded video file .pif Program Information file .sys Driver information file .txt Text file .wav Sound file .wri Windows Write file .xls Microsoft Excel spreadsheet .zip File compressed using PKZip / GZip
Internet Community, MIME FAQ, Internet, 26 February 1995,
RFC 1767; D. Crocker
RFC 1741; P. Faltstrom, D. Crocker, E. Fair
RFC 1740; P. Faltstrom, D. Crocker, E. Fair
RFC 1652; J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker
RFC 1641; D. Goldsmith, M. Davis
RFC 1563; N. Borenstein
RFC 1556; H. Nussbacher
RFC 1522; K. Moore
RFC 1521; N. Borenstein, N. Freed
RFC 1496; H. Alvestrand, J. Romaguera, K. Jordan
RFC 1437; N. Borenstein, M. Linimon
RFC 1428; G. Vaudreuil
RFC 1344; N. Borenstein
The following documents have been superseded, but have been included for reference:
RFC 1523; N. Borenstein
RFC 1426; J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker
RFC 1341; N. Borenstein, N. Freed
Example of documentation on the Web:
Documentation for MIME compliant Microsoft Mail Gateway:
Documentation of the RTF standard: