Camel.MimeParser

CamelMimeParser is an object which will parse either a raw message (e.g. maildir) or a Berkeley Mailbox file from a stream or a file descriptor. It is a state machine which handles all the failure cases (truncated parts, missing multipart bits, io errors, etc) - you're always guaranteed to get a valid state sequence, and you can skip bits you're not interested in if you just want to scan the headers/whatever.

In addition to being a push, stack-based parser, you can also use it to automatically re-format data as it is parsed, skip sections efficiently, and a few other little tricks. This is the absolute core object used for all mail parsing, and is robust and fast. It has one minor bug due to an early design change, but otherwise is very reliable.

The sequence of these states is well defined. For each start state you get a matching END state, although various states are optional. You can use the CAMEL_MIME_PARSER_STATE_END bit to determine if the state is an end state - in practice you wont care.

The following diagram shows the state sequence you will get parsing with From enabled - without it, the From state is simply removed. The two states labelled &lt;&gt; are not states in themselves, but transation states, to which one of the other states pointed to by the solid arrows it will actually go to. * means the state can occur 0 or more times, 1*means 1 or more times.

This was created from the Dia file in camel/devel-docs/camel_parser_states.dia in the source distribution.

The PRE_FROM state is missing from that diagram, but would sit between INITIAL and FROM.

The interface

This is some extended documentation on the parser api entry points. The API documentation (or the source) for this file should be consulted as it covers the details too.

First, you need to create and initialise the parser. The parser content can either come from a Evolution/Camel.Stream, or from a Unix file descriptor. The latter exists because CamelMimeParser does it's own buffering, and thisis more efficient. It will steal the file descriptor.

Note that CamelMimeParser is a final object, and cannot be subclassed; the virtual methods defined its class are not implemented.

To greatly simplify the use of the parser states, it never returns an error. Any error in the input will cause the parser to terminate each outstanding state in turn, and return no data content. During this process, or afterwards, the parser can be queried to see if an i/o error occured. Note that the parser itself never signals a data format error; all data encountered will go somewhere, so it is not lost, although it may be reformatted slightly. This is to the user of the parser doesn't have to abort if it gets invalid data, it can fail gracefully.

int camel_mime_parser_errno(CamelMimeParser *parser);

There are a couple of control functions, which modify the parser behaviour. If the from state is enabled, then Berkeley Mailbox "From " lines will be checked for in the input, and it will consistitute the base active state.

Similarly, if pre_from is enabled, an additional state will be added for any data found before the first (and only the first) "From " line discovered in the input. This can be used to skip over invalid content without losing it.

Now we get to the functions used to invoke the parser itself. The optional buf, and buflen arguments will accept pointers to internal buffers for data detected in certain states. For example, the CAMEL_MIME_PARSER_STATE_BODY, and CAMEL_MIME_PARSER_STATE_PRE_FROM states will pass any data present using this mechanism. This pointer is only valid until the next call to camel_mime_parser_step. A pointer to the internal buffer is used for efficiency; in many cases data doesn't need to be copied to be used.

Unstep can be used to go back one state transition. Infact it merely means the existing state is repeated for as many times as unstep was called. This is useful if you've gone past the states you understand, but your callee might be expecting it.

void camel_mime_parser_unstep(CamelMimeParser *parser);

Drop step is a little different, it will cause the parser to drop one level from its parser stack. What this means for example, is that if you just received a HEADER state, it will drop the following HEADER_END state, and skip that data until the next appropriate boundary.

void camel_mime_parser_drop_step(CamelMimeParser *parser);

Push state can be used to pre-load the parser with a particular state. This wont let you control the entire parser proccess, but needs to be used in a few specific cases to ensure parsing continues properly. It is often used with the seek function.

As well as parsing, you can force a non-parsed read through the parser from the current parse position. Like the other functions, a pointer to the internal buffer is returned, as well as the length of valid data available; which will be at most len bytes, but may be less.

Then there are a bunch of location functions used to jump to locations in a file, and find the physical location of various pieces of information. These are used for loading specific messages from mailbox files, and working out where they are in the first place.

Once you are in one of the header-related states, you can query the parser for information about the current level. Once this state has been passed, much of this information is no longer available, so it needs to be used at the right time - see the API comments for more information.

You can get everything from the part's Content-Type in a pre-parsed form, to any specific header in raw form (including the character offset in the file for the start of the header), all headers, pre/post text in a multipart type, or the physical "From " line present in a mailbox file.

And last but not least, there are some utility functions that let you add Evolution/Camel.MimeFilter fillters to pre-process content before it leaves the parser. This is a covenient way to get data in the right form efficiently without having to process it afterwards (this was the original use for the CamelMimeFilter interface, hence it's name). Filters are active until they are removed, so filters can be added and removed as desired as the processing takes place - ideal for example for scanning an entire mailbox and performing some work on it.

Example: Listing all messages in a Berkeley Mailbox

Often a client needs to scan a whole mailbox, extract some information from the top-level headers, but not parse the entire content. This is quite easy to achieve. We can even find out where the message was in the mailbox, etc.

Example: Searching a message

Now for something a bit more complicated. Searching a message. Using simple file i/o will not work - content may be in any encoding format, and may be in the wrong character set. You could convert everything to a message at a time, but that isn't particularly efficient.

This example also demonstrates the use of Evolution/Camel.MimeFilter filters as additional processing elements in the data pipeline.

For this code frament, we'll assume the parser has been initalised appropriately.

Note how that because we are guarnteed a specific state sequence, we don't have to worry about the edge cases. And by dropping the step at uninteresting places we wont even bother parsing or converting binary parts. And because we're just worried about text-parts, we don't even care about the structure of the message, so we don't need to track the state transitions either.

To perform the same task on a Berkeley Mailbox file should be a simple matter of initialising the parser to scan From lines, and point to an appropriate file. The From states will just be ignored.

Unfortunately, since real messages are likely to break the rfc's - particularly those from someones little shareware bunky-mail-library-of-the-week, or worse, from LookOut, in real life things get a lot more complicated, and you can't really do fully streamed processing. But for anything created by Camel, or in controlled environments, then it can lead to massive memory and cpu savings.