Well, "release candidate" wasn't really right name for last two versions. Maybe not for this one either, it has a few changes that could potentially break things badly (new hash table code especially). Anyway, seems to work with me. If I don't see any problems with it for a few days it'll be the final.
The really great news is that we support threading. A lot of people have not used Dovecot simply because it couldn't be used for webmails. Hmm. What's the next most important feature? .. Better mbox support? Shared folders? Quota? LDAP/MySQL/etc. authentication?
Here's the change summary:
v0.99.6 2003-01-xx Timo Sirainen tss@iki.fi
+ THREAD=REFERENCES extension support. ORDEREDSUBJECT would be easy to
add, but I think it's pretty useless.
+ SORT is much faster now.
+ mbox: If ~/mail directory isn't found, create it.
+ Log login usernames
* Some coding style changes (less typedefs)
- Mails with nested MIME parts might have caused incorrect BODY and
BODYSTRUCTURE fetches and sometimes might have crashed dovecot
(assert at imap-bodystructure.c). If client had already successfully
done the BODY fetching a couple of times, the bug couldn't happen
anymore since Dovecot then began caching the BODY data. So, this
mostly happened with new users.
- non-UID SEARCH might gave wrong replies in certain conditions.
- SORT replied always with UIDs instead of sequences.
- If authentication was aborted by client ("*" reply to AUTHENTICATE),
the login process crashed later.
- STATUS command gave invalid reply for mailboxes with spaces in name
- Timezones were parsed wrong with message dates
- Digest-MD5: We used "qop-options" instead of "qop", which was
incompatible with at least Cyrus SASL.
- Realms in passwd-file were buggy
- Literals didn't work when logging in
- Crashed if it had to wait for mbox lock
- With invalid configuration auth and login processes were just dying
and master filling log files infinitely.
- We didn't work with some 64bit systemsOn Sat, 2003-01-11 at 15:22, Timo Sirainen wrote:
Well, "release candidate" wasn't really right name for last two versions. Maybe not for this one either, it has a few changes that could potentially break things badly (new hash table code especially). Anyway, seems to work with me. If I don't see any problems with it for a few days it'll be the final.
The really great news is that we support threading. A lot of people have not used Dovecot simply because it couldn't be used for webmails. Hmm. What's the next most important feature? .. Better mbox support? Shared folders? Quota? LDAP/MySQL/etc. authentication?
I know this has been asked before. But I know a fair number of people would like dovecot to drop-in replace uw-imapd/ipopd
so two things - can you make it possible to drop in replace uw-imapd/ipopd by having a pop3 daemon come along w/it and will dovecot now handle a /var/mail/$user mbox as an inbox but allow ~/mail maildir/mbox folders?
-sv
On Sat, 2003-01-11 at 22:26, seth vidal wrote:
I know this has been asked before. But I know a fair number of people would like dovecot to drop-in replace uw-imapd/ipopd
so two things - can you make it possible to drop in replace uw-imapd/ipopd by having a pop3 daemon come along w/it
Yes, I think. pop3 should so simple enough to write in a few hours, unless I have to redesign some interfaces for accessing mail. I'll read the pop3 spec and see then.
and will dovecot now handle a /var/mail/$user mbox as an inbox but allow ~/mail maildir/mbox folders?
Yes. default_mail_env=mbox:/var/mail/$U to config file does that. Except maildir and mboxes can't be mixed for now - wouldn't be too difficult to support though.
On Sat, 2003-01-11 at 22:34, Timo Sirainen wrote:
so two things - can you make it possible to drop in replace uw-imapd/ipopd by having a pop3 daemon come along w/it
Yes, I think. pop3 should so simple enough to write in a few hours, unless I have to redesign some interfaces for accessing mail. I'll read the pop3 spec and see then.
Well, it requires a few changes it seems. Another related problem is that with mbox we should hide some of the message headers, with current code that'd messy and slow. I've also thought about supporting SQL databases to store mails, but a bit too much of the logic is index file-specific now.
So, time for a cleanup to fix all these at once. FETCH and SEARCH are the only commands whose logic should be moved, after that the lib-storage won't have hardly any IMAP specific features anymore. Any other protocols that we could support? :)
On Sun, 2003-01-12 at 17:53, Timo Sirainen wrote:
On Sat, 2003-01-11 at 22:34, Timo Sirainen wrote:
so two things - can you make it possible to drop in replace uw-imapd/ipopd by having a pop3 daemon come along w/it
Yes, I think. pop3 should so simple enough to write in a few hours, unless I have to redesign some interfaces for accessing mail. I'll read the pop3 spec and see then.
Well, it requires a few changes it seems. Another related problem is that with mbox we should hide some of the message headers, with current code that'd messy and slow. I've also thought about supporting SQL databases to store mails, but a bit too much of the logic is index file-specific now.
So, time for a cleanup to fix all these at once. FETCH and SEARCH are the only commands whose logic should be moved, after that the lib-storage won't have hardly any IMAP specific features anymore. Any other protocols that we could support? :)
well if you're bored and feel like working on an acap server I'm sure no one would be pissed. ;)
-sv
participants (2)
-
seth vidal
-
Timo Sirainen