[Dovecot] data retention and e-discovery rules
Hello All,
I am in the United States where we have e-discovery rules. Some organizations have to retain data for a certain amount of time, others are required to have a data retention policy.
This means that while it should probably be possible for a user to "delete" an email so they do not see it. The server needs to store it, possibly in a tree that mirrors the folder setup of the user (so if it is in "Sales" folder, it should move to namespace "hidden", or similar, in folder "Sales").
Is there anything like this in dovecot? Is it possible to use cron jobs to see when the message was deleted (Maildir) and erase it based on policy? (Python scripts are fine if the users password isn't needed.)
Thank you, Trever Adams
Hi Trever
On 02/12/2008, Trever L. Adams trever.adams@gmail.com wrote:
Hello All,
I am in the United States where we have e-discovery rules. Some organizations have to retain data for a certain amount of time, others are required to have a data retention policy. ... Is there anything like this in dovecot? Is it possible to use cron jobs to see when the message was deleted (Maildir) and erase it based on policy? (Python scripts are fine if the users password isn't needed.)
Thank you, Trever Adams
Cyrus, I know for a fact, supports data retention policies, but I guess you'd just need to be imaginative when it comes to using Dovecot. I personally have all mail blindly bcc'd to a mailbox to which only I have access, but I'm doing that before delivery (using postfix's always_bcc) instead of at the dovecot/mail delivery end. It seems to work fine.
Otherwise, what you could look at doing is setting up the cron job, as you say, to mirror any files that have appeared in the mailbox.
Just my 2c
Best regards, Ronald.
-- Ronald MacDonald http://www.rmacd.com/ 0777 235 1655
On Tue, 2008-12-02 at 10:02 -0700, Trever L. Adams wrote:
Hello All,
I am in the United States where we have e-discovery rules. Some organizations have to retain data for a certain amount of time, others are required to have a data retention policy.
This means that while it should probably be possible for a user to "delete" an email so they do not see it. The server needs to store it, possibly in a tree that mirrors the folder setup of the user (so if it is in "Sales" folder, it should move to namespace "hidden", or similar, in folder "Sales").
Is there anything like this in dovecot? Is it possible to use cron jobs to see when the message was deleted (Maildir) and erase it based on policy? (Python scripts are fine if the users password isn't needed.)
One possibility is http://wiki.dovecot.org/Plugins/Lazyexpunge
Timo Sirainen wrote:
One possibility is http://wiki.dovecot.org/Plugins/Lazyexpunge
This is exactly what I am looking for, except two things:
The cron job shown on that URL seems to not work off of the date the message was deleted. Am I correct?
The URL mentions that it should be possible to keep the user from accessing the namespaces, is this under the namespace configuration?
Thank you, Trever Adams
On Dec 2, 2008, at 7:47 PM, Trever L. Adams wrote:
Timo Sirainen wrote:
One possibility is http://wiki.dovecot.org/Plugins/Lazyexpunge
This is exactly what I am looking for, except two things:
The cron job shown on that URL seems to not work off of the date the
message was deleted. Am I correct?
It uses -cmin, meaning the message's ctime. It's usually the delete
time (ctime gets updated by rename()) but it could also be later if
the same message had been copied to another mailbox and it was changed
there (expunged, copied, flag changed, etc).
You could also use expire plugin which actually uses the delete time.
The URL mentions that it should be possible to keep the user from
accessing the namespaces, is this under the namespace configuration?
Well, there's currently no way to prevent user from accessing them,
but security through obscurity works well here :) Just use a namespace
prefix that's not easily guessable and set list=no hidden=yes.
participants (3)
-
Ronald MacDonald
-
Timo Sirainen
-
Trever L. Adams