Erfahrungen revisionssichere Archivierung GoBD

  • Ich sollte stattdessen mit dem duplog von David arbeiten.

    Das war dann das ko für mailstore. Wurde euch das nicht erzählt?

    Was spricht gegen Duplog und abruf per IMAP so wie das Inoxision macht?
    Ausser das es nicht vor dem MailServer gemacht wird.

    https://ihr-it.support
    Bietet seit zwanzig Jahren Systemhaus Lösungen für kleine bis mittlere Kunden an.
    Auf meiner Homepage finden Sie Infos zu allen Zertifizierungen und Partnerschaften ;)
    Support Hotline: 07345 23 63 80

  • Damit der ServiceLayer eine DupLog schreibt musst du folgende Punkte durchgehen.

    1. In der TAS (über den David Client) Verzeichnise anlegen (z.B. MailArchiv in Unterordner Ein/Ausgang) in die der SL die
    DupLog für den Ein und Ausgang schreibt.
    2. In die David.ini folgende Einträge einfügen (weichen je nach namen etc ab).

    Code: david.ini
    DupLog={RX|DocType=2}+\\srv-david\david\archive\MailArchiv\Eingang\ARCHIVE.DAT
    DupLog={TX|DocType=2}+\\srv-david\david\archive\MailArchiv\Ausgang\ARCHIVE.DAT
    
    
    RX = Eingang , TX = Ausgang

    Service Layer neu starten. Ab jetzt führt der SL in diesen Verzeichnissen die Duplogs.

    3. MailAccess im David aktivieren, auf IMAP4 umstellen, TLS einrichten ;) wer will
    Den Ordner z.b. MailArchiv per MA erreichbar machen.

    Nun kann man über einen Mail Client per IMAP auf die Duplog des Ein/Ausgangs zugreifen.
    So macht es ja z.b Inoxision.

    https://ihr-it.support
    Bietet seit zwanzig Jahren Systemhaus Lösungen für kleine bis mittlere Kunden an.
    Auf meiner Homepage finden Sie Infos zu allen Zertifizierungen und Partnerschaften ;)
    Support Hotline: 07345 23 63 80

    Einmal editiert, zuletzt von stylistics (18. September 2017 um 19:08)

  • Was spricht gegen Duplog und abruf per IMAP so wie das Inoxision macht?Ausser das es nicht vor dem MailServer gemacht wird.

    der große vorteil wenn es vor/nach dem Mailserver gemacht wird, ist das man die Kommunikation selbst auch speichern kann. Und so im fall der fälle nachweisen kann das sie wirklich angekommen ist, und nicht nur unseren Mailserver verlassen hat.

  • der große vorteil wenn es vor/nach dem Mailserver gemacht wird, ist das man die Kommunikation selbst auch speichern kann. Und so im fall der fälle nachweisen kann das sie wirklich angekommen ist, und nicht nur unseren Mailserver verlassen hat.

    Macht das Duplog nicht genau das? Es bildet alles was Ein und Ausgegangen ist ab.

    https://ihr-it.support
    Bietet seit zwanzig Jahren Systemhaus Lösungen für kleine bis mittlere Kunden an.
    Auf meiner Homepage finden Sie Infos zu allen Zertifizierungen und Partnerschaften ;)
    Support Hotline: 07345 23 63 80

  • aber nicht die SMTP kommunikation selbst. wenn du am MX direkt archivierst, bzw. direkt versendest über deine archivierung sind die SMTP Commands (250 Empfangen z.B.) archiviert und damit lässt sich der versand/emfpang nachweisen. das ist z.b. relevant bei terminsachen.

    in einer reddoxx schaut das so aus für den versand, das wird separat zu jeder email gespeichert und ist quasi ewig nachvollziehbar.

    Code
    Connecting to: [Ziel MX]:25
    Receive on HELO: 250 HELP
    Receive on MAIL FROM: <Absender> = 250 2.1.0 Sender ok
    Receive on RCPT TO: <Empfänger> = 250 2.1.5 Recipient ok
    Data result: 250 2.1.5 OK mail delivered with id y03b65t8JBG2XSx
    - Disconected


    wenn du eine klassische archivierung einsetzt kannst du zwar mitunter belegen dass dein server die mail versendet hat - aber nicht dass sie auch angekommen ist. eine email gilt dann als zugestellt wenn der ziel mx sie akzeptiert hat, was danach passiert ist nicht dein problem.

  • soweit ich weiß nein. deshalb auch meine aussage weiter oben im thread, dass es die beste lösung ist direkt am MX zu archivieren.
    daraus ergeben sich auch noch diverse andere vorteile wie z.b. die lösung des problems mit verschlüsselten mails und archivierung bzw. der verschlüsselung selbst.

    ich bin der ansicht dass die meisten "günstigeren" archiv lösungen zu kurz greifen. das thema ist relativ komplex und bietet einige ansätze um das email/doku system generell zu optimieren und sicherer zu machen. wer mit gewalt versucht für kleines geld den gesetzlichen pflichten nachzukommen und nicht über den tellerrand hinausdenkt verschenkt hier viel potenzial. schwierig ist es natürlich in der typischen 5-10 mitarbeiter bude solch eine lösung unterzubringen aber wir versuchen generell alle kunden über 15 user in diese richtung zu bewegen. bisher mit recht gutem erfolg, die akzeptanz der endanwender ist auch deutlich besser als wir es zu anfang erwartet haben.

  • Ich habe mal den Mailstore-Abruf über Duplog getestet.
    Übersehe ich was oder kann Mailstore aus dem Duplog auch die Benutzer nicht richtig zuordnen?
    Hat das mal jemand getestet?


    Ich bleibe bei der Proxy-Methode, das funktioniert.
    Allerdings ist Verschlüsselung da wirklich ein Problem.

    Korrektur: Duplog funktioniert bestens.
    Danke für die Hilfe!

    Einmal editiert, zuletzt von UKe (22. September 2017 um 22:30)

  • Und hier sind wir, der Wirtschaftsprüfer erkennt das David System inkl WORM Bändern für die Revisionssichere Archivierung nicht mehr an.

    ich habe nun die großen Krieger and der Backe und alle Geschäftsführer unendlich viele Konferenzen etc.

    09-f9-11-02-9d-74-e3-5b
    MfG Kingcopy seit C16 / C64
    Fachinformatiker / Systemintegration
    IT-Systemadministrator
    David (R) 20 User / 500 GB
    David (R) 200 User / 2,5 TB
    d8-41-56-c5-63-56-88-c0

  • Ich Sichere täglich die Strongbox und diese geht Jährlich bzw 3 Monatlich in ein Bandarchiv ausserdem Täglich und Mitarbeiter werden Jährlich mit der Strongbox bzw. Verlassen täglich und Jährlich extrahiert.


    Ich prüfe gerade den MailStore ggf lass ich den auf einem Server Mitlaufen

    09-f9-11-02-9d-74-e3-5b
    MfG Kingcopy seit C16 / C64
    Fachinformatiker / Systemintegration
    IT-Systemadministrator
    David (R) 20 User / 500 GB
    David (R) 200 User / 2,5 TB
    d8-41-56-c5-63-56-88-c0

  • Auf welchen Punkt/welche Punkte hat denn der WP konkret hingewiesen?

    "Programming today is a race between software engineers striving to
    build bigger and better idiot-proof programs, and the Universe trying
    to produce bigger and better idiots. So far, the Universe is winning."

  • Interessant wäre hier wirklich die konkrete Begründung.

    Prinzipiell würde ich nicht mehr über Proxy archivieren, weil das bei Ende-zu-Ende verschlüsselten Mails kontraproduktiv ist.
    Ein Archiv soll ja langfristig gedacht sein und vielleicht erleben wir wirkich noch EMail-Verschlüsselung.

    Und dann bleibt bei Mailstore + Tobit nur der Abruf per IMAP aus den Postfächern oder vom Duplog.
    Prinzipiell ist das auch nicht 100%ig wasserdicht, weil der Abruf nur in endlichen Intervallen und nicht sofort erfolgt.
    Natürlich deutlich feiner als bei Strongebox.

    Ich weiß nicht wie Reddoxx + David arbeiten, aber nach den oben gesehen Screens scheint das intelligenter zu sein.

  • reddoxx setzt direkten SMTP empfang vorraus (kann auch proxy, aber aus den genannten gründen nicht empfohlen). versand sollte idealerweise auch direkt, ohne smtp relay, erfolgen. dann gibts die oben gezeigten logs.

  • @UKe bei der Reddox wäre es möglich es über die Reddox zu ent/verschlüsseln. Die bietet die Option an, die eMail im Client im Klartext zur Reddox zu schicken und diese Verschlüsselt es dann mit einem hinterlegten smime Zertifikat. Was verschlüsselt werden soll kann man vorher festlegen und im Einzelfall über den Betreff geregelt werden.

    Natürlich ist dann die kette Client - David/Kerio etc - Reddox nicht verschlüsselt. Aber zumindest kommt man den gesetzlichen vorgaben der Sicherung nach. Irgendwas ist ja immer.

  • Und hier sind wir, der Wirtschaftsprüfer erkennt das David System inkl WORM Bändern für die Revisionssichere Archivierung nicht mehr an.

    ich habe nun die großen Krieger and der Backe und alle Geschäftsführer unendlich viele Konferenzen etc.


    Auch wenn der Artikel schon älter ist.

    Mich würde tatsächlich interesieren was die Wps nicht anerkennen? Dein Vorgehen mit den Worm Bändern? Oder die Art wie die Daten auf die Bänder kommen? Was mich dabei besonders drückt ist die (wohl sinnlose) Frage - woher ein WP die (nichtvorhandene?) Sachkenntnis nimmt um Dein System abzulehnen?

    Denn beurteilen kann er die Problematik ja doch nicht. Oder anders gefragt - auf welche Tatsachen stützt die WPS Ihre Ablehnung?


    Gruß

    Baer

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!