Problem:
Some IMAP-clients (Thunderbird in some cases) have problem with corrupt attachments using Exchange IMAP.

Solution:
One possible reason is how Exchange delivers MIME-message to users. In exchange 2003 you could set an option on IMAP – ”Fast message retrieval” and it makes IMAP answer faster to clients with MIME-messages. In Exchange 2010 this option is set thru powershell with Set-imapsettings and it is now called ”EnableExactRFC822Size”. When this is enabled it will give IMAP-clients an exact size of each MIME-message content and not an approximate size as default. Old IMAP-clients can not handle an approximate size of MIME messages and there for shows messages as corrupt. As Marek writes below: ”MS Exchange violates RFC and provides only approximate size of the message for ‘performance reasons'”.

A plot from technet and powershell-command ”set-imapsettings”.
Link: http://technet.microsoft.com/en-us/library/aa998252.aspx

Set-imapsetting -EnableExactRFC822Size $true|$false
The EnableExactRFC822Size parameter calculates the exact size of each MIME message that can be retrieved from the server. When you set this parameter to $true, the exact size of MIME messages stored on the Exchange server is available to POP3 or IMAP4 client programs that rely on knowing the exact size of each MIME message.
This parameter is set to $false by default. If you don’t set this option to $true, the size of each MIME message that the Exchange server returns to POP3 and IMAP4 client programs may be slightly different than the exact size of the message. Because setting this option to $true can negatively affect performance, you should only use this option if many of your users are using a client that requires knowing the exact size of MIME messages.

A post by Marek Vitek 2010-01-28
There are several reasons and also few possible solutions for solving this issue.
– MS Exchange violates RFC and provides only approximate size of the message for ”performance reasons”
– I saw also other mail servers providing incorrect RFC822.SIZE value

So sticking with this value is not a good idea. It is also discouraged by IETF author in RFC 2683 http://tools.ietf.org/html/rfc2683 section 3.4.5.

Solutions:
– in Exchange disable ”Fast message retrieval” function/RFC violation. http://support.microsoft.com/kb/191504 But it will have performance implications. (In exchange 2010 this is same as -EnableExactRFC822Size on set-imapsettings)
– follow RFC 2683 recommendations and in Thunderbird fix the code and use message size provided by ”FETCH RFC822.SIZE” command only for informational purposes. For message size validation and possibly truncation use e.g. size reported by ”FETCH RFC822” as it seems to be correct value all the time.

————-
Link: http://support.microsoft.com/kb/191504
Thunderbird: E-mail attachments are corrupted and and images partially load http://blog.jonsson.it/?p=258

Tagged with:
 
Area:
Exchange 2010, IMAP, Thunderbird

Synopsis:

In Thunderbird, there is a problem where attachments on received e-mail messages are corrupted, and images in e-mail messages only partially load. This is caused by Exchange reporting attachment sizes incorrectly, so when Thunderbird breaks the message into chunks it doesn’t download all of them.

Solution:
Exchange has a bug in the IMAP server implementation that reports the wrong size for messages and attachments. There is a workaround that causes Thunderbird to ignore the erroneous information.

Truncated Attachment Problem
Warning: This may result in any tags you have set disappearing. If you use Thunderbird’s tagging you should back up your profile before doing the following (your profile is in the ~/.mozilla-thunderbird directory by default).

  • From the Edit menu, select Preferences
  • Select the Advanced tab
  • Click the Config Editor button
  • Set the filter to mail.server.default.fetch_by_chunks. The default value should be true
  • Double-click the mail.server.default.fetch_by_chunks preference. It should turn bold, and the value should now read false

Thunderbird will now download attachments as one block, avoiding the bad attachment size problem.

Tagged with: