Email Protective Marking Standard for the Australian Government

More documents

Recommendations

Info

2. The standard2.1 ScopeThis Standard defines the format of protective markings in Internet email message(RFC2822) headers.This Standard is mandatory for Australian Government agencies as defined in the PSPFand optional for non-government agencies. Specific compliance requirements for agenciesare outlined in the Australian Government Information Security Manual (ISM) [7].2.2 Out of ScopeThe following topics are not addressed by this Standard:• How a sending or receiving email agent should behave when creating or receivingan email message. This behaviour is defined in the ISM.• The protective measures that need to be applied to an email message based on itsprotective marking. The PSPF and the ISM define the protective measures to betaken based on the protective marking of the information.• The format of the protective marking when the marking is part of the body of anemail message.• The format of the protective marking when the marking is a digitally signedattribute of the message.• Differentiation between protective markings for whole messages or differentprotective markings for parts or components of messages, including attachmentsand paragraphs. The protective marking is used to indicate the highest protectionrequirements of any part or component of the email message.2.3 VersionThe version number for this definition of the Standard is:2012.378
2.4 NamespaceThe protective markings described in this Standard use the security classificationsystem defined in the Australian Government security classification system.The syntaxes defined in this Standard contain elements to convey this namespace. Thenamespace for this Standard is:gov.au• This namespace value does not necessarily reflect the email domain of the sendingand receiving parties. It is simply a short and convenient string that has been usedto differentiate this namespace from another entity’s.• If an Australian State or Territory government agency wishes to use the FederalGovernment namespace and terms then it can use the above. If the state agencywishes to define and use its own namespace and rules, then it may do so provided ituses a different namespace value.2.5 Syntax of the Protective MarkingThis Standard specifies two ways in which the protective marking can be applied to anemail message: Subject Field Marking Internet Message Header Extension.The Internet Message Header Extension SHOULD be used in preference to the SubjectField Marking (see the Implementation Guide for further information).2.5.1 Subject Field MarkingIn this syntax the protective marking is placed in the Subject field of the message (RFC2822“Subject”).• This approach is the least sophisticated of the techniques and is purposely designed so thata human user can construct and interpret the protective marking without the need foradditional tools. Email gateways should be able to translate the email’s subject betweeninternal and Internet formats without any degradation. The syntax is sufficiently rich so anemail agent, or extensions thereof, can include or parse the protective marking in anautomated fashion. The overloading of the “Subject:” header could interfere with other usesof the Subject field. Furthermore, entry of this information by a human is prone to error, andcould be easily misinterpreted by email systems. The approach is also included because it isbackwards compatible with all Internet email agents and systems.• Agencies SHOULD position the Protective Marking at the end of the Subject field.• Agencies SHOULD, where possible, implement mitigation strategies to minimise the risk ofthe Protective Marking being truncated from the end of the subject line.Note that during message generation and transport, other agents may manipulate the subject.9
Page 1 and 2: Email Protective Marking Standardfo
Page 3 and 4: AbstractThis Standard defines the f
Page 5 and 6: Changes from Version 1.0 26Changes
Page 7: 1.2 AudienceThis Standard is intend
Page 11 and 12: 2.10 Regular Expression DefinitionT
Page 13 and 14: Values for DLMs that may be conditi
Page 15 and 16: NS appears in the Internet Message
Page 17 and 18: 2.11.1 Base tokenscomma-FWS = "," F
Page 19 and 20: 2.11.6 Caveat rulescaveat-tag = %d6
Page 21 and 22: 2.11.13 Version rulesversion-tag =
Page 23 and 24: 4. GlossaryThese definitions have b
Page 25 and 26: 5. Appendix AA5.1 Change LogThis is
Page 27 and 28: Changes from 2005.3Specified Intern
Page 29 and 30: 6. Appendix B6.1 ExamplesFor the sa
Page 32: A message containing SECRET informa

Email Protective Marking Standard for the Australian Government

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?