Ich habe gerade unerwartet ein wenig Zeit und möchte daher etwas "zu Papier" bringen, das ich schon ziemlich lange auf meinem Zettel habe.
Wir beobachten bei einigen Kunden seit einem Versionswechsel auf Notes und Domino 12 recht unangenehme Probleme beim Austausch von Kalenderdaten zwischen unseren Kunden und deren externen Kontakten. Grundsätzlich sind gewisse Probleme ja Grundrauschen und normalerweise auf individueller Ebene lösbar, jedoch ist an dieser Situation etwas überraschend, dass:
- es mit der neuen Version deutlich schlimmer geworden ist (und auch mit Version 14 anscheinend nicht besser wird)
- das aber irgendwie nicht allen unseren Kunden auffällt. Tauschen diese keine Kalenderinformationen mit externen Kontakten mit anderen Mail Clients aus?
Das Problem
Der Anwender sendet eine ganz normale Einladung an seine externen Kontakte. Diese melden sich und beklagen, dass diese Einladung für sie nicht verarbeitbar sei. Sie wird weder als Einladung angezeigt noch wenigstens eine angehängte Datei mit der Endung .ics, die man per Doppelklick öffnen und annehmen könnte.
Statt dessen zeigt der Body der E-Mail den kompletten Text-Inhalt der Kalender-Einladung im iCal-Format. Das ist für den Empfänger natürlich Kauderwelsch und kann nicht sinnvoll verarbeitet werden.
METHOD:REQUEST
[...]
BEGIN:VEVENT
[...]
END:VEVENT
END:VCALENDAR
Exklusiv mit Microsoft
Nach etlichen Tests mit verschiedenen Empfängern stellt sich heraus, dass das Problem exklusiv bei E-Mail-Empfängern auftritt, die in irgendeiner Form Mail Dienste von Microsoft einsetzen. Sei es mit M365, MS Exchange, Outlook.com, hotmail.
Wenn man sich in den jeweiligen Clients die Mailsource anzuschauen versucht, hat die fragliche Nachricht quasi keinen MIME-Body. Er ist einfach leer. Der Umstand, dass wir auf der einen Seite im normalen User-Interface einen Body angezeigt bekommen, die aufgerufene Source den aber nicht kennt, weist für mich deutlich auf ein Problem hin, das Microsoft mit der Interpretation des MIME-Body hat.
Leider bringt uns diese Ahnung kein Stück weiter.
Der Kalender-Kompatibilitätsmodus als Ursache
Nach weiterem Experimentieren stellt sich heraus, dass das Problem mit dem Kompatibilitätsmodus zusammenhängt.
Der Kalender Kompatibilitätsmodus (cscompatibilitymode) wurde eingeführt, um sicherzustellen, dass auch Empfänger von Notes-Kalendereinladungen mit diesen etwas anfangen können, wenn deren Client iCal anders oder unvollständig interpretiert.
Er kann über einen notes.ini-Parameter gesteuert werden oder über die Clienterkennung in den Mail-Settings per Richtlinie. Bei Aktivierung werden bestimmte Funktionen in der Benutzeroberfäche des Kalendereintrags deaktiviert, die für Probleme sorgen können. Im Regelfall geht es dabei um Funktionen in wiederholenden Terminen.
Wird der Kompatibilitätsmodus deaktiviert, tritt das Problem plötzlich nicht mehr auf. Die Einladung wird korrekt als solche dargestellt.
Aber wieso hat der Inhalt eines Kalendereintrags Einfluss auf die Darstellung bei Microsoft?
Antwort: hat es nicht.
Der relevante Unterschied ist, dass der MIME-Body anders konvertiert wird. Mit eingeschaltetem Kompatibilitätsmodus wird der Kalenderteil als MIME-Type "Related" vom typ "text/calendar" konvertiert. Mit ausgeschaltetem Kompatibilitätsmodus ist der MIME-Part vom Typ "Alternative". Beides ist technisch korrekt und sollte daher eigentlich funktionieren.
Related iCalendar MIME
Wenn also der MIME Content-Type "Related" das Problem zu sein scheint, kann man dann Domino nicht sagen, dass er das nicht verwenden soll?
Da gibt es doch den Parameter
DisallowRelatedIcalendarMime
, mit dem man das offenbar steuern können soll. Tatsächlich jedoch war genau dieser Parameter mit einem anderen Wert als "0" Ursache für weitere Probleme bei einem betroffenen Kunden.
Mit anderen Worten: Finger Weg! Entweder weglassen, wenn es ihn noch nicht gibt oder ihn in Client und Server auf "0" setzen, wenn es ihn gibt.
Also Kompatibilitätsmodus deaktivieren, oder wie?
Ja...ein.
Mit dem Kompatibilitätsmodus kann man diese Probleme umgehen, fängt sich aber leider andere ein.
Wenn man dann nämlich tatsächlich wiederholende Termine plant und dabei Funktionen nutzt, die vom Kompatibilitätsmodus deaktiviert würden, sind die Effekte teilweise unerfreulich.
So haben wir bei mehreren Kunden beobachtet, dass unter bestimmten Bedingungen im Fall einer Aktualisierung des Termins reproduzierbar für jeden Termin einer Serie eine Aktualisierungsnachricht gesendet wird. Das ist ab einer bestimmten Seriendauer nicht mehr ernsthaft zu verarbeiten.
HCL sieht dieses Verhalten anscheinend als Verbesserung an. Immerhin kann man damit eine komplette Terminserie in einem Schritt bearbeiten. Dem zuzustimmen fällt mir und den betroffenen Kunden leider schwer.
So bleibt leider die etwas unbefriedigende Konklusion, dass es keinen vollends zufriedenstellenden Weg gibt, Termine mit Microsoft-Nutzern zu machen. Man sollte sich dabei auf Einzeltermine beschränken. Serien werden schwierig. Da haben sowohl Microsoft als auch HCL Hausaufgaben.
Ich hoffe dennoch, dass mein Blogeintrag dem ein oder anderen Leser zu etwas mehr Verständnis oder gar einem Workaround verholfen hat.