locked
Exchange 2010 embedded images in email problem RRS feed

  • Question

  • We have Exchange 2010 and the limit on our global settings and various send/receive connectors is 30720 KB everywhere for Max receive size & max send size.  Currently, even if the message size is well below the KB limit, if there are enough images embedded in the message the email is not delivered successfully. 

    For example, if there are 222 small attachments embedded in an email with the email message TotalBytes = 657358 (~658 KB), the email does not deliver and this is the error that is logged in Exchange:
    554-5.3.4 Content conversion limit(s) exceeded 554 5.3.4 STOREDRV.Deliver.Exception:ConversionFailedException; Failed to process message due to a permanent exception with message The content conversion limit has been exceeded. ConversionFailedException: The content conversion limit has been exceeded. [Stage: CreateReplay]

    This appears to be a bug with the number of images and the fact that they are embedded into the message.  Is there a fix for this issue?  Or is there a setting in Exchange I can adjust to allow these messages to be delivered successfully?

    Thanks,
    Elizabeth

    Friday, August 22, 2014 11:10 PM

Answers

  • Hi,

    Base on my research, the issue may be caused by "MaxBodyPartsTotal" attribute. When total number of parts in an email is more than 250, it will cause this issue. This is hardcoded limit with exchange server (by design).

    I recommend you refer to the following article:

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

    MaxBodyPartsTotal   This limit specifies the maximum number of message parts that can be used in a MIME multipart message. The value is 250.

    In addition, I suggest you use winzip tool to compress the images in one file as a workaround to resolve this issue.

    Best regards,

    Niko


    Niko Cheng
    TechNet Community Support

    Monday, August 25, 2014 7:19 AM
    Moderator
  • You're probably correct about the number of body parts being the problem. But I'd enable pipeline tracing first and add this to the cmdlet:

    -ContentConversionTracingEnabled:$true

    When one of those messages fails content conversion you'll find the reason in the log file.

    I've seen content conversion fail for reasons other than the number of body parts which is why I'm suggesting this.


    --- Rich Matheisen MCSE&I, Exchange MVP

    Monday, August 25, 2014 4:06 PM

All replies

  • If I am not mistaken you don't have documented solution for this. Please check this and this


    Thanks,
    MAS
    Please mark as helpful if you find my comment helpful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you.

    Saturday, August 23, 2014 11:53 AM
  • Hi,

    Base on my research, the issue may be caused by "MaxBodyPartsTotal" attribute. When total number of parts in an email is more than 250, it will cause this issue. This is hardcoded limit with exchange server (by design).

    I recommend you refer to the following article:

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

    MaxBodyPartsTotal   This limit specifies the maximum number of message parts that can be used in a MIME multipart message. The value is 250.

    In addition, I suggest you use winzip tool to compress the images in one file as a workaround to resolve this issue.

    Best regards,

    Niko


    Niko Cheng
    TechNet Community Support

    Monday, August 25, 2014 7:19 AM
    Moderator
  • Agree with Niko.
    Compress using Winzip or Winrar and send in one file as your attachment size is less than the send connector allowed size limit.

    Thanks, MAS
    Please mark as helpful if you find my comment helpful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you.

    Monday, August 25, 2014 7:33 AM
  • You're probably correct about the number of body parts being the problem. But I'd enable pipeline tracing first and add this to the cmdlet:

    -ContentConversionTracingEnabled:$true

    When one of those messages fails content conversion you'll find the reason in the log file.

    I've seen content conversion fail for reasons other than the number of body parts which is why I'm suggesting this.


    --- Rich Matheisen MCSE&I, Exchange MVP

    Monday, August 25, 2014 4:06 PM
  • Thank you for the feedback! I will do the reading and pipeline tracing you all suggested and will come back with more questions if I have them.

    Just FYI, the suggested workaround isn't very useful in my situation.  We have a SSRS report subscription set to email a copy of the report in MHTML format, which embeds the report into the email Body.  The report in question is small in size, but has many "Indicators" that render as completely different images in the table of the report when it's emailed.  (There are only 4 different indicator images possible, so really I would think there should be 4 attachments embedded repeatedly, instead of 222 separate attachments embedded individually. )  The workaround in my situation is to have the report subscription attach the report in the email using any format other than MHTML (such as Excel, CSV, HTML 4.0, PDF, etc.).  The report renders and attaches differently using other formats and so the email delivers successfully.

    Monday, August 25, 2014 4:10 PM
  • Hi Rich,

    I configured tracing as suggested, and this is what I got:

    This message was not processed because it contains a large number of MIME bodies.

    Microsoft.Exchange.Data.Storage.ConversionFailedException: The content conversion limit has been exceeded.
       at Microsoft.Exchange.Data.Storage.InboundMimeConverter.ConvertToItem(MimePromotionFlags promotionFlags)
       at Microsoft.Exchange.Data.Storage.ItemConversion.ConvertAnyMimeToItem(Item itemOut, EmailMessage messageIn, InboundConversionOptions options)
    InboundConversionOptions:
    - defaultCharset: Microsoft.Exchange.Data.Globalization.Charset
    - trustAsciiCharsets: True
    - isSenderTrusted: True
    - imceaResolveableDomain: <DOMAIN REDACTED>
    - preserveReportBody: False
    - clearCategories: True
    - userADSession: Microsoft.Exchange.Data.Directory.Recipient.ADRecipientSession
    - recipientCache: Microsoft.Exchange.Data.Directory.Recipient.ADRecipientCache
    - clientSubmittedSecurely: False
    - serverSubmittedSecurely: True
    - charsetDetectionOptions: CharsetDetectionOptions:
    - preferredInternetCodePageForShiftJis: 50222
    - requiredCoverage:  100
    - preferredCharset:  null

    - convertReportToMessage:  False
    - headerPromotionMode: NoCreate
    - treatInlineDispositionAsAttachment:  False
    - applyTrustToAttachedMessages: True
    - resolveRecipientsInAttachedMessages: True
    - applyHeaderFirewall: False
    - ignoreImceaDomain: False
    - combineMixedContentBodies: True
    ConversionLimits:
    - maxMimeTextHeaderLength: 2000
    - maxMimeSubjectLength: 255
    - maxSize: 2147483647
    - maxMimeRecipients: 12288
    - maxBodyPartsTotal: 250
    - maxEmbeddedMessageDepth: 30
    - exemptPFReplicationMessages: True

    Thanks to all!  As previously mentioned, the ConversionLimits cannot be adjusted, so a work-around will be necessary for our scenario.

    Monday, August 25, 2014 7:21 PM