Re: Cyrus 2.3.13 RC2
> > We were only looking at SQL to replace BDB (deliver.db, > tls_sessions.db), because we still think that skiplist is superior > from mailboxes.db and seen.db. If you do some heavy testing with > the BDB code we'd be interested in your results. OK, that's interesting. I'll get 2.3.13 onto batten.eu.org and try some testing. The whole instance is under ZFS so I can roll back if necessary. ian Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus 2.3.13 RC2
Ian G Batten wrote: > > On 08 Oct 08, at 1119, Bron Gondwana wrote: > >> >> On Wed, 8 Oct 2008 09:24:49 +0100, "Ian G Batten" >> <[EMAIL PROTECTED]> said: >>> What's the testing status of the SQL backend for cyrusdb? I'll >>> switch batten.eu.org over to it, but that only has a dozen or so >>> users; ftel.co.uk's 1000+ users might be a little tenser. I'm keen to >>> switch as the ability to replicate cyrusdb as well as replicating the >>> entire mailsystem is attractive. >> >> You are aware that cyrus replication replicates DB records for all the >> important things as well, aren't you? > > Yes, of course. It's just that having, many years ago, experienced the > loss of a cyrusdb, being able to keep up-to-date copies of it which I > can use without the nuclear option of failing over to my off-site > replica is a good thing. So I will shortly have my whole Cyrus instance > (~60K mailboxes, ~1000 users, ~4TB of mail) replicated via GigE to a > remote site. But if my local instance went south just because Cyrus DB > had gone, being able to simply switch cyrusdb to a MySQL/PostgresQL > replica while keeping mail service on the master is preferable to doing > a full off-site failover. We were only looking at SQL to replace BDB (deliver.db, tls_sessions.db), because we still think that skiplist is superior from mailboxes.db and seen.db. If you do some heavy testing with the BDB code we'd be interested in your results. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus 2.3.13 RC2
On 08 Oct 08, at 1119, Bron Gondwana wrote: > > On Wed, 8 Oct 2008 09:24:49 +0100, "Ian G Batten" <[EMAIL PROTECTED] > > said: >> What's the testing status of the SQL backend for cyrusdb? I'll >> switch batten.eu.org over to it, but that only has a dozen or so >> users; ftel.co.uk's 1000+ users might be a little tenser. I'm keen >> to >> switch as the ability to replicate cyrusdb as well as replicating the >> entire mailsystem is attractive. > > You are aware that cyrus replication replicates DB records for all the > important things as well, aren't you? Yes, of course. It's just that having, many years ago, experienced the loss of a cyrusdb, being able to keep up-to-date copies of it which I can use without the nuclear option of failing over to my off- site replica is a good thing. So I will shortly have my whole Cyrus instance (~60K mailboxes, ~1000 users, ~4TB of mail) replicated via GigE to a remote site. But if my local instance went south just because Cyrus DB had gone, being able to simply switch cyrusdb to a MySQL/PostgresQL replica while keeping mail service on the master is preferable to doing a full off-site failover. ian Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus 2.3.13 RC2
On Wed, 8 Oct 2008 09:24:49 +0100, "Ian G Batten" <[EMAIL PROTECTED]> said: > What's the testing status of the SQL backend for cyrusdb? I'll > switch batten.eu.org over to it, but that only has a dozen or so > users; ftel.co.uk's 1000+ users might be a little tenser. I'm keen to > switch as the ability to replicate cyrusdb as well as replicating the > entire mailsystem is attractive. You are aware that cyrus replication replicates DB records for all the important things as well, aren't you? Bron. -- Bron Gondwana [EMAIL PROTECTED] Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus 2.3.13 RC2
Ian G Batten wrote: > > On 08 Oct 08, at 0536, Bron Gondwana wrote: > >> On Mon, Oct 06, 2008 at 11:33:18AM -0400, Ken Murchison wrote: >>> I just put together a second release candidate for Cyrus 2.3.13. I'd >>> appreciate any independent testing before I release this to the masses. >> >> Sorry about the delay in testing - we've had a few exciting issues >> here that had to be fixed first. >> >>> If there are any outstanding issues that you believe still need to be >>> addressed in 2.3.13, please let me know. >> >> No, it's looking good. I just removed the patches that have gone into >> CVS from my build tree and it built fine. Running on our test server >> now with no problems. All the patches that have gone upstream have >> been running happily on our production machines for a bit too. >> >> I think now's a good time to release a 2.3.13. > > What's the testing status of the SQL backend for cyrusdb? I'll switch > batten.eu.org over to it, but that only has a dozen or so users; > ftel.co.uk's 1000+ users might be a little tenser. I'm keen to switch > as the ability to replicate cyrusdb as well as replicating the entire > mailsystem is attractive. Minimal. My boss asked if we could try to get away from BDB and move to something like SQlite. I dusted off an old SQL patch that I wrote while working for my old employer and ported it to the 2.3 code. We set it up on a test machine and threw a couple of low volume users on it and the campus didn't burn down. We haven't done any kind of load testing or performance testing yet. That's why its listed as experimental -- use at your own risk. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus 2.3.13 RC2
On 08 Oct 08, at 0536, Bron Gondwana wrote: > On Mon, Oct 06, 2008 at 11:33:18AM -0400, Ken Murchison wrote: >> I just put together a second release candidate for Cyrus 2.3.13. I'd >> appreciate any independent testing before I release this to the >> masses. > > Sorry about the delay in testing - we've had a few exciting issues > here that had to be fixed first. > >> If there are any outstanding issues that you believe still need to be >> addressed in 2.3.13, please let me know. > > No, it's looking good. I just removed the patches that have gone into > CVS from my build tree and it built fine. Running on our test server > now with no problems. All the patches that have gone upstream have > been running happily on our production machines for a bit too. > > I think now's a good time to release a 2.3.13. What's the testing status of the SQL backend for cyrusdb? I'll switch batten.eu.org over to it, but that only has a dozen or so users; ftel.co.uk's 1000+ users might be a little tenser. I'm keen to switch as the ability to replicate cyrusdb as well as replicating the entire mailsystem is attractive. ian Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus 2.3.13 RC2
> Kenneth Marshall wrote: > >> There have been 5 major releases of PostgreSQL since 7.2 was released >> and 7.2 is EOL in the next few months. I think it is completely >> reasonable >> to not support version 7.1/7.2 in a new system considering that 7.1 is >> EOL and 7.2 will be shortly. >> >> Cheers, >> Ken > > Oh seriously, don't even waste time worrying about it. 7.2 died a long > time ago, 7.3 was EOL the beginning of this year [1], and 7.4 is about > to go the same way real soon now. Normally adding 7.3 support is fairly > easy if required, whereas going back to 7.2 is often a complete pain, > plus you have to live with several unfixable data loss bugs... The point is that I'm maintaining cyrus-imapd rpms for RedHat/Fedora and always try to provide maximum functionality with them. PostgreSQL 7.1 is still supported there, not by the PostgreSQL team but by RedHat, so that's not a security problem or whatever. However, I understand now that it doesn't make sense to support those old version with cyrus-imapd because of the changes on the PostgreSQL side. Simon Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus 2.3.13 RC2
On Mon, Oct 06, 2008 at 11:33:18AM -0400, Ken Murchison wrote: > I just put together a second release candidate for Cyrus 2.3.13. I'd > appreciate any independent testing before I release this to the masses. Sorry about the delay in testing - we've had a few exciting issues here that had to be fixed first. > If there are any outstanding issues that you believe still need to be > addressed in 2.3.13, please let me know. No, it's looking good. I just removed the patches that have gone into CVS from my build tree and it built fine. Running on our test server now with no problems. All the patches that have gone upstream have been running happily on our production machines for a bit too. I think now's a good time to release a 2.3.13. Bron. Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus 2.3.13 RC2
Kenneth Marshall wrote: > There have been 5 major releases of PostgreSQL since 7.2 was released > and 7.2 is EOL in the next few months. I think it is completely reasonable > to not support version 7.1/7.2 in a new system considering that 7.1 is > EOL and 7.2 will be shortly. > > Cheers, > Ken Oh seriously, don't even waste time worrying about it. 7.2 died a long time ago, 7.3 was EOL the beginning of this year [1], and 7.4 is about to go the same way real soon now. Normally adding 7.3 support is fairly easy if required, whereas going back to 7.2 is often a complete pain, plus you have to live with several unfixable data loss bugs... HTH, Mark. [1] http://www.postgresql.org/about/news.905 -- Mark Cave-Ayland Sirius Corporation - The Open Source Experts http://www.siriusit.co.uk T: +44 870 608 0063 Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus 2.3.13 RC2
On Tue, Oct 07, 2008 at 12:18:01PM +0200, Simon Matter wrote: > > I just put together a second release candidate for Cyrus 2.3.13. I'd > > appreciate any independent testing before I release this to the masses. > > > > http://www.contrib.andrew.cmu.edu/~murch/cyrus-imapd-2.3.13rc2.tar.gz > > http://www.contrib.andrew.cmu.edu/~murch/cyrus-imapd-2.3.13rc2.tar.gz.sig > > > > > > Noteworthy changes: > > > > * Added an experimental "sql" backend for cyrusdb. Currently MySQL, > >PostgreSQL, and SQLite are supported. > > * Added support for IMAP [CAPABILITY] response code to client-side > >of Murder proxies. > > * Added support for ManageSieve auto-capability response after > >STARTTLS and after AUTH with a SASL security layer. > > * Made MAXWORD and MAXQUOTED sizes configurable via imapd.conf > > * Rewrote cyrusdb_quotalegacy.c to use readir() > >rather than glob.c. This avoids a potential crash due to > >conflicts between glibc and Heimdal implementations of glob(). > > * Added support for fulldirhash to 'ctl_mboxlist -v' > > * Several skiplist transaction bugfixes. > > * cyr_expire no longer has a default of 0 (zero) for -X and -D. > >These options must be used explicitly in order to have the desired > >effect. > > * Added sieve_utf8fileinto option. > > > > Check doc/changes.html for a complete list of changes. > > > > If there are any outstanding issues that you believe still need to be > > addressed in 2.3.13, please let me know. > > I did some test builds on different systems and found that postgresql > support doesn't work with postgresql 7.1.x and 7.2.x as shown in the error > below. I understand that these are old versions but if there is an easy > workaround for the problem it would still be nice. > > One question to the new sieve_utf8fileinto options, is the default that it > behaves like old cyrus versions? > > Thanks, > Simon > There have been 5 major releases of PostgreSQL since 7.2 was released and 7.2 is EOL in the next few months. I think it is completely reasonable to not support version 7.1/7.2 in a new system considering that 7.1 is EOL and 7.2 will be shortly. Cheers, Ken Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus 2.3.13 RC2
Kenneth Marshall wrote: > On Tue, Oct 07, 2008 at 12:18:01PM +0200, Simon Matter wrote: >>> I just put together a second release candidate for Cyrus 2.3.13. I'd >>> appreciate any independent testing before I release this to the masses. >>> >>> http://www.contrib.andrew.cmu.edu/~murch/cyrus-imapd-2.3.13rc2.tar.gz >>> http://www.contrib.andrew.cmu.edu/~murch/cyrus-imapd-2.3.13rc2.tar.gz.sig >>> >>> >>> Noteworthy changes: >>> >>> * Added an experimental "sql" backend for cyrusdb. Currently MySQL, >>>PostgreSQL, and SQLite are supported. >>> * Added support for IMAP [CAPABILITY] response code to client-side >>>of Murder proxies. >>> * Added support for ManageSieve auto-capability response after >>>STARTTLS and after AUTH with a SASL security layer. >>> * Made MAXWORD and MAXQUOTED sizes configurable via imapd.conf >>> * Rewrote cyrusdb_quotalegacy.c to use readir() >>>rather than glob.c. This avoids a potential crash due to >>>conflicts between glibc and Heimdal implementations of glob(). >>> * Added support for fulldirhash to 'ctl_mboxlist -v' >>> * Several skiplist transaction bugfixes. >>> * cyr_expire no longer has a default of 0 (zero) for -X and -D. >>>These options must be used explicitly in order to have the desired >>>effect. >>> * Added sieve_utf8fileinto option. >>> >>> Check doc/changes.html for a complete list of changes. >>> >>> If there are any outstanding issues that you believe still need to be >>> addressed in 2.3.13, please let me know. >> I did some test builds on different systems and found that postgresql >> support doesn't work with postgresql 7.1.x and 7.2.x as shown in the error >> below. I understand that these are old versions but if there is an easy >> workaround for the problem it would still be nice. >> >> One question to the new sieve_utf8fileinto options, is the default that it >> behaves like old cyrus versions? >> >> Thanks, >> Simon >> > > There have been 5 major releases of PostgreSQL since 7.2 was released > and 7.2 is EOL in the next few months. I think it is completely reasonable > to not support version 7.1/7.2 in a new system considering that 7.1 is > EOL and 7.2 will be shortly. I wasn't aware of the release history, thanks for that. Given this, I agree that support for 7.1/7.2 isn't necessary, especially since the cyrusdb_sql.c code is experimental and not built by default. If somebody really wants/needs 7.1/7.2 for Cyrus, they can send a patch. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus 2.3.13 RC2
> Simon Matter wrote: >>> I just put together a second release candidate for Cyrus 2.3.13. I'd >>> appreciate any independent testing before I release this to the masses. >>> >>> http://www.contrib.andrew.cmu.edu/~murch/cyrus-imapd-2.3.13rc2.tar.gz >>> http://www.contrib.andrew.cmu.edu/~murch/cyrus-imapd-2.3.13rc2.tar.gz.sig >>> >>> >>> Noteworthy changes: >>> >>> * Added an experimental "sql" backend for cyrusdb. Currently MySQL, >>>PostgreSQL, and SQLite are supported. >>> * Added support for IMAP [CAPABILITY] response code to client-side >>>of Murder proxies. >>> * Added support for ManageSieve auto-capability response after >>>STARTTLS and after AUTH with a SASL security layer. >>> * Made MAXWORD and MAXQUOTED sizes configurable via imapd.conf >>> * Rewrote cyrusdb_quotalegacy.c to use readir() >>>rather than glob.c. This avoids a potential crash due to >>>conflicts between glibc and Heimdal implementations of glob(). >>> * Added support for fulldirhash to 'ctl_mboxlist -v' >>> * Several skiplist transaction bugfixes. >>> * cyr_expire no longer has a default of 0 (zero) for -X and -D. >>>These options must be used explicitly in order to have the desired >>>effect. >>> * Added sieve_utf8fileinto option. >>> >>> Check doc/changes.html for a complete list of changes. >>> >>> If there are any outstanding issues that you believe still need to be >>> addressed in 2.3.13, please let me know. >> >> I did some test builds on different systems and found that postgresql >> support doesn't work with postgresql 7.1.x and 7.2.x as shown in the >> error >> below. I understand that these are old versions but if there is an easy >> workaround for the problem it would still be nice. > > Do you happen to have a workaround? No unfortunately not. Maybe it's not worth to care for those old versions. Simon Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus 2.3.13 RC2
Simon Matter wrote: >> I just put together a second release candidate for Cyrus 2.3.13. I'd >> appreciate any independent testing before I release this to the masses. >> >> http://www.contrib.andrew.cmu.edu/~murch/cyrus-imapd-2.3.13rc2.tar.gz >> http://www.contrib.andrew.cmu.edu/~murch/cyrus-imapd-2.3.13rc2.tar.gz.sig >> >> >> Noteworthy changes: >> >> * Added an experimental "sql" backend for cyrusdb. Currently MySQL, >>PostgreSQL, and SQLite are supported. >> * Added support for IMAP [CAPABILITY] response code to client-side >>of Murder proxies. >> * Added support for ManageSieve auto-capability response after >>STARTTLS and after AUTH with a SASL security layer. >> * Made MAXWORD and MAXQUOTED sizes configurable via imapd.conf >> * Rewrote cyrusdb_quotalegacy.c to use readir() >>rather than glob.c. This avoids a potential crash due to >>conflicts between glibc and Heimdal implementations of glob(). >> * Added support for fulldirhash to 'ctl_mboxlist -v' >> * Several skiplist transaction bugfixes. >> * cyr_expire no longer has a default of 0 (zero) for -X and -D. >>These options must be used explicitly in order to have the desired >>effect. >> * Added sieve_utf8fileinto option. >> >> Check doc/changes.html for a complete list of changes. >> >> If there are any outstanding issues that you believe still need to be >> addressed in 2.3.13, please let me know. > > I did some test builds on different systems and found that postgresql > support doesn't work with postgresql 7.1.x and 7.2.x as shown in the error > below. I understand that these are old versions but if there is an easy > workaround for the problem it would still be nice. Do you happen to have a workaround? > One question to the new sieve_utf8fileinto options, is the default that it > behaves like old cyrus versions? Yes. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus 2.3.13 RC2
> I just put together a second release candidate for Cyrus 2.3.13. I'd > appreciate any independent testing before I release this to the masses. > > http://www.contrib.andrew.cmu.edu/~murch/cyrus-imapd-2.3.13rc2.tar.gz > http://www.contrib.andrew.cmu.edu/~murch/cyrus-imapd-2.3.13rc2.tar.gz.sig > > > Noteworthy changes: > > * Added an experimental "sql" backend for cyrusdb. Currently MySQL, >PostgreSQL, and SQLite are supported. > * Added support for IMAP [CAPABILITY] response code to client-side >of Murder proxies. > * Added support for ManageSieve auto-capability response after >STARTTLS and after AUTH with a SASL security layer. > * Made MAXWORD and MAXQUOTED sizes configurable via imapd.conf > * Rewrote cyrusdb_quotalegacy.c to use readir() >rather than glob.c. This avoids a potential crash due to >conflicts between glibc and Heimdal implementations of glob(). > * Added support for fulldirhash to 'ctl_mboxlist -v' > * Several skiplist transaction bugfixes. > * cyr_expire no longer has a default of 0 (zero) for -X and -D. >These options must be used explicitly in order to have the desired >effect. > * Added sieve_utf8fileinto option. > > Check doc/changes.html for a complete list of changes. > > If there are any outstanding issues that you believe still need to be > addressed in 2.3.13, please let me know. I did some test builds on different systems and found that postgresql support doesn't work with postgresql 7.1.x and 7.2.x as shown in the error below. I understand that these are old versions but if there is an easy workaround for the problem it would still be nice. One question to the new sieve_utf8fileinto options, is the default that it behaves like old cyrus versions? Thanks, Simon i386-redhat-linux-gcc -L/usr/lib -lpcreposix -lpcre -L/usr/lib/mysql -L/usr/include/mysql -Wl,-rpath,/usr/include/mysql -L/usr/include/pgsql/lib -Wl,-rpath,/usr/include/pgsql/lib -o imapd \ ../master/service.o pushstats.o imapd.o proxy.o imap_proxy.o index.o version.o mutex_fake.o \ libimap.a ../lib/libcyrus.a ../lib/libcyrus_min.a -lsasl2 -lssl -lcrypto -lresolv -lfl -lresolv -ldb-3.2 -lmysqlclient -lpq -lpcre -lpcreposix -lcom_err -lwrap -lnsl /usr/bin/ld: warning: libcom_err.so.3, needed by /usr/lib/libpq.so, may conflict with libcom_err.so.2 ../lib/libcyrus.a(cyrusdb_sql.o): In function `_pgsql_escape': cyrusdb_sql.o(.text+0x4af): undefined reference to `PQescapeBytea' ../lib/libcyrus.a(cyrusdb_sql.o): In function `_pgsql_exec': cyrusdb_sql.o(.text+0x5ae): undefined reference to `PQunescapeBytea' cyrusdb_sql.o(.text+0x5d1): undefined reference to `PQunescapeBytea' collect2: ld returned 1 exit status make[1]: *** [imapd] Error 1 make[1]: Leaving directory `/usr/src/redhat/BUILD/cyrus-imapd-2.3.13rc2/imap' make: *** [all] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.769 (%build) Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Cyrus 2.3.13 RC2
I just put together a second release candidate for Cyrus 2.3.13. I'd appreciate any independent testing before I release this to the masses. http://www.contrib.andrew.cmu.edu/~murch/cyrus-imapd-2.3.13rc2.tar.gz http://www.contrib.andrew.cmu.edu/~murch/cyrus-imapd-2.3.13rc2.tar.gz.sig Noteworthy changes: * Added an experimental "sql" backend for cyrusdb. Currently MySQL, PostgreSQL, and SQLite are supported. * Added support for IMAP [CAPABILITY] response code to client-side of Murder proxies. * Added support for ManageSieve auto-capability response after STARTTLS and after AUTH with a SASL security layer. * Made MAXWORD and MAXQUOTED sizes configurable via imapd.conf * Rewrote cyrusdb_quotalegacy.c to use readir() rather than glob.c. This avoids a potential crash due to conflicts between glibc and Heimdal implementations of glob(). * Added support for fulldirhash to 'ctl_mboxlist -v' * Several skiplist transaction bugfixes. * cyr_expire no longer has a default of 0 (zero) for -X and -D. These options must be used explicitly in order to have the desired effect. * Added sieve_utf8fileinto option. Check doc/changes.html for a complete list of changes. If there are any outstanding issues that you believe still need to be addressed in 2.3.13, please let me know. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html