Re: [Dovecot] dovecot-ldap for active directory 2003 r2
On Thu, 29 Mar 2007 17:15:51 -0300 Claudio Roberto Prateat [EMAIL PROTECTED] wrote: Hi, You have example of the dovecot-ldap.conf for authenticate in active directory 2003 r2 ? I have squid, apache authenticate in active directory, but dovecot return failed. Help, please... Lets see your configuration and the error message then. Best regards ! PS. Reply to the list, not to me. Dominic
Re: [Dovecot] uiddir mailbox format with benchmarks
On Thu, 2007-03-29 at 10:12 -0700, Scott Silva wrote: TS TS BTW. Does anyone have better naming ideas than uiddir? I'll commit it TS TS to CVS HEAD once I'm sure about the name. :) .. Or cydir showing its Cyrus like roots? cydir it is then. Committed to CVS HEAD if someone wants to play with it. Maybe in future it could be extended to be able to initially read the message flags from cyrus.index file to make it simple to migrate to Dovecot (even if to another format, with convert plugin). signature.asc Description: This is a digitally signed message part
[Dovecot] [PATCH] Split sql drivers from lib-sql to plugins
Hi, in order to solve rhbz#170960 [1], I split the sql drivers to plugins so that they are loaded dynamically and can be split to separate packages. [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170960 The patches are here: [2] http://people.redhat.com/tjanouse/dovecot/145241/dovecot-1.0-split.patch [3] http://people.redhat.com/tjanouse/dovecot/145241/dovecot-trunk-split.patch (mv src/lib-sql/driver-mysql.c src/plugins/sql-mysql/, etc., afterwards) I'd like to ask for your comments and whether it's ok for inclusion or at least ok to use in the Fedora package. Regards, -- Tomas Janousek, SW Engineer, Red Hat, Inc.
Re: [Dovecot] Freebsd 4 error DSN stat=Service Unavailable after dovecot install
Charles Marcus wrote: Biffy Bob wrote: Hello everyone, I am getting an error message on FreeBSD 4 after I install dovecot. To start off, I create two regular users, testuser and testuser1. Hi Bob, You might get a response if you provided a bit more info that might help, like, maybe... dovecot version dovecot -n output Since dovoecot isn't an smtp server, and what you have is a delivery problem, assuming that you had done enough troubleshooting to lead you to believe this was a dovecot problem, you would also want to provide some details on the smtp server and config. The only reason I can think of that you might think this might be a dovecot issue is: are you using dovecot LDA? Otherwise, this would be an issue with your smtp server. From the logs below, it looks to me like you don't have your delivery mechanism set up properly (sm-mta - service unavailable), but since you didn't provide any details whatsoever about your environment, all anyone can do is guess... I send each user emails then I install dovecot. After installing dovecot I set up the users in Maildir format then proceed to send them emails and here is what shows up in the maillogs: Email to testuser3 - Mar 29 22:34:52 myserver sendmail[4379]: l2TMYqwj004379: from=root, size=54, class=0, nrcpts=1, msgid=[EMAIL PROTECTED], relay=r [EMAIL PROTECTED] Mar 29 22:34:52 myserver sm-mta[4380]: l2TMYqMi004380: from=[EMAIL PROTECTED], size=342, class=0, nrcpts=1, msgid=[EMAIL PROTECTED] .vwh.net, proto=ESMTP, daemon=MTA-v4, relay=localhost [127.0.0.1] Mar 29 22:34:52 myserver sendmail[4379]: l2TMYqwj004379: [EMAIL PROTECTED], ctladdr=root (0/0), delay=00:00:00, xdelay=00:00:00, mailer=relay, pr i=30054, relay=localhost.. [127.0.0.1], dsn=2.0.0, stat=Sent (l2TMYqMi004380 Message accepted for delivery) Mar 29 22:34:52 myserver sm-mta[4381]: l2TMYqMi004380: to=[EMAIL PROTECTED], ctladdr=[EMAIL PROTECTED] (0/0), delay=00:00:00, xdelay=00:00:0 0, mailer=local, pri=30560, relay=local, dsn=5.0.0, stat=Service unavailable (something didn't work) Mar 29 22:34:52 myserver sm-mta[4381]: l2TMYqMi004380: l2TMYqMi004381: DSN: Service unavailable (something didn't work) Mar 29 22:34:52 myserver sm-mta[4381]: l2TMYqMi004381: to=myserver, delay=00:00:00, xdelay=00:00:00, mailer=local, pri=31584, relay=local, dsn=5.0.0, stat=Se rvice unavailable (something didn't work) Mar 29 22:34:52 myserver sm-mta[4381]: l2TMYqMi004381: l2TMYqMj004381: return to sender: Service unavailable (something didn't work) Mar 29 22:34:52 myserver sm-mta[4381]: l2TMYqMj004381: to=myserver, delay=00:00:00, xdelay=00:00:00, mailer=local, pri=32608, relay=local, dsn=5.0.0, stat=Se rvice unavailable (something didn't work) Mar 29 22:34:52 myserver sm-mta[4381]: l2TMYqMi004381: Losing ./qfl2TMYqMi004381: savemail panic Mar 29 22:34:52 myserver sm-mta[4381]: l2TMYqMi004381: SYSERR(root): savemail: cannot save rejected email anywhere Here is what the user looks like in /etc/passwd: testuser3:*:2400:2400:My very own test user:/home/testuser3:/sbin/nologin For the other users that have shell access, they don't get this problem. It seems to be only the users with no shell. Does anybody know of a fix for this problem? Thanks for the quick replies. I realize that some things might be seemingly out of date, but I have all the recent security patches loaded, etc. I realize that the error appears to be a sendmail issue, however, the error only manifests itself after I install dovecot. I only see the problem with the people who have no shell. The reason why I am writing to this list and not the sendmail list is because the problems only happen with dovecot installed. I can send and receive mail just fine before dovecot is installed. The problem doesn't happen on my FreeBSD 6 boxes, but I don't have the luxury of upgrading the FreeBSD 4 boxes. Here's a printout of my dovecot -n: # /usr/local/etc/dovecot.conf protocols: imap imaps pop3 pop3s disable_plaintext_auth: no login_dir: /var/run/dovecot/login login_executable(default): /usr/local/libexec/dovecot/imap-login login_executable(imap): /usr/local/libexec/dovecot/imap-login login_executable(pop3): /usr/local/libexec/dovecot/pop3-login verbose_proctitle: yes first_valid_gid: 0 mail_extra_groups: mail mail_location: maildir:~/Maildir mail_executable(default): /usr/local/libexec/dovecot/imap mail_executable(imap): /usr/local/libexec/dovecot/imap mail_executable(pop3): /usr/local/libexec/dovecot/pop3 mail_plugin_dir(default): /usr/local/lib/dovecot/imap mail_plugin_dir(imap): /usr/local/lib/dovecot/imap mail_plugin_dir(pop3): /usr/local/lib/dovecot/pop3 imap_client_workarounds(default): delay-newmail outlook-idle netscape-eoh tb-extra-mailbox-sep imap_client_workarounds(imap): delay-newmail outlook-idle netscape-eoh tb-extra-mailbox-sep imap_client_workarounds(pop3): outlook-idle pop3_uidl_format(default): pop3_uidl_format(imap): pop3_uidl_format(pop3): %08Xu%08Xv
[Dovecot] 1.0.rc29 released
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 signature.asc Description: This is a digitally signed message part
Re: [Dovecot] 1.0.rc29 released
-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-
Re: [Dovecot] make failed in doc/wiki
On Fri, 2007-03-30 at 17:46 +0200, Daniel wrote: Hi! I have this problem with cvs (1.0 branch): [...] Making all in wiki make: don't know how to make \n. Stop Did you run autogen.sh so that it downloads the doc/wiki/ contents? signature.asc Description: This is a digitally signed message part
Re: [Dovecot] [PATCH] Split sql drivers from lib-sql to plugins
Hi, On Fri, Mar 30, 2007 at 06:01:35PM +0300, Timo Sirainen wrote: I'd like to make it possible to use some configure option to decide what plugins should be compiled directly into binaries and what should be installed as plugins. So that's the long term plan. I think I may rework that patch to do this at least for the sql modules. But for now, wouldn't it simply work if you did like http://wiki.dovecot.org/CompilingSource (last section) shows? It's a bit dirty though. Does that really work? It doesn't work here unless I symlink those files to the sql subdir and apply the part of my patch that loads the modules. There's simply no code in dovecot-auth that would load the modules. Regards, -- Tomas Janousek, SW Engineer, Red Hat, Inc.
Re: [Dovecot] make failed in doc/wiki
2007. March 30. 18:13, Timo Sirainen: On 30.3.2007, at 19.03, Daniel wrote: 2007. March 30. 17:58, Timo Sirainen: On Fri, 2007-03-30 at 17:46 +0200, Daniel wrote: Hi! I have this problem with cvs (1.0 branch): [...] Making all in wiki make: don't know how to make \n. Stop Did you run autogen.sh so that it downloads the doc/wiki/ contents? I've downloaded it by myself from a nightly tarball. Does it make a difference? Then you don't need to run autoconf/automake at all. I don't have any problems with doing just ./configure;make for latest snapshot. But does running autogen.sh break it? I'm updating dovecot from cvs, but downloading the doc/wiki/* from the nightly tarball (I guess this right). Daniel
Re: [Dovecot] 1.0.rc29 released
On Fri, Mar 30, 2007 at 05:47:30PM +0200, Robert Schetterer wrote: HI Timo, you added the wiki in txt format to the docs dir, this again brokes my suse spec *g What annoys me more (as dovecot maintainer for pkgsrc) is that the example config file changes with (almost) every release. The changes are mostly just in comments, but it makes users have to merge their configuration on every update. Geert pgpsI2rExOMQR.pgp Description: PGP signature
Re: [Dovecot] 1.0.rc29 released
Le 30.03.2007 18:23, Geert Hendrickx a écrit : On Fri, Mar 30, 2007 at 05:47:30PM +0200, Robert Schetterer wrote: HI Timo, you added the wiki in txt format to the docs dir, this again brokes my suse spec *g What annoys me more (as dovecot maintainer for pkgsrc) is that the example config file changes with (almost) every release. The changes are mostly just in comments, but it makes users have to merge their configuration on every update. Changes will be certainly minimal after v1.0 final release, you can't blame Timo for trying to make something more and more usable and adapted to everybody's needs while v1.0 is still in development.. -- Nico Rien ne m'est sûr que la chose incertaine. -+- François Villon (1431-1463?), Ballade du concours de Blois (vers 9) -+-
Re: [Dovecot] 1.0.rc29 released
Geert Hendrickx wrote: What annoys me more (as dovecot maintainer for pkgsrc) is that the example config file changes with (almost) every release. The changes are mostly just in comments, but it makes users have to merge their configuration on every update. What part of Release Candidate isn't clear here... ;-) Seriously, until 1.0-final comes out, everything is up for grabs; though one would hope that the number of changes per RC is going to approach zero at some point... ;-) John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
Re: [Dovecot] 1.0.rc29 released
On Fri, Mar 30, 2007 at 12:35:09PM -0400, John Peacock wrote: What part of Release Candidate isn't clear here... ;-) release candidate equals latest supported release in this case as well. If they were 2.0 rc's, I'd continue running the latest 1.whatever release until done. Geert
Re: [Dovecot] 1.0.rc29 released
On Fri, Mar 30, 2007 at 07:35:40PM +0300, Timo Sirainen wrote: I hate how badly the configuration file updating works everywhere (well, or at least in Debian). If the changes don't really change any existing settings and won't conflict with the modified parts of the config file, there's no need to ask anything about merging. Why couldn't it work by doing a diff of the old and new default config files, and then try to patch the changes into the current config. If the patch succeeds, that's your new config. Of course if the new config file really changes existing defaults, it shouldn't do this without asking. I'm actually doing a merge dovecot.conf old-default new-default every time, and it usually causes some conflicts due to changed comments. They're easy to resolve, of course, but it could be avoided. Geert pgpcP3Q3sMDjc.pgp Description: PGP signature
Re: [Dovecot] [ rc28 ] dict{} seems to be ignored
On Thursday 29 March 2007 19:15, Emiliano Gabrielli (aka AlberT) wrote: it's attached ... tomorrow i'll compile and try the rc29 ... just tried rc29 .. nothing changed for me .. Any suggestion ? -- ?php echo ' Emiliano Gabrielli (aka AlberT) ',\n, 'GrUSP founder - ZCE',\n, ' AlberT_at_SuperAlberT_it - www.SuperAlberT.it ',\n, ' IRC:#php,#AES azzurra.com ',\n,'ICQ: 158591185'; ?
Re: [Dovecot] rc28 : can't set quotas with userdb + passwd file
On Wednesday 28 Mar 2007, Timo Sirainen wrote: I cannot get per-user quotas put in the relevant field of the userdb to work. They appear to be completely ignored; only the setting from /etc/dovecot.conf is applied. How exactly do you set it in the passwd-file? You need to set it as userdb_quota=... Thank you very much - that works. I was missing the userdb_ bit. I've amended UserDatabase/ExtraFields on the wiki to add this as an example so that people like me in future will find what they need. David -- For I am not ashamed of the gospel of Christ: for it is the power of God unto salvation to every one that believes; to the Jew first, and also to the Greek. - Romans 1:16
Re: [Dovecot] imaptest10 and stalled messages
Hi Timo et al, On 29 Mar 2007, at 17:52, Mike Brudenell wrote: But then the ODDNESS starts. I'm still a little hazy how to interpret the output of imaptest, but every now and then one or two processes stall for several seconds. When this happens activity seems to grow quieter in the imaptest output: number of operations per second decreases and the N/N count drops. Eventually it clears somehow and things spring back into life... Further to my message to the list yesterday I'm still baffled and concerned as to why imaptest10 shows stalls in SELECT occasionally and, when it does so, it looks like all other clients are blocked or something. When the Maildir mailstore is mounted over NFS from our NetApp filer to the Solaris 10 box Dovecot and imaptest10 are running on the problem shows. Switch to using local disk for the mailstore and run imaptest10 with the same number of clients and there are no stalls. But increase the number of simulated clients (from 50 to 100) and they come back, but not too badly at that setting. So it looks like something to do with when the system gets really loaded... I think the things I'd like to know are: 1. Are other people on the List running Dovecot with Maildir mailstore NFS-mounted from NetApp filers and having it work OK? (If you are using Solaris 10, what mount options are you using?) 2. How much real-life user load does running imaptest10 with 50 simulated clients equate to? I assume each simulated user is hammering away at its IMAP connection, so should equate to several (how many?) normal users in real-life operation? 3. I'm concerned by the N/M number at the end of the imaptest10 output lines plummeting whenever one process goes into this stalled state: it almost suggests as if the only thing the other processes can do is logout? Are other sessions really being blocked, or is it just imaptest10 behaving like this? As far as I can tell I *think* it's only imaptest10 getting blocked: when it is happening for an extended period I can quickly manually Telnet in to port 143, login as one of the test usernames and SELECT INBOX just fine. So it's probably NOT all of the Dovecot processes getting blocked, but imaptest10 that drives them. Does that sound plausible? Help! (Concerned, and hoping we're not going down the wrong road... can anyone reassure me about the Solaris 10/NFS/NetApp filer setup?) With thanks, Mike B-) -- The Computing Service, University of York, Heslington, York Yo10 5DD, UK Tel:+44-1904-433811 FAX:+44-1904-433740 * Unsolicited commercial e-mail is NOT welcome at this e-mail address. * EXAMPLE OUTPUT FROM IMAPTEST10 == 24 13 20 28 25 36 10 14 23 24 48 50/ 50 32 15 15 28 28 46 18 16 35 32 64 50/ 50 21 13 14 27 30 3298 21 22 42 50/ 50 - 45. stalled for 16 secs in SELECT 05267 27 10 18 26 28 58 21/ 21 === 46 22 25 40 38 388 12 21 17 34 50/ 50 28 11 13 24 22 3296 24 28 56 50/ 50 20 10 15 24 27 38 13 10 24 20 40 50/ 50 299 11 25 21 33 13 14 28 29 58 50/ 50 28 17 12 32 37 43 17 15 27 28 56 50/ 50 and 34 15 13 28 27 47 16 20 34 34 68 50/ 50 18 13 16 27 25 239 13 17 18 36 50/ 50 2198 22 25 36 17 13 23 22 42 50/ 50 - 30. stalled for 16 secs in SELECT - 37. stalled for 16 secs in SELECT Logi List Stat Sele Fetc Fet2 Stor Dele Expu Appe Logo 100% 50% 50% 100% 100% 100% 50% 100% 100% 100% 100% 30% 5% 05277 28 11 12 28 29 60 20/ 20 === 41 16 18 31 26 2464 12 11 22 50/ 50 299 15 28 29 42 10 13 27 29 58 50/ 50
[Dovecot] Using Dovecot LDA with Sendmail
Hi all, After looking at the LDA/Sendmail page in the dovecot wiki, I wanted to contribute another method to easily configure Sendmail to use deliver. Instead of adding a new mailer definition, as already suggested, one can simply use the following line in their sendmail.mc file instead: FEATURE(`local_procmail', `/usr/libexec/dovecot/deliver', `deliver -d $u', `SPhnu9')dnl And further on, still use: MAILER(procmail)dnl The location of deliver will of course vary for each OS and distro, etc, but this redefines the procmail mailer in the resulting sendmail.cf to use deliver instead, with the correct flags. For most setups, I believe this is the simplest configuration path. Scott -- Scott Peron, Webmaster, Infolytica Corp. [EMAIL PROTECTED] Tel: (514) 849-8752 x269 Fax: (514) 849-4239 http://www.infolytica.com Place du Parc, 300 Leo-Pariseau, Suite , Montreal, QC, Canada, H2X 4B3
[Dovecot] prefetch + static + deliver
Hi all... The prefetch entry in the wiki says: If you're using Dovecot's local delivery agent, you'll still need a valid userdb which it can use to locate the users. You can do this by adding a normal sql/ldap userdb after userdb prefetch. (http://wiki.dovecot.org/UserDatabase/Prefetch) My question is: Does it need to be a SQL/LDAP userdb? How about static or passwd? Thanks in advance :)
Re: [Dovecot] 1.0.rc29 released
On Fri, Mar 30, 2007 at 04:05:55PM -0700, Kenneth Porter wrote: A few new small features and lots of index/mbox fixes. I've been heavily stress testing this release, so I think it should be about perfect. :) *Features*?! In an rc?! No wonder there's no convergence. [snip] So please, no more features in these rc's! Just lock it down and ship it and let people get some experience with it, so I'll know exactly what to expect when *I* install it. I have to agree with you on this. I'm relatively new with Dovecot and have been evaluating it for deployment in a production environment. I must say that Dovecot has the most unusual development method of a large-scale project I've seen. There have been so many show-stopping bugs in the past 10 releases that I wouldn't even consider this a candidate for a Beta release at this point, let alone a production release. I'm very appreciative of all the hard-work the author(s) have put into this, but I think at some point they need to take a hard-look at the way they develop and release distributions. It seems extremely sloppy and I know it's confusing to others besides myself. -- Dean Brooks [EMAIL PROTECTED]
Re: [Dovecot] 1.0.rc29 released
On March 30, 2007 4:05:55 PM -0700 Kenneth Porter [EMAIL PROTECTED] wrote: --On Friday, March 30, 2007 3:24 PM -0700 Frank Cusack [EMAIL PROTECTED] wrote: This is why I'm still using 0.99. The RC's still look like betas and I have no idea which one (if any) is less a regression than any other. They ARE betas. That's no reason to stay with 0.99. It's effectively beta as well. In principle, a release candidate should be a gamma. It should be effectively ready for release, and distributed to check for awful show-stoppers. Is 1.0rc29 stable enough to replace 0.99 from Fedora? Will I suddenly have a bunch of angry users seeing things break? Will 1.0 be stable enough to replace 0.99? You are going to have to do the exact same testing from 0.99-1.0 as you would from 0.99-1.0rc29. Caveat emptor with open source software; the responsibility is upon YOU to do your own testing. It sounds to me like the reason you are running 0.99 is not because of any rc naming and/or lack of stability, it is because Fedora ships with 0.99. So you should just wait until Fedora updates it and not worry about the fact that the rc releases are misnamed. So please, no more features in these rc's! Just lock it down and ship it and let people get some experience with it, so I'll know exactly what to expect when *I* install it. People ARE getting experience with the rc's. That's why there's so many of them: feedback. Why do you care anyway? (Not attacking you.) If 0.99 works for you, great! -frank
Re: [Dovecot] 1.0.rc29 released
On March 30, 2007 7:31:15 PM -0400 Dean Brooks [EMAIL PROTECTED] wrote: On Fri, Mar 30, 2007 at 04:05:55PM -0700, Kenneth Porter wrote: A few new small features and lots of index/mbox fixes. I've been heavily stress testing this release, so I think it should be about perfect. :) *Features*?! In an rc?! No wonder there's no convergence. [snip] So please, no more features in these rc's! Just lock it down and ship it and let people get some experience with it, so I'll know exactly what to expect when *I* install it. I have to agree with you on this. I'm relatively new with Dovecot and have been evaluating it for deployment in a production environment. I must say that Dovecot has the most unusual development method of a large-scale project I've seen. ??? 1. write code 2. release for testing 3. incorporate feedback Doesn't seem that unusual. It's just that rc is misnamed. There have been so many show-stopping bugs in the past 10 releases that I wouldn't even consider this a candidate for a Beta release at this point, let alone a production release. Sure, Timo probably did screw up by wanting 1.0 to be so great and all, and not just freezing things where they stood, but who cares? Just stick with 0.99 or 1.0beta8. It's great that he releases so many rc versions and so many people test them and shake out bugs. I'm very appreciative of all the hard-work the author(s) have put into this, but I think at some point they need to take a hard-look at the way they develop and release distributions. It seems extremely sloppy and I know it's confusing to others besides myself. It's very easy. In the dovecot world, rc means development version. Or are you too stupid and ignorant to learn how the versioning works for dovecot. (Sorry, that's directed to another dovecot thread; I'm not calling you stupid and ignorant.) Seriously though, if you so desperately want dovecot frozen somewhere, use 1.0beta8 or 1.0rc1 and pretend it was released as 1.0. -frank
Re: [Dovecot] 1.0.rc29 released
--On Friday, March 30, 2007 4:41 PM -0700 Frank Cusack [EMAIL PROTECTED] wrote: You are going to have to do the exact same testing from 0.99-1.0 as you would from 0.99-1.0rc29. Caveat emptor with open source software; the responsibility is upon YOU to do your own testing. Actually, no. A few people keep up with the latest rc's. A lot of people will install 1.0. I try never to be the first lemming over the cliff. I wait to hear the sounds of the others splash, to see where the rocks are. With a proper 1.0 release, I can have high confidence in knowing what bugs to expect before I install it. I don't have that confidence with an rc tried by only a handful and then rapidly replaced with its successor. Windows Server 2003 Service Pack 2 came out a week ago. I'm leaving it in the unapproved queue for a couple weeks, maybe a month, to hear what happens to the early adopters. I'm quite sure it will have its share of problems, and I can live with that, as long as I have some idea of what they are. Note that I'm a small shop. I don't have the luxury of a parallel testing environment like some corporation with hundreds or thousands of employees and the IT budget to match. I rely on the experiences of other admins with the deep pockets to do that sort of thing. It sounds to me like the reason you are running 0.99 is not because of any rc naming and/or lack of stability, it is because Fedora ships with 0.99. So you should just wait until Fedora updates it and not worry about the fact that the rc releases are misnamed. It's because lots of people are running this version, and it's a known entity. Why do you care anyway? (Not attacking you.) If 0.99 works for you, great! Because there are features in 1.0 I'd like to start using. But I don't want to have to wait for tomorrow's feature's testing before I can use yesterday's features. Lock down 1.0 and ship it. Most people realize that a dot-oh release is going to have bugs. Let the wider community start getting experience with it. Don't do any more coding on this branch except bug fixes.
Re: [Dovecot] 1.0.rc29 released
--On Friday, March 30, 2007 4:52 PM -0700 Frank Cusack [EMAIL PROTECTED] wrote: It's very easy. In the dovecot world, rc means development version. Or are you too stupid and ignorant to learn how the versioning works for dovecot. (Sorry, that's directed to another dovecot thread; I'm not calling you stupid and ignorant.) That's fine for isolated users supporting only themselves. But it won't win any mind share in the boardroom. If you want widespread deployment to get proper testing (and hence a larger user base) you need a version number that gives business people the confidence to install it. Otherwise you'll be limited to avant garde hobbyists who have nothing to risk. Once 1.0 locks down, you should see a huge expansion of users. Bug fixes (not features!) in 1.0.1 will see further expansion. Any new features (like the recent addition of the wiki to the tarball) should be in the scary and experimental 1.1, not 1.0.
Re: [Dovecot] 1.0.rc29 released
On March 30, 2007 5:04:58 PM -0700 Kenneth Porter [EMAIL PROTECTED] wrote: --On Friday, March 30, 2007 4:52 PM -0700 Frank Cusack [EMAIL PROTECTED] wrote: It's very easy. In the dovecot world, rc means development version. Or are you too stupid and ignorant to learn how the versioning works for dovecot. (Sorry, that's directed to another dovecot thread; I'm not calling you stupid and ignorant.) That's fine for isolated users supporting only themselves. But it won't win any mind share in the boardroom. If you want widespread deployment to get proper testing (and hence a larger user base) you need a version number that gives business people the confidence to install it. Otherwise you'll be limited to avant garde hobbyists who have nothing to risk. Once 1.0 locks down, you should see a huge expansion of users. Please don't mistake my email for any involvement with dovecot development. AFAIK, Timo is the one and only developer. That's sure to win over your board and boards worldwide. 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. -frank
Re: [Dovecot] 1.0.rc29 released
--On Friday, March 30, 2007 5:22 PM -0700 Frank Cusack [EMAIL PROTECTED] wrote: Please don't mistake my email for any involvement with dovecot development. AFAIK, Timo is the one and only developer. That's sure to win over your board and boards worldwide. If you mean a single developer might scare away users, I don't think that's the case. Plenty of popular software is developed by a single person or a very small developer group. And with open source, the loss of the developer doesn't mean that the application gets orphaned. 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. My concern is not quality but predictability. There's a reason 0.99 and 1.0 software is poor quality: Few people are willing to risk using it, so it doesn't receive widespread testing. More will use 1.0 than 0.99, and more yet 1.0.1. The rc on the end of the current dovecot is little better than 0.99 to those who insist on a 1.0. (It's psychologically better, but only just marginally better.) I also don't seek more users out of some kind of popularity vote. I'm looking for the many eyes effect. With more people using it, more issues get identified. It's like sending an army of bots over a minefield, so I don't have to be the one losing a leg.
Re: [Dovecot] 1.0.rc29 released
Quoting Dean Brooks [EMAIL PROTECTED]: I have to agree with you on this. I'm relatively new with Dovecot and have been evaluating it for deployment in a production environment. I must say that Dovecot has the most unusual development method of a large-scale project I've seen. I've seen about the same from other pre-1.0 software projects. The usual problem (and I have no idea if this describes Timo accurately or not, though it appears as such to me), is that the people (usually one person) heading the project are not experienced with large-scale software releases, and they make some simple mistakes. Often they look back years later and reflect on how they were in over their heads when they started, etc. But, let me also say, that in the above paragraph I am thinking of 3 projects, all of which I use in production, all of which I love, all of which have worked out their problems after their first major release. I would say, in general, these types of things are just growing pains and shouldn't be too surprising to most people. What would be surprising (and bad) was if they continued through the following releases. Timo has already admitted his errors on the mailing list recently, and has already sought advice on how to fix them in the future, so I would think the future is bright for dovecot. And eventually, we'll all forget the past... There have been so many show-stopping bugs in the past 10 releases that I wouldn't even consider this a candidate for a Beta release at this point, let alone a production release. Actually, that is more due to the large number of RC cuts Timo makes, rather than the number of bugs in the code, IMHO. I've found several of the releases to be very stable for me, as have others. Of course, I'm very selective as to which I install and test; I don't test each RC that comes out (in particular, since I run mbox, I don't run ones that have only maildir fixes, etc). I'm very appreciative of all the hard-work the author(s) have put into this, but I think at some point they need to take a hard-look at the way they develop and release distributions. It seems extremely sloppy and I know it's confusing to others besides myself. I believe Timo already has done so, based on his comments on the list, and his requests for help on things like versioning systems, test suites, etc. If you've been reading the list over the last couple months, I think you would recognize this. But then, I don't speak for Timo. -- Dean Brooks [EMAIL PROTECTED] -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns!
Re: [Dovecot] 1.0.rc29 released
Quoting Kenneth Porter [EMAIL PROTECTED]: That's fine for isolated users supporting only themselves. But it won't win any mind share in the boardroom. If you want widespread deployment to get proper testing (and hence a larger user base) you need a version number that gives business people the confidence to install it. Otherwise you'll be limited to avant garde hobbyists who have nothing to risk. While, is there really no one between the boardroom and the avant garde hobbyists? I didn't realize there was such a void between those levels... Once 1.0 locks down, you should see a huge expansion of users. Bug Yes, well, of course. We all know that already. fixes (not features!) in 1.0.1 will see further expansion. Any new features (like the recent addition of the wiki to the tarball) should be in the scary and experimental 1.1, not 1.0. That is simply documentation, not really a feature. And it is actually fairly normal to add and refine documentation during a RC release. I agree in general with the no more features requests, but docs are really a whole different thing. Most shops are working on the docs right up to the last minute for every release. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns!
Re: [Dovecot] 1.0.rc29 released
On 2007 Mar 30 (Fri) at 20:56:43 -0700 (-0700), Kenneth Porter wrote: :--On Friday, March 30, 2007 8:26 PM -0700 Peter Hessler :[EMAIL PROTECTED] wrote: : :This sort of decision is exactly why I'm the mail admin and they are :not. They know things at the boardroom level, and they are :(presumably) good at it. I don't look at things from the boardroom :level. However, I understand the MTA-related arena better than they do. :If they understood the details, why would they spend the money on my :salary. : :So which rc are you running in production? What made you decide that rc and :not some other was good enough without being too risky. What's your :confidence in that particular rc? : :I'm looking at 29 rc's and I have no idea how to pick. What's your method? I personally am running rc22, and plan on upgrading to rc29 this weekend. I chose it because it was the most recent dovecot when I last upgraded. I've previously been upgrading to each rc within a day or two of release. My upgrade testing goes like this: Install it on a non-mailserver box, setup a bogus mail directory (usually a cp of my regular Maildir/), poke at it with ipv4/ipv6 over both imap and pop3. Usually 20 minutes is enough to figure its quality. If it passes, then I kill the master dovecot process, uninstall old, install new, start up, run tests again. -- Don't take life so serious, son, it ain't nohow permanent. -- Walt Kelly
Re: [Dovecot] 1.0.rc29 released
On Fri, 2007-03-30 at 16:05 -0700, Kenneth Porter wrote: --On Friday, March 30, 2007 3:24 PM -0700 Frank Cusack [EMAIL PROTECTED] wrote: This is why I'm still using 0.99. The RC's still look like betas and I have no idea which one (if any) is less a regression than any other. They ARE betas. That's no reason to stay with 0.99. It's effectively beta as well. In principle, a release candidate should be a gamma. It should be effectively ready for release, and distributed to check for awful show-stoppers. Is 1.0rc29 stable enough to replace 0.99 from Fedora? Will I suddenly have a bunch of angry users seeing things break? It is stable enough. I've been using it in production, and each RC, with no issues. Really damn good software. 1.0.rc1 was released in June. Here's a quote from the release message for rc11 (November 4): Hopefully the last RC release? As far as I know there are no major problems left now. If nothing big shows up, v1.0 should be out in a couple of weeks. In rc27: A few new small features and lots of index/mbox fixes. I've been heavily stress testing this release, so I think it should be about perfect. :) *Features*?! In an rc?! No wonder there's no convergence. Oddly, the new features don't seem to act up. Just little issues keep coming up.
