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