Windows Live Mail stalls reading a PN IMAP Inbox

[#1]

Windows Live Mail* (WLM) stalls when UID FETCHing a range (sequence set) of headers
On setting up a new WLM account for one particular PN IMAP account, WLM downloads some headers then stalls.
One of my IMAP Inboxes (at the PN end) has 312 messages. The lowest message UID is 1623 and the highest is 2094. The first FETCH (during account setup) stalled after retrieving 124 headers (header 124 has UID 1779 and header 125 has UID 1783). Any subsequent Send/Receive just stalls (“Your IMAP server has not responded within 60 seconds…”).
From the WLM trace, the essential dialogue is:
IMAP [tx] a3mx SELECT "INBOX"
IMAP [rx] * FLAGS (\Draft \Answered \Flagged \Deleted \Seen \Recent)
IMAP [rx] * OK [PERMANENTFLAGS (\* \Draft \Answered \Flagged \Deleted \Seen)] Limited
IMAP [rx] * 312 EXISTS
IMAP [rx] * 0 RECENT
IMAP [rx] * OK [UIDVALIDITY 1370898774] Ok
IMAP [rx] * OK [MYRIGHTS "acdilrsw"] ACL
IMAP [rx] a3mx OK [READ-WRITE] Ok
IMAP [tx] u7d7 UID FETCH 1:* (BODY.PEEK[HEADER.FIELDS (References X-Ref X-Priority X-MSMail-Priority Importance X-MSOESRec Newsgroups)] ENVELOPE RFC822.SIZE UID FLAGS INTERNALDATE)
IMAP [rx] * 1 FETCH (BODY[HEADER.FIELDS ("References" "X-Ref" "X-Priority" "X-MSMail-Priority" "Importance" "X-MSOESRec" "Newsgroups")] {2}
IMAP [rx]  ENVELOPE ("…header information…")
IMAP [rx] * 2 FETCH (BODY[HEADER.FIELDS ("References" "X-Ref" "X-Priority" "X-MSMail-Priority" "Importance" "X-MSOESRec" "Newsgroups")] {59}
IMAP [rx]  ENVELOPE ("…header information…")
.
.
IMAP [rx] * 123 FETCH (BODY[HEADER.FIELDS ("References" "X-Ref" "X-Priority" "X-MSMail-Priority" "Importance" "X-MSOESRec" "Newsgroups")] {60}
IMAP [rx]  ENVELOPE ("…header information…")
IMAP [rx] * 124 FETCH (BODY[HEADER.FIELDS ("References" "X-Ref" "X-Priority" "X-MSMail-Priority" "Importance" "X-MSOESRec" "Newsgroups")] {79}
IMAP [rx]  ENVELOPE ("…header information…")
…then waits and waits and waits…for no obvious reason
The ("…header information…") above contains the date, title, addressee etc
The " UID FETCH 1:* " is 'get records with UIDs between 1 and the highest in use'. UID 1 does not have to exist

If I reissue a Read/Write against the account, WLM just waits and waits....
Again,  the essential dialogue is:
IMAP [tx] c8uz SELECT "INBOX"
IMAP [rx] * FLAGS (\Draft \Answered \Flagged \Deleted \Seen \Recent)
IMAP [rx] * OK [PERMANENTFLAGS (\* \Draft \Answered \Flagged \Deleted \Seen)] Limited
IMAP [rx] * 312 EXISTS
IMAP [rx] * 0 RECENT
IMAP [rx] * OK [UIDVALIDITY 1370898774] Ok
IMAP [rx] * OK [MYRIGHTS "acdilrsw"] ACL
IMAP [rx] c8uz OK [READ-WRITE] Ok
IMAP [tx] wdir UID FETCH 1780:* (BODY.PEEK[HEADER.FIELDS (References X-Ref X-Priority X-MSMail-Priority Importance X-MSOESRec Newsgroups)] ENVELOPE RFC822.SIZE UID FLAGS INTERNALDATE)
…at which point we wait and wait and wait…

UID FETCH 1780:* syntax literally means 'fetch those records that have UIDs lying between 1780 and the highest UID currently in the mailbox. UID 1780 itself does not have to exist, but unless the mailbox is empty the '*' should ensure that at least one record is returned)  
 
Outlook 2010 works fine against the same Inbox, and the UIDs (above) come from running an Outlook trace.
Non-sequential UIDs and FETCHing using non-existent UIDs are specifically allowed by RFC3501, and Outlook’s version of the UID FETCH (above) was:
6ftr FETCH 312 (UID)
IMAP: 18:39:18 [rx] * 312 FETCH (UID 2094)
IMAP: 18:39:18 [rx] 6ftr OK FETCH completed.
IMAP: 18:39:18 [tx] b81t UID FETCH 1:2094 (UID FLAGS)
… which is followed by retrieval of 312 skeleton headers
i.e. UID 1 does not exist but UID 2094 does.
Outlook cautiously asks for every (skeleton) header with a UID in the range 1-2094 (i.e 'give me everything you have') whereas WLM tries to fetch the (fuller) header of every header it doesn't currently have (it doesn't ask for the lot).
WLM's code looks valid (but - in the second case - risky where WLM relies on its local log of the highest UID previously  downloaded). The fault appears to lie with Courier (I assume PN uses the Courier IMAP interface) since it should return some response and not stall.
Any ideas or similar experiences pls?  
* versions 2009 (build 14), 2011 (build 15) and 2012 (build 16)  running on Win7

[#2]

Not directly compatible (Linux/claws-mail ), but I have had couple of IMAP failures this year - both the result of a corrupted local "control" file, corrected by restoring a few files from a "pre-fail" backup
Phil
Edit: Forgot to mention that the server is a local system and it's disk activity peaked during the failed access, with c-m not responding.

[#3]

If you're able to identify the message it's stalling at then is it worth deleting or moving that message using Webmail to see if that helps?

[#4]

Yes Bob. The first thing I originally tried was to use webmail to delete the 'next 'email; the Inbox then moved on to the next email and stalled there.
However, you gave me an idea...
I used webmail to move one of the 'next' emails to the Drafts box (which hitherto had worked fine). And it caused the Drafts box synch to stall! The culprit!
But there were apparently <i>several</i> culprits.
So  I simply worked my way though the Inbox using webmail to forward (and then delete) each 'next' email to a POP account which is accessed by Outlook.
After such five culprits were removed the Inbox sprang into life.
Looking at these in in a separate Outlook environment disclosed that they all had .docx attachments sent from the same individual (the emails themselves were not from the same individual - some were forwarded) which - although they opened successfully - had very strange sizes:100KB vs a more reasonable 16Kb when opened and then saved.
I re-sent the emails (with cleaned up .docx attachments) back to the failing IMAP account and they were received successfully. They don't of course have the original 'received' date but that is a minor penalty.
This doesn't explain why Outlook was happy when WLM hiccuped since neither Outlook nor WLM were actually retrieving the document - just the headers. But Outlook's dialogue was different from WLM's: Outlook gets just the flags (presumably later in a subsequent dialogue it gets the full headers) whereas WLM asks for all the header and some of the 'bodystructure' information including RFC822.SIZE. Were the latter corrupt (and i cannot remember offhand whether RFC822.SIZE includes attachments), Courier (or whatever the IMAP interface is) could get very upset. Anyhow, that is hypothesising; the good news is that I have a solution.
So if anyone else has a similar problem, try this first!  

[#5]

Excellent, glad you managed to sort it