1
votes

We are experiencing a problem with Rich Text Emails that are forwarded as attachments having the ContentIDs being stripped from the attachments, which prevents us from correctly rebuilding the email message.

Here is an example response from EWS for a Rich Text Email with a picture

<t:ItemAttachment>
    <t:AttachmentId Id="AAMkAGRlNWE5MTc1LTUyODktNDRjNi05NTcwLWZjZGM1ODNkMmUxYwBGAAAAAABtOoJbAYfVSZzEDvklEbbPBwBBckyCi9TiT4cjPa5DHYwwAAAAemCwAABBckyCi9TiT4cjPa5DHYwwAABknfz6AAABBgAEAAAAAAA="/>
    <t:Name>Message with Attachments</t:Name>
    <t:Size>97993</t:Size>
    <t:LastModifiedTime>2014-06-10T13:19:25</t:LastModifiedTime>
    <t:IsInline>false</t:IsInline>
    <t:ContentId>F4880FA606E4DC9BBC5143C97C52AC554A3AE55B@1</t:ContentId>
</t:ItemAttachment>

Here is the same Email that is forwarded as an attachment:

<t:FileAttachment>
    <t:AttachmentId Id="AAMkAGRlNWE5MTc1LTUyODktNDRjNi05NTcwLWZjZGM1ODNkMmUxYwBGAAAAAABtOoJbAYfVSZzEDvklEbbPBwBBckyCi9TiT4cjPa5DHYwwAAAAemCwAABBckyCi9TiT4cjPa5DHYwwAABknfz6AAACBgAEAAAAAAAGAAQAAQAAAA=="/>
    <t:Name>Picture (Device Independent Bitmap)</t:Name>
    <t:Size>5210</t:Size>
    <t:LastModifiedTime>2014-06-10T13:19:25</t:LastModifiedTime>
    <t:IsInline>true</t:IsInline>
</t:FileAttachment>

Of Note - Exhange 2010 SP2 EWS API v2.2 (also happens in 2.0)

My Questions are:

  1. Is this intended behavior? (if so why?)
  2. Is this configurable on exchange (not the correct forum - but still)
  3. If it is configurable on exchange what are the implications of said configuration.

I'll be opening an MSFT Support Incident here shortly.

Steps to recreate:

  1. New Message
  2. Set Message to Rich Text
  3. Attach Image
  4. Send Email
  5. Open Email
  6. Forward as attachment to another Rich Text Email (this can also be done by saving the msg to disk and then attaching it manually)
1
Have you looked at the content of the PidTagRtfCompressed extended property to see if it's included there?Mimi Gentz
@MimiGentz Would you possibly have an example using the EWS 2.2 API? I cannot seem to locate that anywhere.Wjdavis5
To retrieve the PidTagRtfCompressed property, use this: ExtendedPropertyDefinition PidTagRtfCompressed = new ExtendedPropertyDefinition(0x1009, MapiPropertyType.Binary); PropertySet propSet = new PropertySet(BasePropertySet.IdOnly, EmailMessageSchema.Subject, PidTagRtfCompressed); EmailMessage message = EmailMessage.Bind(service, ItemId, propSet); I'm not sure if that property also contains the RTF of the original attachment or not.Mimi Gentz

1 Answers

0
votes

I've delt with exchange alot when building an outlook addin. I'm talking about older versions of exchange and outlook but I have painful memories dealing with custom email sending and rebuilding. Especially with RTF.

  1. Is this intended behavior? - my guess is yes and most likely because if exchange doesn't strip the ContentId, it might present a security issue or cause unintended behavior on the client. It would be difficult for the exchange developers to support tracking exchange emails attached to other exchange emails. It doesn't consider it an exchange item any more when it's an attachment, to exchange it's just another block of data.

  2. Is this configurable? - I'm not sure as I haven't dealt with any of the newer versions of exchange lately but based on my answer to number 1, probably not.

  3. If it is configurable on exchange what are the implications of said configuration? - see answer #1, my guess is security related and/or development difficulty.

You need look at the RTF contents of the message. But take note that in many cases the RTF body content is usually compressed with base-64 so you may need to decompress it first.

    -