Fax to Email

Keith Billings







The Problem

Strengths and Weaknesses of Fax Technology






Solution One: Fax Modem






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.





 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



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:

    

  •  The remote machine is broken, offline or (the line) is busy.

  •  The paper jams on the local machine.

  •  The paper jams on the remote machine.

  •  The remote machine runs out of paper.





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.