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.