Das war dann das ko für mailstore. Wurde euch das nicht erzählt
Hm, nö. Uns wurde nur erzählt, dass mit David am besten die Proxy-Variante klappt.
Das war dann das ko für mailstore. Wurde euch das nicht erzählt
Hm, nö. Uns wurde nur erzählt, dass mit David am besten die Proxy-Variante klappt.
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.
Mal eine blöde Frage:
Wie greife ich das Duplog per IMAP ab?
Wie kann ich das frei geben?
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).
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.
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.
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.
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.
aber nicht die SMTP kommunikation selbst.
Das stimmt, ist das bein Journaling beim Exchange und co anders?
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!
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.
mein beileid
wenn du infos zur integration von reddoxx in david brauchst melde dich.
Was nutzt ihr, Strongebox?
Halte uns bitte auf dem Laufenden, ist sicher für alle interessant.
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
Auf welchen Punkt/welche Punkte hat denn der WP konkret hingewiesen?
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
Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!