Email an Adresse mit geschweiften Klammern erzeugt neuen Benutzer (zum selber ausprobieren)

  • Noch einer aus der Kategorie "Selber ausprobieren und staunen": 

    Zwei Kunden von mir haben mit Mandanten in Amerika zu tun, die ein DMS einsetzen (offenbar vom selben Hersteller). Das DMS bekommt Kopien des ein- und ausgehenden Emailverkehrs über CC:-Empfängeradressen. Diese Adressen sehen so aus: „{xxxxxxxx}.blabla@domain.com“. Wenn einer der Mandanten eine Email an einen der beiden Kunden schreibt, steht im CC: immer eine der vorgenannten Adressen, wobei die Vorgangsnummer in den geschweiften Klammern steht. 

    Drücken meine Kunden bei einer solchen Email auf antworten (und sie sollen auf „allen antworten“ gehen, weil der Mandant die Antwort automatisch in seinem DMS haben will), dann passiert beim Absenden der Antwort folgendes: 

    Jeder „normale“ Empfänger erhält seine Kopie der Email. Diese werden wie gewohnt extern über POSTMAN verschickt. Die Email an das DMS jedoch erscheint sofort nach dem Abschicken im Ausgangsordner des Absenders als „interne“ Email. Extern wird sie nicht verschickt. Auch im Ausgangsprotokoll erscheint sie als interne Email. 

    Wenn man dann im System nach der Nachricht sucht, stellt man fest, dass im Archive-System unter „Benutzer“ ein neues Archive ohne Namen angelegt wurde. Die Unter-Ordnerstruktur darin entspricht der eines normalen DAVID-Users. Im Eingang dieses Users existiert die bekannten Willkommensnachricht für neue User und die Email an das DMS. 

    Eine Empfängeradresse mit geschweiften Klammern führt also beim Versand der Nachricht dazu, dass der Service-Layer auf Dateiebene einen neuen Benutzer anlegt und die Nachricht dort in dessen Eingang ablegt. Diesen User gibt es nicht als Benutzer im DvAdministrator. 

    Ich habe das unter DAVID.fx 2011, FX12 und mit der aktuellsten david reproduzieren können. Das ist offenbar ein Riesenbock im Servicelayer. Das System macht sich an dieser Stelle selbständig, verändert reproduzierbar das Archivesystem und die Email an das DMS des Kunden wird nicht abgeschickt.

    Das kann jeder von Euch ausprobieren, nehmt dazu einfach die oben angegebene Beispieladresse, schreibt eine Email an sie und schickt sie ab. Wer das zweimal macht, hat anschließend zwei neue namenlose Benutzer im Archivesystem, die er dann manuell über das Infocenter löschen kann. Sichert Euch vorher aber in jedem Fall die ARCHIVE.DIR des User-Verzeichnisses, denn die Datenbereinigung entfernt die Schrottuser nach Löschen der Archive nicht mehr aus der ARCHIVE.DIR, sondern kennzeichnet diese lediglich als gelöscht. 

    Hat von Euch schon jemand ähnliche Erfahrungen gemacht? Gibt es da einen Workaround? 

    Viele Grüsse 

    Werner

  • Ist bei euch das Auto User Anlegen Feature aus? wenn sich ein unbekannter User an Tobit zum ersten mal anmeldet.

    Vielleicht kann man so dieses Verhalten verhindern...

    AutoValidation = FALSE
    ; Default is TRUE
    ; If TRUE is set, a user who has not been entered as a David
    ; user yet, will be automatically defined as a new user when
    ; creating a send job. This will only be possible provided that
    ; the number of licensed users will not be exceeded.


    David.ini

    09-f9-11-02-9d-74-e3-5b
    MfG Kingcopy seit C16 / C64
    Fachinformatiker / Systemintegration
    IT-Systemadministrator
    David (R) 20 User / 500 GB
    David (R) 200 User / 2,5 TB
    d8-41-56-c5-63-56-88-c0

  • Ja, die AUTOVALIDATION setze ich generell immer auf FALSE, denn sonst legt mir jeder Praktikant oder jede Teilzeitkraft, die eigentlich gar keinen Zugriff auf das Email-System haben soll, automatisch einen User an, wenn er aus Versehen das Infocenter auf seinem Rechner startet. Das o.a. Verhalten legt auch nur ein User-Archive auf Dateiebene an. Im DvAdmin selbst wird kein User erzeugt (wie bei AutoValidation=TRUE), es geht also auch keine User-Lizenz verloren.

    Werner

  • Ich hatte soetwas ähnliches bei dem eine Spam Adressbuch Einträge anlegen konnte auch mit geschweiften Klammern

    Noch schlimmer: fremde konnten Termine und Serien anlagen. Dabei hat es ausgereicht wenn man die mail nur zum löschen angeklickt hat !!!

    09-f9-11-02-9d-74-e3-5b
    MfG Kingcopy seit C16 / C64
    Fachinformatiker / Systemintegration
    IT-Systemadministrator
    David (R) 20 User / 500 GB
    David (R) 200 User / 2,5 TB
    d8-41-56-c5-63-56-88-c0

  • Ich habe gerade noch mit einem befreundeten TAR gesprochen: Der hat dieses Verhalten bei einem seiner Kunden schon im August 2011 mit fx.2011 festgestellt und über das Intercom an TOBIT gemeldet. TOBIT meinte damals dazu:

    "Wir konnten diesen Effekt nachvollziehen, ..... Möglicherweise wird hierzu eine Änderung bzw. Anpassung schon in einem der nächsten Service Packs (Hotfixes) oder Releases enthalten sein."

    Er meinte auch, dass TOBIT das offenbar nicht fixen will oder kann, weil es zentrale Funktionen des Service Layers betrifft und es gibt offenbar auch keinen Workaround dazu. Das was Kingcopy im Beitrag vorher beschrieben hat, würde sich dann mit dieser Aussage in so fern decken, als das es offenbar wirklich intern im Service-Layer Funktionen gibt, die bei Triggerung durch die geschweiften Klammern in Abhängigkeit vom Kontext entweder etwas Nützliches oder aber auch etwas total Unvorhergesehenes machen - und TOBIT weiß das schon seit Langem und macht die Augen zu.

    Meine beiden Kunden wird das sicher freuen, wenn ich Ihnen davon berichte.

    Ich wünsche Euch ein schönes langes Wochende!

    Werner

  • Geschweifte Klammern haben in der David-Syntax eine spezielle Bedeutung. Sie bezeichnen beim Anlegen eines Verzeichnisses den auf Windows-Ebene zu verwendenden Namen. Der vor der geschweiften Klammer liegende Teil des Betreffs ist der Verzeichnis-Name im David-Client, der innerhalb der Verzeichnisname auf Windows-Ebene.

    In einer eMail-Adresse hat eine geschweifte Klammer - also ein Sonderzeichen - nichts zu suchen. Denn diese Sonderzeichen werden je nach eingestellter Browser-Landessprache unterschiedlich dargestellt und sollten daher in Adressen vermieden werden. Wenn die Dokumentenverwalter das mit den geschweiften Klammern so haben wollen, dann werden noch einige Probleme auf die zukommen. Denn nicht nur Java-Scripte können da schon mal etwas seltsam drauf reagieren.

    Möglicherweise liegt ein Übersetzungsfehler vor, und die Amis wollten die geschweifte Klammer im Betreff und nicht im eMail-Namen. Oder aber das DMS fügt die geschweiften Klammern und dazwischen liegende Zählvariablen hinzu, um die Nachrichten wiederzufinden. Damit sind sie die Klammern aber NICHT Teil der eMail-Adressen. Ergo ist vor dem Beantworten solcher eMails die geschweifte Klammer zu entfernen!

    Bei europäischen Providern ist ein Sonderzeichen wie die geschweifte Klammer im eMail-Namen nicht zulässig und wird beim Anlegen eines neuen eMail-Alias normalerweise als ungültig abgewiesen.

    4 Mal editiert, zuletzt von Arno (17. Mai 2013 um 19:08)

  • Hallo,

    RFC 5322 gibt eindeutig vor, dass geschweifte Klammern im local part erlaubt sind.
    Somit sollte Tobit dies auch unterstützen und macht hier ggf. etwas falsch.
    Ich kann den Sachverhalt bei mir nicht mehr testen, da wir Tobit zum Glück ersetzt haben.

    Gruß Despo

  • Reagiert der Servicelayer nur beim Abschicken der Mail so oderbesteht die Möglichkeit, dass auch beim Empfang einer E-Mail mit geschweiften Klammern Unvorhergesehenes ausgelöst wird?
    Das wäre ja Wahnsinn wenn man von außen nur durch das Senden von Emails mit geschweiften Klammern den David Server manipulieren könnte.

  • @Despo: grundsätzlich nach RFC 5322 zulässig sind geschweifte Klammern im local Part einer eMail-Adresse in der Tat. Aber die mir bekannten Provider verweigern die Erstellung von eMail-Alias oder eMail-Konten, die eine geschweifte Klammer enthalten. Denn geschweifte Klammern finden als Variablenkennung Verwendung.

    @Kato: ausprobieren. Ggfs. via Intercom mal eine dem entsprechende Anfrage einsteuern.

    2 Mal editiert, zuletzt von Arno (18. Mai 2013 um 12:48)

  • Hallo zusammen,

    das Problem tritt derzeit offenbar nur beim Versand auf. Die Kunden erhalten von Ihren amerikanischen Mandanten wie geschildert Emails, bei denen im TO: eine oder mehrere hausinterne Empfänger genannt sind, im CC: aber neben evtl. anderen Empfängern auch die im Eingangspost geschilderte DMS-Empfängeradresse mit den geschweiften Klammern. Da nach RFC diese Emailadressen in Ordnung sind, werden sie von allen beteiligten Providern und Servern kommentarlos übermittelt und schlagen beim Empfänger im DAVID-Server auf. Dort kann man sie öffnen, drucken, löschen und sonst was damit machen - alles kein Problem. Wenn man aber auf eine dieser DMS-Adressen antwortet, schlägt der beschriebene Mechanismus zu und man hat auf Dateiebene einen kompletten neuen User ohne Namen im System.

    Das bedeutet: Der Service-Layer entwickelt beim Versand einer Nachricht an eine Email-Adresse mit geschweiften Klammern (die vollständig den gültigen Standards entspricht) ein Eigenleben und das ist in meinen Augen kein Feature, sondern ein übler Bug, der TOBIT bereits seit 1 1/2 Jahren bekannt ist.

    @Kato: Da schon Kingcopy von ähnlichen Erfahrungen in einem anderen Zusammenhang berichtet hat, liegt die Vermutung nahe, dass hier ein systematisches Problem vorliegt, das auch noch an ganz anderer Stelle zuschlagen kann. Wenn der Service-Layer von sich aus alleine durch eine passende Email-Adresse dazu veranlasst werden kann, ein komplettes Benutzer-Archive anzulegen, eine Willkommens-Email zu erzeugen und eine für den externen Versand bestimmte Nachricht in den Eingang dieses neuen Benutzers zu kopieren, dann ist in meinen Augen vom Prinzip her auch alles andere denkbar. TOBIT wird sich dazu aber überhaupt nicht äußern.

    Vielleicht habe ich die nächsten Tage einmal Zeit, ein paar Experimente mit einem Testsystem zu machen.

    Übrigens: Einer der Mandanten hat Lotus-Notes, der andere MS-Exchange. Wenn meine Kunden die Emails jeweils mit z.B. Outlook beantworten, funktioniert alles ohne jede Klage.

    Werner

  • Das sind beunruhigende Vorstellungen. Abhängig davon ob der Servicelayer auch beim Empfang einer solchen E-Mail so dämlich reagiert, ist es natürlich keine schöne Idee dass jemand eine päparierte E-Mail tausendfach an den Server schickt um ihn lahm zu legen. Es genügt ja die Vorstellung, dass 1 User auf "Alle Antworten" klickt und der Server verreckt.....

  • Hi,

    das wirklich schlimme ander Geschichte ist einfach, dass jeder Benutzer diese Funktion einfach ausführen kann.
    Desweiteren könnte ich mir vorstellen, dass mit anderen @@ oder { } Befehle Funktionen ausgeführt werden, da der
    Service Layer beim Versenden einer EMail genau auf solche Steuerelemente achtet.

    Es gab ja zwischendurch mal in David.F einen BUG, dass mit mit @@ATTACH Dateien auf dem David Server als Analge automatisch
    mitversenden lassen konnte. Bedeutet, der Benutzer antwortet auf eine eMail, wo @@ATTACH ...\David\Code\David.usr drin steht
    und schon wird die David.usr als Anlage versendet.

    Dieser BUG sollte aber mitlerweile raus sein.

    Gruß,

  • @Kamil: Dieser Bug wurde dadurch entschärft, dass Du beim Weiterleiten/Antworten derartiger Mails darauf hingewiesen wirst, dass im Text DAVID-Steuerbefehle stehen. Danach schaltet das Infocenter auf Textmodus um und nimmt die @@-Zeichen raus.

    Ich habe noch ein bisschen rumgespielt und dabei entdeckt, dass man bei der o.a. Problematik durch Weglassen des "@domain...." in der Empfängeradresse auch interne Faxe verschicken kann. Wenn man im Infocenter also eine neue Email erstellt, als Empfänger nur "{12345}" eingibt und das dann abschickt, legt der Service-Layer wie gehabt einen neuen Benutzer an, macht dort sein Willkommensemail in den Eingang und dann noch die gerade erstellte Nachricht als Fax. Und ich bin sicher da geht noch mehr.

    Vorstellbares Szenario: Ein User (und es kann wirklich ein DAVID-User mit so gut wie keinen Rechten sein) bekommt eine Joke-Mail, wo zig Empfänger im TO: stehen. Am Ende dieser Liste stehen dann noch 30 fiktive Empfänger nach dem Schema aus meinem Eingangspost. Das Infocenter zeigt Dir die Empfängerliste ja nicht komplett an, sondern spricht nur von "und ... weitere". Unser DAU drückt auf Antworten, weil er sich auch an dem Blödsinn beteiligen will und schon hat der Admin gut zu tun, weil es 30 neue Benutzer im System gibt. Einziger Trost: Der Admin weiß dann auch, wer es war und kann demjenigen einen Besuch abstatten. Aber er kann nichts tun, um so etwas zukünftig zu verhindern.

    Übrigens: Wenn man zwischen den geschweiften Klammern die User-ID eines bekannten internen DAVID-Users schreibt, erhält dieser User die Nachricht direkt. Der Service-Layer legt in diesem Fall keinen neuen sinnlosen User an. Vielleicht ist das auch eine der oft dementierten Hintertüren, über die TOBIT z.B. seine Werbeemails verteilt. Ich erinnere nur an die Zeit, als vehement für FX12 geworben wurde und in meinem Kundenkreis mehrere Installationen waren, wo plötzlich alle User der jeweiligen Site eine Werbung für das Update auf FX12 in ihrem Eingang hatten, obwohl es keinen entsprechenden regulären Email-Eingang gegeben hat.

    Werner

  • Ich hatte es definitiv das eine Spam Email einen TERMIN im System angelegt hatte und dadurch eine AUTO Reply Terminbestätigung an die Spam versender Adresse kopiert wurde.

    Wenn ich dazu nur die Bilder finden würde... Ich suche.. auch hier im Forum finde ichs nicht mehr , ist schon Jahre her...

    ich neige nach Stundenlager Suche dazu zu sagen das mein Report darüber gelöscht wurde... denn diese Mail hatte das Potential den SL zu zerstören. Wie immer war ich mir warscheinlich über die Tragweite nicht im klaren und hatte das Verhalten nur als Gefährlich abgetan.

    09-f9-11-02-9d-74-e3-5b
    MfG Kingcopy seit C16 / C64
    Fachinformatiker / Systemintegration
    IT-Systemadministrator
    David (R) 20 User / 500 GB
    David (R) 200 User / 2,5 TB
    d8-41-56-c5-63-56-88-c0

    3 Mal editiert, zuletzt von kingcopy (22. Mai 2013 um 10:23)

  • Ich hatte es definitiv das eine Spam Email einen TERMIN im System angelegt hatte und dadurch eine AUTO Reply Terminbestätigung an die Spam versender Adresse kopiert wurde.

    Wenn ich dazu nur die Bilder finden würde... Ich suche.. auch hier im Forum finde ichs nicht mehr , ist schon Jahre her...

    ich neige nach Stundenlager Suche dazu zu sagen das mein Report darüber gelöscht wurde... denn diese Mail hatte das Potential den SL zu zerstören. Wie immer war ich mir warscheinlich über die Tragweite nicht im klaren und hatte das Verhalten nur als Gefährlich abgetan.


    Dieser hier?

  • Ja! wie hast Du die gefunden?

    09-f9-11-02-9d-74-e3-5b
    MfG Kingcopy seit C16 / C64
    Fachinformatiker / Systemintegration
    IT-Systemadministrator
    David (R) 20 User / 500 GB
    David (R) 200 User / 2,5 TB
    d8-41-56-c5-63-56-88-c0

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!