FWIW, this patch to reclaim disk space during IMAP IDLE seems to
cause problem with Outlook clients.
Both Outlook Express and Outlook reported errors like:
* Can not display the folder tcp/ip error occurred while trying
to access folder
* This IMAP command could not be sent to the server before the
connection was terminated.
* Your 'BLAH' folder was not polled for its unread count.
Could not get the unread counts for 'BLAH' on '<servername>'
Account: '<accountname>'. Server: '<servername>', Protocol
IMAP. Server Response: 'This IMAP command could not be sent
to the server before the connection was terminated.' Port:
993, Secure(SSL), Yes. Error Number: 0x800CCC0F
* Header download for the 'Inbox' folder did not complete.
Could not select 'Inbox' on the IMAP server. You might
try refreshing your folder list to synchronize with
the IMAP server. Account: <accountname>. Server:
'<servername>'. Protocol: IMAP, Server Response: 'This IMAP
command could not be sent to the server before the connection
was terminated.' Port: 993, Secure(SSL): Yes, Error Number:
0x800CCC0F.
The few other clients that we tested showed no problems. Thunderbird,
Eudora, Alpine, Horde/IMP were all fine.
I can only guess that Outlook does not like the reclaimed notification
during the IMAP IDLE loop. Here is a snippet of telemetry showing
the differences before and after the patch.
This is me typing commands directly to the server via openssl s-client.
BEFORE
-------
a1 IDLE
+ Waiting for DONE
[perform deletion from other client]
[snip lots of expunge lines]
* 1 EXPUNGE
* 1 EXPUNGE
* 1 EXPUNGE
* 1 EXPUNGE
* 103 EXISTS
* 0 RECENT
* OK Timeout in 30 minutes
DONE
a1 OK IDLE completed
a2 logout
* BYE <server redacted> IMAP4rev1 server terminating connection
a2 OK Reclaimed 15610 bytes of expunged space
AFTER
-----
a1 IDLE
+ Waiting for DONE
[perform deletion from other client]
[snip lots of expunge lines]
* 1 EXPUNGE
* 1 EXPUNGE
* 1 EXPUNGE
* 1 EXPUNGE
* 103 EXISTS
* 21 RECENT
* OK Reclaimed 15610 bytes of expunged space
* OK Timeout in 30 minutes
DONE
a1 OK IDLE completed
a2 logout
* BYE <server redacted> IMAP4rev1 server terminating connection
a2 OK LOGOUT completed
--
David A. Halsema E-mail Administrator
Purdue University e-mail: [EMAIL PROTECTED]
Date: Sat, 13 Sep 2008 13:37:30
From: Mark Crispin <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [email protected]
Subject: RE: [Imap-uw] RIM Blackberry BIS service and inability to reclaim
space (burping) following delete/expunge
Try sticking in a call to mail_check() in the IDLE loop. I would do it
immediately after the ping_mailbox() call, then add an
fs_give((void **) &lsterr);
to reduce the resulting babble, e.g.
if (!donefake) { /* don't ping mailbox if faking */
mail_parameters (stream,SET_ONETIMEEXPUNGEATPING,
(void *) stream);
ping_mailbox(uid);
mail_check(stream);
fs_give((void **) &lsterr);
}
Sorry about the lack of formatting, but Hotmail sucks royally when trying to
enter code.
If that solves your problem, I won't mind receiving a modest honorarium for the
patch.
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
Date: Sat, 13 Sep 2008 13:07:01 -0400
From: [EMAIL PROTECTED]
To: [email protected]
Subject: [Imap-uw] RIM Blackberry BIS service and inability to reclaim space
(burping) following delete/expunge
The following message posted to the Email Administration in Higher
Education mailing list may also be of interest to readers of this mailing
list ...
---------- Forwarded message ----------
From: [EMAIL PROTECTED]
To: Email Administration in Higher Education
Date: Wed, 10 Sep 2008 16:26:58 -0400 (EDT)
Subject: Re: Blackberry, in all of its awful glory
In the last 24 hours we have had 3 Blackberry IMAP users report problems
reducing their disk space to get under the hard quota we enforce.
We see the same problem ...
Here at the University of Toronto we have about 12-15 calls per day of
customers who are over-quota, for whom "delete" followed by "expunge"
doesn't free up storage.
Based on a preliminary investigation it appears that the customers
suffering this problem all use the Blackberry BIS service. The BIS service
appears to have a long running (ie lasts weeks) IMAP session to access the
INBOX with an IMAP IDLE. (An IMAP IDLE allows BIS to be notified of new
messages essentially right away, without the need for polling.)
Our IMAP server supports concurrent IMAP sessions (including concurrent
list, fetch, and delete). Our server also appears to support concurrent
expunge (ie any client session can do an expunge, and all concurrent IMAP
sessions to the same INBOX all see the INBOX has been expunged), but
actual freeing of space (sometimes called "burping"), only happens when a
session is able to get exclusive access to the INBOX.
As far as we can see, RIM's BIS server is acting according to IMAP
standards. The problem lies in the inability to perform burping with
concurrent access.
As a bypass to the this problem, we are currently considering killing
BIS initiated TCP/IP sessions every 10 minutes, if the customer is
over-quota.
Technical details
We think the problem has been happening since about mid-August. We don't
know if something changed around then (e.g. did RIM start supporting
IMAP IDLE around that time?)
Looking at IMAP logs, one sees many short lived connections from the RIM
BIS service. (We haven't confirmed this, but these are likely to be for
fetching messages.) One needs to do a "ps" to see the long living IMAP
processes.
Most of the long running BIS initiated IMAP sessions appear to have
started on a Saturday. ie right now we see sessions that started Aug 16,
Aug 23, and Aug 30. Perhaps RIM restarts BIS servers on Saturdays,
rotating which BIS sever is restarted each Saturday ?
We use Washington IMAP with MIX format. Mark Crispin documented burping in
http://www.washington.edu/imap/documentation/mixfmt.txt.html including
"Shared burping has been a problem for every other IMAP server. Most get
it wrong, and cause terrible confusion to clients (including client
crashes)."
References for related problems which may shed light on the current
problem,
IMAP IDLE
KB13816
July 25, 2007
http://www.blackberry.com/btsc/articles/436/KB13816_f.SAL_Public.html
Email message delivery from IMAP IDLE integrated accounts is delayed
KB13846
Dec 13, 2007
http://www.blackberry.com/btsc/search.do?cmd=displayKC&docType=kc&externalId=KB13846&sliceId=SAL_Public&dialogID=179992621&stateId=1%200%20179994453
Blackberry blocks emails from PC
Sep 3, 2008
http://supportforums.blackberry.com/rim/board/message?board.id=8100&thread.id=4468
Alex Nishri
University of Toronto
_______________________________________________
Imap-uw mailing list
[email protected]
http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
_________________________________________________________________
See how Windows Mobile brings your life together—at home, work, or on the go.
http://clk.atdmt.com/MRT/go/msnnkwxp1020093182mrt/direct/01/_______________________________________________
Imap-uw mailing list
[email protected]
http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
_______________________________________________
Imap-uw mailing list
[email protected]
http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
