Internet Message

An Internet Message is a text document basically consisting of a header section and a body section that follows the standard that was originally described in RFC 822: Standard For the Format of ARPA Text Messages.  This standard has gone through a number of revisions but the fundamental concepts of the original standard continue to be maintained.

• Format of Internet Message
• Message Header
• Message Body
• Composite Message
• Boundary Delimiter

Format of Internet Message

The format of the Internet Message basically consists of  the following:

• Header.  The header section always appears before the body and consists of a list of fields.  A single field is made up of a field name and a field value separated by a colon.  The field is terminated by a carriage-return line-feed pair (CRLF).
• Body.  The body is optional and contains the freeform data of the message.  In a composite (or multipart) message, the body does not exist but is instead replaced with multiple sub messages or body parts.

The header and body section must be separated by an empty line.

 

Message Header

The message header section consists of a list of fields.  A header field consists of a field name and a field value separated by a colon. The field is terminated by a carriage-return line-feed pair (CRLF). 

            <field name> <colon> <field value> <CRLF>

 Example: 

            Subject: The quick brown fox 

Where:

            “Subject” is the field name.
            “The quick brown fox” is the field value.

The header section of the message can contain a list of fields that must follow each other in succession and not separated by any empty line.  When the header gets too long, the field value is terminated with a CRLF, and continues to the next line preceded by a character space.  This is known as folding. 

The following is an example of a header, called "Subject", that is being folded:

Notice how the next line -- " lazy dog" -- is preceded by a space.  When this header is read, it will replace any <CRLF><single space> sequence with a concatenate operation, such that the resulting field value above will be stored as "The quick brown fox jumps over the lazy dog." Note that folding only applies to the the field value and not on the text of the message body.

Following the list of headers in the message is an empty line, which indicates the end of the header section.  There must NOT be an empty line between the headers, otherwise the list of headers following the empty line will be accepted as the body of the message. 

The following is a sample of an internet message showing how the header and body is separated by an empty line:

Message Body

The body holds the following properties:

• Data in the body is treated as binary. 
• There is no limitation to the size of the data in the body barring limitations imposed by disk space. 
• There is no limitation to the number of characters allowed in a single line.  To format the body to a specific number of characters per line, the WrapText method can be used to  insert carriage-return line-feed pair (CRLF) into the text.
• The body in a body part (sub message) of a composite message does not include the CRLF that starts the boundary delimiter that terminates the body part.  For example, consider the following internet message.  It is a composite message with only one body part, and the boundary string is "boundary.string" as specified by the Content-Type header boundary parameter.  The closing boundary "--boundary.string--" terminates the body part.

  

  The diagram below shows how the body is extracted apart from the closing boundary delimiter.  The left side of the diagram displays the byte representation of the message.  On the right side is the text representation of the message.  The CRLF is represented by the bytes 0D 0A sequence, and is part of the closing boundary that is highlighted in blue.  The gray highlight is the body that is extracted from the body part, which does not include the trailing CRLF.

  

Composite Message

In a composite message, the single body is replaced by multiple sub messages separated by a boundary string.  The composite message must have the “Content/Type” header which specifies the type of composite message -- “multipart” or “message” – and specifies the boundary string in the “boundary” parameter.

Example of composite message:

In a nutshell, a composite message has the following properties:

• Each body part is itself an internet message consisting of a header and body section.
• The body parts are separated by a boundary.
• Any text preceding the first body part is treated as the preamble.  This text is currently ignored by FREDI.
• Any text following the last body part is treated as the epilogue. This text is currently ignored by FREDI.
• The main message containing the body parts must have a "Content-Type" header whose type must be "multipart".  Furthermore, the Content-Type header must have a parameter called "boundary" whose value specifies the boundary string that separates the body parts.

Basic structure:

Example:

Boundary Delimiter

A one-line string called the boundary delimiter separates the body parts in a composite or multipart message.  A boundary opens the beginning of the first body part and ends all subsequent body parts except for the last.  The last body part ends with a closing boundary.  The boundary delimiter is made up of:

• For the opening boundary and separation boundaries, the boundary string is preceded by CLRF and 2 hyphens ("--").

      <CRLF><"--"><boundary string>

  For example, if the boundary string is "some.boundary" then the delimiter is "--some.boundary".

   

• For the closing boundary, the boundary string is preceded by CRLF and 2 hyphens, and then the string is followed by 2 hyphens.

      <CRLF><"--"><boundary string><"--">

  For example, "--some.boundary--".

The boundary string is specified by the "Boundary" parameter of the Content-Type header that is in the message that encapsulates the body parts (or the mailMessage object that encapsulates this mailMessages collection object).  

The CRLF that starts the boundary delimiter indicates that the boundary MUST start at the beginning of the line.  The CRLF itself is part of the delimiter and not the preceding body part.

There MUST NOT be a text or a string within the body part that matches the boundary or closing boundary delimiter.  Framework EDI searches for the delimiter pattern to determine when a body part begins and ends.

For additional information, see RFC 2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types.