From murch at andrew.cmu.edu  Wed Apr  1 07:46:16 2009
From: murch at andrew.cmu.edu (Ken Murchison)
Date: Wed, 01 Apr 2009 07:46:16 -0400
Subject: "Cyrus IMAP4" to "Cyrus IMAP" accidental change of greeting?
In-Reply-To: <200903310952.41282.bernhard@intevation.de>
References: <200903310952.41282.bernhard@intevation.de>
Message-ID: <49D35408.9020807@andrew.cmu.edu>

I don't recall if this change was intentional or accidental, but I 
wouldn't recommend trying to use any free-form banner information to 
determine a server's capability.  In fact, some Cyrus servers might not 
even include "Cyrus" in the banner if folks turn the "serverinfo" option 
off.

The proper way to detect the presence of shared seen state is the 
following (don't forget that shared seen state is per-mailbox):

Check for ANNOTATEMORE in the CAPABILITIES

If not present, then no shared seen state.

Otherwise,

GETANNOTATION <mboxname> "/vendor/cmu/cyrus-imapd/sharedseen" "value"

If you get an empty response, then no shared seen state.  Otherwise, the 
value will tell you if its enabled on the given mailbox.


Bernhard Reiter wrote:
> Just saw that between 2.3.11 and 2.3.12 the greeting changed to not include
> the "4" of "IMAP4" anymore.
> 
> https://bugzilla.andrew.cmu.edu/cgi-bin/cvsweb.cgi/src/cyrus/imap/imapd.c.diff?r1=1.545;r2=1.547;f=h
> The log message indicate no rational of this change, is it indentional?
> 
> (The second commit fixed a typo that "POP3" was in there, so it does look like 
> a typo indeed.)
> Ken, both commits are from you. :)
> 
> I detected this change because we wanted to detect if there is the ability to 
> have shared seen flags in KDE Kontact enterprise and our regex 
> contained "IMAP4", thus we've noticed the change.
> We'll change the regex, this kind of change should not happen without a reason 
> I guess.
> 
> (Even better would be to have a capability or so or a better way of detecting 
> the existance of the shared seen flags annotation switch. :) )
> 
> Best Regards,
> Bernhard

-- 
Kenneth Murchison
Systems Programmer
Carnegie Mellon University

From lorenzo at sancho.ccd.uniroma2.it  Wed Apr  1 12:48:22 2009
From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci)
Date: Wed, 1 Apr 2009 18:48:22 +0200 (CEST)
Subject: AMD64 and PIC
In-Reply-To: <20090329115725.GA10073@brong.net>
References: <20090329115725.GA10073@brong.net>
Message-ID: <alpine.DEB.1.10.0904011843310.8865@sancho.ccd.uniroma2.it>

I don't know if it's relevant, but I've posted many times a small 
opt-in patch to configure.in that does work (for me?) on both i386 and 
x86_64.

Here it is once more...

A nice forthweek to all!

Yours,

	lorenzo


On Sun, 29 Mar 2009, Bron Gondwana wrote:

BG> http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=3
BG> 
BG> (just because they seem to have documented it well)
BG> 
BG> I ran in to this with libcyrus.a when I put Ubuntu Jaunty Beta amd64 on
BG> my laptop today.  Passing CFLAGS with -fPIC to configure does the trick,
BG> but it would be nice if our configure could handle it.
BG> 
BG> Bron ( not at all an expert in configure writing! )
BG> 

+-------------------------+----------------------------------------------+
|   Lorenzo M.  Catucci   | Centro di Calcolo e Documentazione           |
| catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" |
|                         | Via O. Raimondo 18 ** I-00173 ROMA  ** ITALY |
|  Tel. +39 06 7259 2255  | Fax. +39 06 7259 2125                        |
+-------------------------+----------------------------------------------+
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cyrus_perl_ldflags.patch
Type: text/x-diff
Size: 1334 bytes
Desc: 
Url : http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20090401/ca2233a5/attachment.bin 

From ume at mahoroba.org  Thu Apr  2 03:46:51 2009
From: ume at mahoroba.org (Hajimu UMEMOTO)
Date: Thu, 02 Apr 2009 16:46:51 +0900
Subject: AMD64 and PIC
In-Reply-To: <alpine.DEB.1.10.0904011843310.8865@sancho.ccd.uniroma2.it>
References: <20090329115725.GA10073@brong.net>
	<alpine.DEB.1.10.0904011843310.8865@sancho.ccd.uniroma2.it>
Message-ID: <ygefxgrv6ok.wl%ume@mahoroba.org>

Hi,

>>>>> On Wed, 1 Apr 2009 18:48:22 +0200 (CEST)
>>>>> "Lorenzo M. Catucci" <lorenzo at sancho.ccd.uniroma2.it> said:

lorenzo> +dnl -- this is needed on NetBSD and Linux, but seems to cause problems on atleast Solaris --
lorenzo> +    case "${target_os}" in
lorenzo> +        linux*|netbsd*)
lorenzo> +            AC_MSG_CHECKING(for perl cccdlflags needed on "${target_os}")
lorenzo> +            eval `${PERL} -V:cccdlflags`
lorenzo> +            PERL_CCCDLFLAGS="$cccdlflags"
lorenzo> +            AC_SUBST(PERL_CCCDLFLAGS)
lorenzo> +            AC_MSG_RESULT($PERL_CCCDLFLAGS)
lorenzo> +            ;;
lorenzo> +        *)
lorenzo> +            AC_MSG_WARN(skipping check for perl cccdlflags on "${target_os}")
lorenzo> +    esac

Please add `freebsd*' as well.

Sincerely,

--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
ume at mahoroba.org  ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/

From bernhard at intevation.de  Thu Apr  2 10:58:11 2009
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 2 Apr 2009 16:58:11 +0200
Subject: "Cyrus IMAP4" to "Cyrus IMAP" accidental change of greeting?
In-Reply-To: <49D35408.9020807@andrew.cmu.edu>
References: <200903310952.41282.bernhard@intevation.de>
	<49D35408.9020807@andrew.cmu.edu>
Message-ID: <200904021658.15414.bernhard@intevation.de>

Am Mittwoch, 1. April 2009 13:46:16 schrieb Ken Murchison:
> I don't recall if this change was intentional or accidental, 

Okay, I just wanted to point it out.

> but I  wouldn't recommend trying to use any free-form banner information to
> determine a server's capability.  In fact, some Cyrus servers might not
> even include "Cyrus" in the banner if folks turn the "serverinfo" option
> off.

I know this is suboptimal, but still some clients might still do it.

> The proper way to detect the presence of shared seen state is the
> following (don't forget that shared seen state is per-mailbox):
>
> Check for ANNOTATEMORE in the CAPABILITIES
>
> If not present, then no shared seen state.
>
> Otherwise,
>
> GETANNOTATION <mboxname> "/vendor/cmu/cyrus-imapd/sharedseen" "value"
>
> If you get an empty response, then no shared seen state.  Otherwise, the
> value will tell you if its enabled on the given mailbox.

This would answer the wrong question, we want to detect if the server is able 
to run in shared seen state. if it does we can offer a configuration option, 
otherwise we do not. 

I do not know if there is a different test method that could answer this 
question. It is not feasable to try to set the annotation on a  test folder 
for each connection IMO. So best would be if there would be a SHAREDSEEN
or so capability.


> Bernhard Reiter wrote:
> > Just saw that between 2.3.11 and 2.3.12 the greeting changed to not
> > include the "4" of "IMAP4" anymore.
> >
> > https://bugzilla.andrew.cmu.edu/cgi-bin/cvsweb.cgi/src/cyrus/imap/imapd.c
> >.diff?r1=1.545;r2=1.547;f=h The log message indicate no rational of this
> > change, is it indentional?
> >
> > (The second commit fixed a typo that "POP3" was in there, so it does look
> > like a typo indeed.)
> > Ken, both commits are from you. :)
> >
> > I detected this change because we wanted to detect if there is the
> > ability to have shared seen flags in KDE Kontact enterprise and our regex
> > contained "IMAP4", thus we've noticed the change.
> > We'll change the regex, this kind of change should not happen without a
> > reason I guess.
> >
> > (Even better would be to have a capability or so or a better way of
> > detecting the existance of the shared seen flags annotation switch. :) )
> >
> > Best Regards,
> > Bernhard


-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20090402/bab66a63/attachment.bin 

From murch at andrew.cmu.edu  Thu Apr  2 17:51:14 2009
From: murch at andrew.cmu.edu (Ken Murchison)
Date: Thu, 02 Apr 2009 17:51:14 -0400
Subject: "Cyrus IMAP4" to "Cyrus IMAP" accidental change of greeting?
In-Reply-To: <200904021658.15414.bernhard@intevation.de>
References: <200903310952.41282.bernhard@intevation.de>	<49D35408.9020807@andrew.cmu.edu>
	<200904021658.15414.bernhard@intevation.de>
Message-ID: <49D53352.3080802@andrew.cmu.edu>

We could add a X-SHAREDSEEN capability, letting clients know that the 
server has the functionality, but its still a per-mailbox option.



Bernhard Reiter wrote:
> Am Mittwoch, 1. April 2009 13:46:16 schrieb Ken Murchison:
>> I don't recall if this change was intentional or accidental, 
> 
> Okay, I just wanted to point it out.
> 
>> but I  wouldn't recommend trying to use any free-form banner information to
>> determine a server's capability.  In fact, some Cyrus servers might not
>> even include "Cyrus" in the banner if folks turn the "serverinfo" option
>> off.
> 
> I know this is suboptimal, but still some clients might still do it.
> 
>> The proper way to detect the presence of shared seen state is the
>> following (don't forget that shared seen state is per-mailbox):
>>
>> Check for ANNOTATEMORE in the CAPABILITIES
>>
>> If not present, then no shared seen state.
>>
>> Otherwise,
>>
>> GETANNOTATION <mboxname> "/vendor/cmu/cyrus-imapd/sharedseen" "value"
>>
>> If you get an empty response, then no shared seen state.  Otherwise, the
>> value will tell you if its enabled on the given mailbox.
> 
> This would answer the wrong question, we want to detect if the server is able 
> to run in shared seen state. if it does we can offer a configuration option, 
> otherwise we do not. 
> 
> I do not know if there is a different test method that could answer this 
> question. It is not feasable to try to set the annotation on a  test folder 
> for each connection IMO. So best would be if there would be a SHAREDSEEN
> or so capability.
> 
> 
>> Bernhard Reiter wrote:
>>> Just saw that between 2.3.11 and 2.3.12 the greeting changed to not
>>> include the "4" of "IMAP4" anymore.
>>>
>>> https://bugzilla.andrew.cmu.edu/cgi-bin/cvsweb.cgi/src/cyrus/imap/imapd.c
>>> .diff?r1=1.545;r2=1.547;f=h The log message indicate no rational of this
>>> change, is it indentional?
>>>
>>> (The second commit fixed a typo that "POP3" was in there, so it does look
>>> like a typo indeed.)
>>> Ken, both commits are from you. :)
>>>
>>> I detected this change because we wanted to detect if there is the
>>> ability to have shared seen flags in KDE Kontact enterprise and our regex
>>> contained "IMAP4", thus we've noticed the change.
>>> We'll change the regex, this kind of change should not happen without a
>>> reason I guess.
>>>
>>> (Even better would be to have a capability or so or a better way of
>>> detecting the existance of the shared seen flags annotation switch. :) )
>>>
>>> Best Regards,
>>> Bernhard
> 
> 

-- 
Kenneth Murchison
Systems Programmer
Carnegie Mellon University

From robm at fastmail.fm  Thu Apr  2 18:39:10 2009
From: robm at fastmail.fm (Rob Mueller)
Date: Fri, 3 Apr 2009 09:39:10 +1100
Subject: "Cyrus IMAP4" to "Cyrus IMAP" accidental change of greeting?
In-Reply-To: <49D53352.3080802@andrew.cmu.edu>
References: <200903310952.41282.bernhard@intevation.de>	<49D35408.9020807@andrew.cmu.edu><200904021658.15414.bernhard@intevation.de>
	<49D53352.3080802@andrew.cmu.edu>
Message-ID: <42F2A5611FDC46BC8EFDC67130DE0272@Atticus>


> I do not know if there is a different test method that could answer this
> question. It is not feasable to try to set the annotation on a  test 
> folder for each connection IMO. So best would be if there would be a 
> SHAREDSEEN
> or so capability.

I think you misread that.

Ken said:

---
> GETANNOTATION <mboxname> "/vendor/cmu/cyrus-imapd/sharedseen" "value"
>
> If you get an empty response, then no shared seen state.  Otherwise, the
> value will tell you if its enabled on the given mailbox.
---

You don't need to "set the annotation", you just need to see if the 
annotation exists by using GETANNOTATION. Note that there's a difference 
between getting back a value (whether true/false) vs getting nothing back. 
If you get back a value at all, then it's supported, if you get nothing 
back, then it isn't.

Since INBOX is always guarnateed to exist as a folder, you can do:

tag GETANNOTATION INBOX "/vendor/cmu/cyrus-imapd/sharedseen" "value"

And see if you get a response back or not.

Rob


From brong at fastmail.fm  Thu Apr  2 17:56:24 2009
From: brong at fastmail.fm (Bron Gondwana)
Date: Fri, 3 Apr 2009 08:56:24 +1100
Subject: "Cyrus IMAP4" to "Cyrus IMAP" accidental change of greeting?
In-Reply-To: <200904021658.15414.bernhard@intevation.de>
References: <200903310952.41282.bernhard@intevation.de>
	<49D35408.9020807@andrew.cmu.edu>
	<200904021658.15414.bernhard@intevation.de>
Message-ID: <20090402215624.GA6898@brong.net>

On Thu, Apr 02, 2009 at 04:58:11PM +0200, Bernhard Reiter wrote:
> Am Mittwoch, 1. April 2009 13:46:16 schrieb Ken Murchison:
> > Check for ANNOTATEMORE in the CAPABILITIES
> > GETANNOTATION <mboxname> "/vendor/cmu/cyrus-imapd/sharedseen" "value"
> >
> > If you get an empty response, then no shared seen state.  Otherwise, the
> > value will tell you if its enabled on the given mailbox.
> 
> This would answer the wrong question, we want to detect if the server is able 
> to run in shared seen state. if it does we can offer a configuration option, 
> otherwise we do not. 

That's what Ken said... by using GET (not SET) ANNOTATION you can see if
the server supports that annotation.  You don't need to change the
value, just see if it will display it for you.
 
> I do not know if there is a different test method that could answer this 
> question. It is not feasable to try to set the annotation on a  test folder 
> for each connection IMO. So best would be if there would be a SHAREDSEEN
> or so capability.

Except that's not standard at all.  You could probably get away with
just checking the annotation on INBOX - if it exists then it's
reasonable to assume all the subfolders have it as well (you can
always return an error if/when the actual setting fails in that case)

Regards,

Bron.

From bernhard at intevation.de  Fri Apr  3 05:07:08 2009
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 3 Apr 2009 11:07:08 +0200
Subject: "Cyrus IMAP4" to "Cyrus IMAP" accidental change of greeting?
In-Reply-To: <49D53352.3080802@andrew.cmu.edu>
References: <200903310952.41282.bernhard@intevation.de>
	<200904021658.15414.bernhard@intevation.de>
	<49D53352.3080802@andrew.cmu.edu>
Message-ID: <200904031107.11769.bernhard@intevation.de>

Am Donnerstag, 2. April 2009 23:51:14 schrieb Ken Murchison:
> We could add a X-SHAREDSEEN capability, letting clients know that the
> server has the functionality, 

I think this would be the best way to do it,
because client can determine most easily if the server will honor a setting.

> but its still a per-mailbox option. 

Yes, I knew, sorry for being unclear on this and thanks a lot for the 
explanations.

> Bernhard Reiter wrote:
> > Am Mittwoch, 1. April 2009 13:46:16 schrieb Ken Murchison:
> >> I don't recall if this change was intentional or accidental,
> >
> > Okay, I just wanted to point it out.
> >
> >> but I ?wouldn't recommend trying to use any free-form banner information
> >> to determine a server's capability. ?In fact, some Cyrus servers might
> >> not even include "Cyrus" in the banner if folks turn the "serverinfo"
> >> option off.
> >
> > I know this is suboptimal, but still some clients might still do it.

Let me add, that I believe that some intrusion detection systems 
or security version scanner will bark on such a change in the free-form banner
just because it is a change. So I would possibly revert it to IMAP4 again 
(assuming that most people will not yet have gotten to 2.3.12 or 2.3.13 which 
both have "IMAP".) Otherwise it has been in there in two versions so this 
software would just bark until fixed.

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20090403/88b3b2e9/attachment.bin 

From bernhard at intevation.de  Fri Apr  3 05:12:57 2009
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 3 Apr 2009 11:12:57 +0200
Subject: "Cyrus IMAP4" to "Cyrus IMAP" accidental change of greeting?
In-Reply-To: <42F2A5611FDC46BC8EFDC67130DE0272@Atticus>
References: <200903310952.41282.bernhard@intevation.de>
	<49D53352.3080802@andrew.cmu.edu>
	<42F2A5611FDC46BC8EFDC67130DE0272@Atticus>
Message-ID: <200904031112.57821.bernhard@intevation.de>

Bron, Rob, 

thanks for helping to clarify. 

Am Freitag, 3. April 2009 00:39:10 schrieb Rob Mueller:
> ---
> > GETANNOTATION <mboxname> "/vendor/cmu/cyrus-imapd/sharedseen" "value"
> >
> > If you get an empty response, then no shared seen state. ?Otherwise, the
> > value will tell you if its enabled on the given mailbox.
> ---
>
> You don't need to "set the annotation", you just need to see if the
> annotation exists by using GETANNOTATION. Note that there's a difference
> between getting back a value (whether true/false) vs getting nothing back.
> If you get back a value at all, then it's supported, if you get nothing
> back, then it isn't.
>
> Since INBOX is always guarnateed to exist as a folder, you can do:
>
> tag GETANNOTATION INBOX "/vendor/cmu/cyrus-imapd/sharedseen" "value"
>
> And see if you get a response back or not.

This assumes that the ability of setting this special annotation also means 
the server will honor it. Probably a save thing to do with the current 
implementations. But this gives this detection two small drawbacks:

a) has to be done on one folder
Which is not as simple sometimes. E.g. a Kolab Server 
non-home server will give 
most users only some rights on the INBOX because they only connect to those
servers to see shared folders. So for me it is not guarenteed that there are 
write permissions for the annotation of the INBOX folder always.
Also it is slight more expensive than just parsing the CAPABILITIES
which is already existing code
b) Implementation might not honor the annotation even when set sometimes in 
the future or in strange setting, e.g. migrated folders with annotations. At 
least this is another assumption that might break.

Bernhard


-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20090403/aa42af4f/attachment.bin 

From robm at fastmail.fm  Sat Apr  4 03:32:20 2009
From: robm at fastmail.fm (Robert Mueller (web))
Date: Sat, 04 Apr 2009 18:32:20 +1100
Subject: "Cyrus IMAP4" to "Cyrus IMAP" accidental change of greeting?
In-Reply-To: <200904031112.57821.bernhard@intevation.de>
References: <200903310952.41282.bernhard@intevation.de><49D53352.3080802@andrew.cmu.edu><42F2A5611FDC46BC8EFDC67130DE0272@Atticus>
	<200904031112.57821.bernhard@intevation.de>
Message-ID: <1238830340.18752.1308923153@webmail.messagingengine.com>


> This assumes that the ability of setting this special annotation also
> means the server will honor it. Probably a save thing to do with the
> current implementations. But this gives this detection two small
> drawbacks:

This is still way better than your current solution which was to look
for "Cyrus IMAP4" in the opening banner! This is way less specific and
less broken than that approach.

Rob
robm at fastmail.fm
Sign up at http://fastmail.fm for fast, ad free, IMAP accessible email


From benjamin.oshrin at rutgers.edu  Mon Apr  6 09:58:35 2009
From: benjamin.oshrin at rutgers.edu (Benn Oshrin)
Date: Mon, 06 Apr 2009 09:58:35 -0400
Subject: Advanced CAMP on IDM
Message-ID: <89D5C1E2F8FB117AFDAE017A@boshrin-m.ad.ess.rutgers.edu>

I2 (& etc) are putting together a "Digital Identity Summit" for the 
Advanced CAMP in Philadelphia in June.  One of the program committee's 
goals is to assemble application folks to discuss what their pain points 
are when it comes to IDM integration, eg accessing your central IDM's 
authorization information easily (or rather, not so easily) from your 
application.

Is there anybody in the Cyrus dev community who might be interested in 
participating?

-Benn-

From alexey.melnikov at isode.com  Sun Apr 12 04:44:03 2009
From: alexey.melnikov at isode.com (Alexey Melnikov)
Date: Sun, 12 Apr 2009 09:44:03 +0100
Subject: New IMAP capability for advertising support for shared Seen state 
	(was Re: "Cyrus IMAP4" to "Cyrus IMAP" accidental change of greeting?)
In-Reply-To: <200904021658.15414.bernhard@intevation.de>
References: <200903310952.41282.bernhard@intevation.de>
	<49D35408.9020807@andrew.cmu.edu>
	<200904021658.15414.bernhard@intevation.de>
Message-ID: <49E1A9D3.3060401@isode.com>

Bernhard Reiter wrote:

>>The proper way to detect the presence of shared seen state is the
>>following (don't forget that shared seen state is per-mailbox):
>>
>>Check for ANNOTATEMORE in the CAPABILITIES
>>
>>If not present, then no shared seen state.
>>
>>Otherwise,
>>
>>GETANNOTATION <mboxname> "/vendor/cmu/cyrus-imapd/sharedseen" "value"
>>
>>If you get an empty response, then no shared seen state.  Otherwise, the
>>value will tell you if its enabled on the given mailbox.
>>
>
>This would answer the wrong question, we want to detect if the server is able 
>to run in shared seen state. if it does we can offer a configuration option, 
>otherwise we do not. 
>
>I do not know if there is a different test method that could answer this 
>question. It is not feasable to try to set the annotation on a  test folder 
>for each connection IMO. So best would be if there would be a SHAREDSEEN
>or so capability.
>  
>
I would support standardizing of such IMAP capability.


From carson at taltos.org  Mon Apr 13 12:18:16 2009
From: carson at taltos.org (Carson Gaspar)
Date: Mon, 13 Apr 2009 09:18:16 -0700
Subject: AMD64 and PIC
In-Reply-To: <alpine.DEB.1.10.0904011843310.8865@sancho.ccd.uniroma2.it>
References: <20090329115725.GA10073@brong.net>
	<alpine.DEB.1.10.0904011843310.8865@sancho.ccd.uniroma2.it>
Message-ID: <49E365C8.1020808@taltos.org>

Lorenzo M. Catucci wrote:
> I don't know if it's relevant, but I've posted many times a small 
> opt-in patch to configure.in that does work (for me?) on both i386 and 
> x86_64.

Please define "seems to cause problems on atleast Solaris". Hard coded 
OS specific nastiness is a Very Bad Thing in autoconf.

-- 
Carson

From carson at taltos.org  Mon Apr 13 12:19:48 2009
From: carson at taltos.org (Carson Gaspar)
Date: Mon, 13 Apr 2009 09:19:48 -0700
Subject: AMD64 and PIC
In-Reply-To: <20090329115725.GA10073@brong.net>
References: <20090329115725.GA10073@brong.net>
Message-ID: <49E36624.8080502@taltos.org>

Bron Gondwana wrote:
> http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=3
> 
> (just because they seem to have documented it well)
> 
> I ran in to this with libcyrus.a when I put Ubuntu Jaunty Beta amd64 on
> my laptop today.  Passing CFLAGS with -fPIC to configure does the trick,
> but it would be nice if our configure could handle it.

Shared objects must be compiled PIC on almost all platforms. This has 
nothing to do specifically with AMD64. If the current code does not 
behave properly, it needs to be fixed on all platforms.

-- 
Carson

From dave64 at andrew.cmu.edu  Wed Apr 15 15:22:33 2009
From: dave64 at andrew.cmu.edu (Dave McMurtrie)
Date: Wed, 15 Apr 2009 15:22:33 -0400
Subject: Improvement to config file parsing code?
Message-ID: <49E633F9.2030105@andrew.cmu.edu>

I discovered that the code in libconfig.c that parses imapd.conf really
has no way of warning you if you make a typo.  It looks like someone
tried to deal with this at some point, but that code is commented out
because it would die on any service-specific configuration options.

The patch I propose here relies on the fact that a service-specific
option must contain a '_' character in it, so this patch would at least
catch simple typos to real imapd configuration options.  Of course, this
patch is only valid if my assumption that all service-specific options
must contain an underscore is valid.

Thoughts?  If this would be useful, I'll throw it in bugzilla.  If it's
a dumb idea, I'll forget about it.

--- libconfig.c.orig    2009-03-31 08:22:14.000000000 -0400
+++ libconfig.c 2009-04-15 15:04:44.000000000 -0400
@@ -589,18 +589,14 @@
            /* check to make sure it's valid for overflow */
            /* that is, partition names and anything that might be
             * used by SASL */
-/*
-  xxx this would be nice if it wasn't for other services who might be
-      sharing this config file and whose names we cannot predict
-
            if(strncasecmp(key,"sasl_",5)
-           && strncasecmp(key,"partition-",10)) {
+              && strncasecmp(key,"partition-",10)
+              && (!strchr(key,'_'))) {
                sprintf(errbuf,
                        "option '%s' is unknown on line %d of config file",
                        fullkey, lineno);
                fatal(errbuf, EC_CONFIG);
            }
-*/

            /* Put it in the overflow hash table */
            newval = xstrdup(p);

-- 
Dave McMurtrie, SPE
Email Systems Team Leader
Carnegie Mellon University,
Computing Services

From martin.konold at erfrakon.de  Mon Apr 20 01:37:05 2009
From: martin.konold at erfrakon.de (Martin Konold)
Date: Mon, 20 Apr 2009 07:37:05 +0200
Subject: New IMAP capability for advertising support for shared Seen state
	(was Re: "Cyrus IMAP4" to "Cyrus IMAP" accidental change of greeting?)
In-Reply-To: <49E1A9D3.3060401@isode.com>
References: <200903310952.41282.bernhard@intevation.de>
	<200904021658.15414.bernhard@intevation.de>
	<49E1A9D3.3060401@isode.com>
Message-ID: <200904200737.06163.martin.konold@erfrakon.de>

Am Sonntag, 12. April 2009 10:44:03 schrieb Alexey Melnikov:

Hi,

> Bernhard Reiter wrote:

> >>following (don't forget that shared seen state is per-mailbox):
> >>
> >>Check for ANNOTATEMORE in the CAPABILITIES

> >>GETANNOTATION <mboxname> "/vendor/cmu/cyrus-imapd/sharedseen" "value"
> >>
> >>If you get an empty response, then no shared seen state. 

> >question. It is not feasable to try to set the annotation on a  test
> > folder for each connection IMO. So best would be if there would be a
> > SHAREDSEEN or so capability.
>
> I would support standardizing of such IMAP capability.

Technically it would be required to test with every mailbox not only with each 
connection. E.g. there are sometimes reasons why the shared seen is only 
available for some namespaces.

IMHO probing each mailbox or each namesapce is not an option and would pervert 
the efficiency of IMAP especially over high latency low bandwidth links.

On the other hand capabilities should not be expanded without good reasons.

What about a server provided GETANNOTATION answer?

Yours,
-- martin

-- 
e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
Sitz: Adolfstra?e 23, 70469 Stuttgart, Partnerschaftsregister Stuttgart PR 126
http://www.erfrakon.com/

From alexey.melnikov at isode.com  Mon Apr 20 14:04:49 2009
From: alexey.melnikov at isode.com (Alexey Melnikov)
Date: Mon, 20 Apr 2009 19:04:49 +0100
Subject: New IMAP capability for advertising support for shared Seen state 
	(was Re: "Cyrus IMAP4" to "Cyrus IMAP" accidental change of greeting?)
In-Reply-To: <200904200737.06163.martin.konold@erfrakon.de>
References: <200903310952.41282.bernhard@intevation.de>
	<200904021658.15414.bernhard@intevation.de>
	<49E1A9D3.3060401@isode.com>
	<200904200737.06163.martin.konold@erfrakon.de>
Message-ID: <49ECB941.7090908@isode.com>

Martin Konold wrote:

>Am Sonntag, 12. April 2009 10:44:03 schrieb Alexey Melnikov:
>
>Hi,
>  
>
>>Bernhard Reiter wrote:
>>    
>>
>>>>following (don't forget that shared seen state is per-mailbox):
>>>>
>>>>Check for ANNOTATEMORE in the CAPABILITIES
>>>>        
>>>>
>>>>GETANNOTATION <mboxname> "/vendor/cmu/cyrus-imapd/sharedseen" "value"
>>>>
>>>>If you get an empty response, then no shared seen state. 
>>>>        
>>>>
>>>question. It is not feasable to try to set the annotation on a  test
>>>folder for each connection IMO. So best would be if there would be a
>>>SHAREDSEEN or so capability.
>>>      
>>>
>>I would support standardizing of such IMAP capability.
>>    
>>
>Technically it would be required to test with every mailbox not only with each 
>connection. E.g. there are sometimes reasons why the shared seen is only 
>available for some namespaces.
>
>IMHO probing each mailbox or each namesapce is not an option and would pervert 
>the efficiency of IMAP especially over high latency low bandwidth links.
>  
>
No, I had something else in mind - return this capability if at least 
one mailbox is known to support shared seen state.
This might benefit other IMAP servers more, e.g. if a server is known to 
only support shared seen state, or always support shared seen state for 
a particular mailbox.

>On the other hand capabilities should not be expanded without good reasons.
>
>What about a server provided GETANNOTATION answer?
>
Regards,
Alexey

-- 
IETF Application Area Director, <http://www.ietf.org/IESGmems.html>
Internet Messaging Team Lead, <http://www.isode.com>
JID: same as my email address


From cyril.servant at atosorigin.com  Tue Apr 21 06:02:53 2009
From: cyril.servant at atosorigin.com (Cyril Servant)
Date: Tue, 21 Apr 2009 12:02:53 +0200
Subject: Warning if a service name contains non alphanumerical character
Message-ID: <1240308173.6424.4.camel@localhost>

Hello,

last week, I ran into a configuration issue :
- in cyrus.conf, I configured two imapd services, named 'imap' and
'imap_int' (this was my error).
- cyrus started correctly, but those services hung after the first
successful connection. This is because cyrus ignores '_int', and
therefore believes these two services are named 'imap'... and locks a
single file for both services...

The only thing that annoys me is that no warning appears in the logs,
the processes hang quietly.

So I wrote a patch for this : if a service name contains a
non-alphanumeric AND non-space character, a warning is syslogged when
master reads the configuration.

Here is the bugzilla link :
https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=3152

-- 
Cyril Servant <cyril.servant at atosorigin.com>


From dpc22 at cam.ac.uk  Wed Apr 22 09:54:15 2009
From: dpc22 at cam.ac.uk (David Carter)
Date: Wed, 22 Apr 2009 14:54:15 +0100 (BST)
Subject: Small type bug in lmtpengine.c
Message-ID: <alpine.LSU.2.00.0904221449510.27467@hermes-2.csi.cam.ac.uk>

The quota parameter to verify_user() is quota_t, not long.

Solaris 10 with bundled GCC 3.4.3 wasn't doing type promotion correctly. 
(long)(-1) becomes (long long int)(4294967295), which is >= 0.

Consequently IGNOREQUOTA had no effect.

-- 
David Carter                             Email: David.Carter at ucs.cam.ac.uk
University Computing Service,            Phone: (01223) 334502
New Museums Site, Pembroke Street,       Fax:   (01223) 334679
Cambridge UK. CB2 3QH.

Index: imap/lmtpengine.c
===================================================================
RCS file: /data/ucvs/hermes/src/cyrus-imapd/imap/lmtpengine.c,v
retrieving revision 1.1.1.1
diff -u -d -r1.1.1.1 lmtpengine.c
--- imap/lmtpengine.c	25 Mar 2009 17:02:48 -0000	1.1.1.1
+++ imap/lmtpengine.c	22 Apr 2009 13:48:05 -0000
@@ -809,7 +809,7 @@
  static int process_recipient(char *addr, struct namespace *namespace,
  			     int ignorequota,
  			     int (*verify_user)(const char *, const char *,
-						char *, long,
+						char *, quota_t,
  						struct auth_state *),
  			     message_data_t *msg)
  {
@@ -898,7 +898,7 @@
  	ret->user = NULL;

      r = verify_user(ret->user, ret->domain, ret->mailbox,
-		    ignorequota ? -1 : msg->size, msg->authstate);
+		    (quota_t)(ignorequota ? -1 : msg->size), msg->authstate);
      if (r) {
  	/* we lost */
  	free(ret->all);

From bawood at umich.edu  Wed Apr 22 13:58:11 2009
From: bawood at umich.edu (Brian Awood)
Date: Wed, 22 Apr 2009 13:58:11 -0400
Subject: DELAYED DELETE and very long mailboxes => segfault
In-Reply-To: <200902061227.48403.bawood@umich.edu>
References: <20090206134159.GA5729@brong.net>
	<200902061227.48403.bawood@umich.edu>
Message-ID: <200904221358.11644.bawood@umich.edu>


On Friday 06 February 2009 @ 12:27, Brian Awood wrote:
> We have had users that weren't able to delete a mailbox that was
> close to, or already at, the max name length.  Cyrus generates the
> new name with the DELETED prefix and time stamp suffix, which ends
> up being longer than the allowed max and the rename then fails.

While doing testing of 2.3.14 with our local changes I found that we 
still aren't able to delete mailboxes that are at or near the 
MAX_MAILBOX_SIZE limit.  It fails in the mboxname_policycheck() at 
the length test.  The simple solution I see is for the policy check 
to just return 0 if mboxname_isdeletedmailbox() returns true.  
Logically, if a mailbox is being deleted, it already exists and 
therefore should have passed the policy check when it was created.  
I'm wondering if anyone knows of problems that would cause which I'm 
not seeing, if not I'll submit a BZ report and diff with the fix.

Brian

From brong at fastmail.fm  Wed Apr 22 19:06:35 2009
From: brong at fastmail.fm (Bron Gondwana)
Date: Thu, 23 Apr 2009 09:06:35 +1000
Subject: DELAYED DELETE and very long mailboxes => segfault
In-Reply-To: <200904221358.11644.bawood@umich.edu>
References: <20090206134159.GA5729@brong.net>
	<200902061227.48403.bawood@umich.edu>
	<200904221358.11644.bawood@umich.edu>
Message-ID: <20090422230635.GA6160@brong.net>

On Wed, Apr 22, 2009 at 01:58:11PM -0400, Brian Awood wrote:
> 
> On Friday 06 February 2009 @ 12:27, Brian Awood wrote:
> > We have had users that weren't able to delete a mailbox that was
> > close to, or already at, the max name length.  Cyrus generates the
> > new name with the DELETED prefix and time stamp suffix, which ends
> > up being longer than the allowed max and the rename then fails.
> 
> While doing testing of 2.3.14 with our local changes I found that we 
> still aren't able to delete mailboxes that are at or near the 
> MAX_MAILBOX_SIZE limit.  It fails in the mboxname_policycheck() at 
> the length test.  The simple solution I see is for the policy check 
> to just return 0 if mboxname_isdeletedmailbox() returns true.  
> Logically, if a mailbox is being deleted, it already exists and 
> therefore should have passed the policy check when it was created.  
> I'm wondering if anyone knows of problems that would cause which I'm 
> not seeing, if not I'll submit a BZ report and diff with the fix.

Yes, fair enough.  That sounds good to me.  I just had a look back
through the logs... the MAX_MAILBOX_BUFFER code is in 2.3.14, so
the bug probably still exists in current CVS.

A patch would be great!

Thanks,

Bron.

From murch at andrew.cmu.edu  Wed Apr 22 21:30:57 2009
From: murch at andrew.cmu.edu (Ken Murchison)
Date: Wed, 22 Apr 2009 21:30:57 -0400
Subject: Small type bug in lmtpengine.c
In-Reply-To: <alpine.LSU.2.00.0904221449510.27467@hermes-2.csi.cam.ac.uk>
References: <alpine.LSU.2.00.0904221449510.27467@hermes-2.csi.cam.ac.uk>
Message-ID: <49EFC4D1.6020404@andrew.cmu.edu>

Applied to CVS.


David Carter wrote:
> The quota parameter to verify_user() is quota_t, not long.
> 
> Solaris 10 with bundled GCC 3.4.3 wasn't doing type promotion correctly. 
> (long)(-1) becomes (long long int)(4294967295), which is >= 0.
> 
> Consequently IGNOREQUOTA had no effect.
> 

-- 
Kenneth Murchison
Systems Programmer
Carnegie Mellon University

From brong at fastmail.fm  Sat Apr 25 06:27:35 2009
From: brong at fastmail.fm (Bron Gondwana)
Date: Sat, 25 Apr 2009 20:27:35 +1000
Subject: IMAP COMPRESS
In-Reply-To: <200904231710.n3NHA78j027738@unix37.andrew.cmu.edu>
References: <200904231710.n3NHA78j027738@unix37.andrew.cmu.edu>
Message-ID: <20090425102735.GA23694@brong.net>

On Thu, Apr 23, 2009 at 01:10:07PM -0400, murch at andrew.cmu.edu wrote:
> Update of /afs/andrew/system/cvs/src/cyrus/imap
> In directory unix37.andrew.cmu.edu:/var/tmp/cvs-serv27712/imap
> 
> Modified Files:
> 	backend.c deliver.c imap_proxy.c imap_proxy.h imapd.c index.c 
> 	lmtpd.c lmtpengine.h mupdate-client.c mupdate.c nntpd.c 
> 	pop3d.c protocol.h pushstats.snmp sync_client.c version.c 
> Log Message:
> Added support for MUPDATE COMPRESS and IMAP COMPRESS commands
> which help speed up bulk data commands over slow links

Nice :)

Here's what my offlineimap gets going through a skanky little proxy
that I coded up in Perl to interfere with the stream and enable
compression:

COMPRESSION RATIO: [8 fromfm] 27932/172698 = 16.2%
COMPRESSION RATIO: [10 fromfm] 428077/2904757 = 14.7%

On the two accounts that I'm using.

That's a pretty nice FLAGS compression :)

Bron ( ok, ok - so if it used CONDSTORE it would probably save
       50 times that, but I haven't got around to hacking
       CONDSTORE into offlineimap yet )

From duncan.gibb at siriusit.co.uk  Sat Apr 25 11:36:30 2009
From: duncan.gibb at siriusit.co.uk (Duncan Gibb)
Date: Sat, 25 Apr 2009 16:36:30 +0100
Subject: [PATCH] client certificates for TLS
In-Reply-To: <496E1D7D.5020503@SiriusIT.co.uk>
References: <491481E8.2010103@SiriusIT.co.uk> <496E1D7D.5020503@SiriusIT.co.uk>
Message-ID: <49F32DFE.9050900@siriusit.co.uk>

Hello

I've updated my backend client certificates patch to work with 2.3.14.
Attached and at https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=3133

I doing so, I added a few checks in the new MITM attack detection code
because the client segfaults if the server initially gives an empty mech
list (ie it wants the client to STARTTLS before offering EXTERNAL).

Also, I set mupdate_protocol.tls_cmd.auto_capa because the client needs
to re-parse the banner after STARTTLS to pick up EXTERNAL when using a
client cert.  I think this is harmless, and I know it's useless without
https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=3119


Cheers


Duncan

-- 
Duncan Gibb - Technical Director
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk/ || t: +44 870 608 0063
Debian Cyrus Team - https://alioth.debian.org/projects/pkg-cyrus-imapd/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mainline_backend-client-certs_2-3-14.patch
Type: text/x-diff
Size: 5279 bytes
Desc: not available
Url : http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20090425/48398816/attachment.bin 

From jleu at mindspring.com  Wed Apr 29 01:37:09 2009
From: jleu at mindspring.com (James R. Leu)
Date: Wed, 29 Apr 2009 00:37:09 -0500
Subject: New to list, looking for pointer
Message-ID: <20090429053708.GB20712@mindspring.com>

Hello,

I'm new to the list and am looking for a recommendation
on where to post a question about a crash I seeing with
imapd.

I'm going to include the info I have, if this is not the correct
info or the correct place, please kindly point out what I'm
missing or where I should post.  Thanks.

db4-4.3.29-9.fc6
cyrus-imapd-2.3.7-2.el5
kernel-2.6.18-92.1.22.el5

running on CentOS 5.2

I'm running cyrus-imapd inside a VirtualBox VM that gets
its disk via ISCSI.

I see the imapd processes die in the 10's producing
core files that have the following stack trace.

Core was generated by `imapd -s'.
Program terminated with signal 11, Segmentation fault.
[New process 27178]
#0  index_searchmsg (substr=0x96612c0 "statistics", pat=0x964cd70, 
    msgfile=0xbfa19604, format=0, skipheader=1, 
    cacheitem=0x2458eb6c <Address 0x2458eb6c out of bounds>) at index.c:3267
3267		subparts = CACHE_ITEM_BIT32(cacheitem);
(gdb) where
#0  index_searchmsg (substr=0x96612c0 "statistics", pat=0x964cd70, 
    msgfile=0xbfa19604, format=0, skipheader=1, 
    cacheitem=0x2458eb6c <Address 0x2458eb6c out of bounds>) at index.c:3267
#1  0x00c2d979 in index_search_evaluate (mailbox=0xd30380, 
    searchargs=0x964dfd8, msgno=2934, msgfile=0xbfa19604) at index.c:3227
#2  0x00c2dd1e in _index_search (msgno_list=0xbfa19644, mailbox=0xd30380, 
    searchargs=0x964dfd8, highestmodseq=0x0) at index.c:1012
#3  0x00c2e135 in index_search (mailbox=0xd30380, searchargs=0x964dfd8, 
    usinguid=1) at index.c:1071
#4  0x00c1116b in cmd_search (tag=0x9661768 "6", usinguid=1) at imapd.c:4465
#5  0x00c1e2bc in cmdloop () at imapd.c:1664
#6  0x00c20441 in service_main (argc=2, argvat imapd.c:793
#7  0x00c04d21 in main (argc=2, argv=0xbfa1bea4, envp=0xbfa1beb0)
    at service.c:532
(gdb) 

When I searched http://cyrusimap.web.cmu.edu/archive/search.php?mailbox=archive.cyrus-devel
for index_searchmsg, it only comes up with two hits for a patch by
Bron Gondwana <brong at fastmail.fm> from March.

Is the above a known issue?  If so, is there any sort of work around or
resource I can change to alleviate the issue?  Otherwise can someone in the
know give me a rough idea of where in the life-cycle of the imapd process
this code path might be executed so I can start to dig into the issue
myself.

Thank you in advance.
-- 
James R. Leu
jleu at mindspring.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20090429/b338a943/attachment.bin 

From brong at fastmail.fm  Wed Apr 29 02:38:45 2009
From: brong at fastmail.fm (Bron Gondwana)
Date: Wed, 29 Apr 2009 16:38:45 +1000
Subject: New to list, looking for pointer
In-Reply-To: <20090429053708.GB20712@mindspring.com>
References: <20090429053708.GB20712@mindspring.com>
Message-ID: <20090429063845.GA20468@brong.net>

On Wed, Apr 29, 2009 at 12:37:09AM -0500, James R. Leu wrote:
> Hello,
> 
> I'm new to the list and am looking for a recommendation
> on where to post a question about a crash I seeing with
> imapd.
> 
> I'm going to include the info I have, if this is not the correct
> info or the correct place, please kindly point out what I'm
> missing or where I should post.  Thanks.
> 
> db4-4.3.29-9.fc6
> cyrus-imapd-2.3.7-2.el5
> kernel-2.6.18-92.1.22.el5
> 
> running on CentOS 5.2
> 
> I'm running cyrus-imapd inside a VirtualBox VM that gets
> its disk via ISCSI.
> 
> I see the imapd processes die in the 10's producing
> core files that have the following stack trace.
> 
> Core was generated by `imapd -s'.
> Program terminated with signal 11, Segmentation fault.
> [New process 27178]
> #0  index_searchmsg (substr=0x96612c0 "statistics", pat=0x964cd70, 
>     msgfile=0xbfa19604, format=0, skipheader=1, 
>     cacheitem=0x2458eb6c <Address 0x2458eb6c out of bounds>) at index.c:3267
> 3267		subparts = CACHE_ITEM_BIT32(cacheitem);
> (gdb) where
> #0  index_searchmsg (substr=0x96612c0 "statistics", pat=0x964cd70, 
>     msgfile=0xbfa19604, format=0, skipheader=1, 
>     cacheitem=0x2458eb6c <Address 0x2458eb6c out of bounds>) at index.c:3267
> #1  0x00c2d979 in index_search_evaluate (mailbox=0xd30380, 
>     searchargs=0x964dfd8, msgno=2934, msgfile=0xbfa19604) at index.c:3227
> #2  0x00c2dd1e in _index_search (msgno_list=0xbfa19644, mailbox=0xd30380, 
>     searchargs=0x964dfd8, highestmodseq=0x0) at index.c:1012
> #3  0x00c2e135 in index_search (mailbox=0xd30380, searchargs=0x964dfd8, 
>     usinguid=1) at index.c:1071
> #4  0x00c1116b in cmd_search (tag=0x9661768 "6", usinguid=1) at imapd.c:4465
> #5  0x00c1e2bc in cmdloop () at imapd.c:1664
> #6  0x00c20441 in service_main (argc=2, argvat imapd.c:793
> #7  0x00c04d21 in main (argc=2, argv=0xbfa1bea4, envp=0xbfa1beb0)
>     at service.c:532
> (gdb) 
> 
> When I searched http://cyrusimap.web.cmu.edu/archive/search.php?mailbox=archive.cyrus-devel
> for index_searchmsg, it only comes up with two hits for a patch by
> Bron Gondwana <brong at fastmail.fm> from March.
> 
> Is the above a known issue?  If so, is there any sort of work around or
> resource I can change to alleviate the issue?  Otherwise can someone in the
> know give me a rough idea of where in the life-cycle of the imapd process
> this code path might be executed so I can start to dig into the issue
> myself.
> 
> Thank you in advance.

Walk up the tree up a couple of times and 'p *mailbox'.  That will tell
you which mailbox has the corrupted cache file.

Then run reconstruct on that mailbox, which will fix the cache file.

(the patches stop it crashing, but don't fix the cache file.  There
are also quite a few patches in more recent versions of cyrus that
stop it corrupting cache files... 2.3.14 is pretty good.  I think
we've got most of them!)

Regards,

Bron.

From tschlabach at gmx.net  Wed Apr 29 10:30:58 2009
From: tschlabach at gmx.net (Torsten Schlabach)
Date: Wed, 29 Apr 2009 16:30:58 +0200
Subject: Making sieveshell more scripting friendly
Message-ID: <49F864A2.9080809@gmx.net>

Hi all!

I found that scripting sieveshell (for example, writing a bash script 
which iterates over mailboxes and does something to the sieve settings) 
is a bit tricky for two reasons:

1. You cannot pass the user's password on the command line.
2. You cannot pass it a command which is executed and the shell 
terminated afterwards.

Would anyone object to adding these two features?

Regards,
Torsten