In my last blog post on named properties, I detailed the history of named properties, how they are arranged, mapped, and how Exchange (since Exchange 2000) has created named property mappings for x-headers on inbound messages. Rollup 8 for Service Pack 1 contains the changes we made to restrict named property mapping further, and with Service Pack 2 on the horizon there are more changes in the waters. This post details what is changed in Service Pack 2, how that affects (or does not) you, and includes a request for feedback.
As mentioned before, Exchange 2007 creates named properties for x-headers during delivery. The RTM version of Exchange 2007 would NDR messages if the named property quota was reached, even if the property were only for an x-header. Service Pack 1 changed this behavior to only NDR the message if a non X-header named property could not be mapped (in other words, a property likely to contain critical data). Rollup 8 for Service pack 1 removes the ability of non-authenticated messages to consume named property IDs. Service Pack 2 goes even further.
Service Pack 2 is in line with Exchange2010 behavior - that is, no x-headers are ever promoted to individual properties if a client has not already requested (and mapped) them. Not even authenticated submissions can create new named property mappings. The x-headers are still stored in PR_TRANSPORT_HEADERS and still accessible to MAPI clients but they are not individual properties. This creates a problem for IMAP clients in particular:
Exchange2007 does not contain an STM file - it doesn't save the original mime content. Messages are converted to MAPI. IMAP has the ability to search based on header values, but if these are not promoted, the result is that the message is not contained in the results. If a client has previously mapped t he header in question (a MAPI client) then messages delivered after this will have the x-header promoted as an individual property.
So, the questions I ask are:
Things that aren't on the table:
We're aware that both of these would prove useful. Also, this is not a voting contest - we've seen how a vocal minority can skew results before. Just a heads up and if you have real world reasons for arguing for a particular request, let us know.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.