Traveler address lookup

Hallo werte Community,

ich würde gerne wissen, wer einen Traveler Service für mehrere Kunden betreibt (Hub) und folgendes beschriebene Verhalten bestätigen kann.

Konfiguration:

- aktuelles 8.5.3.3.1 Release (klassische Version), Domino 8.5.3.3
- EDC (Extended Directory Catalog) eingebunden (beinhaltet mehrere Domänen/Organisationen)
- Traveler Service steht in einer eigenen Domäne

Ich möchte jetzt wissen, ob wir wieder weltweit die einzigen sind (mit dieser Konstellation), die von einem gravierenden Problem betroffen sind.

Wie lässt sich das Problem reproduzieren?

1) Kunde A schreibt ein Mail an eine interne Gruppe "Revision"
2) Mail wird korrekt via Notes an die Gruppenmember zugestellt und in weiterer Folge an deren iOS Geräte
3) Einer dieser Gruppenmember schickt jetzt ein Anwortmail von seinem iPhone/iPad mit der Option "An Alle" (das ist der springende Punkt!)
4) Die Antwort geht jetzt korrekterweise an den Absender retour, zusätzlich aber an die SMTP Adresse "revision@kunde-b.com" - und leider nicht an die Gruppe "Revision" in der eigenen Domäne!

Normalerweise sollte die Antwort zurück an die Gruppe "Revision" gesendet werden.
Der Traveler AddressCacheManager findet die Adresse "Revision" aber als SMTP Alias Adresse beim Kunden B(!) - da der Revisor des Kunden B ein Alias "revision@kunde-b.com" in seinem Personendokument eingetragen hat.
Achtung, die internen Gruppen der einzelnen Mandanten befinden sich logischerweise NICHT im EDC (nur Personendokumente) - was auch nicht umsetzbar wäre.

Das einzige was ich jetzt eben wissen möchte ist, ob ihr (sofern selbe Konfiguration aktiv) dasselbe Verhalten nachstellen bzw. bestätigen könnt.
Meiner Erfahrung nach tritt das Problem erst seit der Gruppenünterstützung in 8.5.3 auf.

Der normale iOS User bekommt von dem Verhalten meist nichts mit, erst wenn sich der falsche Empfänger meldet
Und wenn sich die involvierten Gruppen dann Geschaeftsleitung, Innenrevision, usw. nennen, dann ist das schon weniger lustig

Mir geht es im Speziellen jetzt nur darum, dass IBM dies publizieren muss - PMR Prio 1 läuft schon.

Danke für euren Input.
Michael

"Verbogen" ist eigentlich nichts, sind ganz normale Personendokumente von allen Kunden in einem EDC zusammengefasst, ein ganz gewöhnliches Directory für Mailing eben.
Es sind nur die Gruppen der Kunden nicht includiert, da

1) nicht notwendig, da die Gruppe ja trotzdem via Notes adressierbar ist (bei Antwort incl. Domänezusatz, oder neuer Mail durch manuelles Hinzufügen der Domäne)
2) viele Gruppennamen redundant und somit unübersichtlich wären (mit unterschiedlichen Members natürlich)
3) interne Gruppen für domänenübergreifendes Routing eigentlich nicht benötigt werden

Der AddresscacheManager darf nicht nur den local part der Adresse checken, sondern muss auch den global part berücksichtigen!
"Revision" ist ja nicht dasselbe wie "revision@kunde-b.com", sofern er auf den ganzen String antwortet. Das Mail wird ja ohnehin vom Home-Mailserver versendet, aber der Lookup wird aus performancetechnischen Gründen vorher im Traveler AddressCache durchgeführt, in meinen Augen aber nicht vollständig korrekt.

Ist ja auch egal, interessant wäre jetzt, ob jemand das Verhalten bestätigen kann. Reproduziert ist dies relativ schnell.

Zitat von RockWilder

"Revision" ins Shortname-Feld rein zu schreiben, sehe ich schon als "verbiegen" an. Da hat das nämlich sowas von gar nichts zu suchen.

Interessante Ansicht. Wieso darf ich bei einem Personendokument keinen SMTP Alias verwenden? Es steht beim Short-Name nicht "Revision" drinnen, sondern selbstverständlich die vollständige SMTP Adresse (nur um das klar zu stellen). Jeder User kann sich natürlich eine durch den Admin freigegebene Alias Adresse vergeben, das ist ja wohl gängige Praxis. Der "physische" Revisor in Person hat neben seinem "real" name auch einen SMTP Alias der eben "revision@kunde-b.com" lautet.

Zitat von RockWilder

Wenn ich an eine Gruppe schreibe, habe ich keine Domain hintendran. Jedenfalls, wenn ich eine NRPC-Mail schreibe.

Korrekt.

Zitat von RockWilder

Wenn dann ein Gruppenmitglied ein Reply schickt, wird halt im primary und allen weiteren DDs der Name gesucht, ohne den Suffix hintendran. Und wenn nun der (Teil-)String per Zufall in einem Personendokument gefunden wird, nimmt der Router halt an, dass das Dokument damit gemeint ist, erweitert die Adresse und verschickt die Mail halt da hin.

Stopp. Genau hier liegt der Wurm drinnen. Das Mail, welches am iOS Gerät angezeigt wird (ohne auch nur geanwortet zu haben), zeigt im Empfängerfeld bereits den Namen des Revisors von Kunde B an! Dass eine Antwort natürlich auch an diesen gesendet wird ist klar. Ich würde jetzt trotzdem gerne wissen, wer das nachstellen kann - es ist wirklich sehr einfach. Einfach eine Person suchen (in einer anderen Domäne/Organisation im EDC), die einen Alias definiert hat (da gibt es sicher einige). Dann erstellt man eine Gruppe in Domäne A die sich exakt so nennt. Mail an diese Gruppe senden und am iOS kontrollieren - Überraschung

Zitat von taurec

Steht auf dem iOS Gerät dann die vollständige eMail Adresse oder der vollständige NotesName der Gruppe inkl Domain drin ?

Ganz genau, und zwar die vollständige eMail Adresse des Users, der den Alias "revision@kunde-b.com" hat.

Zitat von taurec

Wie sieht eure Adressauflösung auf dem Traveler Server aus ? Denn wenn er keinen besseren Treffer findet, dann versucht Notes eben einen genau so guten Treffer zu finden, in deinem Fall eben einen User.

Tja, genauso ist es auch - er nimmt den nächstbesten Treffer, egal ob das jetzt der wirkliche User ist oder nicht. Folglich wird das Mail beim Beantworten an einen komplett anderen User versendet - eine Katastrophe schlechthin, vor allem bekommt der User im Regelfall nichts davon mit.

Zitat von taurec

Im Endeffekt müsstet ihr wohl einerseits die vollständige Adressauflösung konfigurieren

?

Zitat von taurec

am besten die Gruppen ebenfalls mitaufnehmen

Absolutes No-Go (logische Gründe die dagegen sprechen siehe weiter oben)

Zitat von heuti

meines wissens nach darf der Traveler Server doch keinen Adresslookup machen, diesen muss er doch immer über den homemailserver des Anwenders machen.
Wäre ja bei einer Mehrmandanten Lösung eine Katastrophe, wenn Anwender der Dom A die Personen aus Dom B sehen und Adressieren könnten,

Prinzipiell hast du vollkommen recht. Aber der Traveler Server hat insgesamt 3 "verschiedene" Lookups:

1. User lookup: to find out who the user is, whether the Traveler server has ACL rights, home mail server, etc. This is required for any Traveler user.
2. Sync lookup: The Apple devices complain about any non-internet addresses, so Traveler attempts to convert any non-internet addresses to internet addresses. Because this is every address (not just those of Traveler users), it is a large number which caused to create a cache of the results so that people sending to the same addresses don't require a lookup all the time. To avoid possible differences between user's mail servers, this is only done on the Traveler server. When Traveler does this lookup, it will use the result if the lookup found exactly one result; any other result causes Traveler to leave the address alone.
3. Device lookup: where the user makes a request in mail, contacts, lookup, etc. to the server to do a lookup. This is done against the user's mail server (in this case it will find the group).

Und wir haben jetzt genau das Problem mit diesem 2. Lookup, mit dem "Cache". Habt ihr das in der Zwischenzeit mal ausprobieren können? Scheinbar verwendet hier keiner einen mandantenübergreifenden EDC...
Da die Mandanten miteinander kommunizieren dürfen/sollen ist das kein Problem. Es wird erst dann ein Problem, wenn eine via Notes eindeutig adressierte Gruppe beim Beantworten vom iOS Device plötzlich an einen ganz anderen User ergeht.

Lt. IBM Support wird in einem "future" Release am Adress-Handling gearbeitet. Nur benötigen wir JETZT eine Lösung, und da sieht es derzeit noch relativ schlecht aus

Zitat von taurec

Darf ich mal raten: Ihr habt auf dem Traveler Server genau ein GlobalDomain Dokument mit allen Domains drin ?

Nein, absolut nicht. So eine Konfiguration hab ich auch noch nie gesehen.

Eigentlich wollte ich nur wissen, ob das von euch jemand nachstellen kann/konnte. Aber scheinbar sind wir wieder mal die einzigen weltweit, die auf ein gravierendes Problem gestoßen sind.

Mittlerweile haben wir einen Workaround zusammen mit dem Support gefunden:

Man kann das Caching am Server deaktivieren, indem man in der NTSConfig.xml den Parameter <PROPERTY NAME="TSS_ADDRESSCACHE_ENABLED_AS_MAIL" VALUE="false"/> setzt.
Natürlich ist Vorsicht geboten, der Server muss bezüglich Performance beobachtet werden, da der Lookup beim MailSync nicht mehr über den lokalen Traveler Cache ausgeführt wird!

Lt. Support wird an einem geänderten Caching Verhalten in einer neueren Version gearbeitet. Auf Empfehlung des Supports sollten wir auf die neue UP1 Version (ohne HA und SQL DB) wechseln, dort wären mehr Issues gefixt als in der klassischen Variante. Weiters wurde uns ein "private" Fix angeboten - wir prüfen das gerade. Wenn in der UP1 Installation das Problem ohne obigen Parameter trotzdem gefixt ist, wird es definitiv einen APAR geben.

Ich war mir sicher, dass dies jemand in seiner Umgebung nachstellen kann, aber egal.

Das Traveler Support Team arbeitet wirklich flink: APAR LO72995
Es wird ein UP2 (publiziert wird das morgen am 11.12.) geben, mit einem HF.