Skip to content.
|Networking government in New Zealand.
 
You are here: Home » Services » SEEMail » Business Requirements v2.2 » 1 High Level Requirements

1 High Level Requirements

You are viewing an ARCHIVED page.


Key to symbols used throughout this document:

[BR] - Business requirement

[RFC] - RFC requirement (our interpretation)

[SIGS] [GCSB] - Government Security requirement (SIGS or GCSB)

1.1 Applicable RFCs

1. Gateways MUST be compliant with the following RFCs:

2. Compliance with the following RFCs is encouraged and partial compliance is required to meet S.E.E. Business requirements:

3. Where Gateways fail to interoperate, then the S.E.E. Steering Group will make a final decision, using the following order of precedence is:

  • S.E.E. Mail business requirements

  • RFC compliance

  • Product implementations

4. Wherever possible, Gateways SHOULD utilise the RFC specifications in the same manner as desktop clients.

5. Note that in certain circumstances, the S.E.E. Mail business requirements will be mandatory (MUST), even though the RFC only specifies an optional compliance (SHOULD).

1.2 Agency Requirements

6. The Gateway MUST NOT adversely impact on the functionality of existing systems, including virus checking and content filtering software. Specifically the Gateway MUST:

  • Permit transmission of existing non-secure e-mail;

  • Permit secure e-mails containing attachments;

  • Permit secure e-mails being transmitted to multiple user recipients;

  • Permit transmission of individual-to-individual S/MIME messages

7. Each SEEMail Agency must be confident that:

  • All SEEMail messages are secured;

  • A message with a SEEMail trigger word [ Current SEEMail trigger words are "[S**MAIL]", "[IN CONFID*NC*]", "[S*NSITV*]" and "[R*STRICT*D]"] will only ever be sent securely;

  • All messages between SEEMail Agencies authenticate the sending agency;

  • Incoming and outgoing messages must be automatically suspended when the Gateway is not operational.

8. The Recipient in a SEEMail Agency must be confident that:

  • The message is from the sending SEEMail Agency [ The definition of a SEEMail Agency is a Participating Agency who uses SEEMail and has current site certification.] as claimed;

  • No one outside the sending SEEMail Agency has read the message;

  • No one outside the sending SEEMail Agency has altered the message.

9. The Sender in a SEEMail Agency must be confident that:

  • The message can only be read by the receiving SEEMail Agency;

  • No one outside the receiving SEEMail Agency can read the message in transit;

  • No one outside the receiving SEEMail Agency can alter the message.

1.3 Implementation Requirements

10. The Gateway MUST require minimal implementation effort by existing SEEMail Agencies.

11. The Gateway MUST behave in a consistent and predictable manner.

12. The Gateway MUST notify relevant parties on exceptions.

1.4 Integration Requirements

13. The Gateway MUST require no client software customisation.

14. The Gateway MUST support common e-mail client software.

1.5 Integration Requirements

15. The Gateway MUST be able to utilise X.509 v3 certificates from any major certificate authority vendor.

16. The Gateway SHOULD operate on multiple platforms, such as Windows NT and Unix.

1.6 Listserve Requirements

17. The Gateway MUST permit the exchange of non-secure e-mail among list-serve groups of individuals; some of whom are members of Participating Agencies and some of whom are members of non-Participating Agencies.

18. The Gateway MUST allow the exchange of secure e-mail among list-serve groups of individuals; who are all members of Participating Agencies.

19. The Gateway MUST function with non-S.E.E. list-serves.

1.7 Interoperability Requirements

20. The Gateway MUST interoperate with all other Accredited Software in all Participating Agencies, in a manner that complies with these business requirements.

21. The Gateway MUST gracefully handle ALL functions indicated in this document as being potentially supported by a communicating gateway, whether mandatory (MUST) or optional (SHOULD), i.e. the Gateway must not cause a communicating Gateway to have to be configured with optional functions switched-off because the first Gateway cannot handle the optional functions without crashing or exhibiting some other undesirable behaviour.

1.8 Scalability Requirements

22. The Gateway MUST be scalable to interoperate with all Participating Agencies, up to the number of Eligible Agencies.

As per RFC822, Section 4.7.5, User-Defined-Fields:

Individual users of network mail are free to define and use additional header fields. Such fields must have names which are not already used in the current specification or in any definitions of extension-fields, and the overall syntax of these user-defined-fields must conform to this specification's rules for delimiting and folding fields. Due to the extension-field publishing process, the name of a user-defined-field may be pre-empted.

23. [RFC] The Gateway SHOULD be able to tag messages with an "X-SEEMail-Version" field, identifying the current SEEMail version e.g. "X-SEEMail-Version: 2.0".

1.9 Security Requirements

24. A Participating Agency MUST comply with the minimum security standards dictated by the Security In the Government Sector (SIGS) manual [ www.security.govt.nz/sigs/] and New Zealand Security of Information Technology (NZSIT) publications [ www.gcsb.govt.nz/nzsit/].

25. A Participating Agency MUST

  • Apply a structured risk management approach

  • Conduct risk assessments

  • Avoid default installations

  • Test and install security patches

  • Review audit logs

  • Review applications' security coding

  • Maintain security documentation

26. A Participating Agency MUST ensure at all times it is able to pass Site Certification tests.

27. A Participating Agency MUST be able to add a security classification label to messages.

28. A Participating Agency MUST be able to recover quickly from key compromise.

29. A Participating Agency MUST have real time access to the logging and analysis of faults, alerts and intrusions.

30. A Participating Agency SHOULD be aware when their Gateway fails and how this appears to Senders.


[ Previous | Next ]