There are viable products on the market that efficiently time stamp
unstructured documents like email, so the hash value of the record can be
traced and validated as the authentic original.  It is not something we sell
or offer, but if anyone would like more information, please give me a call
or drop me a line.


Best regards,


Rick Wolf


347 Mt. Pleasant Avenue
Suite 204
West Orange, NJ 07052
(973) 324-0050 (direct)
(973) 324-0052 (fax)
(201) 602-9486 (cell)
www.lexakos.com




-----Original Message-----
From: Records Management Program [mailto:[log in to unmask]] On Behalf
Of Larry Medina
Sent: Friday, December 05, 2008 10:52 AM
To: [log in to unmask]
Subject: Re: Keeping Email is Native Format - What is the Pro

>  I have a question for all of ya'll.  In some newer electronic document
management systems, there is a capability to capture and move emails over in
their native format and allow them to reside this way until lifecycle is
complete.  In the past, I have been taught that an email should be converted
to pdf or something like that so that the content can be preserved.  Now the
argument seems to be if the email can be moved over, it allows the
attachments to stay attachments, I really do not see this as the best method
of keeping documents because if attachments are of value, they should be
filed as should the email.  However, I ask you all for an opinion - what 
are the pros in keeping email in the native format in an electronic document
management system?  I also was under the impression that there were some
legal stipulations that require an unalterable document, however if metadata
and audit trails are captured is this enough?  Just curious as to what the
list has to say.
>

I always love it when I can start out a response with "It depends..."

This is certainly one of those occasions....the first condition is what are
you trying to accomplish, and the second condition is what are you obligated
to do?   I don't know who regulates LCRA's work product... in fact, if I
recall correctly, depending on what facet of the business you're in, there
may be multiple agencies, some State and some Federal that do.

So, for the Federal records side you have a couple of requirements to
follow. most of which are included in 36CFR 1234.24.  If it's a RECORD, it
MUST be moved from the native application to an ERMS (not an EDMS) and there
are a lot of metadata elements that must be retained, but they don't specify
any format you must use... just that you retain the 'stuff'.  In addition,
there is specific guidance that says an attachment MUST BE RETAINED WITH the
message.  And as you correctly stated, there are numerous reasons this is a
bad RIM practice in general, but whatcanisay, they're the Feds... they don't
generally follow good RIM practices =)

Not sure about the State obligations... there are too many of them for me to
follow, so I usually focus on California, which has some pretty stringent
ones. And they apply not only to businesses that operate IN CA, but to those
doing business with residents of CA as well.

So, benefits of keeping it in native format?  Not a lot that I can think
of... you'd need to have the application to read/use them, and you'd have to
bet on backwards compatibility being provided as an application migrates
forward to view/use the content in the future... or you'd have to have some
way of tagging what version of the application the messages were
created/received in and maintain independent "states of the system" in
perpetuity to access the content throughout its retention period.

Larry

List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
To unsubscribe from this list, click the below link. If not already present,
place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the message.
mailto:[log in to unmask]

List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
To unsubscribe from this list, click the below link. If not already present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the message.
mailto:[log in to unmask]