ISO/IEC ISP 10611-1:1997

Information technology — International Standardized Profiles AMH1n — Message Handling Systems — Common Messaging — Part 1: MHS Service Support

Technologies de l'information — Profils normalisés internationaux AMH1n — Systèmes de messagerie — Messagerie commune — Partie 1: Support de Service MHS

General Information

• Status: Withdrawn
• Publication Date: 10-Dec-1997
• Withdrawal Date: 10-Dec-1997
• ICS: 35.100.05 - Multilayer applications
• Technical Committee: ISO/IEC JTC 1/SC 6 - Telecommunications and information exchange between systems
• Drafting Committee: ISO/IEC JTC 1/SC 6 - Telecommunications and information exchange between systems
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 03-Jul-2003
• Completion Date: 12-Feb-2026

Relations

• Revised: ISO/IEC ISP 10611-1:2003 - Information technology — International Standardized Profiles AMH1n — Message Handling Systems — Common Messaging — Part 1: MHS Service Support
• Effective Date: 15-Apr-2008
• Revises: ISO/IEC ISP 10611-1:1994 - Information technology — International Standardized Profiles AMH1n — Message Handling Systems — Common Messaging — Part 1: MHS Service Support
• Effective Date: 15-Apr-2008

Standards Content (Sample)

ISOAEC
INTERNATIONAL
ISP
STANDARDIZED
10611-1
PROFILE
Second edition
1997-12-15
Information technology - International
Standardized Profiles AMHI n - Message
Handling Systems - Common
Messaging -
Part 1:
MHS Service Support
Prof.& normalis& interna tionaux
Technologies de I’informa tion -
- Systgmes de messagerie - Messagerie commune -
AMHln
Partie I: Support de Service MHS
Reference number
ISOAEC ISP 10611-1:1997(E)
lSO/IEC ISP 1061 l-l : 1997 (E)
Contents
Page
. . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . III
Foreword
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv
Introduction
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1 Scope
. . . . . . . . . . . . . .*. 2
2 Normative references
. . . . . . . . .*. 2
3 Definitions
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .~. 4
4 Abbreviations
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .* 5
5 Conformance
6 Basic requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7 Functional groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8 Naming and addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9 Error and exception handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Annexes
A Elements of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
B Amendments and corrigenda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
C Secure messaging - rationale and implementation considerations. 31
D Additional recommended practices for 1984 inter-working . . . . . . . . . . . . . . . . . . 39
‘E AMHI - overall scope and applicability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .m. 41
F Bibliography .=.~~*~=~=~~*.==~~*~==. 45
0 ISOAEC 1997
All rights reserved. Unless otherwise specified, no part of this publication may be
reproduced or utilized in any form or by any means, electronic or mechanical, including
photocopying and microfilm, without permission in writing from the publisher.
ISO/IEC Copyright Office l Case Postale 56 l CH-1211 Geneve 20 l Switzerland
Printed in Switzerland
ii
ISOAEC ISP 1061 l-l : 1997 (E)
0 ISO/IEC
Foreword
IS0 (the International Organization for Standardization) and IEC (the
International Electrotechnical Commission) form the specialized system
for worldwide standardization. National bodies that are members of IS0
or IEC participate in the development of International Standards through
technical committees established by the respective organization to deal
with particular fields of technical activity. IS0 and IEC technical
committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with IS0
and IEC, also take part in the work.
In the field of information technology, IS0 and IEC have established a
joint technical committee, ISO/IEC JTC 1. In addition to developing
International Standards, ISO/IEC JTC 1 has created a Special Group on
Functional Standardization for the elaboration of International
Standardized Profiles.
An International Standardized Profile is an internationally agreed,
harmonized document which identifies a standard or group of standards,
together with options and parameters, necessary to accomplish a function
or a set of functions.
Draft International Standardized Profiles are circulated to national bodies
for voting. Publication as an International Standardized Profile requires
approval by at least 75 o/b of the national bodies casting a vote.
International Standardized Profile ISO/IEC ISP 1061 l-l was prepared
with the collaboration of
- Asia-Oceania Workshop (AOW);
- European Workshop for Open Systems (EWOS);
- Open Systems Environment Implementors’ Workshop (OIW).
This second edition cancels and replaces the first edition (ISO/IEC ISP
10611 -I:1 994), which has been technically revised. It also incorporates
Technical Corrigendum 1 :I 996.
ISOIIEC ISP 10611 consists of the following parts, under the general title
lnforma tion technology - lnterna tional Standardized Profiles A MH 1 n -
Message Handling Systems - Common Messaging:
- Part 1: MHS Service Support
- Part2: Specification of ROSE, RTSE, ACSE, Presentation and
Session Protocols for use by MHS
- Part 3: AMH 11 - Message Transfer (PI)
- Part 4: AMHIZ and AMH74 - MTS Access (P3) and MTS 94 Access
P3)
- Par? 5: AMH13 - MS Access (P?‘)
- Part 6: AMHIS - MS 94 Access (P7)
Annexes A and B form an integral part of this part of ISO/IEC ISP 10611.
Annexes C, D, E and F are for information only.
. . .
III
ISOAEC ISP 1061 l-l : 1997 (E)
0 ISO/lEC
Introduction
This part of ISOIIEC ISP 10611 is defined within the context of Functional
Standardization, in accordance with the principles specified by ISO/IEC
TR 10000, “Framework and Taxonomy of International Standardized
Profiles”. The context of Functional Standardization is one part of the
overall field of Information Technology (IT) standardization activities,
covering base standards, profiles, and registration mechanisms. A profile
defines a combination of base standards that collectively perform a
specific well-defined IT function. Profiles standardize the use of options
and other variations in the base standards, and provide a basis for the
development of uniform, internationally recognized system tests.
One of the most important roles for an ISP is to serve as the basis for the
development (by organizations other than IS0 and IEC) of internationally
recognized tests. ISPs are produced not simply to ‘legitimize’ a particular
choice of base standards and options, but to promote real system
interoperability. The development and widespread acceptance of tests
based on this and other ISPs is crucial to the successful realization of this
goal .
The text for this part of ISO/IEC ISP 10611 was developed in close
cooperation between the MHS Expert Groups of the three Regional
Workshops: the North American OSE Implementors’ Workshop (OIW),
the European Workshop for Open Systems (EWOS) (jointly with the
corresponding expert group of the European Telecommunications
Standards Institute - ETSI) and the OSI Asia-Oceania Workshop (AOW).
This part of ISO/IEC ISP 10611 is harmonized between these three
Workshops and it has been ratified by the plenary assemblies of all three
Workshops.
iv
INTERNATIONAL STANDARDIZED PROFILE @ ‘So”EC ISO/IEC ISP 1061 l-l : 1997 (E)
Information technology - International Standardized
Profiles AMHln - Message Handling Systems - Common
Messaging -
Part 1: MHS Service Support
1 Scope
1 .l General
This part of ISO/IEC ISP 10611 contains the overall specifications of the support of MHS Elements of Service
and associated MHS functionality which are generally not appropriate for consideration only from the perspective
of a single MHS protocol. These specifications form part of the Common Messaging application functions, as
defined in the parts of ISO/IEC ISP 10611, which form a common basis for content type-dependent International
Standardized Profiles for MHS that will be developed. Such specifications are in many cases applicable to more
than one MHS protocol or are otherwise concerned with component functionality which, although it can be
verified via protocol, is not just related to protocol support. They are therefore designed to be referenced in the
MHS Common Messaging application profiles ISO/IEC ISP 1061 l-3 (AMHI I), ISO/IEC ISP 1061 l-4 (AMH12
and AMH14), ISO/IEC ISP 1061 l-5 (AMH13) and ISO/IEC ISP 1061 l-6 (AMH15), which specify the support of
specific MHS protocols and associated functionality.
The specifications in this part of ISO/IEC ISP 10611 cover the provision and use of features associated with the
Message Transfer (MT) Service (MTS) (as defined in clause 8 of ISO/IEC 10021-l), together with those features
associated with intercommunication with Physical Delivery (PD) Services (as defined in clause 10 of ISO/IEC
10021-I). Features which are associated with the Message Store (MS) and User Agent (UA) which are content
type-independent are also covered. Features which are specific to a particular content type (including the
provision of services by a UA to an MHS user) are covered in separate content type-dependent ISPs.
The specifications in this part of ISO/IEC ISP 10611 are divided into basic requirements, which are required to
be supported by all MHS implementations, and a number of optional functional groups, which cover significant
discrete areas of related functionality which are not required to be supported by all implementations.
An overview of the scope and applicability of the AMHln set of profiles and of the structure of ISO/IEC ISP
10611 is provided in annex E.
1.2 Position within the taxonomy
This part of ISO/IEC ISP 10611 is the first part, as common text, of a multipart ISP identified in IEC TR
10000-2 as “AMHI, Message Handling Systems - Common Messaging”.
This part of ISO/IEC ISP 10611 does not, on its own, specify any profiles.

0 ISO/IEC
ISOAEC ISP 10611-l : 1997 (E)
Normative references
The following documents contain provisions which, through reference in this text, constitute provisions of this
part of ISO/IEC ISP 10611. At the time of publication, the editions indicated were valid. All documents are
subject to revision, and parties to agreements based on this part of ISO/IEC ISP 10611 are warned against
automatically applying any more recent editions of the documents listed below, since the nature of references
made by ISPs to such documents is that they may be specific to a particular edition. Members of IEC and IS0
maintain registers of currently valid International Standards and ISPs, and the Telecommunications
Standardization Bureau of the ITU maintains a list of currently valid ITU-T Recommendations.
Amendments and corrigenda to the base standards referenced are listed in annex B.
NOTES
1 - References in the body of this part of ISO/IEC ISP 10611 to specific clauses of lSO/IEC documents shall be considered
to refer also to the corresponding clauses of the equivalent ITU-T Recommendations (as noted below) unless otherwise
stated.
2 - Informative references are found in annex F.
ISOAEC TR I OOOO-l:- 1 , Information technology - Framework and taxonomy of International Standardized Profiles - Part I:
General principles and documentation framework.
ISOAEC TR 10000-2:- ‘, Information technology - Framework and taxonomy of Internatjonal Standardized Profiles - Part 2:
Principles and Taxonomy for OS/ profiles.
ITU-T Recommendation F.4OO/X.400 (1996), Message Handling Systems - System and service overview.
ISOAEC 10021-l:- * , Information technology - Message Handling Systems (MHS): System and service overview
[see also ITU- T Recommenda t/on F. 400/X. 4001.
ITU-T Recommendation X.402 (1995) I ISO/IEC 10021-2: 1996, information technology - Message Handling Systems
(MHS): Overa// architecture.
ITU-T Recommendation X.41 1 (1995) I ISOAEC 10021-4: 1997, Information technology - Message Handling Systems
(MHS): Message transfer system: Abstract service definition and procedures.
ITU-T Recommendation X.413 (1995) I ISOAEC 10021-5: 1996, information technology - Message Handling Systems
(MHS): Message store: Abstract service definition.
ITU-T Recommendation X.509 (1993) I ISOAEC 9594-8: 1995, Information technology - Open Systems Interconnectjon -
The Directory: Authentication framework.
Definitions
,3
For the purposes of this part of ISO/IEC ISP 10611, the following definitions apply.
Terms used in this part of ISO/IEC ISP 10611 are defined in the referenced base standards; in addition, the
following terms are defined.
1 To be published. (Revision of ISO/IEC 10000:1995)
* To be published. (Revision of ISO/IEC IOWl-1:1994)
0 ISOAEC ISOAEC ISP 10611-l : 1997 (E)
3.1 General
3.1.1 Basic requirement: an Element of Service, protocol element, procedural element or other identifiable
feature specified in the base standards which is required to be supported by all MHS implementations.
3.1.2 Functional group: a specification of one or more related Elements of Service, protocol elements,
procedural elements or other identifiable features specified in the base standards which together support a
significant optional area of MHS functionality.
NOTE - A functional group can cover any combination of MHS features specified in the base standards for which the effect
of implementation can be determined at a standardized external interface - i.e. via a standard OSI communications protocol
(other forms of exposed interface, such as a standardized programmatic interface, are outside the scope of this version of
ISO/IEC ISP 10611).
3.2 Support classification
To specify the support level of Elements of Service for this part of ISOAEC ISP 10611, the following terminology
is defined.
3.2.1 mandatory support (m):
for origination: a service provider shall be able to make the Element of Service available to a
service user in the role of originator; a service user shall be able to use the Element of Service in
the role of originator;
for processing: a service provider shall implement all procedures specified in the base standards
which are associated with the provision of the Element of Service (i.e. to be able to provide the full
effect of the Element of Service);
for reception: a service provider shall be able to make the Element of Service available to a
service user in the role of recipient; a service user shall be able to use the Element of Service in the
role of recipient.
3.2.2 optional support (0): an implementation is not required to support the Element of Service. If support is
claimed, then the Element of Service shall be treated as if it were specified as mandatory support.
3.2.3 conditional support (c): the Element of Service shall be supported under the conditions specified in this
part of ISOAEC ISP 10611. If these conditions are met, the Element of Service shall be treated as if it were
specified as mandatory support. If these conditions are not met, the Element of Service shall be treated as if it
were specified as optional support (unless otherwise stated).
3.2.4 out of scope (i): the Element of Service is outside the scope of this part of ISOAEC ISP 10611 - i.e. it will
not be the subject of an ISP conformance test. However, the handling of associated protocol elements may be
specified separately in the subsequent parts of this ISP.
3.2.5 not applicable (0): the Element of Service is not applicable in the particular context in which this
classification is used.
3.3 Profile object identifiers
Profiles that are specified in ISOAEC ISP 10611 are identified by the object identifiers in table 1.
NOTE - These object identifiers are included for formal purposes and any use of them is not defined.
They are not related to
any implementation of messaging and do not appear in the protocols specified in this ISP.

0 ISO/IEC
ISO/IEC ISP 10611-l : 1997 (E)
Table 1 - Profile object identifiers
Profile Object ldentif ier
AMHI 11 { iso(1) standard(O) common-messaging(lO611) message-transfer(3) normal-mode(l) }
{ iso(1) standard(O) common-messaging(lO611) message-transfer(3) x410-mode(2) }
AMHI 12
{ iso(1) standard(O) common-messaging(lO611) mts-access(4) }
AMH12
{ iso(1) standard(O) common-messaging(lO611) ms-access@) }
AMH13
AMH14 { iso(1) standard(O) common-messaging(lO611) mts-95access(6) }
AMH15 { iso(1) standard(O) common-messaging(lO611) ms-94-access(7) }
4 Abbreviations
841W 84 Interworking
AA Auto-Annotation
AC Auto-Correlation
AD Auto-Deletion
AG Auto-Grouping
ALERT Alert
AMH Application Message Handling
ASN.l Abstract Syntax Notation One
COMPUSEC Computer security
COMSEC Communications securitv
,
cv Conversion
DC Delivery Constraints
DIR Use of Directory
DL Distribution List
DSA Directory system agent
DUA Directory user agent
EoS Element of Service
FG Functional group
ISP International Standardized Profile
LD Latest Delivery
LOG Logging
MHS Message Handling Systems
MLS Multi-Level Security
MS Message store
MT Message transfer
MTA Message transfer agent
MTS Message Transfer System
ORAM ORAddress Matching
ORNM ORName Matching
OSI Open Systems Interconnection
PD Physical Delivery
,PDAU Physical delivery access unit
RED Redirection
RED2 Redirection Instructions
RD Restricted Delivery
Return of Content
RoC
Storage of Draft Messages
SDM
Security
SEC
Storage and Grouping
SG
SPP Simple Protected Password
Trash
TRASH
User agent
UA
lSO/IEC ISP 1061 l-l : 1997 (E)
0 ISO/IEC
Support level for Elements of Service (see 3.2):
m
mandatory support
optional support
C
conditional support
i
out of scope
-
not applicable
5 Conformance
NO conformance requirements are specified in this part of ISO/IEC ISP 10611.
NOTE - This part of ISO/IEC ISP 10611 is a reference specification of the basic requirements and functional groups
covered by the AMHln set of profiles and is additional to the protocol-specific requirements specified in the following parts
of lSO/IEC ISP 10611. Although this part of ISO/IEC ISP 10611 contains normative requirements, there is no separate
conformance to this part (i.e. it is not identified in the MHS taxonomy in ISO/IEC TR 10000-2) since such requirements are
only significant when referenced in the context of a particular protocol.
Conformance requirements are specified by protocol for each MHS functional object in the following parts of
ISO/IEC ISP 10611 with reference to the specifications in this part. Support of functionality as specified in this
part may only be verifiable where the effect of implementation can be determined at a standardized external
interface - i.e. via a standard OSI communications protocol. Further, the provision of Elements of Service and
other functionality at a service interface will not necessarily be verifiable unless such interface is realized in the
form of a standard OSI communications protocol. Other forms of exposed interface (such as a human user
interface or a standardized programmatic interface) may be provided, but are not required for conformance to
this version of ISO/IEC ISP 10611.
6 Basic requirements
Annex A specifies the basic requirements for support of MHS Elements of Service (EoS) for conformance to
ISO/IEC ISP 10611. Basic requirements specify the level of support required by all MHS implementations, as
appropriate to each type of MHS functional object - i.e. MTA, MS or UA (as MTS-user or MS-user, as relevant).
NOTE - ISO/IEC ISP 10611 is confined to the provision of services by MTAs and MSs, and the use of such services by
MTS-users and MS-users. It does not cover the provision of such services by UAs to MHS users, which is specified in
content type-specific profiles.
6.1 Content and encoded information types
It shall be stated in the PIGS which content type and encoded information type values are supported.
6.2 Message length
If the implementation imposes any constraints on the size of the message content or envelope, then all such
constraints shall be stated in the PIGS.
NOTE - Implementors are advised to avoid constraining the size of messages as far as possible. For example, any
constraint which prevents the transfer of a 2 Megaoctet message could cause problems when interworking with 1984
systems. Requirements will vary according to application and environment and could be much higher than 2 Megaoctets.
6.3 Number of recipients
It shall be stated in the PIGS if there is any limit on the number of recipients that can be specified in a message
envelope.
0 ISOAEC
ISOAEC ISP 1061 l-l : 1997 (E)
7 Functional groups
Annex A also specifies any additional requirements for support of MHS EoS if support of an optional functional
group (FG) is claimed, as appropriate to each type of MHS functional object. The following subclauses
summarize the functionality supported by each of the optional FGs and identify any particular requirements or
implementation considerations which are outside the scope of formal conformance to ISO/IEC ISP 10611. A
summary of the functional groups, identifying which may be supported (Y) and which are not applicable (N) for
each type of MHS functional object (i.e. MTA, MS or UA - whether as MTS-user or as MS-user is not
distinguished), is given in table 2 and 3. Table 3 lists the functional groups which are only applicable when
claiming conformance to AMHI 5.
Table 2 - Summary of AMHln optional functional groups
Functional Group MTA
MS
Conversion (CV) Y N
Distribution List (DL) Y N
Physical Delivery (PD) Y N
Redirection (RED)
Y N
Latest Delivery (LD) Y
N
Return of Content (RoC) Y Y
Security (SEC) Y Y
Use of Directory (DIR) Y N
84 Interworking (841W) Y N
Simple Protected Password (SPP)
Y Y
Redirection Instructions (RED2)
Y N
Delivery Constraints (DC) Y N
Restricted Delivery (RD)
Y N
NOTES
UA functionality may be further defined in content type-dependent profiles.

0 ISO/IEC ISO/IEC ISP 1061 l-l : 1997 (E)
Table 3 - Summary of AMHIS optional functional groups
Functional Group MTA MS UA
N Y Y
ORAddress Matching (ORAM)
N Y Y
ORName Matching (ORNM)
Storage of Draft Messages (SDM) N Y Y
Storage and Grouping (SG) N Y Y
N Y Y
Alert (ALERT)
Auto-Annotation (AA) N Y Y
Auto-Grouping (AG) N Y Y
N
Trash (TRASH) Y Y
N Y Y
Auto-Deletion (AD)
Auto-Correlation (AC) N Y Y
Logging (LOG) N Y Y
The conformance requirements for support of the various functional groups, covering support of additional
protocol elements and/or procedures, are specified in parts 3, 4, 5 and 6 of this ISP, according to the protocol(s)
to which each functional group relates.
7.1 Conversion (CV)
The Conversion FG covers support of those EoS which provide the functionality required to perform the action of
encoded information type conversion. Support of the CV FG is only applicable to an MTA.
NOTE 1 - Support of EoS associated with conversion prohibition is a basic requirement, but this does not imply a capability
to perform conversion.
Either or both of Explicit Conversion and Implicit Conversion shall be supported. A conforming implementation
shall obey the rules specified in subclauses 14.3.5 and 14.3.9 of ISO/IEC 10021-4.
Conformance to ISO/IEC ISP 10611 does not require the capability to perform any specific conversions. Further
specific requirements may be included in content type-dependent International Standardized Profiles for MHS
that will be developed or may otherwise be separately specified. It shall be stated in the PIGS which encoded
information type conversions the implementation can perform, for the type(s) of conversion (i.e. explicit or
implicit) for which support is claimed. The PIGS shall also state the conditions under which loss of information is
determined (if at all) for each encoded information type conversion for which support is claimed.
NOTE 2 - It may not be possible to verify support of conversion in the absence of additional specification which is related to
one or more identified content types.

0 ISO/IEC
ISOAEC ISP 10611-l : 1997 (E)
7.2 Distribution List (DL)
The Distribution List FG covers all issues relating to the performance of distribution list (DL) expansion. Support
of the DL FG is only applicable to an MTA.
NOTE - Other aspects concerned with the use of DLs (e.g. the ability to submit a message specifying a recipient which is a
DL) are basic requirements. Similarly, it is a basic requirement that an MTA must be able to receive and handle correctly a
message that reflects prior DL expansion.
A conforming implementation shall obey the rules specified in subclause 14.3.10 of ISO/IEC 10021-4.
Conformance to ISO/IEC ISP 10611 does not require any DL management capability other than as specified in
subclause 14.3.10 of ISO/IEC 10021-4. Any further specification will be implementation-dependent.
7.3 Physical Delivery (PD)
FG is concerned with access to physical delivery (i.e.
The Physical Delivery postal, courier, etc) services. The
separate and distinct parts:
PD FG comprises two
support of PD EoS on submission;
support of a co-located physical delivery access unit (PDAU).
Support of PD EoS on submission is applicable to an MTA or a UA. Support of a PDAU is only applicable to an
MTA. If an MTA supports a PDAU and also supports message submission, then it shall also support PD EoS on
submission.
Support of the PD FG also requires support of corresponding OR-address extension attributes.
If the PDAU generates any error on export, then the MTA shall generate a non-delivery report or take other
appropriate action (e.g. alternate recipient processing). All other processing concerned with the actual physical
rendition and delivery of the message is outside the scope of ISOIIEC ISP 10611.
7.4 Redirection (RED)
The Redirection FG covers support of those EoS which provide the functionality required to perform the actions
associated with the delivery of a message to a recipient other than the one initially specified by the originator.
Support of the RED FG is only applicable to an MTA.
NOTE - Support of EoS associated with the prevention of redirection is a basic requirement, but this does not imply a
capability to perform redirection. Similarly, support of the Alternate Recipient Allowed EoS is a basic requirement, but this
does not imply a capability to perform alternate recipient assignment.
A conforming implementation shall obey the rules specified in subclause 14.3 of ISO/IEC 10021-4.
The means by which the Alternate Recipient Assignment EoS is achieved is outside the scope of ISO/IEC ISP
10611.
7.5 Latest Delivery (LD)
The Latest Delivery FG covers support of the Latest Delivery EoS - i.e. the functionality required to cause non-
delivery to occur if a latest delivery time specified by the originator has expired. Support of the LD FG is
applicable to an MTA or a UA. If an MTA supports the LD FG and also supports message submission, then it
shall also support the Latest Delivery EoS on submission.
NOTE - Latest delivery designation is assured only if it is supported by at least the delivering MTA.

0 ISO/IEC ISOAEC ISP 10611-l : 1997 (E)
7.6 Return of Content (RoC)
The Return of Content FG covers support of the Return of Content EoS - i.e. the functionality required to cause
the contents of a submitted message to be returned in any non-delivery notification if so requested by the
originator. Support of the RoC FG is applicable to an MTA, an MS or a UA. If an MTA supports the RoC FG and
also supports message submission, then it shall also support the Return of Content EoS on submission.
NOTE - Return of content is assured only if it is supported by all MTAs through which the message might pass.
7.7 Security (SEC)
7.7.1 Overview
The Security FG covers the provision of secure messaging and is specified as three security classes which are
incremental subsets of the security features available in the MHS base standards:
This security class only requires security functions which are applicable between MTS-users.
so
Consequently security mechanisms are implemented within the MTS-user. An MTA is only required
to support the syntax of the security services on submission and delivery (support of the syntax on
relaying is a basic requirement). An MTA is not expected to understand the semantics of the
security services.
This security class requires security functionality within both the MTS-user and the MTS. The MTS
Sl
security functionality is only required to achieve secure access management. As with SO, most of
the security mechanisms are implemented within an MTS user. Sl primarily provides integrity and
authentication between MTS users. However, MTAs are expected to support digital signatures for
peer-to-peer authentication, security labelling and security contexts.
s2 This security class adds security functions within MTAs and the MTS. The main security function
added within this class is authentication within the MTS, and hence non-repudiation can also be
provided.
In addition, each of the three security classes has a variant (denoted as SOC, SlC and S2C) which requires
support of end-to-end content confidentiality.
NOTE - A separate Functional Group is defined for Simple Protected Password, since it was introduced in the base
standard in the 1995-l 996 publication.
Double enveloping can be used with each security class as an optional extension, but is outside the scope of
conformance to ISO/IEC ISP 10611 and will be subject to bilateral agreement.
Support of the SEC FG is applicable to an MTA, an MS or a UA (either as MTS-user or as MS-user) and
requires as a minimum support of security class SO.
Unless otherwise stated, symmetric or asymmetric techniques (or a combination thereof) may be used within
each security class and are identified by the registered algorithm identifier.
Various levels of assurance in trusted COMPUSEC functionality may be used within each security class, but this
is outside the scope of an ISP.
A full rationale for each of the security classes and a broader discussion of security considerations are provided
in annex C.
Table 4 summarizes the requirements of the security classes on an MTS-user and on an MTA.

0 ISO/IEC
ISOAEC ISP 1061 l-l : 1997 (E)
Table 4 - Overview of the SEC security classes
MTS-user
Security
Class
Supports relay of security EoS
~
Supports submission and delivery of
Content integrity
security EoS
Origin authentication (end-to-end)
As SO plus: As SO plus:
Proof of delivery Peer entity authentication
Message security labelling Message security labelling
Security context Security context
Security management Security management
As Sl plus:
As Sl plus:
Origin authentication checks Origin authentication checks
Proof of submission Proof of submission
As Sn
As Sn plus:
Content confidentiality
diagrammatically as shown in figure 1.
The incremental functionality of the security classes can be represented
s2
\
L-t \\. n
Figure 1 - Incrementa functionality of the SEC security classes
7.7.2 Secure interworking
Interworking between implementations supp rting different security classes can be achieved in terms of any
,common class(es) supported. As specified in the base standards, an implementation which supports secure
access management shall check the label of a message, probe or report against the security context. There is
no negotiation of security class during association establishment.
The security class in force is identified using the security-policy-identifier within a security label, as specified in
table 5. Such generic security-policy-identifiers only imply support of the MHS security services as specified for
these security classes in this part of ISO/IEC ISP 10611. No other COMSEC or COMPUSEC functionality can be
assumed by use of such security-policy-identifiers. More specific security policies may be based on one or more
of the security classes as defined in this clause but will require use of registered security-policy-identifiers for
private secure interworking.
A security label may additionally contain one or more of security-classification, security-categories and privacy-
mark. Table 5 specifies a minimum set of values for security-categories. Again, further values may be registered
for private secure intetworking. However, in all cases, the precise semantics of security-categories are outside
the scope of this ISP and will require bilateral agreement.
ISOAEC ISP 1061 l-l : 1997 (E)
0 ISO/IEC
Table 5 - Security label identifiers
ldentif ier Value
{ iso identified-organization(3) ewos(16) eg(2) mhs(4) security(4) }
id-mhs-security
id-policy-identifier { id-mhs-security 1 }
security-policy-identifiers:
{ id-policy-identifier 0 0 0 }
security-class-SO-no-POD
{ id-policy-identifier 0 1 0 }
security-class-SOC-no-POD
{ id-policy-identifier 1 0 }
security-class-S1
{ id-policy-identifier 1 1 }
security-class-S1 C
{ id-policy-identifier 2 0 }
security-class-S2
{ id-policy-identifier 2 1 }
security-class-S2C
id-category-identifier { id-mhs-security 2 }
security-categories:
{ id-category-identifier 0 }
private
{ id-category-identifier 1 }
confidence
{ id-category-identifier 2 }
commercial-in-confidence
{ id-category-identifier 3 }
management-in-confidence
personal-in-confidence { id-category-identifier 4 }
The Security Context security service ensures that a message security label matches at least one of the set of
labels specified in the security context established between the communicating entities. An implementation
which supports this service shall as a minimum support exact matching for equality on the security-policy-
identifier, security-classification and security-categories elements of the label.
The basic support requirement is that absence of an element shall not be treated as “any value” - i.e. all
permissible combinations of occurrence and value for the elements of the message security label will need to be
elaborated in the security context (see also annex C).
7.7.3 Description of the security classes
The following tables identify the security sewices covered by each of the security classes within the SEC FG.
Where the classification of a security service does not change for the higher security classes, then the security
service is not repeated in the tables for those higher security classes.
Figure 2 explains the column headings used in the tables, which identify which MHS functional objects are
involved in the provision and use of each security service.
’ UA k, pi Gi :,19l UA
Figure 2 - Key to security class tables
0 ISO/IEC
ISO/IEC ISP 1061 l-l : 1997 (E)
7.7.3.1 Security class SO
Table 6 - Security class SO
2 3 4 5 6 7 a 9
Security Service 1
UN UN MS/ UA/ MTA/ MTA/ MTA/ MS/ MS/
UA MS MTA MTA MTA UA MS UA UA
ORIGIN AUTHENTICATION
- - -
- -
Message Origin Authentication’ m i - i
- - - -
- -
Probe Origin Authentication i - i
- - - -
- -
Report Origin Authentication i i i
- - - - - -
- -
Proof of Submission i
0 - - - - - -
Proof of Delivery 0 -
SECURE ACCESS MANAGEMENT
-
0 0
Peer Entity AuthenticationzV6 0 0 0 0 - 0
-
Security Context 0 0 0 0 0 0 - 0
DATA CONFIDENTIALITY
- -
i i i i i i i
Connection Confidentiality
0 - - - - - - - -
Content Confidentiality
i - - _ - - - - -
Message Flow Confidentiality
DATA INTEGRITY
- -
Connection Integrity i i i i i i i
m - - - - _ _ - -
Content Integrity
0 - - - - - - - -
Message Sequence Integrity4
NON-REPUDIATION
- - - - -
Non-repudiation of Origin’ j5 0 - - i
- - - - - - - -
Non-repudiation of Submission i
0 - - - - - -
Non-repudiation of Delivery’ 0 -
Message Security Labelling2’3 0 0 0 0 0 0 0 0 0
SECURITY MANAGEMENT
-
Change Credentials 0 - 0 i7 0 0 - -
- - - - -
Register 0 - 0 i7
- 0 - - - - - - -
MS-Register
0 ISO/IEC ISOAEC ISP 1061 l-l : 1997 (E)
NOTES
Only provided to the message recipient (using the Message Argument Integrity security element).
Using either asymmetric or symmetric algorithms as identified by the algorithm identifier.
When security labelling is used, the security-policy-identifier shall be included.
Allocation and management of sequence numbers is outside the scope of this ISP and is subject to bilateral
agreement.
Using either a trusted notary (symmetric) or using certificates and tokens which are not repudiable (asymmetric).
6 Authentication between co-located objects is a local issue.
7 These services are expected to be provided by non-standard management services and are therefore outside the
scope of this ISP.
7.7.3.2 Security class Sl
Table 7 - Security class Sl
Security Service 1 2 3 4 5 6 7 a 9
As SO plus: UN UAI MS/ UA/ MTA/ MTA/ MTA/ MS/ MS/
UA MS MTA MTA MTA UA MS UA UA
ORIGIN AUTHENTICATION
- - - - -
Message Origin Authentication* m’ i -
i
m - - - - - - -
m6
Proof of Delivery
SECURE ACCESS MANAGEMENT
- -
Peer Entity Authentication3’4 m’ m’ m’ m’ m’ m’ m’
- -
Security Context m’ m’ m’ m’ m’ m’ m’
DATA CONFIDENTIALITY
-
-
Connection Confidentiality i i i i i i i
DATA INTEGRITY
- -
Connection Integrity
i i i i i i i
- - - - - -
- -
Content Integrity
m’
Message Security Labelling3 m’
m’ m’ m’ m’ m’ m’ m’ m’
SECURITY MANAGEMENT
Change Credentials m - m i5
m m - -
- - - - -
Register m - m
i5
- m - - - - - _ _
MS-Register
0 ISO/IEC
ISOAEC ISP 1061 l-l : 1997 (E)
NOTES
Shall always be used.
Only provided to the message recipient (using the Message Argument Integrity security element).
Using either asymmetric or symmetric algorithms as identified by the algorithm identifier.
Authentication between co-located objects is a local issue.
These services are expected to be provided by non-standard management services and are therefore outside the
scope of this ISP.
6 If Proof of Delivery and Content Confidentiality are both used, and delivery is to an MS, then proof of delivery can
only be computed on the encrypted content. It should be noted that this will not provide Non-repudiation of
Delivery.
7.7.3.3 Security class S2
Table 8 - Security class S2
Security Service 1 2 3 4 5 6 7 a 9
As Sl plus: UAI UAI MTA/
MS/ UN MTA/ MTA/ MS/ MS/
UA MS MTA
MTA MTA UA MS UA UA
ORIGIN AUTHENTICATION
- - - - - -
Message Origin Authentication3 m’ m’ m’
- - - - - - -
Probe Origin Authentication m’ m’
- - - - - -
Report Origin Authentication m’ m’
m’
- - - - - - - -
Proof of Submission m
NON-REPUDIATION
- - - - - - -
Non-repudiation of Origin’
m4 m*
- - - - - - - -
Non-repudiation of Submission
m*
- - - - - - -
Non-repudiation of Delivery
m4
m*
1 Shall always be used.
Using an asymmetric mechanism (i.e. certificates and tokens which are non-repudiable) for authentication within
MTAs and the MTS.
3 Using the Message Origin Authentication Check security element.
4 Using either a trusted notary (symmetric) or non-repudiable certificates and tokens (asymmetric).
ISOAEC ISP 10611-l : 1997 (E)
0 ISO/IEC
7.7.3.4 Confidential security class variants SnC
Table 9 - Confidential security class variants SnC
6 7 a 9
Security Service 1 2 3 4 5
UAI UAI MS/ UN MTA/ MTA/ MTA/ MS/ MS/
As Sn plus:
UA MS MTA MTA MTA UA MS UA UA
DATA CONFIDENTIALITY
m - - - - - - - -
Content Confidentiality
7.8 Use of Directory (DIR)
The Use of Directory FG covers support of the Designation of Recipient by Directory Name EoS as follows:
support of specification of a recipient by means of a directory name by an MTS-user or an MTA on
submission;
support of access to a directory service by an MTA to obtain one or more OR-addresses (either on
submission or subsequently if an OR-address is absent or determined to be invalid and a directory
name is present).
NOTE 1 - A directory may also be used directly by MHS users to obtain information to assist in the submission of
messages. However, such use is not necessarily MHS-specific and is therefore outside the scope of this ISP.
For a UA, support of the DIR FG only requires the ability to submit a message with one or more OR-names
specified using a directory name, as specified in subclause 8.5.5 of ISO/IEC 10021-4. In addition, the UA shall
be able to make use of a Directory Name to identify itself, as specified in clause 8.1 .I .I .I .I of ISO/IEC 10021-4.
Whether or not the UA also has the capability to access a directory directly is outside the scope of ISO/IEC ISP
10611.
An MTA may access a directory service using a Directory User Agent (DUA). The interface between the MTA
and the DUA is a local matter and is outside the scope of ISO/IEC ISP 10611.
The only information that is assumed to be capable of being returned by the directory service in this version of
ISO/IEC ISP 10611 is an attribute containing one or more OR-addresses. The use of a directory service to
support distribution list processing is outside the scope of this version of lSO/IEC ISP 10611.
NOTE 2 - The MTS may also use a directory service to obtain information, for example, that may be used in the routeing of
messages. However, such applications of a directory service are not defined by the MHS base standards and are therefore
outside the scope of ISO/IEC ISP 10611.
7.9 84 Interworking (841W)
The 84 Interworking functional group covers interworking between implementations conforming to ISO/IEC ISP
10611 (hereafter referred to as ‘1988 systems’) and implementations conforming to the ITU X.400(1 984)
Recommendations (hereafter referred to as ‘1984 systems’). Support of the 841W FG is only applicable to an
MTA and is not applicable unless the MTA supports the PI mts-transfer-protocol-1984 application context (see
ISO/IEC ISP 10611-3).
Support of the 841W FG requires observance of the interworking rules defined in annex B of ISO/IEC 10021-6.
Additional recommended practices for interworking with 1984 systems are described in annex D.
0 ISO/IEC
ISOAEC ISP 1061 l-l : 1997 (E)
7.10 Simple Protected Password (SPP)
The Simple Protected Password functional group covers the use of the protected-authentication introduced in
the 1995-I 996 publication of the base standards. The initiator-credentials comprise a password protected as
described in clause 6 of ISO/IEC 9594-8. Support of the SPP FG is applicable to an MTA, an MS or a UA.
One part provides a protection of the password in storage e.g. in a message store system.
The permanent protection of A’s password is of the form :
Protected1 = fl (tl a, ql a, passwA)
The second part provides protection in transit e.g. against replay. An originating user, user A, sends its protected
identifying information to user B protection in transit is achieved by applying the one-way function f2 of figure 3,
where the time stamp and/or random number is used to minimise replay and to conceal the password.
The information conveyed to B is of the form:
t2 a, q2 a, f2 (t2 a, q2 a, Protected1 )
*
passwA b Protected 1
fl
tl a
c
*
91 a
f2
+ Protected2
t2 a
passwA Password of A
t Timestamp
Random number
q
Figure 3 - The simple protected password function
NOTE The timer t2 should be present and be used down to seconds. The random value ql should be present and should
not rep
...