Unencrypting Mail Journal(s)

Has anyone successfully unencrypted files created by Domino Mail Journaling?

We’ve set Mail Journaling up by-the-book (using a mail-in database).

The user whose ID is used to encrypt the databases can successfully open and browse databases (and documents); however, now there is a need to locate specific documents where the sender and/or recipient is unknown, and it seems like create a Full Text Index would be helpful.

Now the fun starts.

Since the documents are encrypted for a specific user, it is not possible to create a Full Text Index for searching anything other than the Sender, Recipient and Subject. The Body field and all attachments are encrypted, and the server cannot read them to index them.

Searched the Forum, and IBM/Lotus Technotes. Found TN 1089495 - How to remove encryption from documents, and TN 1192238 - Mail Journaling Issue with Encrypted Documents.

Both documents describe a way to unencrypt documents, but this process does not work on Mail Journals - First, there is no “Encrypt” or “SecretEncryptionKeys” field(s) on MailJournal docs created from Domino 6.5.5 or 7.0.2. I modified the code to run against the ‘AllDocuments’ view; and found that only the first Attachment found was un-encrypted. The remaining attachments were not only still encrypted, but are now not able to be opened by even the user whose ID encrypted them in the first place.

Found TN 1197314 - Mail documents are encrypted but there is no ‘Encrypt’ field. That technote suggests that “The administrator can try and remove encryption from these documents by following the steps outlined in technote “Removing encryption from all documents in a mail file” (#1110567).”

TN 1110567 - Removing encryption from all documents in your mail file - suggests a different method entirely - using “@Command([ToolsRefreshAllDocs])” to refresh all docs.

However, there are docs that “@Command([ToolsRefreshAllDocs])” cannot refresh, and the process quits.

Found this technote: LO11980: PICTURE IN RTF, GETS CORRUPTED AFTER RUNNING AGENT WITH @COMMAND([TOOLSREFRESHALLDOCS]); - with no plans to fix.

So, I’m tearing what’s left of my hair out - I have a year’s worth of Journals that I cannot search.

Does anyone have any ideas?

Thanks!

Subject: Unencrypting Mail Journal(s)

Hallo Mark,we were facing similar problems with the MailJournal. Finally we made some dirty tricks:

1.we manually created a person document for a user called “Journalist”. This person document does NOT contain a public key.

2.We configured the MailJournal, used this user for “Encrypt on behalf of user” and left

“Field encryption exclusion list” empty

3.We modified the MailJournal-template for our needs

→ It works without any encryption problems

As a side effect you will see entries in the server log complaing the unavailable public key for Journalist

Subject: Unencrypting Mail Journal(s)

Short followup with my progress to date just in case anyone else needs to go down this path…

I’ve found the most expedient way to search the encrypted Journal is to:

  1. Copy the database to a local machine - Sign into the client using the ID file that the journal is encrypted for.

  2. Build the FTI, ensuring that I select ‘Index Encrypted Fields’.

In my case I created an agent to perform the actual search, and it copies the results to another database (using Doc.CopyToDatabase( db ) ) - and since the source docs are encrypted, the results are also encrypted. One might also use this method manually, and just copy/paste the docs to a new database.

At this point, the documents still need to be unencrypted to allow other users to access them - I’ve found that a bug exists in 7.0.2 which causes the problem(s) that I experienced running an agent based on the code in TN 1192238. The bug does not exist in 6.5.5, so a 6.5.5 client (or older?) is required to un-encrypt the documents. I had already upgraded my clinet (and my ‘Admin’ client) to 7.0.2, so I had to set up a new client at 6.5.5 for this task. Worked out for the best, because these are long running tasks.

Note that the actual code listed in TN 1192238 (and TN 1089495) is just plain incorrect for 6.5.x and 7.x - There is NO field entitled ‘Encrypt’ or ‘SecretEncryptionKeys’ so there’s no point creating a view entitled 'Encrypted. I replaced the line: “Set view = db.getview(“Encrypted”)” to an existing view, such as: " Set view = db.getview(“$All”)".

The ‘ToolsRefreshAllDocs’ method listed in TN 1110567 also simply does not work, with apparently no plans to fix the ‘ToolsRefreshAllDocs’ method anytime soon (TN LO11980) - this error also exists in 7.0.2.

So, I’m slowly making progress…

If you’re using standard Lotus ‘Journaling’ as a ‘long-term’ solution for Mail journaling, I might suggest that you test unencrypting databases and/or the steps required to search the databases for use when the need should someday arise. This was always something that I had intended to test; but unfortunately the need arose before I had a chance to test.