Encrypted mail 1

[malekura1]

Users in the office have access to read and send mail on behalf of each other. There is one mail file where everone receives the error that the mail is encrypted and can only be read by the person it was sent to. They can access the mail file and see the mail in the in box. They have sent an uncrypted mail to this account and receive the same error. I know that this is set up through the delegation profile, does the person named in the profile need manager access to read encrypted mail? is there a setting that has been missed to read the mail?
thanks in advance

 

[geier]

Our users have designer access on their mailfiles and they don't have the problem you describe. When they work on behalf of others in their mailfiles they cannot read any encrypted mail that these persons receive, but they can work with unencrypted mails quite well.

In the mail file where you have the problems you should check first who is the owner of the mailfile. The first one who opens the mailfile after it has been created will be set as the owner. If that entry is wrong you need administrator access to set the value right again. Then you should assign the mail delegations as you have planned them, and it should work correctly from then on. Other possibility: Set the owner in the profile document correctly, then sign on with the ID of the owner of the mailfile and delegate accordingly.

 

[malekura1]

thanks Geier
I do not have admin rights. I have gone through the delegation setting and one of the delgations is for read/send/edit/delete and this person still can not read the mail. The person in question is named in the owners section in the person doc.

 

[geier]

Perhaps I can help you better by giving an example:
let's assume we have two mail accounts: Ernie and Bert. Both Ernie and Bert have Designer Access to their own mail files and they are listed correctly as owner of their mail file in the preferences of their individual mailboxes (field: This mail file belongs to). Now Ernie decides to give Bert access to his mailfile:

1. Ernie logs on and goes into his mailfile.

2. Under 'Preferences' Mail Delegation he gives Bert the right to read/send/edit and delete.

What now happens is that Bert is added to the ACL of Ernies mailfile with the access level Ernie has granted him (which in this case will be Editor). This is done by the Server's administration process which creates a task called 'Delegate Mail File' - if your server is rather busy this might take a few minutes.

And now comes the tricky part: Let's assume Ernie's hierarchical Notes Name in the names.nsf is Ernie/Sesame/US which will be automatically set in the field 'this mail file belongs to' when Ernie signs on for the first time as new Notes User. Ernie can change this value and replace it with some other name from the names.nsf or a completely different one. Once he has done this he can no longer delegate his mail file as he is no longer the owner (the administration process will reject such tasks, but the user who tries to delegate just gets an error in the status bar at the bottom of the screen, where he will never notice it anyway).

So Ernie assumes he has delegated to Bert, but actually the process got killed in between. The only way to give Ernie owner rights to his mailfile again: Someone with Manager rights in the ACL must do this (Probably your Administrator).

Check the ACL of the mailfile in question and see whether the persons who have been granted delegation have the proper access level needed to work with the mails. They still won't be able to read encrypted mail (Bert can't read an encrypted mail that has been sent to Ernie) but they should be able to work with the standard unencrypted mails.

Good luck...

 

[malekura1]

Thakns Geier for you exelant advise, the out come of this problem was; The "encrypt incoming mail" option in the PNAB was set to yes!

 

[apinkerton]

Just to set the record straight on mail encryption...
First of all, the answer that you came up with was correct. I am using Domino 5.08 and Notes 5.08 just to be clear; earlier version of Domino/Notes may function differently. The way the encryption works is based on the private key in the users id file. If a user has been sent encrypted mail or sends encrypted mail than ONLY the sender or recipient will be able to view the mail, delegation has no effect on this. If you the user loses the id file for whatever reason and it cannot be restored and it needs to be re-created, then the encrypted mail will no longer be readable as the private key in the id file will be different.
I do however have to disagree with some of grier's comments. The manager ACL right is given to the creator of the file, not the first person to access it. When using the registration process, the owner of the mail file is automatically set to the user that it is being created for, and the ACL level to the mail file is also set at the time of registration - for security, this should probably be set to designer, but issues may arise that require otherwise.
The mail files' user has to be set as manager for delegation to work immediately, as no other ACL level with allow ACL changes (which is how delegation works). If it it set to something other that manager (designer or editor) the the delegation ACL changes are carried out via the admin process on a schedule). Any users that are added to the ACL through delegation are given the "user type" of "Unspecified". Delegation works as follows: "Read Mail, Calendar and To Do documents" gives the delegatee reader access (read public documents). "Read Mail, Calendar and TO Do documents, and send Mail on my behalf" gives the delegatee Author access with Create documents (this may sound funny to have Create documents as another level on Author, but that is how the ACL works). "Read, send and edit any Mail, Calendar and To Do document" gives Editor access. "Delete Mail, Calendar and To Do documents" gives Author with Create Documents and Delete documents, it also puts the delegatee in the "Read Mail, Calendar and To Do documents, and send Mail on my behalf" group.
Changing the mail file owner with the 'this mail file belongs to' field does not change the ACL at all, as far as i can see it changes the fields that shows who the mail is sent from and does not allow deligation to take place unless you have manager rights to the database, it also only allows the 'owner' or a manager (in the ACL) to change the field.
Assume designer access; if you are the 'owner' of the mail and you change the delegation and then shortly after, change the 'owner', the delegation will go through first as it would be queued for the admin process before the 'owner' change.

 

[malekura1]

more good reading. thanks for all the input.

 

[moose53]

Owner of message needs to send public key to other users.

Encryption is done by using a combination of the public key from the name and address book and the public key of the person who is receiving the email.

Unless you have the public key in your own ID, you will not be able to read the email.