[Dovecot] Converting from UW-IMAP to dovecot - odd client problems

Michael Durket durket at highwire.stanford.edu
Wed Mar 19 19:43:01 EET 2008


Our installation currently uses an old version of UW-IMAP. Instead of  
upgrading to the latest
version, we're in the process of testing dovecot 1.0.13 on a Solaris 9  
machine (using a different
set of network ports of course so both the old and new systems can  
coexist during testing).

We've been asking selected users to switch from UW-IMAP to dovecot in  
order to test various
clients and OSes with dovecot. On our system the inboxes are always on  
local disk, but the
indexes and any folders may be on NFS or local disk (it has to do with  
how and where we
added disk as our user population increased over time). Only a single  
server is ever used
and I've made sure for our version of dovecot that the settings  
specified for NFS are as
described in the Wiki article.

We've noticed some oddities which we can't figure out:

     1) When siwtching a Thunderbird user running on a Fedora system  
(latest version of
          Thunderbird) Thunderbird couldn't see his mail folders even  
when the appropriate
          checkbox  (Server Settings -> Advanced -> Show Only  
Subscribed Folders) was
          unchecked. Clearing out the IMAP Server Directory setting  
seemed to fix this, but
          the very next day, the folders were gone again and we've  
been unable since to get
          Thunderbird to see them.

          Using the same version of Thunderbird, running on Mac OS X  
10.5.2 yields no such
          problem.

           Another problem with this same user involved a test wherein  
we created a new
           mail folder and then deleted it. The deletion caused an  
error message to be displayed
           (inferior folders, etc) but on the Mac OS X version no such  
error occurred and the
           folder was deleted. Investigating the protocol traces for  
Thunderbird showed that in the
           error case, it attempted to rename the deleted folder as a  
subfolder of the Trash folder
           (thus generating the error message) but on the Mac OS X  
version, it actually deleted
           the folder (which would seem to make more sense). The  
settings pertaining to the Trash
           folder are the same on both clients.

     2)  When switching an Apple Mail.app user running on Mac OS X  
10.4.11 (Tiger) at the
           latest patch level, things appeared to work fine, and then  
the user mentioned that
           no mail was showing up in her inbox. Closing and restarting  
Mail.app appeared to
           fix that temporarily. She normally keeps a large number of  
messages in her inbox
           (approximately 7000+) and receives a large number of  
messages each day (several
           hundred).

           In this case, the Postfix mail logs showed that mail was  
being received, and the procmail
           delivery log for this user showed that procmail was putting  
the mail in her inbox, yet
           Mail.app was not indicating the presence of new mail (until  
it was restarted). Also Mail.app
           became very very slow at startup and shutdown (taking  
several minutes as compared to
           a few seconds normally).

     We've had no problems so far with another Tiger Mail.app user  
(but his inbox is considerably smaller)
and no problems yet with converting a Eudora user running under  
Windows, but this is a stumbling
block in our efforts to convert to dovecot since we'd hoped to be able  
to switch users over fairly
easily (just by changing the port address mostly).

     While these woud seem to be client problems at first glance, the  
common factor of course is dovecot.
There are no problems with any of these clients using UW-IMAP. I'm  
hoping that perhaps there are some
readers of this list that might have seen similar problems and know of  
solutions, or could point me to
some ways of debugging these problems (with Thunderbird I can at least  
debug IMAP protocol exchanges,
but since dovecot doesn't log IMAP exchanges for specific IPs and  
since the socket connections are all
via STARTTLS I can't use tcpdump so I'm kind of at a loss for how to  
track these things down short of
patching the dovecot code to put in tracing messages).

     Any suggestions would be appreciated (and would help us complete  
our conversion to dovecot).

     Michael Durket



More information about the dovecot mailing list