Camel.Imap

The IMAP provider implements an IMAP backend.

Even with all of it's problems, this is the most stable and featureful remote backend in existance. It just isn't very easy to maintain.

It supports SSL, TLS and unsecured connections. All of the Evolution/Camel.SASL authentication modes. It will try to use IMAP4REV1 partial fetches if they are available (not always to beneficially effect), LITERAL+ is supported for many tasks as well.

I should really add more detail here, but I just don't care - I barely understand the code either, and I rewrote it anyway. Maybe others can update it.

Folders

The IMAP folders map best they can to the Camel folders. In the event of badly named folders supplied by the server (i.e. not properly UTF-7 encoded), it will create an internal mapping so the folder can still be used and accessed.

All operations apart from handling EXPUNGE return codes are implemented using UIDs directly. The Camel UID is the same as the IMAP UID.

Folders update by retrieving the ENVELOPE and some of the message headers. Most of the information required for the CamelMessageInfo is in the envelope, but not all - hence the less efficient request.

Messages are retrieved sometimes in parts - it depends on the server capabilities and their size. i.e. attachments will often be downloaded separately to the message content. Unfortunately, in many cases this just makes it run slower.

Searching

Searching is implemented using a customised Evolution/Camel.Search#Camel.FolderSearch object. Since most search operations work against the Evolution/Camel.FolderSummary, those are unaltered, but the (body-contains ...) search is overridden, and sent to the server using the UID SEARCH command.

It also caches the results, to improve performance, particularly Evolution/Camel.VFolder startup time.

Offline

Offline is supported using the Evolution/Camel.Offline#Camel.Disco interfaces.

Many operations work fine in offline mode, but you cannot perform most folder operations, such as renaming (moving), deleting or creating folders.

Namespaces

Only a single namespace is supported. It will either take the default user namespace from the NAMESPACE command, or use the one provided by the user.

Workarounds

It has hardcoded workarounds for certain servers. For example Courier IMAPD says it supports IMAP4REV1, but it doesn't implement many of the features we might otherwise use. We therefore hardcode it to fall back to simple.

Some workarounds are based on hostname (!), for some of the larger ISP or email providers with broken custom servers.

Check the source, if you dare ...

Notes

Oh where to start ... this is a pretty hairy bit of code.

Several attempts have been made to write a completely new IMAP implementation to replace this, none have fully succeeded, although the IMAP4Rev1 code came quite close. One problem is the initial implementation was written by someone who never finished it, and didn't follow structured coding practices. So it has suffered from multiple author syndrome among other things.

There are scads of performance issues. Most notably because the implementation is fully synchronous. All protocol exchanges are performed as uninterruptable SEND/WAIT/RECEIVE steps (cancellation still works).

Although initially it seems to make sense to use partial fetches to retrieve attachments separate from message parts, it is a tunable which is hard to get right. In most cases it is quicker to just get the whole message. Perhaps the threshold needs to be substantially increased from the 5K it uses now.