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

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 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

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

@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