dovecot - Dec 2004 - 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20050106/216c5ec3/attachment-0001.bin>