[Kommentierung 1.5.3] A_23737 - Clientmodul - Übermittlung von zusätzlichen Header-Informationen

[CLAM01]

A_23737 - Clientmodul - Übermittlung von zusätzlichen Header-Informationen Das Clientmodul MUSS beim Versand einer Nachricht die folgenden X-KIM Header erzeugen.

X-KIM-ToData Enthält Daten aus dem VZD-Eintrag des Empfängers (MAIL TO). Wenn mehrere professionOID oder specialization Attribute vorhanden sind, werden sie durch "|" getrennt. Format: {,,,}

X-KIM-CcData Enthält die Daten aus dem VZD-Eintrag des Empfängers (MAIL CC). Wenn mehrere professionOID oder specialization Attribute vorhanden sind, werden sie durch "|" getrennt. Format: {,,,}

Frage: Wie soll vorgegangen werden, wenn es in einer KIM-Nachricht mehrere CC oder TO gibt. Sollen dann n Header der gleichen Keynames vorhanden sein? Es wird ja nur beschrieben dass prtofessionOID und specialization durch | getrennt werden müssen.

[gem-cp]

Eine Abstimmung mit dem BfDI erfolgt noch.

[dhufnagel]

Ich hatte es so gelesen, dass in dem Fall mehrerer TO oder CC Adressen, die Header pro Adresse gesetzt werden müssen. Ich halte die komplette AFO jedoch für problematisch, siehe #29

[CLAM01]

Ja, so hat die Afo den Anschein, was ich als problematisch sehe. Das würde aber bei einer Mail an viele TO und CC einen enormen Overhead in den Headern erzeugen. BTW. All diese Daten gehen danach zu lasten des LE, denn er kann dann immer weniger Daten versenden, da die Header Datenplatz belegen wenn es viele werden.

[dhufnagel]

Aus meiner Sicht ist es der falsche Weg, statistische Informationen zu erfassen, da die Komplexität des CmM erhöht wird, welches tausendfach clientseitig installiert wird. Die Daten kann man auch beim erheben der Statistik vom vzd abfragen.

[CLAM01]

Ok, die eigentliche Frage hat sich geklärt, nachdem man unter die Tabelle schaut und da den Satz findet:

...Wenn mehrere Empfänger adressiert wurden, MUSS das jeweilige Header-Element mehrfach angegeben werden.[<=]

[stophane]

Hallo zusammen,

die bereits berechtigten Anmerkgungen von @dhufnagel in #28 & #29 aufgreifend...

Diese Anforderung ist unter verschiedenen Gesichtspunkten massiv problematisch:

• Redundanz und round trip
  • Tausendfach instanziierter Abruf zentraler Informationen, welche wieder an zentrale Services übermittelt werden.
  • Massenhafter und redundanter Transport von Daten, welche bereits im VZD existieren oder ohnehin Teil der MimeMessage-Header sind oder über SMTP-Protokoll transportiert werden.
  • All diese Daten liegen bereits an verschieden Stellen in Ihrer jeweiligen System- und Anwendungsdomäne zentral vor (KIM-Mailserver & VZD)
• Erhöhung der Datenmenge
  • Beachte n…m Beziehung der Inhalte
    • 50 recipients => jeder header mit ggf. mehreren values tritt mehrfach auf
    • im Regelfall wird so die Datenmenge einer Mail ohne Anhang primär durch die dynamischen header-Inhalte bestimmt
• Kein idempotentes Verhalten VZD
  • Der VZD hat aus Sicht von KIM kein idempotentes Verhalten, sodass jederzeit Änderungen der Daten und damit u.a. neue Problemfälle eintreten können.
    • Daten der Header-Element sind u.s. obsolete und ggf. nicht mehr korrekt zuordenbar -> Verwirrung.
  • Fehlerfälle durch syntaktische Veränderungen, welche ohnehin nicht Regeln des RFC für MIME-Header entsprechen, auch wenn semantisch korrekt
  • Potenzielle Probleme für MIME-Header-Abbildung durch ungeeignete Werte der VZD-Values, die nicht Regeln des RFC für MIME-Header entsprechen (vgl. Problem-Kontexte: folding; „\n“; …)
  • Die reine Nutzung von Daten aus dem VZD und die Weiternutzung dieser in RFC-definierten Feldern einer anderen Domäne birgt hohes Problempotenzial (siehe Erfahrungswerte KIM)
    • Es dürfen keine weiteren, nicht speziell für KIM designten Abhängigkeiten zum VZD existieren, da dieser nicht die notwendigen Regeln von u.a. E-Mail/Mime befolgen.
    • Attribute aus dem VZD können plötzlich entfallen (z.B. durch fehlende Indizierung) oder unabhängig von KIM verändert werden, was ggf. in bereits dezentral ausgerollten Clientmodul neue Fehlerfälle/Probleme verursachen kann (umfassende fallback Definitionen notwendig)
• Probleme für Systeme die Header verarbeiten
  • Die Steigerung der Komplexität der Header sowie der Auswertung dieser und den damit verbundenen Datenmengen hat erfahrungsgemäß hohes Problempotenzial in allen Systemen, welche jene Header verarbeiten (CM, FD-Mailserver, …)
• Abbildung in CM ungeeignet
  • Treten Probleme oder Veränderung der Anforderung auf können diese im dezentralen Betrieb der Clientmodule i.d.R. nicht behandelt werden (Updates notwendig -> werden oft nicht durchgeführt)

Tabelle mit Header-Elementen: In der Tabelle wird der Bezug zu MAIL FROM & RCPT TO sowie Cc etc. hergestellt, was nicht geeignet ist. Daten in SMTP-Protokollschritten sind nicht gleich Daten in MIME-Message-Headern. Der E-Mail-Transport an Empfänger wird einzig anhand der SMTP-Protokollschritte RCPT TO, je Empfänger erfolgen. Ein RFC-konformer Mail-Client sendet die Adressinformationen aus MimeMessage-Header To, Cc, Bcc über RCPT TO an Clientmodul und Clientmodul an FD-Mailserver. Folglich spielt für den technisch stattfindenden Transport einer Mail, der eigentliche Mail-Header in KIM keine Rolle (umliegende Afo. Absenderintegrität erfüllt). (Beachte auch Bcc-handling in RFC-konformen Mail-Clients https://www.rfc-editor.org/rfc/rfc2822#section-3.2.6 https://www.rfc-editor.org/rfc/rfc5321#section-7.2 -> Bcc nicht Teil der Mime-Message, jedoch trotzdem per SMTP RCPT TO)

---

[!!!]

Die Anforderung ist zu hinterfragen & neu zu evaluieren (hohes Risiko – Fehlerpotenzial, Redundanz, …)

---

Vorschlag: Zentrale Systeme haben die Möglichkeit VZD-Informationen selbst und bedarfsgerecht zu ermitteln. Dies kann bereits anhand der KIM-Adresse erfolgen.

(1) (ideal) Zentraler gematik reporting service erhält Informationen KIM-Anwnedungsdomäne von KIM FD und reichert diese mit Informationen aus zentralem VZD selbst an (Suchschlüssel KIM-Adresse).

• Vorteile:
  • Eine zentrale Instanz sammelt Daten und verknüpft diese geeignet
  • Es muss nur diese eine zentrale Instanz angepasst werden, zentrale KIM-FD nur dann wenn andere Daten aus Anwendungsdomäne KIM benötigt werden
• Nachteile:
  • Pseudonymisierung muss geklärt werden, wenn zentraler gematik Service mit KIM-Adressen im Klartext arbeiten soll
  • (Fraglich ob überhaupt relevant, da geschlossenes System und VZD in diesem System für alle nutzbar die Klartextdaten bereitstellt + gematik entsprechenden "Schutzpflichten" unterliegt (?!))

(2) Zentraler KIM FD ermittelt die Daten analog (1), bloß entsprechend pseudonymisiert, siehe nachfolgende Punkte. => Auch hier können je FD-Instanz verschiede Probleme, inkonsistente Abbildung analog den o.g. Punkte entstehen. Jedoch sind es in diesem Fall aktuell nur 6 betroffene, zentral steuerbare Services, statt knapp 100k+ Clientmodule im dezentralen Bereich.

Für o.g. Aspekte sind relevante Anforderungen aus der Fachdienstspezifikation zu beachten, u.a.:

• 5.4 Betriebsdatenerfassung
• A_23746 - KIM Fachdienst, Betriebsdatenerfassung Senderichtung
• A_23748 - KIM Fachdienst, Betriebsdatenerfassung Empfangsrichtung

Abschnitt 5.4 Betriebsdatenerfassung aufgreifen Ja, hashing ist ein geeignetes Mittel zu pseudonymisieren. Jedoch sind KIM-Adressen ohnehin öffentlich einsehbar und durch den VZD als lookup table nutzbar. => Zur "sicheren", nicht-rückauflösbaren Abbildung der hashes sollen diese mit einem salt versehen werden. (!) Sofern diese Abbildung/Afo. zum tragen kommt, muss die Länge sowie die randomisierte Abbildung der salts definiert werden. Ist salt nicht "random genung" und oder zu kurz = Rückschlüsse "einfach" möglich.

Viele Grüße