Hello, We're seeing problems with users using PINE to access their mailbox on Exchange 2007. It seems that this is due to Exchange reporting the RFC822.SIZE value incorrectly. I've found that the imap/popsettings contain an option called "EnableExactRFC822Size" set to false. The only documentation of this setting I can find is in the MS-OXIMAP4 Protocol specification document, in the Appendix: <5> Section 1.7: Exchange 2007 - Set the EnableExactRFC822Size to true for clients that expect an exact message size for the message they are retrieving. This seems to be the correction that we are looking for, but I wanted to see if there were any other considerations. For example, why is this not set to True by default, why is the value being reported incorrectly in the first place? If anyone has any insight, I would appreciate it. Thanks,

In order for Exchange 2007to return the exact size, it must rebuild the MIME which can have a performance impact on large messages or deeply nested attachments. The default setting is to return an estimate of the size to improve performance and since most other IMAP clients don't have any problems if the size is wrong.You can enable the exact size for everyone with:Set-ImapSettings -EnableExactRFC822Size:$trueOr only for a specific user:Set-CASMailbox "IMAP User" -ImapUseProtocolDefaults:$false-ImapEnableExactRFC822Size:$true

Hi,Below is clarification on why we are seeing this behavior. The reason we have this problem is that E2K7 no longer has an STM that stores the actual MIME of the message. Instead we store what's called a "Mime Skeleton" to rebuild the MIME. The SIZE returned if EnableExactRFC822Size is FALSE is the original MIME Size of the message, not the size of the message after it's rebuilt via the MIME Skeleton. The caveat to setting EnableExactRFC822Size is that we will calculate (by rebuilding the MIME from the MIME skeleton) the actual size of the message before it is downloaded so that the SIZE command returns an accurate value. This can cause perceived performance issues because on particularly large messages or deeply nested attachments, we have to process the message as if it was being downloaded before the size command returns a result. This may cause a delay in downloading large amounts of large messages or large numbers of messages with deeply nested attachments. It's hard to quantify how much of a delay, but there will be a small delay to download files this way. We have to send EVERY message in the FETCH request through FULL content conversion to calculate the size regardless of what they are requesting. The # of messages, the total size of the messages, the CPU and I/O etc,. will impact that but I can't begin to predict what level of perf they'll see. In other words if there's a 20MB message w/attachment and ALL they want is the RFC822-Size on the message (which would be maybe a few bytes on the wire) we would have to convert the entire message as if we were sending it to the client so that we can accurately calculate the sizeThanksAllen