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 at 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 systems
On 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20030111/4090508d/attachment-0003.bin>
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/itYes, 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.