Beiträge von riawie

Zitat von stylistics

Das macht ja niemand, hat alles vor und nachteile.

Niemend?
Tobit hat beschlossen den alten Chat abschaffen zu wollen.

Zitat von stylistics

Ist doch bei den meisten so, die die User in der Masse verwenden...

das ist für mich kein Argument. Auch der David Chat unsicher angebunden ein Problem werden...

Das Problem ist das die Leute sich nicht dessen bewusst sind das da mehr Menschen zu erreichen sind als nur eigene Mitarbeiter.

Kurzum: wir wollen den Scheiß nicht und wenn das irgendwann die einzige Möglichkeit ist werden wir es lieber komplett abschalten.
Dann allerdings sind auch wir nicht mehr weit davon entfernt Tobit den Rücken zu kehren.
Das ist dann nur noch eine Frage der Zeit.
Der David Server hat seine Stärken im Datenschutz und in der Funktionalität.
Eine wesentliche dieser Funktionalitäten ist das >rein interne< diskutieren über Mails.
Nimmt man uns das wird es zwangsläufig zu Entscheidungen führen.

Ich halte hier wirklich beharrlich am David Server fest.
Aber auch ich habe rote Linien.
Und da ich im nächsten Jahr Verstärkung im Team bekomme werde ich dann auch mehr Zeit für neue Dinge haben.
Das bedeutet dann werden im Zweifel andere Datenschutzfreundliche Lösungen aufgebaut.

Und ich lasse mir den Chayns basierten Chat sicher nicht schön reden.
Der Chat hat auf unserem Server zu bleiben und externe haben keine Teilnehmer des Chats zu sein.

Für Kommunikation mit extern haben wir andere Lösungen, welche hinreichend weit verbreitet sind, welche wir den Leuten also auch nicht noch erst erklären müssen, da wird Tobit eh kein Bein an die Erde bekommen.

Zitat von caddo

Auf der Seite https://david.tobit.software/downloads? braucht man nicht eingeloggt sein, um den aktuellen Client zu laden.

Heute kann ich dort den Team Client ohne Login laden, gestern nur die ISO der Installationsdaten (ich hatte extra nachgeschaut).

Will man den Classic Client muss man auch heute noch angemeldet sein.

ciwu Hauptnutzen des Chats für mich sind Rückfragen zu eMails innerhalb des Unternehmens.
Die beste Neuerung war die Möglichkeit (die allerdings leider nur im Team Client eingeführt wurde) auch über eMails mit externen Teilnehmern intern chatten zu können. Ich hab dafür teils sogar extra den Team Client geöffnet um so einen Chat zu einer solchen Mail zu starten, denn ist der Chat erst mal da kann er auch mit dem Classic Client weitergeführt und sogar der Personenkreis erweitert werden.
Das war mal ein lang ersehnter und echter Fortschritt.

Der neue Chayns basierte Chat hingegen mutet wie ein potentielles Datenschutzdesaster an.

Tobit hat mir inzwischen eine geänderte dvgrab.exe zur Verfügung gestellt, die habe ich gerade eingespielt und warte nun darauf, das der Lieferant wieder mailt...

...ich bin gespannt

Ritana ich denke es kommt auf die konkrete Länge der Strings und vielleicht auch das besondere Sonderzeichen, welches enthalten ist an.

Wir sehen das Problem ja bislang auch nur bei genau diesem einen Absender.

Aber Tobit hat ja scheinbar was gefunden und so sind wir nun mal gespannt

Der Test war erfolgreich.
Tobit hat das Problem also identifiziert und - zumindest in der mir zur Verfügung gestellten dvgrab.exe - auch beseitigt.

pul klicke den Link von caddo
dann klick oben links in das Hamburger Menü
dort klickst Du auf Anmelden
nun mit Eurer Site ID anmelden
jetzt oben rechts auf "Mehr" klicken
Nun siehst Du die Seite, welche Du eigentlich im David Administrator sehen solltest.
Da findest Du dann auch Deine gewünschten Downloads:

Zitat von stylistics

Das stimmt schon, besser als der Intern Chat ist das allemal...

Der interne Chat wird hier halt von einigen bewusst genutzt, weil so sicher ist das man nicht versehentlich wen extern in der Kommunikation hat.
Ich finde den internen David Chat auch genau deswegen erhaltenswert.

Zitat von stylistics

So kann der Kunde Externe (User) in den Chat aufnehmen (Monteure, Dienstleister

Und wer von den externen, die nicht selbst David haben lässt sich darauf ein?

Ich sehe da das gleiche Problem wie bei allen anderen Messengern in den letzten Jahren.
Wenn das nicht interoperabel ist wird da keinem wirklich ein nennenswerter Erfolg beschieden sein.

Die Leute haben halt WhatsApp, Signal oder auch noch Telegram, und keiner von denen möchte noch was anderes nutzen.
Zumal nicht, wenn die Nutzerbasis, welche dahinter zu erreichen ist derart klein ist.

Ja, habe ich aktiviert und dem Tobit Support auf Rückfrage von gestern Nachmittag auch schon eine exportierte Nachricht zukommen lassen.

Ist halt die Frage ob sowas wirklich ein extremer Einzelfall ist, oder ob deren Umbaumaßnahmen noch weitere Probleme ausgelöst haben könnten.
Daher der Hinweis an alle hier mal genau hinzuschauen und gegebenenfalls zu melden wenn da noch wer Auffälligkeiten findet

die fragliche From Zeile sieht mit dem Grabbing Server abgeholt bei Strato vor und nach dem letzten Update anonymisiert im David SMTP-Header Tab wie folgt aus:

From: =?iso-8859-1?Q?Abcdefghij=2C_Klmnopq_=7C_Ing=2E-B=FCro_abcdefghij+klmnop?=
<Abcdefghij@ak-xyz.de>

Dieser From Header sieht nach dem Update noch genauso aus wie vor dem Update.

Im Klartext soll das eigentlich so aussehen:

From: Abcdefghij, Klmnopq | Ing.-Büro abcdefghij+klmnop <Abcdefghij@ak-xyz.de>

vor dem Update hat der David Server daraus dies gemacht:

From: Abcdefghij, Klmnopq | Ing.-Büro abc <Abcdefghij@ak-xyz.de>

Und seit dem Update macht er das daraus:

From: Abcdefghij, Klmnopq | Ing.-Büro abc <Abcdefghij@ak>

Ich könnte mir durchaus vorstellen das dieser Trennstrich ein Problem ist, vielleicht aber auch schlicht die Länge?
Ging aber halt bis zum vorherigen Rollout noch in einem technisch als o.k. zu bezeichnenden Maße.
Das der Klartext Name da das Feld gesprengt hat und vom David abgeschnitten wurde hat hier nun echt keinen gekratzt, das jetzt allerdings die eMail Adresse selbst abgeschnitten wird ist schon ein Problem.

UZF8 codierte From Header sehe ich auch ab und an, kommt halt drauf an wie der Absender seine Nachrichten codiert hat.
Hier im speziellen Fall sind sie allerdings iso-8859-1 codiert.

Seit wir das Rollout 513 eingespielt haben schneidet der David Server bei eingehenden Mails eines bestimmten Absenders ab.
Dieser Absender hat in seinem From Header einen Klartextnamen mit Sonderzeichen und einem senkrechten Trennstrich + Firmennamen stehen, zusätzlich seine korrekte eMail Adresse in spitzen Klammern.

Schon auf dem Server wird nun seine "Von" eMail Adresse abgeschnitten, so das nach dem @ nur noch zwei Zeichen übrig bleiben.

Ein bestimmtes Muster kann ich natürlich noch nicht erkennen, da das ganze ja bislang nur bei diesem einen Absender auftritt.
Allerdings schreibt der uns im Rahmen eines Projekts seit geraumer Zeit täglich mehrere Mails und hat dabei an dem Inhalt seines From: Header Feldes nichts verändert.
Vor einspielen des Updates war alles o.k., die eMail Adresse wurde auf dem David Server korrekt interpretiert, im Eingangslog korrekt festgehalten, im Client korrekt angezeigt und man konnte problemlos auf seine Mails antworten. Seit dem einspielen des Rollout 513 wird seine eMail Adresse schon auf dem Davis Server unmittelbar beim Empfang abgeschnitten erfasst, überall abgeschnitten angezeigt und man kann entsprechend nicht mehr ohne manuellen Eingriff auf seine Mails antworten.

Ich habe das Problem - nach dem es mir heute gemeldet wurde - auch bereits bei Tobit gemeldet.

Ich denke allerdings das es vielleicht nicht verkehrt wäre mal zu fragen ob auch andere von Euch bei genauem Hinschauen in die Eingangslogbücher derartige Fehler finden können.
Es würde Tobit in dem Fall bestimmt die Fehlersuche deutlich erleichtern, wenn sie mehr Meldungen dazu bekommen.

Ich vermute da einen Zusammenhang mit den Änderungen am Grabbing Server und Postman in Zusammenhang mit der veränderten "Engine für die Message Identification Services"

Guckt doch mal bitte nach, ob das nicht nur bei uns auftritt.

Zitat von mikemars

Dies will beim Kunden einfach nicht gelingen, wenn ich die Postman-Log richtig interpretiere, gibt es Fehler bei der TLS-Aushandlung.

Mit Logfile Ausschnitt (anonymisiert) könnte man ja eventuell etwas sachdienliches dazu sagen.
Ohne wird es schwierig.

Ich habe hier reichlich Systeme, welche per smtp mit aktivem tls mails über den aktuellen David Server senden.

Apropos aktueller David Server... Welche Version läuft dort?

Da fällt es mir wie schuppen von den Augen.
Du schreibst das ein aktuelles Let's Encript-Zertifikat vorhanden ist.
Wie sieht es mit der DNS Auflösung aus?
Wird der David Server vom Lexware über einen zum Zertifikat passenden DNS Namen angesprochen und löst dessen IP Adresse im - vermutlich an der Stelle - internen Netz auch auf diesen DNS Namen auf?
Ich fahre hier ein split DNS Setup, damit unsere internen Server den David Server intern mit seinem externen Namen ansprechen können und auch Antworten unter diesem Namen bekommen, denn sonst akzeptieren sie dessen Zertifikat schlicht nicht.

autsch, sorry, hatte ich übersehen, weil ich das nie nutze.

@@lock
deaktiviert alle nachfolgenden David Befehle, ändert aber nichts daran das sie bei der Verarbeitung und vor dem eigentlichen Versand aus dem Text der Nachricht entfernt werden.

@@lock +
deaktiviert die Befehle und sorgt dafür das die Befehle auch noch in der Nachricht stehen und für den Empfänger sichtbar bleiben.

Euer früheres
@@lock +
@@VON ihre@absenderadresse.de@@

hat also auch keine Absenderadresse gesetzt.

Ohne das @@lock +
werden die Befehle verarbeitet und entfalten ihre Wirkung, außerdem werden sie, so wie vorgesehen aus dem Nachrichtentext entfernt.
Weiterer Text - außer David Befehlen - in einer Include Datei sollten allerdings mit beim Empfänger ankommen.
Auch sollte man lokal sehen können was in der Include Datei drin steht.
Es gibt da allerdings so ein seltsames Verhalten des David, das die Befehle in einer Include entfernt werden, wenn man sie auf eine bestimmte Weise im David Editor speichert. Ich kann mir nie merken wie das im Detail war.
Ich erzeuge neue Includes immer erst mal leer, oder durch kopieren einer anderen als Vorlage, öffne sie dann über bearbeiten, füge ein was rein soll und speichere sie dann durch verlassen mit dem Fenster schließen X rechts oben und bestätige die nachfrage das gespeichert werden soll. So bleibt in den includes immer alles an @@Befehlen@@ sichtbar

Roland
Ja, genau.
Das @@own benutzername@@ sorgt dafür das der David Server weiß wem die Nachricht gehört und in wessen Ausgang die gesendete Nachricht entsprechend auch zu legen ist.

setze mal zusätzlich zu den @@von email@adresse@@ auch noch den @@own benutzername@@ (Achtung, der muss vor @@von gesetzt werden)

klar kannste den alten blockieren, brauchst ihn ja nur zu deinstallieren.
Wenn er auf einem System nicht mehr vorhanden ist kann er auch nicht mehr aufgerufen werden und er wird auch durch die Update Funktion nicht wieder installiert.

Darüber wie man auf die Idee kommt das der neue Team (nicht Teams) Client besser läuft als der alte, diskutieren wir hier allerdings besser nicht :o

über die Registry ist es easy

HKCU\SOFTWARE\Tobit\Team\MessageEditor\Settings\AddressInputDisplay

Wenn der Wert auf 1 steht wird die Adresse angezeigt, steht er auf 0 wird der angezeigte Name, bzw. halt was vom Absender in <> übermittelt wurde angezeigt.
Und auch wenn das in Editor Settings gespeichert wird bezieht es sich auch auf den Nachrichtenviewer und die Vorschau.

Alternativ über die Einstellungen:

willst Du das wirklich bei jedem schließen des Programms haben?

Würde Dir auch reichen, wenn es greift sobald sich der aktuelle Benutzer von seinem Rechner abmeldet?

Falls letzteres reicht, dann könntest Du über ein Logoff Script in der Windows Benutzerkonfiguration einfach die LogonData löschen, also:

reg delete "HKCU\SOFTWARE\Tobit\Team\Servers\NameEuresDavidServers" /v LogonData2 /f

Anschließend müssen die Anmeldedaten beim nächsten Start des Team Client zwingend neu eingegeben werden.

dann bleibt eigentlich nur noch der unwahrscheinliche Fall übrig, das Du ihm zwar den Adressordner verknüpft, aber nicht eingeblendet hast.
Ist das Verknüpfungs Symbol rechts oben in seinem Adressordner denn aktiv?
Das ist nämlich auch noch so ein Ding. Der Desktop Client reagiert drauf wenn man die verknüpften Ordner ausblendet. für per EAS angebundene iPhones oder Androids ist das hingegen egal, die sehen trotzdem immer alles.

Passen die Berechtigungen des Ziel-Adress Archivs, welches da verknüpft wurde?

Damit er die Adressen sowohl im Client sehen kann muss er auf das Zielarchiv mindestens Leserechte haben.
(Eigenschften des Archivs > Zugang > Berechtigungen)

Damit er die Adressen im iPhone sehen kann braucht es nur eine passende Benutzer Freigabe.
(Eigenschften des Archivs > Zugang > Benutzer-Freigaben)

Falls man vergisst die Berechtigungen entsprechend zu setzen, aber die Benutzer Freigabe für den Benutzer passend einstallt passiert genau das was Du aktuell erlebst.

Beim Zugriff via EAS am iPhone prüft der Server nämlich nicht ob der Nutzer auch passende Windows NT Filesystem Rechte hat.