I apologize if this is the incorrect forum to post this to - perhaps it belongs in the "Migration" forum.I'm struggling with the odd behaviour of Exchange 2007 IMAP server. I'm seeing this behaviour with both a production Hosted Exchange (2007) installation and a Exchange "Trial" installation. I do *not* see this behaviour with our production Exchange 2003 installation. I have to add that I have very limited experience with Exchange (other than as an end-user that is). I live predominantly in the Unix world However, my organization's Exchange administrators are currently at a loss as to what is going on so I don't feel too bad I picked this up whilst trying to put a solution together to migrate mailboxes from an IMAP server to the above Hosted Exchange system. I have had good mileage out of the Perl "imapsync" script in the past and started off testing with this. I found that as the script was trying to CREATE all the folders found in the source IMAP mailbox in the target (Exchange) mailbox, Exchange would abruptly close the connection, consistently, on the attempt to create the tenth folder. Weird enough. As I said above, I see the same behaviour on a "Trial" 2007 installation whilst our 2003 installation works fine. I've tinkered about with test scripts and telnet'ing to Exchange's IMAP and the problem seems to be that Exchange forces the IMAP connection closed after receiving ten IMAP commands from the client that have caused it (Exchange) to respond with an IMAP "NO" status response. This is during any given session that is. So, getting back to the imapsync script, the underlying Perl IMAP module that is used creates a new folder on the server by first issuing an IMAP "STATUS <folder name> (Messages)" command to test for the existance of the folder before issuing an IMAP "CREATE <folder name>". In cases where the source mailbox has ten or more folders not found in the target (Exchange) mailbox, then, of course, Exchange forces the connection closed on the tenth folder. What is concerning is that the connection is simply closed without Exchange issuing an IMAP "BYE" response.It's easiest to show this by means of a test telnet session:root@myhost:~# telnet imap.xyz.com 143Trying 123.123.123.123...Connected to imap.xyz.com.Escape character is '^]'.* OK Microsoft Exchange Server 2007 IMAP4 service ready0 login bob@imap.xyz.com ********0 OK LOGIN completed.1 status f1 (Messages)1 NO f1 doesn't exist.2 status f2 (Messages)2 NO f2 doesn't exist.3 status f3 (Messages)3 NO f3 doesn't exist.4 status f4 (Messages)4 NO f4 doesn't exist.5 status f5 (Messages)5 NO f5 doesn't exist.6 status f6 (Messages)6 NO f6 doesn't exist.7 status f7 (Messages)7 NO f7 doesn't exist.8 status f8 (Messages)8 NO f8 doesn't exist.9 status f9 (Messages)9 NO f9 doesn't exist.10 status f10 (Messages)10 NO f10 doesn't exist.Connection closed by foreign host. <=== Exchange closes connectionroot@myhost:~#Note that this is not specific to the IMAP "STATUS" command; on the tenth issuing of a "NO" response, in response to any combination of ten commands from the client, Exchange closes the connection.Rather a long-winded explanation, apologies. I can't help wondering whether this is a security/denial-of-service related issue. Is this a known issue and is there a solution? Is there perhaps an Exchange configuration parameter to alter this behaviour?Many thanks in advance!

I have experienced the same problems myself, and I doubt you are going to get any kind of fix, or even a responsetothis. The two systems I have tried include Exchange Labs (hosted Exchange system) and an in house version of Exchange 2007 Enterprise. I found out about Exchange 2007's IMAP problems while trying to migrate e-mail accounts from a non Exchange IMAP server to Exchange 2007. I ended up using a hacked-up version of imapsync to get it done, but there are still a lot of problems with the solution. In particular the problem you mention above still stops my hacked-up version of imapsync in its tracks. Luckily I only had a handful of user accounts with more than nine folders to migrate, and I ended up doing those by hand. Good luck.

I'mseeing the same thing. Exchange closes connections with TCP RST packets for no reason we can see. I have several irate Thunderbird users that are threatening the overall success of our Exchange migration. What's going on here? How can I troubleshoot this further. Documentation on the IMAP service on Exchange 2007 seems to be very hard to find. m.

I don't think that there is anything you can do to fix the problem since it is a design flaw in Exchange 2007. From my experience thus far, forget using IMAP clients, you're unfortunately going to have to use POP. Otherwise, you'll have to use clients that support Exchange.