Hi Larry and everyone else, 

My responses inline below. 

.pst files are  copies of e-mail messages (sort of) that are stored in a
personal folder locally, right?

JW: Depends on how the server is set up - they could be the actual original
messages (e.g. nothing remaining on the server). But essentially yes. 

So what is missing from them that is in the original message... do you
retain all of the original transmission data and recipient records and the
header information, or is it/are they altered in some manner at all?  Is a
new date or other data appended to them or is any of the "blah, blah, blah"
removed??

JW: Microsoft indicates that they are the exact message as from the server,
with potentially even MORE information such as local folder, status of
read/unread, flag status, and a few others. 

We've spent a couple of days discussing the manner in which e-mails are
managed and used when they meet the definition of a record, but does a PST
copy/version of an M$ message represent 100% accurately the original message
as sent or received??

JW: A .pst copy is the accurate original message; in fact, .pst is one of
the preferred mechanisms for providing messages to
internal/external/opposing counsel because it faithfully captures the
message content and its context. It is also used to aggregate messages
across inboxes and deliver them to an authorized third party. 

Everything I've seen on pst files so far discusses how to fix them, what the
problems are with them, 3rd party products to work with them, limited files
sizes to store them, compression and expansion of them, etc... none of this
sounds as though they're a positive manner to manage e-mail that rises to
the level of a record, especially if it's a long-term record.   AND, it's a
proprietary format...

JW: True, true, and true. They are NOT considered a best practice for
message storage for any period of time. Older versions have a 2GB limit and
then they corrupt pretty efficiently(!); newer ones have a 20GB limit but
are not 100% backwards compatible. They are inefficient to store because
they store two copies of each message, one in .msg and one in .eml. Any
message sent to more than one user is stored as a single copy in the email
server, but if users are allowed .pst files, that message is stored locally
for each user meaning that a single message with a single 1 MB attachment
sent to 1000 people will take up 1 GB of storage. They are often stored
locally which means they are NOT backed up. They don't allow for shared
access to the messages therein because the .pst files are single threaded
access. They are incredibly easy to get out of the organization on a $25 4
GB flash drive, thereby completely bypassing any RM or IT restrictions. And
they have a few other issues as well. Other than that they are great. :)

So for my money, I agree with the approach someone mentioned earlier: forbid
them except under specific defined circumstances such as discovery or for
employees who go on the road and need access (and don't have e.g. Outlook
Web Access). If you *do* allow them, at least require that they be stored on
a network shared drive someplace so they can be backed up. If you have them
and want to get rid of them, there are solutions available that will spider
the network, locate all the .pst files, suck all the email and context out
of them, de-duplicate the messages if they are identical (e.g. same
message-id/GUID) and put them in a repository/archive/ECMS/ERMS. 

That said, let me be clear that I'm talking about .pst files, not the
messages within them. Fundamentally a .msg file is an .eml file (the
standard per RFC 2821 and 2822) plus any additional information including
but not limited to what Microsoft adds such as formatting and any MIME
content such as attachments or embedded stuff. A .pst file is simply a
Microsoft proprietary container file, almost a database, that contains the
.msg files. .msg files are a fine (albeit somewhat proprietary) format to
store all but the most long-term or permanent records. .eml would be better
because it's a standard (RFCs don't quite have the force of standards but
every email client on the planet writes RFC 2821/2 compatible .eml files)
but as .msg is native format it is at least defensible over the short- to
medium-term. 

Did I mention I teach a four-day workshop on email management? :)

Regards, 

Jesse Wilkins
[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]