We recently had a customer who was copying messages around using CopyTo. They found that for certain messages, if the target message store was a PST, they’d get MAPI_E_NO_ACCESS (0x80070005). They saw this for the same messages every time, when other messages would copy to the same PST just fine.
When I debugged the failure, I found the root of the problem was that the source message had an attachment with the property 0x67100003 set on it. The PST provider does not allow this property to be set on a messages in its store, so any attempt to set it returns the error MAPI_E_NO_ACCESS. When they did the CopyTo of the message properties, because PR_MESSAGE_ATTACHMENTS was not excluded, one of the side effects was that MAPI looped through the the attachments and copied them, using calls to CopyTo at the attachment level. These CopyTo calls did not use an exclusion array at all, so every property on the source attachments were copied to the destination. When CopyTo reached the property 0x67100003, the PST provider returned an error, which caused the attachment level CopyTo to fail, which in turn caused the customer’s CopyTo call to fail.
By the way, 0x67100003 isn’t the only property that causes this problem. In fact, most properties in the service provider defined non-transmittable range (0x6600-0x67FF) caused the same problem.
The fix we used was to add PR_MESSAGE_ATTACHMENTS to the exclusion list for CopyTo, then copy the attachments manually using OpenAttach, CreateAttach, and CopyTo, passing an exclusion array specifying that the non-transmittable properties should be excluded. Since this is the same logic CopyTo uses to copy attachments (without the exclusion array), doing the copy like this doesn’t have a performance hit.