Mail-IN-DB verschlüsselte Email / Kalender

[maxritti]

Hallo zusammen,

wir haben eine Menge an normalen Mail-IN DBen.
Also Datenbanken, welche das Mailtemplate als Schablone haben, dazu ein Mail-IN-Dokument und über eine Gruppe werden die Zugriffe gesteuert.
Nun sind die Benutzer auf die Idee gekommen Mails und Kalendereinträge zu verschlüsseln.

Bei Emails klappt das auch. Eine Email erstellt, die Mail wird verschlüsselt und versendet.
Lesbar dann nur von den Benutzern, die auch als Empfänger drin standen. Also eine Vertretung eine Benutzers, der die verschlüsselte Email erhalten hat, kann die Mail nicht lesen.

Das ganze scheint bei Kalendereinträgen nicht zu klappen.
Eine Besprechung geplant, die Option "Verschlüsseln" aktiviert und nach dem versenden kommt die Meldung, dass es für den Benutzer, welcher als Owner der Mail-IN-DB angegeben ist (der Name des Mail-In-Dokuments in hierarchischer Form, also "Mail-In-Name/Org") kein öffentlicher Schlüssel verfügbar ist.
Stimmt ja auch, da es ja kein "ordentlicher "Notesuser" ist.

Ist das nur Zufall, dass es bei den Emails funktioniert?
Müssen wir nun aus den Mail-In-Dokumente richtige Benutzer machen?

Danke schön für Eure Tips.

[CarstenH]

Du kannst, analog zu den Personendokumenten, den Schlüssel EINES Nutzers im Mail-In-Dokument eintragen.
Anschließend kann NUR dieser EINE Nutzer die Mails dort noch lesen. Verhält sich dann genau so wie eine persönliche Mail-DB.

Was auch immer der Sinn dahinter sein soll - technisch kein Problem.

Es würde sich übrigens nichts daran ändern wenn ihr Personendokumente verwendet - außer dass dann Lizenzen fällig werden wenn noch jemand Credentials dafür hinterlegt.

Carsten

[maxritti]

Hi Carsten,

vielen Dank für Deine Info.
Ich glaube, dass Du doch eine Lösung hast mitteilen können. 

Man muß ja zwei Wege der verschlüsselten Email betrachten:


1. Verschlüsselte Email geht an die Mail-IN-DB:

Das ist der Fall, den Du meinst. So hoffe ich es verstanden zu haben. 
Sofern ein Benutzer eine Mail verschlüsselt und an die Mail-IN-Db senden möchte, geht dies nicht, da in dem Mail-IN-Dokument kein öffentlicher Schlüssel existiert.
Ist dort einer eingetragen, dann kann nur der Benutzer, dessen öffentlicher Schlüssel das ist, die Mail in der Mail-IN-DB lesen.


Das ist momentan aber nicht unser Thema, sondern dieser Fall:


2. Eine Email/Kalendereintrag soll ausgehend von der Mail-IN-DB versendet/erstellt und verschlüselt werden.

Da bekommt der Benutzer momentan die Fehlermeldung, dass für die Mail-IN-DB kein öffentlicher Schlüssel gefunden werden kann.
Ist auch korrekt, da in dem Mail-IN-Dokument kein Schlüssel existiert.

Ich habe nun mal wie Du beschrieben hast, einen öffentlichen Schlüssel von einem registrierten Notestestuser in das Mail-IN-DB Dokument gespeichert.
Nun kann ich in der Mail-IN-DB schon mal einen Kalendereintrag erstellen, diesen verschlüsseln und die Fehlermeldung des fehlenden Schlüssels kommt nicht mehr.
Und das beste ist, die Einladungsmail für den Kalendereintrag der Mail-IN-DB kann auch nur von den Empfängern gelesen werden.


Somit denke ich, dass die Fehlermeldung welche erscheint, wenn kein öffentlicher Schlüssel in dem Mail-IN-Dokument ist, ein Bug ist.

Denn die Mail an sich wird ja mit den öffentlichen Schlüssel(n) der Empfänger verschlüsselt.
Und mit den privaten Schlüsseln der Empfänger entschlüsselt.


Zumindest hat mein Test das so ergeben. Hoffe nur, dass damit keine anderen Probleme auf uns zurollen. 

[CarstenH]

Jupp, du hast meinen Post richtig verstanden (1).

Allerdings hatte ICH aus deinem Ursprungspost nicht herausgelesen, dass es um Mails/Einladungen AUS der Mail-In-DB geht.

Dass es beim Versand eine (scheinbar) unnötige Fehlermeldung gibt ist kein Bug sondern eine Vorsichtsmaßnahme/ein Warnhinweis da Antworten der Eingeladenen an den Leiter (also die Mail-In) ohne öffentlichen Schlüssel selbiger unverschlüsselt wären. Es kommt beim Eingeladenen übrigens nochmal eine zusätzliche Warnung in dem Fall wenn er annehmen/ablehnen/etc will.

Noch ein ergänzender Vorschlag: statt den öffentlichen Schlüssel irgendeiner Person zu verwenden würde ich eine separate Funktions-ID für solche Fälle rechnen und deren PubKey verwenden.

Carsten

[maxritti]

Danke Dir Carsten für die wie immer hilfreichen Antworten.

Im Zuge des ganzen Tests habe ich in der Tat vergessen zu schreiben, wo das eigentlich Problem liegt. Also Mails raussenden.

Auf jeden Fall habe ich jetzt mal einen Status den ich so weitergeben kann.
Mal schauen was daraus wird.

Deinen ergänzenden Vorschlag hatte ich auch im Kopf, im Test aber erst mal den Test genommen.

Gruß

Jörg

[ronka]

darf ich nochmal nachfragen ?

Für den verschlüsselte mail, geht der NUR an den Mail-in datenbank, oder auch an andere personen ?

[maxritti]

Deine Frage verstehe ich nicht wirklich. Sorry.

Es geht ja so, dass ein Benutzer eine Mail verschlüsselt an die Mail-IN-DB und andere Personen schicken möchte.
Dann wird die Mail für jeden Benutzer mit dessen öffentlichen Schlüssel verschlüsselt und die Person selber kann die Mail mit seinem privaten Schlüssen entschlüsseln und lesen.
Das klappt bei einer Mail-IN-DB ja nicht. Denn da gibt es keine dedizierte Notes ID für, mit der zugegriffen wird.
Sondern die Benutzer greifen mit ihrer Notes ID auf die Mail-IN-DB zu und können die Mail daher nicht entschlüsseln und nicht lesen.

Der Weg aus der Mail-IN-DB an mehrere Benutzer läuft ja so, dass auch diese Email mit den öffentlichen Schlüssen der Empfänger verschlüsselt wird und jeder einzelne Benutzer entschlüsselt diese mit dem privaten Schlüssel.

[CarstenH]

Ein Problem könnte es dennoch geben:

Das Szenario funktioniert nur wenn immer die gleiche Person die Mail-In-DB verwaltet und daraus sendet. Nur dann steckt in den Einladungen auch der zum Entschlüsseln notwendige Key für alle Beteiligten.

Sobald aber mehrere Personen die DB verwalten wird's schwierig. Dann kann jeder Verwalter nur seine selbst erstellten Einladungen lesen und bearbeiten. Vertretung ist nicht möglich.

Lösungen wären auszutesten z.B. Automatische Weiterleitung (mein Favorit hierfür; zu finden unter Vorgaben > Zugriff > Verwaltername > Automatische Weiterleitung), oder Vertreter immer in CC, Tricksen mit Gruppe die alle Verwalter + Mail-In enthält oder andere Varianten, die mir spontan gerade nicht einfallen.

Carsten