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