From werner at pure.ch Sun Feb 5 13:17:00 2023 From: werner at pure.ch (Werner Reisberger) Date: Sun, 05 Feb 2023 13:17:00 +0100 Subject: kolab source Message-ID: <4e6f56bbb3706fbd8fb970f80d9ab0a8@pure.ch> Although Open Source is emphasized as a key principle of running and developing kolab it looks different to me. First of all I cannot easily get to the code. I have seen https://github.com/orgs/kolab-groupware/repositories There are 52 repos and they seem not to be structured and current (most recent one is kolab-docs (2022)). There is a section on kolab.org for contribution but I would have to follow a complicated registration process. In case I want to contribute it's mentioned that I have to work under a Scrum based project (sorry to say that, but I am traumatized with some "Scrum Masters";). Please let me know if I misunderstood something completly. --Werner From werner at pure.ch Sun Feb 5 13:56:32 2023 From: werner at pure.ch (Werner Reisberger) Date: Sun, 05 Feb 2023 13:56:32 +0100 Subject: kolab source In-Reply-To: <4e6f56bbb3706fbd8fb970f80d9ab0a8@pure.ch> References: <4e6f56bbb3706fbd8fb970f80d9ab0a8@pure.ch> Message-ID: <9e13beeca8398666827127574b06dfc9@pure.ch> Sorry, just found the open git repo https://git.kolab.org/source/kolab/ --Werner On 2023-02-05 13:17, Werner Reisberger wrote: > Although Open Source is emphasized as a key principle of running and > developing kolab it looks different to me. First of all I cannot > easily get to the code. I have seen > > https://github.com/orgs/kolab-groupware/repositories > > There are 52 repos and they seem not to be structured and current > (most recent one is kolab-docs (2022)). > > There is a section on kolab.org for contribution but I would have to > follow a complicated registration process. In case I want to > contribute it's mentioned that I have to work under a Scrum based > project (sorry to say that, but I am traumatized with some "Scrum > Masters";). From kolab983 at der-he.de Sun Feb 5 14:53:06 2023 From: kolab983 at der-he.de (hede) Date: Sun, 5 Feb 2023 14:53:06 +0100 Subject: audit-proof email archive / Revisionssicheres Email-Archiv Message-ID: <20230205145306.6e0fb1ae@hpusdt5.der-he.de> (german text below) Hi all, there are many professional business solutions for audit-proof email archives. For my personal (private) email archive I do not need a commercial solution, but... nevertheless I'd like to have some kind of an email archive which is capable of delivering a maybe comparable feature. At least for the conservation of evidence, not an easily accessible solution. So I made a small hack - some proof of concept. The idea is to timestamp all mails which are handled by the email server. It runs for more than two years now without noticeable problems. in a nutshell: - forward all mails transmitted by postfix via "always_bcc" to a special system account - deliver those mails via postfix transport directive to a subdir in the mailarchive-users home - the users mailbox is of type "maildir" - one file per mail - once a day run a script to move all mail-files into a temporary directory (to prevent side effects with postfix in case mails arrive while doing the work) - hash all email-files into a single hash-file (sha256sum) - create a hash of this hash-file - publicly timestamp this hash (e.g. truetimestamp.org) - create a (compressed) tar archive of all those files - create redundancy via par2 (to repair possible bit errors) - feed those files to the redundant backup system This way there's some sort of evidence that a specific mail has arrived or was sent by my mail server at a specific day or - by handing out the full set - not arrived or wasn't sent. Like almost _every_ technical solution this is not 100% perfect as cheating is possible, but that's at least only possible exactly at the specific date. After the daily file got timestamped it's not possible to modify the archive without having the private key of the timestamping service. This way I think it delivers good evidence for all named cases if some controversial or obscurities rise only after some time has passed. (commercial products on the other hand can also get cheated with criminal intent) What do you think about this solution? Do you think it's worth the effort or not? Do I make some logical mistake here? hede ### german Hallo zusammen, es gibt in Deutschland eine Verpflichtung zur revisionssicheren E-Mail-Archivierung f?r Unternehmen - f?r Privatpersonen ist das nicht notwendig. Dennoch m?chte ich f?r den Fall der F?lle belegen k?nnen, dass eine E-Mail mein Mailsystem empfangen oder verlassen hat, ohne ein komplexes Archivsystem zu installieren. Auf dessen zus?tzliche Komfortfunktionen kann ich verzichten. Ich nutze einen Online-Zeitstempeldienst, um t?glich ein Archiv aller eingehenden und ausgehenden Mails signieren zu lassen. Die L?sung besteht aus wenigen im System verteilten Skripten und l?uft nun schon seit zwei Jahren ohne Auff?lligkeiten. Grober Ablauf: - alle emails via postfix "always_bcc" zu einem speziellen Konto weiterleiten - Postfix anweisen diese im Format "maildir" in das homedir des Nutzers auszuliefern - einmal t?glich ein Skript starten, das diese Mails zu einem tempor?ren Verzeichnis kopiert (dies soll Seiteneffekte verhindern, falls w?hrend der Verarbeitung neue Mails eintreffen) - alle diese Dateien hashen (sha256sum) und diese Hashes in eine Datei schreiben - diese Datei wiederum hashen - zu diesem Hash einen vertrauensw?rdigen Zeitstempel besorgen (z.B. truetimestamp.org) - Alle Dateien zur unmodifizierten Vorlage in einem (komprimierten) tar Archiv zusammenfassen - (optional) zus?tzliche Redundanz via par2 bilden (kann Bitfehler im Archiv reparieren) - dieses Archiv dem Sicherungssystem (Backup) zur Aufbewahrung zuf?hren Auf diese Art kann ich in gewisser Hinsicht belegen, dass eine bestimmte E-Mail empfangen oder versendet wurde oder eben nicht. F?r ersteres reicht die Datei der E-Mail plus die Hash-Datei, f?r letzteres ist das ganze Archiv notwendig. Wie eigentlich alle technischen L?sung ist es nat?rlich nicht 100% f?lschungssicher. Das hei?t bei bewusster Betrugsabsicht im Vorfeld kann man das System nat?rlich an genau dem Tag vor dem Zeitstempeln modifizieren - das gilt aber auch f?r kommerzielle Profi-L?sungen. Aber ?nderungen im Nachhinein sind so halt eben nicht m?glich - jedenfalls nicht ohne den privaten Schl?ssel des Zeitstempeldienstes. Nun interessiert mich, was haltet ihr davon? Seht ihr einen Zweck oder klingt es unsinnig, der M?he nicht wert? Hab ich eventuell einen Denkfehler bei der Herangehensweise? hede From kolab983 at der-he.de Sun Feb 5 15:06:47 2023 From: kolab983 at der-he.de (hede) Date: Sun, 5 Feb 2023 15:06:47 +0100 Subject: kolab on centos 8 In-Reply-To: <01de12b581b3feb987eadbed8bb29036@pure.ch> References: <01de12b581b3feb987eadbed8bb29036@pure.ch> Message-ID: <20230205150647.7e7f2e1f@hpusdt5.der-he.de> On Sun, 29 Jan 2023 18:08:40 +0100 Werner Reisberger wrote: > I would like to install kolab on centos 8. > > Is there any change to get kolab 16 running there? As I'm using Debian and not CentOS I cannot tell for sure, but this question was asked here some time ago - without any answer. There are packages for CentOS 8 at http://obs.kolabsys.com/repositories/Kolab:/16/CentOS_8/ and maybe someone is working on it and it's in a usable state. But... I don't know. The installation instructions do still refer to CentOS 7 but that's also the case for Debian 11 and AFAIK this works. Ah, yeah, I'm still on Debian 10 here, my last 'buster' system begs for an upgrade ;-) hede From machniak at kolabsys.com Mon Feb 6 07:43:36 2023 From: machniak at kolabsys.com (Aleksander Machniak) Date: Mon, 6 Feb 2023 07:43:36 +0100 Subject: kolab source In-Reply-To: <9e13beeca8398666827127574b06dfc9@pure.ch> References: <4e6f56bbb3706fbd8fb970f80d9ab0a8@pure.ch> <9e13beeca8398666827127574b06dfc9@pure.ch> Message-ID: <89141be9-40c0-f52b-4ac3-446146bd3ab8@kolabsys.com> On 5.02.2023 13:56, Werner Reisberger wrote: > Sorry, just found the open git repo > > ??? https://git.kolab.org/source/kolab/ This is only one Kolab component, specifically Kolab4 Cockpit. So, it might not be what you're looking for. https://git.kolab.org/diffusion/ -- Aleksander Machniak Senior Software Engineer Apheleia IT AG PGP: 19359DC1 From tr at erdfunkstelle.de Mon Feb 6 14:22:58 2023 From: tr at erdfunkstelle.de (Thomas Reitelbach) Date: Mon, 6 Feb 2023 14:22:58 +0100 Subject: audit-proof email archive / Revisionssicheres Email-Archiv In-Reply-To: <20230205145306.6e0fb1ae@hpusdt5.der-he.de> References: <20230205145306.6e0fb1ae@hpusdt5.der-he.de> Message-ID: <89FFEC0F-65FF-4577-93DB-E698604546F3@erdfunkstelle.de> Hi Hede, I have no idea if your personal way for an email archive is good or bad. But I can say I?m using piler mailarchive for my business which is a very good solution and you can use it with no cost if you like - same as with kolab: you can buy enterprise support but you don?t have to if you don?t need it. So give it a try. Cheers Thomas > Am 05.02.2023 um 14:59 schrieb hede : > > ?(german text below) > > Hi all, > > there are many professional business solutions for audit-proof email archives. For my personal (private) email archive I do not need a commercial solution, but... nevertheless I'd like to have some kind of an email archive which is capable of delivering a maybe comparable feature. At least for the conservation of evidence, not an easily accessible solution. > > So I made a small hack - some proof of concept. The idea is to timestamp all mails which are handled by the email server. It runs for more than two years now without noticeable problems. > > in a nutshell: > - forward all mails transmitted by postfix via "always_bcc" to a special system account > - deliver those mails via postfix transport directive to a subdir in the mailarchive-users home > - the users mailbox is of type "maildir" - one file per mail > - once a day run a script to move all mail-files into a temporary directory > (to prevent side effects with postfix in case mails arrive while doing the work) > - hash all email-files into a single hash-file (sha256sum) > - create a hash of this hash-file > - publicly timestamp this hash (e.g. truetimestamp.org) > - create a (compressed) tar archive of all those files > - create redundancy via par2 (to repair possible bit errors) > - feed those files to the redundant backup system > > This way there's some sort of evidence that a specific mail has arrived or was sent by my mail server at a specific day or - by handing out the full set - not arrived or wasn't sent. > > Like almost _every_ technical solution this is not 100% perfect as cheating is possible, but that's at least only possible exactly at the specific date. After the daily file got timestamped it's not possible to modify the archive without having the private key of the timestamping service. This way I think it delivers good evidence for all named cases if some controversial or obscurities rise only after some time has passed. (commercial products on the other hand can also get cheated with criminal intent) > > What do you think about this solution? Do you think it's worth the effort or not? Do I make some logical mistake here? > > hede > > ### german > > Hallo zusammen, > > es gibt in Deutschland eine Verpflichtung zur revisionssicheren E-Mail-Archivierung f?r Unternehmen - f?r Privatpersonen ist das nicht notwendig. Dennoch m?chte ich f?r den Fall der F?lle belegen k?nnen, dass eine E-Mail mein Mailsystem empfangen oder verlassen hat, ohne ein komplexes Archivsystem zu installieren. Auf dessen zus?tzliche Komfortfunktionen kann ich verzichten. > > Ich nutze einen Online-Zeitstempeldienst, um t?glich ein Archiv aller eingehenden und ausgehenden Mails signieren zu lassen. Die L?sung besteht aus wenigen im System verteilten Skripten und l?uft nun schon seit zwei Jahren ohne Auff?lligkeiten. > > Grober Ablauf: > - alle emails via postfix "always_bcc" zu einem speziellen Konto weiterleiten > - Postfix anweisen diese im Format "maildir" in das homedir des Nutzers auszuliefern > - einmal t?glich ein Skript starten, das diese Mails zu einem tempor?ren Verzeichnis kopiert > (dies soll Seiteneffekte verhindern, falls w?hrend der Verarbeitung neue Mails eintreffen) > - alle diese Dateien hashen (sha256sum) und diese Hashes in eine Datei schreiben > - diese Datei wiederum hashen > - zu diesem Hash einen vertrauensw?rdigen Zeitstempel besorgen (z.B. truetimestamp.org) > - Alle Dateien zur unmodifizierten Vorlage in einem (komprimierten) tar Archiv zusammenfassen > - (optional) zus?tzliche Redundanz via par2 bilden (kann Bitfehler im Archiv reparieren) > - dieses Archiv dem Sicherungssystem (Backup) zur Aufbewahrung zuf?hren > > Auf diese Art kann ich in gewisser Hinsicht belegen, dass eine bestimmte E-Mail empfangen oder versendet wurde oder eben nicht. F?r ersteres reicht die Datei der E-Mail plus die Hash-Datei, f?r letzteres ist das ganze Archiv notwendig. > > Wie eigentlich alle technischen L?sung ist es nat?rlich nicht 100% f?lschungssicher. Das hei?t bei bewusster Betrugsabsicht im Vorfeld kann man das System nat?rlich an genau dem Tag vor dem Zeitstempeln modifizieren - das gilt aber auch f?r kommerzielle Profi-L?sungen. Aber ?nderungen im Nachhinein sind so halt eben nicht m?glich - jedenfalls nicht ohne den privaten Schl?ssel des Zeitstempeldienstes. > > Nun interessiert mich, was haltet ihr davon? Seht ihr einen Zweck oder klingt es unsinnig, der M?he nicht wert? Hab ich eventuell einen Denkfehler bei der Herangehensweise? > > hede > _______________________________________________ > users mailing list > users at lists.kolab.org > https://lists.kolab.org/mailman/listinfo/users From kolab983 at der-he.de Mon Feb 6 23:20:16 2023 From: kolab983 at der-he.de (hede) Date: Mon, 06 Feb 2023 23:20:16 +0100 Subject: audit-proof email archive / Revisionssicheres Email-Archiv In-Reply-To: <89FFEC0F-65FF-4577-93DB-E698604546F3@erdfunkstelle.de> References: <20230205145306.6e0fb1ae@hpusdt5.der-he.de> <89FFEC0F-65FF-4577-93DB-E698604546F3@erdfunkstelle.de> Message-ID: On 2023-02-06 14:22 CET Thomas Reitelbach wrote: > I have no idea if your personal way for an email archive is good or > bad. But I can say I?m using piler mailarchive ... Piler definitely is a way more feature rich and professional solution and maybe I will use something like that in the future. Still I'm happy with what I have - for now. Btw. my solution probably is not optimal for business users: there's no simple way to find and delete mails from some specific sender - except by extracting and searching through _all_ archived mails. Quite important for GDPR cases (German: DSGVO). Yet it's really simple, no additional complex software stack like with e.g. piler and as long as there is no GDPR case ... ;-) hede From klaus at myexpertise.net Tue Feb 28 01:20:32 2023 From: klaus at myexpertise.net (Klaus Schreyack) Date: Mon, 27 Feb 2023 17:20:32 -0700 Subject: set-quota resets In-Reply-To: <754ca1e8-e718-6f02-3c14-f9acde326d4c@gnaa.net> References: <6fcb9809-d2ea-31dc-24c0-c29cda344de9@saurymper.com> <60dd159e-2559-53a5-0fea-c9dc679f1fbe@saurymper.com> <754ca1e8-e718-6f02-3c14-f9acde326d4c@gnaa.net> Message-ID: <2f95c647-faa3-f668-6ec8-4f6039551f82@myexpertise.net> Hmm, I never got mine to update with the LDAP changes suggested. Not sure what to try next.? I have made the changes in the Kolab Admin Web UI as well, but the user still has old 1GB quota set and no email coming into the account due to this I feel. Looking for suggestions, thanks in advance! Klaus On 9/29/22 17:03, Geoff Nordli wrote: > Hi, > > On 2018-01-16 11:28, Skale, Franz wrote: >> Hi, >> Am 2018-01-16 15:27, schrieb Sruli Saurymper: >>> Many thanks, I have never touched a ldap table directly, please help me >>> understand further; >>> >>>> this only can be done using ldapmodify: >>>> ldif-example: >>> Is this a .ldif file i need to create? >>>> dn: uid=user,ou=People,dc=example,dc=org >>>> changetype: modify >>>> replace: mailQuota >>>> mailQuota: 2097152 >>>> >>>> /usr/lib/mozldap/ldapmodify? -D "cn=Directory Manager" -f >>>> change-mailquota.ldif -w [password] >>> I do not have a dir /usr/lib/mozldap/ -- change-mailquota.ldif is this >>> the file I created above? >> Then use the default ldapmodify utililty. >> It should accept the same command parameters as mozldaps version do !. >> Yes, either you have to create a ldif file using an editor or, when >> using a shellscript variant, put it in your script. (<> ldapmodify should support reading the file from STDIN using -f -. >> (Try and test). >> >> Debian provides the mozldap-tools package: >> mozldap-tools: /usr/lib/mozldap/ldapmodify >> Perhaps you forgot to install the package (Highly recommended). >> >>>> modifying entry uid=user,ou=People,dc=example,dc=com >>>> >>>> It's quite easy to create a shell script for this purpose ! >>> Once I understand it properly I can create a bash script to automate. >> > Once you do the update, should it show in the kolab list-quota right > away or does something need to sync between ldap and cyrus? > > list-quota is still showing the old value, even after a few hours. > > I assume ldapmodify would error out if it didn't find the > object/property. > > On a side note is there a spot to create a global quota? ? The Kolab > Webadmin interface shows 0 on all accounts. ? I tried changing that > but it had no affect. > > thanks, > > Geoff > > _______________________________________________ > users mailing list > users at lists.kolab.org > https://lists.kolab.org/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: