[Dovecot] outstanding issues with 0.99.13

[sean finney]

hi list,

i'm in the process of testing dovecot before a hopeful switchover from
uw-imap/qpopper to dovecot, primarily to get off of the uw-imap/mbox
combo and moved to Maildir.  i think we've worked out the logistics to
avoid any service downtime, with only a short window of a few minutes
per user for when we convert from mbox to maildir format.

however, during testing a few issues have come up, some of which i've
been able to work around, others which i haven't.  for those that i have
been able to work around, i'll include my solution so that fellow
googlers may profit, and for those that i haven't i'd really appreciate
your feedback.

logistical problems:

1 - automagic detection and uw-imap inbox in ~/mbox.  i'm not sure if
    this is a default characteristic or if it's specific to us, but
    our spool is in /var/mail/foo and inbox in ~/mbox.  the automagic
    Maildir/mbox detection doesn't find the "mbox", and i can't tell it
    where it is because then it doesn't look for the Maildir.
  solution: i wrote a small patch to dovecot's autodetect code to help 
    it find the location of our mailboxes.  if anyone would like a copy
    of said patch i can send it off list.

2 - uw-imap's spool/inbox message moving.  i read from the wiki that
    this isn't a feature currently being worked on.
  solution: deliver all mail to the same place.  since we use procmail
    as our MDA, this isn't too hard of a problem.  basically we redirect
    mail to the inbox and redeliver everything in the spool.

3 - supporting multi-homed services + ssl.  for historical reasons we
    provide services from multiple hostnames (mail.foo, imap.foo, etc).
    with ssl, that means a different cert for each, otherwise some
    clients will break.
  solution: we're spawning off three seperate dovecot instances, each
    using a different config file.  not the most graceful, but it
    works...

application problems:

4 - dovecot imap + ms lookout 2002 + deleting messages.  i'm not sure if
    this is an app or server side problem.  basically, a user will
    delete a message, only to have it reappear in the mailbox a short
    time (few minutes) later.  if i monitor the state of the mbox file,
    no changes are made to it until the user selects "empty trash",
    after which point they are expunged.  looking at a protocol dump, i see
    the client setting the deleted flag on the message when they
    originally delete it.  here's an excerpt:

<snip>
tg7i OK Idle completed.

6gzd UID STORE 30021 +FLAGS (\Deleted \Seen)

* 51 FETCH (FLAGS (\Deleted \Seen \Recent) UID 30021)
6gzd OK Store completed.

stpw IDLE
<snip>

    i'm not too familiar with imap, but it looks like the server is
    caching the deletion request and then forgetting later forgetting
    about it?  i have all the "client workarounds" enabled, fwiw.
  solution: ???

5 - mac os x + eudora + deleting mail.  a different problem alltogether.
    in eudora deleting a mail seems to immediately move it to the
    "trash" mailbox, so the above problem does not occur.  what *does*
    happen is that if a user rapidly deletes messages one-by-one, an
    error message pops up about UID's not existing.  i haven't gotten
    a full description of this problem, but here's an excerpt from
    what i think is the symptom:

<snip>
A00109 UID COPY 30002 Trash

A00109 OK Copy completed.

A00110 UID STORE 30002 +Flags.silent (\Deleted)

A00110 OK Store completed.

A00111 EXPUNGE

* 31 EXPUNGE
A00111 OK Expunge completed.
<snip>
    and later:
<snip>
A00040 UID FETCH 30002 (UID BODYSTRUCTURE)

A00040 NO Some of the requested messages no longer exist.

A00041 UID FETCH 30002 RFC822.SIZE

A00041 NO Some of the requested messages no longer exist.

A00042 UID FETCH 30002 (BODY.PEEK[])

A00042 NO Some of the requested messages no longer exist.
<snip>
    which i suppose is correct that it doesn't exist (since it was moved
    out of the inbox).  however, eudora does not have this problem with
    uw-imap, and i'm wondering what might be causing it?
  solution: ???


okay, i think that's everything that i've ran into.  we're still pushing
ahead with this because we need to get the hell off of uw-imap/mbox,
but i don't think we'll be able to stick with dovecot if these are
unresolvable issues.  in that case, we'll probably use dovecot with
these minor nuisances while we transition, and then perhaps use
courier in the long run.  hopefully that won't have to be the case
though :)

if anyone has any experience specifically with "5" and "5", i'd
really, really like to hear about it.  in the meantime, i'll continue
to test other things, and also see if the problem also persists when
mail is stored in Maildir format.


anyway, thanks for your time!
	sean
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://dovecot.org/pipermail/dovecot/attachments/20050209/e30837f3/attachment-0001.bin>