[Dovecot] 0.99.1[12] IMAP problems with Apple Mail.app?
Is anyone else having trouble using the Apple OS X Mail.app with a Dovecot IMAP server?
With 0.99.11 and 0.99.12 attempting to read certain messages using IMAP
or IMAPS seems to put Mail.app into spinning pizza of death mode.
Sniffing the connection, it looks like it happens after the client
issues a BODY.PEEK[] and the server has responded with the (UID XXXX
BODY[] {YYYY}...) and OK Fetch completed. I've only been able to catch
it happening with messages that are either (a) Base64 encoded or (b)
those that claim to be multi-part/alternative, but only seem to contain
a single part. The client acts like it has received the message, since
if I kill Mail.app and restart it, I am able to read the problem
message from its cache. Is this a Mail.app bug? Is it something about
the way Dovecot is responding to the BODY.PEEK[] in these cases?
Using Mail.app with the Novell myrealbox.com IMAP I haven't seen problem, even with a test problematic message I redirected there, although admittedly I'm changing the headers by doing the redirection.
I haven't gotten 0.99.13rc3 to get past the autotools stage of complaining about AM_ICONV (and a number of AC_ warnings), so I've yet to try it.
I've been using mail.app against Dovecot 0.99.10.9 for 3 months now without a problem (except that it's slow as mud). However, it's entirely likely that I have not received any messages formatted the way you describe.
- Pete
On Dec 31, 2004, at 5:56 AM, Jim Tittsler wrote:
Is anyone else having trouble using the Apple OS X Mail.app with a Dovecot IMAP server?
With 0.99.11 and 0.99.12 attempting to read certain messages using IMAP or IMAPS seems to put Mail.app into spinning pizza of death mode. Sniffing the connection, it looks like it happens after the client issues a BODY.PEEK[] and the server has responded with the (UID XXXX BODY[] {YYYY}...) and OK Fetch completed. I've only been able to catch it happening with messages that are either (a) Base64 encoded or (b) those that claim to be multi-part/alternative, but only seem to contain a single part. The client acts like it has received the message, since if I kill Mail.app and restart it, I am able to read the problem message from its cache. Is this a Mail.app bug? Is it something about the way Dovecot is responding to the BODY.PEEK[] in these cases?
Using Mail.app with the Novell myrealbox.com IMAP I haven't seen problem, even with a test problematic message I redirected there, although admittedly I'm changing the headers by doing the redirection.
I haven't gotten 0.99.13rc3 to get past the autotools stage of complaining about AM_ICONV (and a number of AC_ warnings), so I've yet to try it.
On Fri, 2004-12-31 at 19:56 +0900, Jim Tittsler wrote:
Is anyone else having trouble using the Apple OS X Mail.app with a Dovecot IMAP server?
I haven't noticed any problems, but I've been using 1.0-tests for a long time now.
With 0.99.11 and 0.99.12 attempting to read certain messages using IMAP or IMAPS seems to put Mail.app into spinning pizza of death mode.
Sniffing the connection, it looks like it happens after the client issues a BODY.PEEK[] and the server has responded with the (UID XXXX BODY[] {YYYY}...) and OK Fetch completed. I've only been able to catch it happening with messages that are either (a) Base64 encoded or (b) those that claim to be multi-part/alternative, but only seem to contain a single part. The client acts like it has received the message, since if I kill Mail.app and restart it, I am able to read the problem message from its cache. Is this a Mail.app bug? Is it something about the way Dovecot is responding to the BODY.PEEK[] in these cases?
If you delete the message from Mail.app cache (~/Library/Mail/..), does it happen again? Can you send me one such message?
I haven't gotten 0.99.13rc3 to get past the autotools stage of complaining about AM_ICONV (and a number of AC_ warnings), so I've yet to try it.
You wouldn't have needed auto* stuff if you just ran configure.
participants (3)
-
Jim Tittsler
-
Peter Lacey
-
Timo Sirainen