www.openlinksw.com
docs.openlinksw.com

Book Home

Contents
Preface

Internet Services

WebDAV Server
URIQA Semantic Web Enabler
Mail Delivery & Storage
NNTP Newsgroups
MIME & Internet Messages
About Simple Internet (RFC 822) Messages MIME Messages - Extension to Simple Internet Messages S/MIME Support
FTP Services
VSP Guide
LDAP

18.5. MIME & Internet Messages

18.5.1. About Simple Internet (RFC 822) Messages

RFC 822 messages have two major parts:

This structure can be seen in the following illustration:

The structure of an Internet mail
Figure: 18.5.1.1. The structure of an Internet mail
Simple Internet Mail Message

As you can see in the following sample of a message's contents, the format described in RFC 822 produces messages readable with little difficulty by humans.

The first few lines, from the first instance of "Received" to "Precedence", are headers. These lines define the recipients, the sender, the date, and other information involved with message transmission.

Following the headers is a blank line. This is marked by the consecutive occurrence of the four characters: CR, LF, CR, LF. After this blank line starts the body of the message. In the following example, only the final few lines make up the message body.

Received: from techsupp@openlinksw.co.uk
Message-Id: <v1214040cad6a13935723@>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 4 Jun 1998 09:43:14 -0800
To: customer.services@openlinksw.co.uk
From: OpenLink Technical Support <techsupp@openlinksw.co.uk>
Subject: Happy Reading
Precedence: bulk

Hope you are enjoying this chapter,
Technical Support
See Also:

RFC 822 at www.rfc-editor.org


18.5.2. MIME Messages - Extension to Simple Internet Messages

MIME (Multipurpose Internet Mail Extensions) grew out of a need to encapsulate messages within messages. It includes multipart messages comprising a variety of file types such as images, audio, and video. MIME does all this while following all the standard SMTP and RFC 822 mail rules. MIME messages can be constructed to transport mail over any mail transport system that is compliant with SMTP. MIME is able to transmit objects with varying ranges of complexity in a way that allows any MIME-compliant user agent (UA) to faithfully process them and hand them off to an appropriate application. The multiple parts are arranged so that the parts requiring the least sophisticated UA are at the beginning of the message. In fact, most MIME UAs include courtesy text when constructing messages to give users of non-MIME UAs an indication of the message content. This courtesy text is inserted ahead of any MIME parts.

MIME is consistent with Internet mail protocols using headers and bodies. It allows for transmission of 7-bit printable US-ASCII characters and maximum 1000-character lines in message bodies over all Internet mail transports. It has become the most widely used extension to the simple e-mail standard. It is also used as a transport mechanism in Web pages.

Each content body part is made up of header fields and content. The headers convey specific information about the content for the message recipient. The content can be essentially any serialized stream of bytes, such as binary data or HTML. When necessary, the content is encoded so that the entire body complies with RFC 822. If the content is encoded, MIME defines the header Content-Transfer-Encoding to specify the mechanism. Other details are sometimes included, such as the Content-Disposition, which indicates to the recipient whether the content is to be treated simply as an attachment, or whether it is to be rendered inline with other content in other body parts.

A simple MIME message sample

Mime message including a picture stored as a file GIF format. Because .gif files use 8-bit bytes, and the RFC 822 format requires messages to contain only US-ASCII text, the picture data must be encoded. For the recipient to correctly decode and display the picture, it needs information about which encoding mechanism was used. The following example shows part of a MIME header that identifies that the content is a .gif file, that it is encoded using the standard base64 algorithm, and that it is to be treated by the e-mail client as an attachment.

Content-Type: image/gif;
     name="picture.gif"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
     filename="picture.gif"

[encoded content here]
...

MIME accomplishes this simplifying and rebuilding of complex files by encoding a file and transporting it as a message body, or a series of messages with component parts of the file. A MIME-compliant user agent (UA) on the receiving end can decode the message, presenting it to the reader or providing it to another application as a file. A UA that is not MIME-compliant will be able to process a MIME-encoded mail message, but may not be able to decode the message.

MIME defines a message format that allows for:

Sample MIME Message

MIME uses headers and separators to tell a UA what processing is required to re-create the message. An example with no encoded body parts is:

From: OpenLink Support <techsupp@openlinksw.co.uk>
MIME-Version: 1.0
Content-Type: multipart/mixed;
        boundary="XXXXboundary text"

This is a multipart message in MIME format.

--XXXXboundary text
Content-Type: text/plain

here is the body text

--XXXXboundary text
Content-Type: text/plain;
Content-Disposition: attachment;
        filename="test.txt"

this is the attachment text

--XXXXboundary text--

This example shows the use of a MIME message to send a text message and an attached text file. Both are body parts of this message.

The "MIME-Version:" header tells the receiving UA to treat this as a MIME message.

The "Content-Type:" header specifies "multipart/mixed". This tells the receiving UA that this message has parts separated by the string argument defined in "boundary=". A MIME-compliant UA will only display or otherwise process content following the specified "boundary=" text strings. The actual boundaries are constructed using the "boundary=" string, prepended by "--". The final body part is followed by the "boundary=" string with the "--" both prepended and appended.

In the preceding example, the courtesy message "This is a multipart message in MIME format." will not be displayed or otherwise processed by the MIME UA since it does not follow a "boundary=" string. A UA that does not support MIME will display it, and at least this part of the message will be readable no matter what features the reader supports. If our example had encoded parts, they would make no sense to the human reader using a non-MIME-compliant UA, but at least the courtesy message would give the user a hint as to why.

There are two message body parts in our example. Each body part has headers of its own, in addition to the overall message headers. Each body-part begins with the boundary string. If there were no headers in the body parts, then the blank line that must follow headers in RFC 822 messages would follow the boundary string. The first body part is a plain text message. It is the message the sender might have typed into a UA. Its single "Content-Type:" header identifies it as "text/plain", meaning US-ASCII characters are used exclusively and any UA should be able to display this body part. Text/plain is the default content type.

The second body part in this example contains the file attachment. Since the file attachment is an ASCII text file, it is sent with no encoding and its content-type is given as text/plain. The "Content-Disposition: attachment" header has an attribute, "filename=", which specifies a suggested name for the file. This header specifies that this body part is to be treated as a file rather than being displayed to the user and is to be saved on local storage under the suggested file name.

18.5.2.1. MIME Headers

MIME headers appear at the beginning of a MIME message as well as within the separate body parts. Some MIME headers can be used both as message headers and in MIME body parts. Some additional headers are defined for use only in body parts.

The following headers are defined in MIME:

There are additional headers that are applied in specialized situations, such as Content-Base and Content-Location. All of the "Content-xxx" headers have defined sub-headers, fields, and/or attributes. Headers that begin with "Content-" are the only headers that have defined meaning in body parts. All other body part headers can be ignored and might actually be removed by message transfer agents (MTAs).


18.5.2.2. MIME_TREE - MIME parser

array mime_tree (in message_text string, [in flag integer ]);

parses MIME messages into an array structure


18.5.2.3. Processing HTTP PUT of type "multipart/form-data"

When the Virtuoso server receives a PUT request of type "multipart/form-data" from the client agent, then it passes the HTTP text to the MIME_TREE function internally and adds any MIME subpart as an element pair ("name", "value") of the "params" parameter of the vsp page being specified in the URI. It also adds an additional "params" pair for each HTTP request MIME part named "attr-name" and whose value is an array of all MIME header fields of that part.

Example:

Consider the following HTTP request:

PUT handler.vsp
Content-Type: "multipart/form-data"; boundary="--end_part"

----end_part
Content-Type: image/gif
Content-Disposition: form-data; name=upload_control; filename="some image.gif"

GIF...
----end_part
Content-Type: text/plain
Content-Disposition: form-data; name=textarea

The description
----end_part--

Virtuoso parses that and produces the following params content when calling handler.vsp:

( "upload_control", "GIF....",
  "attr-upload_control", ( "Content-Type", "image/gif",
		"Content-Disposition", "form-data", "name",
		"upload_control", "filename", "some image.gif"),
  "textarea", "The description",
  "attr-textarea", ("Content-Type", "text/plain",
		"Content-Disposition", "form-data", "name",
		"textarea")
)

This allows for vsp's to handle uniformly "x-www-form/url-encoded" and "multipart/form-data" PUTS and to have full access to the MIME headers if needed.



18.5.3. S/MIME Support

S/MIME is a specification for secure electronic mail. S/MIME stands for Secure/Multipurpose Internet Mail Extensions and was designed to add security to e-mail messages in MIME format. The security services offered are authentication (using digital signatures) and privacy (using encryption).

The S/MIME specification consists of two documents: S/MIME Message Specification (RFC 2311) and S/MIME Certificate Handling (RFC 2312). Both of these are Internet Drafts. The S/MIME community has submitted these to the IETF. The goal is to form a working group and produce an Internet standard.

All certificates and private keys are read and stored as PEM encoded strings. If the server is compiled without SSL support then dummy versions of smime_sign, smime_verify, pem_certificates_to_array and get_certificate_info are available so that existing SQL code would not be broken. Currently the Virtuoso server supports S/MIME signing and S/MIME signature verification. These are done through the following 2 functions:

smime_verify()

smime_sign()

A useful utility function for S/MIME support is:

pem_certificates_to_array()