Nach meinem Verständnis sollte zum Verschlüsseln nur öffentliche Schlüssel des Empfängers eine Rolle spielen. Dass der Server als Absender keinen öffentlichen Schlüssel hat, sollte doch ohne Belang sein.
Ja und Nein.
Ja: nur der Public Key der Empfänger wird verwendet.
Nein: auch ein Server hat ein Private/Public Schlüsselpaar - wie jede Notes-ID.
Trotzdem spielt der Schlüssel des Servers in diesem Szenario hier keine Rolle, soweit korrekt.
Steht dieser im Serverdokument unter Sicherheit bei "darf beschränkte Agenten ausführen"?
Prinzipiell wäre die Frage berechtigt - wenn es sich nicht um die ausführende Server-ID handeln würde.
Die Server-ID selbst sowie "Lotus Notes Template Development" sind immer zur Ausführung berechtigt.
Im Beitrag
https://atnotes.de/index.php?topic=38949.0
wird außerdem davon gesprochen, dass beim Verschlüsseln auch der public key des Senders im Spiel wäre.
Warum ist der bei Dir nicht eingetragen?
Diese Aussage ist falsch, hier hat der Leser des Redbooks Signatur und Verschlüsselung verwechselt.
Sonst könnte ja jeder die verschlüsselte Mail lesen wenn diese mit einem öffentlichen (!) Schlüssel, egal von wem, so einfach zu entschlüsseln wäre.
Ich habe das dann mal nachgestellt, weil ich zuerst auch dachte, so problematisch kann das doch nicht sein.
Um es auf die absoluten Basics zu reduzieren habe ich als Ausgangspunkt das offizielle HCL Beispiel zur Property
EncryptOnSend verwendet.
Quelle:
https://help.hcltechsw.com/dom_designer/12.0.0/basic/H_EXAMPLES_ENCRYPTONSEND_PROPERTY.htmlGetestet habe ich auf einem Domino 9.0.1FP10 HF747 for Windows/64 und einem Client mit Release 10.0.1FP4 (hatte gerade keinen aktuell gepatchten 9er Client zur Verfügung - aber ich vermute anhand der Google-Ergebnisse dass das eh keinen Unterschied macht).
Weiterhin habe ich alle Tests mit drei Nutzern und zwei Orten (Desktop/Server) durchgeführt:
a) als Benutzer (mit meiner ID)
b) als Server (mit der ID des Servers, der den Agenten auch ausführt)
c) als Spezieller Name (technisch ein beliebiger, auch ein ausgedachter, Notes-Name für den ein Personen- oder Mail-In-Dokument angelegt ist, unabhängig davon ob eine ID oder Schlüssel existieren oder eingetragen wurden)
1. Erkenntnis: das Beispiel-Script funktioniert nicht
Zumindest nicht ohne Änderungen (siehe später) - unabhängig davon, wo und in wessen Kontext es ausgeführt wird
Und nein, natürlich meine ich damit nicht die Änderung von Datenbank- und Empfängernamen.
2. Erkenntnis: Variante (b) verschlüsselter Versand im Namen des ausführenden Servers funktioniert nicht
Es wird kein Bulk-Schlüssel generiert und in der Mail mitgeschickt (Item $Seal fehlt in empfangener Mail).
Das hat NICHTS damit zu tun, dass ein Serverdokument keine Mailadresse hat oder dass es ein Server ist.
3. Erkenntnis: Sobald im Namen einer real im DD existierenden Adresse (Typ a oder c) versendet wird funktioniert es
Bedingung: die "Adresse" muss auch unter "darf restricted Agents ausführen" aufgeführt sein und Zugriffsrechte in der DB und auf dem Server haben, in der der Agent läuft sowie mindestens Depositor in den mail.box(en) sein.
4. Erkenntnis: der Mailer-Demon weiß von sich aus nicht WAS verschlüsselt werden soll
Mit Sender = (a) oder (c) ändert sich das Verhalten. Jetzt wird zwar ein Schlüssel generiert und in der Mail auch mitgeschickt ($Seal) aber es findet keine Verschlüsselung eines Feldes statt ($SealData mit verschlüsseltem Body fehlt).
Erläuterung: in der normalen Memo-Maske hat das Body-Feld mehrere zusätzliche Attribute, die beim Beispiel-Script nicht gesetzt werden.
Damit weiß der Client-Mailer-Demon (der mit der Methode Send ausgelöst wird) nicht welche Items verschlüsselt werden müssen. Lösung: dem Body-Feld muss die Isencrypted=True Property hinzugefügt werden.
Wenn man das alles auf einen Punkt bringt ergibt sich das folgende, absolute Minimum an Script:
Sub Initialize
Dim s As New NotesSession
Dim db As NotesDatabase
Set db = s.CurrentDatabase
Dim memo As New NotesDocument( db )
Dim recipients ( 1 To 2 ) As String
memo.Subject = "Test encrypted Mail"
memo.Body = "Test encrypted memo from " + db.Title
Dim itm As Notesitem
Set itm = memo.Getfirstitem("Body")
itm.Isencrypted = True
memo.EncryptOnSend = True
recipients( 1 ) = "Vorname Name/Meine Organisation"
recipients( 2 ) = "#Meine-Verteiler-Liste"
Call memo.Send( False, recipients )
End Sub
(Fun)Facts anhand der Tests:
- Es ist egal, ob "Name" im OnBehalfOf steht oder nur als Signierer/Ausführender fungiert.
- Es ist egal, ob "Name" ein Servername ist solange er im DD steht und NICHT identisch mit dem ausführenden Server ist (aber nicht empfehlenswert da DEAD-Mails entstehen können und werden).
- Es ist egal ob zu "Name" eine ID (mit einem Schlüsselpaar) existiert oder es nur ein fiktivier Name mit einem Mail-In-Dok ist - Hauptsache der Name steht im DD.
- Es ist egal, ob Empfänger ein Notes-Name, eine Gruppe oder Mail-In ist. Sofern ein Public Key gefunden wurde wird verschlüsselt.
- Sobald ein Schlüssel ($Seal) in der Mail steckt erkennen Traveler/Verse die Mail als verschlüsselt und weigern sich den Inhalt anzuzeigen - unabhängig davon ob der Body überhaupt verschlüsselt wurde.
Insgesamt muss ich gestehen - spannende Geschichte. Ich mache seit langer Zeit viel mit Verschlüsselung und Mail aber bin bisher nie auf die Idee gekommen, Mails als Server zu versenden da damit zwangsläufig DEAD-Mails bei Rückläufern entstehen. Vermutlich bin ich dadurch auch noch nie auf das Problem gestoßen.
Also umstellen auf eine reale Adresse, ggf. eine Mail-In wie "Infomailer/Meine Org" anlegen, und das Problem hat sich erledigt. Und keine DEAD-Mails gibt's als gratis Zugabe dazu
HTH
Carsten
Thema: periodischer Server-Agent und verschlüsselte Mails (Gelesen 4543 mal)