Embedded Files
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.
Committee of Australian University Directors of Information Technology
Committee of Australian University Directors of Information Technology
Document Exchange using Electronic Mail
Document Exchange using Electronic Mail
Executive Summary
Executive Summary
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.
Document -> Encode-> Transfer -> Decode -> Translate-> Document
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:
- users are trained in the use of Email and attachments
- the document is saved in the author's native format
- each Email message contains a description of the attachment
- MIME is used as the preferred attachment standard
- one attachment is sent per Email message
Author's Note
Author's Note
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.
Onno Benschop - December 1995
1.0 Introduction
1.0 Introduction
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?
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.
2.0 Document Transfer
2.0 Document Transfer
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.
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.)
2.1 Attaching a document to an Email message
2.1 Attaching a document to an Email message
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.
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.
2.2 File Formats
2.2 File Formats
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.
2.2.1 Macintosh
2.2.1 Macintosh
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.
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.
2.2.2 IBM PC compatible
2.2.2 IBM PC compatible
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.
2.2.3 Unix
2.2.3 Unix
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.
2.3 Mail Attachments
2.3 Mail Attachments
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.
2.3.1 Encoding Mail
2.3.1 Encoding Mail
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.
2.3.1.1 ASCII
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.
2.3.1.2 UUENCODE
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.
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.
2.3.1.3 BINHEX
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.
2.3.1.4 MIME[1]
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.
The MIME standard defines Email messages containing the following parts:
- character sets other than ASCII
- enriched text (bold, italic, underscore, etc.)
- images
- sounds
- other messages (reliably encapsulated)
- tar files
- PostScript
- FTPable file pointers
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.)
2.3.2 Decoding Mail
2.3.2 Decoding Mail
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.
2.3.2.1 EMIL
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.
2.3.2.2 Compatibility Server[2]
The Clarity Compatibility server transparently intercepts Email messages being sent and transforms them as necessary to bridge incompatibilities in three areas:
- Differences in Email systems used by sender and recipient;
- Differences in operating systems and their file identification conventions (eg., file extensions on DOS and Windows, resource forks on Macintosh) between sender and recipient;
- Differences in application software used to send and receive the files
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.
2.4 Translating Documents
2.4 Translating Documents
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.
The following areas impact on the successful translation of a document:
- Method of document preparation
- Intermediate standards, such as RTF, SYLK and WKS
- Compression
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.
2.4.1 Document Preparation
2.4.1 Document Preparation
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.
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:
Alternative 1:
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.
Alternative 2:
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.
Alternative 3:
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.
2.4.1.1 Intermediate Standards for Translation
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.
2.4.1.2 RTF
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 current version of RTF is 1.3 and it is available from:
ftp://ftp.primate.wisc.edu/pub/RTF/
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.
2.4.2.3 SYLK/WKS
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.
2.4.2 Compression
2.4.2 Compression
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.
2.5 Other Ways of Exchanging Information
2.5 Other Ways of Exchanging Information
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.
The implications of these major difference are:
- 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.
2.5.1 FTP
2.5.1 FTP
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.
2.5.2 The World Wide Web (WWW)
2.5.2 The World Wide Web (WWW)
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.[3]
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.[3]
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.
2.5.2.1 URLs
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.
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.)
2.5.2.2 HTML
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 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:
http://www.curtin.edu.au/curtin/dept/cc/docs/howto/
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.
3.0 Electronic Mail survey
3.0 Electronic Mail survey
All universities in Australia were asked a number of questions about Email on their campus. Below are the results of the survey.
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 Unix From 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.
4.0 Implementation Issues
4.0 Implementation Issues
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.
4.1 Conversion
4.1 Conversion
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.
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 Zmail Table 1. Email Package Conversion Process
4.2 Training
4.2 Training
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.
4.2.2 Support
4.2.2 Support
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.
4.3 Life Time of recommendations
4.3 Life Time of recommendations
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.
5.0 Recommendations
5.0 Recommendations
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.
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.
Appendix A Glossary of Terms
Appendix A Glossary of Terms
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. Appendix B Survey
Appendix B Survey
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.
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:
- 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.
Some side issues which were discovered during the trial were:
- Results show that user training is an issue to address problems like:
- "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.
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:[4]
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.
Organisation: Type of Organisation: Number of Staff: Number of Students: Number of Postgraduate Students:Number of people with access to Electronic Mail: Number of people actually using Electronic Mail:Email Package: Version used: In the Public Domain: Author: Platform(s) used: Number of users who use this package across all platforms:Attachments that the package supports are Send text: Send BINHEX: Send UUENCODE: Send MIME: MIME-types sent: Send Other (name them): Receive text: Receive BINHEX: Receive UUENCODE: Receive MIME: MIME-types received: Receive Other (name them):Formats that the package supports are Send Sound: Send Video: Send Graphics: Send Attachments: Receive Sound: Receive Video: Receive Graphics: Receive Attachments: Comments about this package:Appendix C Document details
Appendix C Document details
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.
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 Appendix D Sites
Appendix D Sites
Below is a list of the participants in the project.
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 Appendix E Packages
Appendix E Packages
Appendix E: Inventory of Email software
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-stream Out of 25 organisations, 8% use cc:Mail. The number of cc:Mail users across all organisations is 1% of the total user community.
User comments:
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 installed Out of 25 organisations, 44% use Elm. The number of Elm users across all organisations is 26% of the total user community.
User comments:
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, Base64 Out of 25 organisations, 76% use Eudora. The number of Eudora users across all organisations is 20% of the total user community.
User comments:
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: None Out 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: Yes Out 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 types Out 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: No Out of 25 organisations, 16% use Microsoft Mail. The number of Microsoft Mail users across all organisations is 2% of the total user community.
User comments:
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.[5] The PC version, supports: UUENCODE, BINHEX, Base64, GIF, JPEG, MPEG, Audio (AU), PostScript Out of 25 organisations, 40% use Pegasus Mail. The number of Pegasus Mail users across all organisations is 19% of the total user community.
User comments:
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: Yes Out of 25 organisations, 40% use Pine. The number of Pine users across all organisations is 14% of the total user community.
User comments:
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: No Out of 25 organisations, 12% use Popmail. The number of Popmail users across all organisations is 1% of the total user community.
User comments:
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: None Out of 25 organisations, 8% use QuickMail. The number of QuickMail users across all organisations is less than 1% of the total user community.
User comments:
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: None 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.
User comments:
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: None Out 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: No Out 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: Yes Out of 25 organisations, 8% use Zmail. The number of Zmail users across all organisations is less than 1% of the total user community.
Appendix F DOS file extensions
Appendix F DOS file extensions
.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 Appendix G Related Documents
Appendix G Related Documents
Information Exchange Steering Committee, Electronic Mail - Issues for Government Business, Canberra, February 1994
Internet Community, MIME FAQ, Internet, 26 February 1995,
http://www.cis.ohio-state.edu/text/faq/usenet/mail/mime-faq/top.html
RFC 1767; D. Crocker
MIME Encapsulation of EDI Objects
RFC 1741; P. Faltstrom, D. Crocker, E. Fair
MIME Content Type for BinHex Encoded Files
RFC 1740; P. Faltstrom, D. Crocker, E. Fair
MIME Encapsulation of Macintosh files - MacMIME
RFC 1652; J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker
SMTP Service Extension for 8bit-MIMEtransport
RFC 1641; D. Goldsmith, M. Davis
Using Unicode with MIME
RFC 1563; N. Borenstein
The text/enriched MIME Content-type
RFC 1556; H. Nussbacher
Handling of Bi-directional Texts in MIME
RFC 1522; K. Moore
MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text
RFC 1521; N. Borenstein, N. Freed
MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies
RFC 1496; H. Alvestrand, J. Romaguera, K. Jordan
Rules for downgrading messages from X.400/88 to X.400/84 when MIME content-types are present in the messages
RFC 1437; N. Borenstein, M. Linimon
The Extension of MIME Content-Types to a New Medium
RFC 1428; G. Vaudreuil
Transition of Internet Mail from Just-Send-8 to 8Bit-SMTP/MIME
RFC 1344; N. Borenstein
Implications of MIME for Internet Mail Gateways
The following documents have been superseded, but have been included for reference:
RFC 1523; N. Borenstein
The text/enriched MIME Content-type
(Obsolete)
RFC 1426; J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker
SMTP Service Extension for 8bit-MIMEtransport
(Obsolete)
RFC 1341; N. Borenstein, N. Freed
MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies
(Obsolete)
Appendix H Web References:
Appendix H Web References:
(As of noon, December 4th, 1995)
(As of noon, December 4th, 1995)
MIME FAQ:
http://www.cis.ohio-state.edu/text/faq/usenet/mail/mime-faq/top.html
Example of documentation on the Web:
http://www.curtin.edu.au/curtin/dept/cc/docs/howto/
Documentation for MIME compliant Microsoft Mail Gateway:
http://www.ep.se/ep/eng/mimetic/mimetic.htm
Documentation of the RTF standard:
ftp://ftp.primate.wisc.edu/pub/RTF/
Compatibility Server:
Report abuse