[Kommentierung 1.5.3] AccountLimit.kasMailSizeThreshhold

[stophane]

Es fehlt ggf. notwendige Spezifikation bzgl. des neuen AccountLimits-Parameter „kasMailSizeThreshold“.

Siehe ursprüngliche PR: #22

=> Entsprechend muss der Umgang mit diesem Parameter definiert:

• Was impliziert der Parameter?
• Wie ist der Parameter zu verwenden?
• Was passiert, wenn nicht oder invalid gesetzt?
  ...

[gem-cp]

AccountLimits-Parameter [„kasMailSizeThreshold“] wird wie vorgeschlagen ergänzt.

Vorausgesetzt alle Empfänger der Nachricht können 1.5.x, dann wäre es sinnvoll alle Mails über den KAS zu versenden. Wenn ein Empfänger KIM 1.0 hat, dann bekommen alle Empfänger die Mail als KIM 1.0 Nachricht.

Die Einstellung des Parameters sollte durch den Fachdienst erfolgen (aus unserer Sicht sinnvoll, um dem Nutzer nicht zusätzliche Entscheidungen zu überlassen).
Welcher Minimalwert soll möglich sein? Vorschlag: 0Byte
Zu "dataTimeToLive" auf dem KAS: Wenn alle KIM-Nachrichten über den KAS transportiert werden, dann kann der Nutzer nur über "dataTimeToLive" die Dauer der Speicherung steuern. Das kann dazu führen, dass sein Account mehr Daten speichert als notwendig wäre. Daher muss der Fachdienst Betreiber einen sinnvollen Wert für "kasMailSizeThreshold" wählen.

Zur Frage "Was passiert, wenn nicht oder invalid gesetzt?": Der Fachdienst sollte aus unserer Sicht immer einen korrekten Default Wert vorgeben und falsche Eingaben (außerhalb min/max) ablehnen, sodass der Fall "nicht gesetzt oder invalid" nicht eintreten kann. Wenn der Fachdienst diesen Wert vorgibt wäre eine Regelung im CM nicht erforderlich.

[stophane]

Achtung:
Es gilt Kontext KIM 1.5+ bzw. zukünftig dem "+" zu beachten.
Das "+" sagt aus, dass ein Empfänger große Nachrichten > 15 - 700 MiB verarbeiten kann.

Mit Einführung von „kasMailSizeThreshold“ und dem Heruntersetzen dieser Schwelle, folgt automatsich, dass die Empfänger Ihre KIM-Version mit "+" versehen haben müssen, da ein KIM Clientmodul sonst beim Nachrichtenabruf einen Fehlerfall produziert (siehe A_23512 - Auswertung der KOM-LE-Version bei Nachrichten mit KAS-Content). Denn mit „kasMailSizeThreshold“ würden auch dann KAS-Nachrichten versendet werden, welche < 15 MiB sind, sodass potenziell ohne "+" keine Nachrichten versendet oder empfangen werden können.
Dies steht auch im direkten Konflikt zur eigentlichen Nutzung des "+" - Verhinderung, dass "über"-große Datenmenge unkontrolliert in das Empfängersystem gelangen.

Vorschlag:
Ohne Einführung einer technisch verlässlichen Informationsquelle, welche die tatsächliche Datenmenge, die durch "getAttachment" in das System gelangt, bereitstellt, darf diese Änderung nicht, oder nicht mit zu "kleinem" Minimal-Wert eingeführt werden.

Als sinnvolle und nicht "never trust the client"-problem-behaftete Quelle der Information zur Datenmenge, welche durch getAttachment abgerufen wird, kann HTTP HEAD bzgl. getAttachment genutzt werden.
Das setzt jedoch voraus, dass für getAttachment entsprechende Definition für das Interface geschaffen wird und alle KAS dies unterstützen.

[kurtkoe]

Die Argumentation mit A_23512 würde ich grundsätzlich unterstützen, hierzu gibt es aber in der aktuellen gemSpec_CM_KOMLE_V1.16.0 einen spannenden Hinweis im nicht normativen Teil:

Wäre spannend zu wissen, welche Hersteller das tatsächlich so umgesetzt haben.

[stophane]

Die Argumentation mit A_23512 würde ich grundsätzlich unterstützen, hierzu gibt es aber in der aktuellen gemSpec_CM_KOMLE_V1.16.0 einen spannenden Hinweis im nicht normativen Teil:

Wäre spannend zu wissen, welche Hersteller das tatsächlich so umgesetzt haben.

Dieser Hinweis ist bekannt, auch dass "size" in der KIM-AttachmentDatenStruktur eine entsprechende Wertangabe liefert.

Jedoch gilt hier "never trust the client", da diese Angaben durch den versendenden Client gesetzt werden und fälschlicher-/boshafterweise von der tatsächlichen, technischen Datenmenge abweichen können.

Dabei dient die Einführung des "+" genau dazu, zu verhindern, dass große Datenmenge unkontrolliert in Systeme gelangen, die potenziell damit nicht umgehen können. Demzufolge der o.s. Konmentar.

X-KIM-KAS-Size wurde nicht primär für diesen Fall eingeführt, sondern bspw. für dispatching Mechanismen im Kontext POP3 TOP, um vor dem eigentlichen Nachrichtenabruf "grob" zu erkennen, ob bestimmte Nachrichten bspw. außerhalb von Spitzenlasten abgerufen werden sollten.

Viele Grüße