[Dovecot] outstanding issues with 0.99.13

[Timo Sirainen]

On Wed, 2005-02-09 at 11:48 -0500, sean finney wrote:
> 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...

With 1.0-tests you can create server { .. } blocks so there's only one
dovecot master process, but still multiple login processes. I'm thinking
about removing this feature and rather create a separate configuration
process which allows dynamic configuration based on different rules. For
example in your case you'd set cert file based on target IP address.

I'm not really sure how that dynamic configuration lookup would work. At
least with SQL it would be pretty simple because you can put the rules
into the SQL queries, but I'm not sure if I should support anything
else..

I was also thinking about modifying dovecot-auth so that you could
include whatever configuration settings there to make user-specific
settings. Especially the mail-setting wouldn't be a special case anymore
then.

> 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: ???

So later the \Deleted flag is lost? And this is with maildir? Is the
maildir filename updated by adding 'T' flag to it?

> A00040 UID FETCH 30002 (UID BODYSTRUCTURE)
> A00040 NO Some of the requested messages no longer exist.

This is actually a bug, UID FETCH should never fail.

1.0-tests also has the same problem, except instead of replying with
"NO" it disconnects the client. This only happens when one connection
expunges the mail and another tries to fetch it but notices that it's
gone.

I'll try to get this fixed for 0.99.14 and next 1.0-test.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://dovecot.org/pipermail/dovecot/attachments/20050209/7f31f588/attachment-0001.pgp