I recently received a question regarding what one should do with the mail files of users who are no longer with the company. This is actually something that I have seen many organizations struggle with.
Do we keep the file? Do we archive it off? What if someone needs access to it – how long should it be retained? Oh, we’ve held on to that one for a few years now but I can’t remember if we still actually need it.
And with that is another related question regarding auto-reply messages as well as possibly forwarding email to another person who is taking over the duties of the former employee.
There really isn’t a silver bullet for handling this. And that’s typically why I have seen this process become a mess in many places. I figured that I would put out my thoughts in a blog post for others to add to and/or critique. 🙂 Like I said, it’s often mishandled and probably even by me. Let us now take a look at the two questions of how to handle the mail routing for the former employee and then how to handle the mail file retention along with some general and design considerations.
One of the primary recommendations that I would have is that whatever policy you adopt should be incorporated into the processes, procedures, and workflow systems. If you’re going to have a somewhat fluid policy where you may only retain mail files if asked, then this should be part of the separation workflow. Click this checkbox if the mailfile needs to be retained and if so, who should have access to it, etc… Consistency and documentation will be key. Also, if you don’t delete the Person Document immediately, make sure that you have added the user to the Deny Access group and change the Internet Password. If you have applications, make sure you have removed the account from any groups used in application ACL’s.
Mail Routing Considerations
There are a few different options here. First, you can just leave the Person Document in place with mail continuing to flow to the mailbox for a time period. In this scenario, some person would be designated as a delegate to monitor that mailbox. That person may or may not wish to forward all mail to themselves. Another option would be to just enable forwarding on the Person Document. Something else to consider is whether or not you want an auto-reply email sent. You may need to implement an agent in the mail file that will respond (or simply use the Out of Office service). These would be the primary things to be concerned with about mail routing, but there are definitely other trails which can spin off of these.
Mail File Retention Considerations
Often it is the case that a corporate or legal retention policy will guide how this is handled. But even if that is the case, I would advise doing some things to make your life as an administrator simpler. Personally, the option I would choose is to ensure that the mailfile has been properly backed up under a backup policy which will retain the mailfile for what the policy mandates. This way you can allow for a period where the mail flow/access could continue from the considerations above, and then you can process the final removal of the mailfile from Domino. If you’re going to do this, make sure that you have de-daosified the mailfile prior to that final backup. Another option is to have a separate mail archive server which can be used to store these old mailfiles. This doesn’t even have to be a separate Domino server – you could use some network-attached storage and move the mailfile to that while still allowing it to be on the same server. This also forces us to keep in mind that if you had an archiving system in place that you may need to also remove those archive files. Furthermore, you may want to have some type of “Separated Users” archiving policy in place that will simply archive all documents to the archive system (whether this be Domino or some other service). But I would advise to not just keep these old mailfiles on the primary mail server(s) indefinitely. Get them onto some cheaper storage if possible and reduce the overhead on your primary mail server(s) that would be used to run maintenance, indexing, etc… on these old mail files. Also, if you have a passive cluster-mate you may wish to just delete the mailfile from the primary server and leave it online on the cluster-mate – perhaps moved to a different directory.
Additional Design Considerations
Just a quick note here that you should probably create a new view in names.nsf which will help you. Update some (hidden) fields on the person document with a separation date and perhaps even some separation comments. Have a view which sorts on this and that you go to on a monthly basis to see if you need to process any final steps. The same may need to be done in admin4.nsf in the Pending Administrator Approval views so that you know whether you can process the mailfile deletion requests. Also, make sure that you are following up on these! Create a monthly calendar reminder to review any separation requests and/or keep them in a Notes Database, spreadsheet, or other system so that you can ensure that you are keeping your systems clean.
Again, there is definitely much to consider. Hopefully some of these options will be helpful as you help craft your own Separated User Mail Retention Policy.