Mozilla sometimes is having some problems getting the extire message from my Exchange server. It only gets part of the message. I've now dug some deeper and here's what I found by doing manually IMAP commands on my IMAP server: Mozilla will send this IMAP command to get the message: UID fetch 4519 (UID RFC822.SIZE BODY[]<0.10240>) but this apparently only gets part of the message. I'm not sure if it's a Mozilla bug or a Exchange bug. Anyways... If I sent this command: UID FETCH 4519 (BODY.PEEK[] UID) everything is working perfectly!!! This is btw also the command that Outlook Express sends.. Any chance that Mozilla could change the IMAP command it's sending, so that I dont have this "incomplete message" error.

I'm so closed to uninstalling Mozilla due to this single bug. Whenever I receive a large mail I have to start Outlook Express or Outlook to view the message.. arhhhhg!

This seems to effectively completely kill S/MIME on any emails downloaded from a MS Exchange IMAP server using Mozilla. Mozilla seems to completely skip the S/MIME attachment. To recreate: S/MIME sign an email to yourself, then check the email. You won't even see the S/MIME attachment in the message source. Send the same email and then check the message in MS Outlook and you WILL see the attachment. Very very bad..

Please dont' forget that this bug and bug #92111 are really the same. THis one is a little more technical, the 92111 explains some workarounds.

It's described in Fetchmail FAQ that exchange does not report the full size of message, but the size of the compressed version it has inside it's database. There is a work around by modifying a registry key on the imap server. http://www.tuxedo.org/~esr/fetchmail/fetchmail-FAQ.html > Somewhat belatedly, I've learned that there's supposed to be a registry bit > that can fix this breakage: > > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MsExchangeIs\Parameters System\Pop3 Compatibility > > This is a bitmask that controls the variations from the standard protocol. The > bits defined are: > > 0x00000001: > Report exact message sizes for the LIST command

S/MIME QA -> Charles. (Ccing Gregg for MS Exchange) Charles, can you confirm whether this problem is still occurring on our Netscape Messaging Server or not? Also, does your S/MIME testing cover MS Exchange Server?

I don't regularly test MS-Exchange, although we do have some bugs that we have uncovered due to Exchange. I have plans to add it into the regular test cycle right after I wrap up some Outlook family related bugs I have been working on. When I do test, it is primarily on PoisonOak. This particular bug, while I can see where it would render s/mime useless, actually has nothing to do with s/mime however. The kinds of bugs that I have noticed (related to s/mime specifically) are things like the conversion of 8bit chars to 7bit during transport rendering the signature invalid, etc... My question is, which version of Exchange are we talking about here, and is it a bug in Exchange that we want to workaround (i.e. a microsoft feature that magically allows only MS products to interoperate correctly), or are there newer versions of Exchange that fix this in addition to the workaround mentioned in comment 4.

The problem with comment 4 is getting the administrator of the server to apply the workaround, mainly when all they are concerned about are MS Outlook clients. According to the banner message I get when I telnet to the imap port, it is running MS Exchange IMAP4rev1 server version 5.5.2653.23

This is the errormsg window which appears when opening an imap folder with a big (> 4 MB) mail in it.

I can confirm this is still happening on Thunderbird 1.5.0.4 on Windows XP. We want to test the workaround described in the Fetchmail FAQ, but unfortunately we cannot do this on our production Exchange 2003 server. And we don't have a test environment yet :-(.

Rubin, Henrik, do you still see this? possible dupes: Bug 114576 related? bug 326833

Since I'm not using exchange anymore, I can't confirm if this issue still exists. I do remember that we did apply the workaround mentioned (pop compat=1) and that seemed to work at the time.

bienvenu, should consider this bug fixed or dupe? we fixed at least one such bug a couple years ago and another is still open iirc.

(In reply to Wayne Mery (:wsmwk) from comment #12) > bienvenu, should consider this bug fixed or dupe? > we fixed at least one such bug a couple years ago and another is still open > iirc. I'd say dup of bug 92111.