Whenever mtaDecodeMessage() is called, an “inspection” routine must be supplied by the caller. In Example 5–1, the inspection routine’s name is decode_inspect().
As the message is parsed and decoded, mtaDecodeMessage() presents each atomic message part to the inspection routine one line at a time. The presentation begins with the part’s header lines. Once all of the header lines have been presented, the lines of content are presented.
So that the inspection routine can tell if it is being presented with a line from the header or content of the message, a data type indicator is supplied to the inspection routine each time it is called. In regards to lines of the message’s content, the data type indicator discriminates between text and binary content. Text content is considered any content with a MIME content type of text or message (for example, text/plain, text/html, message/rfc822), while binary content is all other MIME content types (application, image, and audio).
When writing an inspection routine for use with mtaDecodeMessage(), the following points apply:
Message parts need not have any content. A common case is a single part message with no content for which the sender used the Subject: header line to express their communique.
In the case of a non-multipart message, the message has a single part. The header for this sole part is the header for the message itself. As noted previously, there may or may not be any content to this single part.
In the case of a multipart message, individual parts need not have a part header. In such cases, MIME’s defaults apply and imply that the content is text/plain using the US-ASCII character set.
Regardless of the value of the Content-transfer-encoding header line, the content presented will no longer be encoded.
In the case of a multipart message, the outermost header is not presented. However, it may be inspected by means of an output routine (see The Output Destination).