http://dovecot.org/releases/dovecot-1.0.rc29.tar.gz http://dovecot.org/releases/dovecot-1.0.rc29.tar.gz.sig Probably one more RC after this. * Security fix: If zlib plugin was loaded, it was possible to open gzipped mbox files outside the user's mail directory. + Added auth_gssapi_hostname setting. - IMAP: LIST "" "" didn't return anything if there didn't exist a namespace with empty prefix. This broke some clients. - If Dovecot is tried to be started when it's already running, don't delete existing auth sockets and break the running Dovecot - If deliver failed too early it still returned exit code 89 instead of EX_TEMPFAIL. - deliver: INBOX fallbacking with -n parameter wasn't working. - passdb passwd and shadow couldn't be used as master or deny databases - IDLE: inotify didn't notice changes in mbox file - If index file directory couldn't be created, disable indexes instead of failing to open the mailbox. - Several other minor fixes -------------- 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-news/attachments/20070330/8e3541bc/attachment.pgp
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Timo Sirainen schrieb:> http://dovecot.org/releases/dovecot-1.0.rc29.tar.gz > http://dovecot.org/releases/dovecot-1.0.rc29.tar.gz.sig > > Probably one more RC after this. > > * Security fix: If zlib plugin was loaded, it was possible to open > gzipped mbox files outside the user's mail directory. > > + Added auth_gssapi_hostname setting. > - IMAP: LIST "" "" didn't return anything if there didn't exist a > namespace with empty prefix. This broke some clients. > - If Dovecot is tried to be started when it's already running, don't > delete existing auth sockets and break the running Dovecot > - If deliver failed too early it still returned exit code 89 instead > of EX_TEMPFAIL. > - deliver: INBOX fallbacking with -n parameter wasn't working. > - passdb passwd and shadow couldn't be used as master or deny databases > - IDLE: inotify didn't notice changes in mbox file > - If index file directory couldn't be created, disable indexes instead > of failing to open the mailbox. > - Several other minor fixes >HI Timo, you added the wiki in txt format to the docs dir, this again brokes my suse spec *g - -- Mit freundlichen Gruessen Best Regards Robert Schetterer https://www.schetterer.org Munich/Bavaria/Germany -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGDTESfGH2AvR16oERAkisAJ45K6MnCCR2XTSdEA7HUef2ihdA0wCeLpJz XE+W4N94pM5vjpbXosgHiHY=oitS -----END PGP SIGNATURE-----
On Saturday March 31, 2007 at 08:32:40 (AM) Jeff A. Earickson wrote:> My one concern about dovecot is the "feeping creaturism" in the code. > Why does it have to be an LDA? That is what procmail is for. And designing > your own mailbox format (dbox?) seems dangerous too. I would have it > stick to POP and IMAP, period. But then it is not my code either. > It works great for IMAP, which is what I need.Personally, I like the LDA feature in Dovecot. Procmail is a memory hog with a cavorted rules configuration scheme. Its use has seriously declined in favor of better products now available. Procmail is best left to single user status. I would never consider employing it in a multi user environment, although I know it has been done. Why though I fail to understand. There are better and easier methods available. There is no inherent danger in designing your own inbox structure, provided that no other application attempts to access it incorrectly. Dovecot would not be the first LDA/POP/IMAP application to do this. -- Gerard "A psychiatrist is a man who goes to a strip club and watches the audience." Merv Stockwood
On Sat, Mar 31, 2007 at 08:32:40AM -0400, Jeff A. Earickson wrote:> My one concern about dovecot is the "feeping creaturism" in the code. > Why does it have to be an LDA? That is what procmail is for. And > designing your own mailbox format (dbox?) seems dangerous too. I would > have it stick to POP and IMAP, period. But then it is not my code > either. It works great for IMAP, which is what I need.Using the Dovecot LDA will improve POP3/IMAP performance, as the index files are being updated on delivery instead of login time. So it sure makes sense to combine the LDA with the POP3/IMAP daemon. An as soon as those are combined, the actual mailbox format (mbox/maildir/dbox) is just an internal interface for dovecot. Geert
Jeff A. Earickson wrote:> My one concern about dovecot is the "feeping creaturism" in the code. > Why does it have to be an LDA? That is what procmail is for. And > designing your own mailbox format (dbox?) seems dangerous too.Both features were done for paying customer. Dovecot LDA is lot more than procmail is, for example, how would you implement a proper out of office reply only using procmail? You also have great performance benefits when using Dovecot LDA over procmail, indexing for both Maildir and mbox and header padding for mbox. Tomi
At 8:32 AM -0400 3/31/07, Jeff A. Earickson wrote:>On Fri, 30 Mar 2007, Frank Cusack wrote: >>FWIW, in my experience, all 1.0 software is utter shit and should be >>avoided like the plague if stability is a requirement. So 0.99, 1.0, etc >>is all meaningless to me. > >1.0 = shit is almost always true for payware IMHO. Open source has a far >better track record on this. If I had to give dovecot a version number >right now, I would say it is about version 9.8. > >My one concern about dovecot is the "feeping creaturism" in the code. >Why does it have to be an LDA? That is what procmail is for.That specific case is a very good thing. Procmail is not a good piece of software to rely on and offer to users as their filtering tool. -- Bill Cole bill at scconsult.com
On Fri 30 Mar 2007 at 06:07PM, Timo Sirainen wrote:> http://dovecot.org/releases/dovecot-1.0.rc29.tar.gz > http://dovecot.org/releases/dovecot-1.0.rc29.tar.gz.sig > > Probably one more RC after this.Hey all-- for those interested in deploying 1.0rc29, I just wanted to report that I deployed 1.0.rc29 Monday evening and it has been absolutely rock solid for the past 48 hours: zero core dumps, and I have fielded no significant complaints in the past two days. At this moment we have 220+ processes in our dovecot deployment serving 103 users. We did a little measurement and it's nice to see that dovecot is very resource efficient; here is an aggregated view of all of the dovecot processes we are using: PROJID NPROC SWAP RSS MEMORY TIME CPU PROJECT 100 221 179M 196M 0.6% 2:22:24 0.2% imap ^^^^ So my runtime RSS per User is about 2MB. Wow. (In recent Nevada builds we've refined prstat's ability to correctly measure RSS for projects, zones, etc. so this number should be pretty accurate). We're still working on debugging why our Kerberos setup isn't working-- Thanks to Timo we have auth_gssapi_hostname, but we're still not quite there... our Kerberos engineers are looking into it. I've gotten a lot of compliments about how stable and fast our setup is compared with the old deployment-- those really should go to Timo. Thanks! -dp -- Daniel Price - Solaris Kernel Engineering - dp at eng.sun.com - blogs.sun.com/dp