[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kroupware
Subject:    Re: audit-proof email archive / Revisionssicheres Email-Archiv
From:       Thomas Reitelbach <tr () erdfunkstelle ! de>
Date:       2023-02-06 13:22:58
Message-ID: 89FFEC0F-65FF-4577-93DB-E698604546F3 () erdfunkstelle ! de
[Download RAW message or body]

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 <kolab983@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
> _______________________________________________
> users mailing list
> users@lists.kolab.org
> https://lists.kolab.org/mailman/listinfo/users
_______________________________________________
users mailing list
users@lists.kolab.org
https://lists.kolab.org/mailman/listinfo/users


[prev in list] [next in list] [prev in thread] [next in thread]