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...
Updated Jul 01, 2019
Version 2.0
Blog Post
Radu - If (as you indicate) the client is actually asking for those x-headers by name then in fact they will be promoted to individual named properties. If the submission is authenticated they will also be promoted to individual x-headers. On E2k7 if one user on an MDB has mapped an x-header to a named property all other users on that mdb will see it mapped to an individual property.
If no users have mapped an x-header to a named property id and the submission is not authenticated and the application has not requested this id, it will NOT be promoted to an individual property. It is available in PR_TRANSPORT_HEADERS. You can get around this by having your application send one user on the MDB an authenticated message with the x-header. OR you could have one user on the mdb actually retrieve the property.
In Exchange2010 that will not work - mappings are per user and each user would need the property mapped to see it promoted as an individual property.
James - TNEF should be properly restricted as well. I believe RU8 does not apply the constriction to TNEF in all cases, something we've fixed. PS_PUBLIC_STRINGS is not limited...yet. It's on our radar (and has been for a few months) as something to keep an eye on and consider a similar constraint.
If no users have mapped an x-header to a named property id and the submission is not authenticated and the application has not requested this id, it will NOT be promoted to an individual property. It is available in PR_TRANSPORT_HEADERS. You can get around this by having your application send one user on the MDB an authenticated message with the x-header. OR you could have one user on the mdb actually retrieve the property.
In Exchange2010 that will not work - mappings are per user and each user would need the property mapped to see it promoted as an individual property.
James - TNEF should be properly restricted as well. I believe RU8 does not apply the constriction to TNEF in all cases, something we've fixed. PS_PUBLIC_STRINGS is not limited...yet. It's on our radar (and has been for a few months) as something to keep an eye on and consider a similar constraint.