## 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.