![]() |
![]() |
![]() |
Evolution Connector for Microsoft Exchange Programmer’s Reference Manual | ![]() |
---|
Mail Architecture |
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.
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.
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.
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.