Add files from ESR's dev directory that weren't under version control

svn path=/trunk/; revision=3881

4 files changed, 1721 insertions, 0 deletions

diff --git a/mime64/Makefile b/mime64/Makefile
new file mode 100644
index 00000000..a94322ba
--- /dev/null
+++ b/mime64/Makefile
@@ -0,0 +1,14 @@
+DESTDIR = /usr/local/bin
+CFLAGS = $G $O $S
+O = -m486 -O2
+S = -s
+G =
+
+mime64:	mime64.c
+	$(CC) $(CFLAGS) -o $@ $^
+
+install:mime64
+	install -s mime64 $(DESTDIR)
+
+clobber:
+	rm -f mime64
diff --git a/mime64/README b/mime64/README
new file mode 100644
index 00000000..f87e9d52
--- /dev/null
+++ b/mime64/README
@@ -0,0 +1,81 @@
+
+                   MIME64 Encoder/Decoder
+
+WHAT MIME64 IS:  MIME64 is an encoding described in RFC1341 as MIME base64.
+Its purpose is to encode binary files into ASCII so that they may be passed
+through e-mail gates.  In this regard, MIME64 is similar to UUENCODE.
+Although most binaries these days are transmitted using UUENCODE, I
+have seen a few using MIME64, and I have had requests from friends that
+I decode MIME64 files that have fallen into their hands.  As long as
+some MIME64 continues to exist, a package such as this one is useful
+to have.
+
+
+WHAT THIS PACKAGE CONTAINS:  This package contains both executable
+and ANSI-C source code for a MIME64 encoder/decoder (MIME.EXE and
+MIME.C respecively).  It also contains this README file, and a MIME64
+encoded file called MIME.64.  The latter will decode to MIME.ZIP if
+you issue the DOS command line:
+
+   MIME64 MIME.64 MIME.ZIP
+
+If you unzip the zip file, you will get an essay by Mark Grand about
+MIME.
+
+
+HOW TO USE THIS PACKAGE:  To decode a MIME64 file you may type:
+
+   MIME64 infile outfile
+
+If you leave out the outfile specification, the output file will
+overwrite the input file unless there is a filename specifier in
+the header of the input file.  If there is a file name specifier
+in infile, and no outfile is given, the output file will be
+according to the specifier.  An example of a filename specifier
+in the header of a base64 MIME file is:
+
+Content-Type: text/plain; charset=US-ASCII; name=dork.zip
+
+The filename specified here is dork.zip.
+
+If the input file has a content transfer encoding of any but base64,
+that input will be ignored.  For example, if it had a header line of:
+
+Content-transfer-encoding: unusualformat
+
+instead of:
+
+Content-transfer-encoding: base64
+
+there would be no output.  If no content-transfer-encoding line is
+given in the file, MIME64 assumes the file to be base64 and decodes
+it accordingly.
+
+There can be several files encoded into an input file.  If subsequent
+encoded files are found in the input file, they will be decoded according
+to the name specified in a content-type line.
+
+To encode a file into MIME64 format, type:
+
+   MIME64 infile outfile -e
+
+If you leave off the outfile specification, the output will
+overwrite the input.  MIME64 does not permit you to encode more than
+one file at a time.  If you wish to combine several base64 files,
+you will have to do so with a text editor.
+
+
+STATUS OF THIS PACKAGE:  This package is freeware.  As author, I
+claim no copyright.  If you change the source code and intend to
+propogate that change to other users, please include a comment to
+that effect at the top that states:  The date of the change, the
+nature of the change, and who made the change.  As a courtesy, I also
+ask that you retain the comment that acknowledges me as the original
+author.
+
+
+SEND QUESTIONS ABOUT THIS PACKAGE TO:  hahn@lds.loral.com
+
+Karl Hahn
+
+
diff --git a/mime64/mime.txt b/mime64/mime.txt
new file mode 100644
index 00000000..109e481c
--- /dev/null
+++ b/mime64/mime.txt
@@ -0,0 +1,831 @@
+

+

+                            MIME Overview

+

+                by Mark Grand <mark@premenos.sf.ca.us>

+

+Internet e-mail allows mail messages to be exchanged between users of

+computers around the world and occasionally beyond... to space

+shuttles.  One of the main reasons that Internet e-mail has achieved

+such wide use is because it provides a standard mechanism for messages

+to be exchanged between over 1,000,000 computers connected to the

+Internet.

+

+The standards that are the basis for Internet e-mail were established

+in 1982.  Though they were state of the art in 1982, in the

+intervening years they have begun to show their age.  The 1982

+standards allow for mail messages that contain a single human readable

+message with the restrictions that:

+

+    * the message contains only ASCII characters.

+

+    * the message contains no lines longer than 1000 characters.

+

+    * the message does not exceed a certain length

+

+The 1982 standards do not allow EDI to be transmitted through Internet

+mail, since EDI messages can violate all of these restrictions.  There

+are a number of other types of messages and services that have are

+supported by other mail standards that have been designed more

+recently.  In June of 1992 a new Internet mail standard was approved.

+This new standard is called MIME.

+

+MIME is an acronym for Multipurpose Internet Mail Extensions.  It

+builds on the older standard by standardizing additional fields for

+mail message headers that describe new types of content and

+organization for messages.

+

+MIME allows mail messages to contain:

+

+    * Multiple objects in a single message.

+

+    * Text having unlimited line length or overall length.

+

+    * Character sets other than ASCII.

+

+    * Multi-font messages.

+

+    * Binary or application specific files.

+

+    * Images, Audio, Video and multi-media messages.

+

+MIME defines the following new header fields:

+

+1.  A MIME-Version header field, which uses a version number to

+    declare that a message conforms to the MIME standard.

+

+2.  A Content-Type header field, which can be used to specify the type

+    and subtype of data in the body of a message and to fully specify

+    the encoding of such data.

+

+    2.a.  A Text Content-Type value, which can be used to represent

+          textual information in a number of character sets and

+          formatted text description languages in a standardized

+          manner.

+

+    2.b.  A Multipart Content-Type value, which can be used to combine

+          several body parts, possibly of differing types of data,

+          into a single message.

+

+    2.c.  An Application Content-Type value, which can be used to

+          transmit application data or binary data.

+

+    2.d.  A Message Content-Type value, for encapsulating a mail

+          message.

+

+    2.e.  An Image Content-Type value, for transmitting still image

+          (picture) data.

+

+    2.f.  An Audio Content-Type value, for transmitting audio or voice

+          data.

+

+    2.g.  A Video Content-Type value, for transmitting video or moving

+          image data, possibly with audio as part of the composite

+          video data format.

+

+3.  A Content-Transfer-Encoding header field, that specifies how the

+    data is encoded to allow it to pass through mail transports having

+    data or character set limitations.

+

+4.  Two optional header fields that can be used to further describe

+    the data in a message body, the Content-ID and Content-Description

+    header fields.

+

+MIME is an extensible mechanism.  It is expected that the set of

+content-type/subtype pairs and their associated parameters will grow

+with time.  Several other MIME fields, such as character set names,

+are likely to have new values defined over time.  To ensure that the

+set of such values develops in an orderly, and public manner, MIME

+defines a registration process which uses the Internet Assigned

+Numbers Authority (IANA) as a central registry for such values.

+

+To promote interoperability between implementations, the MIME standard

+document specifies a minimal subset of the above mechanisms that are

+required for an implementation to claim to conform to the MIME

+standard.

+

+

+

+                        MIME Technical Summary

+

+MIME is defined by an Internet standard document called RFC 1341.

+This document summarizes the contents of RFC 1341.  Sufficient detail

+is presented here to understand the capabilities of MIME.  For

+sufficient detail to implement MIME please read RFC 1341.

+

+MIME allows messages to contain multiple objects.  When multiple

+objects are in a MIME message, they are represented in a form called a

+body part.  A body part has a header and a body, so it makes sense to

+speak about the body of a body part. Also, body parts can be nested in

+bodies that contain one or multiple body parts.

+

+The Content-Type values, subtypes, and parameter names defined in the

+MIME standard are not case insensitive.  However, many parameter

+values are case sensitive.

+

+The MIME standard is written to allow MIME to be extended in certain

+ways, without having to revise the standard.  MIME specifies sets of

+values that are allowed for various fields and parameters.  The

+provides a procedure for extending these sets of values by registering

+them with an entity called the Internet Assigned Numbers Authority

+(IANA).

+

+

+The MIME-Version Header Field

+

+MIME is designed to be compatible with older Internet mail standards.

+In particular, it is compatible with RFC 822.  If a mail reading

+program receives a message that is a MIME message then it will likely

+perform additional processing for the MIME message that it would not

+perform for non-MIME messages.  In order to allow mail reading

+programs to recognize MIME messages, MIME messages are required to

+contain a MIME-Version header field.  The MIME-Version header field

+specifies the version of the MIME standard that the message conforms

+to.

+

+As of this writing there is only version (1.0) of the MIME standard.

+Messages that comply with the standard must include a header field,

+with the following verbatim text:

+

+        MIME-Version: 1.0

+

+The MIME-Version header field is required at the top level of a

+message. It is not required for each body part of a multipart entity.

+It is required for the embedded headers of a body of type "message" if

+and only if the embedded message is claimed to be MIME-compliant.

+

+

+The Content-Type Header Field

+

+The Content-Type field describes the data contained in the body fully

+enough that the mail reader can pick an appropriate mechanism to

+present the data to the user, or otherwise deal with the data in an

+appropriate manner.

+

+The Content-Type header field is used to specify the nature of data in

+the body or body part, by giving type and subtype identifiers, and by

+providing parameters that may be needed for certain types.  After the

+type and subtype names, the remainder of the header field is a set of

+parameters, specified in an attribute/value notation.  The set of

+meaningful parameters differs for different types.  The order of

+parameters is not significant.  Comments are allowed (in accordance

+with RFC 822 rules) in structured header fields by placing them in

+parentheses.

+

+The top-level Content-Type is used to declare the general type of

+data, while the subtype specifies a specific format for that type of

+data.  Thus, a Content-Type of Image/xyz is enough to tell a mail

+reader that the data is an image, even if the mail reader has no

+knowledge of the specific image format xyz.  Such information can be

+used, to decide whether or not to show a user the raw data from an

+unrecognized subtype -- such an action might be reasonable for

+unrecognized subtypes of Text, but not for unrecognized subtypes of

+Image or Audio.  For this reason, registered subtypes of Audio, Image,

+Text, and Video, should not contain embedded information that is

+really of a different type.  Such compound types are usually

+represented using the Multipart or Application types.

+

+Parameters are modifiers of the content-subtype.  Although most

+parameters make sense only with certain content-types, others are

+"global" in the sense that they might apply to any subtype.  For

+example, the Boundary parameter, which is used to indicate how body

+parts are separated from each other, makes sense only for the

+Multipart content-type.  The Charset parameter might make sense with

+several content-types.

+

+The MIME standard defines seven content-types.  The authors of the

+MIME standard state that the set of seven types is "substantially

+complete".  They expect additional supported types to be accommodated

+by creating new subtypes of the seven initial top-level types.  The

+MIME standard, functioning as a constitution for the MIME community,

+states that new standard content types can be defined only by revising

+the standard (as opposed to the registration procedure for other types

+of extensions).  However, MIME does provide for the use of

+non-standard content types.  Non-standard content-types can be used,

+but must be given names starting with X-.  Future standard content

+type names will not begin with X-.

+

+The syntax for the content type header field is

+

+    Content-Type := type "/" subtype [";" parameter]...

+

+The defined content types are:

+

+    Application

+        indicates data that does not fit into any of the other

+        categories, such as uninterpreted binary data or information

+        to be processed by a mail-based application. In addition to

+        the following subtypes, it is likely that additional subtypes

+        will be defined for applications such as mail-based scheduling

+        systems, spreadsheets and EDI.

+

+    Application/Octet-Stream

+        indicates uninterpreted binary data, which a mail reading

+        program may simply offer to write the information into a file.

+        Possible parameters for Application/Octet-Stream include:

+

+        Name

+            a suggested name for the binary data if stored as a file.

+

+        Type

+            the general type or category of binary data.  This is

+            intended for human recipients rather than for automated

+            processing.

+

+        Conversions

+            the operations that performed on the data before putting

+            it the body.  Note that the standard defines no conversion

+            values.  Any conversion values that do not begin with X-

+            must be preceded by a published specification and by

+            registration with IANA.

+

+        Padding

+            the number of bits of padding that were appended to the

+            bitstream comprising the actual contents to produce the

+            enclosed byte-oriented data.  This is useful for enclosing

+            a bitstream in a body when the total number of bits is not

+            a multiple of the byte size.

+

+    Application/ODA

+        indicates a body containing information encoded according to

+        the Office Document Architecture (ODA) standards, using the

+        ODIF representation format.  For Application/ODA, the

+        Content-Type line should also specify an attribute/value pair

+        that indicates the document application profile (DAP), using a

+        Profile parameter.  Thus an appropriate header field might

+        look like this:

+

+            Content-Type: application/oda;

+                          profile=Q112

+

+        Consult the ODA standard for further information.

+

+    Application/PostScript

+        indicates a body containing a postscript document.

+

+Audio

+    Indicates audio data.  Audio requires an audio output device (such

+    as a speaker or a telephone) to "display" the contents.

+

+    Audio/Basic

+        The content of the Audio/Basic subtype is audio encoded using

+        8-bit ISDN u-law. When this subtype is present, a sample rate

+        of 8000 Hz and a single channel is assumed.

+

+    Image

+        Image data.  Image requires a display device (such as a

+        graphical display, a printer, or a FAX machine) to view the

+        information.

+

+    Image/Jpeg

+        indicates an image in JPEG format.

+

+    Image/Gif

+        indicates an image in GIF format.

+

+Message

+    indicates an encapsulated message.

+

+    Message/Rfc822

+        indicates that the body contains an encapsulated message, with

+        the syntax of an RFC 822 message.

+

+    Message/Partial

+        indicates a partial message, allowing fragmented transmission

+        of bodies too large to be passed through mail transport

+        facilities.  Message/Partial indicates that the body contains

+        a fragment of a larger message.

+

+        Three parameters are required in a Content-Type field of type

+        Message/Partial: The first, Id, is a unique identifier, as

+        close to world-unique as possible, used to match the parts

+        together.  The second, Number, an integer, is the part number

+        indicating where this part fits into the sequence of

+        fragments.  The third, Total, another integer, is the total

+        number of parts. Total is required on the final part, and

+        optional on earlier parts.

+

+    Message/External-Body

+        indicates that the actual body data are not included, but

+        merely referenced.  In this case, the parameters describe a

+        mechanism for accessing the external data.

+

+        When a body or body part is of type Message/External-Body,

+        it consists of a header, a blank line, and the message header

+        for the encapsulated message.  If another blank line appears,

+        this ends the message header for the encapsulated message.

+        However, since the encapsulated message's body is itself

+        external, it does not appear in the area that follows.  For

+        example, consider this message:

+

+            Content-type: message/external-body;

+                          access-type=local-file;

+                          name=/u/nsb/Me.gif

+

+            Content-type: image/gif

+

+            THIS IS NOT REALLY THE BODY!

+

+        The area at the end, which constitutes a phantom body, is

+        ignored for most external-body messages.  However, it may be

+        used to contain auxiliary information for a

+        "mail-server".

+

+        The only parameter of Message/ExternalÄBody that is always

+        mandatory is Access-Type.  Its other parameters are mandatory

+        or optional depending on the value of Access-Type.  The values

+        defined for the Access-Type parameter are FTP, ANON-FTP, TFTP,

+        AFS, LOCAL-FILE, and MAIL-SERVER.  Except for values beginning

+        with X-, other values must be registered with IANA.

+

+        The standard also specifies additional parameters that are to

+        be used in conjunction with the various access types.

+

+        In addition to access-type specific parameters, the standard

+        defines the following parameters which are optional for all

+        access types:

+

+            * The Expiration parameter is used to specify a date after

+              which the existence of the external data is not

+              guaranteed. 

+

+            * The Size parameter is used to specify the size of the

+              data.

+

+Multipart

+

+    indicates data consisting of multiple body parts; each having its

+    own data type.  It is possible to tell where each body part begins

+    and ends because each body part is preceded by a special string

+    called an encapsulation boundary; the last body part is followed

+    by a closing boundary.

+

+    The boundary strings used are specified by a mandatory parameter

+    called Boundary.  The encapsulation boundary is an end of line

+    followed by two hyphens followed by the boundary parameter value

+    of the ContentÄType header field.  The closing boundary is the

+    same as the encapsulation boundary with the addition of two

+    hyphens at the end of the line.

+

+    The encapsulation boundary must not appear inside any of the

+    encapsulated parts.  It is crucial that the composing user agent

+    be able to choose and specify the unique boundary that will

+    separate the body parts.  Encapsulation boundaries may be no

+    longer than 70 characters, not counting the blank line and leading

+    hyphens.

+

+    Thus, a typical multipart Content-Type header field might look

+    like:

+

+        Content-Type: multipart/mixed; boundary=gc0y0pkb9ex

+

+    This indicates a body consisting of several body parts, each

+    having a structure syntactically identical to an RFC 822 message,

+    except that the header area may be completely empty, and each part

+    is preceded by the line

+

+        --gc0y0pkb9ex

+

+    The closing boundary following the last body part indicates that

+    no further body parts will follow.  It is identical to the

+    preceding encapsulation boundaries, with the addition of two more

+    hyphens at the end of the line:

+

+        --gc0y0pkb9ex--

+

+    There is room for additional information prior to the first

+    encapsulation boundary and following the final boundary.  These

+    areas are often blank.  Anything appearing before the first or

+    after the last boundary is ignored.

+

+    As a simple example, the following multipart message has two

+    parts, both plain text, one explicitly typed and one implicitly

+    typed:

+

+        From: Nathaniel Borenstein <nsb@bellcore.com>

+        To: Ned Freed <ned@innosoft.com>

+        Subject: Sample message

+        MIME-Version: 1.0

+        Content-type: multipart/mixed;

+                      boundary="simple boundary"

+

+        This is the preamble.  It is to be ignored, though it is a

+        handy place for mail composers to include an explanatory note

+        to non-MIME compliant readers.

+

+        --simple boundary

+

+        This is implicitly typed plain ASCII text.

+        --simple boundary

+        Content-type: text/plain; charset=us-ascii

+

+        This is explicitly typed plain ASCII text.

+        It DOES end with a line break.

+

+        --simple boundary--

+        This is the epilogue.  It is also to be ignored.

+

+    The use of a Content-Type of multipart in a body part within

+    another multipart entity is explicitly allowed.  In such cases,

+    care must be taken to ensure that each nested multipart entity

+    uses a different boundary delimiter.

+

+    The use of the multipart Content-Type with only a single body part

+    may be useful in certain contexts, and is explicitly permitted.

+

+    Multipart/Mixed

+        indicates multiple independent body parts to be viewed

+        serially.

+

+    Multipart/Alternative

+        is syntactically identical to Multipart/Mixed.  Each part is

+        an "alternative" version of the same information.  Mail

+        readers should recognize that the content of the parts are

+        interchangeable.  The mail reader should either choose the

+        "best" type based on the user's environment and preferences,

+        or offer the user the available alternatives.  Generally,

+        choosing the best type means displaying only the last part

+        that can be displayed.  This may be used, for example, to send

+        mail in a fancy text format in such a way that it can easily

+        be displayed anywhere:

+

+            From:  Nathaniel Borenstein <nsb@bellcore.com>

+            To: Ned Freed <ned@innosoft.com>

+            Subject: Formatted text mail

+            MIME-Version: 1.0

+            Content-Type: multipart/alternative;

+                          boundary=boundary42

+

+

+            --boundary42

+            Content-Type: text/plain; charset=us-ascii

+

+            ...plain text version of message goes here...

+            --boundary42

+            Content-Type: text/richtext

+

+            ... richtext version of same message goes here ...

+            --boundary42

+            Content-Type: text/x-whatever

+

+            ... fanciest formatted version of same message goes here

+            ...

+            --boundary42--

+

+        In this example, users whose mail system understood the

+        text/x-whatever format would see only the fancy version,

+        while other users would see only the richtext or plain text

+        version, depending on the capabilities of their system.

+

+        Some mail reading programs that recognize more than one of the

+        formats will offer the user a choice of which format to view.

+        This makes sense, for example, if mail includes both a nicely

+        formatted image version and an easily edited text version.

+        The point is that multiple versions of the same data are not

+        automatically shown.  Either the user is shown the last

+        recognized version or explicitly given the choice.

+

+    Multipart/Parallel

+        is syntactically identical to Multipart/Mixed.  However, in a

+        parallel body, all of the body parts are intended to be

+        presented simultaneously on hardware and software that are

+        capable of doing so.  Composing agents should be aware that

+        many mail readers will lack this capability and will show the

+        parts serially in any event.

+

+        Multipart/Parallel will likely be used for multimedia messages

+        that combine such message types as text, audio and/or video.

+

+    Multipart/Digest

+        Indicates that each of the body parts is an RFC 822 mail

+        message.  Multipart/Digest is syntactically identical to

+        Multipart/Mixed, except that the default Content-Type value

+        for a body part is changed from Text/Plain to Message/Rfc822.

+

+Text

+    The text Content-Type is for sending material that is principally

+    textual in form.  It is the default Content-Type.  A Charset

+    parameter may be used to indicate the character set of the text.

+    The default Content-Type for Internet mail is

+        text/plain; Charset=US-ASCII.

+

+    The value of the Charset parameter is not case sensitive.

+    Allowable values are US-ASCII, ISO-8859-1, ISO-8859-2, ... and

+    ISO-8859-9. The default value for Charset is US-ASCII.

+

+    Text/Plain

+        indicates plain (unformatted) text.  No special software is

+        required to get the full meaning of the text, aside from

+        support for the indicated character set.  Other subtypes

+        should be used for enriched text in forms where application

+        software may enhance the appearance of the text, but such

+        software must not be required in order to get the general idea

+        of the content.  Possible future subtypes include any readable

+        word processor format.

+

+    Text/Richtext

+        indicates a simple portable word processing format that is

+        defined by the MIME standard.  It is a very small subset of

+        SGML.  Mail readers that implement Richtext may implement only

+        a subset of it.

+

+        When a mail composing program is given a file in a word

+        processing format to send and there is no standardized subtype

+        for that format, then the message composing program may

+        reformat the file into richtext format which will preserve

+        more of the original formatting information than reformatting

+        the file to plain ASCII.

+

+Video

+    indicates that the body contains a time-varying-picture image,

+    possibly with color and coordinated sound.  The term Video is

+    used very generically and does not refer to any particular

+    technology or format.  It is not meant to preclude subtypes

+    such as animated drawings encoded compactly.

+

+    Video/Mpeg

+        indicates video coded according to the MPEG standard.

+

+x-TypeName

+    This is any type name that begins with X-.  A Content-Type value

+    beginning with X- is a private value, to be used by consenting

+    mail systems by mutual agreement.  The standard specifies no

+    subtypes.

+

+No type may be specified without a subtype.

+

+The standard allows the use of additional sub-types without having to

+change the standard.  However, it is important to insure that

+sub-types used by different user communities of MIME do not conflict.

+It would be confusing if Content-Type: application/foobar meant two

+different things.  The standard specifies two mechanisms for defining

+new Content-Type subtypes:

+

+1.  Private values (starting with X-) may be defined between

+    cooperating mail composing and reading programs without outside

+    registration.  Use of this mechanism requires knowing that the

+    reader of the message will not mistake the content type for

+    something other than originally intended.

+

+2.  New standard values must be registered with IANA.  Where intended

+    for public use, the formats they refer to must also be defined by

+    a published specification.

+

+Messages that do not have a Content-Type field in their header are

+displayed by user agents as if

+

+    Content-Type: Text/plain; Charset=US-ASCII

+

+had been specified.

+

+When a mail reader encounters mail with an unknown Content-Type value,

+it will generally treat it as equivalent to application/octet-stream.

+

+

+The Content-Transfer-Encoding Header Field

+

+Many Content-Types which could usefully be transported via e-mail are

+represented, in their "natural" format, as 8-bit character or binary

+data.  Such data cannot be transmitted over some transport protocols.

+For example, SMTP (Simple Mail Transfer Protocol is an Internet

+standard for transporting e-mail defined by a document called RFC 821)

+restricts mail messages to 7-bit ASCII data with lines no longer than

+1000 characters.

+

+MIME provides two mechanisms for re-encoding such data into a 7-bit

+short-line format.  The Content-Transfer-Encoding header field

+indicates the mechanism used to perform such an encoding.  The

+Content-Transfer-Encoding field indicates the transformation that has

+been used to represent the body in an acceptable manner for transport.

+

+The possible values for the Content-Transfer-Encoding field are:

+        BASE64

+        QUOTED-PRINTABLE

+        8BIT

+        7BIT

+        BINARY

+        x-EncodingName

+These values are not case sensitive.  That is, Base64, BASE64 and

+bAsE64 are all equivalent.  An encoding type of 7BIT requires that the

+body is already in a 7-bit mail-ready representation.  That is the

+default value: Content-Transfer-Encoding: 7BIT is assumed if the

+Content-Transfer-Encoding header field is not present.

+

+Both BASE64 and the QUOTED-PRINTABLE imply an encoding that consists

+of lines no longer than 76 ASCII characters.  In other respects the

+two encoding schemes are very different.

+

+The encoding scheme implied by QUOTED-PRINTABLE is most appropriate

+for data that consists primarily of printable ASCII characters. Using

+this encoding method, printable ASCII character are represented as

+themselves.  The equals sign (=) serves as an escape character.  Any

+character that is not a printable or white space ASCII character is

+represented as an equals sign followed by two hexadecimal digits.  An

+equals sign in the message is also represented in this way.  Lines

+that are longer than 76 characters are cut off after the 75th

+character and the line ends with a equals sign.

+

+The advantages of using the QUOTED-PRINTABLE encoding for message that

+are mostly printable ASCII characters are that few additional

+characters are required and the message can be read by human beings

+who to not have a MIME aware mail reading program.  As an example,

+here is an EDI interchange in QUOTED-PRINTABLE encoding:

+

+ISA*00*          *00*          *01*987654321      *12*8005551234     *910=

+607*0111*U*00200*110000777*0*T*>

+GS*PO*987654321*8005551234*920501*2032*7721*X*002003

+ST*850*000000001

+BEG*00*NE*MS1112**920501**CONTRACT#

+REF*IT*8128827763

+N1*ST*MAVERICK SYSTEMS

+N3*3312 NEW HAMPSHIRE STREET

+N4*SAN JOSE*CA*94811

+PO1*1*25*EA***VC*TP8MM*CB*TAPE8MM

+PO1*2*30*EA***VC*TP1/4*CB*TAPE1/4INCH

+PO1*3*125*EA***VC*DSK31/2*CB*DISK35

+CTT*3

+SE*11*000000001

+GE*1*7721

+IEA*1*110000777

+

+Except for the ISA segment having been wrapped onto two lines, the

+QUOTED-PRINTABLE encoding of the interchange is identical to its 7BIT

+representation.

+

+The BASE64 encoding mechanism is well suited for representing binary

+files.  It represents any sequence of three bytes as four printable

+ASCII characters.  The same interchange as shown above but using the

+BASE64 encoding would look like:

+

+SVNBKjAwKiAgICAgICAgICAqMDAqICAgICAgICAgICowMSo5ODc2NTQzMjEgICAgICAqMTIq

+ODAwNTU1MTIzNCAgICAgKjkxMDYwNyowMTExKlUqMDAyMDAqMTEwMDAwNzc3KjAqVCo+CkdT

+KlBPKjk4NzY1NDMyMSo4MDA1NTUxMjM0KjkyMDUwMSoyMDMyKjc3MjEqWCowMDIwMDMKU1Qq

+ODUwKjAwMDAwMDAwMQpCRUcqMDAqTkUqTVMxMTEyKio5MjA1MDEqKkNPTlRSQUNUIwpSRUYq

+SVQqODEyODgyNzc2MwpOMSpTVCpNQVZFUklDSyBTWVNURU1TCk4zKjMzMTIgTkVXIEhBTVBT

+SElSRSBTVFJFRVQKTjQqU0FOIEpPU0UqQ0EqOTQ4MTEKUE8xKjEqMjUqRUEqKipWQypUUDhN

+TSpDQipUQVBFOE1NClBPMSoyKjMwKkVBKioqVkMqVFAxLzQqQ0IqVEFQRTEvNElOQ0gKUE8x

+KjMqMTI1KkVBKioqVkMqRFNLMzEvMipDQipESVNLMzUKQ1RUKjMKU0UqMTEqMDAwMDAwMDAx

+CkdFKjEqNzcyMQpJRUEqMSoxMTAwMDA3NzcK

+

+BASE64 bears some resemblance to uuencode in both appearance and

+function.  However, uuencode uses characters that may not be processed

+properly by an EBCDIC gateway.

+

+The values 8bit, 7bit, and binary all imply that no encoding has been

+performed. However, they are useful to indicate of the kind of data

+contained in the object, and therefore of the kind of encoding that

+might need to be performed for transmission in a given transport

+system.  7bit means that the data is all represented as short lines of

+ASCII data.  8bit means that the lines are short, but there may be

+non-ASCII characters.  Binary means that not only may non-ASCII

+characters be present, but also that the lines are not necessarily

+short enough for SMTP transport.

+

+The difference between 8bit and binary is that binary does not require

+adherence to any limits on line length.  8bit and binary are intended

+for compatibility with future Internet e-mail transport standards and

+with gateways to non-Internet environments.  As of this writing there

+are no standardized Internet e-mail transports for which it is

+legitimate to include unencoded 8-bit or binary data in mail bodies.

+

+Note that the five values defined for the Content-Transfer-Encoding

+field imply nothing about the Content-Type other than the algorithm by

+which it was encoded or the transport system requirements if

+unencoded.

+

+Some implementations may support additional Content-Transfer-Encoding

+values (it is permitted but strongly discouraged by the standard).

+Any such additional values must have names that begin with X- to

+indicate its non-standard status For example:

+

+        Content-Transfer-Encoding: x-my-new-encoding.

+

+If a Content-Transfer-Encoding header field appears as part of a

+message header, it applies to the entire body of that message.  If a

+Content-Transfer-Encoding header field appears as part of a body

+part's headers, it applies only to the body of that body part.  If a

+message or body part is of type Multipart or Message, the

+Content-Transfer-Encoding must be 7bit, 8bit or Binary.

+

+The encoding mechanisms defined here explicitly encode all data in

+ASCII.  Thus, for example, suppose a message or body part has header

+fields such as:

+

+        Content-Type: text/plain; charset=ISO-8859-1

+        Content-transfer-encoding: base64

+

+This should be interpreted to mean that the body is a Base64 ASCII

+encoding of data that was originally in ISO-8859-1, and will be in

+that character set again after decoding.

+

+

+Optional Content-ID Header Field

+

+It may be desirable to allow one body to reference another.

+Accordingly, bodies may be labeled using the Content-ID header field,

+which is syntactically identical to the RFC 822 Message-ID header

+field: Content-ID values should be be as unique as possible.

+

+

+Optional Content-Description Header Field

+

+The ability to associate descriptive information with a body is often

+desirable. For example, it may be useful to mark an Image body as

+"a picture of the Space Shuttle Endeavor."  Such text may be

+placed in the Content-Description header field.

+

+

+Summary

+

+Using MIME-Version, Content-Type, and Content-Transfer-Encoding header

+fields, it is possible to include arbitrary types of data objects in

+RFC 822 conformant mail messages.  No restrictions imposed by RFC 821

+or RFC 822 are violated. MIME has been designed to avoid problems

+caused by additional restrictions imposed by some Internet mail

+transport mechanisms. The Multipart and Message content types allow

+mixing and hierarchical structuring of objects of different types in a

+single message.  Further content types provide a mechanism for tagging

+messages or body parts as audio, image, or other kinds of data.  A

+parameter syntax allows further specification of data format details,

+particularly the specification of alternate character sets.

+Additional optional header fields provide mechanisms for certain

+extensions deemed desirable by many implementors.  Finally, a number

+of useful content types are defined for general use by consenting user

+agents, notably Text/Richtext, Message/Partial, and

+Message/External-Body.

+

+To promote interoperability between user agents, the MIME standard

+specifies a minimal subset of MIME features a user agent must support

+to be considered MIME conformant.

+

+

+A Complex Multipart Example

+

+The outline of a complex multipart message follows.  This message has

+five parts to be displayed serially: two introductory plain text

+parts, an embedded multipart message, a richtext part, and a closing

+encapsulated text message in a non-ASCII character set.  The embedded

+multipart message has two parts to be displayed in parallel, a picture

+and an audio fragment.

+

+    MIME-Version: 1.0

+    From: Nathaniel Borenstein <nsb@bellcore.com>

+    Subject: A multipart example

+    Content-Type: multipart/mixed;

+                  boundary=unique-boundary-1

+

+    This is the preamble area of a multipart message.  Mail readers

+    that understand multipart format should ignore this preamble.

+    If you are reading this text, you might want to consider changing

+    to a mail reader that understands how to properly display

+    multipart messages.

+    --unique-boundary-1

+

+    Some text appears here...

+    [Note that the preceding blank line means

+    no header fields were given and this is text,

+    with charset US ASCII.  It could have been

+    done with explicit typing as in the next part.]

+

+    --unique-boundary-1

+    Content-type: text/plain; charset=US-ASCII

+

+    This could have been part of the previous part, but illustrates

+    explicit versus implicit typing of body parts.

+

+    --unique-boundary-1

+    Content-Type: multipart/parallel; boundary=unique-boundary-2

+

+    --unique-boundary-2

+    Content-Type: audio/basic

+    Content-Transfer-Encoding: base64

+

+    ... base64-encoded 8000 Hz single-channel

+    u-law-format audio data goes here ...

+

+    --unique-boundary-2

+    Content-Type: image/gif

+    Content-Transfer-Encoding: Base64

+

+    ... base64-encoded image data goes here...

+

+    --unique-boundary-2--

+

+    --unique-boundary-1

+    Content-type: text/richtext

+

+    This is <bold><italic>richtext.</italic></bold><nl><nl>Isn't it

+    <bigger><bigger>cool?</bigger></bigger>

+

+    --unique-boundary-1

+    Content-Type: message/rfc822

+

+    From: (name in US-ASCII)

+    Subject: (subject in US-ASCII)

+    Content-Type: Text/plain; charset=ISO-8859-1

+    Content-Transfer-Encoding: Quoted-printable

+

+    ... Additional text in ISO-8859-1 goes here ...

+

+    --unique-boundary-1--

+

diff --git a/mime64/mime64.c b/mime64/mime64.c
new file mode 100644
index 00000000..c7ddd3ed
--- /dev/null
+++ b/mime64/mime64.c
@@ -0,0 +1,795 @@
+/* mime64 */
+/* MIME base64 encoder/decoder by Karl Hahn  hahn@lds.loral.com  3-Aug-94 */
+/* modified 30-Sep-94 by Karl Hahn hahn@lds.loral.com: handle multiple
+   content */
+/* modified 12-Jan-95 by Karl Hahn hahn@lds.loral.com: handle file names
+   that are encased in quotes */
+/* modified 18-Jan-95 by Karl Hahn hahn@lds.loral.com: prevent complete
+   failure if filename in name field matches name of input file */
+/* modified 19-Jan-95 by Karl Hahn hahn@lds.loral.com: prevent early exit
+   if last decoded character falls on a multiple of 3 -- would cause error
+   message and failure to rename output file if rename was necessary */
+/* modified 19-Jan-95 by Karl Hahn hahn@lds.loral.com: prevent complete
+   failure if a line of text preceding the MIME64 stuff contains no
+   non-base64 characters */
+/* modified 19-Jan-95 by Karl Hahn hahn@lds.loral.com: fixed command
+   line parser to prevent missing a name field preceded by another
+   name field */
+/* modified 19-Jan-95 by Karl Hahn hahn@lds.loral.com: prevent error
+   message at the end of decoding each section.  Terminates output
+   file now on a blank line as well as the conditions that did so
+   previously */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+
+#ifdef __FreeBSD__
+#define	strcmpi(x,y)	strcasecmp(x,y)
+#endif
+
+char alphabet[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"
+                  "0123456789+/";
+
+enum TOKENTYPE { NONE, BLANKS, PUNCT, TAG, NAME, CONTENT };
+
+struct TOKEN {
+                char *text;
+                int  length;
+                int  index;
+                enum TOKENTYPE type;
+             };
+
+int compare_token( struct TOKEN *token, char *text )
+{
+   int index=0;
+   int count;
+   int result;
+   char blivit1, blivit2;
+
+   count = token->length;
+
+   if ( count > 0 )
+   {
+      result = 1;
+   }
+   else
+   {
+      result = 0;
+   }
+
+   while ( (count > 0) && ( result != 0 ) )
+   {
+      blivit1 = token->text[index++];
+      if ( (blivit1 >= 'a' ) && (blivit1 <= 'z') )
+      {
+         blivit1 -= ' ';
+      }
+
+      blivit2 = *text++;
+      if ( (blivit2 >= 'a' ) && (blivit2 <= 'z') )
+      {
+         blivit2 -= ' ';
+      }
+
+      if ( blivit1 != blivit2 )
+      {
+         result = 0;
+      }
+
+      count--;
+   }
+
+   return result;
+}
+
+int ispunct( char blivit )
+{
+   if ( ( blivit >= 'a' ) && (blivit <= 'z' ) )
+   {
+      blivit -= ' ';
+   }
+
+   if ( ( ( blivit < '0' ) ||
+          ( ( blivit > '9' ) && (blivit < 'A') ) ||
+          ( blivit > 'Z' ) ) &&
+        ( blivit != '-') && (blivit != '/') && (blivit != '.') )
+   {
+      return 1;
+   }
+   else
+   {
+      return 0;
+   }
+}
+
+void fixname( char *name )
+{
+   while ( *name != '\0' )
+   {
+
+     if (ispunct( *name ) )
+     {
+        *name = '\0';
+     }
+
+     name++;
+   }
+}
+
+void acquire_token( char *line, enum TOKENTYPE type, struct TOKEN *token )
+{
+   int doneflag=0, startflag=1;
+   int index;
+   enum TOKENTYPE nextstate=NONE;
+   char blivit;
+
+   if (token->type == NONE)
+   {
+      token->index = 0;
+      token->length = 0;
+   }
+
+   index = token->index + token->length;
+
+   token->text = 0;
+
+   while ( doneflag == 0 )
+   {
+      blivit = line[index];
+      if ( (blivit >= 'a') && (blivit <= 'z') )
+      {
+         blivit -= ' ';
+      }
+
+      switch (token->type)
+      {
+         case NONE:
+         if ( blivit == ' ')
+         {
+            index++;
+            token->index++;
+         }
+         else
+         {
+            token->type = TAG;
+            nextstate = TAG;
+         }
+         break;
+
+         case BLANKS:
+         if      ( blivit == ' ')
+         {
+            index++;
+         }
+         else if ( ispunct( blivit ) )
+         {
+            token->type = PUNCT;
+            token->index = index;
+         }
+         else
+         {
+            token->type = nextstate;
+            token->index = index;
+         }
+         break;
+
+         case PUNCT:
+         if      ( blivit <  ' ')
+         {
+            doneflag = 1;
+            token->type = NONE;
+            token->index = index;
+            token->text = line + index;
+            token->length = 0;
+         }
+         else if ( blivit == ' ' )
+         {
+            token->type = BLANKS;
+            token->index = index;
+            if      ( line[ token->index ] == ';' )
+            {
+               nextstate = NAME;
+            }
+            else if ( line[ token->index ] == '=' )
+            {
+               nextstate = CONTENT;
+            }
+
+         }
+         else if ( ispunct( blivit ) )
+         {
+            index++;
+         }
+         else
+         {
+            if      ( line[ token->index ] == ';' )
+            {
+               nextstate = NAME;
+            }
+            else if ( line[ token->index ] == '=' )
+            {
+               nextstate = CONTENT;
+            }
+
+            token->type = nextstate;
+            token->index = index;
+         }
+         break;
+
+         case TAG:
+         if ( ispunct( blivit ) )
+         {
+            token->length = index - token->index;
+            token->text = line + token->index;
+            nextstate = NAME;
+
+            if ( ( ( type == TAG ) || ( type == NONE ) ) && !startflag)
+            {
+               doneflag = 1;
+            }
+            else if (blivit == ' ')
+            {
+               token->type = BLANKS;
+               token->index = index;
+            }
+            else
+            {
+               token->type = PUNCT;
+               token->index = index;
+            }
+         }
+         else
+         {
+            index++;
+         }
+         break;
+
+         case NAME:
+         if ( ispunct( blivit ) )
+         {
+            token->length = index - token->index;
+            token->text = line + token->index;
+
+            if ( blivit != ';' )
+            {
+               nextstate = CONTENT;
+            }
+            else
+            {
+               nextstate = NAME;
+            }
+
+            if ( ( ( type == NAME ) || ( type == NONE ) ) && !startflag )
+            {
+               doneflag = 1;
+            }
+            else if (blivit == ' ')
+            {
+               token->type = BLANKS;
+               token->index = index;
+            }
+            else
+            {
+               token->type = PUNCT;
+               token->index = index;
+            }
+         }
+         else
+         {
+            index++;
+         }
+         break;
+
+         case CONTENT:
+         if ( ispunct( blivit ) )
+         {
+            token->length = index - token->index;
+            token->text = line + token->index;
+            nextstate = NAME;
+
+            if ( ( ( type == CONTENT ) || ( type == NONE ) ) && !startflag )
+            {
+               doneflag = 1;
+            }
+            else if (blivit == ' ')
+            {
+               token->type = BLANKS;
+               token->index = index;
+            }
+            else
+            {
+               token->type = PUNCT;
+               token->index = index;
+            }
+         }
+         else
+         {
+            index++;
+         }
+         break;
+      }
+      startflag = 0;
+   }
+}
+
+void fputch( char blivit, FILE *f )
+{
+/*   if (blivit == '\n') fputc( '\r', f );*/
+   fputc( blivit, f );
+}
+
+int classify_args( int narg,
+                   char *rawargs[], char *fileargs[], char *optargs[] )
+{
+   int index, jndex, kndex;
+   char *argptr;
+
+   for ( index = 0, jndex = 0, kndex = 0; index < narg; index++ )
+   {
+      argptr = rawargs[index];
+      if (*argptr == '-')
+      {
+         argptr++;
+         optargs[kndex++] = argptr;
+      }
+      else
+      {
+         fileargs[jndex++] = argptr;
+      }
+   }
+
+   return kndex;
+}
+
+int cvt_ascii( unsigned char alpha )
+{
+   if      ( (alpha >= 'A') && (alpha <= 'Z') ) return (int)(alpha - 'A');
+   else if ( (alpha >= 'a') && (alpha <= 'z') )
+        return 26 + (int)(alpha - 'a');
+   else if ( (alpha >= '0') && (alpha <= '9' ) )
+        return 52 + (int)(alpha - '0');
+   else if ( alpha == '+' ) return 62;
+   else if ( alpha == '/' ) return 63;
+   else if ( alpha == '=' ) return -2;
+   else                     return -1;
+}
+
+char *fileargs[64], *optargs[64];
+
+struct STATE64 {
+                  unsigned long int accum;
+                  int               shift;
+               };
+
+
+int main( int nargs, char *cargs[] )
+{
+   int n_options, n_files, index, jndex, shift, save_shift;
+   enum { ENCODE, DECODE } whattodo = DECODE;
+   int help_flag = 0, replace_flag = 0, perm_replace_flag = 0, quit = 0;
+   int cycle_flag = 0;
+   FILE *fin, *fout = NULL, *dummy;
+   unsigned char blivit;
+   unsigned long accum, value;
+   char buf[80], dumname[80];
+   char *cptr, *altptr;
+   int decode_state;
+   struct TOKEN token;
+   int firsttime = 1;
+   int skipflag = 0;
+   int printmsg = 1;
+   int outcount = 0;
+
+   n_options = classify_args( nargs, cargs, fileargs, optargs );
+
+   n_files = nargs - n_options;
+
+   if ( n_files < 2 ) help_flag = 1;
+
+   for ( index = 0; index < n_options; index++ )
+   {
+      if ( ( optargs[index][0] == 'e' ) ||
+           ( optargs[index][0] == 'E' ) ) whattodo = ENCODE;
+      if ( optargs[index][0] == '?' ) help_flag = 1;
+   }
+
+   if ( help_flag )
+   {
+      printf( "mime64 infile [outfile] [-option] [-option] etc.\n\n"
+              "convert between binary and MIME BASE64 format\n\n"
+              "        -e       MIME base64 encode (default is decode)\n"
+              "        -?       display help message\n\n"
+              "if no outfile given, output file replaces infile\n" );
+   }
+
+   if ( n_files < 2 ) exit(0);
+
+   if ( whattodo == DECODE )
+   {
+      fin = fopen( fileargs[1], "r" );
+   }
+   else
+   {
+      fin = fopen( fileargs[1], "rb" );
+   }
+
+   if ( fin == 0 )
+   {
+      printf( "%s file not found\n", fileargs[1] );
+      exit(-1);
+   }
+
+   if ( n_files > 2 )
+   {
+      if ( whattodo == DECODE )
+      {
+         sprintf( dumname, "%s", fileargs[2] );
+      }
+      else
+      {
+         fout = fopen( fileargs[2], "w" );
+
+	 if ( fout == 0 )
+	 {
+	    printf( "Couldn't open %s for output\n", fileargs[2] );
+	 }
+      }
+   }
+   else
+   {
+      if ( whattodo == DECODE )
+      {
+         sprintf( dumname, "%s", fileargs[1] );
+      }
+      else
+      {
+         fout = fopen( "$$$$$$$$.$$$", "w" );
+      }
+
+      replace_flag = 1;
+   }
+
+
+do {
+   quit = 0;
+   printmsg = 1;
+
+   if ( whattodo == DECODE )
+   {
+      shift = 0;
+      accum = 0;
+      decode_state = 0;
+
+      while ( ( !feof( fin ) ) && (quit == 0) )
+      {
+         fgets( buf, 80, fin );
+         if ( feof( fin ) )
+         {
+            if ( ( dumname[0] != '\0' ) && ( shift != 0 ) )
+            {
+               printf( "Unexpected end of file encountered in %s\n"
+                       "last few bytes may have been lost\n", dumname );
+               quit = 1;
+               decode_state = 1;
+               continue;
+            }
+            else if ( cycle_flag == 0 )
+            {
+               quit = 1;
+               decode_state = 1;
+               continue;
+            }
+         }
+         else
+         {
+            cycle_flag = 1;
+
+            if ( (decode_state == 1) &&
+                 ( (buf[0] == '\n') || (buf[0] < '+') ) )
+            {
+               quit = 1;
+
+               if ( shift != 0 )
+               {
+                  printf( "Unexpected end of section in %s\n"
+                          "last few bytes may have been lost\n", dumname );
+               }
+
+               continue;
+            }
+         }
+
+
+         if ( decode_state == 0 )
+         {
+            for ( index = 0;
+                  (buf[index] != '\n') && (buf[index] != '\0') &&
+                  (decode_state >= 0);
+                  index++ )
+            {
+               if ( ( (buf[index] >= 'A') && (buf[index] <= 'Z') ) ||
+                    ( (buf[index] >= 'a') && (buf[index] <= 'z') ) ||
+                    ( (buf[index] >= '0') && (buf[index] <= '9') ) ||
+                    (buf[index] == '+') ||
+                    (buf[index] == '/') ||
+                    (buf[index] == '=') )
+               {
+                  decode_state = 1;
+               }
+               else
+               {
+                  decode_state = -2;
+               }
+            }
+
+            if ( decode_state <= 0 )
+            {
+
+               decode_state = 0;
+               token.type = NONE;
+
+               acquire_token( buf, TAG, &token );
+               if      ( compare_token( &token, "Content-Type") )
+               {
+                  do
+                  {
+                     acquire_token( buf, NAME, &token );
+                     if ( compare_token( &token, "name" ) )
+                     {
+                        acquire_token( buf, CONTENT, &token );
+
+                        if ( ( replace_flag ) ||
+                             ( firsttime == 0 ) )
+                        {
+                           sscanf( token.text, "%s", dumname );
+                           fixname( dumname );
+
+                           if ( strcmpi( dumname, fileargs[1] ) != 0 )
+                           {
+                              replace_flag = 0;
+                           }
+                           else
+                           {
+                              if ( perm_replace_flag )
+                              {
+                                 printf( 
+                                 "More than one output file named %s\n",
+                                 dumname );
+
+                                 exit(-1);
+                              }
+                           }
+                        }
+                     }
+                  } while ( token.type != NONE );
+               }
+               else if ( compare_token( &token, "Content-transfer-encoding" ) )
+               {
+                  skipflag = 1;
+
+                  do
+                  {
+                     acquire_token( buf, NAME, &token );
+                     if ( compare_token( &token, "base64" ) )
+                     {
+                        skipflag = 0;
+                     }
+                  } while ( token.type != NONE );
+               }
+               continue;
+            }
+            else if ( skipflag != 0 )
+            {
+               continue;
+            }
+         }
+
+         if ( printmsg )
+         {
+            if ( skipflag )
+            {
+               printf( "Section %s not MIME base64\n", dumname );
+            }
+            else
+            {
+               printf( "Creating %s\n", dumname );
+               if ( strcmpi( dumname, fileargs[1] ) == 0 )
+               {
+                  replace_flag = 1;
+               }
+
+               if ( replace_flag )
+               {
+                  fout = fopen( "$$$$$$$$.$$$", "wb" );
+               }
+               else
+               {
+                  fout = fopen( dumname, "wb" );
+               }
+
+               if ( fout == 0 )
+               {
+                  printf( "Couldn't open %s for output\n", dumname );
+               }
+            }
+
+            printmsg = 0;
+         }
+
+         if ( fout == 0 )
+         {
+            printf( "No filename given for subsequent section\n" );
+            exit(-1);
+         }
+
+         if ( feof(fin) )
+         {
+            quit = 1;
+         }
+
+         if ( quit != 0 )
+         {
+            buf[0] = '\0';
+         }
+
+         for ( index = 0; (buf[index] != '\n') && (buf[index] != '\0'); index++)
+         {
+            value = cvt_ascii( buf[index] );
+
+            if ( value < 64 )
+            {
+               accum <<= 6;
+               shift += 6;
+               accum |= value;
+               if ( shift >= 8 )
+               {
+                  shift -= 8;
+                  value = accum >> shift;
+                  blivit = (unsigned char)value & 0xFFl;
+                  fputc( blivit, fout );
+               }
+            }
+            else
+            {
+               quit = 1;
+               break;
+            }
+         }
+      }
+   }
+   else
+   {
+      fprintf ( fout,
+       "Content-Type: text/plain; charset=US-ASCII; name=%s\n"
+       "Content-transfer-encoding: base64\n\n", fileargs[1] );
+
+      shift = 0;
+      accum = 0;
+      index = 0;
+      while ( ( !feof( fin ) ) || (shift != 0) )
+      {
+         if ( ( !feof( fin ) ) && ( quit == 0 ) )
+         {
+            blivit = fgetc( fin );
+
+            if ( feof( fin ) )
+            {
+               quit = 1;
+               save_shift = shift;
+               blivit = 0;
+            }
+         }
+         else
+         {
+            quit = 1;
+            save_shift = shift;
+            blivit = 0;
+         }
+
+         if ( (quit == 0) || (shift != 0) )
+         {
+            value = (unsigned long)blivit;
+            accum <<= 8;
+            shift += 8;
+            accum |= value;
+         } /* ENDIF */
+
+         while ( shift >= 6 )
+         {
+            shift -= 6;
+            value = (accum >> shift) & 0x3Fl;
+            blivit = alphabet[value];
+
+            buf[index++] = blivit;
+            if ( index >= 60 )
+            {
+               buf[index] = '\0';
+               fprintf( fout, "%s\n", buf );
+               index = 0;
+            }
+
+            if ( quit != 0 )
+            {
+               shift = 0;
+            }
+         }
+      }
+
+      if      ( save_shift == 2 )
+      {
+         buf[index++] = '=';
+         if ( index >= 60 )
+         {
+            buf[index] = '\0';
+            fprintf( fout, "%s\n", buf );
+            index = 0;
+         }
+
+         buf[index++] = '=';
+         if ( index >= 60 )
+         {
+            buf[index] = '\0';
+            fprintf( fout, "%s\n", buf );
+            index = 0;
+         }
+      }
+      else if ( save_shift == 4 )
+      {
+         buf[index++] = '=';
+         if ( index >= 60 )
+         {
+            buf[index] = '\0';
+            fprintf( fout, "%s\n", buf );
+            index = 0;
+         }
+      }
+
+      if ( index != 0 )
+      {
+         buf[index] = '\0';
+         fprintf( fout, "%s\n", buf );
+      }
+   }
+
+   if ( fout )
+   {
+      ++outcount;
+      fclose( fout );
+   }
+
+   if ( replace_flag )
+   {
+      perm_replace_flag = 1;
+
+      if ( ( whattodo == DECODE ) && ( decode_state <= 0 ) && ( outcount == 0 ) )
+      {
+         remove( "$$$$$$$$.$$$" );
+         printf( "No MIME base64 lines found in %s\n", fileargs[1] );
+      }
+   }
+   else
+   {
+      if ( ( whattodo == DECODE ) && ( decode_state <= 0 ) && ( outcount == 0 ) )
+      {
+         remove( fileargs[2] );
+         printf( "No MIME base64 lines found in %s\n", fileargs[1] );
+      }
+   }
+
+   fout = 0;
+   firsttime = 0;
+   dumname[0] = '\0';
+   cycle_flag = 0;
+
+} while ( !feof( fin ) );
+
+
+if ( perm_replace_flag )
+{
+   remove( fileargs[1] );
+   rename( "$$$$$$$$.$$$", fileargs[1] );
+}
+
+fclose( fin );
+}