Beiträge von complusit

    Hallo Leute,


    Habt ihr schon mal folgendes Problem gehabt und vllt. eine Lösung für mich:


    Kunde mit neuester David Version (sitecare) hat eine Mitarbeiterin, die verschlüsselt und signiert Mails verschicken muss. Habe ihr also zunächst im David Administrator das Recht gegeben das zu tun (screen1.jpg), habe auch allgemein unter System freigegeben, dass man das tun darf (screen2.jpg).


    Danach habe ich in ihrem Client eine Signatur angefordert und danach das D-Trust Freischaltverfahren mit der PIN Nummer durchgezogen. Danach kam die Mail mit dem Zertifikat (screen3.jpg). Wenn ich das anklicken will um es zu importieren, kommt zunächst noch korrekterweise die Mail mit dem Importhinweis (screen4.jpg). Danach stürzt der David Client vollumfänglich nach einigen Sekunden Sanduhr ab. Das heißt er schließt sich ohne weitere Meldung. Auch unten in der Taskleiste bei der Uhrzeit ist das David Icon dann weg.


    Auch auf einem anderen PC, an dem ich mich mit diesem User mal testweise angemeldet habe, passiert das selbe. Neustart von PCs und Server bringt nichts. Ein Doppelklick auf die Datei im Anhang führt im Übrigen zu dem selben Ergebnis.


    ??? WTF? Habt ihr das schon mal gehabt?


    Gruß, Oliver Hoppe

    Kannst du immer noch sagen, dass das ein brauchbarer Weg ist?

    Wir mussten uns leider wieder davon verabschieden diese Open Source Lösung zu benutzen und sind nun wieder bei Te-Systems XCAPI. Denn wir haben in der Praxis festgestellt, dass die ankommenden Faxe teilweise nicht lesbar waren. Da war irgendwas mit dem Dateiformat und mein Kollege musste ein kleines Tool zur Ordnerüberwachung programmieren, was die Dateien wieder in ein lesbares Format umwandelt. Wenn du dazu genauere Infos brauchst, kann ich den Kollegen bitten das an dieser Stelle reinzukommentieren, bzw. mir zu sagen, was da genau los war. Bei uns war aber der Sonderfall der, dass wir den Provider Sipgate direkt an Freeswitch angebunden haben wollten. Vllt. läuft es mit der FB besser.


    Gruß, Oliver

    Ja wir nutzen den kostenpflichtigen Service. In einer Arztpraxis hat man i.d.R. auch nur sehr wenige User. Da halten sich die Kosten somit auch im Rahmen.


    Und ja, kingcopy, ich gebe dir Recht. Aber das Gesamtpaket mit Spamfilter und auch noch Filter für "richtige" Trojaner macht aus Sicht des Kunden dann schon Sinn.


    @caddo: Voilà.


    @alle Habt ihr Tipps welche Formate man noch so sperren sollte?

    Mhh solche Regeln haben wir bei uns gar nicht... Sollten wir aber sicher besser einstellen oder?

    Viele Kollegen lösen das auch per Firewall. Die Sophos kann das beispielsweise ganz gut. Aber da unsere Kunden i.d.R. "notleidende Kassenärzte" sind, ist der Investitionswille leider oft zu niedrig, als dass wir solche "teuren" Lösungen verbauen dürften. Dann hat sich der Kompromiss die Mails mit potentiell gefährlichen Anhängen in David einfach zu "killen" als der beste herauskristiallisiert.

    Auch wenn korrekte Mails mit Word Anhängen z.B. von KV auch mal hängen bleiben. Man kann aber in David zwei HTML Files im Ordner /Vscan/ passend editieren und den Haken setzen, dass der Absender informiert wird, wenn sein Mail nicht zugestellt wird. (Beispiel siehe Anhang)

    Damit erreicht man im besten Fall, dass die KV nochmal nachdenkt und ein PDF schickt - oder zumindest verwundert den Kunden anruft.


    Gruß, Oliver

    Hallo David,


    Wir nutzen bei vielen unserer Kunden diese Funktion des generellen Löschens von diversen Anhängen auch. So halten wir uns pauschal viele Trojaner vom Leib die z.B. mit Java Script (*.js) oder in Makros von Word Files daherkommen. Auch *.exe und die gängigen gepackten Fileformate blocken wir. Das klappt eigentlich seit der Einführung sehr gut, wenn ich mal unsere Langzeiterfahrung betrachte.


    Dass es mal zu mehr "Angriffen", mal zu weniger solchen Mails kommt, stellen wir in der Tat auch fest. Frag mich bitte nicht warum das so ist. Aber Spam und Trojanerversand scheint gewissen Wellenbewegungen zu unterliegen.


    Schöne Grüße, Oliver

    Mit dem guten alten PantsOff gehts auch. 8o Wird zwar inzwischen von Windows Defender als "hochgefährlich" eingestuft, aber man kann diesem ja sagen, dass es das nicht ist.


    Tipp: Wenn man Pantsoff ch in die Suchmaschine eintippt findet man in der Schweiz auch noch einen Downloadlink.


    Grüßle, Oliver

    Mein Bauchgefühl sagt mir auch, dass da was im Busch ist. Aber noch weiß ich nicht warum. Vllt. liegt es daran, dass die Provider was geändert haben, oder Tobit muss seinen Grabbing Dienst mal wieder anfassen und verbessern.


    Wir werden sehen. Vllt. melden sich hier ja noch weitere Betroffene.


    Gruß, Oliver

    Danke, riawie, für deine Einschätzung. Problem bei uns ist, dass das Thema früher nie und jetzt bei mehreren Kunden in regelmäßiger Wiederholung alle paar Tage auftritt.


    Ist meine Annahme richtig, dass die Mail(s), an der/denen er letztlich scheitert, dann im Ordner

    David\Apps\Dvgrab\In liegen bleibt/bleiben, wenn der Grabbing Dienst sich beendet?


    Dann hätten wir ja einen Anhaltspunkt.


    Um es etwas einfacher zu machen könnte man auch in den Einstellungen der abzurufenden Postfächer mal die Option Kopie aller Nachrichten auf Server belassen - welche viele angehakt haben - mal abstellen.

    Das haben wir bei allen betroffenen Kunden bereits getan. Jedoch kommt es nach einigen Tagen wieder zu dem Problem. Anscheinend werden sie öfter mit solch fehlerhaften Mails beschossen.


    Wir updaten jetzt mal einen der betroffenen Kunden (kostenpflichtig) auf die neueste David Version. Dann werden wir sehen, ob sich die Probleme damit erledigen. Denn auffällig ist es ja schon, dass das Problem bei uns aktuell nur 4 Kunden betrifft, die alle noch mit alten David Versionen unterwegs sind.


    Ich werde berichten, ob's erfolgreich war.


    Gruß, Oliver

    Hallo Tobit-Cracks,


    Wir registrieren bei mehrerer unserer Kunden in den letzten Tagen ein Phänomen, welches früher schon mal diskutiert wurde. z.B. hier im Forum oder hier.


    Das Problem ist, dass sich der Grabbing Server Dienst nach ein paar Sekunden Laufzeit von selbst beendet. Wir räumen dann streng nach Tobit Knowledgebase im Ordner \david\apps\dvgrab auf und starten ihn erneut. Dann ruft er wieder ab, und stürzt irgendwann wieder ab.


    Wir haben jetzt per Webmailer direkt beim Provider (Ionos) alle Postfächer leergeräumt und danach lief es wieder. Was uns zu der These bringt, dass es bestimmte Mails sein müssen, die den Absturz des Grabbing Servers verursachen. Vllt. Spam? Vllt. Viren/Trojaner?


    Was ich noch dazu sagen muss: Alle Kunden, die bislang bei uns betroffen sind, haben zwar David 3, aber nicht die allerletzte Version. z.B. hat einer diese hier im Einsatz: 12.00a - 2913


    Gibt es dazu schon neue Erkenntnisse? Oder haben vllt. Kollegen das Problem seit Kurzem auch wieder verstärkt? Ist euch ein Patch in einer aktuellen Version bekannt, der das Problem löst?


    Vielen Dank für alle erleuchtenden Beiträge!


    Gruß, Oliver

    riawie


    Nur damit das auch meinerseits klargestellt ist: Ich finde deinen Einsatz hier echt toll und möchte auch mal explizit Danke sagen! Es ist sicher nicht selbstverständlich, dass man sich in einem Forum "für lau" solche Mühe gibt, den anderen zu helfen.


    :)


    Gruß, Oliver

    Der einzig richtige Weg zur Behandlung des "Problems" wäre das Tobit im David Client erzwingt das man einen Empfänger ins "An" Feld einträgt, so das der Postman einen RFC konformen To: Header erzeugen kann. Gerne dann auch noch mit einer Konfigurationsoption das der Client dieses für den Nutzer übernimmt der nicht dran denkt und von mir aus auch noch konfigurabel um so vorgaben wie "To: nondisclosedrecipients@domain.tld" oder ähnlich, ganz wie es dem Betreiber des Systems belieben mag.

    Das sehe ich auch so wie riawie. Und es ist ja auch nicht jeder User, der Tobit im Alltag benutzt in Ahaus geschult worden. Die allermeisten werden ja noch nicht mal durch das Systemhaus in die Benutzung eingewiesen.


    Also wir halten fest: Bislang brauchte man das AN Feld bei IONOS nicht auszufüllen - ab jetzt muss man es tun. Das hat eben zu der Verwirrung jedenfalls von einigen unserer Kunden geführt. Es wäre schön, wenn Tobit hier nachbessern könnte, so dass so ein Fauxpas dem User gar nicht mehr unterkommen kann.


    Und ehrlich gesagt: Ich hatte es erst mal auch nicht auf dem Schirm, dass unsere Kunden das AN Feld nicht ausgefüllt hatten, als wir die Fehlerbeschreibung reinbekamen.


    Ob man dies jetzt - so wie von riawie oder tab-soft getan - als Anlass nehmen muss seine eigene Person mit ironischen Posts über andere Forumsteilnehmer zu erheben, steht dabei auf einem ganz anderen Blatt. Wäre zumindest nicht mein Style.


    Kollegiale Grüße an alle!


    Oliver

    Kann sein, jedoch hat das unser Kundenkreis wohl so nicht verinnerlicht gehabt. :|

    Wir haben jetzt einen Workaround gefunden, nachdem der Tipp von riawie nicht funktioniert hat, einfach den Haken bei "Rundsendung" rauszunehmen.


    Bei uns lag es daran, dass 1&1 es nicht mag, wenn man alle Empfänger einer Rundmail DSGVO konform nur im BCC Feld einträgt und dabei das AN Feld leer lässt. Also habe ich meine eigene Mailadresse ins AN Feld eingetragen und bei BCC die eigentlichen Kunden/Empfänger.


    Danach ging die Rundsendung komplikationslos raus.


    Schöne Grüße, Oliver

    Hallo Leute,


    Danke für die spannende Diskussionsrunde hier. Ich möchte nur mitteilen, dass wir bei einem Kunden genau das selbe Problem mit GMX und Web.de Mails bei Rundsendungen haben.

    Unser David Mailserver ist ganz ähnlich konfiguriert, wie der von arnes. Provider ist bei uns aber Mittwald.


    Hier eine Meldung:


    <Testus.Testmann@gmx.de>: host mx01.emig.gmx.net[212.227.17.5] said:

    554-Transaction failed 554-Reject due to policy restrictions. 554 For

    explanation visit

    https://www.gmx.net/mail/sende…nes?ip=185.15.192.33&c=hi (in reply

    to end of DATA command)


    Im Anhang die Guidelines, die wir von GMX vorgeschlagen bekommen. Uhrzeit ist gecheckt. Die sind synchron.


    Die Frage die sich mir stellt: Warum kriegen wir so etwas seit Kurzem? Ich habe über 130 aktive David Installationen da draußen am Laufen. Alle sind in etwa identisch konfiguriert. Also immer Mailversand über SMTP und Abholung beim Provider über POP. Ok, es sind bei unterschiedlichen Kunden unterschiedliche Provider dabei.


    Kann es sein, dass Web.de und GMX hier in letzter Zeit ihre Zäune bezgl. Spamschutz hochgezogen haben? Wäre aber schlecht. Bei unserem Kunden handelt es sich um eine Schule, die in Coronazeiten immer mal wieder Rundmails an Eltern, Schüler und Lehrer schicken muss. Und diese Privatleute haben nunmal ziemlich oft GMX und Web.de als Mailanbieter.


    Ich hoffe wir finden hier an der Stelle noch einen Lösungsansatz. Wenn ich mit irgendwelchen Screenshots oder Protokollen helfen kann, gerne!


    Schöne Grüße, Oliver

    Hallo Leute! Wahrscheinlich eine saudumme Frage, aber ich checks zur Zeit echt nicht:


    Kunde, der bislang alte David Version hatte, verlangt, dass beim Ausdruck von eingegangenen Mails auch immer die Liste der CC Empfänger mit auf's Papier gedruckt wird. Beim alten David ging das - sagt er.


    Bei der aktuellen Version, die wir ihm die Tage eingerichtet haben, und bei der wir das David Migration Tool benutzt haben, um die alte Version zu migrieren, druckt er nur die Liste der AN Leute mit aus, nicht die CCs.


    Könnt ihr mir sagen: Ist das A) eine Funktion, die es früher mal gab, aber die jetzt von Tobit eingespart wurde, oder besser B) wo der Haken rein muss, damit er das wieder mit ausdruckt?


    Vielen Dank für eure Tipps!!!


    Oliver