Beiträge von andev

    Ich habe diese erfahrung mit verteilregeln die berichte nach ein archiv kopieren oder verschieben das nicht mehr existiert (also gelöscht ist).

    Danke für den Hinweis. Hat das Tool David-Rule-Check zum "Leben" erweckt.

    Werde es jetzt nochmal ein paar Tage mit aktiviertem 2nd Scan testen.

    Zudem aus dem Support Chat mit Tobit:

    ...wir haben nun eine Anpassung vorgenommen, diese wird im kommenden Rollout enthalten sein...

    Schaun wir mal.

    Hi riawie

    Ich habe Sonntag noch alle betreffenden Konten auf "X-ENVELOPE-TO:" umgebaut und den 2nd Scan wieder aktiviert.

    Just tauchen wieder Mails direkt im Archiv auf. Im To ist manchmal Bullshit drin, manchmal nicht. Das sollte ja aber jetzt egal sein, da das - immer passende - X-Envelope-to ausgewertet werden sollte.

    Zudem scheint das korrekte Archiv (X-DESTARCHIVE) gefunden zu werden, die Mail aber dennoch nicht verschoben.

    Weitere Vorschläge oder Ideen?

    Code
    X-DESTARCHIVE: \\dc\david\archive\user\1002C000\in\
    ...
    X-Envelope-to: mitarbeiter@firma.de
    ...
    To: "mitarbeiter@firma.de" <mitarbeiter@firma.de>
    ...
    X-DvISE-Msg-Identification: 223::1608048424......
    Zitat

    ...einen neuen Benutzer auf die richtige Weise einzurichten...

    Und genau hier ist glaube ich das Problem (bei dieser Kommunikation). Ich bin nicht der Meinung, das "dein" Weg der Richtige ist und "mein" Weg der falsche.

    Tobit bietet 2 Moglichkeiten (ohne Catchall) ein POP3-Abruf einzurichten.
    1) Im DvAdmin unterhalb des Benutzers, welches einen Eintrag in Sytem\David\Grabbing Server erstellt und vom DvGrab zur Abholung benutzt wird.

    2) Im DvAdmin unter Grabbingserver Konten, welches einen Eintrag in Sytem\David\Grabbing Server erstellt und vom DvGrab zur Abholung benutzt wird.

    Ob ich das nun unter 1 oder 2 einrichte MUSS egal sein. Es wäre absoluter Blödsinn, etwas zu ermöglichen, was der "falsche" Weg ist.

    Wenn es darum geht in 1 und/oder 2 das X-Envelope-To als auzuwertendes Feld zu nehmen, dann wäre die Frage, warum macht das David nicht von Haus aus, wenn das To Feld eh zu möglichen Fehlern führt. DAS könnte eine Möglichkeit für zukünftige, bessere Einrichtungen sein und bei Wartungen ggf beim Kunden nachgeholt werden. I agree....

    Zitat

    wie nicht wenige andere auch

    z.B. das Schulungsteam von Tobit. Ich hab gerade noch einmal in meiner Doku nachgesehen...


    ----

    Lange Rede kurz:

    Fakt ist, ich/wir haben bei 99% unserer Kunden, wie auch bei uns, NICHT die "X-Envelope-To Auswertung" an, weil das kein Standard ist und auch in den Schulungen als nicht sooo wichtig kommuniziert wurde, wenn überhaupt (die letzte ist schon ne Weile her).

    Fakt ist, bei 99% unserer Kunden, die MIS benutzen, ist 2nd Scan aktiv. Weil beides auch durchaus Sinn macht. Die ohne MIS bekommen weniger SPAM oder leben mit mehr davon. Ist dann so.

    Fakt ist, wenn MIS + 2nd Scan + "nicht RFC Zeichen" im To oder machmal auch eben nicht ?!?, dann wird die Mail von David falsch abgelegt.

    Damit liegt der Ball - meiner Meinung nach - zur Lösung eines besseren Handlings bei "nicht RFC" Headern bei Tobit. Und sei es Unverteilt.

    Um das Problem, bei den betroffenen Kunden zu beheben, werde ich da wohl die Einstellungen anpassen. Das verschiebe ich persönlich aber auf 2021 :P

    Vielleicht gibbet ja bis dahin noch nen Rollout.

    Danke dir riawie für deine ausführliche Aufklärung.

    riawie Da 99,9% der Mails mit den "falschen" Einstellungen ja korrekt ge'2nd scannt und zugestellt werden, ist die Rechnung leider nicht so amortisierend.

    Zudem bezahlen Kunden ungerne Rechnungen für Leistungen (Umbau), die Aufgrund eines Fehlers in einer Software auftreten, für die sie viel Geld (Lizenzen/Sitecare) bezahlen. Und das auch noch durch ein Modul, welches sie nochmals extra bezahlen (MIS).

    Danke für die ausführliche Erklärtung. Mir war nicht klar, das die selbe Abholung (POP3) so unterschiedlich agiert, jenachdem wo sie eingerichtet wurde.

    Fraglich warum der Tobit Support das nicht weiß ?!?!

    Ich habe jetzt also die Möglichkeit, bei allen Kunden die MIS benutzen (wollen), den 2nd Scan zu deaktivieren oder sämliche Abholungsmethoden umzubauen und ggf. noch Personal zu Schulen, das sie die Konten anders anlegen, als gewohnt.

    Mhh...

    Zitat

    ...denn einfache Hochkommata sind schlicht unzulässig im To: Header...

    Ok, mache von den Mails haben ein ', oder ", oder ? im To, die dürfen dann auch falsch zugeordnet werden.

    Das sind aber nicht alle und zudem sollten die dann nicht in Unverteilt laden?

    Zitat

    da kann man jetzt trefflich drüber streiten.

    Da hast du wohl recht ;)

    Zitat

    Zunächst sind die eMails über welche wir hier reden so sehr defekt ins Weltweite eMail System eingeleitet worden, das sie eigentlich bereits vom ersten empfangenden Server hätten abgelehnt oder verworfen werden müssen, denn einfache Hochkommata sind schlicht unzulässig im To: Header.

    Da hast du wohl recht. Diese Mails aus M$ System dürfen wirklich nicht ins System eingeleitet werden...

    Weder im To als im X-Envelope-to sind ' vorhanden. Nur name@domain.de und dazu auch noch die richige.

    Zitat

    Würde der Verwalter des jeweiligen David Servers seine Arbeit richtig gemacht haben und den Transport der Mails von seinem Provider zu seinem David Server sinnvoll eingerichtet haben

    Ich soll also nicht einen Weg der Einrichtung benutzen, der vom Hersteller eingebaut wurde um ihn zu benutzen, weil er "böse" ist? Belassen wir es dabei....

    Zitat

    Das Problem mit dem 2cnd Scan scheint aktuell so zu sein, das der Grabbing Server Mails die er für einen speziellen Nutzer einsammelt dem 2nd Scan ohne ein Schildchen dran für welchen Nutzer er sie eingesammelt hat vorwirft. Anschließend darf der postman nach durchlauf durch den 2nd scan raten wem er die Nachrichten zustellen soll und trifft auf den fehlerhaften To: header welcher...

    Die fehlerhafte Zustellung hört auf, wenn man den 2nd Scan abschaltet. Nach deiner Theorie werden die zuvor vermeintlich fehlerhaften Header, bei der Abschaltung des 2nd Scan also wieder korrekt, weil das Problem an den Headern liegt?

    Denn es landen dort auch Mails von Absendern, die mit dem gleich System (Outlook/Exchange zu David) auf beiden Seiten mehrfach Kontakt haben. (verschiede Lieferanten mit verschiedenen Mitarbeitern). Und mittendrin ist mal ein To Header nicht RFC Konform und bei Abschlatung des 2nd Scan dann wieder schon?

    Also bitte....

    Zitat

    Natürlich kann man nun drauf warten das Tobit den Grabbing Server so modifiziert...

    Natürlich kann ich erwarten, das der Grabbing Server so modifiziert wird, das er die Mails an die im to/envelope-to adressierte Person abliefert.

    Schönes Wochenende 8)

    riawie Ja wir holen die Mails pro User ab, CatchAll benutzen wir nicht.

    Auch wenn dein Lösungsweg zu Ziel führen könnte/würde, gibt es ein David Internes Zuordungsproblem, wenn MIS mit 2nd Scan genutzt wird - und das wohl schon seit Jahren.

    Denn wenn ein Konto im Admin bei einem Benutzer eingerichtet ist, und nur dieser Benutzer diese Mailadresse hat, und nur Mails an ihn in seinem Konto auftauchen, dann darf David die nicht woanders hin legen, als in sein Konto (ausser es gibt ne Regel/Einstellungen, die dieses verhalten abändert).

    Ich bin der Meinung, dass das gerne mal gefixt werden darf, ohne das die Abholung bei n Installationen ungestellt werden muss.

    wie kommen Eure Mails rein bzw. wie holt ihr sie bei Eurem Provider ab und welches Header Adressfeld wertet Ihr bezüglich der Erkennung der lokalen Empfänger aus?

    zu 1) Mails kommen via POP3 über den Grabbing Server.

    zu 2) Zuordnung lt. David Standard (Eingetragene Adressen im Benutzer)

    Hi.

    Ich benutzte auch das 3 Spalten Layout und bei mir ist es genau so.

    Wenn ich im rechten Teil ENTF drücke, passiert nichts. Hier ist man ja auch im Editor und würde einen Buchstaben löschen, aber das editieren ist ja bei der Ansicht deaktiviert.

    Ist mir in meinem Workflow aber noch nicht aufgefallen. Mein Focus ist meist in der mittleren Spalte und hier navigiere ich mit Hoch/Runter/Entf/Strg+M und schaue nur im rechten Bereich.

    Der Wechsel in David passiert meist über die Taskleiste oder mit Alt+Tab. Daher bleibt der Focus in der mittleren Spalte.

    Moinsen.

    Ab und an kommt es vor, dass das David Mails direkt im Archiv-Root (David\Archive) ablegt.
    Diese sind von verschiedenen Absender, an verschiedene Empfänger und zeitlich mal diese mal jene.

    Sämtliche offensichtlichen Umleitungs-/Verteil-/Verschieberegeln sehen gut aus.

    Hat jemand von euch ne Idee, wie man der Ursache näher kommt?

    Moriis Ich färbe mir die Blöcke zum testen gerne ein.

    z.B. hier in der Vorlage ist die Schrift bei Gelb und Orange definiert (div/font Blöcke) = Arial

    Der Text der original Mail hat die Schrift des senden Clients = Verdana

    Die leeren Zeilen (grün) und der Bereich zwischen der Vorlage und der originalen Mail sowie das "Test von O16 30. Oktober 2020, 09:39 Uhr" sind "undefinierter Bereich". Hier ist die Schrift lt. Client-Einstellungen >> Editor >> Standard Schriftart = Tahoma

    Wenn ich vom Betreff via Tab in den Text springe, schreibe ich in Arial weiter.

    Wenn ich mit der Maus in den Text spring und die falsche Stelle treffe, schreibe ich in Tahoma weiter.

    Wenn man die offensichtlichen Stellen, die man "treffen" kann entfernt oder dort die Schrift definiert, dann sollte das eigentlich passen.

    Ich hoffe das hilft dir ein wenig beim Verständnis bzw. bei der Fehlersuche.

    Allerdings bin ich schlampig mit dem abrufen und speichern ganzer Installationsdatenträgerabbilder, so das ich da nur sehr wenige von habe.

    riawie davon habe ich noch ein paar liegen ;)

    david-fx.iso

    david-fx2011.iso

    david-fx12.iso

    david_Build_2684_17.06.2013.iso

    david_Build_2743_19.06.2014.iso

    david_Build_2748_11.07.2014.iso

    david_Build_2755_21.08.2014.iso

    david_Build_2832_02.12.2015.iso

    david_Build_2913_17.01.2017.iso

    david_Build_2975_16.01.2018.iso

    david_Build_2993_08.06.2018.iso

    david_Build_3006_13.08.2018.iso

    david_Build_3224_19.08.2020.vhd