Florian Oszwald | 1 Dec 2008 08:52
Picon

Re: Kolab-users Digest, Vol 57, Issue 37

Am Samstag 29 November 2008 23:03:58 schrieb kolab-users-request <at> kolab.org:
> Quoting Florian Oszwald <oszwald <at> web.de>:
> > Hi all,
> >
> > I now have horde installed working together with kolab on opensuse 10.2.
> >
> > The problem is, that i get the message DB Error: not found everytime I
> > log in on a new day or making a new entry in the calendar or in notes.
> >
> > In /var/log/horde/horde.log I do not get any useful information about
> > this problem. On the internet I found, that it might be related to the
> > SQL, but I am using it together with Kolab, so there is no need for sql,
> > is there?
>
> Correct. In general there is no need for a database. If Horde gives  
> you this error the configuration provided by the package maintainers  
> is broken and you should submit a bug concerning the package.
>
> For newer Horde/Kolab installations you need a database if you want to  
> use SyncML. But it should be sufficient if this is based on sqlite and  
> I see it as a package maintainers task to provide a correctly  
> preconfigured database in that case.
>
> Cheers,
>
> Gunnar

Hi Gunnar,
thank you very much for your email.
Would it be possible to somehow narrow it a little bit more down, so I can 
(Continue reading)

Carsten Burghardt | 1 Dec 2008 09:37

Re: Mail not rejected

Quoting "ITSEF Admin" <itsef-admin <at> brightsight.com>:

> On Friday 14 November 2008 20:56:55 Carsten Burghardt wrote:
>> I tested some usernames and noticed an (for me) inconsistent
>> behaviour. A mail to mail <at> mydomain is accepted whereas
>> nonsense <at> mydomain is rejected. I have not created an alias entry for
>> "mail" that is for sure.
>
> Is "mail <at> domain" the only "strange" address that works? "mail <at> domain" *seems*
> to be a standard address that always work. I have not been able to track down
> where this is defined or where Kolab enables this, but it sure
> worked "out-of-the-box" on our Kolab server as well (2.0.x and 2.1).

Thanks for the information as that seems to be the case. Unfortunately  
a lot of the spam senders also know this.

Carsten
Loïc Elineau | 1 Dec 2008 09:59
Picon
Favicon

Re: Add logging info for untrusted sender

Hy,
> > I don't want kolab to add "UNTRUSTED", I'd like it to respond with 550
> > error.
>
> Should be possible by switching to "Reject forged from header" in the
> Kolab web admin "Service" tab.
>
Isn't it supposed to implie problems with mailing lists subscribtions such as 
this one?
I'll try it

Cheers

--

-- 
Loïc Elineau
http://www.benefacere.fr/
Loïc Elineau | 1 Dec 2008 10:06
Picon
Favicon

Re: Add logging info for untrusted sender

Hello
>
> Sorry I didn(t know about the "UNTRUSTED" label added by kolab, I was
> thinking about
> something else.
> Do you want to deny any unauthenticated connection ?
>
Yes, but it isn't possible if I want kolab to deliver mails from external. The 
problems deal with "reject forged from header" as write by Gunnar. But if I 
check this option, I am afraid I won't receive kolab-users messages any more, 
as the "to" field doesn't equals to me. I try it....

best regards,

--

-- 
Loïc Elineau
http://www.benefacere.fr/
Loïc Elineau | 1 Dec 2008 10:11
Picon
Favicon

Re: Add logging info for untrusted sender

>
> Should be possible by switching to "Reject forged from header" in the
> Kolab web admin "Service" tab.
>
it seems it's working without I lost mail from mailing lists. There must be 
anything wrong in the assertion:
"Always reject the message. Note that enabling this setting will make the 
server reject any mail with non-matching sender and From header if the sender 
is an account on this server. This is known to cause trouble for example with 
mailinglists. "

I'll wait a few days to validate that I don't receive any more spams from 
"UNSTRUSTED me" :D

Cheers

--

-- 
Loïc Elineau
http://www.benefacere.fr/
Albrecht Dreß | 2 Dec 2008 10:37
Favicon

Re: Log Rotation Question

Am 29.11.2008 22:35:00 schrieb(en) Gunnar Wrobel:
> The notices can in fact be ignored. Though I hope they are gone with  
> Kolab Server 2.2.1.
[snipped descriptions]

Thanks for the clarification - the important message is that there is  
nothing I really have to worry about...

Best, Albrecht.

Dr. Albrecht Dreß
LIOS Technology GmbH
R & D - Software Design
Schanzenstrasse 39 / Building D9-D13
D-51063 Cologne / Germany
Phone +49 221 99887 401
Fax   +49 221 99887 150
Managing Director: Thomas Oldemeyer
Registration Court Amtsgericht Cologne, Reg.-No. HRB 33482
Albrecht Dreß | 2 Dec 2008 10:59
Favicon

Duplication of appointments in shared calendar

Hi,

I have a *really* nasty problem with the duplication of appointments in  
a shared calendar.  I run a self-compiled Kolab 2.2.0 on Ubuntu  
8.04/64.  My users (~35) use Outlook 2002/2003/2007 through the latest  
Toltec connector.

The problem occurs on a shared calendar for which all users have write  
access.  Periodically, *all* appointments in this calendar get  
mysteriously duplicated, and in some cases they occur even more times  
(I saw up to 8 copies of the same one).  Sometimes the attributes of  
the copies are slightly different (e.g. the background colour displayed  
in Outlook is changed).

I tried to follow (in imapd.log) who adds the "spam" to the calendar,  
and temporarily de-activated write access for those users, but  
apparently many of them seem to trigger this problem.

Is this a known problem?  In Toltec or in Kolab?  Any idea how I can  
solve this bug?  It is somewhat annoying to manually erase the  
duplicates manually every day...

Thanks,
Albrecht.
Gregor Adamczyk | 2 Dec 2008 12:30
Picon

How-To activate RBL (Spamhaus), the SpamAssassin way

Halo, I have some trouble with activating SPAMHAUS RBL and another in
Kolab 2.2.

I don't really understand the working mechanism from amavisd-new.

I read already some FAQ but this don't help me to understand the situation.

In the FAQ: http://www.ijs.si/software/amavisd/#faq-spam

I read this:
Does SpamAssassin observe settings in its configuration file local.cf?
SA does observe all settings in its configuration file, but not all of
them have effect...

I know that it is possible to activate RBL on two ways.
With SpamAssassin or directly in Postfix.

I think SpamAssassin is the better way, so I test this:

change in:
/kolab/etc/kolab/templates/local.cf.template
score RCVD_IN_SBL 10
score RCVD_IN_XBL 10
score RCVD_IN_PBL 10

change in:
/kolab/etc/kolab/templates/amavisd.conf.template
$sa_local_tests_only = 0;   # (default: false)

then run:
(Continue reading)

Joon Radley | 2 Dec 2008 16:03
Picon

RE: Duplication of appointments in shared calendar

Hi Albrecht,

Can you please direct your Toltec related support questions to
support <at> toltec.co.za. This is the Kolab support mailing list and it is not
vendor specific.

Regards

Joon Radley
Radley Network Technologies CC
Cell: +27 (0)83 368 8557
Fax: +27 (0)12 998 4346
E-mail: joon <at> radleys.co.za
Web: www.toltec.co.za

> -----Original Message-----
> From: kolab-users-bounces <at> kolab.org [mailto:kolab-users-
> bounces <at> kolab.org] On Behalf Of Albrecht Dreß
> Sent: Tuesday, December 02, 2008 12:00 PM
> To: Kolab Users List
> Cc: support <at> toltec.co.za
> Subject: Duplication of appointments in shared calendar
> 
> Hi,
> 
> I have a *really* nasty problem with the duplication of appointments in
> a shared calendar.  I run a self-compiled Kolab 2.2.0 on Ubuntu
> 8.04/64.  My users (~35) use Outlook 2002/2003/2007 through the latest
> Toltec connector.
> 
(Continue reading)

Thomas Arendsen Hein | 2 Dec 2008 18:27
Picon
Favicon

Kolab Security Issue 23 20081202 (clamav)

Kolab Security Issue 23 20081202
================================

Package:              Kolab Server, ClamAV
Vulnerability:        various
Kolab Specific:       no
Dependent Packages:   none

Summary
~~~~~~~

Moritz Jodeit reports that ClamAV up to version 0.94 contains an
off-by-one heap overflow vulnerability in the code responsible for
parsing VBA project files. Successful exploitation could allow an
attacker to execute arbitrary code with the privileges of the `clamd'
process by sending an email with a prepared attachment.

Ilja Van Sprundel reported a denial-of-service vulnerability and an
unconfirmed possibility to run arbitrary code in ClamAV up to version
0.94.1 by sending malformed JPEG files.

Affected Versions
~~~~~~~~~~~~~~~~~

This affects versions of ClamAV up to version 0.94.1
Kolab Server 2.2.0 and previous prereleases are affected.
Kolab Server 2.1.0 and previous releases of the 2.1 branch are affected.
Kolab Server 2.0.4 and previous releases of the 2.0 branch are affected.

Fix
(Continue reading)


Gmane