I agree and understand the records management principles outlined in
these discussions previously. We have been looking towards acheiving a
position whereby we can file emails alongside other relevant information
to maximise the benefit and investment in our existing EDRM system for
the purposes of multiple access, sharing, storage etc. etc. 

This has flagged the difficulty of acheiving something that works from
a records management perspective but also meets the needs of the
business and the constraints of existing systems and process. I have
taken many learnings from this debate and will certainly continue to
keep an eye on this.

I hope this area continues to be debated here and beyond but I too like
Steve would be interested in more about renditions as an option.

>>> Steve Norris <[log in to unmask]> 06/02/07 10:10:09
>>>
Re: Converting emails into documentsHi Susan,

Thanks for showing this to your colleague, her comments further clarify
this
complicated issue.

Metadata is always a problem, just what is required and what isn't ?
Keeping
all metadata is possible but is it necessary ? Would it be possible for
the
metadata required for e-mails to be defined/agreed (by say MoReq or
TNA) ?
As Chris points out we don't keep the envelope a letter arrives in. 
(At the
moment I favour the belt and braces approach of keeping all metadata).

The point about a trail of email correspondence is well made; as your
colleague points out you can only use the last email as the record if
it
includes the entire chain of discussion, otherwise you need to declare
all
the e-mails individually.

I agree with Phillip's comments regarding  "When email records are
saved as
"msg" files ... they lose part of their context". A .msg file keeps all
the
data (metadata, content, attachments etc.) that was in the e-mail. It
can't
be searched using Outlook but other software can view or search it,
including (hopefully) any Records Management system it is saved into.

The statement  "By declaring emails as records from within the email
client,
the integrity of the record is intact." is crucial. At this point we
have
the full metadata, content etc. available and can declare the record
(into a
records management package) . A much better approach than trying to
invent
workarounds.

I was also interested in the comment "The creation of renditions may be
an
option, as this would not alter the original record content or
metadata.".
Does your colleague mean you could render an email (to say a PDF
format) and
this would be acceptable as the record ?

Regards,
Steve Norris
http://www.alliancegroup.co.uk 



 -----Original Message-----
From: The UK Records Management mailing list
[mailto:[log in to unmask]]On Behalf Of Healy, Susan
Sent: 05 February 2007 13:52
To: [log in to unmask] 
Subject: Converting emails into documents


  I've been showing a colleague emails in this interesting thread and
she
has provided the following response:



  "Emails consist of content (e.g. plain text and / or attachments)
and
transmission metadata (e.g. To, From, Subject, and associated
datestamps).
The transmission metadata is as much a part of the email as the
content, and
if an email is to be declared as a business record, the original
transmission metadata must be captured along with the content. The
transmission metadata provides context for the email record, and can be
used
to support the integrity of the record. If the record does not include
the
original transmission metadata, the record is incomplete.



  Some emails may be sent back and forth, building up a trail of email
correspondence over time. Where the entire chain of discussion is
included
in a single email, it can be declared as a single record, with all of
the
necessary transmission metadata captured direct from the email client.
However, where the correspondence is less connected, involving
different
email chains, the only way to ensure the integrity of each email is to
declare them separately, with the option to add relational links added
as
appropriate.



  Where users wish to view a block of content from separate emails
covering
the same topic, consideration must be given to both the metadata and
the
content. While there are times when it would be clearly beneficial to
view
the combined content of different emails, any attempt to do so must not
be
at the expense of record integrity. The creation of renditions may be
an
option, as this would not alter the original record content or
metadata.



  By declaring emails as records from within the email client, the
integrity
of the record is intact. The process is controlled and audited. The
transmission metadata is captured automatically, and can be used to
search
and retrieve the email when required. If there are any email
attachments,
they will often be selected and declared as records in their own right
so
that they can be readily retrieved and managed by the ERMS over time
(especially in terms of digital preservation).



  When email records are saved as "msg" files (or other file formats),
they
lose part of their context and become less controlled. If a user
chooses to
attach multiple "msg" email files to a new email and send that email
to
their own email account, when the email is declared, the record
metadata
will only reflect transmission details for the new email. While users
may
edit the record Title so that it reflects the whole email content, it
is
unlikely that standard details such as who sent which email to whom and
when
would be captured - so users may end up in a position where they
cannot
search upon the very emails they wanted to simplify. Furthermore,
depending
on content, the management of access and disposal controls may be
problematic over time.



  If it is not possible to declare records directly from an email
client, it
is inevitable that workarounds will be applied. However, any
environment
where actions are not properly controlled and audited may be open to
question. The application of strict business rules and management
controls
will help but it should be noted that they may not be sufficient to
ensure
the integrity and authenticity of both the record content and the
metadata
at all times."


  Susan Healy
  Information Policy Consultant
  The National Archives
  Tel 020 8392 5330 ext 2305
  Email [log in to unmask] 
  www.nationalarchives.gov.uk 




  Please don't print this e-mail unless you really need to.



 
--------------------------------------------------------------------------
-------




  National Archives Disclaimer







  This email message (and attachments) may contain information that is
confidential to The National Archives. If you are not the intended
recipient
you cannot use, distribute or copy the message or attachments. In such
a
case, please notify the sender by return email immediately and erase
all
copies of the message and attachments. Opinions, conclusions and other
information in this message and attachments that do not relate to the
official business of The National Archives are neither given nor
endorsed by
it.




 
--------------------------------------------------------------------------
----------




-----------------------------------------------------------------------------------------------
 Visit our website www.citb-constructionskills.co.uk for information and advice on training, learning and careers.

Files attached to this e-mail have been checked with virus detection software prior to transmission but you should still carry out your own virus check before opening any attachments.  CITB-ConstructionSkills does not accept liability for any damage or loss which may be caused by software viruses.  The contents of this e-mail and any attachments are the property of CITB-ConstructionSkills and are intended for the use of the recipient only.

If you have received this e-mail in error, please immediately notify us at [log in to unmask] and delete it.