Beiträge von riawie

tobit-user-24 ja, so soll das gedacht sein

bevor Tobit Let's Encrypt integriert hat haben einige von uns das selbst schon genutzt und sogar die Zertifikats Erneuerung automatisiert. Die alten Beiträge inklusive Anleitung dazu finden sich hier auch noch im Forum

Du kannst ja die Historie auch weiterhin löschen.

Du musst halt nur die unsinnigen Werte aus der Registry löschen wenn da immer wieder Tippfehler oder ähnliches vorgeschlagen werden.

Natürlich musst Du auch das Adressbuch des jeweiligen Nutzers kontrollieren ob da unsinnige Werte drin stehen.
Das kommt nämlich gerne vor wenn man die Einstellung aktiv hat welche dazu führt das er bei unbekannten Adressen fragen soll ob die ins Adressbuch aufgenommen werden sollen.
Denn dann ist die Kausalreihenfolge halt:
Benutzer tippt Adresse von Hand ein, vertippt sich, guckt nicht hin.
David erkennt neue Adresse die noch nicht im Adressbuch vorkommt und fragt ob diese ins Adressbuch aufgenommen werden soll.
Nutzer bestätigt die Aufnahme ins Adressbuch, weil er auch dann den Tippfehler nicht erkennt.
Ab jetzt steht die fehlerhafte Eingabe sowohl im Adressbuch, als auch in der Eingabehistorie mit drin.

Die Eingabehistorie selbst bereinigt sich nach eine weile wenn man die Adresse länger nicht eingegeben hat.
Die fehlerhafte Adresse wird bei Eingabe aber dennoch wieder vorgeschlagen weil sie ja im Adressbuch dauerhaft gespeichert wurde.

Merke: in solchen Fällen immer auch die Adressbücher im Zugriff des Nutzers mit prüfen

hab ich das jetzt falsch in Erinnerung?
soweit ich mich erinnere ist die die contacts.db doch nur eine lokale Datenbank zur beschleunigten Suche in den eigentlichen Adressordnern welche dem jeweiligen Client zugänglich sind. Löscht man sie wird sie aus genau diesen Adressordnern bei nächster Gelegenheit wieder aufgebaut.
Demnach müsste alles was einem aus der contacts.db vorgeschlagen werden kann auch in den konfigurierten Adressordnern vorkommen.

Da ich mal davon ausgehe das Lycra die Adressbücher auf welche zugegriffen werden kann als erstes von eventuellem Müll bereinigt hat dürften die seltsamen Vorschläge vermutlich eher aus der Eingabehistorie stammen.

Die Eingabehistorie wird allerdings in der Registry gespeichert.
Je nach Client Version ist das ausgehend davon als der jeweilige Nutzer angemeldet zu sein einer der beiden folgenden Pfade:

Computer\HKEY_CURRENT_USER\SOFTWARE\Tobit\David Client\MRU
Computer\HKEY_CURRENT_USER\SOFTWARE\Tobit\Tobit InfoCenter\MRU

Zitat von lycra

Weil bei euch zu viel auf duplog aufbaut?

na, weil das Duplog hier die Quelle für das revisionssichere eMail Archiv ist.
Schalte ich Duplog ab werden keine neuen Mails mehr archiviert.
Da ich allerdings auch grundsätzlich nie von Hand über den Explorer in den Archiven herumwurschtle hab ich halt auch den Grund nicht sowas zu tun wie der Kollege oben nun, nach dem er von Hand Dateien gelöscht hat weil er sich nicht mehr an sein Duplog erinnert hatte

Wenn hier mal ein anderer Nutzer oder auch ein ammok laufender Prozess einzelne Dateien wegwirft muss ich da zwar auch mal ran um sie wieder an Ort und Stelle zu platzieren, aber dann lösche ich halt nix, sondern besorg mir das was fehlt aus der Strongbox und pack es anschließend mit dem korrekten Dateinamen wieder genau da hin wo es vermisst wird.
Das kommt allerdings wirklich selten mal vor und ansonsten lassen wir hier die Finger vom Dateisystem
Was aber halt nicht heißt das ich nicht genau weiß was man da alles anrichten kann und wie man es im Zweifel wieder repariert

kommt halt drauf an wozu Du den DupLog nutzt.
Ich könnte sowas bei uns auf keinen Fall machen.
Wenn Du aber auch den Duplog so lange verzichten kannst könnte das in der Tat helfen.
Dann stell Dir aber nicht gleich das nächste Bein und lösch erst mal den gesamten Inhalt des DupLog Ordners, lass eine Bereinigung durchführen und lösch erst anschließend der Ordner als solchen.
Das Problem bei der Geschichte ist halt das Du dann trotzdem nicht sicher sein kannst ob es aufgrund Deiner vorherigen Aktionen irgendwo noch Zombies gibt die nur aufgrund der fehlenden Info das ihr Duplog Eintrag gelöscht wurde in irgendwelchen Archiven liegen bleiben.
Sowas kann man zwar durchaus auch sauber aufräumen, ist aber sehr aufwändig und es zu erklären grenzt allein schon an einen Roman :o

Wenn das mal nun nicht dazu führt das Dein David Server keine Ahnung hat welche Dateien er nun von der Platte putzen und auch den jeweiligen Archive.dat Dateien putzen darf :o ?
Soweit ich weiß sollten Duplog Nutzer übrigens auch nicht auf die Idee kommen die Archive.dat Dateien neu aufbauen zu lassen, weil es sonst zu Verknüpfungen im Duplog kommen kann welche dann nur noch so lange tatsächlich auf Dateien zeigen wie niemand die ursprünglichen Einträge löscht... 100% sicher bin ich mir in dem Punkt allerdings nicht, weiß aber noch das man als Duplog Nutzer besser so wenig wie möglich von Hand im Explorer in den Dateien rumpfuschen und auch die Tracking Nachrichten tunlichst in Ruhe lassen sollte :o
Das System räumt schon recht zuverlässig selbst auf wenn man ihm nicht dazwischen funkt.
Wenn man das allerdings mal macht und von Hand Dinge löscht kann es ganz schön gehörig aus dem Tritt kommen.
Wichtig ist vor allem das man sich stets dran erinnert wenn man Duplog aktiv hat und sich bewusst ist wie Verknüpfungen funktionieren und das alleine die Verwendung von einem der beiden dazu führt das es in manchen Archiven zu scheinbar verwaisten Dateien im Dateisystem kommen kann, welche aber in Wirklichkeit gar nicht verwaist sind.

Wenn man da mal von Hand drin herumgewerkelt hat sollte man anschließend übrigens so lange jeden Tag den Purging Report aufmerksam auf Fehler prüfen und diese korrigieren, bis mindestens eine Woche lang keine solchen Fehler mehr aufgetreten sind. solltest Du bislang keine Purging Reports bekommen guck mal nach dem Eintrag "MSGMAILNAMES = email@adresse.tld" in der david.ini und sorge dafür das er existiert sowie eine sinnvolle eMail Adresse enthält.

für die internen Tracking Geschichten ist nur der Api Ordner relevant

im Verzeichnis david\apps\faxware\out\api sieht man das am besten. Wenn da sehr viele Dateien liegen ist meist das Tracking schuld. Da das Tracking aber ja inzwischen nachrangig behandelt wird hat das zumindest bei uns keinen negativen Einfluss mehr auf den regulären Betrieb.

Zitat von lycra

Auch du als Admin nicht?

Als Admin hat man Berufsbedingt zu sehr vielen Bereichen technisch Zugriff auf die man aus Datenschutzgründen besser keinen haben wollen würde.
Das lässt sich an der Stelle nur durch Complience regeln.
Nur weil ich technisch könnte darf ich rechtlich eben doch nicht und das bedeutet hier konkret das ich es auch tatsächlich nicht mache und das der Datenschutzbeauftragte darüber wacht das ich mich dran halte (Auditlogs )

graef-edv womit Du Dir nun leider einen Teil Deines Duplog zerschossen hast

Duplog ist ne tolle Sache, aber man sollte sich stets bewusst sein wenn man das laufen hat, sonst passieren einem unter Umständen dumme Dinge

Zitat von graef-edv

Das ist bei Windows-Verknüpfungen auch nicht anders.

oh, doch, das ist anders.

Wenn man bei Windows die Datei löscht auf welche sich die Verknüpfung bezieht führt die Verknüpfung anschließend ins Leere.

Wenn man bei David das Objekt löscht auf welches die Verknüpfung zeigt bleibt die Verknüpfung gültig, da das Objekt dann zwar im Ordner wo es gelöscht wurde nicht mehr angezeigt, aber die dahinter liegenden Daten erhalten bleiben. Erst wenn die letzte Verknüpfung gelöscht wird löscht die nächtliche Bereinigung auch die Daten auf welche die Verknüpfung gezeigt hat.
Nur wenn man einen Ordner löscht auf den eine Verknüpfung zeigt führt die Verknüpfung anschließend ins leere.

Der Weg von Tobit ist da deutlich näher an dem was man von Unix Rechnern kennt.

huch, eigentlich sollte das auch beim Empfänger korrekt ankommen.
man muss nur aufpassen das nicht nach dem @@von noch andere die Eigentümerschaft berührende Befehle ausgeführt werden wie z.B. ein @@own

Zitat von graef-edv

Schön wäre es, wenn es so einfach wäre.

Was mache ich, wenn mir jemand eine Bewerbung an meine persönliche Adresse (oder an die info@ ) schickt?

Die GOBD sagen, diese Mail muss unverfälschlich für >10 Jahre archiviert werden.

Das Datenschutzgesetz sagt: Diese Mail muss nach 3 Monaten nicht wiederherstellbar gelöscht werden.

Jörg.

Art. 6 Abs. 1 S. 1 lit c) DSGVO sagt recht klar, dass eine Verarbeitung personenbezogener Daten rechtmäßig ist, wenn und soweit sie zur Erfüllung einer rechtlichen Verpflichtung erforderlich ist.
Die gesetzliche revisionssichere Aufbewahrungspflicht geschäftlicher eMails ist ganz klar so eine rechtliche Verpflichtung. Bleibt also nur sicherzustellen das nicht zu anderen Zwecken auf die archivierten Mails zugegriffen wird und das sie gelöscht werden sobald die gesetzlich vorgeschriebene Aufbewahrungspflicht abgelaufen ist. Bei uns hat kein Nutzer Zugriff auf das Mail Archiv und kann somit auch niemand entgegen der DSGVO unberechtigt zu lang auf Daten zugreifen.
Sollten wir je rechtlich zur Herausgabe von bestimmten eMails verpflichtet werden wird sichergestellt das dazu auch nur genau die angeforderten eMails bereitgestellt werden. Problem gelöst.

Zitat von cossys

kann man den Zustand der Warteschlange im System sehen / prüfen ?

Im Moment läuft unser Server nicht sonderlich stabil und Ich würde das Problem gerne einkreisen ...

beobachten kann man das im Verzeichnis david\apps\faxware\out\api - wenn dort sehr viele Einträge vorhanden sind, kann es zu Verzögerungen kommen. Diese Einträge könnten z.B. durch Message Tracking Aktionen (verschieben, löschen, etc.) ausgelöst werden.

Guck mal im Reiter Identifizierung was dort bei SPAM eingestellt ist

setze mal statt Leerzeichen ein ? ein und teste das noch mal

Omnideal wie ciwu bereits schrieb kann bei dem Subject "Rückerstattung" halt gar nicht funktionieren. Funktionieren würde allerdings

enthält: "ckerstattung"

Genau deswegen muss man sich ja an solchen Stellen den Source der Mails anschauen um zu sehen was da Zeichensatz technisch bedingt wirklich empfangen wird.

Baumi hey, super wieder was dazu gelernt

Damit ist Tobit in der Bedienung ja noch einen ganzen Schritt näher an den anderen beiden dran
Muss ich jetzt nur noch den Anwendern erklären

Das Rollout drüber zu installieren würde nur fehlerhaft installierte oder beschädigte bzw. Programmdateien, Bibliotheken und Komponenten reparieren, aber es ändert grundsätzlich keine bestehenden Konfigurationsdaten.

Ich würde in diesem fall wirklich anregen den Tobit Support, oder einen guten Tobit Partner zu Rate zu ziehen.