Abstract

I describe the tradeoffs between Internet email and Fax technology in the context of a particular situation where a college is currently using a Fax machine. I then describe specific Email techniques that could be used to solve both the problem at hand and in terms of the general needs of the college. I discuss the general "perfect" solution and then a migration path from an initial solution and a medium range solution. The immediate solution is to send multiple email formats using the

Introduction

Facsimile machines and email have been around for about the same amount of time and originally served similar purposes. Primarily they were intended to transmit small amounts of information from one point to another. The fax machine provided connectivity corresponding to the phone system's connectivity (as long as both ends had a fax machine). It was good for normal text, handwritten messages and pictures or illustrations that could be transmitted at low resolution. Internet email provide the same connectivity as Internet (initially very limited, but now potentially rivalling the phone system connectivity). It was good only for text but had the advantage that the information received could be viewed, stored, deleted, or even deleted before being read. Since that time, both the email and fax technologies have improved dramatically as have the requirements that have been Problems arise in both techniques when

The Problem

This problem is based on a real problem I encountered in supporting a class at a college in Washington, D.C. The college needs to send a 50 page fax to about 100 locations around the world. The DP capabilies/facilities at these locations is unknown, variable and unpredicatable. For example, they cannot be expected to have an Oracle database. The data is inside an Oracle database and can be printed to a postscript printer or output as a postscript file. These series of faxes must be sent on a semi-regular basis. Eventually they may want to send a picture on each postscript page. The problem is that it takes about an hour to send each fax, if nothing goes wrong. Things that can go wrong are:

As a result, University staff make every excuse possible for not sending the fax to each of the locations. Now let us take a step back and compare the strengths and weaknesses of fax technology with that of some alternative solutions.

Strengths and Weaknesses of Fax Technology

Solution One: Fax Modem

So we look to Internet-based solutions: It turns out that the fax data we want to send can be output as postscript. There is no way to convert postscript to any kind of structured data. (Could convert it to a bitmap). The University email program is Novell's groupwise -- which supports attachments of many different types of files. Unfortunately, postscript is not one of them. MIME, however, does explicitly support postscript.

Possible Internet-based Solutions

A Perfect Solution

Solution Two: Email

Possible Formats

Proposed Solution

Conclusion

As the University staff you have two options:

Message Security

Postscript to bitmap conversions

Mime Encoding Capabilities

Groupwise formats supported

Todo

Their proposed solution: Print the bios on a postscript printer, scan them into an image, and send the image as an email attachment. They have groupwise mail. Is it compatable with the email at the destinations? Reading a message Pine should be able to handle just about any MIME message. When a MIME message is received, Pine will display a list of all the parts, their types and sizes. It will display the attachments when possible and appropriate and allow users to save all other attachments. Starting with version 3.90, Pine honors the "mailcap" configuration system for specifying external programs for handling attachments. The mailcap file maps MIME attachment types to the external programs loaded on your system which can display and/or print the file. If a $MAILCAPS environment variable is defined, Pine will use that to look for one or more mailcap files, which are combined. In the absence of $MAILCAPS, Unix Pine will look for a personal mailcap file in ~/.mailcap and combine that with a system-wide file in /etc/mailcap. PC-Pine will look for a file named MAILCAP in the same directory as the PINERC file, and/or the directory containing the PINE.EXE executable. If Pine sees a MIME message part tagged as type IMAGE, and Pine's image-viewer. configuration variable is set, Pine will attempt to send that attachment to the named image viewing program. In the case of UNIX Pine, the DISPLAY environment variable is checked to see if an X-terminal is being used (which can handle the images). If the image-viewer variable is not set, Pine uses the mailcap system to determine what to do with IMAGE types, just as it does for any other non-TEXT type, e.g. type APPLICATION. For MIME's generic "catch all" type, APPLICATION/OCTET-STREAM, the mailcap file will probably not specify any action, but Pine users may always Save any MIME attachment to a file.
http://www.cac.washingt...w-level.html

Sending a message There are two important factors when trying to include an attachment in a message: encoding and labeling. Pine has rules for both of these which try to assure that the message goes out in a form that is robust and can be handled by other MIME mail readers. MIME has two ways of encoding data-Quoted-Printable and Base64. Quoted-Printable leaves the ASCII text alone and only changes 8-bit characters to "=" followed by the hex digits. For example, "=09" is a tab. It has the advantage that it is mostly readable and that it allows for end of line conversions between unlike systems. Base64 encoding is similar to uuencode or btoa and just encodes a raw bit stream. This encoding is designed to get text and binary files through even the most improperly implemented and configured gateways intact, even those that distort uuencoded data. All attachments are encoded using Base64 encoding. This is so that the attachment will arrive at the other end looking exactly like it did when it was sent. Since Base64 is completely unreadable except by MIME-capable mailers or programs, there is an obvious tradeoff being made here. We chose to ensure absolutely reliable transport of attachments at the cost of requiring a MIME-capable mailer to read them. If the user doesn't want absolute integrity he or she may always include text (with the ^R command) in the body of a message instead of attaching it. With this policy, the only time quoted-printable encoding is used is when the main body of a message includes special foreign language characters. When an attachment is to be sent, Pine sniffs through it to try to set the right label (content-type and subtype). An attachment with any lines longer than 500 characters in it or more than 10% of the characters are 8-bit it will be considered binary data. Pine will recognize (and correctly label) a few special types including GIF, JPEG, PostScript, and some audio formats.
The "mailcap" format is formally defined by RFC 1524. Basically, a mailcap file is a configuration file that maps MIME types to external viewers. (MIME is defined by RFC 1521.) An example would be mapping MIME type image/gif to the image viewer "xv". Here is an example mailcap file: # This is a simple example mailcap file. # Lines starting with '#' are comments. # This maps all types of audio data (audio/basic, audio/x-aiff, # etc.) to the viewer 'showaudio'. Note that '%s' means 'put the # datafile name here when the viewer is executed'. audio/*; showaudio %s # This maps all types of images (image/gif, image/jpeg, etc.) # to the viewer 'xv'. image/*; xv %s # This maps MPEG video data to the viewer 'mpeg_play'. video/mpeg; mpeg_play %s # This maps all types of video *other than MPEG* to the viewer # 'genericmovie'. video/*; genericmovie %s application/postscript; ghostview %s application/x-dvi; xdvi %s
7.4.2. The Application/PostScript subtype
The Postscript application type in A Content-Type of "application/postscript" indicates a PostScript program. Currently two variants of the PostScript language are allowed; the original level 1 variant is described in [POSTSCRIPT] and the more recent level 2 variant is described in [POSTSCRIPT2].

7.5. The Image Content-Type
A Content-Type of "image" indicates that the body contains an image. The subtype names the specific image format. These names are case insensitive. Two initial subtypes are "jpeg" for the JPEG format, JFIF encoding, and "gif" for GIF format [GIF].

The list of image subtypes given here is neither exclusive nor exhaustive, and is expected to grow as more types are registered with IANA, as described in Appendix E.

The formal grammar for the content-type header field for data of type image is given by: image-type := "image" "/" ("gif" / "jpeg" / extension-token)
Content-Type: image/gif
Content-Transfer-Encoding: base64
... base64-encoded image data goes here....


A postscript example With the emerging possibility of very wide-area file systems, it becomes very hard to know in advance the set of machines where a file will and will not be accessible directly from the file system. Therefore it may make sense to provide both a file name, to be tried directly, and the name of one or more sites from which the file is known to be accessible. An implementation can try to retrieve remote files using FTP or any other protocol, using anonymous file retrieval or prompting the user for the necessary name and password. If an external body is accessible via multiple mechanisms, the sender may include multiple parts of type message/external-body within an entity of type multipart/alternative. However, the external-body mechanism is not intended to be limited to file retrieval, as shown by the mail-server access-type. Beyond this, one can imagine, for example, using a video server for external references to video clips. If an entity is of type "message/external-body", then the body of the entity will contain the header fields of the encapsulated message. The body itself is to be found in the external location. This means that if the body of the "message/external-body" message contains two consecutive CRLFs, everything after those pairs is NOT part of the message itself. For most message/external-body messages, this trailing area must simply be ignored. However, it is a convenient place for additional data that cannot be included in the content-type header field. In particular, if the "access-type" value is "mail- server", then the trailing area must contain commands to be sent to the mail server at the address given by the value of the SERVER parameter. The embedded message header fields which appear in the body of the message/external-body data must be used to declare the Content-type of the external body if it is anything other than plain ASCII text, since the external body does not have a header section to declare its type. Similarly, any Content-transfer-encoding other than "7bit" must also be declared here. Thus a complete message/external-body message, referring to a document in PostScript format, might look like this: From: Whomever To: Someone Subject: whatever MIME-Version: 1.0 Message-ID: Content-Type: multipart/alternative; boundary=42 Content-ID: --42 Content-Type: message/external-body; name="BodyFormats.ps"; site="thumper.bellcore.com"; access-type=ANON-FTP; directory="pub"; mode="image"; expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)" Content-type: application/postscript Content-ID: --42 Content-Type: message/external-body; name="/u/nsb/writing/rfcs/RFC-MIME.ps"; site="thumper.bellcore.com"; access-type=AFS expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)" Content-type: application/postscript Content-ID: --42 Content-Type: message/external-body; access-type=mail-server server="listserv@bogus.bitnet"; expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)" Content-type: application/postscript Content-ID: get RFC-MIME.DOC --42-- Note that in the above examples, the default Content-transfer- encoding of "7bit" is assumed for the external postscript data. Like the message/partial type, the message/external-body type is intended to be transparent, that is, to convey the data type in the external body rather than to convey a message with a body of that type. Thus the headers on the outer and inner parts must be merged using the same rules as for message/partial. In particular, this means that the Content-type header is overridden, but the From and Subject headers are preserved. Note that since the external bodies are not transported as mail, they need not conform to the 7-bit and line length requirements, but might in fact be binary files. Thus a Content-Transfer-Encoding is not generally necessary, though it is permitted. Note that the body of a message of type "message/external-body" is governed by the basic syntax for an RFC 822 message. In particular, anything before the first consecutive pair of CRLFs is header information, while anything after it is body information, which is ignored for most access-types.
There are two issues - Internet e-mail was originally designed only for the transfer of simple text messages. The problem is how more complex messages should be converted to and from simple text so that they can be sent via e-mail. Can the sender and recipient agree on a word-processor (or picture, database, spreadsheet, etc.) format to be used? These issues are complex enough to be avoided if possible. If you are sending text that is to be revised by the recipient(s) or where its appearance does not matter, you are advised to use your word-processor to convert it to plain ASCII text before sending it. If you cannot avoid sending complex data via e-mail you must face the problems .... To MIME or uuencode? There are two common methods used by mail systems today for turning complex data into simple text that can be e-mailed: MIME (Multi-purpose Internet Mail Extensions) and uuencoding. Where a mail system supports one of these, it will normally perform any conversion of incoming and outgoing mail automatically. However because the method supported by your mailer may be different from that used by your correspondent's mailer, you need to be aware not only of the method used by your mailer but also of what your correspondents' mailer does. For example, if you send MIME encoded mail and your correspondent doesn't support MIME, the mail will be of no use to them. You both need to support MIME or both support uuencoding to successfully exchange complex messages. If you do not know what method your mail system uses, seek the advice of your local computer services staff. MIME is a draft Internet standard but it is not yet ubiquitous within the Internet in general nor within the Research Councils in particular. At the time of writing the common MS Windows office systems, such as MS Office and Novell's GroupWise, uuencode attachments when sending mail to or through the Internet. Which word-processor? Agreeing on whether to use MIME or uuencoding is not the end of the matter. Just as you may give a word- processor file on a floppy disk to someone only to find that their word-processor can read the disk but not the file, so you may have successfully mailed your file to someone only to find their word-processor (or spreadsheet or database or graphics software) cannot read it. You need to be aware of the formats that your software can produce and of the formats that can be read by your correspondents' software. If you can find a common format, use it, but you must accept that sometimes there will be no common format other than plain ASCII text. For documents that are not supposed to be revised by their recipients and for which appearance is important, it should be borne in mind that printers which support Postscript are becoming ubiquitous and most word-processing software can produce Postscript output. Thus, final-form documents can sometimes be sent as Postscript. However, Postscript is not without its problems: there are two levels of Postscript extant; level 2 is supposed to be a superset of level 1, so that level 2 capable printers should be able to accept level 1 documents, but this does not always work. Also, authors often make assumptions about the fonts available on printers that are not supported in practice. Before distributing Postscript documents you may need to check that the fonts and the level of Postscript you use are supported by the intended recipients. Other options becoming available for the transfer of final-form complex documents are so-called portable document formats such as Adobe Acrobat and Novell's Envoy. Both these turn complex documents into a 'portable' format which may be read using the appropriate viewing software. MS Windows viewers for Acrobat and Envoy documents have been made freely available by their suppliers. Thus any Windows user can be given the ability to view and print such a document. The fly in the ointment is that the software that produces these portable document formats is not free. Good Practice A final note on the subject of mailing complex documents: it is good practice to include a plain text comment at the start of the mail saying what the message contains, to give the recipient the best chance of reading it. Something like this should suffice - The attached file contains the latest annual report in WordPerfect 6.1 format. It is uuencoded.