Mail Architecture

Mail-related WebDAV properties

Most mail-related WebDAV properties are in either the urn:schemas:mailheader: or urn:schemas:httpmail: namespaces. In fact, many properties are available in both of those namespaces. Every RFC 822 header in the message is copied literally to a property in the urn:schemas:mailheader: namespace with the same name. urn:schemas:httpmail: on the other hand has only a subset of headers, but in a more processed form. (For example, if there are non-ASCII characters in the subject of a message, urn:schemas:httpmail:subject will have a UTF-8 representation of the subject, while urn:schemas:mailheader:subject will have the MIME-encoded ASCII representation.)

A few important mail-related WebDAV properties are:

urn:schemas:httpmail:read (aka E2K_PR_HTTPMAIL_READ), urn:schemas:httpmail:hasattachment (aka E2K_PR_HTTPMAIL_HAS_ATTACHMENT), and PR_ACTION_FLAG, which are used to generate the Camel message flags.
urn:schemas:httpmail:messageflag (aka E2K_PR_HTTPMAIL_MESSAGE_FLAG), urn:schemas:mailheader:reply-by (aka E2K_PR_MAILHEADER_REPLY_BY), and urn:schemas:mailheader:completed (aka E2K_PR_MAILHEADER_COMPLETED), to determine "flag for followup" information.
DAV:getcontentlength (aka E2K_PR_DAV_CONTENT_LENGTH), which tells the message size.

MIME messages

Normal message/rfc822 messages delivered by SMTP, or copied into the folder with a PUT (eg, by Connector) are the easiest type of mail item to deal with.

The PR_TRANSPORT_MESSAGE_HEADERS property of a real MIME message contains the complete MIME structure of the message with none of the actual content. (Eg, all of the RFC822 and MIME headers, plus multipart boundary delimeters.) This can be used to create most of the summary information for a message.

MAPI messages

Messages sent by other local users using Outlook, and some messages generated by Exchange itself, are not represented as MIME messages internally. While Exchange will fake up MIME headers if you GET the message, these messages don't have a PR_TRANSPORT_MESSAGE_HEADERS property, so to create summary information, we have to fetch urn:schemas:mailheader: properties and fake up the headers from there.

A few types of MAPI messages get additional special handling:

Delegated meeting requests

When you set up your delegates to get copies of your meeting requests, Exchange mangles the message/rfc822 body in various ways. (In Connector, mail_util_demangle_delegated_meeting fixes things for us.)
Sticky notes

Technically, these aren't in mail folders, but they're handled by the mail code. This is a silly hack because I was bored one day. If the folder is a stickynotes folders instead of a mail folder, Connector fetches some additional properties and uses mail_util_stickynote_to_rfc822 to make an HTML message simulating the stickynote.

Non-mail Documents

Public folders that are not calendar, contact, or task folders are treated as mail folders by default, but are sometimes used for things other than mail, such as storing Word documents.

These objects have basically no email properties at all, and when you GET the bodies, they're application/x-msword or whatever instead of message/rfc822.

Sometimes these items will have a PR_INTERNET_FREE_DOC_INFO property that contains a Content-Type header, but not always. So in that case, we get the E2K_PR_DAV_CONTENT_TYPE and make Content-* headers ourselves. Then we fake up the rest of the headers to make the document look like an email message with an attached document.