From kolab-issues at intevation.de  Fri Aug  1 00:22:36 2008
From: kolab-issues at intevation.de (helen kumba)
Date: Thu, 31 Jul 2008 22:22:36 +0000
Subject: [Kolab-devel] [issue2957] Hello,
Message-ID: <d75c9d800807311522y1cd092eby82027e6523c50786@mail.gmail.com>


New submission from helen kumba <helenkumba05 at gmail.com>:

Hello,

 my name is Helen, i am 25 years in search of a man who understands love as
trust and faith rather seeing it as a way of fun always but a matured man
with scence of humor. so after reading your profile i derive spercial
interest on you so contact me with this email addres (helenkumba at yahoo.com)
I believe we can start from here. awaiting to hear from you soon so i can
send pics for more introductions.

Kisses

Helen

----------
messages: 15996
nosy: helenkumba05
status: unread
title: Hello,
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue2957>
___________________________________________________


From thomas at intevation.de  Fri Aug  1 12:39:02 2008
From: thomas at intevation.de (Thomas Arendsen Hein)
Date: Fri, 1 Aug 2008 12:39:02 +0200
Subject: [Kolab-devel] Modifying the LDAP user representation for a
	distributed Kolab server system?
In-Reply-To: <87od4grj4a.fsf@home.pardus.de>
References: <871w1drtk6.fsf@home.pardus.de>
	<20080729092316.GB27133.thomas@intevation.de>
	<87wsj5qak7.fsf@home.pardus.de>
	<200807291326.25828.bernhard@intevation.de>
	<87od4grj4a.fsf@home.pardus.de>
Message-ID: <20080801103902.GC5403.thomas@intevation.de>

* Gunnar Wrobel <wrobel at pardus.de> [20080729 14:05]:
> So let me suggest an alternative by using the existing
> "kolabHomeserver" attribute. Would it be okay to extend its syntax to
> allow for several settings like:
> 
>   "example.org"
>   "MTA:smtp.example.org"
>   "IMAP:imap.example.org"
>   "FreeBusy:fb.example.org"
> 
> The default would be the entry without "prefix:" but it would be
> possible to provide redirects for specific services.
> 
> I don't suggest to directly add support for this in the various Kolab
> services we currently have as I don't see this as urgent. But if we
> define the syntax this way we could at least start supporting this for
> the more common splitted Kolab server setups.
> 
> If I consider the point Bernhard mentioned recently concerning
> splitted IMAP storage per user it might also make sense to have a
> syntax like
> 
>   "imap://USER:PASS at SERVER"

Do not make it look like URLs, otherwise you'll get confusion when
storing URLs, e.g. imap://user:pass at server vs. imaps://user:pass at server
I'd suggest somethink like IMAP=imap://... if you want to have URLs.

Thomas

-- 
thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A
Intevation GmbH, Osnabrueck - Register: Amtsgericht Osnabrueck, HR B 18998
Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner


From kolab-issues at intevation.de  Sun Aug  3 20:56:08 2008
From: kolab-issues at intevation.de (Marc Mutz)
Date: Sun, 03 Aug 2008 18:56:08 +0000
Subject: [Kolab-devel] [issue2960] IMAP protocol slave misleading error
	message [regression from KDE 3.5 Debian Etch Packages]
Message-ID: <1217789768.1.0.182554444134.issue2960@intevation.de>


New submission from Marc Mutz <marc at kdab.net>:

Easy to reproduce with SSH-over-UMTS, or with a network fault injector:
1. Configure dIMAP over an SSH tunnel.
2. Pull network and tunnel up.
3. Suspend computer.
4. Resume computer.
-> Underlying connection broken, but SSH connection appears up to clients
   (though nothing goes through)
5. Start a Favourite Folder Sync (CTRL-Shift-L).
-> hangs as expected
6. killall ssh
-> Error message:
   "The server ... supports neither IMAP4 nor IMAP4rev1."
   "It identified itself with:" <end of error message>
Expected:
   "Connection to ... broken."
This is a regression from KDE 3.5.7 (Etch packages).

----------
assignedto: till
messages: 16008
nosy: marc, till
priority: minor bug
status: unread
title: IMAP protocol slave misleading error message [regression from KDE 3.5 Debian Etch Packages]
topic: enterprise35, kde client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue2960>
___________________________________________________


From ml at radoeka.nl  Sun Aug  3 23:56:58 2008
From: ml at radoeka.nl (Richard Bos)
Date: Sun, 3 Aug 2008 23:56:58 +0200
Subject: [Kolab-devel] Kolab on Gmail
In-Reply-To: <87tze9rzza.fsf@home.pardus.de>
References: <87r69tki4b.fsf@home.pardus.de>
	<200807241719.37503.bernhard@intevation.de>
	<87tze9rzza.fsf@home.pardus.de>
Message-ID: <200808032356.58719.ml@radoeka.nl>

Op Tuesday 29 July 2008 08:00:57 schreef Gunnar Wrobel:
> For general acceptance of the annotation extension the following draft
> also needs to be accepted by IETF:
>
> http://ietfreport.isoc.org/all-ids/draft-daboo-imap-annotatemore-14.txt
>
> This is progressing but it seems to take years. Last time I asked for
> annotation support in c-client Mark Crispin said that he would only
> consider that if the draft has become a RFC. Even then he didn't sound
> too positive about it as he seemed unhappy with the draft. Now that he
> has been laid off I don't know if our chances of getting wider
> annotation support are higher or lower. c-client seems kind of
> unmaintained at the moment.

Should this information be stored at 
http://wiki.kolab.org/index.php/Kolab-major-app-patches#UW_IMAP_c-client ?
Is there an alternative by for example using a different library?

-- 
Richard Bos
We are borrowing the world of our children,
It is not inherited from our parents.


From richard at radoeka.nl  Mon Aug  4 00:01:07 2008
From: richard at radoeka.nl (Richard Bos)
Date: Mon, 4 Aug 2008 00:01:07 +0200
Subject: [Kolab-devel] wilde: server/php-kolab/Kolab_Filter AUTHORS, 1.3,
	1.4 ChangeLog, 1.19, 1.20 package.xml.in, 1.7, 1.8
In-Reply-To: <20080801105451.3F9BB600BB1@lists.intevation.de>
References: <20080801105451.3F9BB600BB1@lists.intevation.de>
Message-ID: <200808040001.08200.richard@radoeka.nl>

Op Friday 01 August 2008 12:54:51 schreef cvs at kolab.org:
> +???????* Filter/DovecotLDA.php: New file: simple Dovecot LDA backend with
> +???????API similar to Net_LMTP, so it can be used as drop-in replacement.

How does one choose between Dovecot and Net_LMTP?  Is that automatic or should 
it be configured  manually?  If the latter where is that done?

-- 
Richard Bos
We are borrowing the world of our children,
It is not inherited from our parents.


From ml at radoeka.nl  Mon Aug  4 07:51:22 2008
From: ml at radoeka.nl (Richard Bos)
Date: Mon, 4 Aug 2008 07:51:22 +0200
Subject: [Kolab-devel] Dovecot as imap server (was: Kolab on Gmail)
In-Reply-To: <200807241719.37503.bernhard@intevation.de>
References: <87r69tki4b.fsf@home.pardus.de>
	<200807241719.37503.bernhard@intevation.de>
Message-ID: <200808040751.23083.ml@radoeka.nl>

Op Thursday 24 July 2008 17:19:30 schreef Bernhard Reiter:
> On Wednesday 16 July 2008 16:40, Gunnar Wrobel wrote:
> > The Kolab concept is based on this annotation support but so far the
> > feature is only being provided by the Cyrus IMAP server. In addition
> > the Kolab Server uses some patches in that area which means that you
> > always need a full Kolab Server as a basis for Kolab specific
> > development.
>
> Note that we are currently looking into what it takes to beef
> up Dovecot to play nicely as IMAP server within a Kolab Server.

Do you mean a full replacement of the cyrus server including acl and 
annotation support?  Would that result in an imap server that does not need 
to be patched.  Currently with cyrus the patch situation is rather hopeless:
http://wiki.kolab.org/index.php/Kolab-major-app-patches#Cyrus_IMAPD
If so (no patches to be applied) I'm very much looking forward to dovecot as 
the imap server for kolab!


-- 
Richard Bos
Without a home the journey is endless


From ml at radoeka.nl  Mon Aug  4 08:17:00 2008
From: ml at radoeka.nl (Richard Bos)
Date: Mon, 4 Aug 2008 08:17:00 +0200
Subject: [Kolab-devel] Kolab-major-app-patches - Kolab wiki
Message-ID: <200808040817.00441.ml@radoeka.nl>

Hi,

this page https://wiki.kolab.org/index.php/Kolab-major-app-patches on the wiki 
shows the status of the patches that are needed for kolab to work correctly. 
Is it however really necessary to keep the patches that are marked "applied" 
and "outdated".  The page becomes clearer when these patches are removed from 
that page.  Perhaps they can be moved to a page that lists the closed patches 
(status "applied" and "outdated"), so the patches are not forgotten.

The patch for e.g. apache1 seems totally redundant as kolab is now using 
apache2.  When the sections about apache and postfix are removed the page is 
already much better.

What's your opinion about this?

-- 
Richard Bos
Without a home the journey is endless


From ml at radoeka.nl  Mon Aug  4 14:41:25 2008
From: ml at radoeka.nl (Richard Bos)
Date: Mon, 4 Aug 2008 14:41:25 +0200
Subject: [Kolab-devel] Dovecot as imap server (was: Kolab on Gmail)
In-Reply-To: <200808040751.23083.ml@radoeka.nl>
References: <87r69tki4b.fsf@home.pardus.de>
	<200807241719.37503.bernhard@intevation.de>
	<200808040751.23083.ml@radoeka.nl>
Message-ID: <200808041441.26121.ml@radoeka.nl>

Op maandag 4 augustus 2008 07:51, schreef Richard Bos:
> Op Thursday 24 July 2008 17:19:30 schreef Bernhard Reiter:
> > On Wednesday 16 July 2008 16:40, Gunnar Wrobel wrote:
> > > The Kolab concept is based on this annotation support but so far the
> > > feature is only being provided by the Cyrus IMAP server. In addition
> > > the Kolab Server uses some patches in that area which means that you
> > > always need a full Kolab Server as a basis for Kolab specific
> > > development.
> >
> > Note that we are currently looking into what it takes to beef
> > up Dovecot to play nicely as IMAP server within a Kolab Server.
>
> Do you mean a full replacement of the cyrus server including acl and
> annotation support? ?Would that result in an imap server that does not need
> to be patched. ?Currently with cyrus the patch situation is rather
> hopeless:
> http://wiki.kolab.org/index.php/Kolab-major-app-patches#Cyrus_IMAPD If so
> (no patches to be applied) I'm very much looking forward to dovecot as the
> imap server for kolab!

Is replication supported?  According this message:
http://www.dovecot.org/list/dovecot/2008-May/030446.html it looks like it is 
being implemented....  Is that sufficient for kolab?

-- 
Richard Bos
Without a home the journey is endless


From wrobel at pardus.de  Tue Aug  5 10:17:12 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Tue, 05 Aug 2008 10:17:12 +0200
Subject: [Kolab-devel] Modifying the LDAP user representation for a
	distributed Kolab server system?
In-Reply-To: <20080801103902.GC5403.thomas@intevation.de> (Thomas Arendsen
	Hein's message of "Fri, 1 Aug 2008 12:39:02 +0200")
References: <871w1drtk6.fsf@home.pardus.de>
	<20080729092316.GB27133.thomas@intevation.de>
	<87wsj5qak7.fsf@home.pardus.de>
	<200807291326.25828.bernhard@intevation.de>
	<87od4grj4a.fsf@home.pardus.de>
	<20080801103902.GC5403.thomas@intevation.de>
Message-ID: <87ljzbkh9z.fsf@home.pardus.de>

Thomas Arendsen Hein <thomas at intevation.de> writes:

> * Gunnar Wrobel <wrobel at pardus.de> [20080729 14:05]:
>> So let me suggest an alternative by using the existing
>> "kolabHomeserver" attribute. Would it be okay to extend its syntax to
>> allow for several settings like:
>> 
>>   "example.org"
>>   "MTA:smtp.example.org"
>>   "IMAP:imap.example.org"
>>   "FreeBusy:fb.example.org"
>> 
>> The default would be the entry without "prefix:" but it would be
>> possible to provide redirects for specific services.
>> 
>> I don't suggest to directly add support for this in the various Kolab
>> services we currently have as I don't see this as urgent. But if we
>> define the syntax this way we could at least start supporting this for
>> the more common splitted Kolab server setups.
>> 
>> If I consider the point Bernhard mentioned recently concerning
>> splitted IMAP storage per user it might also make sense to have a
>> syntax like
>> 
>>   "imap://USER:PASS at SERVER"
>
> Do not make it look like URLs, otherwise you'll get confusion when
> storing URLs, e.g. imap://user:pass at server vs. imaps://user:pass at server
> I'd suggest somethink like IMAP=imap://... if you want to have URLs.

Yup. This was actually a very rough initial idea and I think it
something we probably can't store in kolabHomeserver anyhow. Probably
a topic for Kolab3 stuff.

Cheers,

Gunnar

>
> Thomas
>
> -- 
> thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A
> Intevation GmbH, Osnabrueck - Register: Amtsgericht Osnabrueck, HR B 18998
> Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel

-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   >> Mail at ease - Rent a kolab groupware server at p at rdus <<                 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


From wrobel at pardus.de  Tue Aug  5 10:24:13 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Tue, 05 Aug 2008 10:24:13 +0200
Subject: [Kolab-devel] Modifying the LDAP user representation for
	a	distributed Kolab server system?
In-Reply-To: <488F648B.5000805@infosecurity.ch> (Fabio Pietrosanti's message
	of "Tue, 29 Jul 2008 20:42:19 +0200")
References: <871w1drtk6.fsf@home.pardus.de> <488F648B.5000805@infosecurity.ch>
Message-ID: <87hc9zkgya.fsf@home.pardus.de>

"Fabio Pietrosanti (naif)" <lists at infosecurity.ch> writes:

> Gunnar Wrobel wrote:
>> I'd like to know if people feel it makes sense to allow for such
>> splitted Kolab server setups. As far as I can see this would require
>> additional settings comparable to "kolabHomeserver" in the LDAP schema
>> for a Kolab user. There is already "kolabHomeMTA" in the schema but it
>> is currently unused.
>>   
> Great!
>
> In 2006 in installed a kolab infrastructure of more than 16 hosts and 
> was quite difficult to have all the different components separated.
>
> That's a great idea, it can make Kolab very useful for enterprise 
> deployments drammatically reducing the TCO of the infrastructure project 
> buildup and maintenance.
>
>
> Even if could be more difficult from a design point of view, it could be 
> even really cool to introduce the splitting of the data available inside 
> the ldap directory.
>
> For example keeping the passwords outside the slave ldap servers in 
> order to save the security of the system (avoid that a single server in 
> branch office, with a local compromise with offline data recovery 
> causing a strong data loss) could cause the failure of the security of 
> the whole identification infrastructure.
>
> A cool approach could be to use LDAP referral for the password field:
> http://www.openldap.org/doc/admin24/referrals.html
>
> What do you think about it?

Certainly useful. I guess you'd need to have a large amount of users
to make a splitted LDAP system necessary. I think distributing the
Kolab server would be the first level and splitting a distributed
system into different subnets would then be a second level.

Cheers,

Gunnar

>
> Regards
> Fabio
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel

-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   >> Mail at ease - Rent a kolab groupware server at p at rdus <<                 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


From wrobel at pardus.de  Tue Aug  5 11:29:03 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Tue, 05 Aug 2008 11:29:03 +0200
Subject: [Kolab-devel] Kolab on Gmail
In-Reply-To: <200808032356.58719.ml@radoeka.nl> (Richard Bos's message of "Sun,
	3 Aug 2008 23:56:58 +0200")
References: <87r69tki4b.fsf@home.pardus.de>
	<200807241719.37503.bernhard@intevation.de>
	<87tze9rzza.fsf@home.pardus.de> <200808032356.58719.ml@radoeka.nl>
Message-ID: <877iavizds.fsf@rdus.de>

Richard Bos <ml at radoeka.nl> writes:

> Op Tuesday 29 July 2008 08:00:57 schreef Gunnar Wrobel:
>> For general acceptance of the annotation extension the following draft
>> also needs to be accepted by IETF:
>>
>> http://ietfreport.isoc.org/all-ids/draft-daboo-imap-annotatemore-14.txt
>>
>> This is progressing but it seems to take years. Last time I asked for
>> annotation support in c-client Mark Crispin said that he would only
>> consider that if the draft has become a RFC. Even then he didn't sound
>> too positive about it as he seemed unhappy with the draft. Now that he
>> has been laid off I don't know if our chances of getting wider
>> annotation support are higher or lower. c-client seems kind of
>> unmaintained at the moment.
>
> Should this information be stored at 
> http://wiki.kolab.org/index.php/Kolab-major-app-patches#UW_IMAP_c-client ?

As far as I can tell all the required information is already available
there. The link to the merge issue is there and the merge issue links
to the mailing list thread. The status of the draft can be checked by
anybody.

> Is there an alternative by for example using a different library?

Not really as c-client provides the IMAP functionality within PHP and
we actually patch c-client because of PHP. You can always use the
Net_IMAP PEAR package but that is a PHP implementation and
significantly slower.

Cheers,

Gunnar

>
> -- 
> Richard Bos
> We are borrowing the world of our children,
> It is not inherited from our parents.
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel

-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   >> Mail at ease - Rent a kolab groupware server at p at rdus <<                 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


From wrobel at pardus.de  Tue Aug  5 11:32:14 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Tue, 05 Aug 2008 11:32:14 +0200
Subject: [Kolab-devel] Dovecot as imap server
In-Reply-To: <200808040751.23083.ml@radoeka.nl> (Richard Bos's message of "Mon,
	4 Aug 2008 07:51:22 +0200")
References: <87r69tki4b.fsf@home.pardus.de>
	<200807241719.37503.bernhard@intevation.de>
	<200808040751.23083.ml@radoeka.nl>
Message-ID: <873aljiz8h.fsf@rdus.de>

Richard Bos <ml at radoeka.nl> writes:

> Op Thursday 24 July 2008 17:19:30 schreef Bernhard Reiter:
>> On Wednesday 16 July 2008 16:40, Gunnar Wrobel wrote:
>> > The Kolab concept is based on this annotation support but so far the
>> > feature is only being provided by the Cyrus IMAP server. In addition
>> > the Kolab Server uses some patches in that area which means that you
>> > always need a full Kolab Server as a basis for Kolab specific
>> > development.
>>
>> Note that we are currently looking into what it takes to beef
>> up Dovecot to play nicely as IMAP server within a Kolab Server.
>
> Do you mean a full replacement of the cyrus server including acl and 
> annotation support?  Would that result in an imap server that does not need 
> to be patched.  Currently with cyrus the patch situation is rather hopeless:
> http://wiki.kolab.org/index.php/Kolab-major-app-patches#Cyrus_IMAPD
> If so (no patches to be applied) I'm very much looking forward to dovecot as 
> the imap server for kolab!

Dovecot does look more open to external patches than Cyrus IMAP to
me. But that is just a general observation and not based on actual
experience with Dovecot. Dovecot development seems to be rather active
so the chance of getting Kolab specific stuff in there are probably
higher.

I wouldn't be too optimistic about this yet. As far as I know Dovecot
lacks a few central features that Cyrus provides which are part of the
core Kolab Server functionality (which is the reason why we use
Cyrus). Implementing this in Dovecot will probably not be done in a
few weeks. 

Cheers,

Gunnar

>
>
> -- 
> Richard Bos
> Without a home the journey is endless
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel

-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   >> Mail at ease - Rent a kolab groupware server at p at rdus <<                 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


From wrobel at pardus.de  Tue Aug  5 11:32:32 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Tue, 05 Aug 2008 11:32:32 +0200
Subject: [Kolab-devel] Kolab-major-app-patches - Kolab wiki
In-Reply-To: <200808040817.00441.ml@radoeka.nl> (Richard Bos's message of "Mon,
	4 Aug 2008 08:17:00 +0200")
References: <200808040817.00441.ml@radoeka.nl>
Message-ID: <87y73bhknj.fsf@rdus.de>

Richard Bos <ml at radoeka.nl> writes:

> Hi,
>
> this page https://wiki.kolab.org/index.php/Kolab-major-app-patches on the wiki 
> shows the status of the patches that are needed for kolab to work correctly. 
> Is it however really necessary to keep the patches that are marked "applied" 
> and "outdated".  The page becomes clearer when these patches are removed from 
> that page.  Perhaps they can be moved to a page that lists the closed patches 
> (status "applied" and "outdated"), so the patches are not forgotten.
>
> The patch for e.g. apache1 seems totally redundant as kolab is now using 
> apache2.  When the sections about apache and postfix are removed the page is 
> already much better.
>
> What's your opinion about this?

Fine with me.

Cheers,

Gunnar

>
> -- 
> Richard Bos
> Without a home the journey is endless
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel

-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   >> Mail at ease - Rent a kolab groupware server at p at rdus <<                 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


From wrobel at pardus.de  Tue Aug  5 11:39:33 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Tue, 05 Aug 2008 11:39:33 +0200
Subject: [Kolab-devel] Dovecot as imap server
In-Reply-To: <200808041441.26121.ml@radoeka.nl> (Richard Bos's message of "Mon,
	4 Aug 2008 14:41:25 +0200")
References: <87r69tki4b.fsf@home.pardus.de>
	<200807241719.37503.bernhard@intevation.de>
	<200808040751.23083.ml@radoeka.nl> <200808041441.26121.ml@radoeka.nl>
Message-ID: <87sktjhkbu.fsf@rdus.de>

Richard Bos <ml at radoeka.nl> writes:

> Op maandag 4 augustus 2008 07:51, schreef Richard Bos:
>> Op Thursday 24 July 2008 17:19:30 schreef Bernhard Reiter:
>> > On Wednesday 16 July 2008 16:40, Gunnar Wrobel wrote:
>> > > The Kolab concept is based on this annotation support but so far the
>> > > feature is only being provided by the Cyrus IMAP server. In addition
>> > > the Kolab Server uses some patches in that area which means that you
>> > > always need a full Kolab Server as a basis for Kolab specific
>> > > development.
>> >
>> > Note that we are currently looking into what it takes to beef
>> > up Dovecot to play nicely as IMAP server within a Kolab Server.
>>
>> Do you mean a full replacement of the cyrus server including acl and
>> annotation support? ?Would that result in an imap server that does not need
>> to be patched. ?Currently with cyrus the patch situation is rather
>> hopeless:
>> http://wiki.kolab.org/index.php/Kolab-major-app-patches#Cyrus_IMAPD If so
>> (no patches to be applied) I'm very much looking forward to dovecot as the
>> imap server for kolab!
>
> Is replication supported?  According this message:
> http://www.dovecot.org/list/dovecot/2008-May/030446.html it looks like it is 
> being implemented....  Is that sufficient for kolab?

I'm not aware that we'd be using replication with the Cyrus server at
the moment. At least not by default.

Cheers,

Gunnar

>
> -- 
> Richard Bos
> Without a home the journey is endless
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel

-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   >> Mail at ease - Rent a kolab groupware server at p at rdus <<                 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


From wrobel at pardus.de  Tue Aug  5 11:45:06 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Tue, 05 Aug 2008 11:45:06 +0200
Subject: [Kolab-devel] wilde: server/php-kolab/Kolab_Filter AUTHORS, 1.3,
	1.4 ChangeLog, 1.19, 1.20 package.xml.in, 1.7, 1.8
In-Reply-To: <200808040001.08200.richard@radoeka.nl> (Richard Bos's message of
	"Mon, 4 Aug 2008 00:01:07 +0200")
References: <20080801105451.3F9BB600BB1@lists.intevation.de>
	<200808040001.08200.richard@radoeka.nl>
Message-ID: <87od47hk2l.fsf@rdus.de>

Richard Bos <richard at radoeka.nl> writes:

> Op Friday 01 August 2008 12:54:51 schreef cvs at kolab.org:
>> +???????* Filter/DovecotLDA.php: New file: simple Dovecot LDA backend with
>> +???????API similar to Net_LMTP, so it can be used as drop-in replacement.
>
> How does one choose between Dovecot and Net_LMTP?  Is that automatic or should 
> it be configured  manually?  If the latter where is that done?

http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/php-kolab/Kolab_Filter/Filter/Incoming.php.diff?r1=1.9&r2=1.10

Cheers,

Gunnar

>
> -- 
> Richard Bos
> We are borrowing the world of our children,
> It is not inherited from our parents.
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel

-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   >> Mail at ease - Rent a kolab groupware server at p at rdus <<                 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


From ml at radoeka.nl  Tue Aug  5 12:16:31 2008
From: ml at radoeka.nl (Richard Bos)
Date: Tue, 5 Aug 2008 12:16:31 +0200
Subject: [Kolab-devel] Dovecot as imap server
In-Reply-To: <87sktjhkbu.fsf@rdus.de>
References: <87r69tki4b.fsf@home.pardus.de> <200808041441.26121.ml@radoeka.nl>
	<87sktjhkbu.fsf@rdus.de>
Message-ID: <200808051216.32104.ml@radoeka.nl>

Op Tuesday 05 August 2008 11:39:33 schreef Gunnar Wrobel:
> > Is replication supported? ?According this message:
> > http://www.dovecot.org/list/dovecot/2008-May/030446.html it looks like it
> > is being implemented.... ?Is that sufficient for kolab?
>
> I'm not aware that we'd be using replication with the Cyrus server at
> the moment. At least not by default.

Slurpd is started by default and isn't slurpd the replication daemon?  I 
thought it was used to communicate the configuration changes to the kolabd 
daemon that will instruct the cyrus to create the mailboxes.

-- 
Richard Bos
Without a home the journey is endless


From wrobel at pardus.de  Tue Aug  5 12:23:01 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Tue, 05 Aug 2008 12:23:01 +0200
Subject: [Kolab-devel] Dovecot as imap server
In-Reply-To: <200808051216.32104.ml@radoeka.nl> (Richard Bos's message of "Tue,
	5 Aug 2008 12:16:31 +0200")
References: <87r69tki4b.fsf@home.pardus.de> <200808041441.26121.ml@radoeka.nl>
	<87sktjhkbu.fsf@rdus.de> <200808051216.32104.ml@radoeka.nl>
Message-ID: <87zlnriwvu.fsf@home.pardus.de>

Richard Bos <ml at radoeka.nl> writes:

> Op Tuesday 05 August 2008 11:39:33 schreef Gunnar Wrobel:
>> > Is replication supported? ?According this message:
>> > http://www.dovecot.org/list/dovecot/2008-May/030446.html it looks like it
>> > is being implemented.... ?Is that sufficient for kolab?
>>
>> I'm not aware that we'd be using replication with the Cyrus server at
>> the moment. At least not by default.
>
> Slurpd is started by default and isn't slurpd the replication daemon?

Now you are confused :) slurpd replicates the LDAP data (the
configurtion data), not IMAP data.

Cheers,

Gunnar

> I thought it was used to communicate the configuration changes to
> the kolabd daemon that will instruct the cyrus to create the
> mailboxes.
>
> -- 
> Richard Bos
> Without a home the journey is endless
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel

-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   >> Mail at ease - Rent a kolab groupware server at p at rdus <<                 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


From ml at radoeka.nl  Tue Aug  5 12:40:51 2008
From: ml at radoeka.nl (Richard Bos)
Date: Tue, 5 Aug 2008 12:40:51 +0200
Subject: [Kolab-devel] Dovecot as imap server
In-Reply-To: <87zlnriwvu.fsf@home.pardus.de>
References: <87r69tki4b.fsf@home.pardus.de> <200808051216.32104.ml@radoeka.nl>
	<87zlnriwvu.fsf@home.pardus.de>
Message-ID: <200808051240.51416.ml@radoeka.nl>

Op Tuesday 05 August 2008 12:23:01 schreef Gunnar Wrobel:
> Now you are confused :)

Indeed very confused. Sorry.

-- 
Richard Bos
Without a home the journey is endless


From kolab-issues at intevation.de  Tue Aug  5 15:48:00 2008
From: kolab-issues at intevation.de (Jens Kleikamp)
Date: Tue, 05 Aug 2008 13:48:00 +0000
Subject: [Kolab-devel] [issue2961] Postfix - received headers - auth token
Message-ID: <1217944080.39.0.185633617126.issue2961@intevation.de>


New submission from Jens Kleikamp <jens at codes-concepts.de>:

Hello,

this issue is about the problem when an user who is on a dynamic IP and send
mail with kolab over an authentifcated smtp session. Then SA tags the mail
because of the dynamic IP. SA don?t know that the smtp session of the user was
authenticated.

The Kolab wiki helps with information about the following postfix directive.

smtpd_sasl_authenticated_header = yes

So that the mailheader get an auth token and SA ignore this header for DNS checks.


Would it make sense to put this directive in cvs for future releases?

sorry for bad english

Kind Regards
Jens

----------
assignedto: thomas
messages: 16044
nosy: bernhard, jens, martin, thomas, till, wilde, wrobel
status: unread
title: Postfix - received headers - auth token
topic: server
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue2961>
___________________________________________________


From liste at gelpi.it  Tue Aug  5 18:12:07 2008
From: liste at gelpi.it (Gelpi Andrea)
Date: Tue, 05 Aug 2008 18:12:07 +0200
Subject: [Kolab-devel] Horde - How to personalize po files
Message-ID: <48987BD7.6020400@gelpi.it>

HI,
	I try to personalize it_IT.po in horde.

In horde/po dir there is a README and translation.php

If I understand correct I have to do:

1) Modify it_IT.po file
2) run translation.php make -l it_IT

But the last command don't find gettext.

mail1:/kolab/var/kolab/www/horde/po# ./translation.php make -l it_IT
---------------------------
Horde translation generator
---------------------------
Loading libraries...
Console_Getopt... OK
Console_Table... OK
File_Find... OK

Searching gettext binaries...
gettext... not found




As written in README I first run:

/koab/bin/pear Console_Table File_Find (translation.php says they were missing)

A check with openpkg says that gettext is in /kolab/bin

What can I check?

I write here because I suspect a configuration problem with PEAR

-- 
ing. Andrea Gelpi
***************************************************
La Terra non la abbiamo ereditata dai nostri avi,
ma la abbiamo presa in prestito dai nostri bambini.
***************************************************


From kolab-issues at intevation.de  Thu Aug  7 11:45:37 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Thu, 07 Aug 2008 09:45:37 +0000
Subject: [Kolab-devel] [issue2962] Composer text snippets: Add/Edit group,
	snippet text "GROUP"  is not translated into German.
Message-ID: <1218102337.17.0.288521480315.issue2962@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

enterprise35 kdepim 20080801.840707
             kde-i18n 20080801.840686

Test:
Use German as language.
1. Switch to kmail.
2. Start to create a new mail.
3. Activate text snippets with View->Snippets.
4. RMB on the snippet window and select "Add group".
In the snippet textfield is "GROUP" instead of the German "GRUPPE".

----------
assignedto: till
messages: 16129
nosy: bh, ludwig, osterfeld, pradeepto, till, vkrause
priority: minor bug
status: unread
title: Composer text snippets: Add/Edit group, snippet text "GROUP"  is not translated into German.
topic: kde client, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue2962>
___________________________________________________


From kolab-issues at intevation.de  Thu Aug  7 13:16:29 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Thu, 07 Aug 2008 11:16:29 +0000
Subject: [Kolab-devel] [issue2963] Crash in KMMoveCommand::execute
Message-ID: <1218107789.7.0.0624024174249.issue2963@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

enterprise 20080602.814375

A customer reported this crash:
After changing an account to mixed mode he found double mails in his inbox.
He selected both mails and one of the mails was empty. While deleting the empty
mail kontact crashs. (See bt.) 

I couldn't reproduce it and I think it is an old bug, but I haven't found it in
the bugtracker.

Till, can you have a look at it?

----------
assignedto: till
files: ghostmessage.kontact.kcrash
messages: 16132
nosy: bh, ludwig, osterfeld, pradeepto, till, vkrause
priority: critical
status: unread
title: Crash in KMMoveCommand::execute
topic: kde client, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue2963>
___________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ghostmessage.kontact.kcrash
Type: application/octet-stream
Size: 3795 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20080807/55aaa9d1/ghostmessage.kontact.exe

From kolab-issues at intevation.de  Thu Aug  7 13:28:42 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Thu, 07 Aug 2008 11:28:42 +0000
Subject: [Kolab-devel] [issue2964] Crash in KMMessage::setTransferInProgress
Message-ID: <1218108522.6.0.149851751011.issue2964@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

enterprise35 20080602.814375

A customer reproted a crash:
He changed his account type to mixed mode and wanted to configure 
the Account/Receiving , while kontact was syncing.
Then kontact crashed (See the backtrace.)

I couldn't reproduce this bug.

----------
assignedto: till
files: kontact-20080830.kcrash
messages: 16133
nosy: bh, ludwig, osterfeld, pradeepto, till, vkrause
priority: urgent
status: unread
title: Crash in KMMessage::setTransferInProgress
topic: kde client, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue2964>
___________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kontact-20080830.kcrash
Type: application/octet-stream
Size: 5775 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20080807/f47d1089/kontact-20080830.exe

From kolab-issues at intevation.de  Thu Aug  7 14:42:20 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Thu, 07 Aug 2008 12:42:20 +0000
Subject: [Kolab-devel] [issue2965] Sometimes clicking on calendar in the
	Mail part closes horde session
Message-ID: <1218112940.7.0.310801870931.issue2965@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

Horde 3.2-RC2.

A user uses horde on a fresh account. Then used the account with kontact and
outlook. After that he started horde again. If he then clicked on the calendar
in the Webmail, horde closed the session.

----------
assignedto: wrobel
messages: 16134
nosy: bernhard, ludwig, wrobel
priority: bug
status: unread
title: Sometimes clicking on calendar in the Mail part closes horde session
topic: horde
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue2965>
___________________________________________________


From kolab-issues at intevation.de  Thu Aug  7 14:45:55 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Thu, 07 Aug 2008 12:45:55 +0000
Subject: [Kolab-devel] [issue2966] A created/edited event doesn't send mails
	to all attendee as default.
Message-ID: <1218113154.92.0.0942829234433.issue2966@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

Horde 3.2-RC2.

If a user wants to create an event with another attendee, he needs to check a
"send to attendee" checkbox. This checkbox should be set as default.

----------
assignedto: wrobel
messages: 16135
nosy: bernhard, ludwig, wrobel
priority: bug
status: unread
title: A created/edited event doesn't send mails to all attendee as default.
topic: horde
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue2966>
___________________________________________________


From kolab-issues at intevation.de  Thu Aug  7 14:48:02 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Thu, 07 Aug 2008 12:48:02 +0000
Subject: [Kolab-devel] [issue2967] Mail part should have a sent mails folder.
Message-ID: <1218113282.44.0.368023063416.issue2967@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

Horde 3.2-RC2.

The mail part should have a sent mail folder, which includes all sent mails.

----------
assignedto: wrobel
messages: 16136
nosy: bernhard, ludwig, wrobel
priority: bug
status: unread
title: Mail part should have a sent mails folder.
topic: horde
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue2967>
___________________________________________________


From kolab-issues at intevation.de  Thu Aug  7 14:55:27 2008
From: kolab-issues at intevation.de (Andy Kopciuch)
Date: Thu, 07 Aug 2008 12:55:27 +0000
Subject: [Kolab-devel] [issue2968] Link to webmail on administration login
	page
Message-ID: <1218113727.38.0.292903011436.issue2968@intevation.de>


New submission from Andy Kopciuch <akopciuch at bddf.ca>:

With the webmail being integrated into Kolab as of 2.2 it would be nice to 
have a link on the administration login page to the webmail.  People tend to 
setup their server mail.domain.com, and typing that in a web browser takes 
them to the Kolab server, when what they really want is webmail.

It's simple enough to place a link to href="/horde/" somewhere on the main 
page.

----------
messages: 16137
nosy: akopciuch
priority: feature
status: unread
title: Link to webmail on administration login page
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue2968>
___________________________________________________


From kolab-issues at intevation.de  Fri Aug  8 11:30:08 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Fri, 08 Aug 2008 09:30:08 +0000
Subject: [Kolab-devel] [issue2969] Save OpenPGP encrypted mails unencrypted
	after reading them.
Message-ID: <1218187808.3.0.841490488779.issue2969@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

tested with enterprise rev. 20080602.814375

It is not possible for a user to save an OpenPGP encrypted mails unencrypted.
Adding the line 
store-displayed-messages-unencrypted=true
to kmailrc doesn't work.

----------
assignedto: till
messages: 16149
nosy: bh, ludwig, osterfeld, pradeepto, till, vkrause
priority: wish
status: unread
title: Save OpenPGP encrypted mails unencrypted after reading them.
topic: enterprise35, kde client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue2969>
___________________________________________________


From thomas at intevation.de  Mon Aug 11 15:58:55 2008
From: thomas at intevation.de (Thomas Arendsen Hein)
Date: Mon, 11 Aug 2008 15:58:55 +0200
Subject: [Kolab-devel] gunnar: server/kolab-webclient - New directory
In-Reply-To: <20080811093553.49EED600170@lists.intevation.de>
References: <20080811093553.49EED600170@lists.intevation.de>
Message-ID: <20080811135855.GJ20888.thomas@intevation.de>

Hallo Gunnar!

* cvs at kolab.org <cvs at kolab.org> [20080811 11:35]:
> Author: gunnar
> 
> Update of /kolabrepository/server/kolab-webclient
> In directory doto:/tmp/cvs-serv4012/kolab-webclient
> 
> Log Message:
> Directory /kolabrepository/server/kolab-webclient added to the repository

Why did you add that?

Thomas

-- 
thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A
Intevation GmbH, Osnabrueck - Register: Amtsgericht Osnabrueck, HR B 18998
Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner


From wrobel at pardus.de  Mon Aug 11 17:12:07 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Mon, 11 Aug 2008 17:12:07 +0200
Subject: [Kolab-devel] gunnar: server/kolab-webclient - New directory
In-Reply-To: <20080811135855.GJ20888.thomas@intevation.de>
References: <20080811093553.49EED600170@lists.intevation.de>
	<20080811135855.GJ20888.thomas@intevation.de>
Message-ID: <20080811171207.18552llqrjj2vh6o@webmail2.pardus.de>

Quoting "Thomas Arendsen Hein" <thomas at intevation.de>:

> Hallo Gunnar!
>
> * cvs at kolab.org <cvs at kolab.org> [20080811 11:35]:
>> Author: gunnar
>>
>> Update of /kolabrepository/server/kolab-webclient
>> In directory doto:/tmp/cvs-serv4012/kolab-webclient
>>
>> Log Message:
>> Directory /kolabrepository/server/kolab-webclient added to the repository
>
> Why did you add that?

I'm currently preparing the next round of horde updates to move  
towards Kolab Server 2.2.1.

I did ponder the best way of maintaining the Kolab patch queue for  
Horde release packages last week. I did initially add the Horde  
packages as splitted packages under "/server/horde".

In principle I still believe this is the right way of doing things.  
One package, one spec file and a decent definition of dependencies.

PHP applications have had a history of neglecting the common (and  
sane) concept of programming libraries. Instead many apps simply  
"bundle" the required libraries to be installed into the webservers  
document root. I think we know the drawbacks of such an approach  
pretty well (security, maintainability).

Horde has a splitted approach of releasing packages which is not  
totally consistent. All the applications are being released as single  
packages. But the framework packages are all PEAR packages that should  
be released as single modules or packages, too. Instead they are  
bundled with the base horde-package and the user is expected to  
install the libraries into the web root.

I did correct that for the package definitions in "/server/horde" and  
this is why we have "/server/horde/horde-framework-kolab" and  
"/server/horde/horde/".

But Horde also distributes larger monolithic packages that combine all  
the common applications such as imp, kronolith, turba, nag and so on.  
In addition these packages contain all required PEAR packages to run  
Horde. I guess many users prefer these types of packages because they  
just untar them into the document root of the web server and are up  
and running.

While this is not really the best thing to do security-wise and  
restricts the user as well as maintenance, I'm still in favor of  
moving the OpenPKG packages (as well as the Gentoo packages btw - and  
it does hurt me more there) to the monolithic horde release.

This has one significant advantage over the splitted packages: We can  
provide a single kolab-specific patch that can be applied to the  
horde-webmail package instead of having more than ten different  
patches for the different applications.

And since I trust Horde to handle security well enough I think the  
single monolithic approach is the easier approach at the moment. It  
hopefully makes it clearer what we are doing there.

Of course the single patches are still available at my patch queue  
(http://hg.pardus.de/cgi-bin/hg.cgi/horde/HORDE/file/tip/series - the  
release patches are guarded with "release"). So I don't think we loose  
anything.

Do people agree?

Cheers,

Gunnar

>
> Thomas
>
> --
> thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key:  
> 0x5816791A
> Intevation GmbH, Osnabrueck - Register: Amtsgericht Osnabrueck, HR B 18998
> Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-keys
Size: 2803 bytes
Desc: =?iso-8859-1?b?1mZmZW50bGljaGVyIA==?=
	=?iso-8859-1?b?UEdQLVNjaGz8c3NlbA==?=
Url : http://kolab.org/pipermail/kolab-devel/attachments/20080811/f822b4e6/attachment.bin

From kolab-issues at intevation.de  Mon Aug 11 17:36:07 2008
From: kolab-issues at intevation.de (Valentin Steffen-Munsberg)
Date: Mon, 11 Aug 2008 15:36:07 +0000
Subject: [Kolab-devel] [issue2971] horde external install script -> include
	dead links
Message-ID: <1218468967.28.0.43664903515.issue2971@intevation.de>


New submission from Valentin Steffen-Munsberg <v.steffen-munsberg at dmmd.de>:

please cange/modify the horde external install script

http://kolab.org/cgi-bin/viewcvs-kolab.cgi/*checkout*/server/horde/external-horde.sh

Thx.

lg Vale

----------
messages: 16164
nosy: nivadis
priority: critical
status: unread
title: horde external install script -> include dead links
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue2971>
___________________________________________________


From kolab-issues at intevation.de  Mon Aug 11 18:41:14 2008
From: kolab-issues at intevation.de (Thomas Arendsen Hein)
Date: Mon, 11 Aug 2008 16:41:14 +0000
Subject: [Kolab-devel] [issue2972] Crash after manually removing dmap cache
	and using "Refresh Cache"
Message-ID: <1218472874.84.0.371778641101.issue2972@intevation.de>


New submission from Thomas Arendsen Hein <thomas at intevation.de>:

Kontact Version 1.2.9 (enterprise35 20080725.837785)

I manually removed all (including hidden) files/directories below
share/apps/kmail/dimap/, then started kontact.
Now I chose Troubleshoot IMAP Cache -> Refresh Cache.
It asked me if it should create the groupware folders (which exist on the
server!) or not (in which case it would disable IMAP resources!?), so I selected
the first (Continue) button.

After that kontact crashed with the backtrace below and kept crashing until I
removed all files/directories below dimap again. Using "Check Mail In" instead
of Refresh Cache seems to work.

Using host libthread_db library "/lib/tls/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread -1242339648 (LWP 22350)]
[New Thread -1284342864 (LWP 22356)]
[New Thread -1275954256 (LWP 22355)]
[New Thread -1267565648 (LWP 22354)]
[New Thread -1259177040 (LWP 22353)]
[KCrash handler]
#5  0xb547866d in subresourceLabelForPresentation (folder=0x85c0310)
    at kmailicalifaceimpl.cpp:684
#6  0xb54797bc in KMailICalIfaceImpl::folderContentsTypeChanged (
    this=0x8281828, folder=0x85c0310, 
    contentsType=KMail::ContentsTypeCalendar) at kmailicalifaceimpl.cpp:1436
#7  0xb52d43ca in KMFolder::slotContentsTypeChanged (this=0x85c0310, 
    type=KMail::ContentsTypeCalendar) at kmfolder.cpp:867
#8  0xb52d44a6 in KMFolder::qt_invoke (this=0x85c0310, _id=5, _o=0xbff87194)
    at kmfolder.moc:392
#9  0xb7041d4f in QObject::activate_signal (this=0x85f68b0, clist=0x85bda78, 
    o=0xbff87194) at kernel/qobject.cpp:2356
#10 0xb52f1607 in FolderStorage::contentsTypeChanged (this=0x85f68b0, 
    t0=KMail::ContentsTypeCalendar) at folderstorage.moc:299
#11 0xb52f165c in FolderStorage::setContentsType (this=0x859cb00, 
    type=KMail::ContentsTypeMail, quiet=12) at folderstorage.cpp:1108
#12 0xb5479fcb in KMailICalIfaceImpl::initFolder (this=0x8281828, 
    contentsType=KMail::ContentsTypeCalendar) at kmailicalifaceimpl.cpp:1972
#13 0xb547a8e8 in KMailICalIfaceImpl::readConfig (this=0x8281828)
    at kmailicalifaceimpl.cpp:1776
#14 0xb547c7b4 in KMailICalIfaceImpl::slotCheckDone (this=0x8281828)
    at kmailicalifaceimpl.cpp:1920
#15 0xb54803b6 in KMailICalIfaceImpl::qt_invoke (this=0x8281828, _id=9, 
    _o=0xbff87710) at kmailicalifaceimpl.moc:138
#16 0xb7041e7c in QObject::activate_signal (this=0x82b47b0, clist=0x82bf500, 
    o=0xbff87710) at kernel/qobject.cpp:2380
#17 0xb528aa14 in KMAccount::finishedCheck (this=0x82b47b0, t0=false, 
    t1=KMAccount::CheckOK) at kmaccount.moc:218
#18 0xb5288c89 in KMAccount::checkDone (this=0x82b47b0, newmail=false, 
    status=KMAccount::CheckOK) at kmaccount.cpp:489
#19 0xb53606cb in KMail::ImapAccountBase::postProcessNewMail (this=0x82b47b0, 
    showStatusMsg=true) at imapaccountbase.cpp:352
#20 0xb536e33a in KMAcctCachedImap::postProcessNewMail (this=0x82b47b0, 
    folder=0x82bce70) at kmacctcachedimap.cpp:289
#21 0xb536e3e9 in KMAcctCachedImap::qt_invoke (this=0x82b47b0, _id=21, 
    _o=0xbff87890) at kmacctcachedimap.moc:93
#22 0xb7041d4f in QObject::activate_signal (this=0x82bce70, clist=0x85ad6e8, 
    o=0xbff87890) at kernel/qobject.cpp:2356
#23 0xb538a1a4 in KMFolderCachedImap::folderComplete (this=0x82bce70, 
    t0=0x82bce70, t1=true) at kmfoldercachedimap.moc:361
#24 0xb5390647 in KMFolderCachedImap::serverSyncInternal (this=0x82bce70)
    at kmfoldercachedimap.cpp:1273
#25 0xb5395327 in KMFolderCachedImap::slotCheckNamespace (this=0x82bce70, 
    subfolderNames=@0x85c7830, subfolderPaths=@0x85c7834, 
    subfolderMimeTypes=@0x85c7838, subfolderAttributes=@0x85c783c, 
    jobData=@0x85bead8) at kmfoldercachedimap.cpp:1967
#26 0xb53995ca in KMFolderCachedImap::qt_invoke (this=0x82bce70, _id=36, 
    _o=0xbff87d14) at kmfoldercachedimap.moc:420
#27 0xb7041d4f in QObject::activate_signal (this=0x85c77b8, clist=0x85921b0, 
    o=0xbff87d14) at kernel/qobject.cpp:2356
#28 0xb52a6a0e in KMail::ListJob::receivedFolders (this=0x85c77b8, 
    t0=@0x85c7830, t1=@0x85c7834, t2=@0x85c7838, t3=@0x85c783c, t4=@0x85bead8)
    at listjob.moc:122
#29 0xb52a71ef in KMail::ListJob::slotListResult (this=0x85c77b8, 
    job=0x85b1c18) at listjob.cpp:183
#30 0xb52a7379 in KMail::ListJob::qt_invoke (this=0x85c77b8, _id=2, 
    _o=0xbff87e74) at listjob.moc:128
#31 0xb7041d4f in QObject::activate_signal (this=0x85b1c18, clist=0x85be980, 
    o=0xbff87e74) at kernel/qobject.cpp:2356
#32 0xb6b231ee in KIO::Job::result (this=0x85b1c18, t0=0x85b1c18)
    at ./jobclasses.moc:162
#33 0xb6b631dc in KIO::Job::emitResult (this=0x85b1c18)
    at /build/buildd/kdelibs-3.5.5a.dfsg.1/./kio/kio/job.cpp:226
#34 0xb6b76ebe in KIO::SimpleJob::slotFinished (this=0x85b1c18)
    at /build/buildd/kdelibs-3.5.5a.dfsg.1/./kio/kio/job.cpp:574
#35 0xb6b7724d in KIO::ListJob::slotFinished (this=0x85b1c18)
    at /build/buildd/kdelibs-3.5.5a.dfsg.1/./kio/kio/job.cpp:2095
#36 0xb6b8552e in KIO::ListJob::qt_invoke (this=0x85b1c18, _id=16, 
    _o=0xbff8812c) at ./jobclasses.moc:1734
#37 0xb7041d4f in QObject::activate_signal (this=0x8561720, clist=0x85bff90, 
    o=0xbff8812c) at kernel/qobject.cpp:2356
#38 0xb70427e0 in QObject::activate_signal (this=0x8561720, signal=6)
    at kernel/qobject.cpp:2325
#39 0xb6b1da8c in KIO::SlaveInterface::finished (this=0x8561720)
    at ./slaveinterface.moc:226
#40 0xb6b82e93 in KIO::SlaveInterface::dispatch (this=0x8561720, _cmd=104, 
    rawdata=@0xbff88340)
    at /build/buildd/kdelibs-3.5.5a.dfsg.1/./kio/kio/slaveinterface.cpp:243
#41 0xb6b80ed8 in KIO::SlaveInterface::dispatch (this=0x8561720)
    at /build/buildd/kdelibs-3.5.5a.dfsg.1/./kio/kio/slaveinterface.cpp:173
#42 0xb6b31fab in KIO::Slave::gotInput (this=0x8561720)
    at /build/buildd/kdelibs-3.5.5a.dfsg.1/./kio/kio/slave.cpp:300
#43 0xb6b70a60 in KIO::Slave::qt_invoke (this=0x8561720, _id=4, _o=0xbff88468)
    at ./slave.moc:113
#44 0xb7041d4f in QObject::activate_signal (this=0x85af028, clist=0x8565bc0, 
    o=0xbff88468) at kernel/qobject.cpp:2356
#45 0xb7042656 in QObject::activate_signal (this=0x85af028, signal=2, 
    param=25) at kernel/qobject.cpp:2449
#46 0xb73cb957 in QSocketNotifier::activated (this=0x85af028, t0=25)
    at .moc/debug-shared-mt/moc_qsocketnotifier.cpp:85
#47 0xb70644fa in QSocketNotifier::event (this=0x85af028, e=0xbff887c0)
    at kernel/qsocketnotifier.cpp:258
#48 0xb6fd9c26 in QApplication::internalNotify (this=0xbff88a3c, 
    receiver=0x85af028, e=0xbff887c0) at kernel/qapplication.cpp:2635
#49 0xb6fdba43 in QApplication::notify (this=0xbff88a3c, receiver=0x85af028, 
    e=0xbff887c0) at kernel/qapplication.cpp:2358
#50 0xb7701e0e in KApplication::notify (this=0xbff88a3c, receiver=0x85af028, 
    event=0xbff887c0)
    at /build/buildd/kdelibs-3.5.5a.dfsg.1/./kdecore/kapplication.cpp:550
#51 0xb6f6d421 in QApplication::sendEvent (receiver=0x85af028, 
    event=0xbff887c0) at ../include/qapplication.h:520
#52 0xb6fcbfd9 in QEventLoop::activateSocketNotifiers (this=0x80ac660)
    at kernel/qeventloop_unix.cpp:578
#53 0xb6f81754 in QEventLoop::processEvents (this=0x80ac660, flags=4)
    at kernel/qeventloop_x11.cpp:383
#54 0xb6ff4179 in QEventLoop::enterLoop (this=0x80ac660)
    at kernel/qeventloop.cpp:198
#55 0xb6ff3f9a in QEventLoop::exec (this=0x80ac660)
    at kernel/qeventloop.cpp:145
#56 0xb6fdb7bf in QApplication::exec (this=0xbff88a3c)
    at kernel/qapplication.cpp:2758
#57 0x0805e324 in main (argc=-8804383, argv=0x19) at main.cpp:188
#58 0xb7797ea8 in __libc_start_main () from /lib/tls/libc.so.6
#59 0x0805dc41 in _start () at ../sysdeps/i386/elf/start.S:119

----------
assignedto: till
messages: 16165
nosy: bernhard, bh, ludwig, osterfeld, thomas, till, vkrause
priority: urgent
status: unread
title: Crash after manually removing dmap cache and using "Refresh Cache"
topic: enterprise35, kde client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue2972>
___________________________________________________


From kolab-issues at intevation.de  Mon Aug 11 18:54:20 2008
From: kolab-issues at intevation.de (Thomas Arendsen Hein)
Date: Mon, 11 Aug 2008 16:54:20 +0000
Subject: [Kolab-devel] [issue2973] "End of file" when trying to edit contact
Message-ID: <1218473660.75.0.637416859323.issue2973@intevation.de>


New submission from Thomas Arendsen Hein <thomas at intevation.de>:

Kontact Version 1.2.9 (enterprise35 20080725.837785)

When trying to edit a specific contact stored in an IMAP resource, I get an
error dialog with the title "Key Listing Failed" and the error text:
 An error occurred while fetching the keys from the backend:
 End of file

After pressing OK I the contact shows up without problems.
Other people trying to edit the same contact with the same version of kontact do
not get this error message.
Removing and rebuilding the dimap cache does not help.

Not sure if this is related, the debug output says:
kabc: WARNING: address format database incomplete (no format for locale C
found). Using default address formatting.

When looking at other contacts I noted that I get this error for at least three
contacts:
- one's birthday is in 4 days
- the other's anniversary is in 5 days
- the third's birthday is in April

for another contact with a birthday at the end of August, the error is not shown.

----------
assignedto: till
messages: 16167
nosy: bernhard, bh, ludwig, osterfeld, thomas, till, vkrause
priority: bug
status: unread
title: "End of file" when trying to edit contact
topic: enterprise35, kde client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue2973>
___________________________________________________


From kolab-issues at intevation.de  Tue Aug 12 10:56:47 2008
From: kolab-issues at intevation.de (Karl-Heinz Ruskowski)
Date: Tue, 12 Aug 2008 08:56:47 +0000
Subject: [Kolab-devel] [issue2974] Anniversary event has broken title
Message-ID: <1218531407.43.0.840551771267.issue2974@intevation.de>


New submission from Karl-Heinz Ruskowski <khruskowski at intevation.de>:

Kontact Version 1.2.9 (enterprise35 20080725.837785)
Kontact shows a broken event-title if a anniversary comes up.

Here the german version:
"Hochzeitstag von Peter Mustermann & "

and in english:
"Peter Musermann's & 's anniversary"

----------
assignedto: till
messages: 16170
nosy: bernhard, bh, khruskowski, ludwig, osterfeld, till, vkrause
priority: bug
status: unread
title: Anniversary event has broken title
topic: enterprise35, kde client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue2974>
___________________________________________________


From kolab-issues at intevation.de  Tue Aug 12 10:59:37 2008
From: kolab-issues at intevation.de (Karl-Heinz Ruskowski)
Date: Tue, 12 Aug 2008 08:59:37 +0000
Subject: [Kolab-devel] [issue2975] Anniversary event has wrong event details
Message-ID: <1218531577.49.0.487922246059.issue2975@intevation.de>


New submission from Karl-Heinz Ruskowski <khruskowski at intevation.de>:

The event details of an anniversary event say that it's a birthday of the two
people.

----------
assignedto: till
messages: 16171
nosy: bernhard, bh, khruskowski, ludwig, osterfeld, till, vkrause
priority: minor bug
status: unread
title: Anniversary event has wrong event details
topic: enterprise35, kde client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue2975>
___________________________________________________


From thomas at intevation.de  Tue Aug 12 11:33:06 2008
From: thomas at intevation.de (Thomas Arendsen Hein)
Date: Tue, 12 Aug 2008 11:33:06 +0200
Subject: [Kolab-devel] gunnar: server/kolab-webclient - New directory
In-Reply-To: <20080811171207.18552llqrjj2vh6o@webmail2.pardus.de>
References: <20080811093553.49EED600170@lists.intevation.de>
	<20080811135855.GJ20888.thomas@intevation.de>
	<20080811171207.18552llqrjj2vh6o@webmail2.pardus.de>
Message-ID: <20080812093306.GB28488.thomas@intevation.de>

* Gunnar Wrobel <wrobel at pardus.de> [20080811 17:12]:
> Quoting "Thomas Arendsen Hein" <thomas at intevation.de>:
> >* cvs at kolab.org <cvs at kolab.org> [20080811 11:35]:
> >>Author: gunnar
> >>
> >>Update of /kolabrepository/server/kolab-webclient
> >>In directory doto:/tmp/cvs-serv4012/kolab-webclient
> >>
> >>Log Message:
> >>Directory /kolabrepository/server/kolab-webclient added to the repository
> >
> >Why did you add that?
> 
> While this is not really the best thing to do security-wise and restricts the user as well as maintenance, I'm still in favor of moving the OpenPKG 
> packages (as well as the Gentoo packages btw - and it does hurt me more there) to the monolithic horde release.
> 
> This has one significant advantage over the splitted packages: We can provide a single kolab-specific patch that can be applied to the 
> horde-webmail package instead of having more than ten different patches for the different applications.

Thanks for the explanations.

This sounds like it will make it easier for us to keep up with new
Horde versions, so it is probably worth the drawbacks.

Regards,
Thomas

-- 
thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A
Intevation GmbH, Osnabrueck - Register: Amtsgericht Osnabrueck, HR B 18998
Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner


From kolab-issues at intevation.de  Tue Aug 12 11:42:12 2008
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Tue, 12 Aug 2008 09:42:12 +0000
Subject: [Kolab-devel] [issue2976] Irritating trust warning when selecting
	keys for encryption
Message-ID: <1218534132.31.0.641371924784.issue2976@intevation.de>


New submission from Bernhard Reiter <bernhard at intevation.de>:

With Kontact enterprise35 200806* there sometimes are  
wrong dialogs warning for keys that are not trusted enough when encrypting. 
 
(Setting this to need-eg, because there is not clear description of  
how to reproduce this.) 
 
I am describing one case: 
a) Aim to send email to user encrypted where the key is not yet 
   imported. 
b) Search key with kleopatra an import it. Close Kleo, reread keys. 
c) Now after pressing return there is that bogus dialog that 
   one of the OpenPGP oder S/MIME keys would not be trusted enough. 
d) on the command line gpgsm can encrypt without warning, so there is enough 
   trust. 
 
There is no other key for this person (so no OpenPGP and no other S/MIME key). 
Root certificates are preconfigured.

----------
assignedto: till
messages: 16173
nosy: bernhard, ludwig, michael, till, vkrause
priority: urgent
status: need-eg
title: Irritating trust warning when selecting keys for encryption
topic: kde client, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue2976>
___________________________________________________


From kolab-issues at intevation.de  Wed Aug 13 18:13:40 2008
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Wed, 13 Aug 2008 16:13:40 +0000
Subject: [Kolab-devel] [issue2978] read-only email folders bring up write
	errors with online imap
Message-ID: <1218644020.28.0.686435719703.issue2978@intevation.de>


New submission from Bernhard Reiter <bernhard at intevation.de>:

How to reproduce:     
a) have a folder with read rights (e.g. from somebody else) on      
   a online imap resource and a few emails in there.     
b) check mail on the account and select a few emails.     
Observation: Error message.     
      
Kontact: 1.2.9 (enterprise35 20080801.840707)       
      
Error message, similiar to:    
  Fehler beim Hochladen des Status der Nachrichten auf den Server:    
Schreiben in Ressource nicht m?glich   
Das bedeutet: Die Datenquelle kann zwar ?ndern der Markierung f?r   
imap://ltest3%40test.hq at neso.test.hq:143/user/ltest2/test-read/;UID=4   
fehlgeschlagen. ge?ffnet werden, aber beim Schreiben ist ein Fehler   
aufgetreten.   
   
I have tested with Cyrus IMAPD from Kolab Server 2.2.0.

----------
assignedto: till
messages: 16186
nosy: bernhard, bh, ludwig, till, vkrause
priority: bug
status: unread
title: read-only email folders bring up write errors with online imap
topic: enterprise35, kde client, kksa
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue2978>
___________________________________________________


From bernhard at intevation.de  Thu Aug 14 09:45:05 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 14 Aug 2008 09:45:05 +0200
Subject: [Kolab-devel] Dovecot as imap server (was: Kolab on Gmail)
In-Reply-To: <200808040751.23083.ml@radoeka.nl>
References: <87r69tki4b.fsf@home.pardus.de>
	<200807241719.37503.bernhard@intevation.de>
	<200808040751.23083.ml@radoeka.nl>
Message-ID: <200808140945.09874.bernhard@intevation.de>

On Monday 04 August 2008 07:51, Richard Bos wrote:
> Do you mean a full replacement of the cyrus server including acl and
> annotation support? ?

Yes, in principle.

> Would that result in an imap server that does not need to be patched.

Most likely: Not in the beginning. We'll see how that goes.

-- 
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: 189 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20080814/36242c3f/attachment.bin

From bernhard at intevation.de  Thu Aug 14 09:49:58 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 14 Aug 2008 09:49:58 +0200
Subject: [Kolab-devel] Modifying the LDAP user representation for a
	distributed Kolab server system?
In-Reply-To: <87od4grj4a.fsf@home.pardus.de>
References: <871w1drtk6.fsf@home.pardus.de>
	<200807291326.25828.bernhard@intevation.de>
	<87od4grj4a.fsf@home.pardus.de>
Message-ID: <200808140949.59704.bernhard@intevation.de>

On Tuesday 29 July 2008 14:05, Gunnar Wrobel wrote:
> Inventing a new Kolab user LDAP attribute for each and every service
> of the Kolab server to support such splitting seems like an overhead
> and people did not like the suggestion too much.
>
> So let me suggest an alternative by using the existing
> "kolabHomeserver" attribute. Would it be okay to extend its syntax to
> allow for several settings like:
>
> ? "example.org"
> ? "MTA:smtp.example.org"
> ? "IMAP:imap.example.org"
> ? "FreeBusy:fb.example.org"
>
> The default would be the entry without "prefix:" but it would be
> possible to provide redirects for specific services.

This looks quite ugly to me. Somehow inventing more parsing within
an LDAP attribute really feel wrong to me. 
So if we need the attributes, we can for sure come up with enough for them.

I am not sure that we need it per user, though.
For the user, most should be transparent (means: not visible).
This is why I am also against putting anything server specific in the login 
information. This could change during the lifetime of an account.

> If I consider the point Bernhard mentioned recently concerning
> splitted IMAP storage per user it might also make sense to have a
> syntax like
>  "imap://USER:PASS at SERVER"

For what in particular? 
The splitted IMAP storage will only be known the the user's client mostly.



-- 
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: 189 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20080814/650d6b05/attachment.bin

From bernhard at intevation.de  Thu Aug 14 09:52:12 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 14 Aug 2008 09:52:12 +0200
Subject: [Kolab-devel]
	=?iso-8859-1?q?Modifying_the_LDAP_user_representati?=
	=?iso-8859-1?q?on_for_a=09distributed_Kolab_server_system=3F?=
In-Reply-To: <87hc9zkgya.fsf@home.pardus.de>
References: <871w1drtk6.fsf@home.pardus.de> <488F648B.5000805@infosecurity.ch>
	<87hc9zkgya.fsf@home.pardus.de>
Message-ID: <200808140952.13264.bernhard@intevation.de>

On Tuesday 05 August 2008 10:24, Gunnar Wrobel wrote:
> > For example keeping the passwords outside the slave ldap servers in
> > order to save the security of the system (avoid that a single server in
> > branch office, with a local compromise with offline data recovery
> > causing a strong data loss) could cause the failure of the security of
> > the whole identification infrastructure.

In order to make this suitable, we would need to define a server
which will be able to hold folders that will be shared across homeservers.
Currently we cannot restrict password replication because potentially
all users can log into all Kolab Server to see a folder which was shared with 
them by one of the users of this server.

-- 
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: 189 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20080814/1f38d8f8/attachment.bin

From bernhard at intevation.de  Thu Aug 14 09:53:28 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 14 Aug 2008 09:53:28 +0200
Subject: [Kolab-devel] Kolab-major-app-patches - Kolab wiki
In-Reply-To: <87y73bhknj.fsf@rdus.de>
References: <200808040817.00441.ml@radoeka.nl> <87y73bhknj.fsf@rdus.de>
Message-ID: <200808140953.29615.bernhard@intevation.de>

On Tuesday 05 August 2008 11:32, Gunnar Wrobel wrote:
> > this page https://wiki.kolab.org/index.php/Kolab-major-app-patches on the
> > wiki shows the status of the patches that are needed for kolab to work
> > correctly. Is it however really necessary to keep the patches that are
> > marked "applied" and "outdated". ?The page becomes clearer when these
> > patches are removed from that page. ?Perhaps they can be moved to a page
> > that lists the closed patches (status "applied" and "outdated"), so the
> > patches are not forgotten.
> >
> > The patch for e.g. apache1 seems totally redundant as kolab is now using
> > apache2. ?When the sections about apache and postfix are removed the page
> > is already much better.
> >
> > What's your opinion about this?
>
> Fine with me.

The merge tracker should be used and also should have the history.
It would be fine to keep some history, but the wiki should not have something
that also can be held in the merge tracker.

-- 
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: 189 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20080814/fe876efb/attachment.bin

From bernhard at intevation.de  Thu Aug 14 09:55:59 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 14 Aug 2008 09:55:59 +0200
Subject: [Kolab-devel] Horde - How to personalize po files
In-Reply-To: <48987BD7.6020400@gelpi.it>
References: <48987BD7.6020400@gelpi.it>
Message-ID: <200808140956.00168.bernhard@intevation.de>

On Tuesday 05 August 2008 18:12, Gelpi Andrea wrote:
> A check with openpkg says that gettext is in /kolab/bin
>
> What can I check?

/kolab/bin/openpkg rpm -ql gettext and see if the binaries files are there 
and can be executed?

Otherwise check the code and see which command it tries to execute and why 
this fails.


-- 
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: 189 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20080814/ffc8fc04/attachment.bin

From kolab-issues at intevation.de  Thu Aug 14 16:19:35 2008
From: kolab-issues at intevation.de (Thomas Arendsen Hein)
Date: Thu, 14 Aug 2008 14:19:35 +0000
Subject: [Kolab-devel] [issue2979] kontact: Crash after re-enabling
	groupware support
Message-ID: <1218723575.31.0.146042170088.issue2979@intevation.de>


New submission from Thomas Arendsen Hein <thomas at intevation.de>:

Kontact Version 1.2.9 (enterprise35 20080725.837785)

dimap account without Notes and Tasks folder: When enabling groupware support
kontact tries to create these folders and crashes:

Using host libthread_db library "/lib/tls/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread -1242384704 (LWP 25219)]
[New Thread -1284482128 (LWP 25262)]
[New Thread -1276093520 (LWP 25261)]
[New Thread -1267704912 (LWP 25260)]
[New Thread -1259316304 (LWP 25259)]
[KCrash handler]
#5  0xb545666d in subresourceLabelForPresentation (folder=0x8212168)
    at kmailicalifaceimpl.cpp:684
#6  0xb54577bc in KMailICalIfaceImpl::folderContentsTypeChanged (
    this=0x8280e00, folder=0x8212168, contentsType=KMail::ContentsTypeNote)
    at kmailicalifaceimpl.cpp:1436
#7  0xb52b23ca in KMFolder::slotContentsTypeChanged (this=0x8212168, 
    type=KMail::ContentsTypeNote) at kmfolder.cpp:867
#8  0xb52b24a6 in KMFolder::qt_invoke (this=0x8212168, _id=5, _o=0xbfc14be4)
    at kmfolder.moc:392
#9  0xb7036d4f in QObject::activate_signal (this=0x8229af0, clist=0x820cab8, 
    o=0xbfc14be4) at kernel/qobject.cpp:2356
#10 0xb52cf607 in FolderStorage::contentsTypeChanged (this=0x8229af0, 
    t0=KMail::ContentsTypeNote) at folderstorage.moc:299
#11 0xb52cf65c in FolderStorage::setContentsType (this=0x0, 
    type=KMail::ContentsTypeMail, quiet=92) at folderstorage.cpp:1108
#12 0xb5457fcb in KMailICalIfaceImpl::initFolder (this=0x8280e00, 
    contentsType=KMail::ContentsTypeNote) at kmailicalifaceimpl.cpp:1972
#13 0xb545897b in KMailICalIfaceImpl::readConfig (this=0x8280e00)
    at kmailicalifaceimpl.cpp:1780
#14 0xb545e24f in KMailICalIfaceImpl::qt_invoke (this=0x8280e00, _id=2, 
    _o=0xbfc1514c) at kmailicalifaceimpl.moc:131
#15 0xb7036e7c in QObject::activate_signal (this=0x826a0d8, clist=0x8280d78, 
    o=0xbfc1514c) at kernel/qobject.cpp:2380
#16 0xb70377e0 in QObject::activate_signal (this=0x826a0d8, signal=2)
    at kernel/qobject.cpp:2325
#17 0xb538dc0e in KMKernel::configChanged (this=0x826a0d8) at kmkernel.moc:119
#18 0xb5390dea in KMKernel::slotConfigChanged (this=0x826a0d8)
    at kmkernel.cpp:1980
#19 0xb5390ef9 in KMKernel::qt_invoke (this=0x826a0d8, _id=7, _o=0xbfc1526c)
    at kmkernel.moc:159
#20 0xb7036d4f in QObject::activate_signal (this=0x84b6198, clist=0x84babc0, 
    o=0xbfc1526c) at kernel/qobject.cpp:2356
#21 0xb70377e0 in QObject::activate_signal (this=0x84b6198, signal=21)
    at kernel/qobject.cpp:2325
#22 0xb7d88229 in KCMultiDialog::configCommitted (this=0x84b6198)
    at ./kcmultidialog.moc:115
#23 0xb7d9e49f in KCMultiDialog::apply (this=0x84b6198)
    at /build/buildd/kdelibs-3.5.5a.dfsg.1/./kutils/kcmultidialog.cpp:160
#24 0xb7d9e52c in KCMultiDialog::slotOk (this=0x84b6198)
    at /build/buildd/kdelibs-3.5.5a.dfsg.1/./kutils/kcmultidialog.cpp:179
#25 0xb521ed27 in ConfigureDialog::slotOk (this=0x84b6198)
    at configuredialog.cpp:261
#26 0xb6939789 in KDialogBase::qt_invoke (this=0x84b6198, _id=74, 
    _o=0xbfc1543c) at ./kdialogbase.moc:359
#27 0xb7d9d7d3 in KCMultiDialog::qt_invoke (this=0x84b6198, _id=74, 
    _o=0xbfc1543c) at ./kcmultidialog.moc:148
#28 0xb51f6063 in ConfigureDialog::qt_invoke (this=0x84b6198, _id=74, 
    _o=0xbfc1543c) at configuredialog.moc:113
#29 0xb7036d4f in QObject::activate_signal (this=0x84a4380, clist=0x8375450, 
    o=0xbfc1543c) at kernel/qobject.cpp:2356
#30 0xb70377e0 in QObject::activate_signal (this=0x84a4380, signal=4)
    at kernel/qobject.cpp:2325
#31 0xb73c8c0f in QButton::clicked (this=0x84a4380)
    at .moc/debug-shared-mt/moc_qbutton.cpp:152
#32 0xb70d3cf6 in QButton::mouseReleaseEvent (this=0x84a4380, e=0xbfc158a4)
    at widgets/qbutton.cpp:836
#33 0xb706d6f0 in QWidget::event (this=0x84a4380, e=0xbfc158a4)
    at kernel/qwidget.cpp:4702
#34 0xb6fcec26 in QApplication::internalNotify (this=0xbfc15e6c, 
    receiver=0x84a4380, e=0xbfc158a4) at kernel/qapplication.cpp:2635
#35 0xb6fd0dc9 in QApplication::notify (this=0xbfc15e6c, receiver=0x84a4380, 
    e=0xbfc158a4) at kernel/qapplication.cpp:2421
#36 0xb76f6e0e in KApplication::notify (this=0xbfc15e6c, receiver=0x84a4380, 
    event=0xbfc158a4)
    at /build/buildd/kdelibs-3.5.5a.dfsg.1/./kdecore/kapplication.cpp:550
#37 0xb6f62495 in QApplication::sendSpontaneousEvent (receiver=0x84a4380, 
    event=0xbfc158a4) at kernel/qapplication.h:523
#38 0xb6f6112f in QETWidget::translateMouseEvent (this=0x84a4380, 
    event=0xbfc15cd8) at kernel/qapplication_x11.cpp:4301
#39 0xb6f5f6b0 in QApplication::x11ProcessEvent (this=0xbfc15e6c, 
    event=0xbfc15cd8) at kernel/qapplication_x11.cpp:3478
#40 0xb6f75d02 in QEventLoop::processEvents (this=0x80ac5c8, flags=4)
    at kernel/qeventloop_x11.cpp:192
#41 0xb6fe9179 in QEventLoop::enterLoop (this=0x80ac5c8)
    at kernel/qeventloop.cpp:198
#42 0xb6fe8f9a in QEventLoop::exec (this=0x80ac5c8)
    at kernel/qeventloop.cpp:145
#43 0xb6fd07bf in QApplication::exec (this=0xbfc15e6c)
    at kernel/qapplication.cpp:2758
#44 0x0805e324 in main (argc=) at main.cpp:188
#45 0xb778cea8 in __libc_start_main () from /lib/tls/libc.so.6
#46 0x0805dc41 in _start () at ../sysdeps/i386/elf/start.S:119

----------
assignedto: till
messages: 16204
nosy: bernhard, bh, ludwig, osterfeld, thomas, till, vkrause
priority: bug
status: unread
title: kontact: Crash after re-enabling groupware support
topic: enterprise35, kde client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue2979>
___________________________________________________


From kolab-issues at intevation.de  Thu Aug 14 16:45:24 2008
From: kolab-issues at intevation.de (Thomas Arendsen Hein)
Date: Thu, 14 Aug 2008 14:45:24 +0000
Subject: [Kolab-devel] [issue2980] "Error while uploading folder" after
	creating groupware folders
Message-ID: <1218725124.25.0.367063320811.issue2980@intevation.de>


New submission from Thomas Arendsen Hein <thomas at intevation.de>:

Kontact Version 1.2.9 (enterprise35 20080725.837785)
(and with many versions of enterprise35 before, I just got always told that
this is a known issue, but I can't find a suitable report for this)

When creating groupware folders (by enabling groupware support on an existing
account or by creating a new account with kolabwizard) on one of the next
starts of kontact I get this error dialog (not sure if it is always about
"Journal"):

Error while uploading folder
Could not make the folder Journal on the server.
This could be because you do not have permission to do this, or because the
folder is already present on the server; the error message from the server
communication is here:
Could Not Create Folder
An attempt to create the requested folder failed.
Details of the request:
URL: (unknown)
Date and time: Thursday 14 August 2008 16:34
Additional information:
imaps://user%40example.com at kolab.example.com:993/INBOX/Journal/
Possible causes:
Your access permissions may be inadequate to perform the requested operation on
this resource.
The location where the folder was to be created may not exist.
A protocol error or incompatibility may have occurred.
Possible solutions:
Retry the request.
Check your access permissions on this resource.


Looks similar to kolab/issue100 ("Can't create folder" message on sync)
and kolab/issue838 (Error while uploading folder) which got closed because
they couldn't be reproduced.

I can reproduce this with a clean $HOME and creating initial configuration
using kolabwizard.

As stated above I've seen this _very_ often and it is really annoying,
therefore please keep this to at least "urgent" until it is solved!

----------
assignedto: till
messages: 16207
nosy: bernhard, bh, ludwig, osterfeld, thomas, till, vkrause
priority: urgent
status: unread
title: "Error while uploading folder" after creating groupware folders
topic: enterprise35, kde client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue2980>
___________________________________________________


From kolab-issues at intevation.de  Thu Aug 14 22:27:55 2008
From: kolab-issues at intevation.de (Richard Bos)
Date: Thu, 14 Aug 2008 20:27:55 +0000
Subject: [Kolab-devel] [issue2981] kolab_bootstrap: re-use kolabconf code to
	read the config file
Message-ID: <1218745674.91.0.726276482312.issue2981@intevation.de>


New submission from Richard Bos <ml at radoeka.nl>:

The attach replaces some lines in kolab_bootstrap with a single one to
read in the configuration.  The advantage is that the space in configuration
file becomes optional.

----------
files: kolab_bootstrap_with_readConfig.in.patch
messages: 16218
nosy: rbos
priority: bug
status: unread
title: kolab_bootstrap: re-use kolabconf code to read the config file
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue2981>
___________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kolab_bootstrap_with_readConfig.in.patch
Type: application/octet-stream
Size: 1098 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20080814/0a0d1ccf/kolab_bootstrap_with_readConfig.in.exe

From kolab-issues at intevation.de  Fri Aug 15 02:19:16 2008
From: kolab-issues at intevation.de (Diego Woitasen)
Date: Fri, 15 Aug 2008 00:19:16 +0000
Subject: [Kolab-devel] [issue2982] OpenLDAP segmentation fault
Message-ID: <1218759556.38.0.104972391578.issue2982@intevation.de>


New submission from Diego Woitasen <diegows at xtech.com.ar>:

Kolab: 2.2.0
Debian 4.0 Etch

I got 3 crashes from OpenLDAP this week, dmesg shows:
slapd[3764]: segfault at 0000000000000010 rip 00000000005f1d3a rsp
0000000044006610 error 4
slapd[7738]: segfault at 0000000000000010 rip 00000000005f1d3a rsp
0000000043603510 error 4
slapd[7225] general protection rip:5ef43b rsp:43e046c0 error:0

This produces a database crash too. db_recover works.

I'm upgrading to 2.4.43 and will post more information later if I got a crash
again (with core dump enabled).

----------
messages: 16219
nosy: diegows
priority: critical
status: unread
title: OpenLDAP segmentation fault
topic: server
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue2982>
___________________________________________________


From kolab-issues at intevation.de  Fri Aug 15 06:30:30 2008
From: kolab-issues at intevation.de (Gunnar Wrobel)
Date: Fri, 15 Aug 2008 04:30:30 +0000
Subject: [Kolab-devel] [issue2983] Unknown: SECURITY PROBLEM: insecure
	server advertised AUTH=PLAIN
Message-ID: <1218774630.35.0.502558338896.issue2983@intevation.de>


New submission from Gunnar Wrobel <p at rdus.de>:

We see this error rather often in the PHP related logs:

PHP Notice:  Unknown: SECURITY PROBLEM: insecure server advertised AUTH=PLAIN
 (errflg=1) in Unknown on line 0

This is caused by cyrus imap advertising AUTH=PLAIN on a line that is not SSL
secured. The cclient library inside PHP considers this a security risk and
issues the warning.

I believe I seen this going away on later Gentoo installation but I still need
to check if one of the involved applications did somehow get modified and if we
can get this for OpenPKG too.

----------
assignedto: wrobel
messages: 16220
nosy: bernhard, martin, steffen, thomas, wilde, wrobel
priority: minor bug
status: unread
title: Unknown: SECURITY PROBLEM: insecure server advertised AUTH=PLAIN
topic: server
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue2983>
___________________________________________________


From kolab-issues at intevation.de  Fri Aug 15 06:33:53 2008
From: kolab-issues at intevation.de (Gunnar Wrobel)
Date: Fri, 15 Aug 2008 04:33:53 +0000
Subject: [Kolab-devel] [issue2984] PHP Notice: Unknown: Login aborted or PHP
	Notice: Unknown: IMAP protocol error: Client canceled authentication
Message-ID: <1218774833.1.0.920921822941.issue2984@intevation.de>


New submission from Gunnar Wrobel <p at rdus.de>:

I believe this signifies the attemt of Horde to access the cyrus imap client as
an anonymous user which we don't allow at the moment. The Kolab backend should
probably deny such connection attempts by default (though supporting such things
might be of more interest later if we want to support exporting Kolab stored
data to be publicly viewable).

----------
assignedto: wrobel
messages: 16221
nosy: bernhard, thomas, wilde, wrobel
priority: minor bug
status: unread
title: PHP Notice:  Unknown: Login aborted or PHP Notice:  Unknown: IMAP protocol error: Client canceled authentication
topic: horde
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue2984>
___________________________________________________


From wrobel at pardus.de  Fri Aug 15 06:41:50 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Fri, 15 Aug 2008 06:41:50 +0200
Subject: [Kolab-devel] Modifying the LDAP user representation for
	a	distributed Kolab server system?
In-Reply-To: <200808140949.59704.bernhard@intevation.de>
References: <871w1drtk6.fsf@home.pardus.de>
	<200807291326.25828.bernhard@intevation.de>
	<87od4grj4a.fsf@home.pardus.de>
	<200808140949.59704.bernhard@intevation.de>
Message-ID: <20080815064150.15837km92i9ik18o@devmail.pardus.de>

Quoting Bernhard Reiter <bernhard at intevation.de>:

> On Tuesday 29 July 2008 14:05, Gunnar Wrobel wrote:
>> Inventing a new Kolab user LDAP attribute for each and every service
>> of the Kolab server to support such splitting seems like an overhead
>> and people did not like the suggestion too much.
>>
>> So let me suggest an alternative by using the existing
>> "kolabHomeserver" attribute. Would it be okay to extend its syntax to
>> allow for several settings like:
>>
>>   "example.org"
>>   "MTA:smtp.example.org"
>>   "IMAP:imap.example.org"
>>   "FreeBusy:fb.example.org"
>>
>> The default would be the entry without "prefix:" but it would be
>> possible to provide redirects for specific services.
>
> This looks quite ugly to me. Somehow inventing more parsing within
> an LDAP attribute really feel wrong to me.
> So if we need the attributes, we can for sure come up with enough for them.

Okay, I agree with the parsing thing.

>
> I am not sure that we need it per user, though.

p at rdus does :) If you have an array of IMAP servers behind an MTA  
layer the MTA layer should actually know which IMAP server to deliver  
to. And that is per user. I know this is not possible with  
Kolab2/OpenPKG at the moment but such distributed setup are feasible  
with Kolab.

> For the user, most should be transparent (means: not visible).

The admin sets this stuff in the web admin frontend. It should  
obviously not be editable by the user as this concerns the server  
infrastructure and is no user setting.

> This is why I am also against putting anything server specific in the login
> information. This could change during the lifetime of an account.

Login information? Sorry, didn't understand this comment. Can you clarify?

>
>> If I consider the point Bernhard mentioned recently concerning
>> splitted IMAP storage per user it might also make sense to have a
>> syntax like
>>  "imap://USER:PASS at SERVER"
>
> For what in particular?
> The splitted IMAP storage will only be known the the user's client mostly.

So the user would set the storage spaces in Kontact and in the Kolab  
web client again? Storing that in LDAP would remove this redundancy or  
not?

Cheers,

Gunnar

>
>
>
> --
> 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
>



-- 
____ http://www.pardus.de _________________ http://gunnarwrobel.de _

E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                         Bundesstrasse 29
Fax    : +49 721 1513 52322                        D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


From kolab-issues at intevation.de  Fri Aug 15 12:41:09 2008
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Fri, 15 Aug 2008 10:41:09 +0000
Subject: [Kolab-devel] [issue2985] Kolabwizard startup warning not
	translated to German
Message-ID: <1218796869.37.0.443960406477.issue2985@intevation.de>


New submission from Bernhard Reiter <bernhard at intevation.de>:

Kontact-Installer_20080807
includes kpdepimlibs-branch 844044 kdepim-branch 844000

On Windows XP Sp3 German.
Running the Kolabwizard from the menu results in a Warning-Dialog
which has untranslated texts:

a) The window title starts with "Warning - Kolab-Einstellungsassis.."
b) "Please make sure that" ...

----------
assignedto: till
messages: 16228
nosy: bernhard, ludwig, till, vkrause
priority: minor bug
status: unread
title: Kolabwizard startup warning not translated to German
topic: kde client, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue2985>
___________________________________________________


From kolab-issues at intevation.de  Fri Aug 15 13:03:33 2008
From: kolab-issues at intevation.de (=?utf-8?q?Emanuel_Sch=C3=BCtze?=)
Date: Fri, 15 Aug 2008 11:03:33 +0000
Subject: [Kolab-devel] [issue2986] KNotify needs better solution
Message-ID: <1218798213.68.0.131509179958.issue2986@intevation.de>


New submission from Emanuel Sch?tze <emanuel at intevation.de>:

see kolab/issue2695

jstaniek wrote:
"OK, I have trashed the delay by disabling KNotify use in message boxes (not very
much user feature currently on Windows anyway), until we find real source of the
problem (apps have been waiting for something like a timeout or so)."

----------
assignedto: till
messages: 16230
nosy: bernhard, emanuel, jstaniek, ludwig, till
priority: bug
status: unread
title: KNotify needs better solution
topic: kde client, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue2986>
___________________________________________________


From kolab-issues at intevation.de  Tue Aug 19 12:07:50 2008
From: kolab-issues at intevation.de (Thomas Arendsen Hein)
Date: Tue, 19 Aug 2008 10:07:50 +0000
Subject: [Kolab-devel] [issue2987] Attachment folding with Fancy Headers
	style does not save screen space
Message-ID: <1219140470.62.0.303225598055.issue2987@intevation.de>


New submission from Thomas Arendsen Hein <thomas at intevation.de>:

Kontact Version 1.2.9 (enterprise35 20080725.837785)

With "Fancy Headers" style you can click on a small arrows icon to hide/show the
quick list of attachments directly below the headers of an email, but the
feature is mostly useless since even with folded attachments the text
"Attachments:" is still visible and takes nearly as much space as if the list
was still visible.

----------
assignedto: till
messages: 16248
nosy: bernhard, bh, ludwig, osterfeld, thomas, till, vkrause
priority: minor bug
status: unread
title: Attachment folding with Fancy Headers style does not save screen space
topic: enterprise35, kde client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue2987>
___________________________________________________


From kolab-issues at intevation.de  Tue Aug 19 15:25:53 2008
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Tue, 19 Aug 2008 13:25:53 +0000
Subject: [Kolab-devel] [issue2988] alarm icon in calender not shown,
	when reminder is activated
Message-ID: <1219152353.21.0.0534196636921.issue2988@intevation.de>


New submission from Bernhard Reiter <bernhard at intevation.de>:

Kontact enterprise4 20080807 (Windows)
  kpdepimlibs-branch 844044  kdepim-branch 844000  i18n 845168
  with klauncher-crash-fix.diff

Create a new appointment, activate the standard reminder 15 minutes and save
check the display in the regular day-calender view.
Failed expectation: There is no alarm icon for this event.
Enterprise35 has the alarm icon (a little bell).

Further check: edit the appointment again and remove the reminder: 
Failed expectation: no icon is removed in the day-calender view.

----------
assignedto: till
messages: 16250
nosy: bernhard, ludwig, till, vkrause
priority: bug
status: unread
title: alarm icon in calender not shown, when reminder is activated
topic: kde client, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue2988>
___________________________________________________


From kolab-issues at intevation.de  Tue Aug 19 15:40:09 2008
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Tue, 19 Aug 2008 13:40:09 +0000
Subject: [Kolab-devel] [issue2989] normal reminder changes to advanced
	reminder unexpectedly
Message-ID: <1219153209.72.0.487629062683.issue2989@intevation.de>


New submission from Bernhard Reiter <bernhard at intevation.de>:

Kontact: 1.2.9 (enterprise35 20080814.846427) GNU/Linux  
Kontact enterprise4 20080807 (Windows) 
  kpdepimlibs-branch 844044  kdepim-branch 844000  i18n 845168 
  with klauncher-crash-fix.diff 
 
a) Create an event entry, enable the standard alarm (e.g. 15 minutes) 
by using the check box. Save the event and sync. 
If you reopen the event for edit now, the alarm will be shown as  
standard alarm. 
b) stop and restart kontact 
c) Look at the event again (open for edit). Now the alarm is 
   an "advanced reminder" and you need to go into the advanced reminder 
   dialog to change it.  
Expectation: the standard alarm should stay the same after sync,  
  stopping and starting.

----------
assignedto: till
messages: 16251
nosy: bernhard, ludwig, till, vkrause
priority: minor bug
status: unread
title: normal reminder changes to advanced reminder unexpectedly
topic: gnulinux, kde client, kowi, prokde35, windows
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue2989>
___________________________________________________


From m.gabriel at das-netzwerkteam.de  Tue Aug 19 15:48:14 2008
From: m.gabriel at das-netzwerkteam.de (Mike Gabriel)
Date: Tue, 19 Aug 2008 15:48:14 +0200
Subject: [Kolab-devel] distributionlists testing
In-Reply-To: <20080519102840.291878n4kyy18it4@mail.das-netzwerkteam.de>
References: <20080519102840.291878n4kyy18it4@mail.das-netzwerkteam.de>
Message-ID: <20080819154814.385458x7cly5qyou@mail.das-netzwerkteam.de>

hi joon, hi gunnar,

picking up an old thread... i am wondering if something has happened  
around the issue below. i was under cover for quite a while and busy  
with other stuff than kolab. but in the very near future i will need a  
fix for the problem below and i am wondering if anything has been  
decided yet, how i can help, etc.

best regards to all,
mike

Quoting Mike Gabriel <m.gabriel at das-netzwerkteam.de>:

> hi joon, hi gunnar,
>
> @joon: once you have an idea how to solve this problem let us know on
> the kolab-devel list...
>
> @gunnar: to make distlists of current toltec versions work in horde,
> we probably have to allow both MIME types
> (application/x-vnd.kolab.distribution-list and
> application/x-vnd.kolab.contact.distlist) as a distlist in horde.
>
> i would welcome toltec to move towards kolab xml format standards,  
> that means:
>
>    o new toltec versions will store distlists with standard MIME type
>      application/x-vnd.kolab.distribution-list
>
>    o horde will be able to recognize and read distlists with MIME type
>      application/x-vnd.kolab.contact.distlist
>
>    o all clients try to migrate application/x-vnd.kolab.contact.distlist to
>      application/x-vnd.kolab.distribution-list
>
> DISCUSSIONS:
>
>    o horde: smtp-address in distlists that are not in the same address
> book will
>      be auto-created as new contacts
>
>    o toltec: link smtp-addesses in a distlist to existing contact
> objects in same
>      address book(?)
>
> best and thanks for your work,
> mike


-- 

das netzwerkteam
mike gabriel, dorfstr. 27, 24245 barmissen
fon: +49 (4302) 281418, fax: +49 (4302) 281419
mail: m.gabriel at das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb


From marc at kdab.net  Fri Aug 15 10:44:18 2008
From: marc at kdab.net (Marc Mutz)
Date: Fri, 15 Aug 2008 10:44:18 +0200
Subject: [Kolab-devel] Choosing between kontact and kmail
In-Reply-To: <200610021651.23322.dfaure@klaralvdalens-datakonsult.se>
References: <200610021651.23322.dfaure@klaralvdalens-datakonsult.se>
Message-ID: <200808151044.30267.marc@kdab.net>

On Monday October 2 2006, David Faure wrote:
> Given that kmail (in kde-3.5) or kontact (in proko2) is auto-started when
> korganizer, kaddressbook, korgac, or knotes is started, (to provide the
> calendar/contact/notes data), there needs to be a way for the user to
> select whether kmail or kontact should be autostarted.
>
> I have now implemented a shell-script which lets you choose between kmail
> and kontact as the "imap resource backend". Simply run the attached script,
> first without arguments to check your current setup, and then with either
> kmail or kontact as argument.

I needed to add a few chmod's for it to work. not sure it's a problem of the 
script or of the Intevation packages I use.

Changed script attached.

-- 
Marc Mutz - marc at kdab.com, mutz at kde.org - Klar?lvdalens Datakonsult AB
Platform-independent software solutions - www.kdab.com info at kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: select_imap_backend.sh
Type: application/x-shellscript
Size: 3965 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20080815/2efc7eba/select_imap_backend.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20080815/2efc7eba/attachment.bin

From soliva at comcept.ch  Wed Aug 20 07:50:56 2008
From: soliva at comcept.ch (ComCept Soliva)
Date: Wed, 20 Aug 2008 07:50:56 +0200
Subject: [Kolab-devel] [issue2924] install-kolab.sh: -maxdepth/-mindepth
	notsupported by all find implementations
In-Reply-To: <1216809613.95.0.427766725035.issue2924@intevation.de>
References: <1216809613.95.0.427766725035.issue2924@intevation.de>
Message-ID: <8A1C7CB03FA64FD181416AE969EE6AB1@comcept.ch>

Hi all

is there any news regarding this issue ? I was not able to have a look to
the site https://www.intevation.de/roundup/kolab/ (not available).

kind regards

Andrea

Mail: soliva at comcept.ch 
-----Urspr?ngliche Nachricht-----
Von: Thomas Arendsen Hein [mailto:kolab-issues at intevation.de] Im Auftrag von
kolab-devel-bounces at kolab.org
Gesendet: Mittwoch, 23. Juli 2008 12:40
An: kolab-devel at kolab.org
Betreff: [Kolab-devel] [issue2924] install-kolab.sh: -maxdepth/-mindepth
notsupported by all find implementations


New submission from Thomas Arendsen Hein <thomas at intevation.de>:

> Changing to temporary working directory /tmp/install-kolab....1444 ...
> find: bad option -mindepth
> find: [-H | -L] path-list predicate-list

Seems as if Solaris' find does not support -mindepth and -maxdepth,
so we have to find a different syntax to detect the needed files,
maybe using eval (which I try to avoid if possible).

-mindepth and -maxdepth was used in the script before, so we thought
it would work.

> Found a source based OpenPKG installer. Trying to install Kolab from
source.
> Creating binary openpkg package from ./openpkg-20071227-20071227.src.sh!

Hmm, it should not have found the .src.sh without a working find
command, but we'll see.

> Processing files: openpkg-20071227-20071227
> Wrote:
/kolab/RPM/PKG/openpkg-20071227-20071227.sparc64-solaris10-kolab.rpm
> Executing(%clean): env -i /kolab/lib/openpkg/bash --norc --noprofile
--posix
-e /kolab/RPM/TMP/rpm-tmp.1024
> + cd /kolab/RPM/TMP
> + '[' . = .1 ']'
> + rm -rf openpkg-20071227
> + rm -rf /kolab/RPM/TMP/openpkg-20071227-root
> + exit 0
> Executing(--clean): env -i /kolab/lib/openpkg/bash --norc --noprofile
--posix
-e /kolab/RPM/TMP/rpm-tmp.18771
> + cd /kolab/RPM/TMP
> + exit 0
> Preparing...
##################################################
> openpkg
##################################################
> :::: /tmp/install-kolab....1444/openpkg-20071227-20071227.src.rpm = 0 ::::
> :::: /tmp/install-kolab....1444/make-3.81-20080101.src.rpm ::::
> error: cannot open /tmp/install-kolab....1444/make-3.81-20080101.src.rpm:
No
such file or directory

The script should have aborted earlier here.

----------
assignedto: thomas
messages: 15868
nosy: bernhard, martin, soliva, thomas, till, wilde, wrobel
priority: bug
status: unread
title: install-kolab.sh: -maxdepth/-mindepth not supported by all find
implementations
topic: server
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue2924>
___________________________________________________

_______________________________________________
Kolab-devel mailing list
Kolab-devel at kolab.org
https://kolab.org/mailman/listinfo/kolab-devel


From wrobel at pardus.de  Wed Aug 20 09:37:22 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Wed, 20 Aug 2008 09:37:22 +0200
Subject: [Kolab-devel] distributionlists testing
In-Reply-To: <20080819154814.385458x7cly5qyou@mail.das-netzwerkteam.de>
References: <20080519102840.291878n4kyy18it4@mail.das-netzwerkteam.de>
	<20080819154814.385458x7cly5qyou@mail.das-netzwerkteam.de>
Message-ID: <20080820093722.16755xlh0p59zsus@webmail2.pardus.de>

Quoting "Mike Gabriel" <m.gabriel at das-netzwerkteam.de>:

> hi joon, hi gunnar,
>
> picking up an old thread... i am wondering if something has happened
> around the issue below. i was under cover for quite a while and busy
> with other stuff than kolab. but in the very near future i will need a
> fix for the problem below and i am wondering if anything has been
> decided yet, how i can help, etc.
>
> best regards to all,
> mike
>
> Quoting Mike Gabriel <m.gabriel at das-netzwerkteam.de>:
>
>> hi joon, hi gunnar,
>>
>> @joon: once you have an idea how to solve this problem let us know on
>> the kolab-devel list...
>>
>> @gunnar: to make distlists of current toltec versions work in horde,
>> we probably have to allow both MIME types
>> (application/x-vnd.kolab.distribution-list and
>> application/x-vnd.kolab.contact.distlist) as a distlist in horde.

I am currently still waiting for a final discussion on that topic in  
the kolab-format discussion. I think this issue will be a small  
addendum to the Kolab format and require Kolab compatible clients to  
accept both variants. It currently looks like this issue will be  
resolved for the next Kolab Server version though. Did we have an open  
issue for this?

Cheers,

Gunnar

>>
>> i would welcome toltec to move towards kolab xml format standards,
>> that means:
>>
>>    o new toltec versions will store distlists with standard MIME type
>>      application/x-vnd.kolab.distribution-list
>>
>>    o horde will be able to recognize and read distlists with MIME type
>>      application/x-vnd.kolab.contact.distlist
>>
>>    o all clients try to migrate application/x-vnd.kolab.contact.distlist to
>>      application/x-vnd.kolab.distribution-list
>>
>> DISCUSSIONS:
>>
>>    o horde: smtp-address in distlists that are not in the same address
>> book will
>>      be auto-created as new contacts
>>
>>    o toltec: link smtp-addesses in a distlist to existing contact
>> objects in same
>>      address book(?)
>>
>> best and thanks for your work,
>> mike
>
>
> --
>
> das netzwerkteam
> mike gabriel, dorfstr. 27, 24245 barmissen
> fon: +49 (4302) 281418, fax: +49 (4302) 281419
> mail: m.gabriel at das-netzwerkteam.de, http://das-netzwerkteam.de
> freeBusy:
> https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
____ http://www.pardus.de _________________ http://gunnarwrobel.de _

E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                         Bundesstrasse 29
Fax    : +49 721 1513 52322                        D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


From kolab-issues at intevation.de  Wed Aug 20 10:58:32 2008
From: kolab-issues at intevation.de (Gunnar Wrobel)
Date: Wed, 20 Aug 2008 08:58:32 +0000
Subject: [Kolab-devel] [issue2991] The Kolab web client is always in the
	privileged networks
Message-ID: <1219222712.46.0.391847741722.issue2991@intevation.de>


New submission from Gunnar Wrobel <p at rdus.de>:

A Kolab web client installed on the main Kolab web server will be in the default
privileged network (127.0.0.1). This means that users may fake their sender address.

----------
assignedto: thomas
messages: 16264
nosy: bernhard, martin, steffen, thomas, wilde, wrobel
priority: bug
status: unread
title: The Kolab web client is always in the privileged networks
topic: horde, server
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue2991>
___________________________________________________


From thomas at intevation.de  Wed Aug 20 12:02:56 2008
From: thomas at intevation.de (Thomas Arendsen Hein)
Date: Wed, 20 Aug 2008 12:02:56 +0200
Subject: [Kolab-devel] [issue2924] install-kolab.sh: -maxdepth/-mindepth
	notsupported by all find implementations
In-Reply-To: <8A1C7CB03FA64FD181416AE969EE6AB1@comcept.ch>
References: <1216809613.95.0.427766725035.issue2924@intevation.de>
	<8A1C7CB03FA64FD181416AE969EE6AB1@comcept.ch>
Message-ID: <20080820100256.GA31924.thomas@intevation.de>

* ComCept Soliva <soliva at comcept.ch> [20080820 07:50]:
> is there any news regarding this issue ? I was not able to have a look to

No real news, but I just added a workaround in the issue:

| As a quick workaround you could just remove these options from the
| script and make sure you have no other files matching the pattern
| in subdirectories.

> the site https://www.intevation.de/roundup/kolab/ (not available).

The tracker currently freezes every once a while. I'm not sure
what's happening here, but I've restarted it so it is usable now.

Regards,
Thomas Arendsen Hein

-- 
thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A
Intevation GmbH, Osnabrueck - Register: Amtsgericht Osnabrueck, HR B 18998
Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner


From kolab-issues at intevation.de  Wed Aug 20 12:37:22 2008
From: kolab-issues at intevation.de (Mike Gabriel)
Date: Wed, 20 Aug 2008 10:37:22 +0000
Subject: [Kolab-devel] [issue2992] distlist MIME-types mismatch between
	horde and toltec
Message-ID: <1219228642.17.0.338819393622.issue2992@intevation.de>


New submission from Mike Gabriel <m.gabriel at das-netzwerkteam.de>:

as discussed on the kolab-devel mailing list, there is an incompatibility
problem between the horde distlist code and the toltec distlist handling:

the kolab format demands this MIME type for distlists (as implemented 
in the new horde code fragments):
application/x-vnd.kolab.distribution-list

toltec uses this MIME type... (??? this is not kolab xml format compliant !!!)
application/x-vnd.kolab.contact.distlist

additionally, toltec adds another attachment of the MIME type:
application/x-outlook-tnef

after decoding both toltec base64 encoded attachments, it seems like 
the first (application/x-vnd.kolab.distribution-list) is fully kolab 
xml format compliant (apart from the MIME type), and the latter adds 
some binary stuff that helps to implement the full outlook address 
book / distlist functionality into the kolab IMAP storage system.

for further info refer to the kolab-devel thread:
http://marc.info/?l=kolab-devel&m=121118571904654&w=2

there also is a discussion on this going on on the kolab-format list (no URL,
sorry).

----------
messages: 16271
nosy: mike
priority: bug
status: unread
title: distlist MIME-types mismatch between horde and toltec
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue2992>
___________________________________________________


From m.gabriel at das-netzwerkteam.de  Wed Aug 20 12:41:21 2008
From: m.gabriel at das-netzwerkteam.de (Mike Gabriel)
Date: Wed, 20 Aug 2008 12:41:21 +0200
Subject: [Kolab-devel] distributionlists testing
In-Reply-To: <20080820093722.16755xlh0p59zsus@webmail2.pardus.de>
References: <20080519102840.291878n4kyy18it4@mail.das-netzwerkteam.de>
	<20080819154814.385458x7cly5qyou@mail.das-netzwerkteam.de>
	<20080820093722.16755xlh0p59zsus@webmail2.pardus.de>
Message-ID: <20080820124121.132225dm5u5vm7yp@mail.das-netzwerkteam.de>

hi gunnar,

Quoting Gunnar Wrobel <wrobel at pardus.de>:

> Quoting "Mike Gabriel" <m.gabriel at das-netzwerkteam.de>:
>
>> hi joon, hi gunnar,
>>
>> picking up an old thread... i am wondering if something has happened
>> around the issue below. i was under cover for quite a while and busy
>> with other stuff than kolab. but in the very near future i will need a
>> fix for the problem below and i am wondering if anything has been
>> decided yet, how i can help, etc.
>>

> [...]

>
> I am currently still waiting for a final discussion on that topic in
> the kolab-format discussion. I think this issue will be a small
> addendum to the Kolab format and require Kolab compatible clients to
> accept both variants. It currently looks like this issue will be
> resolved for the next Kolab Server version though. Did we have an open
> issue for this?

i just realized that i am still not subscribed to the kolab-format list...

in the bugtracker i have created an issue for this problem:  
https://www.intevation.de/roundup/kolab/msg16271

thanks for the quick answer,
mike

-- 

das netzwerkteam
mike gabriel, dorfstr. 27, 24245 barmissen
fon: +49 (4302) 281418, fax: +49 (4302) 281419
mail: m.gabriel at das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb


From kolab-issues at intevation.de  Wed Aug 20 16:33:33 2008
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Wed, 20 Aug 2008 14:33:33 +0000
Subject: [Kolab-devel] [issue2993] Security for receiving account setting
	has wrong non-secure default
Message-ID: <1219242813.11.0.820549116739.issue2993@intevation.de>


New submission from Bernhard Reiter <bernhard at intevation.de>:

Kontact on Mac 20080719: 
 
Settings -> Accounts -> Receiving -> Security 
Check what server supports 
comes back with no encryption and TLS possible, 
but selects no-encryption. 
 
Expected behaviouir: Select Encryption by default 
(if it is possible what it was in this case.)

----------
assignedto: till
messages: 16275
nosy: bernhard, emanuel, till
priority: minor bug
status: unread
title: Security for receiving account setting has wrong non-secure default
topic: kde client, kowi, macos
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue2993>
___________________________________________________


From kolab-issues at intevation.de  Wed Aug 20 21:14:43 2008
From: kolab-issues at intevation.de (Richard Bos)
Date: Wed, 20 Aug 2008 19:14:43 +0000
Subject: [Kolab-devel] [issue2994] Duplicated kolab.conf files in cvs,
	one should be removed
Message-ID: <1219259683.28.0.85373284267.issue2994@intevation.de>


New submission from Richard Bos <ml at radoeka.nl>:

Due to the investigation for issue1755, I encountered 2 kolab.conf files 
in cvs.  Is this correct?  They are:

kolabd> ls -1  $(find -name "kolab.conf*") | cut -c3-
kolab.conf
templates/kolab.conf.template.in

During bootstrapping kolab.conf is created from 
templates/kolab.conf.template.in.  Hence keeping the regular kolab.conf file
in cvs seems redundant to me.  At the moment they also show some differences:
kolabd> diff -u ./kolab.conf ./templates/kolab.conf.template.in
--- ./kolab.conf        2008-03-04 20:11:52.000000000 +0100
+++ ./templates/kolab.conf.template.in  2007-11-29 09:27:18.000000000 +0100
@@ -4,11 +4,14 @@
 fqdnhostname : @@@fqdnhostname@@@
 is_master : @@@is_master@@@
 base_dn : @@@kolab_basedn@@@
-bind_dn : cn=manager,@@@kolab_basedn@@@
+bind_dn : cn=manager,cn=internal,@@@kolab_basedn@@@
 bind_pw : @@@kolab_passwd@@@
+bind_pw_hash : @@@kolab_passwd_hash@@@
 ldap_uri : ldap://127.0.0.1:389
 ldap_master_uri : @@@ldap_master_uri@@@
-php_dn : cn=nobody,@@@kolab_basedn@@@
+php_dn : cn=nobody,cn=internal,@@@kolab_basedn@@@
 php_pw : @@@nobody_pw@@@
+calendar_id : calendar
+calendar_pw : @@@calendar_pw@@@
 slurpd_addr : 127.0.0.1
 slurpd_port : 9999

It means that calendar_pw, calendar_id and bind_pw_hash are defined in
kolab.conf.template but not in the regular file kolab.conf.  Confusing....

Suggestion: remove kolab.conf from cvs

ps: although the title is: "Duplicated kolab.conf files in cvs, one should be 
removed", I'm not sure that one must be removed, I think so.

----------
messages: 16277
nosy: rbos
priority: minor bug
status: unread
title: Duplicated kolab.conf files in cvs, one should be removed
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue2994>
___________________________________________________


From kolab-issues at intevation.de  Wed Aug 20 21:16:27 2008
From: kolab-issues at intevation.de (Richard Bos)
Date: Wed, 20 Aug 2008 19:16:27 +0000
Subject: [Kolab-devel] [issue2995] Remove some variables from
	kolab.globals.in as they are already defined in
	kolab.conf.template.in
Message-ID: <1219259787.06.0.885219112364.issue2995@intevation.de>


New submission from Richard Bos <ml at radoeka.nl>:

Due to an investigation for issue1755, I encountered 4 variables that are
defined in kolab.globals.in and kolab.conf.template.in.  These are:
ldap_uri, calendar_id, slurpd_addr and slurpd_port

Does it make sense to have these variables defined in 2 files in cvs?  As these
variables are written to kolab.conf by kolab_bootstap anyway, it does not seem 
to be needed
to have those variables defined in kolab.globals.in.

Suggestion remove the variables from kolab.globals.in

----------
messages: 16278
nosy: rbos
priority: minor bug
status: unread
title: Remove some variables from kolab.globals.in as they are already defined in kolab.conf.template.in
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue2995>
___________________________________________________


From kolab-issues at intevation.de  Wed Aug 20 22:14:58 2008
From: kolab-issues at intevation.de (Christian Tardif)
Date: Wed, 20 Aug 2008 20:14:58 +0000
Subject: [Kolab-devel] [issue2996] Samba-Kolab integration - Patch file
Message-ID: <1219263298.82.0.819749333107.issue2996@intevation.de>


New submission from Christian Tardif <christian.tardif at servinfo.ca>:

Here is a tgz file that contains user.diff and samba.php.

user.diff must patch /kolab/var/kolab/www/admin/user/user.php
samba.php must go in /kolab/var/kolab/php/admin/include/

user must include nis.schema and samba.schema in openldap. The modification make
use of mkntpwd and cracklib-check which must be provided by the host environment.

The modification allows the creation of samba objects for the created users to
login on shell and samba.

----------
messages: 16279
nosy: tardich
priority: feature
status: unread
title: Samba-Kolab integration - Patch file
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue2996>
___________________________________________________


From kolab-issues at intevation.de  Wed Aug 20 22:15:19 2008
From: kolab-issues at intevation.de (Christian Tardif)
Date: Wed, 20 Aug 2008 20:15:19 +0000
Subject: [Kolab-devel] [issue2997] Samba-Kolab integration - Patch file
Message-ID: <1219263319.26.0.703097223765.issue2997@intevation.de>


New submission from Christian Tardif <christian.tardif at servinfo.ca>:

Here is a tgz file that contains user.diff and samba.php.

user.diff must patch /kolab/var/kolab/www/admin/user/user.php
samba.php must go in /kolab/var/kolab/php/admin/include/

user must include nis.schema and samba.schema in openldap. The modification make
use of mkntpwd and cracklib-check which must be provided by the host environment.

The modification allows the creation of samba objects for the created users to
login on shell and samba.

----------
files: kolab-samba.tgz
messages: 16280
nosy: tardich
priority: feature
status: unread
title: Samba-Kolab integration - Patch file
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue2997>
___________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kolab-samba.tgz
Type: application/x-tar
Size: 2283 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20080820/588d5411/kolab-samba-0001.tar

From kolab-issues at intevation.de  Thu Aug 21 03:19:51 2008
From: kolab-issues at intevation.de (Diego Woitasen)
Date: Thu, 21 Aug 2008 01:19:51 +0000
Subject: [Kolab-devel] [issue2998] Default folders are not created
Message-ID: <1219281591.39.0.208583231494.issue2998@intevation.de>


New submission from Diego Woitasen <diegows at xtech.com.ar>:

When I create a new user, the default folders are not created (calendar, notes,
etc). If the user add an event, he gets an error about "folder don't exists".

I know that I could create the folders manually, but that folders should be
created auto.

Kolab 2.2.0

----------
messages: 16285
nosy: diegows
priority: bug
status: unread
title: Default folders are not created
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue2998>
___________________________________________________


From kolab-issues at intevation.de  Thu Aug 21 13:16:59 2008
From: kolab-issues at intevation.de (Saim Kim)
Date: Thu, 21 Aug 2008 11:16:59 +0000
Subject: [Kolab-devel] [issue2999] Set visibility for a persons calendar for
	group accounts
Message-ID: <1219317419.27.0.847180311134.issue2999@intevation.de>


New submission from Saim Kim <s.kim at hia.rwth-aachen.de>:

It would be great to give visibility and read rights to a calendar to a group of
users aka distribution list, using fbview for example.

Best regards,
Saim

----------
messages: 16288
nosy: sojakim
priority: feature
status: unread
title: Set visibility for a persons calendar for group accounts
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue2999>
___________________________________________________


From kolab-issues at intevation.de  Thu Aug 21 23:01:54 2008
From: kolab-issues at intevation.de (Richard Bos)
Date: Thu, 21 Aug 2008 21:01:54 +0000
Subject: [Kolab-devel] [issue3000] openldap conversion from slapd.conf to a
	real time configuration (rtc) in the future
Message-ID: <1219352514.08.0.750998342397.issue3000@intevation.de>


New submission from Richard Bos <ml at radoeka.nl>:

Let me copy and paste the first part of this webpage:

Historically OpenLDAP has been statically configured, that is, to make a change
to the configuration the slapd.conf file was modified and slapd stopped and
started. In the case of larger users this could take a considerable period of
time and had become increasingly unacceptable as an operational method.
OpenLDAP version 2.3 introduced an optional new feature whereby configuration
may be performed at run-time using a DIT entry called cn=config. The feature is
known by a varied and confusing number of terms including run-time
configuration (RTC) (our favorite), zero down-time configuration, cn=config and
slapd.d configuration. First a number of points:

 1. The feature is (at version 2.4) still optional which means that slapd.conf
    will continue to work.

 2. OpenLDAP has a history of being quite brutal about withdrawing support of
    older capabilities. This means that migration to run-time configuration
    should be contemplated as soon as practical. Better to do it when you don't
    need the new release than to be forced to take a new release because of a
    critical bug AND have to migrate to the new configration regime.

A bit further on, on that webpage it is explained what is needed to in 
the slapd.conf to convert the data and how slapd decides that it should
use Real Time Configuration (rtc).  I think that RTC is useful for big
kolab installations...

----------
messages: 16307
nosy: rbos
priority: bug
status: unread
title: openldap conversion from slapd.conf to a real time configuration (rtc) in the future
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3000>
___________________________________________________


From kolab-issues at intevation.de  Fri Aug 22 21:12:31 2008
From: kolab-issues at intevation.de (Karina)
Date: Fri, 22 Aug 2008 19:12:31 +0000
Subject: [Kolab-devel] [issue3001] _New_Dating 95, 203,
	70144 on'line members.
Message-ID: <183962459.44940610333689@rbcmail.ru>


New submission from Karina <aggressorssva86 at rbcmail.ru>:

++++++++++
I am a: 20 y.o.
seeking men from 40-65 
Located in: Bucharest, Muntenia Romania Dating 
photos: 56 
Income: $24,000 to $25,000 
Wants Kids: 168 

-------------------------------------------------------------

Click here to join now >> 

https://sites.google.com/site/datinsertgsrt/?q=Q92/3f6eE+ 

++++++++++++++++++++++++++++++++++

----------
messages: 16323
nosy: aggressorssva86
status: unread
title: _New_Dating 95,203,70144 on'line members.
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3001>
___________________________________________________


From wrobel at pardus.de  Fri Aug 22 21:44:57 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Fri, 22 Aug 2008 21:44:57 +0200
Subject: [Kolab-devel] [issue2998] Default folders are not created
In-Reply-To: <1219281591.39.0.208583231494.issue2998@intevation.de>
References: <1219281591.39.0.208583231494.issue2998@intevation.de>
Message-ID: <20080822214457.10891lgjur0piou8@webmail2.pardus.de>

Quoting "Diego Woitasen" <kolab-issues at intevation.de>:

>
> New submission from Diego Woitasen <diegows at xtech.com.ar>:
>
> When I create a new user, the default folders are not created  
> (calendar, notes,
> etc). If the user add an event, he gets an error about "folder don't exists".
>
> I know that I could create the folders manually, but that folders should be
> created auto.
>
> Kolab 2.2.0

As Richard mentioned this is not the task of the server but the task  
of the client. So we need feedback which client you are referring to.  
At least I guess that you are using a Kolab compatible client to  
create the event you mentioned.

>
> ----------
> messages: 16285
> nosy: diegows
> priority: bug
> status: unread
> title: Default folders are not created
> ___________________________________________________
> Kolab issue tracker <kolab-issues at intevation.de>
> <https://www.intevation.de/roundup/kolab/issue2998>
> ___________________________________________________
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
____ http://www.pardus.de _________________ http://gunnarwrobel.de _

E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                         Bundesstrasse 29
Fax    : +49 721 1513 52322                        D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


From kolab-issues at intevation.de  Sat Aug 23 09:25:21 2008
From: kolab-issues at intevation.de (Gunnar Wrobel)
Date: Sat, 23 Aug 2008 07:25:21 +0000
Subject: [Kolab-devel] [issue3002] Horde WebDAV access does not work with
	Kolab
Message-ID: <1219476321.51.0.616056354248.issue3002@intevation.de>


New submission from Gunnar Wrobel <p at rdus.de>:

Horde WebDAV based access is not supported when running Horde with Kolab. This
should be fixed in the new release.

----------
assignedto: wrobel
messages: 16334
nosy: bernhard, sascha.wilde, thomas, wrobel
priority: bug
status: unread
title: Horde WebDAV access does not work with Kolab
topic: horde
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3002>
___________________________________________________


From kolab-issues at intevation.de  Sat Aug 23 09:29:13 2008
From: kolab-issues at intevation.de (Gunnar Wrobel)
Date: Sat, 23 Aug 2008 07:29:13 +0000
Subject: [Kolab-devel] [issue3003] The "abonemment" link for calendars in
	kronolith does not work with Kolab
Message-ID: <1219476553.51.0.823723417661.issue3003@intevation.de>


New submission from Gunnar Wrobel <p at rdus.de>:

As this is a non-working link it should either be removed or fixed.

----------
assignedto: wrobel
messages: 16335
nosy: bernhard, sascha.wilde, thomas, wrobel
priority: minor bug
status: unread
title: The "abonemment" link for calendars in kronolith does not work with Kolab
topic: horde
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3003>
___________________________________________________


From kolab-issues at intevation.de  Sat Aug 23 09:31:01 2008
From: kolab-issues at intevation.de (Gunnar Wrobel)
Date: Sat, 23 Aug 2008 07:31:01 +0000
Subject: [Kolab-devel] [issue3004] The free7busy url given by horde should
	be the Kolab one
Message-ID: <1219476661.26.0.00987836187401.issue3004@intevation.de>


New submission from Gunnar Wrobel <p at rdus.de>:

Horde displays the Horde free/busy url in the preferences. This is irritating as
Kolab uses a different one.

----------
assignedto: wrobel
messages: 16336
nosy: bernhard, sascha.wilde, thomas, wrobel
priority: minor bug
status: unread
title: The free7busy url given by horde should be the Kolab one
topic: horde
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3004>
___________________________________________________


From kolab-issues at intevation.de  Sat Aug 23 15:55:12 2008
From: kolab-issues at intevation.de (Richard Bos)
Date: Sat, 23 Aug 2008 13:55:12 +0000
Subject: [Kolab-devel] [issue3005] Remove specific TLSCertificate code by
	using new bootstrap_config conditional in slapd.conf.template
Message-ID: <1219499711.98.0.525868861942.issue3005@intevation.de>


New submission from Richard Bos <ml at radoeka.nl>:

With this patch https://www.intevation.de/roundup/kolab/msg16281 (issue1755), 
that makes it possible to use the @@@ conditionals in the ldap config files
too, it is now possible to remove the specific code that commented out the
the TLSCertificate lines in slapd.conf during booting.

Is it okay to commit the patch (existing of 2 files)?

----------
files: kolabconf_bootstrap_config.patch
messages: 16338
nosy: bernhard, martin, rbos, thomas, wilde, wrobel
priority: bug
status: unread
title: Remove specific TLSCertificate code by using new bootstrap_config conditional in slapd.conf.template
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3005>
___________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kolabconf_bootstrap_config.patch
Type: application/octet-stream
Size: 896 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20080823/0a754e2e/kolabconf_bootstrap_config.exe

From kolab-issues at intevation.de  Sun Aug 24 10:58:46 2008
From: kolab-issues at intevation.de (Richard Bos)
Date: Sun, 24 Aug 2008 08:58:46 +0000
Subject: [Kolab-devel] [issue3006] Surround the horde schema include in
	slapd.conf.template with @@@ conditionals
Message-ID: <1219568326.26.0.478814504758.issue3006@intevation.de>


New submission from Richard Bos <ml at radoeka.nl>:

Until now the include in slapd.conf.template for horde is always commented
out.  As it is now possible to use @@@if conditionals in this template,
that particular line can be surround with the @@@conditials, see e.g. the
patch below:

diff -u -r1.21 slapd.conf.template.in
--- slapd.conf.template.in      14 Aug 2008 19:33:06 -0000      1.21
+++ slapd.conf.template.in      24 Aug 2008 08:42:57 -0000
@@ -21,7 +21,9 @@
 include @ldapserver_schemadir@/inetorgperson.schema
 include @ldapserver_schemadir@/rfc2739.schema
 include @ldapserver_schemadir@/kolab2.schema
-#include @ldapserver_schemadir@/horde.schema
+@@@if enable_horde@@@
+include @ldapserver_schemadir@/horde.schema
+@@@endif@@@

kolaconf has been tested with this and it works as expected, just
add the line enable_horde : true in the kolab.conf and the line is included.
Is the name enable_horde okay, or should it be different like horde_enable,
or just horde?

Is it okay to commit this patch?

----------
messages: 16344
nosy: bernhard, martin, rbos, thomas, wilde, wrobel
priority: minor bug
status: unread
title: Surround the horde schema include in slapd.conf.template with @@@ conditionals
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3006>
___________________________________________________


From bernhard at intevation.de  Tue Aug 26 10:49:35 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 26 Aug 2008 10:49:35 +0200
Subject: [Kolab-devel] Choosing between kontact and kmail
In-Reply-To: <200808151044.30267.marc@kdab.net>
References: <200610021651.23322.dfaure@klaralvdalens-datakonsult.se>
	<200808151044.30267.marc@kdab.net>
Message-ID: <200808261049.37434.bernhard@intevation.de>

On Friday 15 August 2008 10:44, Marc Mutz wrote:
> On Monday October 2 2006, David Faure wrote:
> > Given that kmail (in kde-3.5) or kontact (in proko2) is auto-started when
> > korganizer, kaddressbook, korgac, or knotes is started, (to provide the
> > calendar/contact/notes data), there needs to be a way for the user to
> > select whether kmail or kontact should be autostarted.
> >
> > I have now implemented a shell-script which lets you choose between kmail
> > and kontact as the "imap resource backend". Simply run the attached
> > script, first without arguments to check your current setup, and then
> > with either kmail or kontact as argument.
>
> I needed to add a few chmod's for it to work. not sure it's a problem of
> the script or of the Intevation packages I use.
>
> Changed script attached.

Thanks, we'll update our enterprise35 accordingly.

I think that the default with enterprise35 actually should be kontact,
is this already the case? 

-- 
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


From bernhard at intevation.de  Tue Aug 26 12:38:11 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 26 Aug 2008 12:38:11 +0200
Subject: [Kolab-devel]
	=?iso-8859-1?q?Modifying_the_LDAP_user_representati?=
	=?iso-8859-1?q?on_for_a=09distributed_Kolab_server_system=3F?=
In-Reply-To: <20080815064150.15837km92i9ik18o@devmail.pardus.de>
References: <871w1drtk6.fsf@home.pardus.de>
	<200808140949.59704.bernhard@intevation.de>
	<20080815064150.15837km92i9ik18o@devmail.pardus.de>
Message-ID: <200808261238.12841.bernhard@intevation.de>

On Friday 15 August 2008 06:41, Gunnar Wrobel wrote:
> Quoting Bernhard Reiter <bernhard at intevation.de>:
> > On Tuesday 29 July 2008 14:05, Gunnar Wrobel wrote:
> >> Inventing a new Kolab user LDAP attribute for each and every service
> >> of the Kolab server to support such splitting seems like an overhead
> >> and people did not like the suggestion too much.
> >>
> >> So let me suggest an alternative by using the existing
> >> "kolabHomeserver" attribute. Would it be okay to extend its syntax to
> >> allow for several settings like:
> >>
> >>   "example.org"
> >>   "MTA:smtp.example.org"
> >>   "IMAP:imap.example.org"
> >>   "FreeBusy:fb.example.org"
> >>
> >> The default would be the entry without "prefix:" but it would be
> >> possible to provide redirects for specific services.
> >
> > This looks quite ugly to me. Somehow inventing more parsing within
> > an LDAP attribute really feel wrong to me.
> > So if we need the attributes, we can for sure come up with enough for
> > them.
>
> Okay, I agree with the parsing thing.
>
> > I am not sure that we need it per user, though.
>
> p at rdus does :) If you have an array of IMAP servers behind an MTA
> layer the MTA layer should actually know which IMAP server to deliver
> to. And that is per user. I know this is not possible with
> Kolab2/OpenPKG at the moment but such distributed setup are feasible
> with Kolab.

Ah, you also want to split up below one homeserver. 
Of course, if you want to do this, it needs to be saved somewhere.
For most deployment I would normally recommend having one imap server (which 
can be a cluster) per homeserver. It does not hurt to have one MTA per IMAP 
server and might help in many situations. I guess this is why I did not get 
the idea.

> > For the user, most should be transparent (means: not visible).
>
> The admin sets this stuff in the web admin frontend. It should
> obviously not be editable by the user as this concerns the server
> infrastructure and is no user setting.
>
> > This is why I am also against putting anything server specific in the
> > login information. This could change during the lifetime of an account.
>
> Login information? Sorry, didn't understand this comment. Can you clarify?

I believe I've refered to the upcoming point where I saw "USER:PASS at SERVER"
and I wanted to outrule this as part of an LDAP entry.
>
> >> If I consider the point Bernhard mentioned recently concerning
> >> splitted IMAP storage per user it might also make sense to have a
> >> syntax like
> >>  "imap://USER:PASS at SERVER"
> >
> > For what in particular?
> > The splitted IMAP storage will only be known the the user's client
> > mostly.
>
> So the user would set the storage spaces in Kontact and in the Kolab
> web client again? 

Yes. 
Even if we find a desired way of saving client configuration on one server
somehow.

> Storing that in LDAP would remove this redundancy or not?

It would, but it would also defeat the security aspect of the idea.
If you have server A and server B, you would not want admin of server
A to be able to log into server B to have some separation. :)
So putting credentials in the directory service of server A 
is not that helpful. 



-- 
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: 189 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20080826/ada13c7d/attachment.bin

From bernhard at intevation.de  Tue Aug 26 14:16:52 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 26 Aug 2008 14:16:52 +0200
Subject: [Kolab-devel] roundup: changed keyword "horde" -> "web client"
Message-ID: <200808261416.58576.bernhard@intevation.de>

For clarity reasons,
I've just changed the keyword "horde" to "web client" 
in the Kolab issue tracker. 

Till, myself and Gunnar had a chat a while ago and found
that using horde regarding Kolab Server and its web client can 
be suboptimal for a few reasons.

One is that components from Horde are also used for freebusy
and invitation handling tasks both which are not making up the web client.
Kolab's web client that comes with Kolab Server by default
is based on the Free Software Horde (http://www.horde.org/)
and the great work of the Horde community.

Best, 
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: 189 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20080826/1f4bfe18/attachment.bin

From kolab-issues at intevation.de  Wed Aug 27 09:20:36 2008
From: kolab-issues at intevation.de (Sophia U Mcghee)
Date: Wed, 27 Aug 2008 07:20:36 +0000
Subject: [Kolab-devel] [issue3008] Den Tists Database in the US
Message-ID: <218328z5xsw0$l8433mv0$2801e2m0@Delldim5150


New submission from Sophia U Mcghee <Courtney_Lyman at gmail.com>:

Have a look at this new Database

<> 164,533 Dentist.s 
<> 158,309 Addresses
<> 163,562 Contact Phone #
<> 77,446 Office Fax #
<> 45,120 Email Addys

Up to Aug 29 the reduced price is $292 (reg $495)

Send an email to MagdalenaYbarra at fceating.com to inquire about this and other Contact List we have

Send us an email to r557 at fceating.com we will discontinue from the list

----------
messages: 16375
nosy: 010081, 1299-47-mh218, Courtney_Lyman, bill, bridgett, equipment, madriz713, photos
status: unread
title: Den Tists Database in the US
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3008>
___________________________________________________


From kolab-issues at intevation.de  Wed Aug 27 15:45:12 2008
From: kolab-issues at intevation.de (=?utf-8?q?Emanuel_Sch=C3=BCtze?=)
Date: Wed, 27 Aug 2008 13:45:12 +0000
Subject: [Kolab-devel] [issue3010] Mac: Unable to create IMAP calendar
	resource
Message-ID: <1219844712.26.0.350691497136.issue3010@intevation.de>


New submission from Emanuel Sch?tze <emanuel at intevation.de>:

1. Configure a disconnected IMAP account (mail reseiving/sending and contacts
IMAP resource works).
2. Add a new Calendar resource. 
3. Choose "Calendar on IMAP Server via KMail".
-> Error dialog: "Unable to create resource of type imap."

----------
assignedto: till
messages: 16384
nosy: bernhard, emanuel, till
priority: urgent
status: unread
title: Mac: Unable to create IMAP calendar resource
topic: kowi, macos
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3010>
___________________________________________________


From kolab-issues at intevation.de  Wed Aug 27 15:52:22 2008
From: kolab-issues at intevation.de (=?utf-8?q?Emanuel_Sch=C3=BCtze?=)
Date: Wed, 27 Aug 2008 13:52:22 +0000
Subject: [Kolab-devel] [issue3011] Mac: Resize Kontact window not possible
Message-ID: <1219845142.74.0.444196223863.issue3011@intevation.de>


New submission from Emanuel Sch?tze <emanuel at intevation.de>:

An individual resizing of Kontact window is not possible.
Tested with KDEonMac 20080825 (KDE 4.1.62 20080814)

----------
assignedto: till
messages: 16385
nosy: bernhard, emanuel, till
priority: urgent
status: unread
title: Mac: Resize Kontact window not possible
topic: kde client, kowi, macos
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3011>
___________________________________________________


From kolab-issues at intevation.de  Wed Aug 27 15:59:40 2008
From: kolab-issues at intevation.de (=?utf-8?q?Emanuel_Sch=C3=BCtze?=)
Date: Wed, 27 Aug 2008 13:59:40 +0000
Subject: [Kolab-devel] [issue3012] Mac: Kontact doesn't really quit with
	[cmd]+Q
Message-ID: <1219845580.78.0.273881569331.issue3012@intevation.de>


New submission from Emanuel Sch?tze <emanuel at intevation.de>:

Try to quit Kontact with the [cmd]+Q shortcut. 
-> Kontact window closed. But menu bar and empty kontact process (see
[cmd]+[alt]+[esc]) already running.

If you quit Kontat with clicking on the red close button, the program closed
correctly.

----------
assignedto: till
messages: 16386
nosy: bernhard, emanuel, till
priority: urgent
status: unread
title: Mac: Kontact doesn't really quit with [cmd]+Q
topic: kde client, kowi, macos
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3012>
___________________________________________________


From kolab-issues at intevation.de  Thu Aug 28 13:23:29 2008
From: kolab-issues at intevation.de (Hannah Melvin)
Date: Thu, 28 Aug 2008 11:23:29 +0000
Subject: [Kolab-devel] [issue3016] Blaue Pillchen - Endlich wieder Spass am
	Leben
Message-ID: <01c90932$c717a480$3e4cda59@cynthia.d.stotts>


New submission from Hannah Melvin <cynthia.d.stotts at mail.sprint.com>:

Online bestellen - original Qualitaet - 100% wirksam

Unsere Kunden:

- Sex ist befriedigender denn je. Stress und Leistungsdruck verschwinden. Sie ist nie wieder frustriert, ich habe keine Angst mehr zu versagen. Es ist ein wundervolles koerperliches Erlebnis, dem ein genauso tiefes Gefuehl folgt. 

- Das Beste an Vi. ist die Sicherheit, dass man "mit Autopilot fliegt", dass man entspannt und ohne Sorgen zur Sache kommen kann, dass der Staender auch haelt, auch wenn man unterbrochen wird (die Kinder klopfen an die Schlafzimmertuer, der Hund bellt, das Kondom sitzt schlecht). Wenn man Vi. bewusst anwendet, kann es auch der Partnerin gegenueber ein grosses Geschenk sein. Nur ein Rat: Sagen Sie ihr nicht, dass Sie es verwenden, das weibliche Selbstwertgefuehl ist genauso verletzlich wie das unsere.

Angebote des Monats: 
NEU - Vi. Super Active 100 mg 30 Tab. 81,08 Euro
Vi. 10 Tab. 100 mg + Ci. 10 Tab. x 20 mg 48,95 Euro 

Vi. 10 Tab. 22,60 Euro
Vi. 30 Tab. 55,00 Euro - Sie sparen: 17,00 Euro
Vi. 60 Tab. 82,70 Euro - Sie sparen: 53,00 Euro
Vi. 90 Tab. 118,00 Euro - Sie sparen: 85,00 Euro

Ci. 10 - 27,00 Euro
Ci. 20 - 54,00 Euro - Sie sparen: 2,00 Euro
Ci. 30 - 72,00 Euro - Sie sparen: 11,00 Euro

- kostenlose, arztliche Telefon-Beratung
- diskrete Verpackung 
- kein peinlicher Arztbesuch erforderlich
- kein langes Warten - Auslieferung innerhalb von 2-3 Tagen
- diskrete Zahlung
- Visa verifizierter Onlineshop
- bequem und diskret online bestellen.
- keine versteckte Kosten

Bestellen Sie noch heute und vergessen Sie Ihre Enttaeuschungen, anhaltende Versagensaengste und wiederholte peinliche Situationen

http://img523.imageshack.us/img523/188/ibsgncinufv3.swf

----------
messages: 16400
nosy: cynthia.d.stotts
status: unread
title: Blaue Pillchen - Endlich wieder Spass am Leben
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3016>
___________________________________________________


From kolab-issues at intevation.de  Thu Aug 28 16:41:45 2008
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Thu, 28 Aug 2008 14:41:45 +0000
Subject: [Kolab-devel] [issue3017] Crash in KCal::Incidence::revision
Message-ID: <1219934505.72.0.340798110805.issue3017@intevation.de>


New submission from Bernhard Reiter <bernhard at intevation.de>:

Kontact: 1.2.9 (enterprise35 20080826.852422)   
   
Clicked around and got a backtrace, starting with  
[KCrash handler] 
#5  KCal::Incidence::revision (this=0xbfcdff34) at incidence.cpp:249 
#6  0xb66a854b in KCal::IncidenceFormatter::formatICalInvitation ( 
    invitation=@0xbfce01c8, mCalendar=0xbfce00ac, helper=0xbfce01a0) 
    at incidenceformatter.cpp:1284 
#7  0xb2ab1dcb in (anonymous namespace)::Formatter::format (this=0x836f0d0,  
    bodyPart=0xbfce0268, writer=0x8471210) at text_calendar.cpp:173 
#8  0xb51aa3dd in KMail::ObjectTreeParser::parseObjectTree (this=0xbfce0308,  
    node=0x8818690) at objecttreeparser.cpp:271 
#9  0xb51aafa1 in KMail::ObjectTreeParser::insertAndParseNewChildNode ( 
    this=0xbfce0708, startNode=@0x882ba50,  
    content=0x8887220 "Received: from localhost (localhost [127.0.0.1])\n\tby 
neso.test.hq (Postfix) with ESMTP id D4E488F5FC;\n\tFri, 11 Jul 2008 16:54:44 
+0200 (CEST)\nX-Virus-Scanned: by amavisd-new at test.hq\nReceived: from "...,  
    cntDesc=0xb535d963 "encapsulated message", append=false) 
    at objecttreeparser.cpp:226 
#10 0xb51abdcb in KMail::ObjectTreeParser::processMessageRfc822Subtype ( 
    this=0xbfce0708, node=0x882ba50) at objecttreeparser.cpp:1329 
#11 0xb51b43cb in (anonymous 
namespace)::MessageRfc822BodyPartFormatter::process (this=0x8836b08, 
otp=0xbfce0708, node=0x882ba50, result=@0xbfce06a8) 
    at bodypartformatter.cpp:119 
#12 0xb51aa655 in KMail::ObjectTreeParser::parseObjectTree (this=0xbfce0708,  
    node=0x882ba50) at objecttreeparser.cpp:294 
#13 0xb51aa70e in KMail::ObjectTreeParser::stdChildHandling (this=0xbfce0a10,  
    child=0x881c528) at objecttreeparser.cpp:1061 
#14 0xb51aa9c2 in KMail::ObjectTreeParser::processMultiPartMixedSubtype ( 
    this=0xbfce0a10, node=0x8822138) at objecttreeparser.cpp:1074 
#15 0xb51b438b in (anonymous 
namespace)::MultiPartMixedBodyPartFormatter::process (this=0x8836d88, 
otp=0xbfce0a10, node=0x8822138, result=@0xbfce0848) 
    at bodypartformatter.cpp:121 
#16 0xb51aa655 in KMail::ObjectTreeParser::parseObjectTree (this=0xbfce0a10,  
    node=0x8822138) at objecttreeparser.cpp:294 
#17 0xb508b851 in KMReaderWin::parseMsg (this=0x844e918, aMsg=0x8870260) 
    at kmreaderwin.cpp:1588 
#18 0xb5084204 in KMReaderWin::displayMessage (this=0x844e918) 
    at kmreaderwin.cpp:1514 
#19 0xb50843e6 in KMReaderWin::updateReaderWin (this=0x844e918) 
    at kmreaderwin.cpp:1449 
#20 0xb5086ffd in KMReaderWin::qt_invoke (this=0x844e918, _id=48,  
    _o=0xbfce0ddc) at kmreaderwin.moc:301

----------
messages: 16405
nosy: bernhard, ludwig, till, vkrause
priority: bug
status: unread
title: Crash in KCal::Incidence::revision
topic: kde client, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3017>
___________________________________________________


From kolab-issues at intevation.de  Sat Aug 30 16:26:08 2008
From: kolab-issues at intevation.de (Bart Jan Kelter)
Date: Sat, 30 Aug 2008 14:26:08 +0000
Subject: [Kolab-devel] [issue3018] Postfix warings running Kolab 2.2 stable
	on FreeBSD 7.0 AMD64
Message-ID: <1220106368.15.0.287115821344.issue3018@intevation.de>


New submission from Bart Jan Kelter <bartjan at kelter.nl>:

Last week I managed to build Kolab 2.2 stable on FreeBSD 7.0. (See also issue 2349)
I could run /kolab_bootstrap without errors.
When I started Kolab I've got warnings in postfix.log:

Aug 26 15:06:09 mail.vandentempel.nl <warning> postfix/postfix-script[97860]:
warning: not owned by root: /kolab/etc/postfix/ldapdistlist.cf
Aug 26 15:06:09 mail.vandentempel.nl <warning> postfix/postfix-script[97861]:
warning: not owned by root: /kolab/etc/postfix/ldaptransport.cf
Aug 26 15:06:09 mail.vandentempel.nl <warning> postfix/postfix-script[97862]:
warning: not owned by root: /kolab/etc/postfix/ldapvirtual.cf
Aug 26 15:06:09 mail.vandentempel.nl <warning> postfix/postfix-script[97863]:
warning: not owned by root: /kolab/etc/postfix/main.cf
Aug 26 15:06:09 mail.vandentempel.nl <warning> postfix/postfix-script[97864]:
warning: not owned by root: /kolab/etc/postfix/master.cf

----------
messages: 16422
nosy: BartJan
priority: minor bug
status: unread
title: Postfix warings running Kolab 2.2 stable on FreeBSD 7.0 AMD64
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3018>
___________________________________________________


From kolab-issues at intevation.de  Sat Aug 30 16:31:29 2008
From: kolab-issues at intevation.de (Bart Jan Kelter)
Date: Sat, 30 Aug 2008 14:31:29 +0000
Subject: [Kolab-devel] [issue3019] Postfix/SASL errors running Kolab 2.2
	stable on FreeBSD 7.0 AMD64
Message-ID: <1220106688.95.0.254050315932.issue3019@intevation.de>


New submission from Bart Jan Kelter <bartjan at kelter.nl>:

Last week I managed to build Kolab 2.2 stable on FreeBSD 7.0. (See also issue
2349 and issue 3018)
I could run /kolab_bootstrap without errors.
When I tried to deliver mail using SMTP (telnet to port 25, helo etc.), I got
critcal error messages regarding SASL startup in the postfix.log.

Aug 26 15:06:09 mail.vandentempel.nl <info> postfix/postfix-script[97934]:
starting the Postfix mail system
Aug 26 15:06:09 mail.vandentempel.nl <info> postfix/master[97935]: daemon
started -- version 2.4.6, configuration /kolab/etc/postfix
Aug 26 15:06:40 mail.vandentempel.nl <warning> postfix/smtpd[98046]: warning:
xsasl_cyrus_server_get_mechanism_list: no applicable SASL mechanisms
Aug 26 15:06:40 mail.vandentempel.nl <critical> postfix/smtpd[98046]: fatal: no
SASL authentication mechanisms
Aug 26 15:06:41 mail.vandentempel.nl <warning> postfix/master[97935]: warning:
process /kolab/libexec/postfix/smtpd pid 98046 exit status 1
Aug 26 15:06:41 mail.vandentempel.nl <warning> postfix/master[97935]: warning:
/kolab/libexec/postfix/smtpd: bad command startup -- throttling

----------
messages: 16423
nosy: BartJan
priority: critical
status: unread
title: Postfix/SASL errors running Kolab 2.2 stable on FreeBSD 7.0 AMD64
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3019>
___________________________________________________


From kolab-issues at intevation.de  Sat Aug 30 16:42:58 2008
From: kolab-issues at intevation.de (Bart Jan Kelter)
Date: Sat, 30 Aug 2008 14:42:58 +0000
Subject: [Kolab-devel] [issue3020] Mailforlders are not created with Kolab
	2.2 stable on FreeBSD 7.0 AMD64
Message-ID: <1220107378.18.0.691240529862.issue3020@intevation.de>


New submission from Bart Jan Kelter <bartjan at kelter.nl>:

I managed to build Kolab 2.2 stable on FreeBSD 7.0. (See also issue
2349, 3018 and 3019). 
I did run kolab_bootstrap without errors.
When we added the users with the web interface no mailfolders where created.

When I tried to connect with an IMAP client I've got th emessages "mailfolder
does not exist"
When I tried to send mail to the server teh message is bounced. I've got the
following messages in postfix.log:

Aug 27 14:15:34 mail.vandentempel.nl <info> postfix/smtpd[30120]: connect from
gerald.tempel.nl[192.92.9.202]
Aug 27 14:16:19 mail.vandentempel.nl <info> postfix/smtpd[30120]: 75F0F2F327:
client=gerald.tempel.nl[192.92.9.202]
Aug 27 14:16:37 mail.vandentempel.nl <info> postfix/cleanup[30123]: 75F0F2F327:
message-id=<20080827121619.75F0F2F327 at mail.vandentempel.nl>
Aug 27 14:16:37 mail.vandentempel.nl <info> postfix/qmgr[29867]: 75F0F2F327:
from=<>, size=376, nrcpt=1 (queue active)
Aug 27 14:16:38 mail.vandentempel.nl <info> postfix/smtpd[30126]: connect from
localhost[127.0.0.1]
Aug 27 14:16:38 mail.vandentempel.nl <info> postfix/smtpd[30126]: 6F8D32F346:
client=localhost[127.0.0.1]
Aug 27 14:16:38 mail.vandentempel.nl <info> postfix/cleanup[30127]: 6F8D32F346:
message-id=<20080827121619.75F0F2F327 at mail.vandentempel.nl>
Aug 27 14:16:38 mail.vandentempel.nl <info> postfix/qmgr[29867]: 6F8D32F346:
from=<>, size=572, nrcpt=1 (queue active)
Aug 27 14:16:38 mail.vandentempel.nl <info> postfix/smtpd[30126]: disconnect
from localhost[127.0.0.1]
Aug 27 14:16:38 mail.vandentempel.nl <info> postfix/pipe[30124]: 75F0F2F327:
to=<test at vandentempel.nl>, relay=kolabfilter, delay=35, delays=34/0.07/0/0.84,
dsn=2.0.0, status=sent (delivered via kolabfilter service)
Aug 27 14:16:38 mail.vandentempel.nl <info> postfix/qmgr[29867]: 75F0F2F327: removed
Aug 27 14:16:39 mail.vandentempel.nl <info> postfix/smtpd[30130]: connect from
localhost[127.0.0.1]
Aug 27 14:16:39 mail.vandentempel.nl <info> postfix/smtpd[30130]: 06D052F34C:
client=localhost[127.0.0.1]
Aug 27 14:16:39 mail.vandentempel.nl <info> postfix/cleanup[30127]: 06D052F34C:
message-id=<20080827121619.75F0F2F327 at mail.vandentempel.nl>
Aug 27 14:16:39 mail.vandentempel.nl <info> postfix/smtpd[30130]: disconnect
from localhost[127.0.0.1]
Aug 27 14:16:39 mail.vandentempel.nl <info> postfix/qmgr[29867]: 06D052F34C:
from=<>, size=1029, nrcpt=1 (queue active)
Aug 27 14:16:39 mail.vandentempel.nl <info> postfix/smtp[30128]: 6F8D32F346:
to=<test at vandentempel.nl>, relay=127.0.0.1[127.0.0.1]:10024, delay=0.63,
delays=0.15/0.07/0.01/0.4, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as
06D052F34C)
Aug 27 14:16:39 mail.vandentempel.nl <info> postfix/qmgr[29867]: 6F8D32F346: removed
Aug 27 14:16:39 mail.vandentempel.nl <info> postfix/pipe[30132]: 06D052F34C:
to=<test at vandentempel.nl>, relay=kolabmailboxfilter, delay=0.46,
delays=0.04/0.12/0/0.3, dsn=5.3.0, status=bounced (service unavailable. Command
output: Failed to set recipient: Mailbox unknown.  Either there is no mailbox
associated with this name or you do not have authorization to see it. 5.1.1 User
unknown, code=550, original code 550)
Aug 27 14:16:39 mail.vandentempel.nl <info> postfix/qmgr[29867]: 06D052F34C: removed

So something went wrong with the user creation step.
I'm wondering is this has somethng to do with the build problems I had with
imapd (see issue 2349) or with SASL (SASL compiled without errors, but see issue
3019 about postfix<->sasl errors) 

Regards,
Bart Jan kelter

----------
messages: 16424
nosy: BartJan
priority: critical
status: unread
title: Mailforlders are not created with Kolab 2.2 stable on FreeBSD 7.0 AMD64
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3020>
___________________________________________________


From kolab-issues at intevation.de  Wed Aug 27 11:43:40 2008
From: kolab-issues at intevation.de (=?utf-8?q?Emanuel_Sch=C3=BCtze?=)
Date: Wed, 27 Aug 2008 09:43:40 -0000
Subject: [Kolab-devel] [merge82] Mac: Kontact crashes at start if
	Kolabwizard has set configuration before
Message-ID: <1219830214.55.0.657668066398.merge82@intevation.de>


New submission from Emanuel Sch?tze <emanuel at intevation.de>:

Test with KDEonMac 20080825:

1. Install all KDEonMac packages
2. Clear ~/Library/Preferences/KDE dir
3. Run /opt/kde4/bin/kolabwizard.app and configure a new Kolab account.
4. Run /opt/kde4/bin/Kontact.app
-> Crash!

error report attached.

----------
assignedto: till
files: kontact-mac-crash-20080827-1_fehlerbericht.txt
messages: 16376
nosy: bernhard, emanuel, till
status: unread
title: Mac: Kontact crashes at start if Kolabwizard has set configuration before
_________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/merge82>
_________________________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: kontact-mac-crash-20080827-1_fehlerbericht.txt
Url: http://kolab.org/pipermail/kolab-devel/attachments/20080827/6546102e/kontact-mac-crash-20080827-1_fehlerbericht-0001.txt

From kolab-issues at intevation.de  Wed Aug 27 11:44:50 2008
From: kolab-issues at intevation.de (=?utf-8?q?Emanuel_Sch=C3=BCtze?=)
Date: Wed, 27 Aug 2008 09:44:50 -0000
Subject: [Kolab-devel] [merge83] Mac: Kontact crashes at start if
	Kolabwizard has set configuration before
Message-ID: <1219830286.08.0.919415274842.merge83@intevation.de>


New submission from Emanuel Sch?tze <emanuel at intevation.de>:

Test with KDEonMac 20080825:

1. Install all KDEonMac packages
2. Clear ~/Library/Preferences/KDE dir
3. Run /opt/kde4/bin/kolabwizard.app and configure a new Kolab account.
4. Run /opt/kde4/bin/Kontact.app
-> Crash!

error report attached.

----------
assignedto: till
files: kontact-mac-crash-20080827-1_fehlerbericht.txt
messages: 16377
nosy: bernhard, emanuel, till
priority: critical
status: unread
title: Mac: Kontact crashes at start if Kolabwizard has set configuration before
_________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/merge83>
_________________________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: kontact-mac-crash-20080827-1_fehlerbericht.txt
Url: http://kolab.org/pipermail/kolab-devel/attachments/20080827/2345a9b4/kontact-mac-crash-20080827-1_fehlerbericht-0001.txt

From kolab-issues at intevation.de  Wed Aug 27 11:51:38 2008
From: kolab-issues at intevation.de (=?utf-8?q?Emanuel_Sch=C3=BCtze?=)
Date: Wed, 27 Aug 2008 09:51:38 -0000
Subject: [Kolab-devel] [issue3009] Mac: Kontact crashes at start if
	Kolabwizard has set configuration before
Message-ID: <1219830691.22.0.542843759057.issue3009@intevation.de>


New submission from Emanuel Sch?tze <emanuel at intevation.de>:

Test with KDEonMac 20080825:

1. Install all KDEonMac packages
2. Clear ~/Library/Preferences/KDE dir
3. Run /opt/kde4/bin/kolabwizard.app and configure a new Kolab account.
4. Run /opt/kde4/bin/Kontact.app
-> Crash!

error report attached.

----------
assignedto: till
files: kontact-mac-crash-20080827-1_fehlerbericht.txt
messages: 16379
nosy: bernhard, emanuel, till
priority: critical
status: unread
title: Mac: Kontact crashes at start if Kolabwizard has set configuration before
topic: kowi, macos
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3009>
___________________________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: kontact-mac-crash-20080827-1_fehlerbericht.txt
Url: http://kolab.org/pipermail/kolab-devel/attachments/20080827/cbdac78d/kontact-mac-crash-20080827-1_fehlerbericht-0001.txt

From marc at kdab.net  Wed Aug 27 18:45:41 2008
From: marc at kdab.net (Marc Mutz)
Date: Wed, 27 Aug 2008 16:45:41 -0000
Subject: [Kolab-devel] Choosing between kontact and kmail
In-Reply-To: <200808261049.37434.bernhard@intevation.de>
References: <200610021651.23322.dfaure@klaralvdalens-datakonsult.se>
	<200808151044.30267.marc@kdab.net>
	<200808261049.37434.bernhard@intevation.de>
Message-ID: <200808271848.57759.marc@kdab.net>

On Tuesday August 26 2008, Bernhard Reiter wrote:
> I think that the default with enterprise35 actually should be kontact,
> is this already the case?

I use it to switch back to kmail :)

Seriously, while I have your attention, the apt.intevation.org packages should 
not overwrite the config files. Real Debian packages prompt to preserve 
changes. Yours break my setup every single upgrade, since they just hard-code 
kontact. Thus the need for this script. Actually, the script needs to be run 
thrice, since apparently kmail's desktop file already contains a ServiceType. 
not sure what that means, but the script is unhappy...

Thanks,
Marc

-- 
Marc Mutz - marc at kdab.com, mutz at kde.org - Klar?lvdalens Datakonsult AB
Platform-independent software solutions - www.kdab.com info at kdab.com