The latest edition of DominoPower Magazine has an informative interview with Marie Patterson concerning her company's email archiving and retention solution.

At the C-level, the real issue is again the lack of policies, as we're seeing in much-publicized cases like Morgan Stanley. Executives are concerned about anything that will affect shareholder value. As it relates to email, the issues are all risk related, so growing and unbudgeted e-discovery costs definitely affect the bottom line. Litigation that has to go to settlement because organizations are incapable of finding specific records affect the bottom line. High-profile litigation that ends up on the front page of the Wall Street Journal makes the organization look either incompetent or fraudulent. That affects the corporate image which, again, affects shareholder value.

I will bang the drum on this as long as it takes for people to wake up to reality.  If you do not have an email archiving and retention policy and solution already in place, you had better get your butt in gear before you and your CIO loses your job when the fines start rolling in for failure to produce emails that were subpoenaed.  The one line in the interview that really scared me was that Morgan Stanley was found to have actively conspired to defraud its former client.  Not exactly the kind of PR that any company wants.

If there is anyone out there who isn't looking at email archiving, this should definitely get their attention

Morgan Stanley has agreed to pay a record $15 million fine to settle a Securities and Exchange Commission (SEC) probe into its failure to preserve e-mails, according to a 10-K filing with the SEC this week. Reports indicate this is the highest fine ever imposed by the SEC for such behavior

At my previous employer, we were evaluating archiving solutions for this very reason.  They were/are invloved with a large number of law suits due to the industry they work in and really didn't have a viable solution for retrieving past emails.  I am not sure where they stand as of today, but hopefully, for their sake, they have made a decision and are implementing it shortly.

It is issues like this that are the Achilles heel of the hosted email solutions that SMBs are looking into.  Hotmail/GMail/Yahoo Mail do not have the capacity to handle archiving and email life cycle management that is required to be in compliance with the laws that are being enacted.  If you can find the emails, I can only imagine the cost to get them exported to an electronic format for Discovery purposes.  If you can't find it, what are the alternatives?  Hope that it exists on some backup at the host site?  Good Luck!!!  Try arguing that in front of a judge and see how soon your bottom line drops into the red.  And how about getting your users to kill email after it has reached the end of its lifecycle.  Is it worse to not be able to deliver an email that is requested or to deliver one that might be damaging that should have been deleted a year ago?  I am sure that Chris will have something to say on this.

Simon Phipps, Sun Microsystems Inc.'s chief officer of open source, said Sun's Internet Mail Server is more advanced than Exchange and is the mail server of choice for many large enterprises. "Numerically, we service more e-mail accounts than they do," he said.

Tim Bray, a Sun Web technologist and the co-inventor of XML, told eWEEK that while some of Microsoft's software was excellent, "I cannot say that Exchange falls into that category," whether from a technical engineering or feature-set perspective.

"We haven't seen it bubble up as a priority for most organizations to date. I believe that the time for unified messaging will come when VOIP [voice over IP] is more broadly deployed behind the firewall," she said.

But Scalix's Farris disagreed with that, saying that the underlying architecture of Exchange suffers from more than its fair share of reliability and security problems, the fundamental causes of which have not been addressed in Exchange 12.

via Ed Brill

I know that indexing is the biggest drain on any Domino server's performance and reducing a mail file's size by stubbing off attachments won't make those indexes any smaller or faster. In fact, I can't believe that there isn't some performance hit that users feel with they are in a SCOS scenario. Maybe MS' insistence on using SCOS is one of the reasons that they have not implemented their own Full-Text Search Engine for Exchange. I can't remember if cc:Mail had full text indexing, but I am pretty sure it didn't. I am sure that if Richard reads this he will set me straight. In any event, to put it bluntly, it's not the size of the file that matters, it's the number of emails that are in it.

In our next test, we started up 2000 users over a period of 80 minutes, followed by a steady-state period of 90 minutes. In one test, documents were left in the Inbox, while in the second test, we limited the number of documents in the Inbox to 25 percent of the total document count in the mail file. We then compared the CPU usage of both groups over time (see figure 2).

We found that when Inboxes were limited to only 25 percent of total document count, peak CPU usage was 50 percent lower, and steady-state CPU was 12 percent lower, compared to allowing all new documents to remain in the Inbox.

via Ed Brill

A request that recently came to me was to put a reminder for an upcoming IT outage on the calendar for a specific list of users. To me, this seemed like a natural extension of the Company Communications Database. The form I used for setting up the reminder was just a modified mass email form that was already built. All the user has to do is select who gets the reminder, select when the reminder should go off, and enter the subject and body of the reminder. Below is the subroutine that actually puts the reminders on the user's calendar:

Sub SendReminder(person As NotesDocument, doc As NotesDocument)
  Dim mailfile As NotesDatabase
  Dim collection As NotesDocumentCollection
  Dim reminder As NotesDocument
  Dim item As NotesItem
  Dim body As NotesRichTextItem
  Dim oldbody As NotesRichTextItem
  Dim datetime As NotesDateTime
  
  Set mailfile = New NotesDatabase(person.MailServer(0),person.MailFile(0))
  If Not(mailfile.IsOpen) Then Exit Sub
  
  Set datetime = New NotesDateTime(doc.GetItemValue("calendardatetime")(0))
  Set collection = mailfile.Search(|Form = "Appointment" & ApptUNID = "| & doc.UniversalID & |"|,Nothing,0)
  
  If collection.Count = 0 Then
    Set reminder = mailfile.CreateDocument()
    reminder.Form = "Appointment"
    Set item = reminder.ReplaceItemValue("$Alarm",1)
    Set item = reminder.ReplaceItemValue("$AlarmOffset",0)
  '  Set item = reminder.ReplaceItemValue("$NoPurge",doc.GetItemValue("calendardatetime"))
    Set item = reminder.ReplaceItemValue("$PublicAccess","1")
    Set item = reminder.ReplaceItemValue("$CSVersion","2")
    Set item = reminder.ReplaceItemValue("_ViewIcon",10)
    Set item = reminder.ReplaceItemValue("Alarms","1")
    Set item = reminder.ReplaceItemValue("AppointmentType","4")
    Set item = reminder.ReplaceItemValue("ApptUNID",doc.UniversalID)
    Set item = reminder.ReplaceItemValue("Categories","Company Reminders")
    Set item = reminder.ReplaceItemValue("Chair","CN=Generic ID/O=Company")
    Set item = reminder.ReplaceItemValue("ExcludeFromView","D")
    Call item.AppendToTextList("S")
    Set item = reminder.ReplaceItemValue("OrgTable","C0")
    Set item = reminder.ReplaceItemValue("Principal","CN=Clark Construction/O=Clark")
    Set item = reminder.ReplaceItemValue("SequenceNum",1)
    Set item = reminder.ReplaceItemValue("UpdateSeq",1)
    Set item = reminder.ReplaceItemValue("WebDateTimeInit","1")
  Else
    Set reminder = collection.GetFirstDocument
    Set item = reminder.ReplaceItemValue("SequenceNum",reminder.SequenceNum(0) + 1)
    Set item = reminder.ReplaceItemValue("UpdateSeq",reminder.UpdateSeq(0) + 1)
    Call reminder.RemoveItem("Body")
  End If
  Set item = reminder.ReplaceItemValue("CalendarDateTime",doc.GetItemValue("calendardatetime")(0))
  Set item = reminder.ReplaceItemValue("EndDate",Datevalue(datetime.DateOnly))
  Set item = reminder.ReplaceItemValue("EndDateTime",doc.GetItemValue("calendardatetime")(0))
  Set item = reminder.ReplaceItemValue("EndTime",Timevalue(datetime.TimeOnly))
  Set item = reminder.ReplaceItemValue("StartDate",Datevalue(datetime.DateOnly))
  Set item = reminder.ReplaceItemValue("StartDateTime",doc.GetItemValue("calendardatetime")(0))
  Set item = reminder.ReplaceItemValue("StartTime",Timevalue(datetime.TimeOnly))
  Set item = reminder.ReplaceItemValue("Subject",doc.subject(0))
  Set oldbody = doc.GetFirstItem("Body")
  Set body = reminder.CreateRichTextItem("Body")
  Call body.AppendRTItem(oldbody)
  
  Call reminder.ComputeWithForm(True,False)
  Call reminder.Save(True,False,True)
End Sub

A couple of things that you should notice about the subroutine. First, a couple of NotesDocument objects are passed in, one pointing to the user's person document in the address book and the other pointing to the reminder document. Second, the agent is built to be able to update reminders that have already been created. The ApptUNID field will contain the UniversalID of the reminder document so that if the reminder document gets updated, the reminder on the user's calendar will also be updated, not duplicated. Finally, I only set the static calendar fields when the document is created. I think that I got all the required fields, but I might have missed one. Please drop me a line if you think I did.

As a developer, I think about Notes/Domino security every day, but rarely worry about it. I know it's there and I know how to implement it, but encryption is a different story. I have only developed a handful of applications that have every used private key encrypted fields and always have to refer back to the documentation when doing it. There are very few types of applications that truly need this level of security and, therefore, it is not something that I am that familiar with. From the administrative standpoint, I am very familiar with forcing encryption on local database replicas via profile settings. The part of encryption that has come to the fore front recently is the ability to encrypt emails on send and how we would get around that encryption as a part of litigation discovery.

So, my question to every one out there is do you allow users to send encrypted emails and how do you plan on retrieving those emails without the user's consent or if the user leaves?

• ZipLip
• iLumin
• OpenText
• FileNet
• EMC/Legato
• Symmantec/Veritas
• Zantaz

If there is a viable solution out there that we are not looking at, please let me know.

Update: per suggestions in the comments, I have added Waterford Technologies and IBM to my list of vendors.

In case you are unaware of how native Notes mail encryption works, here is an excerpt from the Domino 6 Administration Help Database:

How outgoing Notes mail encryption works

1. The sender sends an outgoing message and selects the Encrypt option.
2. Notes generates a random encryption key and encrypts the message with it.
3. Notes encrypts the random encryption key with the recipient's public key and appends the new key to the message. The recipient's public key must be stored in either a Domino Directory or LDAP directory that a user can access or in the sender's Personal Address Book.
4. If the encrypted message is addressed to multiple recipients, the message is encrypted only once with one random key, and the random key is encrypted using the public key of each recipient.
5. When the recipient attempts to open the encrypted message, the user's mail application attempts to decrypt the random key, using the recipient's private key. If this is successful, the random key decrypts the message.
6. If decryption is successful, the recipient can read the message. If decryption is unsuccessful, the user receives a message indicating that the decryption failed and the mail application does not allow the user to access the message.

A message that Notes has previously encrypted for its recipients is not re-encrypted with the certified public key of the specified Journal user. As a result, when depositing encrypted messages in the Mail Journaling database, Domino preserves the original encryption, so that the message content cannot be decrypted with the ID of the designated Mail Journaling user, unless, of course, that user was included in the original recipient list. A Mail Journaling user who was not on the recipient list can view header information only.