Accepting Appointments With CDO May Break Embedded Message Attachments

This is an issue that has only been reproduced so far with Exchange 2003, but I wanted to document it here in case anyone else is running in to it. Suppose you have a CDO 1.21 based application which uses GetAssociatedAppointment to accept meeting requests. Suppose further that this application receives and processes a meeting request that contains an embedded message. The resulting appointment item created on the calendar will have an attachment on it, but this attachment will be unusable.

What’s going on: When you invoke CDO’s GetAssociatedAppointment call, if CDO doesn’t find a matching appointment on the calendar, it creates one. Part of this creation includes copying any attachments on the source meeting request over to the new appointment item. CDO does this by walking the attachment table on the source message, calling OpenAttach on each attachment. On the destination message, it calls CreateAttach, then uses CopyTo to copy from the source to the destination. No properties are excluded and no specific properties are requested. On the embedded messages, this call doesn’t return an error code, but looking with MFCMAPI, we see that PR_ATTACH_DATA_OBJ doesn’t get copied.

To understand this, I debugged the Store process on the Exchange 2003 server. This CopyTo operation is handled by a special function in Store that deals with copying attachments. This function has two main code paths, one called fast and one called slow, though it doesn’t look like one is necessarily faster than the other. The fast code path looks like it copies everything at once, while the slow code path reads all the properties from the source attachments and writes them one at a time on the destination. Oh – and PR_ATTACH_DATA_OBJ is specifically excluded from this copy. Since this property, which essentially is the embedded message, isn’t copied, the resulting attachment is no good as an embedded message. It’s unclear why the slow path excludes this property – it appears to have always worked this way, at least as far back as Exchange 5.5.

What’s also unclear is when we take this slow path. Given that this problem has only just now been observed, we must normally take the fast path. The specific test being made to determine which path to take is whether the column set of the destination attachment table is a subset of the column set of the source attachment table. It appears that usually, it is, and the fast path is chosen. But there are apparently circumstances, on Exchange 2003 at least, and perhaps depending on how the meeting request entered Exchange, under which the destination attachment table has columns not present in the source attachment table, and the slow path is taken, which doesn’t copy the embedded message portion of the attachment.

The good news here is that in Exchange 2010, these two paths have been merged. The winner in the merge was the slow path, but this path has been augmented specifically to handle the embedded message case. So this problem should be impossible to hit with Exchange 2010.

I didn’t get a chance to test workarounds for this issue, but someone who is encountering it might try checking the attachment table on the meeting request, and if embedded messages are found, delete them from the new appointment and recopy them manually.

[Edit] The customer who reported this to me wanted to point out that the problem seems to only happen when the embedded message comes from another Active Directory domain. The problem has not been observed in single domain scenarios.