The curious case of the dot

'How often have I said to you that when you have eliminated the impossible, whatever remains, however improbable, must be the truth?'

Sherlock Holmes Quote

-The Sign of Four

Chapter 6: "Sherlock Holmes Gives a Demonstration

 

 

I was recently confronted with several cases where customers were complaining that when sending E-Mails with inline attachments, most of the times OLE Images to external recipients, these e-mails are received stripped of the attachment.

 

Such a curious behavior can be reproduced both when sending E-mails with inline attachments to external recipients who are also using Exchange messaging solutions, but are retrieving the messages via IMAP, but also when sending the E-mails to user on Unix solutions:

  

  1. Compose a RTF Message to an external recipient from the exchange 2010 Organization
  2. Insert a picture of size around 2 MB into the message as an embedded attachment
  3. Send the email to an external recipient
  4. At the destination notice that the email has arrived in HTML format, and the attached picture is intact as well
  5. Repeat the same steps, this time with a larger picture embedded.. (Around 6 MB)
  6. At the destination notice that the email has arrived in HTML format, but this time just with a "." (dot) in place of the picture.

Most of the times recipients of such e-mails simply say that they are not receiving the attachments at all. Upon a closer inspection we can see that things are not always what they seem.

This is how the inline graphic is displayed in the received E-Mail:

We can see the pixel

 

When looking with mfcmapi at this message we can clearly see the attachment is still there, but for some reason it has been reduced to a 1x1 pixel image.

Let me first explain what is happening in the background when we are sending E-mails with inline attachments to external recipients

 When a message is composed in RTF and there is an Imaged Embedded on the messages, Exchange needs to convert the message from RTF to MIME/HTML before sending to Internet.
For Exchange 2007 and 2010, the converterProcess is oleconverter.exe.
The oleconverter.exe take the help of function converterProcess.Worker.OleConvertToBmp to do this conversion.
The converterProcess.Worker.OleConvertToBmp function has a hard coded ImageSizeConversionThresholdBytes limit which is 4194304 Bytes = 4MB
When this limit is exceeded, OleConversionFailedException is returned and we see a dot instead of the image.

When converting OLE Objects to JPG these will be temporary written to the folder OleConverter. Should there be issues with the permissions for this folder, if we simply run out of space on the drive where this folder is located, or if the result  of the function converterProcess.Worker.OleConvertToBmp is over 4 MB the images Ole Objects will not be converted and will be replaced in the sent mail by a 1x1 pixel place holder image.

 Should you also be confronted with this strange behavior, you can check the following info:

  1. Open the location \Microsoft\Exchange Server\V14\Working\OleConverter. Can we see older data there, or are all the temporary files deleted?
  2. Check how much free space is on the drive that contains the folder OleConverter., and also check if you have problems with the disk drive itself.
  3. Check the permissions for the folder OleConverter.They should be set as follows:

a. System: Full control

b. Local Service: Read, Write

c. Network Service: Read, Write

d. Administrators: Full control

     4. Also check the security tab ->advanced -> network service and double click on it

If they are configured as in the above mentioned printscreen, please set them temporary to full access for the networking service, confirm, and then change them back to the standard values that are:

 

  • List folder / read data
  • Read attributes
  • Read extended attributes
  • Create files / read data
  • Create folders / append data
  • Write attributes
  • Write extended attributes
  • Read permissions

After doing this, in a matter of minutes the OleConverter folder should be emptied. If the temporary files still persist, simply delete them and then send a new e-mail with an inline OleObject to the recipient. However impossible it may seem that a change to the permissions  for the network service and then reverting back to the standard ones could solve this curious phenomenon, THIS IS THE SOLUTION.

 

The recipient should receive the e-mail correctly this time.

 

More info on content conversion can be found by consulting the following article: 

Understanding Content Conversion

  https://technet.microsoft.com/en-us/library/bb232174(v=exchg.141).aspx