S?45EF>G  !"#)*+(,-./0123456789:;'<=>&?@ABCDEFGHIJKLMNOrqponmlkjihgfedcba`_^]\[ZYXWVUTSRQPONMILKJGEDCBA@?>F=<;:9876543210/.-,+*)('&%$#"!  2  `^BLTT TTT+ 7.4Selected AU Types 0 7.4.1Physical Delivery(7.4.2Telematic$ 7.4.3Telex+ 8.Information Model" 8.1Messages  8.2Probes !  8.3Reports + 9.Operational Model% 9.1Transmittal+ 9.2Transmittal Roles+ 9.3Transmittal Steps*JM9.3.1Origination) 9.3.2Submission% 9.3.3Import 18 o$ 9.3.3Import    ' 9.3.4Transfer 18 % 9.3.5Export 19 'J 9.3.6Delivery 19 ' 9.3.7Retrieva 19 & 9.3.8Receipt 19 ,DJ9.4Transmittal Events( 9.4.1Splitting20 & 9.4.2Joining 20 . 9.4.3Name Resolution+ 9.4.4DL Expansion * 9.4.5Redirection1 )9.4.6Conversion21 + 9.4.7Non-delivery . 9.4.8Non-affirmation* 9.4.9Affirmation1 & 9.4.10Routing 22 ( 10.Security Model22 + 10.1Security Policies + 10.2Security Services F 210.2.1Origin Authentication Security Services224>H 410.2.2Secure Access Management Security Service45>EJM110.2.3Data Confidentiality Security Services1 25>? +10.2.4Data Integrity Security Services+26>@ ,10.2.5Non-Repudiation Security Services,27>J 610.2.6Message Security Labelling Security Service6>; '10.2.7Security Management Services'28>+ 10.3Security Elements ? +10.3.1Authentication Security Elements+28>IJ 510.3.2Secure Access Management Security Elements5>EDJ110.3.3Data Confidentiality Security Elements1 30>? +10.3.4Data Integrity Security Elements+31>@ ,10.3.5Non-repudiation Security Elements,31>? +10.3.6Security Label Security Elements+31>D 010.3.7Security Management Security Elements0 32>: &10.3.8Double Enveloping Technique&32>3Section Three - Configurations33>& 11.Overview333 12.Functional Configurations33>2 12.1Regarding the Directory5 !12.2Regarding the Message Store!33>2 13.Physical Configurations+ 13.1Messaging Systems - 13.1.1Access Systems. 13.1.2Storage Systems9 %13.1.3Access and Storage Systems%36>/JM13.1.4Transfer Systems: &13.1.5Access and Transfer Systems&36>; '13.1.6Storage and Transfer Systems'36>D 013.1.7Access, Storage, and Transfer Systems037>7 #13.2Representative Configurations#37>0 13.2.1Fully CentralizedG 313.2.2Centralized Message Transfer and Storage3>; '13.2.3Centralized Message Transfer'38>0DJ13.2.4Fully Distributed7J #14.Organizational Configurations#38>, 14.1Management Domains@ ,14.1.1Administration Management Domains, 38>9 %14.1.2Private Management Domains%38>7 #14.2Representative Configurations#39>014.2.1Fully Centralized1 14.2.2Directly Connected3 14.2.3Indirectly Connected39>( 15.The Global MHS0 C /Section Four - Naming, Addressing, and Routing/" 16.Overview  17.Naming ) 17.1Directory Names# 17.2O/R Names$ 18.Addressing)JM18.1Attribute Lists( 18.2Character Sets- 18.3Standard Attributes9 %18.3.1Administration-domain-name%* 18.3.2Common-name+ 18.3.3Country-nameF 218.3.4Extension-postal-O/R-address-components2M 918.3.5Extension-physical-delivery-address-components96DJ"18.3.6Local-postal-attributes". 18.3.7Network-address6 "18.3.8Numeric-user-identifier"0J 18.3.9Organization-name8 $18.3.10Organizational-unit-names$= )18.3.11Physical-delivery-service-name)0J 18.3.9Organization-name8 $18.3.10Organizational-unit-names$!  18.3.11Phy j -name  46 ,18.3.12Personal-name= )18.3.13Physical-delivery-country-name)47>< (18.3.14Physical-delivery-office-name(47>> *18.3.15Physical-delivery-office-number*47>B .18.3.16Physical-delivery-organization-name. 47>> *18.3.17Physical-delivery-personal-name*47>6 "18.3.18Post-office-box-address"47>* 18.3.19Postal-code 5 !18.3.20Poste-restante-address!47>2 18.3.21Private-domain-name48>-JM18.3.22Street-address2 18.3.23Terminal-identifier48>, 18.3.24Terminal-type9 %18.3.25Unformatted-postal-address%48>1 18.3.26Unique-postal-name4  18.4Attribute List Equivalence 48>+ 18.5O/R Address Forms 3 18.5.1Mnemonic O/R Address50>2DJ18.5.2Numeric O/R Address51>1 18.5.3Postal O/R Address3 18.5.4Terminal O/R Address51>0 18.6Conditional Attributes!  19.Routing 8J $Section Five - Use of the Directory$54>"20.Overview( 21.Authentication4 ) 22.Name Resolution & 23.DL Expansion/ 24.Capability Assessment2 Section Six - OSI Realization" 25.Overview6 "26.Application Service Elements") 26.1The ASE Concept7 #26.2Symmetric and Asymmetric ASEs#/JM26.3Message Handling ASEs/ 26.3.1Message Transfer1 26.3.2Message Submission/ 26.3.3Message Delivery0 26.3.4Message Retrieval5 !26.3.5Message Administration!) 26.4Supporting ASEs0 26.4.1Remote Operations0DJ26.4.2Reliable Transfer2 26.4.3Association Control. 27.Application Contexts AnnexesA -ADirectory Object Classes and Attributes- 63>( A.1Object Classes4 A.1.1MHS Distribution List 0J A.1.2MHS Message Store9 %A.1.3MHS Message Transfer Agent%6 "A.1.4MHS Organizational User"3 A.1.5MHS Residential User- A.1.6MHS User Agent$ A.2Attributes= )A.2.1MHS Deliverable Content Length)< (A.2.2MHS Deliverable Content Types(  A.1.6MHS User Agent$ A.2Attributes= )A.2.1MHS Deliverable Content Length); 'A.2.2MHS Deliverable Content Types'3 A.2.3MHS Deliverable EITs EITs65 EITs65R *A.2.2MHS  EITs65y- A.2.4MHS DL MembersR65>JM Members65 8 $A.2.5MHS DL Submit Permissions$65>0 A.2.6MHS Message Store0 A.2.7MHS O/R Addresses= )A.2.8MHS Preferred Delivery Methods)66>> *A.2.9MHS Supported Automatic Actions*66>: &A.2.10MHS Supported Content Types&66>@ ,A.2.11MHS Supported Optional Attributes, 67>,DJA.3Attribute Syntaxes7 #A.3.1MHS DL Submit Permission#67>. A.3.2MHS O/R Address+ A.3.3MHS O/R Name D 0BReference Definition of Object Identifiers069>Y ECReference Definition of Directory Object Classes and AttributesE*DSecurity Threats $ D.1Masquerade 76 , D.2Message Sequencing5J !D.3Modification of Information!77>+ D.4Denial of Service % D.5Repudiation 78 0 D.6Leakage of Information' D.7Other Threats78 P <EProvision of Security Services in Recommendation X.411<S ?FDifferences Between CCITT Recommendation and ISO Standard?JM GIndex / .End Table C.&J - --/ Section One - Introduction& 0.IntroductiondJMPThis Recommendation is one of a set of Recommendations for Message Handling. TheP` Lentire set provides a comprehensive blueprint for a Message Handling System LN :(MHS) realized by any number of cooperating open systems.:W CThe purpose of an MHS is to enable users to exchange messages on a C0]DJIreport;s to users. Generated by the MTS, a report relates the outcome or I; 'of a message's or probe's transmittal.'d PThe message or probe that is the subject of a report is called its .I.gl:subjectP6 "message; or .I.gl:subject probe;."\ HA report concerning a JMe%* 18.3.2Common-name+ 18.3.3Country-nameF 218.3.4Extea" standardized.;4 7.1Primary Functional Objects b NThe MHE comprises the Message Handling System, users, and distribution lists. N` LThese primary functional objects interact with one another. Their types are L1 defined and described below.ling Systemsb NThis Recommendation and others in the set cite the following Message Handling N+System specifications:8 $T.330Telematic access to IPMS.$d PX.400Message handling: Service and system overview (see also ISO 10021-1).PM 9X.403Message handling systems: Conformance testing.9b NX.407Message handling systems: Abstract service definition conventions N208Specification of abstract syntax notation one (ASN.1) (see alsoI  ISO 8824). .d PX.209Specification of basic encoding rules for abstract syntax notation oneP1 (ASN.1) (see also ISO 8825)..'[ GX.217Association control: Service definition (see also ISO 8649).Ga MX.218Reliable transfer: Model and service definition (see also M!JM ISO 9066- &signed-data within the Message Token.&b NThC /corresponding ISO specification is ISO 8505-2./g  1.Scope d PThis Recommendation defines the overall architecture of the MHS and serves as a P2 technical introduction to it.` LOther aspects of Message Handling are specified in other Recommendations. A Ld Pnon-technical overview of Message Handling i\ Hstore-and-forward basis. A message submitted on behalf of one user, the Hb Noriginator, is conveyed by the Message Transfer System (MTS) and subsequently NdDJPdelivered to the agents of one or more additional users, the recipients. Access Pc Ounits (AUs) link the MTS to communication systems of other kinds (e.g., postal O] Isystems). A user is assisted in the preparation, storage, and display of I` Lmessages by a user agent (UA). Optionally, he is assisted in the storage of Ld Pmessages by a message store (MS). The MTS comprises a number of message transferPd Pagents (MTAs) which collectively perform the store-and-forward message transfer P function. d PThis Recommendation specifies the overall architecture of the MHS and serves as P4  a technical introduction to it. d PThe text of this Recommendation is the subject of joint CCITT-ISO agreement. ThePD 0corresponding ISO specification is ISO 10021-2.0`  1.Scope d PThis Recommendation defines the overall architecture of the MHS and serves as a P2 technical introduction to it.` LOther aspects of Message Handling are specified in other Recommendations. A Ld Pnon-technical overview of Message Handlings provided by Recommendation X.400. Pd PThe conformance testing of MHS components is described in Recommendation X.403. PdJ PThe conventions used in the definition of the abstract services provided by MHS PdJMPcomponents are defined in Recommendation X.407. The detailed rules by which the Pa MMTS converts the contents of messages from one EIT to another are defined in Mc ORecommendation X.408. The abstract service the MTS provides and the procedures Oc Othat govern its distributed operation are defined in Recommendation X.411. The O] Iabstract service the MS provides is defined in Recommendation X.413. The I] Iapplication protocols that govern the interactions of MHS components are I^DJJspecified in Recommendation X.419. The Interpersonal Messaging System, an Jc Oapplication of Message Handling, is defined in Recommendation X.420. Telematic O` Laccess to the Interpersonal Messaging System is specified in Recommendation L T.330.b NThe CCITT Recommendations and ISO International Standards on Message Handling N5 !are summarized in Table 1/X.402.!R>Table .T.:1/X.402 Specifications for Message Handling Systems>d P+-------+--------+-------------------------------------------+ | CCITT | ISO PR >| SUBJECT MATTER | +- Introduction >b N-+-------------------------------------------+ | X.400 | 8505-1 | Service and Nd Psystem overview | | X.402 | 8505-2 | Overall architecture Pd P | +- Various Aspects ------------------------------------------+ | Pd PX.403 | - | Conformance testing | | X.407 | 8883-2 | P[ GAbstract service definition conventions | | X.408 | - | Encoded GM 9information type conversion rules | +- Abstract Services 9^ J----------------------------------------+ | X.411 | 8883-1 | MTS Abstract Jc OService definition and | | procedures for distributed Od Poperation | | X.413 | TBS-1 | MS Abstract Service definition | +-PcJMOProtocols ----+-------------------------------------------+ | X.419 | 8505-2 | ObJ NProtocol specifications | +- Interpersonal Messaging System Nd P---------------------------+ | X.420 | 9065 | Interpersonal Messaging System P_ K | | T.330 | - | Telematic access to IPMS | KS ?+-------+--------+-------------------------------------------+?_ KThe Directory, the principal means for disseminating communication-related KUDJAinformation among MHS components, is defined in the X.500-series AE 1Recommendations, as summarized in Table 2/X.402.1E 1Table .T.:2/X.402 Specifications for Directories1a M+-------+--------+--------------------------------------+ | CCITT | ISO | MD 0SUBJECT MATTER | +- Model 0\ H--------+--------------------------------------+ | X.200 | 7498 | OSI H7#Reference Model | #a M+-------+--------+--------------------------------------+ | X.500 | 9594-1 | Md POverview | | X.501 | 9594-2 | Models Pa M | | X.509 | 9594-8 | Authentication framework | | M_ KX.511 | 9594-3 | Abstract service definition | | X.518 | 9594-4 | KW CProcedures for distributed operation | | X.519 | 9594-5 | Protocol Cd Pspecifications | | X.520 | 9594-6 | Selected attribute types PV B | | X.521 | 9594-7 | Selected object classes | BN :+-------+--------+--------------------------------------+:a MThe architectural foundation for Message Handling is provided by still other Md PRecommendations. The OSI Reference Model is defined in Recommendation X.200. ThePd Pnotation for specifying the data structures of abstract services and applicationPWJMCprotocols, ASN.1, and the associated encoding rules are defined in C^ JRecommendations X.208 and X.209. The means for establishing and releasing Jd Passociations, the ACSE, is defined in Recommendations X.217 and X.227. The meansP\J Hfor reliably conveying APDUs over associations, the RTSE, is defined in Ha MRecommendations X.218 and X.228. The means for making requests of other open MV Bsystems, the ROSE, is defined in Recommendations X.219 and X.229.B^DJJThe CCITT Recommendations and ISO International Standards foundational to JF 2Message Handling are summarized in Table 3/X.402.2I 5Table .T.:3/X.402 Specifications for MHS Foundations5a M+-------+--------+--------------------------------------+ | CCITT | ISO | MD 0SUBJECT MATTER | +- Model 0\ H--------+--------------------------------------+ | X.200 | 7498 | OSI H@,Reference Model | +- ASN.1 ,a M--------+--------------------------------------+ | X.208 | 8824 | Abstract Md Psyntax notation | | X.209 | 8825 | Basic encoding rules Pd P | +- Association Control ---------------------------------+ | X.217 | 8649P[ G | Service definition | | X.227 | 8650 | Protocol GG 3specification | +- Reliable Transfer 3d P-----------------------------------+ | X.218 | 9066/1 | Service definition P` L | | X.228 | 9066/2 | Protocol specification | +- L^ JRemote Operations -----------------------------------+ | X.219 | 9072/1 | Jd PService definition | | X.229 | 9072/2 | Protocol specificationP^ J | +-------+--------+--------------------------------------+Jd PThis Recommendation is structured as follows. Section one is this introduction. P\JMHSection two presents abstract models of Message Handling. Section three H[ Gspecifies how one can configure the MHS to satisfy any of a variety of Gb Nfunctional, physical, and organizational requirements. Section four describes Na Mthe naming and addressing of users and distribution lists and the routing of Md Pinformation objects to them. Section five describes the uses the MHS may make ofPbJ Nthe Directory. Section six describes how the MHS is realized by means of OSI. NHDJ4Annexes provide important supplemental information.4X DNo requirements for conformance to this Recommendation are imposed.D$ 2.ReferencesX DThis Recommendation and others in the set cite the documents below.D6 "2.1Open Systems Interconnection"U AThis Recommendation and others in the set cite the following OSI A$specifications:I 5X.200Basic reference model.(see also ISO 7498).5] IX.1). .a MX.219Remote operations: Model, notation and service definition (see alsoM!  ISO 9072-1). ._ KX.227Association control: Protocol specification (see also ISO 8650).K_ KX.228Reliable transfer: Protocol specification (see also ISO 9066-2).K_ KX.229Remote operations: Protocol specification (see also ISO 9072-2).K* 2.2 Directory SystemsbJMNThis Recommendation and others in the set cite the following Directory System NG 3specifications: of concepts, models, and service.)3N :X.500The directory Overview (see also ISO 9594-1).:L 8X.501The directory Models (see also ISO 9594-2).8^ JX.509The directory Authentication framework (see also ISO 9594-8).Ja MX.511The directory Abstract service definition (see also ISO 9594-3).M]DJIX.518The directory Procedures for distributed operation (see alsoI!  ISO 9594-4). ^^^^^ISO 9594-4).']J IX.519The directory Protocol specifications (see also ISO 9495-5).I^ JX.520The directory Selected attribute types (see also ISO 9495-6).J] IX.521The directory Selected object classes (see also ISO 9495-7).I2 2.3Message Hand,JM(see also ISO 10021-3).c OX.408Message handling systems: Encoded information type conversion rules.Ob NX.411Message handling systems: Message transfer system: Abstract service NF 2definition and procedures (see also ISO 10021-4).2d PX.413Message handling systems: Message store: Abstract service definition P, (see also ISO 1002105).Z FX.419Message handling systems: Protocol specifications (see alsoF" ISO 10021-6).a MX.420Message handling systems: Interpersonal messaging system (see alsoM" ISO 10021-7).  definition.PQ =X.419Message handling systems: Protoco X DX.420Message handling systems: Interpersonal  &% 3.DefinitionscJMOFor the purposes of this Recommendation and others in the set, the definitions O!  below apply. 6 "3.1Open Systems Interconnection"a MThis Recommendation and others in the set use the following terms defined in Md PRecommendation X.200, as well as the names of the seven layers of the Reference P Model:*DJa)abstract syntax;9 %b)application entity (.I.ab:AE;);%. c)application process;GJ 3d)application protocol data unit (.I.ab:APDU;);3C /e)application service element (.I.ab:ASE;);/B .f)distributed information processing task;.  g)layer; & h)open system;D 0i)Open Systems Interconnection (.I.ab:OSI;);0  j)peer; / k)presentation context;# l)protocol;* m)Reference Model;. n)transfer syntax; and3 o)user element (.I.ab:UE;).a MThis Recommendation and others in the set use the following terms defined in Mb NRecommendations X.208 and X.209, as well as the names of ASN.1 data types and N values:FJM2a)Abstract Syntax Notation One (.I.ab:ASN.1;);2/ b)Basic Encoding Rules;# c)explicit;!  d)export; # e)implicit;!  f)import;  DJ g)macro; !  h)module;   i)tag; # j)type; and  k)value. aJ MThis Recommendation and others in the set use the following terms defined in M*Recommendation X.217:? +a)application association; association;+: &b)application context (.I.ab:AC;);&L 8c)Association Control Service Element (.I.ab:ACSE;);8( d)initiator; and$ e)responder.a MThis Recommendation and others in the set use the following terms defined in M* Recommendation X.218:< (a)Reliable Transfer (.I.ab:RT;); and(J 6b)Reliable Transfer Service Element (.I.ab:RTSE;).6a MThis Recommendation and others in the set use the following terms defined in M* Recommendation X.219:#JMa)argument;' b)asynchronous;  c)bind; $ d)parameter;' e)remote error;+ f)remote operation;8DJ$g)Remote Operations (.I.ab:RO;);$J 6h)Remote Operations Service Element (.I.ab:ROSE;);6!  i)result; * j)synchronous; and!  k)unbind. + 3.2Directory SystemsdPThis Recommendation and others in the set use the following terms defined in theP2J X.500-series Recommendations:$ a)attribute;& b)certificate;2 c)certification authority;- d)certification path;1 e)directory entry; entry;> *f)directory system agent (.I.ab:DSA;);*$ g)Directory;( h)hash function;  i)name; ' j)object class;!JM k)object; 4  l)simple authentication; and 0 m)strong authentication.2 3.3Message Handling Systemsc OFor the purposes of this Recommendation and others in the set, the definitions O. indexed in annex G apply.'DJ4.Abbreviationsd PFor the purposes of this Recommendation and others in the set, the abbreviationsP. indexed in annex G apply.% 5.Conventions[ GThis Recommendation uses the descriptive conventions identified below.G  5.1ASN.1 dPThis Recommendation uses several ASN.1-based descriptive conventions in annexes Pb NA and C to define the Message Handling-specific information the Directory may Nc Ohold. In particular, it uses the OBJECT-CLASS, ATTRIBUTE, and ATTRIBUTE-SYNTAX O^J Jmacros of Recommendation X.501 to define Message Handling-specific object JA -classes, attributes, and attribute syntaxes.-\ HASN.1 appears both in annex A to aid the exposition, and again, largely Hd Predundantly, in annex C for reference. If differences are found between the two,P8 $a specification error is indicated.$_ KNote that ASN.1 tags are implicit throughout the ASN.1 module that annex C KG 3defines; the module is definitive in that respect.3  5.2Grade ` LWhenever this Recommendation describes a class of data structure (e.g., O/R LdJMPaddresses) having components (e.g., attributes), each component is assigned one P4  of the following .I.gl:grade;s: ` La).I.gl:mandatory; (.I.ab:M;): A mandatory component shall be present in L1 every instance of the class.b Nb).I.gl:optional; (.I.ab:O;): An optional component shall be present in an Na Minstance of the class at the discretion of the object (e.g., user) supplying M>DJ*that instance. There is no default value.*d Pc).I.gl:defaultable; (.I.ab:D;): A defaultable component shall be present in Pd Pan instance of the class at the discretion of the object (e.g., user) supplying Pd Pthat instance. In its absence a default value, specified by this Recommendation,P  applies. d Pd).I.gl:conditional; (.I.ab:C;): A conditional component shall be present in PQ=an instance of the class as dictated by this Recommendation.=  5.3Terms d PThroughout the remainder of this Recommendation, terms are rendered in bold whenPd Pdefined, in italic when referenced prior to their definitions, without emphasis P* upon other occasions.XJ DTerms that are proper nouns are capitalized, generic terms are not.D  n Two - Abstract Models-address-syntax; ATTRIBUTE-SYNTAX SYNTAX ORAddress LJ 6MATCHES FOR EQUALITY ::= id-as-mhs-or-address6$DJ-- MHS O/R Named \q task that JN :integrates the following intrinsically related sub-tasks::d Pa).I.gl:Message Transfer;: The non-real-time carriage of information objects PG 3between parties using computers as intermediaries.3^DJJb).I.gl:Message Storage;: The automatic storage for later retrieval of JO ;information objects conveyed by means of Message Transfer.;> *This section covers the following topics:** a)Functional model+ b)Information model+ c)Operational model(d)Security model[ GNote Message Handling has a variety of applications, one of which is GP <Interpersonal Messaging, described in Recommendation X.420.<* 7.Functional Model^ JThis clause provides a functional model of Message Handling. The concrete Ja Mrealization of the model is the subject of other Recommendations in the set.M] IThe .I.gl:Message Handling Environment; (.I.ab:MHE;) comprises "primary" Ic Ofunctional objects of several types, the Message Handling System (MHS), users, O[ Gand distribution lists. The MHS in turn can be decomposed into lesser, GaJ M"secondary" functional objects of several types, the Message Transfer System Ma M(MTS), user agents, message stores, and access units. The MTS in turn can be Mb Ndecomposed into still lesser, "tertiary" functional objects of a single type, N-JMmessage transfer agents.d PThe primary, secondary, and tertiary functional object types and selected accessPM 9unit types are individually defined and described below.9` LAs detailed below, functional objects are sometimes tailored to one or more LY Eapplications of Message Handling, e.g., Interpersonal Messaging (see Ed PRecommendations X.420 and T.330). A functional object that has been tailored to PdDJPan application understands the syntax and semantics of the contents of messages P3 exchanged in that application.] IAs a local matter, functional objects may have capabilities beyond those Id Pspecified in this Recommendation or others in the set. In particular, a typical Pa Muser agent has message preparation, rendition, and storage capabilities that M* are not standardized.,JMnot standardized.b NThe MHE comprises the Message Handling System, users, and distribution lists. N` LThese prima\ Huser agent has message preparation, are&JMnot standardized.A -The situation is depicted in Figure 1/X.402.-c O+----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 | | 08 | | 09 | | 10 | | Od P11 | | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20 | | 21 | | 22 PN :| | 23 | | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+:H 4Figure .F.:1/X.402 The Message Handling Environment4: &7.1.1The Message Handling System&d PThe principal purpose of Message Handling is to convey information objects from PZJ Fone party to another. The functional object by means of which this is F\JMHaccomplished is called the .I.gl:Message Handling System; (.I.ab:MHS;).H4  The MHE comprises a single MHS. $ 7.1.2Usersd PThe principal purpose of the MHS is to convey information objects between users.P` LA functional object (e.g., a person) that engages in (rather than provides) L> *Message Handling is called a .I.gl:user;.*CDJ/The following kinds of user are distinguished:/c Oa).I.gl:direct user;: A user that engages in Message Handling by direct use O  of the MHS. c Ob).I.gl:indirect user;: A user that engages in Message Handling by indirect O_ Kuse of the MHS, i.e., through another communication system (e.g., a postal KM 9system or the telex network) to which the MHS is linked.9;'The MHE comprises any number of users.'1 7.1.3Distribution Lists_ KBy means of the MHS a user can convey information objects to pre-specified K_ Kgroups of users as well as to individual users. The functional object that KX Drepresents a pre-specified group of users and other DLs is called a D: &.I.gl:distribution list; (.I.ab:DL;).&d PA DL identifies zero or more users and DLs called its .I.gl:members;. The latterP[ GDLs (if any) are said to be .I.gl:nested;. Asking the MHS to convey an Ga Minformation object (e.g., a message) to a DL is tantamount to asking that it MS ?convey the object to its members. Note that this is recursive.?[ GThe right, or permission, to convey messages to a particular DL may be Gd Pcontrolled. This right is called .I.gl:submit permission;. As a local matter theP;JM'use of a DL can be further restricted.'9J %The MHE comprises any number of DLs.%d PNote A DL might be further restricted, e.g., to the conveyance of messages of P/ a prescribed content type.6 "7.2Secondary Functional Objects"d PThe MHS comprises the Message Transfer System, user agents, message stores, and P`DJLaccess units. These secondary functional objects interact with one another. LA -Their types are defined and described below.-A -The situation is depicted in Figure 2/X.402.-c O+----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 | | 08 | | 09 | | 10 | | Od P11 | | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20 | | 21 | | 22 PN :| | 23 | | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+:C/Figure .F.:2/X.402 The Message Handling System/: &7.2.1The Message Transfer System&b NThe MHS conveys information objects to individual users and to the members of Nc ODLs. The functional object that actually does this is called the .I.gl:Message O` LTransfer System; (.I.ab:MTS;). The MTS is a store-and-forward communication LJ 6system and can be considered the backbone of the MHS.6a MThe MTS is general-purpose, supporting all applications of Message Handling. Md PAdditionally, the MTS may be tailored to one or more particular applications so P1 it can carry out conversion.4  The MHS comprises a single MTS. * 7.2.2User Agentsd PThe functional object by means of which a single direct user engages in Message PHJM4Handling is called a .I.gl:user agent; (.I.ab:UA;).4_ KA typical UA is tailored to one or more particular applications of Message K  Handling. 9J %The MHS comprises any number of UAs.%b NNote A UA that serves a human user typically interacts with him by means of NZ Finput/output devices (e.g., a keyboard, display, scanner, printer, or F+DJcombination of these).- 7.2.3Message Storesb NA typical user must store the information objects it receives. The functional N^ Jobject that provides a (single) direct user with capabilities for Message Jd PStorage is called a .I.gl:message store; (.I.ab:MS;). Each MS is associated withPC /one UA, but not every UA has an associated MS./bNEvery MS is general-purpose, supporting all applications of Message Handling. Nb NAdditionally, an MS may be tailored to one or more particular applications so Nd Pthat it can more capably submit and support the retrieval of messages associatedP+ with that application.9 %The MHS comprises any number of MSs.%c ONote As a local matter a UA may provide for information objects storage that OB .either supplements or replaces that of an MS..+ 7.2.4Access Unitsb NThe functional object that links another communication system (e.g., a postal N` Lsystem or the telex network) to the MTS and via which its patrons engage in Ld PMessage Handling as indirect users is called an .I.gl:access unit; (.I.ab:AU;).Pd PA typical AU is tailored to a particular communication system and to one or morePAJM-particular applications of Message Handling.-9 %The MHS comprises any number of AUs.%5 !7.3Tertiary Functional Objects!a MThe MTS comprises message transfer agents. These tertiary functional objects MI 5interact. Their type is defined and described below.5AJ -The situation is depicted in Figure 3/X.402.-cDJO+----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 | | 08 | | 09 | | 10 | | Od P11 | | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20 | | 21 | | 22 PN :| | 23 | | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+:C /Figure .F.:3/X.402 The Message Transfer System/6 "7.3.1Message Transfer Agents"` LThe MTS conveys information objects to users and DLs in a store-and-forward LdPmanner. A functional object that provides one link in the MTS' store-and-forwardPR >chain is called a .I.gl:message transfer agent; (.I.ab:MTA;).>c OEvery MTA is general-purpose, supporting all applications of Message Handling. Oc OAdditionally, an MTA may be tailored to one or more particular applications so O1 it can carry out conversion.: &The MTS comprises any number of MTAs.&+ 7.4Selected AU Typesd PAs described above, the MHS interworks with communication systems of other typesPd Pvia AUs. Several selected AU types--physical delivery, telematic, and telex--areP5 !introduced in the clauses below.!0 7.4.1Physical Delivery` LA .I.gl:physical delivery access unit; (.I.ab:PDAU;) is an AU that subjects LdJMPmessages (but neither probes nor reports) to physical rendition and that conveysPS ?the resulting physical messages to a physical delivery system.?d PThe transformation of a message into a physical message is called .I.gl:physicalPc Orendition;. A .I.gl:physical message; is a physical object (e.g., a letter and OA -its paper envelope) that embodies a message.-] IA .I.gl:physical delivery system; (.I.ab:PDS;) is a system that performs IcDJOphysical delivery. One important kind of PDS is postal systems. .I.gl:Physical OcJ Odelivery; is the conveyance of a physical message to a patron of a PDS, one of Oa Mthe indirect users to which the PDAU provides Message Handling capabilities.MZ FAmong the applications of Message Handling supported by every PDAU is FH 4Interpersonal Messaging (see Recommendation X.420).4( 7.4.2TelematiccOTelematic access units, which support Interpersonal Messaging exclusively, are O8 $introduced in Recommendation X.420.$$ 7.4.3Telex_ KTelex access units, which support Interpersonal Messaging exclusively, are K8 $introduced in Recommendation X.420.$+ 8.Information Model` LThis clause provides an information model of Message Handling. The concrete La Mrealization of the model is the subject of other Recommendations in the set.M_ KThe MHS and MTS can convey information objects of three classes: messages, K_ Kprobes, and reports. These classes are listed in the first column of Table K] I4/X.402. For each listed class, the second column indicates the kinds of I^ Jfunctional objects--users, UAs, MSs, MTAs, and AUs--that are the ultimate J?JM+sources and destinations for such objects.+E 1Table .T.:4/X.402 Conveyable Information Objects1^ J+---------+-------------------+ | Infor- | Functional Object | | mation JJ 6+-------------------+ | Object | user UA MS MTA AU | 6d P+---------+-------------------+ | message | SD - - - - | | probe | S Pd P - - D - | | report | D - - S - | +---------+-------------------+ PdDJP +- Legend ---------------+ | S ultimate source | | D ultimate destination P1 | +------------------------+c OThe information objects, summarized in the table, are individually defined and O4J  described in the clauses below. " 8.1Messagesd PThe primary purpose of Message Transfer is to convey information objects called PcO.I.gl:message;s from one user to others. A message has the following parts, as O0 depicted in Figure 4/X.402:b Na).I.gl:envelope;: An information object whose composition varies from one N\ Htransmittal step to another and that variously identifies the message's H_ Koriginator and potential recipients, documents its previous conveyance and Ka Mdirects its subsequent conveyance by the MTS, and characterizes its content.Ma Mb).I.gl:content;: An information object that the MTS neither examines nor M[ Gmodifies, except for conversion, during its conveyance of the message.Gc O+----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 | | 08 | | 09 | | 10 | | Od P11 | | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20 | | 21 | | 22 PN :| | 23 | | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+:H 4Figure .F.:4/X.402 A Message's Envelope and Content4^JMJOne piece of information borne by the envelope identifies the type of the Jd Pcontent. The .I.gl:content type; is an identifier (an ASN.1 Object Identifier orP` LInteger) that denotes the syntax and semantics of the content overall. This L\ Hidentifier enables the MTS to determine the message's deliverability to Hd Pparticular users, and enables UAs and MSs to interpret and process the content.P_ KAnother piece of information borne by the envelope identifies the types of KaDJMencoded information represented in the content. An .I.gl:encoded information Md Ptype; (.I.ab:EIT;) is an identifier (an ASN.1 Object Identifier or Integer) thatP[ Gdenotes the medium and format (e.g., IA5 text or Group 3 facsimile) of Gd Pindividual portions of the content. It further enables the MTS to determine the Pd Pmessage's deliverability to particular users, and to identify opportunities for PcJ Oit to make the message deliverable by converting a portion of the content from O(one EIT to another.  8.2Probes a MA second purpose of Message Transfer is to convey information objects called Mb N.I.gl:probe;s from one user up to but just short of other users (i.e., to the Nc OMTAs serving those users). A probe describes a class of message and is used to OC /determine the deliverability of such messages./Y EA message described by a probe is called a .I.gl:described message;.E^ JA probe comprises an envelope alone. This envelope contains much the same Jd Pinformation as that for a message. Besides bearing the content type and encoded Pd Pinformation types of a described message, the probe's envelope bears the length P$ of its content.` LThe submission of a probe elicits from the MTS largely the same behavior as LdJMPwould submission of any described message, except that DL expansion and deliveryP\ Hare forgone in the case of the probe. In particular, and apart from the Ha Mconsequences of the suppression of DL expansion, the probe provokes the same Mb Nreports as would any described message. This fact gives probes their utility.N!  8.3Reports a MA third purpose of Message Transfer is to convey information objects called MdDJPreports to users. Generated by the MTS, a report relates the outcome or progressP^ Jof a message's or probe's transmittal to one or more potential recipient.Je or probe that is the subject of a report is called its .I.gl:subjectP6 "message; or .I.gl:subject probe;."\ HA report concerning Pparticular potential recipient is conveyed to the Hc Ooriginator of the subject message or probe unless the potential recipient is a OdPmember recipient. In the latter case, the report is conveyed to the DL of which PdJ Pthe member recipient is a member. As a local matter (i.e., by policy establishedPc Ofor that particular DL), the report may be further conveyed to the DL's owner; Oc Oeither to another, containing DL (in the case of nesting) or to the originator OJ 6of the subject message or probe (otherwise); or both.6\ HThe outcome that a single report may relate are of the following kinds:Ha Ma).I.gl:delivery report;: delivery, export, or affirmation of the subject M7 #message or probe, or DL expansion.#d Pb).I.gl:non-delivery report;: non-delivery or non-affirmation of the subject P& al "h 'A message or probe may provoke several 'ng a particular potential I potential IP9 %different transmittal step or event.%#ent transmittal step or event.L+JM9.Operational Model` LThis clause provides an operational model of Message Handling. The concrete La Mrealization of the model is the subject of other Recommendations in the set.Mc OThe MHS can convey an information object to individual users, DLs, or a mix of O] Ithe two. Such conveyance is accomplished by a process called transmittal Ib Ncomprising steps and events. The process, its parts, and the roles that users NHDJ4and DLs play in it are defined and described below.4% 9.1Transmittal[ GThe conveyance or attempted conveyance of a message or probe is called G` L.I.gl:transmittal;. Transmittal encompasses a message's conveyance from its L^ Joriginator to its potential recipients, and a probe's conveyance from its Jd Poriginator to MTAs able to affirm the described messages' deliverability to the PaMprobe's potential recipients. Transmittal also encompasses the conveyance or Mc Oattempted conveyance to the originator of any reports the message or probe may O  provoke. ZJ FA transmittal comprises a sequence of transmittal steps and events. A Fd P.I.gl:transmittal step; (or .I.gl:step;) is the conveyance of a message, probe, PX Dor report from one functional object to another "adjacent" to it. A Dd P.I.gl:transmittal event; (or .I.gl:event;) is processing of a message, probe, orPa Mreport within a functional object that may influence the functional object's ME 1selection of the next transmittal step or event.1b NThe information flow of transmittal is depicted in Figure 5/X.402. The figure Nc Oshows the kinds of functional objects--direct users, indirect users, UAs, MSs, OZ FMTAs, and AUs--that may be involved in a transmittal, the information FcJMOobjects--messages, probes, and reports--that may be conveyed between them, and O_ Kthe names of the transmittal steps by means of which those conveyances are K" accomplished.^ JThe figure highlights the facts that a message or report may be retrieved Jc Orepeatedly and that only the first conveyance of a retrieved object from UA to O. user constitutes receipt.cDJO+----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 | | 08 | | 09 | | 10 | | Od P11 | | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20 | | 21 | | 22 PY E| | 23 | | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+ +- Legend Ed P----------------------------------+ | M message ORG origination EXP export Pb N| | P probe SBM submission DLV delivery | | R report IMP import NR >RTR retrieval | | TRN transfer REC receipt | >B.+-------------------------------------------+.K 7Figure .F.:5/X.402 The Information Flow of Transmittal7` LOne event plays a distinguished role in transmittal. Splitting replicates a Lc Omessage or probe and divides responsibility for its immediate recipients among Ob Nthe resulting information objects. The potential recipients associated with a N]J Iparticular instance of a message or probe are called the .I.gl:immediate Id Precipient;s. An MTA stages a splitting if the next step or event required in thePd Pconveyance of a message or probe to some immediate recipients differs from that Pb Nrequired in its conveyance to others. Each of the step and event descriptions Na Mwhich follow assumes that the step or event is appropriate for all immediate M] Irecipients, a situation that can be created, if necessary, by splitting.I+ 9.2Transmittal RolesaJMMUsers and DLs play a variety of roles in a message's or probe's transmittal. Mc OThese roles are informally categorized as "source" roles, "destination" roles, OG 3or statuses to which users or DLs can be elevated.3c OA user may play the following "source" role in the transmittal of a message or O probe:c Oa).I.gl:originator;: The user (but not DL) that is the ultimate source of a O&DJmessage or probe.Z FA user or DL may play any of the following "destination" roles in the F7 #transmittal of a message or probe:#\ Ha).I.gl:intended recipient;: One of the users and DLs the originator HO ;specifies as a message's or probe's intended destinations.;d Pb).I.gl:originator-specified alternate recipient;: The user or DL (if any) toPcOwhich the originator requests that a message or probe be conveyed if it cannot OD 0be conveyed to a particular intended recipient.0d Pc).I.gl:member recipient;: A user or DL to which a message (but not a probe) P= )is conveyed as a result of DL expansion.)c Od).I.gl:recipient-assigned alternate recipient;: The user or DL (if any) to Od Pwhich an intended, originator-specified alternate, or member recipient may have P2 elected to redirect messages.]J IA user or DL may attain any of the following statuses in the course of a I6 "message's or probe's transmittal:"^ Ja).I.gl:potential recipient;: Any user or DL to (i.e., toward) which a J` Lmessage or probe is conveyed at any point during the course of transmittal. LX DNecessarily an intended, originator-specified alternate, member, or D<JM(recipient-assigned alternate recipient.(b Nb).I.gl:actual recipient; (or .I.gl:recipient;): A potential recipient for N? +which delivery or affirmation takes place.++ 9.3Transmittal Steps_ KThe kinds of steps that may occur in a transmittal are listed in the first K_ Kcolumn of Table 5/X.402. For each listed kind, the second column indicates KbDJNwhether this Recommendation and others in the set standardize such steps, the Nb Nthird column the kinds of information objects--messages, probes, and reports--Nc Othat may be conveyed in such a step, the fourth column the kinds of functional Oof functional --users, UAs, MSs, MTAs, and AUs--that may participate in such a step as P8 $thB .that may be conveyed in such a step, the fourt.?3 column the kinds of functional ction apply OdPto the "creation" of messages and probes, those in the last to the "disposal" ofP_ Kmessages and reports, and those in the middle section to the "relaying" of K3 messages, probes, and reports.8 $Table .T.:5/X.402 Transmittal Steps$d P+------------------+--------+-------------+-------------------+ | Pd P | | Information | Functional | | | Stand- | PP <Objects | Objects | | | ard- <d P+-------------+-------------------+ | Transmittal Step | ized? | M P R | P( user UA MS MTA AU | dJ P+------------------+--------+-------------+-------------------+ | origination Pd P | No | x x - | S D - - - | | submission | Yes | xP3  x - | - S SD D - | dJMP+------------------+--------+-------------+-------------------+ | import Pd P | No | x x x | - - - D S | | transfer | Yes | xPd P x x | - - - SD - | | export | No | x x x | - Pd P- - S D | +------------------+--------+-------------+-------------------+ |Pd Pdelivery | Yes | x - x | - D D S - | | retrieval Pd P | Yes | x - x | - D S - - | | receipt | No | x P2DJ - x | D S - - - | _ K+------------------+--------+-------------+-------------------+ +- Legend Kb N------------------------------+ | M message S source x permitted | | P Nd Pprobe D destination | | R report | P> *+---------------------------------------+*^ JThe kinds of transmittal steps, summarized in the table, are individually J@,defined and described in the clauses below.,* 9.3.1Originationc OIn an .I.gl:origination; step, either a direct user conveys a message or probe Oc Oto its UA, or an indirect user conveys a message or probe to the communication Od Psystem that serves it. This step gives birth to the message or probe and is the P3 first step in its transmittal.b NThe user above constitutes the message's or probe's originator. In this step, N\ Hthe originator identifies the message's or probe's intended recipients. Ha MAdditionally, for each intended recipient, the originator may (but need not) MJ 6identify an originator-specified alternate recipient.6) 9.3.2SubmissioncJ OIn a .I.gl:submission; step, a message or probe is conveyed to an MTA and thus OUJMAentrusted to the MTS. Two kinds of submission are distinguished:Ad Pa).I.gl:indirect submission;: A transmittal step in which the originator's UAP\ Hconveys a message or probe to its MS and in which the MS effects direct HA -submission. Such a step follows origination.-Y EThis step may be taken only if the user is equipped with an MS.Ec Ob).I.gl:direct submission;: A transmittal step in which the originator's UA OcDJOor MS conveys a message or probe to an MTA. Such a step follows origination or O; 'occurs as part of indirect submission.'` LThis step may be taken whether or not the user is equipped with an MS.L[ GIndirect and direct submission are functionally equivalent except that Gb Nadditional capabilities may be available with the former. Indirect submission Nb Nmay differ from direct submission in other respects (e.g., the number of open NaMsystems with which that embodying a UA must interact) and for that reason be M5 !preferable to direct submission.!^ JThe UA or MS involved in direct submission is called the .I.gl:submission JX Dagent;. A submission agent is made known to the MTS by a process of Dd Pregistration, as a result of which the submission agent and MTS keep one anotherPd Pinformed of their names, their locations, and any other characteristics requiredP+ for their interaction.% 9.3.3Importc OIn an .I.gl:import; step, an AU conveys a message, probe, or report to an MTA. OY EThis step injects into the MTS an information object born in another EU Acommunication system, and follows its conveyance by that system.A` LNote The concept of importing is a generic one. How this step is effected LGJM3varies, of course, from one type of AU to another.3'J 9.3.4Transfer^ JIn a .I.gl:transfer; step, one MTA conveys a message, probe, or report to Jd Panother. This step transports an information object over physical and sometimes Pa Morganizational distances and follows direct submission, import, or (a prior) M  transfer. _DJKThis step may be taken, of course, only if the MTS comprises several MTAs.Kd PThe following kinds of transfer are distinguished, on the basis of the number ofP" MDs involved:a Ma).I.gl:internal transfer;: A transfer involving MTAs within a single MD.M_ Kb).I.gl:external transfer;: A transfer involving MTAs in different MDs.K% 9.3.5ExportcOIn an .I.gl:export; step, an MTA conveys a message, probe, or report to an AU. OZ FThis step ejects from the MTS an information object bound for another F] Icommunication system. It follows direct submission, import, or transfer.IR >As part of this step, the MTA may generate a delivery report.>` LNote The concept of exporting is a generic one. How this step is effected LG 3varies, of course, from one type of AU to another.3' 9.3.6Deliveryb NIn a .I.gl:delivery; step, an MTA conveys a message or report to an MS or UA. N\ HThe MS and UA are those of a potential recipient of the message, or the H` Loriginator of the report's subject message or probe. This step entrusts the LZ Finformation object to a representative of the user and follows direct Fb Nsubmission, import, or transfer. It also elevates the user in question to the N3JMstatus of an actual recipient.d PAs part of this step, in the case of a message, the MTA may generate a delivery P report.cJ OThe MS or UA involved is called the .I.gl:delivery agent;. A delivery agent is Oa Mmade known to the MTS by a process of registration, as a result of which the M[ Gdelivery agent and MTS keep one another informed of their names, their G]DJIlocations, and any other characteristics required for their interaction.I( 9.3.7Retrievalc OIn a .I.gl:retrieval; step, a user's MS conveys a message or report to its UA. Od PThe user in question is an actual recipient of the message or the originator of P\ Hthe subject message or probe. This step non-destructively retrieves the H] Iinformation object from storage. This step follows delivery or (a prior) I retrieval. T @This step may be taken only if the user is equipped with an MS.@& 9.3.8Receiptd PIn a .I.gl:receipt; step, either a UA conveys a message or report to its direct Pc Ouser, or the communication system that serves an indirect user conveys such an Od Pinformation object to that user. In either case, this step conveys the object toP. its ultimate destination.c OIn the case of a direct user, this step follows the object's delivery or first Ob Nretrieval (only). In the case of an indirect user, it follows the information N` Lobject's conveyance by the communication system serving the user. In either Lc Ocase, the user is a potential recipient (and, in the case of a direct user, an Oc Oactual recipient) of the message in question, or the originator of the subject O&JMmessage or probe., 9.4Transmittal Events` LThe kinds of events that may occur in a transmittal are listed in the first Lc Ocolumn of Table 6/X.402. For each listed kind, the second column indicates the O` Lkinds of information objects--messages, probes, and reports--for which such LcJ Oevents may be staged, the third column the kinds of functional objects--users, OIDJ5UAs, MSs, MTAs, and AUs--that may stage such events.59 %All the events occur within the MTS.%9 %Table .T.:6/X.402 Transmittal Events%b N+-------------------+-------------+-------------------+ | | N^ JInformation | Functional | | | Objects | J^ JObjects | | +-------------+-------------------+ | JJ6Transmittal Event | M P R | user UA MS MTA AU | 6d P+-------------------+-------------+-------------------+ | splitting | xPd P x - | - - - x - | | joining | x x x | - - - x Pd P - | | name resolution | x x - | - - - x - | | DL expansion Pd P | x - - | - - - x - | | redirection | x x - | - P] I- - x - | | conversion | x x - | - - - x - | | Id Pnon-delivery | x - x | - - - x - | | non-affirmation | - Pd P x - | - - - x - | | affirmation | - x - | - - - x PR > - | | routing | x x x | - - - x - | >W C+-------------------+-------------+-------------------+ +- Legend C_ K---------------+ | M message x permitted | | P probe | | R KF 2report | +------------------------+2_JMKThe kinds of transmittal events, summarized in the table, are individually K@ ,defined and described in the clauses below.,( 9.4.1Splitting` LIn a .I.gl:splitting; event, an MTA replicates a message or probe, dividing L` Lresponsibility for its immediate recipients among the resulting information Ld Pobjects. This event effectively allows an MTA to independently convey an object P5DJ!to various potential recipients.!dJ PAn MTA stages a splitting when the next step or event required in the conveyancePd Pof a message or probe to some immediate recipients differs from that required inP. its conveyance to others.& 9.4.2Joiningd PIn a .I.gl:joining; event, an MTA combines several instances of the same messageP_Kor probe, or two or more delivery and\or non-delivery reports for the same K`# PAn MTA may, but need not stage a -or probe, or two or more . subject message or probe.o convey several highly related information objects P+ to their destinations.. 9.4.3Name Resolutiond PIn a .I.gl:name resolution; event, an MTA adds the corresponding O/R address to PY Ethe O/R name that identifies one of a message's or probe's immediate E  recipients. + 9.4.4DL Expansiond PIn a .I.gl:DL expansion; event, an MTA resolves a DL among a message's (but not Pa Ma probe's) immediate recipients to its members which are thereby made member M^ Jrecipients. This event removes indirection from the immediate recipients' J#JMspecification.] IA particular DL is always subjected to DL expansion at a pre-established Id Plocation within the MTS. This location is called the DL's .I.gl:expansion point;P9 %and is identified by an O/R address.%S ?As part of this event, the MTA may generate a delivery report.?c ODL expansion is subject to submit permission. In the case of a nested DL, that OdDJPpermission must have been granted to the DL of which the nested DL is a member. PL 8Otherwise, it must have been granted to the originator.8* 9.4.5RedirectiondJ PIn a .I.gl:redirection; event, an MTA replaces a user or DL among a message's orPd Pprobe's immediate recipients with an originator-specified or recipient-assigned P) alternate recipient.)9.4.6Conversiona MIn a .I.gl:conversion; event, an MTA transforms parts of a message's content M` Lfrom one EIT to another, or alters a probe so it appears that the described L[ Gmessages were so modified. This event increases the likelihood that an Gd Pinformation object can be delivered or affirmed by tailoring it to its immediateP  recipients. d PThe following kinds of conversion are distinguished, on the basis of how the EITPd Pof the information to be converted and the EIT to result from the conversion areP  selected: b Na).I.gl:explicit conversion;: A conversion in which the originator selects N5 !both the initial and final EITs.!d Pb).I.gl:implicit conversion;: A conversion in which the MTA selects the finalP6JM"EITs based upon the initial EITs."+ 9.4.7Non-deliveryd PIn a .I.gl:non-delivery; event, an MTA determines that the MTS cannot deliver a P[ Gmessage to its immediate recipients, or cannot deliver a report to the Gc Ooriginator of its subject message or probe. This event halts the conveyance of O: &an object the MTS deems unconveyable.&YDJEAs part of this event, in the case of a message, the MTA generates a E) non-delivery report.^ JAn MTA stages a non-delivery, e.g., when it determines that the immediate J] Irecipients are improperly specified, that they do not accept delivery of Ic Omessages like that at hand, or that the message has not been delivered to them O6J "within pre-specified time limits.".9.4.8Non-affirmation` LIn a .I.gl:non-affirmation; event, an MTA determines that the MTS could not L^ Jdeliver a described message to a probe's immediate recipients. This event J_ Kpartially or fully determines the answer to the question posed by a probe.KT @As part of this event, the MTA generates a non-delivery report.@a MAn MTA stages a non-affirmation, e.g., when it determines that the immediate Md Precipients are improperly specified or would not accept delivery of a described P  message. * 9.4.9Affirmationd PIn an .I.gl:affirmation; event, an MTA determines that the MTS could deliver anyPa Mdescribed message to a probe's immediate recipients. This event partially or Mc Ofully determines the answer to the question posed by a probe, and elevates the OMJM9immediate recipients to the status of actual recipients.9S ?As part of this event, the MTA may generate a delivery report.?b NAn MTA stages an affirmation once it determines that the immediate recipients Nd Pare properly specified and, if the immediate recipients are users (but not DLs),Pd Pwould accept delivery of any described message. If the immediate recipients are Pc ODLs, and MTA stages an affirmation if the DL exists and the originator has the O0J relevant submit permission.J  e./4  If the immediate recipients are  specified and, ifD 0would accept delivery of any described message.0 J  & 9.4.10Routingof N5 !transfer for which they prepare:!`La).I.gl:internal routing;: A routing preparatory to an internal transfer L5J !(i.e., a transfer within an MD).!` Lb).I.gl:external routing;: A routing preparatory to an external transfer L4  (i.e., a transfer between MDs). d PAn MTA stages a routing when it determines that it can stage no other event, andP7 #take no step, regarding an object.#( 10.Security Model^ JThis clause provides an abstract security model for Message Transfer. The Jd Pconcrete realization of the model is the subject of other Recommendations in theP] Iset. The security model provides a framework for describing the security I] Iservices that counter potential threats (see annex D) to the MTS and the IC /security elements that support those services./cJMOThe security features are an optional extension to the MHS that can be used to O] Iminimise the risk of exposure of assets and resources to violations of a Id Psecurity policy (threats). Their aim is to provide features independently of thePd Pcommunications services provided by other lower or higher entities. Threats may PT @be countered by the use of physical security, computer security @b N(.I.ab:COMPUSEC;), or security services provided by the MHS. Depending on the N`DJLperceived threats, certain of the MHS security services will be selected in L^ Jcombination with appropriate physical security and COMPUSEC measures. The J_ Ksecurity services supported by the MHS are described below. The naming and KI 5structuring of the services are based on ISO 7498-2.5` JNote ny cases, the broad classes of threats are covered by several of the J% services listed._KThe security services are supported through use of service elements of the K^ JMessage Transfer Service message envelope. The envelope contains security Jd Prelevant arguments as described in Recommendation X.411. The description of the PdJ Psecurity services takes the following general form. In clause 10.2 the services Pd Pare listed, with, in each case, a definition of the service and an indication ofPc Ohow it may be provided using the security elements in Recommendation X.411. In O` Lclause 10.3 the security elements are individually described, with, in each L` Lcase, a definition of the service element and references to its constituent L7 #arguments in Recommendation X.411.#` LMany of the techniques employed rely on encryption mechanisms. The security Ld Pservices in the MHS allow for flexibility in the choice of algorithms. However, Pb Nin some cases only the use of asymmetric encryption has been fully defined in NaJMMthis Recommendation. A future version of this Recommendation may make use of ML 8alternative mechanisms based on symmetric encipherment.8b NNote The use of the terms "security service" and "security element" in this Nd Pclause are not to be confused with the terms "service" and "element of service" Pd Pas used in Recommendation X.400. The former terms are used in the present clauseP= )to maintain consistency with ISO 7498-2.)+DJ10.1Security Policies_ KSecurity services in the MHS must be capable of supporting a wide range of K^ Jsecurity policies which extend beyond the confines of the MHS itself. The J^ Jservices selected and the threats addressed will depend on the individual JL 8application and levels of trust in parts of the system.8d PA security policy defines how the risk to and exposure of assets can be reduced P,to an acceptable level.c OIn addition, operation between different domains, each with their own security O` Lpolicy, will be required. As each domain will be subject to its own overall L_ Ksecurity policy, covering more than just the MHS, a bilateral agreement on Kb Ninterworking between two domains will be required. This must be defined so as NaJ Mnot to conflict with the security policies for either domain and effectively MQ =becomes part of the overall security policy for each domain.=+ 10.2Security Services_ KThis clause defines the Message Transfer security services. The naming and KI 5structuring of the services are based on ISO 7498-2.5a MMHS security services fall into several broad classes. These classes and the Md Pservices in each are listed in Table 7/X.402. An asterisk (*) under the heading PaJMMof the form X/Y indicates that the service can be provided from a functional M7 #object of type X to one = (Table .T.:7/X.402 Mes Security Services(d P+-------------------------------+-------------------------------+ | Pd P | UA/UA MS/MTA UA/MTA MTA/UA | | SERVICE PS ? | UA/MS UA/MTA MTA/MTA MS/UA | +- ORIGIN AUTHENTICATION ?dDJP-------+-------------------------------+ | Message Origin Authentication | * Pd P* - * - - - - | | Probe Origin Authentication | - - * * - Pd P- - - | | Report Origin Authentication | - - - - * * - - | |P_ KProof of Submission | - - - - - - * - | | Proof of K\ HDelivery | * - - - - - - Note | +- SECURE ACCESS Hd PMANAGEMENT ----+-------------------------------+ | Peer Entity Authentication PdP | - * * * * * * * | | Security Context | - * * PA -* * * * * | +- DATA CONFIDENTIALITY -d P--------+-------------------------------+ | Connection Confidentiality | - Pd P * * * * * * * | | Content Confidentiality | * - - - - Pd P - - - | | Message Flow Confidentiality | * - - - - - - - | Pc O+- DATA INTEGRITY SERVICES -----+-------------------------------+ | Connection Od PIntegrity | - * * * * * * * | | Content Integrity PdJ P | * - - - - - - - | | Message Sequence Integrity | * - P@ , - - - - - - | +- NON-REPUDIATION ,d P-------------+-------------------------------+ | Non-repudiation of Origin |Pd P * - - * - - - - | | Non-repudiation of Submission | - - - - Pd P - - * - | | Non-repudiation of Delivery | * - - - - - - - P]JMI | | Message Security Labelling | * * * * * * * * | +- I\ HSECURITY MANAGEMENT SERVICES +-------------------------------+ | Change Hd PCredentials | - * - * * * * - | | Register P? + | - * - * - - - - | +c O+-------------------------------+-------------------------------+ Note This OV Bservice is provided by the recipient's MS to the originator's UA.BbDJNThroughout the security service definitions that follow, reference is made to Nb NFigure 6/X.402, which reiterates the MHS functional model in simplified form. NC /The numeric labels are referenced in the text./d P+------+ +------+ | 1 | | 5 | | MTS- | Pd P | MTS- | | user | | user | +------+ Pd P +------+ | | +------+ +------+ +------+ | PdP 2 | | 3 | | 4 | | MTA |-----| MTA |-----| MTA | | | PN : | | | | +------+ +------+ +------+:G 3Figure .F.:6/X.402 Simplified MHS Functional Model3F 210.2.1Origin Authentication Security Services2^ JThese security services provide for the authentication of the identity of JE 1communicating peer entities and sources of data.1K 710.2.1.1Data Origin Authentication Security Services7d PThese security services provide corroboration of the origin of a message, probe,Pc Oor report to all concerned entities (i.e., MTAs or recipient MTS-users). These OaJ Msecurity services cannot protect against duplication of messages, probes, or M  reports. R >10.2.1.1.1Message Origin Authentication Security Service>_JMKThe Message Origin Authentication Service enables the corroboration of the K) source of a message.Z FThis security service can be provided using either the Message Origin Fb NAuthentication or the Message Argument Integrity security element. The former Nd Pcan be used to provide the security service to any of the parties concerned (1-5Pa Minclusive in the figure), whereas the latter can only be used to provide the M_DJKsecurity service to MTS-users (1 or 5 in the figure). The security element KF 2chosen depends on the prevailing security policy.2P <10.2.1.1.2Probe Origin Authentication Security Service<b NThe Probe Origin Authentication security service enables the corroboration of N+ the source of a probe.c OThis security service can be provided by using the Probe Origin Authentication O`Lsecurity element. This security element can be used to provide the security Ld Pservice to any of the MTAs through which the probe is transferred (2-4 inclusiveP$ in the figure).Q =10.2.1.1.3Report Origin Authentication Security Service=c OThe Report Origin Authentication security service enables the corroboration of O, the source of a report.d PThis security service can be provided by using the Report Origin Authentication P` Lsecurity element. This security element can be used to provide the security Ld Pservice to the originator of the subject message or probe, as well as to any MTAP[ Gthrough which the report is transferred (1-5 inclusive in the figure).GC /10.2.1.2Proof of Submission Security Service/XJ DThis security service enables the originator of a message to obtain D[JMGcorroboration that it has been received by the MTS for delivery to the G7 #originally specified recipient(s).#d PThis security service can be provided by using the Proof of Submission security P  element. A -10.2.1.3Proof of Delivery Security Service-X DThis security service enables the originator of a message to obtain DXDJDcorroboration that it has been delivered by the MTS to its intended D" recipient(s).b NThis security service can be provided by using the Proof of Delivery security N  element. H 410.2.2Secure Access Management Security Service4^ JThe Secure Access Management security service is concerned with providing JdPprotection for resources against their unauthorised use. It can be divided into Pc Otwo components, namely the Peer Entity Authentication and the Security Context O' security services.J 610.2.2.1Peer Entity Authentication Security Service6c OThis security service is provided for use at the establishment of a connection Ob Nto confirm the identity of the connecting entity. It may be used on the links N` L1-2, 2-3, 3-4, or 4-5 in the figure and provides confidence, at the time of La Musage only, that an entity is not attempting a masquerade or an unauthorised M5 !replay of a previous connection.!_ KThis security service is supported by the Authentication Exchange security Kd Pelement. Note that use of this security element may yield other data as a resultP\ Hof its operation that in certain circumstances can be used to support a H_JMKConnection Confidentiality and/or a Connection Integrity security service.K@J ,10.2.2.2Security Context Security Service,d PThis security service is used to limit the scope of passage of messages between P` Lentities by reference to the Security Labels associated with messages. This Ld Psecurity service is therefore closely related to the Message Security Labelling Pb Nsecurity service, which provides for the association of messages and Security NDJLabels.c OThe Security Context security service is supported by the Security Context and O4  the Register security elements. E 110.2.3Data Confidentiality Security Services1d PThese security services provide for the protection of data against unauthorised P  disclosure. J610.2.3.1Connection Confidentiality Security Service6d PThe MHS does not provide a Connection Confidentiality security service. However,Pc Odata for the invocation of such a security service in underlying layers may be Ob Nprovided as a result of using the Authentication Exchange security element to Nb Nprovide the Peer Entity Authentication security service. The security service NY Emay be required on any of links 1-2, 2-3, 3-4, or 4-5 in the figure.EG 310.2.3.2Content Confidentiality Security Service3d PThe Content Confidentiality security service provides assurance that the contentPY Eof a message is only known to the sender and recipient of a message.Eb NIt may be provided using a combination of the Content Confidentiality and the N] IMessage Argument Confidentiality security elements. The Message Argument Ic OConfidentiality security element can be used to transfer a secret key which is OcJMOused with the Content Confidentiality security element to encipher the message Oc Ocontent. Using these security elements the service is provided from MTS-user 1 Ob Nto MTS-user 5 in the figure, with the message content being unintelligible to NJ MTAs.L 810.2.3.3Message Flow Confidentiality Security Service8d PThis security service provides for the protection of information which might be PcDJOderived from observation of message flow. Only a limited form of this security O4  service is provided by the MHS. d PThe Double Enveloping Technique enables a complete message to become the contentP_ Kof another message. This could be used to hide addressing information from Ka Mcertain parts of the MTS. Used in conjunction with traffic padding (which is Mc Obeyond the scope of this Recommendation) this could be used to provide message OdPflow confidentiality. Other elements of this service, such as routing control orPR >pseudonyms, are also beyond the scope of this Recommendation.>? +10.2.4Data Integrity Security Services+_ KThese security services are provided to counter active threats to the MHS.KD 010.2.4.1Connection Integrity Security Service0d PThe MHS does not provide a Connection Integrity security service. However, data P^ Jfor the invocation of such a security service in underlying layers may be Jb Nprovided by using the Authentication Exchange security element to provide the N] IPeer Entity Authentication security service. The security service may be IR >required on any of links 1-2, 2-3, 3-4, or 4-5 in the figure.>A -10.2.4.2Content Integrity Security Service-a MThis security service provides for the integrity of the contents of a single M^JMJmessage. This takes the form of enabling the determination of whether the Ja Mmessage content has been modified. This security service does not enable the Md Pdetection of message replay, which is provided by the Message Sequence IntegrityP& security service.d PThis security service can be provided in two different ways using two different P7J #combinations of security elements.#^DJJThe Content Integrity security element together with the Message Argument JX DIntegrity security element and, in some cases, the Message Argument Dd PConfidentiality security element can be used to provide the security service to Pb Na message recipient, i.e., for communication from MTS-user 1 to MTS-user 5 in Nd Pthe figure. The Content Integrity security element is used to compute a Content Pb NIntegrity Check as a function of the entire message content. Depending on the N\Hmethod used to compute the Content Integrity Check, a secret key may be Hb Nrequired, which may be confidentially sent to the message recipient using the Nc OMessage Argument Confidentiality security element. The Content Integrity Check O^ Jis protected against change using the Message Argument Integrity security Jc Oelement. The integrity of any confidential message arguments is provided using OK 7the Message Argument Confidentiality security element.7c OThe Message Origin Authentication security element can also be used to provide O+ this security service.J 610.2.4.3Message Sequence Integrity Security Service6a MThis security service protects the originator and recipient of a sequence of Mb Nmessages against re-ordering of the sequence. In doing so it protects against N( replay of messages.]JMIThis security service may be provided using a combination of the Message Ia MSequence Integrity and the Message Argument Integrity security elements. The M^ Jformer provides a sequence number to each message, which may be protected Jd Pagainst change by use of the latter. Simultaneous confidentiality and integrity Pb Nof the Message Sequence Number may be provided by use of the Message Argument N6 "Confidentiality security element."dDJPThese security elements provide the service for communication from MTS-user 1 toPPJ <MTS-user 5 in the figure, and not to the intermediate MTAs.<@ ,10.2.5Non-Repudiation Security Services,a MThese security services provide irrevocable proof to a third party after the Md Pmessage has been submitted, sent, or delivered, that the submission, sending, orP` Lreceipt did occur as claimed. Note that for this to function correctly, the LdPsecurity policy must explicitly cover the management of asymmetric keys for the Pa Mpurpose of non-repudiation services if asymmetric algorithms are being used.MI 510.2.5.1Non-repudiation of Origin Security Service5b NThis security service provides the recipient(s) of a message with irrevocable N` Lproof of the origin of the message, its content, and its associated Message L$ Security Label.d PThis security service can be provided in two different ways using two different Pb Ncombinations of security elements. Note that its provision is very similar to NV Bthe provision of the (weaker) Content Integrity security service.B^ JThe Content Integrity security element together with the Message Argument JX DIntegrity security element and, in some cases, the Message Argument Dd PConfidentiality security element can be used to provide the service to a messagePdJMPrecipient, i.e., for communication from MTS-user 1 to MTS-user 5 in the figure. Pb NThe Content Integrity security element is used to compute a Content Integrity Nd PCheck as a function of the entire message content. Depending on the method used Pd Pto compute the Content Integrity Check, a secret key may be required, which may P_ Kbe confidentially sent to the message recipient using the Message Argument Kd PConfidentiality security element. The Content Integrity Check and, if required, PdDJPthe Message Security Label are protected against change and/or repudiation usingP^ Jthe Message Argument Integrity security element. Any confidential message J` Larguments are protected against change and/or repudiation using the Message L?J +Argument Confidentiality security element.+a MIf the Content Confidentiality security service is not required, the Message M` LOrigin Authentication security element may also be used as a basis for this L_Ksecurity service. In this case the security service may be provided to all KM 9elements of the MHS, i.e., for all of 1-5 in the figure.9M 910.2.5.2Non-Repudiation of Submission Security Service9b NThis security service provides the originator of the message with irrevocable Nc Oproof that the message was submitted to the MTS for delivery to the originally O, specified recipient(s).d PThis security service is provided using the Proof of Submission security elementPb Nin much the same way as that security element is used to support the (weaker) N: &Proof of Submission security service.&K 710.2.5.3Non-Repudiation of Delivery Security Service7b NThis security service provides the originator of the message with irrevocable Nc Oproof that the message was delivered to its originally specified recipient(s).OcJMOThis security service is provided using the Proof of Delivery security element Ob Nin much the same way as that security element is used to support the (weaker) N8 $Proof of Delivery security service.$J 610.2.6Message Security Labelling Security Service6d PThis security service allows Security Labels to be associated with all entities Pc Oin the MHS, i.e., MTAs and MTS-users. In conjunction with the Security Context OaDJMsecurity service it enables the implementation of security policies defining Mb Nwhich parts of the MHS may handle messages with specified associated Security N Labels.] IThis security service is provided by the Message Security Label security I` Lelement. The integrity and confidentiality of the label are provided by the LaJ MMessage Argument Integrity and the Message Argument Confidentiality security M elements. ; '10.2.7Security Management Services'] IA number of security management services are needed by the MHS. The only I` Lmanagement services provided within Recommendation X.411 are concerned with LS ?changing credentials and registering MTS-user security labels.?B .10.2.7.1Change Credentials Security Service.b NThis security service enables one entity in the MHS to change the credentials Nb Nconcerning it held by another entity in the MHS. It may be provided using the N9 %Change Credentials security element.%8 $10.2.7.2Register Security Service$d PThis security service enables the establishment at an MTA of the Security LabelsPd Pwhich are permissible for one particular MTS-user. It may be provided using the P/JMRegister security element. ? entsd PThe following clauses describe the security elements available in the protocols Pb Ndescribed within Recommendation X.411 to support the security services in the Nb NMHS. These security elements relate directly to arguments in various services Nc Odescribed in Recommendation X.411. The objective of this clause is to separate OdDJPout each element of the Recommendation X.411 service definitions that relate to P^ Jsecurity, and to define the function of each of these identified security J  elements. ? +10.3.1Authentication Security Elements+_ KThese security elements are defined in order to support authentication and K1 integrity security services.G310.3.1.1Authentication Exchange Security Element3^J JThe Authentication Exchange security element is designed to authenticate, Jd Ppossibly mutually, the identity of an MTS-user to an MTA, an MTA, an MS to a UA,Pb Nor a UA to an MS to an MTS-user. It is based on the exchange or use of secret N^ Jdata, either passwords, asymmetrically encrypted tokens, or symmetrically Jc Oencrypted tokens. The result of the exchange is corroboration of the identity Od Pof the other party, and, optionally, the transfer of confidenath. The Ld Pestablishment and use of a secure communication path. The establishment and use P` Lof a secure communication path is outside the scope of this Recommendation.L d PThis security element uses the Initiator Credentials argument and the Responder P[ GCredentials result of the MTS-bind, MS-bind and MTA-bind services. The GF. The transferred ',M710.3.1.2Data Origin Authentication Surity Elements7] IThese security elements are specifically designed to support data origin Id Pauthentication services, although they may also be used to support certain data P( integrity services.R >10.3.1.2.1Message Origin Authentication Security Element>c OThe Message Origin Authentication security element enables anyone who receives O[DJGor transfers message to authenticate the identity of the MTS-user that G^ Joriginated the message. This may mean the provision of the Message Origin JV BAuthentication or the Non-repudiation of Origin security service.Bb NThe security element involves transmitting, as part of the message, a Message Nd POrigin Authentication Check, computed as a function of the message content, the P_ Kmessage Content Identifier, and the Message Security Label. If the Content KZFConfidentiality security service is also required, the Message Origin Fd PAuthentication Check is computed as a function of the enciphered rather than thePd Punenciphered message content. By operating on the message content as conveyed inPcJ Othe overall message (i.e., after the optional Content Confidentiality security Oa Melement), any MHS entity can check the overall message integrity without the MW Cneed to see the plaintext message content. However, if the Content C` LConfidentiality security service is used, the Message Origin Authentication L] Isecurity element cannot be used to provide the Non-repudiation of Origin I& security service.d PThe security element uses the Message Origin Authentication Check, which is one P^ Jof the arguments of the Message Submission, Message Transfer, and Message J' Delivery services.PJM<10.3.1.2.2Probe Origin Authentication Security Element<d PSimilar to the Message Origin Authentication security element, the Probe Origin Pd PAuthentication security element enables any MTA to authenticate the identity of P; 'the MTS-user which originated a probe.'c OThis security element uses the Probe Origin Authentication Check, which is one OF 2of the arguments of the Probe Submission service.2QDJ=10.3.1.2.3Report Origin Authentication Security Element=d PSimilar to the Message Origin Authentication security element, the Report OriginP_ KAuthentication security element enables any MTA or MTS-user who receives a K` Lreport to authenticate the identity of the MTA which originated the report.Ld PThis security element uses the Report Origin Authentication Check, which is one PE 1of the arguments of the Report Delivery service.1C/10.3.1.3Proof of Submission Security Element/a MThis security element provides the originator of a message with the means to MW Cestablish that a message was accepted by the MHS for transmission.C] IThe security element is made up of two arguments: a request for Proof of Id PSubmission, sent with a message at submission time, and the Proof of Submission,PdJ Preturned to the MTS-user as part of the Message Submission results. The Proof ofPa MSubmission is generated by the MTS, and is computed as a function of all the Mc Oarguments of the submitted message, the Message Submission Identifier, and the O- Message Submission Time.d PThe Proof of Submission argument can be used to support the Proof of Submission Pd Psecurity service. Depending on the security policy in force, it may also be ableP^ Jto support the (stronger) Non-repudiation of Submission security service.J]JMIThe Proof of Submission Request is an argument of the Message Submission Id Pservice. The Proof of Submission is one of the results of the Message SubmissionP  service. A -10.3.1.4Proof of Delivery Security Element-a MThis security element provides the originator of a message with the means to MZ Festablish that a message was delivered to the destination by the MHS.FdDJPThe security element is made up of a number of arguments. The message originatorP^ Jincludes a Proof of Delivery Request with the submitted message, and this Jb Nrequest is delivered to each recipient with the message. A recipient may then Nd Pcompute the Proof of Delivery as a function of a number of arguments associated Pb Nwith the message. The proof of delivery is returned by the MTS to the message N[ Goriginator, as part of a report on the results of the original Message G  Submission. ` LThe Proof of Delivery can be used to support the Proof of Delivery security L_ Kservice. Depending on the security policy in force, it may also be able to KY Esupport the (stronger) Non-repudiation of Delivery security service.Ed PThe Proof of Delivery Request is an argument of the Message Submission, Message Pb NTransfer, and Message Delivery services. The Proof of Delivery is both one of N` Lthe results of the Message Delivery service and one of the arguments of the LBJ .Report Transfer and Report Delivery services.. ] GNote - Non-receipt of a Proof of Delivery does not imply non-delivery.C P :ess JV BManagement security service and the security management services.B@ ,10.3.2.1Security Context Security Element,_JMKWhen an MTS-user or an MTA binds to an MTA or MTS-user, the bind operation K_ Kspecifi P his limits the scope of K] Ipassage of messages by reference to the labels associated with messages. Id PSecondly, the Security Context of the connection may be temporarily altered for P5 !submitted or delivered messages.!d PThe Security Context itself consists of one or more Security Labels defining thePcDJOsensitivity of interactions that may occur in line with the security policy in O force.[ GSecurity Context is an argument of the MTS-bind and MTA-bind services.G8 $10.3.2.2Register Security Element$[ GThe Register security element allows the establishment at an MTA of an G< (MTS-user's permissible security labels.(dPThis security element is provided by the Register service. The Register service Pc Oenables an MTS-user to change arguments, held by the MTS, relating to delivery O2 of messages to that MTS-user.J ;J '10.3.2.3MS-Register Security Element' _ KThe MS-Register security element allows the establishment of the MS-user's K1 permissible security labels. b NThis security element is provided by the MS-Register service. The MS-Register Nc Oservices enables an MS-user to chay element provides assurance that the contentPdJ Pof the message is protected from eavesdropping during transmission by use of an Pd Pencipherment security element. The security element operates such that only the P\ Hrecipient and sender of the message know the plaintext message content.HaJMMThe specification of the encipherment algorithm, the key used, and any other Mb Ninitialising data are conveyed using the Message Argument Confidentiality and Nd Pthe Message Argument Integrity security elements. The algorithm and key are thenPG 3used to encipher or decipher the message contents.3b NThe Content Confidentiality security element uses the Content Confidentiality Nb NAlgorithm Identifier, which is an argument of the Message Submission, Message N=DJ)Transfer, and Message Delivery services.)P <10.3.3.2Message Argument Confidentiality Security Element<[ GThe Message Argument Confidentiality security element provides for the Gb Nconfidentiality, integrity, and, if required, the irrevocability of recipient N^ Jdata associated with a message. Specifically, this data will comprise any Jb Ncryptographic keys and related data that is necessary for the confidentiality NdPand integrity security elements to function properly, if these optional securityP* elements are invoked.` LThe security element operates by means of the Message Token. The data to be Lc Oprotected by the Message Argument Confidentiality security element constitutes O_ Kthe Encrypted Data within the Message Token. The Encrypted Data within the KA -Message Token is unintelligible to all MTAs.-b NThe Message Token is an argument of the Message Submission, Message Transfer, N3 and Message Delivery services.? +10.3.4Data Integrity Security Elements+d PThese security elements are provided to support the provision of data integrity,PG 3data authentication, and non-repudiation services.3AJ -10.3.4.1Content Integrity Security Element-dJMPThe Content Integrity security element provides protection for the content of a PF 2message against modification during transmission.2c OThis security element operates by use of one or more cryptographic algorithms. OZ FThe specification of the algorithm(s), the key(s) used, and any other Fb Ninitialising data are conveyed using the Message Argument Confidentiality and Nd Pthe Message Argument Integrity security elements. The result of the application PcDJOof the algorithms and key is the Content Integrity Check, which is sent in the Od Pmessage envelope. The security element is only available to the recipient(s) of PR >the message as it operates on the plaintext message contents.>d PIf the Content Integrity Check is protected using the Message Argument IntegrityPb Nsecurity element then, depending on the prevailing security policy, it may be NY Eused to help provide the Non-repudiation of Origin security service.EbNThe Content Integrity Check is an argument of the Message Submission, Message N= )Transfer, and Message Delivery services.)J 610.3.4.2Message Argument Integrity Security Element6d PThe Message Argument Integrity security element provides for the integrity, and,Pd Pif required, the irrevocability of certain arguments associated with a message. P\ HSpecifically, these arguments may comprise any selection of the Content Hc OConfidentiality Algorithm Identifier, the Content Integrity Check, the Message Od PSecurity Label, the Proof of Delivery Request, and the Message Sequence Number.P` LThe security element operates by means of the Message Token. The data to be La Mprotected by the Message Argument Integrity security element constitutes the M: &signed-data within the Message Token.&b NThe Message Token is an argument of the Message Submission, Message Transfer, N3JMand Message Delivery services.JJ 610.3.4.3Message Sequence Integrity Security Element6` LThe Message Sequence Integrity security element provides protection for the L_ Ksender and recipient of a message against receipt of messages in the wrong K3 order, or duplicated messages.d PA Message Sequence Number is associated with an individual message. This number PbDJNidentifies the position of a message in a sequence from one originator to one N^ Jrecipient. Therefore each originator-recipient pair requiring to use this Jc Osecurity element will have to maintain a distinct sequence of message numbers. Od PThis security element does not provide for iniZYXWVUTSRQPONMLKJIHGFEDCBA@?>=<;:9876543210/.-,+*)('&%$#"!  H~}|{zyxwvutstialisation or synchronisation of P. Message Sequence Numbers.@ ,10.3.5Non-repudiation Security Elements,WCThere are no specific Non-repudiation security elements defined in C_ KRecommendation X.411. The non-repudiation services may be provided using a K< (combination of other security elements.(? +10.3.6Security Label Security Elements+\ HThese security elements exist to support security labelling in the MHS.HF 210.3.6.1Message Security Label Security Element2_ KMessages may be labelled with data as specified in the prevailing security Kd Ppolicy. The Message Security Label is available for use by intermediate MTAs as PG 3part of the overall security policy of the system.3d PA Message Security Label may be sent as a message argument, and may be protectedPd Pby the Message Argument Integrity or the Message Origin Authentication security PL 8element, in the same manner as other message arguments.8cJMOAlternatively, if both confidentiality and integrity are required, the Message O_ KSecurity Label may be protected using the Message Argument Confidentiality Ka Msecurity element. In this case the Message Security Label so protected is an MdJ Poriginator-recipient argument, and may differ from the Message Security Label inP* the message envelope.D 010.3.7Security Management Security Elements0BDJ.10.3.7.1Change Credentials Security Element.d PThe Change Credentials security element allows the credentials of an MTS-user orP* an MTA to be updated.\ HThe security element is provided by the MTS Change Credentials service.H: &10.3.8Double Enveloping Technique&_ KAdditional protection may be provided to a complete message, including the KdPenvelope parameters, by the ability to specify that the content of a message is Pa Mitself a complete message, i.e., a Double Enveloping Technique is available.Mb NThis technique is available though the use of the Content Type argument which Nd Pmakes it possible to specify that the content of a message is an Inner Envelope.P_ KThis Content Type means that the content is itself a message (envelope and K` Lcontent) for forwarding by the recipient named on the outer envelope to the L; 'recipient named on the Inner Envelope.'d PThe Content Type is an argument of the Message Submission, Message Transfer, andP/ Message Delivery services. 3 Section Three - Configurations"JM11.Overviewd PThis section specifies how one can configure the MHS to satisfy any of a varietyPN :of functional, physical, and organizational requirements.:> *This section covers the following topics:*3J a)Functional configurations1DJb)Physical configurations7 #c)Organizational configurations#( d)The Global MHS3 12.Functional Configurationsa MThis clause specifies the possible functional configurations of the MHS. The M_ Kvariety of such configurations results from the presence or absence of the KM9Directory, and from whether a direct user employs an MS.91 12.1Regarding the Directoryd PWith respect to the Directory, the MHS can be configured for a particular user, Pd Por a collection of users (e.g., see clause 14.1), in either of two ways: with orP_ Kwithout the Directory. A user without access to the Directory may lack the K< (capabilities described in section five.(d PNote A partially, rather than fully interconnected Directory may exist for an PX Dinterim period during which the (global) Directory made possible by DK 7Recommendations for Directories is under construction.75 !12.2Regarding the Message Store!c OWith respect to the MS, the MHS can be configured for a particular direct user Oa Min either of two ways: with or without an MS. A user without access to an MS Md Placks the capabilities of Message Storage. A user in such circumstances depends Pd Pupon his UA for the storage of information objects, a capability that is a localP matter.^JMJThe two functional configurations identified above are depicted in Figure Jb N7/X.402 which also illustrates one possible configuration of the MTS, and its N` Llinkage to another communication system via an AU. In the figure, user 2 is L=DJ)equipped with an MS while user 1 is not.)cJ O+----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 | | 08 | | 09 | | 10 | | Od P11 | | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20 | | 21 | | 22 PN :| | 23 | | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+:R >Figure .F.:7/X.402 Functional Configurations Regarding the MS>a MNote While the users depicted in the figure are people, the figure applies MK7with equal force and validity to users of other kinds.71 13.Physical Configurationsd PThis clause specifies the possible physical configurations of the MHS, i.e., howPd Pthe MHS can be realized as a set of interconnected computer systems. Because theP] Inumber of configurations is unbounded, the clause describes the kinds of I\ Hmessaging systems from which the MHS is assembled, and identifies a few H= )important representative configurations.)+ 13.1Messaging Systems` LThe building blocks used in the physical construction of the MHS are called Ld Pmessaging systems. A .I.gl:messaging system; is a computer system (possibly but P\ Hnot necessarily an open system) that contains, or realizes, one of more H( functional objects.S ?Messaging systems are of the types depicted in Figure 8/X.402.?c O+----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 | | 08 | | 09 | | 10 | | Od P11 | | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20 | | 21 | | 22 PN :| | 23 | | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+:> *Figure .F.:8/X.402 Messaging System Types*cJMOThe types of messaging system, depicted in the figure, are listed in the first OcDJOcolumn of Table 8/X.402. For each type listed, the second column indicates the Od Pkinds of functional object--UAs, MSs, MTAs, and AUs--that may be present in suchPd Pa messaging system, whether their presence is mandatory or optional, and whetherPaJ Mjust one or possibly several of them may be present in the messaging system.Mb NThe table is divided into two sections. Messaging systems of the types in the Nb Nfirst section are dedicated to single users, those of the types in the second N=)can (but need not) serve multiple users.)8 $Table .T.:8/X.402 Messaging Systems$\ H+-----------+--------------------+ | | Functional Objects | | HX DMessaging +--------------------+ | System | UA MS MTA AU | Dd P+-----------+--------------------+ | A/SYS | 1 - - - | | S/SYS PP < | - 1 - - | | AS/SYS | 1 1 - - | <d P+-----------+--------------------+ | T/SYS | - - 1 [M] | | AT/SYS Pd P | M - 1 [M] | | ST/SYS | - M 1 [M] | | AST/SYS | M PQ =M 1 [M] | +-----------+--------------------+ +- Legend =H 4-------------------+ | M multiple [...] optional | 43 +----------------------------+b NThe messaging system types, summarized in the table, are individually defined N8 $and described in the clauses below.$d PNote The following major principles governed the admission of messaging systemP types:d Pa)An AU and the MTA with which it interacts are typically co-located because PM 9no protocol to govern their interaction is standardized.9a Mb)An MTA is typically co-located with multiple UAs or MSs because, of the MdDJPstandardized protocols, only that for transfer simultaneously conveys a message PdJMPto multiple recipients. The serial delivery of a message to multiple recipients Pc Oserved by a messaging system, which the delivery protocol would require, would O$ be inefficient.` Lc)No purpose is served by co-locating several MTAs in a messaging system L`J Lbecause a single MTA serves multiple users, and the purpose of an MTA is to L^Jconvey objects between, not within such systems. (This is not intended to Jb Nexclude the possibility of several MTA-related processes co-existing within a N- single computer system.)d Pd)The co-location of an AU with an MTA does not affect that system's behaviorPd Pwith respect to the rest of the MHS. A single messaging system type, therefore, P? +encompasses the AU's presence and absence.+- 13.1.1Access Systemsa MAn .I.gl:access system; (.I.ab:A/SYS;) contains one UA and neither an MS, an M$ MTA, nor an AU.< (An A/SYS is dedicated to a single user.(. 13.1.2Storage Systemsd PA .I.gl:storage system; (.I.ab:S/SYS;) contains one MS and neither a UA, an MTA,P  nor an AU. < (An S/SYS is dedicated to a single user.(9 %13.1.3Access and Storage Systems%d PAn .I.gl:access and storage system; (.I.ab:AS/SYS;) contains one UA, one MS, andP. neither an MTA nor an AU.= )An AS/SYS is dedicated to a single user.)/DJ13.1.4Transfer Systemsa MA .I.gl:transfer system; (.I.ab:T/SYS;) contains one MTA; optionally, one or M: &more AUs; and neither a UA nor an MS.&6JM"A T/SYS can serve multiple users.": &13.1.5Access and Transfer Systems&c OAn .I.gl:access and transfer system; (.I.ab:AT/SYS;) contains one or more UAs; OE1one MTA; optionally, one or more AUs; and no MS.18J $An AT/SYS can serve multiple users.$; '13.1.6Storage and Transfer Systems'c OA .I.gl:storage and transfer system; (.I.ab:ST/SYS;) contains one or more MSs; OE 1one MTA; optionally, one or more AUs; and no UA.18 $An ST/SYS can serve multiple users.$D 013.1.7Access, Storage, and Transfer Systems0d PAn .I.gl:access, storage, and transfer system; (.I.ab:AST/SYS;) contains one or PY Emore UAs; one or more MSs; one MTA; and optionally, one or more AUs.E9 %An AST/SYS can serve multiple users.%7 #13.2Representative Configurations#d PMessaging systems can be combined in various ways to form the MHS. The possible Pc Ophysical configurations are unbounded in number and thus cannot be enumerated. Ob NSeveral important representative configurations, however, are described below N+ and in Figure 9/X.402.c O+----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 | | 08 | | 09 | | 10 | | Od P11 | | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20 | | 21 | | 22 PN :| | 23 | | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+:NDJ:Figure .F.:9/X.402 Representative Physical Configurations: Notesb N1. While the users depicted in the figure are people, the figure applies with NF 2equal force and validity to users of other kinds.2b N2. Besides the physical configurations that result from the "pure" approaches NLJM8below, many "hybrid" configurations can be constructed.8013.2.1Fully Centralized] IThe MHS may be fully centralized (panel a of the figure). This design is Id Prealized by a single AST/SYS which contains functional objects of all kinds and P4J  which can serve multiple users. G 313.2.2Centralized Message Transfer and Storage3d PThe MHS may provide both Message Transfer and Message Storage centrally but userP_ Kaccess distributedly (panel b of the figure). This design is realized by a K@ ,single ST/SYS and, for each user, an A/SYS.,; '13.2.3Centralized Message Transfer'` LThe MHS may provide Message Transfer centrally but Message Storage and user L_ Kaccess distributedly (panel c of the figure). This design is realized by a K_ Ksingle T/SYS and, for each user, either an AS/SYS alone or an S/SYS and an K& associated A/SYS.0 13.2.4Fully Distributedd PThe MHS may provide even Message Transfer distributedly (panel d of the figure).PE 1This design involves multiple ST-SYNs or T-SYNs.17 #14.Organizational Configurations#a MThis clause specifies the possible organizational configurations of the MHS, MbDJNi.e., how the MHS can be realized as interconnected but independently managed Na Msets of messaging systems (which are themselves interconnected). Because the M] Inumber of configurations is unbounded, the clause describes the kinds of I] Imanagement domains from which the MHS is assembled, and identifies a few I= )important representative configurations.), 14.1Management DomainscOThe primary building blocks used in the organizational construction of the MHS O^JMJare called management domains. A .I.gl:management domain; (.I.ab:MD;) (or Jd P.I.gl:domain;) is a set of messaging systems--at least one of which contains, orPP <realizes, an MTA--that is managed by a single organization.<a MThe above does not preclude an organization from managing a set of messaging MaJ Msystems (e.g., a single A/SYS) that does not qualify as an MD for lack of an Md PMTA. Such a collection of messaging systems, a secondary building block used in P@ ,the MHS' construction, "attaches" to an MD.,a MMDs are of several types which are individually defined and described in the M# clauses below.@ ,14.1.1Administration Management Domains,a MAn .I.gl:administration management domain; (.I.ab:ADMD;) comprises messaging Md Psystems managed by an Administration. The major technical distinction between anPb NADMD and a PRMD is that the former is positioned above the latter in the MHS' Na Mhierarchical addressing (see clause 18) and routing (see clause 19) regimes.ML 8Note An ADMD provides Message Handling to the public.8 country.I9 %14.1.2Private Management Domains%a MA .I.gl:private management domain; (.I.ab:PRMD;) comprises messaging systems MaDJMmanaged by an organization other than an Administration. The major technical Mb Ndistinction between a PRMD and an ADMD is that the former is positioned below Nd Pthe latter in the MHS' hierarchical addressing (see clause 18) and routing (see P( clause 19) regimes.d PNote A PRMD provides Message Handling, e.g., to the employees of a company, orPE 1to those employees at a particular company site.1 epresentative Configurations#d PMDs can be combined in various ways to form the MHS. The possible organizationalPb Nconfigurations are unbounded in number and thus cannot be enumerated. Several NaJMMimportant representative configurations, C /to those employees at a particular company site/v ` O+----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 | | 08 | | 09 | | 10 | | Od P11 | | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20 | | 21 | | 22 PNJ :| | 23 | | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+:U AFigure .F.:10/X.402 Representative Organizational ConfigurationsAa MNote Besides the organizational configurations that result from the "pure" MW Capproaches below, many "hybrid" configurations can be constructed.C0 14.2.1Fully Centralizedd PThe entire MHS may be managed by one organization (panel a of the figure). This P7 #design is realized by a single MD.#1 14.2.2Directly Connectedc OThe MHS may be managed by several organizations, the messaging systems of each Od Pconnected to the messaging systems of all of the others (panel b of the figure).PV BThis design is realized by multiple MDs interconnected pair-wise.B3DJ14.2.3Indirectly Connectedb NThe MHS may be managed by several organizations, the messaging systems of one Nd Pserving as intermediary between the messaging systems of the others (panel c of PY Ethe figure). This design is realized by multiple MDs one of which is E9 %interconnected to all of the others.%( 15.The Global MHSbNA major purpose of this Recommendation and others in the set is to enable the N\ Hconstruction of the .I.gl:Global MHS;, an MHS providing both intra- and H] Iinter-organizational, and both intra- and international Message Handling I  world-wide. _ KThe Global MHS almost certainly encompasses the full variety of functional K;JM'configurations specified in clause 12.'Y EThe physical configuration of the Global MHS is a hybrid of the pure Ed Pconfigurations specified in clause 13, extremely complex and highly distributed P  physically. _J KThe organizational configuration of the Global MHS is a hybrid of the pure Kd Pconfigurations specified in clause 14, extremely complex and highly distributed P& organizationally.d P Figure 11/X.402 gives an example of possible interconnections. It does notP8 Kattempt to identify all possible configurations. As depicted, ADMDs play a K=!  ADMDs play a  GDepending upon national regulations, by interc )_ KFigure 11/X.402 gives an example of possible interconnections. It does not K_ Kattempt to identify all possible configurations. As depicted, ADMDs play a KNB .assignment of O/R addresses to users and DLs..`DJLPRMDs play a peripheral role in the Global MHS, being connected to the ADMD LK 7backbone which serves as an intermediary between them.7c O+----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 | | 08 | | 09 | | 10 | | Od P11 | | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20 | | 21 | | 22 PN :| | 23 | | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+:7 #Figure .F.:11/X.402 The Global MHS#C /Section Four - Naming, Addressing, and Routing/" 16.Overview^ JThis section describes the naming and addressing of users and DLs and the J< (routing of information objects to them.(>JM*This section covers the following topics:*  a)Naming $ b)Addressing!  c)Routing  J  17.Naming b NThis clause specifies how users and DLs are named for the purposes of Message Nd PHandling in general and Message Transfer in particular. It defines O/R names andPJ 6describes the role that Directory names play in them.6d PWhen it directly submits a message or probe, a UA or MS identifies its potentialP^ Jrecipients to the MTS. When the MTS delivers a message, it identifies the Jb Noriginator to each recipient's UA or MS. O/R names are the data structures by NDDJ0means of which such identification is achieved.0) 17.1Directory Namesd PA Directory name is one component of an O/R name. A Directory name identifies anPd Pobject to the Directory. By presenting such a name to the Directory, the MHS canPa Maccess a user's or DL's Directory entry. From that entry the MTS can obtain, M: &e.g., the user's or DL's O/R address.&b NNot every user or DL is registered in the Directory and, therefore, not every N; 'user or DL possesses a Directory name.'Notesb N1. Many users and DLs will lack Directory names until the Directory is widely Nc Oavailable as an adjunct to the MHS. Many indirect users (e.g., postal patrons) Ob Nwill lack such names until the Directory is widely available as an adjunct to N1 other communication systems.Y E2. Users and DLs may be assigned Directory names even before a fully Ed Pinterconnected, distributed Directory has been put in place by pre-establishing P\ Hthe naming authorities upon which the Directory will eventually depend.H a more user-friendly and more stable than the Mb Ntypical O/R address because the latter is necessarily couched in terms of the N] Iorganizational or physical structure of the MHS while the former is not. IaJ MTherefore, it is intended that over time, Directory names become the primary M` Lmeans by which users and DLs are identified outside the MTS (i.e., by other Ld Pusers), and that the use of O/R addresses be largely confined to the MTS (i.e., P% to use by MTAs).# 17.2O/R NamesdDJPEvery user or DL has one or more O/R names. An .I.gl:O/R name; is an identifier Pb Nby means of which a user can be designated as the originator, or a user or DL N[ Gdesignated as a potential recipient of a message or probe. An O/R name Ga Mdistinguishes one user or DL from another and may also identify its point of M' access to the MHS._ TK^^^^^^^An O/R name comprises a Directory name, an O/R address, or both. If Kc Opresent, the directory name (if valid) unambiguously identifies the user or DL Oa M(but is not necessarily the only name that would do so). If present, the O/R ML 8address does the same and more (again see clause 18.5).8D  present, the )  (but is not robe may O_ Kinclude either or both components in each O/R name it supplies. If the O/R Kb Naddress is omitted, the MTS obtains it from the Directory using the Directory Na Mname. If the Directory name is omitted, the MTS does without it. If both are Md Pincluded, the MTS relies firstly upon the O/R address. Should it determine that Pc Othe O/R address is invalid (e.g., obsolete), it proceeds as if the O/R address OG 3had been omitted, relying upon the Directory name.3d P At delivery the MTS includes an O/R address and possibly a Directory name Pd Pin each O/R name it supplies to a message's recipient or to the originator of a P Ireport's subject message or probe. The Directory name is included if the Ic Ooriginator supplied it or if it was specified as the the member of an expanded O 'MTS to convey to a UA or MS at PZJ Fdelivery, O/R names the UA or MS did not supply at direct submission.F$ 18.Addressingd PThis clause specifies how users and DLs are addressed. It defines O/R addresses,PdDJPdescribes the structure of the attribute lists from which they are constructed, P` Ldiscusses the character sets from which individual attributes are composed, Ld Pgives rules for determining that two attribute lists are equivalent and for the P` Linclusion of conditional attributes in such lists, and defines the standard L8 $attributes that may appear in them.$d PTo convey a message, probe, or report to a user, or to expand a DL specified as Pd Pa potential recipient of a message or probe, the MTS must locate the user or DL Pb Nrelative to its own physical and organizational structures. O/R addresses are N]Ithe data structures by means of which all such location is accomplished.I) 18.1Attribute Listsd PThe O/R addresses of both users and DLs are attribute lists. An .I.gl:attribute P; 'list; is an ordered set of attributes.'d PAn .I.gl:attribute; is an information item that describes a user or DL and that Pb Nmay also locate it in relation to the physical or organizational structure of N< (the MHS (or the network underlying it).(: &An attribute has the following parts:&d Pa).I.gl:attribute type; (or .I.gl:type;): An identifier that denotes a class P; 'of information (e.g., personal names).'_ Kb).I.gl:attribute value; (or .I.gl:value;): An instance of the class of K_JMKinformation the attribute type denotes (e.g., a particular personal name).K? +Attributes are of the following two kinds:+c Oa).I.gl:standard attribute;: An attribute whose type is bound to a class of O8 $information by this Recommendation.$`J LThe value of every standard attribute except terminal-type is either a L7DJ#string or a collection of strings.#` Lb).I.gl:domain-defined attribute;: An attribute whose type is bound to a L3 class of information by an MD.b NBoth the type and value of every domain-defined attribute are strings or N, collections of strings.d PNote The widespread use of standard attributes produces more uniform and thus Pb Nmore user-friendly O/R addresses. However, it is anticipated that not all MDs NW Cwill be able to employ such attributes immediately. The purpose of C`Ldomain-defined attributes is to permit an MD to retain its existing, native Ld Paddressing conventions for a time. It is intended, however, that all MDs migratePa Mtoward the use of standard attributes, and that domain-defined attributes be M5 !used only for an interim period.!( 18.2Character Sets` LStandard attribute values and domain-defined attribute types and values are LY Econstructed from Numeric, Printable, and Teletex Strings as follows:E] Ia)The type or value of a particular domain-defined attribute may be a Ic OPrintable String, a Teletex String, or both. The same choice shall be made for O- both the type and value.Z Fb)The kinds of strings from which standard attribute values may be Fd Pconstructed and the manner of construction (e.g., as one string or several) varyPE 1from one attribute to another (see clause 18.3).1`JMLThe value of an attribute comprises strings of one of the following sets of La Mvarieties depending upon its type: Numeric only, Printable only, Numeric and Md PPrintable, and Printable and Teletex. With respect to this, the following rules P;DJ'govern each instance of communication:'_J Ka)Wherever both Numeric and Printable Strings are permitted, strings of KP <either variety (but not both) may be supplied equivalently.<d Pb) Wherever both Printable and Teletex Strings are permitted, strings of Pd P either or both varieties may be supplied, but Printable Strings shall be Pd P supplied as a minimum whenever attributes are conveyed internationally. Pd P If both Printable and Teletex Strings are supplied, the two shou Lbe limited as indicated in the more detailed (i.e., ASN.1) specification of L8$attributes in Recommendation X.411.$ Notesc O1. Teletex Strings are permitted in attribute values to allow inclusion, e.g., OP <of the accented characters commonly used in many countries.<d P2. Not all input/output devices permit the entry and display, e.g., of accented Pc Ocharacters. Printable Strings are required internationally to ensure that such OE 1device limitations do not prevent communication.1- 18.3Standard Attributesb NThe standard attribute types are listed in the first column of Table 9/X.402. Nc OFor each listed type, the second column indicates the character sets--numeric, OV Bprintable, and teletex--from which attribute values may be drawn.B` LThe table has three sections. Attribute types in the first are of a general Lc Onature, those in the second have to do with routing to a PDS, and those in the OC /third have to do with addressing within a PDS./: &Table .T.:9/X.402 Standard Attributes&dJMP+------------------------------------------------+----------------+ | PdDJP | Character Sets | | Pd P +----------------+ | Standard Attribute Type P? + | NUM PRT TTX | +- General +OJ ;--------------------------------------+----------------+ | ;d Padministration-domain-name | x x - | | common-name Pd P | - x x | | country-name Pd P | x x - | | network-address Pd P | x(*) - - | | numeric-user-identifier |PdP x - - | | organization-name | - x xP^ J | | organizational-unit-names | - x x | | JX Dpersonal-name | - x x | | DX Dprivate-domain-name | x x - | | DX Dterminal-identifier | - x - | | D` Lterminal-type | - - - | +- Postal Ld PRouting -------------------------------+----------------+ | PDS-name Pd P | - x - | | physical-delivery-country-name Pd P | x x - | | postal-code P? + | x x - | +- Postal Addressing +E 1----------------------------+----------------+ | 1X Dextension-O/R-address-components | - x x | | DX Dextension-physical-delivery-address-components | - x x | | DX Dlocal-postal-attributes | - x x | | DX Dphysical-delivery-office-name | - x x | | DX Dphysical-delivery-office-number | - x x | | DXDJDphysical-delivery-organization-name | - x x | | DXJMDphysical-delivery-personal-name | - x x | | DX Dpost-office-box-address | - x x | | DX Dposte-restante-address | - x x | | DX Dstreet-address | - x x | | DXJ Dunformatted-postal-address | - x x | | DV Bunique-postal-name | - x x | Bc O+------------------------------------------------+----------------+ +- Legend OdP------------------------------------+ | NUM numeric x permitted Pd P | | PRT printable * Under prescribed circum- | | TTX teletex stancesPY Ea Printable String | +---------------------------------------------+Ed PThe standard attribute types, summarized in the table, are individually defined P8 $and described in the clauses below.$9 %18.3.1Administration-domain-name%d PAn .I.gl:administration-domain-name; is a standard attribute that identifies an PL 8ADMD relative to the country denoted by a country-name.8` LThe value of an administration-domain-name is a Numeric or Printable String Lc Ochosen from a set of such strings that is administered for this purpose by the O. country alluded to above.d PNote The attribute value comprising a single space (" ") shall be reserved forPc Othe following purpose. If permitted by the country denoted by the country-name O_ Kattribute, a single space shall designate any (i.e., all) ADMDs within the Kb Ncountry. This affects both the identification of users within the country and N` Lthe routing of messages, probes, and reports to and among the ADMDs of that L_DJKcountry. Regarding the former, it requires that the O/R addresses of users Kd Pwithin the country be chosen so as to ensure their unambiguousness, even in the P^ Jabsence of the actual names of the users' ADMDs. Regarding the latter, it JdJMPpermits both PRMDs within, and ADMDs outside of the country, to route messages, Pd Pprobes, and reports to any of the ADMDs within the country indiscriminantly, andPd Prequires that the ADMDs within the country interconnect themselves in such a wayP_ Kthat the messages, probes, and reports are conveyed to their destinations.KbJ NTemporary note The inclusion of the above note is tentative, subject to the NcOapproval of Administrations. The note would resolve a long-standing difference Od Pbetween CCITT and ISO in this area. If CCITT rejects the note and ISO elects to Pb Ninclude it in its corresponding International Standard, as is likely, a major N^ Jdifference between the CCITT Recommendation and ISO Standard will result.J* 18.3.2Common-name^ JA .I.gl:common-name; is a standard attribute that identifies a user or DL JR >relative to the entity denoted by another attribute (e.g., an >( organization-name)._ KThe value of a common-name is a Printable String, Teletex String, or both. Kb NWhether Printable or Teletex, the string is chosen from a set of such strings Nd Pthat is administered for this purpose (and perhaps others) by the entity alludedP  to above. [ GNote Among many other possibilities, a common-name might identify an GI 5organizational role (e.g., "Director of Marketing").5+ 18.3.3Country-name] IA .I.gl:country-name; is a standard attribute that identifies a country.IcDJOThe value of a country-name is a Numeric String that gives the number assigned Oa Mto the country by Recommendation X.121, or a Printable String that gives the MH 4character pair assigned to the country by ISO 3166.4? +18.3.4Extension-O/R-address-components+d P^^^^^^^An extension-postal-O/R-address-components; is a standard attribute that Pute that 5JMKpostal address, additional information n( ^^^^^^^An extension-I 5O/R-address-components; is a standard attribute that 5Flue of an extension-O/R-address-components is a Printable String, Teletex P%String, or both.MJ 918.3.5Extension-physical-delivery-address-components9d PAn .I.gl:extension-physical-delivery-address-components; is a standard attributeP] Ithat specifies, in a postal address, additional information necessary to Ib Nidentify the exact point of delivery (e.g., room and floor numbers in a large N  building). b NThe value of an extension-physical-delivery-address-components is a Printable N5 !String, Teletex String, or both.!6 "18.3.6Local-postal-attributes"a MA .I.gl:local-postal-attributes; is a standard attribute that identifies the MH 4locus of distribution, other than that denoted by a 4d Pphysical-delivery-office-name attribute (e.g., a geographical area), of a user'sP' physical messages.d PThe value of a local-postal-attributes is a Printable String, Teletex String, orP both.. 18.3.7Network-addressdDJPA .I.gl:network-address; is a standard attribute that gives the network address P# of a terminal.P <The value of a network-address is any one of the following:<L 8a)A Numeric String governed by Recommendation X.121.8Z Fb)Two Numeric Strings governed by Recommendations E.163 and E.164.Ft Pb Nis mandatory and designates a number. The second is optional and designates a N!  sub-address. m+JMc) A PSAP address.bLNote - Among the strings admitted by Recommendation X.121 is a Telex number H a Telex number L< (preceded by the Telex escape digit (8).(6 "18.3.8Numeric-user-identifier"^J JA .I.gl:numeric-user-identifier; is a standard attribute that numerically JI 5identifies a user relative to the ADMD denoted by an 50 administration-domain-name.d PThe value of a numeric-user-identifier is a Numeric String chosen from a set of P^ Jsuch strings that is administered for this purpose by the ADMD alluded to J above. f PNote - In countries choosing country-wide unique organization-names, a national LO ;registration authority for organization-names is required.; 0 18.3.9Organization-name j Tis a standard attribute that identifies an Gc Oorganization. A[ G^^^^^^^An organization-name is a standard attribute that identifiesDJ$18.3.10Organizational-unit-names$d PAn .I.gl:organizational-unit-names; is a standard attribute that identifies one Pd Por more units (e.g., divisions or departments) of the organization denoted by anPc Oorganization-name, each unit but the first being a sub-unit of the units whose O7 #names precede it in the attribute.#b NThe value of an organizational-unit-names is an ordered sequence of Printable Nc OStrings, an ordered sequence of Teletex Strings, or both. Whether Printable or Oc OTeletex, each string is chosen from a set of such strings that is administered OdPfor this purpose (and perhaps others) by the organization (or encompassing unit)P&JMalluded to above.= )18.3.11Physical-delivery service-name) b N^^^^^^^A Physical-delivery-name is a standard attribute that identifies a PDS NS ?relative to the ADMD denoted by an administration-domain-name.?dJ PThe value of a PDS-name is a Printable String chosen from a set of such strings PX Dthat is administered for this purpose by the ADMD alluded to above.D .D, 18.3.12Personal-named PA .I.gl:personal-name; is a standard attribute that identifies a person relativeP] Ito the entity denoted by another attribute (e.g., an organization-name).Id PThe value of a personal-name comprises the following four pieces of information,P> *the first mandatory, the others optional:*/ a)The person's surname.2 b)The person's given name.K 7c)The initials of all of his names but his surname.77 #d)His generation (e.g., "Jr.").#`DJLThe above information is supplied as Printable Strings, Teletex Strings, or L both.= )18.3.13Physical-delivery-country-name)d PA .I.gl:physical-delivery-country-name; is a standard attribute that identifies PU Athe country in which a user takes delivery of physical messages.Ad PThe value of a physical-delivery-country-name is subject to the same constraintsP7 #as is the value of a country-name.#< (18.3.14Physical-delivery-office-name(cOA .I.gl:physical-delivery-office-name; is a standard attribute that identifies Oa Mthe city, village, etc. in which is situated the post office through which a M> *user takes delivery of physical messages.*`JMLThe value of a physical-delivery-office-name is a Printable String, Teletex L% String, or both.> *18.3.15Physical-delivery-office-number*Z FA .I.gl:physical-delivery-office-number; is a standard attribute that FQJ =distinguishes among several post offices denoted by a single =3 physical-delivery-office-name.b NThe value of a physical-delivery-office-number is a Printable String, Teletex N% String, or both.B .18.3.16Physical-delivery-organization-name.^ JA .I.gl:physical-delivery-organization-name; is a standard attribute that J? +identifies a postal patron's organization.+^ JThe value of a physical-delivery-organization-name is a Printable String, J- Teletex String, or both.>DJ*18.3.17Physical-delivery-personal-name*d PA .I.gl:physical-delivery-personal-name; is a standard attribute that identifiesP% a postal patron.b NThe value of a physical-delivery-personal-name is a Printable String, Teletex N% String, or both.6 "18.3.18Post-office-box-address"` LA .I.gl:post-office-box-address; is a standard attribute that specifies the L] Inumber of the post office box by means of which a user takes delivery of I'physical messages.d PThe value of a post-office-box-address is a Printable String, Teletex String, orPc Oboth chosen from the set of such strings assigned for this purpose by the post OQ =office denoted by a physical-delivery-office-name attribute.=* 18.3.19Postal-codedJMPA .I.gl:postal-code; is a standard attribute that specifies the postal code for P_ Kthe geographical area in which a user takes delivery of physical messages.Kd PThe value of a postal-code is a Numeric or Printable String chosen from the set P` Lof such strings that is maintained and standardized for this purpose by the LIJ 5postal administration of the country identified by a 5> *physical-delivery-country-name attribute.*5 !18.3.20Poste-restante-address!d PA .I.gl:poste-restante-address; is a standard attribute that specifies the code Pa Mthat a user gives to a post office in order to collect the physical messages M0 that await delivery to him.d PThe value of a poste-restante-address is a Printable String, Teletex String, or PcDJOboth chosen from the set of such strings assigned for this purpose by the post OQ =office denoted by a physical-delivery-office-name attribute.=2 18.3.21Private-domain-name d P^^^^^^^^A private-domain-name is a standard attribute that identifies a PRMD. AsPa Ma national matter, this identification may be either relative to the country Md Pdenoted by a country-name (so that PRMD names are unique within the country), orPVBrelative to the ADMD identified by an administration-domain-name.B` L^^^^^^^^The value of a private-domain-name is a Numeric or Printable String Lc Ochotreet Jd Paddress (e.g., house number and street name and type (e.g., "Road")) at which a P> *user takes delivery of physical messages.*T @The value of a street-address is a Printable or Teletex String.@2 18.3.23Terminal-identifiera MA .I.gl:terminal-identifier; is a standard attribute that gives the terminal M^JMJidentifier of a terminal (e.g., a Telex answer back or a Teletex terminal J!  identifier). N :The value of a terminal-identifier is a Printable String.:, 18.3.24Terminal-type\J HA .I.gl:terminal-type; is a standard attribute that gives the type of a H  terminal. a MThe value of a terminal-type is any one of the following: Telex, Teletex, G3 MI 5facsimile, G4 facsimile, IA5 terminal, and Videotex.59 %18.3.25Unformatted-postal-address%bDJNAn .I.gl:unformatted-postal-address; is a standard attribute that specifies a N8 $user's postal address in free form.$c OThe value of an unformatted-postal-address is a sequence of Printable Strings, Od Peach representing a line of text; a single Teletex String, lines being separatedP= )as prescribed for such strings; or both.)1 18.3.26Unique-postal-named PA .I.gl:unique-postal-name; is a standard attribute that identifies the point ofPd Pdelivery, other than that denoted by a street-address, post-office-box-address, PaMor poste-restante-address, (e.g., a building or hamlet) of a user's physical M  messages. ` LThe value of a unique-postal-name is a Printable String, Teletex String, or L both.4  18.4Attribute List Equivalence a MSeveral O/R addresses, and thus several attribute lists, may denote the same Md Puser or DL. This multiplicity of O/R addresses results in part (but not in full)PI 5from the following attribute list equivalence rules:5U Aa)The relative order of standard attributes is insignificant.A_JMKb)Where the value of a standard attribute may be a Numeric String or an K] Iequivalent Printable String, the choice between them shall be considered I# insignificant._ Kc)Where the value of a standard attribute may be a Printable String, an KcJ Oequivalent Teletex String, or both, the choice between the three possibilities O7 #shall be considered insignificant.#c Od)Where the value of a standard attribute may contain letters, the cases of ODDJ0those letter shall be considered insignificant.0a Me)In a domain-defined attribute type or value, or in a standard attribute Mb Nvalue, all leading, all trailing, and all but one consecutive embedded spaces N7 #shall be considered insignificant.# Notesd P1. An MD may impose additional equivalence rules upon the attributes it assigns Pb Nto its own users and DLs. It might define, e.g., rules concerning punctuation N_ Kcharacters in attribute values, the case of letters in such values, or the KA-relative order of domain-defined attributes.-c O2. As a national matter, MDs may impose additional equivalence rules regarding Ob Nstandard attributes whose values are given as Teletex Strings, in particular, NM 9the rules for deriving the equivalent Printable Strings.9+ 18.5O/R Address Formsd PEvery user or DL is assigned one or more O/R addresses. An .I.gl:O/R address; isPb Nan attribute list that distinguishes one user from another and identifies the NS ?user's point of access to the MHS or the DL's expansion point.?d PAn O/R address may take any of the forms summarized in Table 10/X.402. The firstPd Pcolumn of the table identifies the attributes available for the construction of P^ JO/R addresses. For each O/R address form, the second column indicates the J`JMLattributes that may appear in such O/R addresses and their grades (see also L" clause 18.6).cO^^^^^^The table has four sections. Attribute types in the first are those of a O Knature, attribute types in the second and third those specific to physical KXDdelivery. The fourth sec] ributes.5<DJ(Table .T.:10/X.402 Forms of O/R Address(d P+-------------------------------------+-------------------------+ | Pd P | O/R Address Forms | | Pd P +-------------------------+ | | Pd P POST | | Attribute Type | MNEM NUMR F Pb NU TERM | +- General ---------------------------+-------------------------+ | Nd Padministration-domain-name | M M M M C | | common-name Pd P | C - C - - | | country-name PdP | M M M M C | | network-address | - Pd P - - - M | | numeric-user-identifier | - M - - P` L - | | organization-name | C - C - - | | Ld Porganizational-unit-names | C - - - - | | personal-name Pd P | C - C - - | | private-domain-name Pd P | C C C C C | | terminal-identifier | - Pd P - - - C | | terminal-type | - - - - P` L C | +- Postal Routing --------------------+-------------------------+ | LV BPDS-name | - - O O - | | Bd Pphysical-delivery-country-name | - - M M - | | postal-code P[ G | - - M M - | +- Postal Addressing Gd P-----------------+-------------------------+ | extension-O/R-address-components Pd P | - - C - - | | extension-physical-delivery | - - PdJMP C - - | | -address-components | P[ G | | local-postal-attributes | - - C - - | | GV Bphysical-delivery-office-name | - - C - - | | BVDJBphysical-delivery-office-number | - - C - - | | BVJ Bphysical-delivery-organization-name | - - C - - | | BV Bphysical-delivery-personal-name | - - C - - | | BV Bpost-office-box-address | - - C - - | | Bd Pposte-restante-address | - - C - - | | street-addressPd P | - - C - - | | unformatted-postal-address Pd P | - - - M - | | unique-postal-name | - P; ' - C - - | +- Domain-defined 'dP--------------------+-------------------------+ | domain-defined (one or more) P6 " | C C - - C | "a M+-------------------------------------+-------------------------+ +- Legend M\ H------------------------------------+ | MNEM mnemonic F formatted M Hd Pmandatory | | NUMR numeric U unformatted O optional | | POST postal Pb N C conditional | | TERM terminal | ND 0+---------------------------------------------+0d PThe forms of O/R address, summarized in the table, are individually defined and P4  described in the clauses below. 3 18.5.1Mnemonic O/R Addressd PA .I.gl:mnemonic O/R address; is one that mnemonically identifies a user or DL. PL 8It identifies an ADMD, and a user or DL relative to it.8O ;A mnemonic O/R address comprises the following attributes:;] Ia)One country-name and one administration-domain-name, which together I& identify an ADMD.MJM9b)One private-domain-name, one organization-name, one 9dDJPorganizational-unit-names, one personal-name or common-name, or a combination ofPd Pthe above; and optionally one or more domain-defined attributes; which together PP <identify a user or DL relative to the ADMD in item a above.<2J 18.5.2Numeric O/R Address_ KA .I.gl:numeric O/R address; is one that numerically identifies a user. It KC /identifies an ADMD, and a user relative to it./N :A numeric O/R address comprises the following attributes::] Ia)One country-name and one administration-domain-name, which together I&identify an ADMD.b Nb)One numeric-user-identifier and, conditionally, one private-domain-name, N[ Gwhich together identify the user relative to the ADMD in item a above.G\ Hc)Conditionally, one or more domain-defined attributes which provide HN :information additional to that which identifies the user.:1 18.5.3Postal O/R Addressd PA .I.gl:postal O/R address; is one that identifies a user by means of its postalP` Laddress. It identifies the PDS through which the user is to be accessed and L5 !gives the user's postal address.!Q =The following kinds of postal O/R address are distinguished:=` La).I.gl:formatted;: Said of a postal O/R address that specifies a user's L_ Kpostal address by means of several attributes. For this form of postal O/R Ka Maddress, this Recommendation prescribes the structure of postal addresses in M!  some detail. b Nb).I.gl:unformatted;: Said of a postal O/R address that specifies a user's Nd Ppostal address in a single attribute. For this form of postal O/R address, this PaDJMRecommendation largely does not prescribe the structure of postal addresses.MdJMPA postal O/R address, whether formatted or unformatted, comprises the following P  attributes: ] Ia)One country-name and one administration-domain-name, which together I& identify an ADMD.`J Lb)^^^^Conditionally, one private-domain-name, one physical-delivery-service-Lc O^^^^^^name, or both which together identify the PDS by means of which the user O- ^^^^^^is to be acces: &unformatted-postal-address attribute.&.5   unformatted- ;l O/R address comprises, additionally, one unformatted-K. postal-address attribute.M ` JNote - The total number of characters in the values of all attributes but Fd Pcountry-name, administration-domain-name, and physical-delivery-service-name in Pd Pa postal O/R address should be small enough to permit their rendition in 6 linesP 3 a postal O/R address O d Pof 30 characters, the size of a typical physical envelope window. The rendition Pd Palgorithm is PDAU-specific but is likely to include inserting delimiters (e.g., P< (spaces) between some attribute values.(oN!  algorithm is : physical envelope window. The rendition algorithm is K w ae inserting delimiters (e.g., spaces) K3 between some attribute values.3 18.5.4Terminal O/R Address` LA .I.gl:terminal O/R address; is one that identifies a user by means of the Ld Pnetwork address and, if required, the type of his terminal. It may also identifyPaDJMthe ADMD through which that terminal is accessed. In the case of a Telematic M` Lterminal, it gives the terminal's network address and possibly its terminal L` Lidentifier and terminal type. In the case of a Telex terminal, it gives its L"JMTelex number.O ;A terminal O/R address comprises the following attributes:;. a)One network-address.A -b)Conditionally, one terminal-identifier.-;J 'c)Conditionally, one terminal-type.'aMd)Conditionally, both one country-name and one administration-domain-name M5 !which together identify an ADMD.!` Le)Conditionally, one private-domain-name and, conditionally, one or more Lc Odomain-defined attributes, all of which provide information additional to that O/ which identifies the user.d PThe private-domain-name and the domain-defined attributes shall be present only P_ Kif the country-name and administration-domain-name attributes are present.K0 18.6Conditional Attributes ` L^^^^^^The presence or absence in a particular O/R address of the attributes LS ?marked conditional in Table 10/X.402 is determined as follows.? _ K If a user or DL is accessed through a PRMD, attributes used to route Kd Pmessages to the PRMD d Pprovides, in a postal address, additional information necessary to identify the P>JM*addressee (e.g., an organizational unit).*8Joining 20 . 9# provides, in a `=s-components; is a standard attribute that provides, in aPJM addressee ?=ditional information necessary to identify the addressee K4  (e.g., an organizational unit). d PThe va  address does =name that would do so). If present, the O/R address does N[tory name, an O/R address, or both. If present, theP  necessarily ? +the same and more (again see clause 18.5).+  the same and >uld do so). If present, the O/R address does the same and O2more (again see clause 18.5).\c OAt direct submission, the UA or MS of the originator of a message or p*o as to satisfy the postal addressing D0 of the users they identify. ify.) !J  19.Routing d PTo convey a message, probe, or report toward a user or the expansion point of a Pb NDL, an MTA must not only locate the user or DL (i.e., obtain its O/R address) N> *but also select a route to that location.*^ JExternal routing is an incremental and only loosely standardized process. Jd PSuggested below are several principles of external routing. Internal routing is P> *outside the scope of this Recommendation.*O ;The following principles are illustrative, not definitive:;c Oa)In an MHS that comprises a single MD, of course, routing is not an issue.Od Pb)A PRMD may be connected to a single, ADMD. When this is so, routing always P3 involves the ADMD necessarily.d Pc)An ADMD may be connected to multiple PRMDs. When this is so, routing may beP` Lbased upon conditional O/R address attributes, including but not limited to L) private-domain-name.d Pd)An MD may be directly connected to some but not all other MDs. When the O/RPaDJMaddress identifies a MD to which no direct connection exists, routing may be M_ Kbased upon .I.ba:routing;bilateral agreements with the MDs to which direct K@ ,connections do exist and other local rules.,d Pe)When the MD is directly connected to the MD identified by the O/R address, PH 4the object is typically routed to that MD directly.4_ Kf)By .I.ba:routing;bilateral agreement, one MD might route an object to KF 2another MD for the purpose, e.g., of conversion. 2aJMMg)An MD may route to a malformed O/R address provided (of course) that it MH4contains at least the attributes required to do so.4d PNote The bilateral agreements and local rules alluded to above are beyond the Pd Pscope of this Recommendation and may be based upon technical, policy, economic, P-J or other considerations. 8 $Section Five - Use of the Directory$" 20.Overviewd PThis section describes the uses to which the MHS may put the Directory if it is Pa Mpresent. If the Directory is unavailable to the MHS, how, if at all, the MHS MA -performs these same tasks is a local matter.-> *This section covers the following topics:*( a)Authentication) b)Name resolution& c)DL expansion/DJd)Capability assessment( 21.Authenticationb NA functional object may accomplish authentication using information stored in N# the Directory.) 22.Name Resolution\ HA functional object may accomplish name resolution using the Directory.Hd PTo obtain the O/R address(es) of a user or DL whose Directory name it possesses,Pa Man object presents that name to the Directory and requests from the object's M>*Directory entry the following attributes:*+JMa)MHS O/R Addresses8 $b)MHS Preferred Delivery Methods$^ JTo do this successfully, the object must first authenticate itself to the JS ?Directory and have access rights to the information requested.?& 23.DL Expansion_ KA functional object may accomplish DL expansion using the Directory, first KKJ 7verifying that the necessary submit permissions exist.7` LTo obtain the members of a DL whose Directory name it possesses, the object La Mpresents that name to the Directory and requests from the object's Directory M4  entry the following attributes: ( a)MHS DL Members3 b)MHS DL Submit Permissions8 $c)MHS Preferred Delivery Methods$d PTo do this successfully, the MTA must first authenticate itself to the DirectoryPI 5and have access rights to the information requested.5/DJ24.Capability Assessment^ JA functional object may assess the capabilities of a user or MS using the J  Directory. _ KThe following Directory attributes represent user capabilities of possible K6 "significance in Message Handling:"8 $a)MHS Deliverable Content Length$7 #b)MHS Deliverable Content Types#. c)MHS Deliverable EITs8$d)MHS Preferred Delivery Methods$] IThe following Directory attributes represent MS capabilities of possible I6 "significance in Message Handling:"9JM%a)MHS Supported Automatic Actions%5 !b)MHS Supported Content Types!; 'c)MHS Supported Optional Attributes'^ JTo assess a particular capability of a user or MS whose Directory name it Jd Ppossesses, the object presents that name to the Directory and requests from the P\ Hobject's Directory entry the attribute associated with that capability.HdJ PTo do this successfully, the MTA must first authenticate itself to the DirectoryPI 5and have access rights to the information requested.5 2 Section Six - OSI Realization" 25.OverviewTDJ@This section describes how the MHS is realized by means of OSI.@> *This section covers the following topics:*6 "a)Application service elements". b)Application contexts6 "26.Application Service Elements"_ KThis clause identifies the application service elements (.I.ab:ASEs;) that KG 3figure in the OSI realization of Message Handling.3d PIn OSI the communication capabilities of open systems are organized into groups PaMof related capabilities called ASEs. The present clause reviews this concept M\ Hfrom the OSI Reference Model, draws a distinction between symmetric and Hb Nasymmetric ASEs, and introduces the ASEs defined for or supportive of Message N  Handling. ` LNote Besides the ASEs discussed, the MHS relies upon the Directory Access LbJMNService Element defined in Recommendation X.519. However, since that ASE does Nd Pnot figure in the ACs for Message Handling (see Recommendation X.419), it is notP$ discussed here.) 26.1The ASE ConceptY EThe ASE concept is illustrated in Figure 12/X.402, which depicts two Ec Ocommunicating open systems. Only the OSI-related portions of the open systems, O] Icalled AEs, are shown. Each AE comprises a UE and one or more ASEs. A UE Id Prepresents the controlling or organizing portion of an AE which defines the openPdJ Psystem's role (e.g., that of an MTA). An ASE represents one of the communicationPb Ncapability sets, or services (e.g., for message submission or transfer), that N6 "the UE requires to play its role."\DJHThe relationship between two AEs in different open systems is called an Ha Mapplication association. The ASEs in each open system communicate with their Mc Opeer ASEs in the other open system via a presentation connection between them. Od PThat communication is what creates and sustains the relationship embodied in theP_ Kapplication association. For several ASEs to be successfully combined in a K` Lsingle AE, they must be designed to coordinate their use of the application L!  association. c O+----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 | | 08 | | 09 | | 10 | | OdP11 | | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20 | | 21 | | 22 PN :| | 23 | | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+:8 $Figure .F.:12/X.402 The ASE Concept$c OAn ASE plays the largely mechanical role of translating requests and responses Ob Nmade by its UE to and from the form dictated by the application protocol that Nd Pgoverns the ASE's interaction with its peer ASE in the open system to which the P] Iassociation connects it. The ASE realizes an abstract service, or a part I[JMGthereof, for purposes of OSI communication (see Recommendation X.407).Gd PNote Strictly speaking, an open system's role is determined by the behavior ofP^ Jits application processes. In the Message Handling context an application Jd Pprocess realizes a functional object of one of the types defined in clause 7. A PF 2UE in turn is one part of an application process.27 #26.2Symmetric and Asymmetric ASEs#[ GThe following two kinds of ASE, illustrated in Figure 13/X.402, can be G# distinguished:cJ Oa).I.gl:symmetric;: Said of an ASE by means of which a UE both supplies and OaDJMconsumes a service. The ASE for message transfer, e.g., is symmetric because M` Lboth open systems, each of which embodies an MTA, offer and may consume the L@ ,service of message transfer by means of it.,^ Jb).I.gl:asymmetric;: Said of an ASE by means of which a UE supplies or Jd Pconsumes a service, but not both, depending upon how the ASE is configured. The P_ KASE for message delivery, e.g., is asymmetric because only the open system Kc Oembodying an MTA offers the associated service and only the other open system, O< (which embodies a UA or MS, consumes it.(cO+----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 | | 08 | | 09 | | 10 | | Od P11 | | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20 | | 21 | | 22 PN :| | 23 | | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+:F 2Figure .F.:13/X.402 Symmetric and Asymmetric ASEs2d PWith respect to a particular asymmetric ASE, one UE supplies a service which thePd Pother consumes. The ASEs co-located with the UEs assist in the service's supply Pd Pand consumption. The resulting four roles are captured in Figure 14/X.402 and inP/ the following terminology:a Ma)x-.I.gl:supplying UE;: An application process that supplies the service M5JM!represented by asymmetric ASE x.!d Pb)x-.I.gl:supplying ASE;: An asymmetric ASE x configured for co-location withP' an x-supplying-UE.a Mc)x-.I.gl:consuming UE;: An application process that consumes the service M5 !represented by asymmetric ASE x.!d Pd)x-.I.gl:consuming ASE;: An asymmetric ASE x configured for co-location withP' an x-consuming-UE.cDJO+----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 | | 08 | | 09 | | 10 | | OdJ P11 | | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20 | | 21 | | 22 PN :| | 23 | | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+:H 4Figure .F.:14/X.402 Terminology for Asymmetric ASEs4[ GAs indicated, the four roles described above are defined relative to a Gb Nparticular ASE. When an AE comprises several asymmetric ASEs, these roles are Nd Passigned independently for each ASE. Thus, as shown in Figure 15/X.402, a singlePd PUE might serve as the consumer with respect to one ASE and as the supplier with P(respect to another.c O+----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 | | 08 | | 09 | | 10 | | Od P11 | | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20 | | 21 | | 22 PN :| | 23 | | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+:A -Figure .F.:15/X.402 Multiple Asymmetric ASEs-/ 26.3Message Handling ASEsb NThe ASEs that provide the various Message Handling services are listed in the Nd Pfirst column of Table 11/X.402. For each ASE listed, the second column indicatesP[ Gwhether it is symmetric or asymmetric. The third column identifies the Gc Ofunctional objects--UAs, MSs, MTAs, and AUs--that are associated with the ASE, O7 #either as consumer or as supplier.#=JM)Table .T.:11/X.402 Message Handling ASEs)d P+------+------+--------------------+ | | | Functional Objects | | PX D | +--------------------+ | ASE | Form | UA MS MTA AU | D^ J+------+------+--------------------+ | MTSE | SY | - - CS - | Jd P+------+------+--------------------+ | MSSE | ASY | C CS S - | | MDSEPdDJP| ASY | C C S - | | MRSE | ASY | C S - - | | MASE | ASY P\ H | C CS S - | +------+------+--------------------+ +- Legend Hd P-------------------+ | SY symmetric C consumer | | ASY asymmetric S supplierP5J !| +----------------------------+!d PThe Message Handling ASEs, summarized in the table, are individually introduced PS ?in the clauses below. Each is defined in Recommendation X.419.?/ 26.3.1Message Transfera MThe Message Transfer Service Element (.I.ab:MTSE;) is the means by which the M;'transfer transmittal step is effected.'1 26.3.2Message Submissionc OThe Message Submission Service Element (.I.ab:MSSE;) is the means by which the O= )submission transmittal step is effected.)/ 26.3.3Message Deliverya MThe Message Delivery Service Element (.I.ab:MDSE;) is the means by which the M; 'delivery transmittal step is effected.'0 26.3.4Message Retrievalb NThe Message Retrieval Service Element (.I.ab:MRSE;) is the means by which the N< (retrieval transmittal step is effected.(5 !26.3.5Message Administration!d PThe Message Administration Service Element (.I.ab:MASE;) is the means by which aP` LUA, MS, or MTA places on file with one another information that enables and L`JMLcontrols their subsequent interaction by means of the MSSE, MDSE, MRSE, and L MASE.) 26.4Supporting ASEscDJOThe general-purpose ASEs upon which Message Handling ASEs depend are listed in O_ Kthe first column of Table 12/X.402. For each listed ASE, the second column KE 1indicates whether it is symmetric or asymmetric.17 #Table .T.:12/X.402 Supporting ASEs#d P+------+------+ | ASE | Form | +------+------+ | ROSE | SY | | RTSE | SY | PaJ M| ACSE | SY | +------+------+ +- Legend -------+ | SY symmetric | | ASY M4  asymmetric | +----------------+ d PThe supporting ASEs, summarized in the table, are individually introduced in theP#clauses below.0 26.4.1Remote Operationsb NThe Remote Operations Service Element (.I.ab:ROSE;) is the means by which the Nc Oasymmetric Message Handling ASEs structure their request-response interactions OB .between consuming and supplying open systems..A -The ROSE is defined in Recommendation X.219.-0 26.4.2Reliable Transfer^ JThe Reliable Transfer Service Element (.I.ab:RTSE;) is the means by which J^ Jvarious symmetric and asymmetric Message Handling ASEs convey information Jd Pobjects--especially large ones (e.g., facsimile messages)--between open systems PN :so as to ensure their safe-storage at their destinations.:A -The RTSE is defined in Recommendation X.218.-2 26.4.3Association Controld PThe Association Control Service Element (.I.ab:ACSE;) is the means by which all Pd Papplication associations between open systems are established, released, and in P,JMother respects managed.ADJ-The ACSE is defined in Recommendation X.217.-. 27.Application Contexts_ KIn OSI the communication capabilities (i.e., ASEs) of two open systems are KY Emarshalled for a particular purpose by means of application contexts Ea M(.I.ab:ACs;). An AC is a detailed specification of the use of an association M@ ,between two open systems, i.e., a protocol.,Y EAn AC specifies how the association is to be established (e.g., what E_J Kinitialization parameters are to be exchanged), what ASEs are to engage in KcOpeer-to-peer communication over the association, what constraints (if any) are O\ Hto be imposed upon their individual use of the association, whether the H_ Kinitiator or responder is the consumer of each asymmetric ASE, and how the K` Lassociation is to be released (e.g., what finalization parameters are to be L  exchanged). [ GEvery AC is named (by an ASN.1 Object Identifier). The initiator of an Gd Passociation indicates to the responder the AC that will govern the association'sPO ;use by conveying the AC's name to it by means of the ACSE.;d PAn AC also identifies by name (an ASN.1 Object Identifier) the abstract syntaxesPb Nof the APDUs that an association may carry as a result of its use by the AC's Nb NASEs. Conventionally one assigns a name to the set of APDUs associated either N\ Hwith each individual ASE or with the AC as a whole. The initiator of an H] Iassociation indicates to the responder the one or more abstract syntaxes IX Dassociated with the AC by conveying their names to it via the ACSE.Dd PThe abstract syntax of an APDU is its structure as an information object (e.g., P^ Jan ASN.1 Set comprising an Integer command code and an IA5 String command JdDJPargument). It is distinguished from the APDU's transfer syntax which is how the P`JMLinformation object is represented for transmission between two open systems Ld P(e.g., one octet denoting an ASN.1 Set, followed by one octet giving the length P' of the Set, etc.).d PThe ACs by means of which the various Message Handling services are provided areP_ Kspecified in Recommendation X.419. These protocols are known as .I.ab:P1;, K. .I.ab:P3;, and .I.ab:P7;.c ONote The nature of a message's content does not enter into the definition of OdPMessage Handling ACs because the content is encapsulated (as an Octet String) inPDJ 0the protocols by means of which it is conveyed.0  Annexes^ JAnnex A (to Recommendation X.402) Directory Object Classes and AttributesJK 7This annex is an integral part of this Recommendation.7] ISeveral Directory object classes, attributes, and attribute syntaxes are Ic Ospecific to Message Handling. These are defined in the present annex using the Ob NOBJECT-CLASS, ATTRIBUTE, and ATTRIBUTE-SYNTAX macros of Recommendation X.501, N" respectively.` LTemporary note The details of this annex are subject to modification as a Ld Presult of the final meeting of the CCITT Special Rapporteur on Directory SystemsP> *(Q35/VII) in Gloucester in November 1987.*( A.1Object Classes_DJKThe object classes specific to Message Handling are those specified below.K4  A.1.1MHS Distribution List ` LAn .I.ot:MHS Distribution List; object is a DL. The attributes in its entry L`JMLidentify its common name, submit permissions, and O/R addresses and, to the Lc Oextent that the relevant attributes are present, describe the DL, identify its O] Iorganization, organizational units, and owner; cite related objects; and Id Pidentify its deliverable content types, deliverable EITs, members, and preferredP& delivery methods.d P.I.va:mhs-distribution-list; OBJECT-CLASS SUBCLASS OF top MUST PO ;CONTAIN { commonName, ;dPmhs-dl-submit-permissions, mhs-or-addresses} MAYP] ICONTAIN { description, organization, I_ KorganizationalUnitName, owner, seeAlso, KdJ Pmhs-deliverable-content-types, mhs-deliverable-eits,P  O ;mhs-dl-members, ;S ?mhs-preferred-delivery-methods} ::= ?0 id-oc-mhs-distribution-list0 A.1.2MHS Message Stored PAn .I.ot:MHS Message Store; object is an AE that realizes an MS. The attributes Pd Pin its entry, to the extent that they are present, describe the MS, identify itsPa Mowner, and enumerate the optional attributes, automatic actions, and content M' types it supports.[DJG.I.va:mhs-message-store; OBJECT-CLASS SUBCLASS OF Gc OapplicationEntity MAY CONTAIN { description, owner, O  O ;mhs-supported-optional-attributes, ;OJM;mhs-supported-automatic-actions, ;S ?mhs-supported-content-types} ::= ?, id-oc-mhs-message-store9 %A.1.3MHS Message Transfer Agent%d PAn .I.ot:MHS Message Transfer Agent; object is an AE that implements an MTA. ThePcOattributes in its entry, to the extent that they are present, describe the MTA OO ;and identify its owner and its deliverable content length.;[ G.I.va:mhs-message-transfer-agent; OBJECT-CLASS SUBCLASS OF Gc OapplicationEntity MAY CONTAIN { description, owner, O J S ?mhs-deliverable-content-length} hods.= W Atypes, and EITs; its MS; and its preferred delivery methods.=[DJG.I.va:mhs-user; OBJECT-CLASS SUBCLASS OF Gd PORGANIZATIONALPERSON MUST CONTAIN { mhs-or-addresses} MAYPa MCONTAIN { mhs-deliverable-content-length, mhs-deliverable-MG 3content-types, mhs-deliverable-eits, 3  O ;mhs-message-store, ;SJM?mhs-preferred-delivery-methods} ::= ?- id-oc-mhs  0DJA.1.5^^^MHS User Agent c O^^^^^^An MHS User Agent; object is an AE that realizes a UA. The attributes in Oa Mits entry, to the extent that they are present, identify the UA's owner; its M^ Jdeliverable content length, content types, and EITs; and its O/R address.J [ G.I.va:mhs-user-agent; OBJECT-CLASS SUBCLASS OF GZ FapplicationEntity MAY CONTAIN { owner, mhs-F` Ldeliverable-content-length, mhs-deliverable-content-types, mhs-deliverable-L7 eits,  d P^^^^^^An MHS User object is a generic MHS user. (The generic user can have, for Pd Pexample, a business address, a residential address, or both.) The attributes in PcJMOits entry identify the user's O/R address and, to the extent that the relevant Od Pattributes are present, identify the user's deliverable content length, content PQ =types, and EITs; its MS; and its preferred delivery metPwhich the user takes delivery of physical N  messages.  ^^^^^^d P^^^^^^A formatted postal O/R address comprises, additionally, one of each postalPa Maddressing attribute (see Table 9/X.402), except unformatted-postal-address, MI 5that the PDS requires to identify the postal patron.5 Y E^^^^^^An unformatted postal O/R address comprises, additionally, one E eits, ! JMJ6mhs-or-addresses} ::= id-oc-mhs-user-agent6$ A.2Attributes[ GThe attributes specific to Message Handling are those specified below.G= )A.2.1MHS Deliverable Content Length)_ KThe .I.ot:MHS Deliverable Content Length; attribute identifies the maximum KV Bcontent length of the messages whose delivery a user will aA.3.2MHS O/R Address+ A.3.3MHS O/R Name D 0BReference Definition of Object Identifiers069>Y ECReference Definition of Directory Object Classes and AttributesE6 "at-mhs-preferred-delivery-methods"> *A.2.9MHS Supported Automatic Actions*b NThe .I.ot:MHS Supported Automatic Actions; attribute identifies the automatic Nccept.B= )A value of this attribute is an Integer.)d P.I.va:mhs-deliverable-content-length; ATTRIBUTE WITH ATTRIBUTE-SYNTAXPZ FintegerSyntax SINGLE VALUE ::= id-at-mhs-deliverable-content-lengthF<J (A.2.2MHS Deliverable Content Types(d PThe .I.ot:MHS Deliverable Content Types; attribute identifies the content types PG 3of the messages whose delivery a user will accept.3G 3A value of this attribute is an Object Identifier.3d P.I.va:mhs-deliverable-content-types; ATTRIBUTE WITH ATTRIBUTE-SYNTAXPSDJ?objectIdentifierSyntax MULTI VALUE ::= ?8 $id-at-mhs-deliverable-content-types$3 A.2.3MHS Deliverable EITsb NThe .I.ot:MHS Deliverable EITs; attribute identifies the EITs of the messages N7 #whose delivery a user will accept.#G 3A value of this attribute is an Object Identifier.3d P.I.va:mhs-deliverable-eits; ATTRIBUTE WITH ATTRIBUTE-SYNTAXPS ?objectIdentifierSyntax MULTI VALUE ::= ?/ id-at-mhs-deliverable-eits- A.2.4MHS DL MembersS?The .I.ot:MHS DL Members; attribute identifies a DL's members.?>JM*A value of this attribute is an O/R name.*d P.I.va:mhs-dl-members; ATTRIBUTE WITH ATTRIBUTE-SYNTAXPS ?mhs-or-name-syntax MULTI VALUE ::= ?) id-at-mhs-dl-members8 $A.2.5MHS DL Submit Permissions$d PThe .I.ot:MHS DL Submit Permissions; attribute identifies the users and DLs thatP1 may submit messages to a DL.I 5A value of this attribute is a DL submit permission.5d P.I.va:mhs-dl-submit-permissions; ATTRIBUTE WITH ATTRIBUTE-SYNTAXP_ Kmhs-dl-submit-permission-syntax MULTI VALUE ::= K4J  id-at-mhs-dl-submit-permissions 0 A.2.6MHS Message Store[ GThe .I.ot:MHS Message Store; attribute identifies a user's MS by name.GSDJ?The value of this attribute is a Directory distinguished name.?d P.I.va:mhs-message-store; ATTRIBUTE WITH ATTRIBUTE-SYNTAXPS ?distinguishedNameSyntax SINGLE VALUE ::= ?, id-at-mhs-message-store0 A.2.7MHS O/R AddressesZ FThe .I.ot:MHS O/R Addresses; attribute specifies a user's or DL's O/R F  addresses. A -A value of this attribute is an O/R address.-d P.I.va:mhs-or-addresses; ATTRIBUTE WITH ATTRIBUTE-SYNTAXPS ?mhs-or-address-syntax MULTI VALUE ::= ?+id-at-mhs-or-addresses= )A.2.8MHS Preferred Delivery Methods)` LThe .I.ot:MHS Preferred Delivery Methods; attribute identifies, in order of LSJM?decreasing preference, the methods of delivery a user prefers.?N :A value of this attribute is a preferred delivery method.:d P.I.va:mhs-preferred-delivery-methods; ATTRIBUTE WITH ATTRIBUTE-SYNTAXPc OReqiestedDeliveryMethod MATCHES FOR EQUALITY SINGLE VALUE ::= id-OVALUE ::= hs-preferred-delivery-methods%> *A.2.9MHS Supported AutoT @Re` LReqiestedDeliveryMethod MATCHES FOR EQUALITY SINGLE VALUE ::= L7 #actions that an MS fully supports.#G 3A value of this attribute is an Object Identifier.3d P.I.va:mhs-supported-automatic-actions; ATTRIBUTE WITH ATTRIBUTE-SYNTAXPSJ ?objectIdentifierSyntax MULTI VALUE ::= ?:DJ&id-at-mhs-supported-automatic-actions&: &A.2.10MHS Supported Content Types&d PThe .I.ot:MHS Supported Content Types; attribute identifies the content types ofPQ =the messages whose syntax and semantics a MS fully supports.=G 3A value of this attribute is an Object Identifier.3d P.I.va:mhs-supported-content-types; ATTRIBUTE WITH ATTRIBUTE-SYNTAXPS ?objectIdentifierSyntax MULTI VALUE ::= ?6 "id-at-mhs-supported-content-types"@ ,A.2.11MHS Supported Optional Attributes,c OThe .I.ot:MHS Supported Optional Attributes; attribute identifies the optional O:&attributes that an MS fully supports.&G 3A value of this attribute is an Object Identifier.3d P.I.va:mhs-supported-optional-attributes; ATTRIBUTE WITH ATTRIBUTE-SYNTAXPS ?objectIdentifierSyntax MULTI VALUE ::= ?< (id-at-mhs-supported-optional-attributes(,JMA.3Attribute Syntaxesc OThe attribute syntaxes specific to Message Handling are those specified below.O7 #A.3.1MHS DL Submit Permission#d PThe .I.ot:MHS DL Submit Permission; attribute syntax characterizes an attribute PA -each of whose values is a submit permission.-V B.I.va:mhs-dl-submit-permission-syntax; ATTRIBUTE-SYNTAX SYNTAX BS ?DLSubmitPermission MATCHES FOR EQUALITY ::= ?3 id-as-mhs-dl-submit-permissionc O.I.ty:DLSubmitPermission; ::= CHOICE { individual [0] OcDJOORName, member-of-dl [1] ORName, pattern-match [2] OKJ 7ORNamePattern, member-of-group [3] Name}7X DA presented DL submit permission value shall be of type Individual.Da MA DL submit permission, depending upon its type, grants submit access to the M: &following zero or more users and DLs:&d Pa)Individual: The user or (unexpanded) DL any of whose O/R names is equal to P, the specified O/R name.d Pb)Member-of-dl: Each member of the DL, any of whose O/R names is equal to thePK 7specified O/R name, or of each nested DL, recursively.7d Pc)Pattern-match: Each user or (unexpanded) DL any of whose O/R names matches P4 the specified O/R name pattern. 4  .I.ty:ORNamePattern; ::= ORName d Pd)Member-of-group: Each member of the group-of-names whose name is specified,PC /or of each nested group-of-names, recursively./] IA presented value is equal to a target value of this type if the two are Id Pidentical, attribute by attribute. Additionally, equality may be declared under P@ ,other conditions which are a local matter. ,.JMA.3.2MHS O/R Addressc OThe .I.ot:MHS O/R Address; attribute syntax characterizes an attribute each of O4  whose values is an O/R address. ` L.I.va:mhs-or-address-syntax; ATTRIBUTE-SYNTAX SYNTAX ORAddress LJ 6MATCHES FOR EQUALITY ::= id-as-mhs-or-address6c OA presented O/R address value is equal to a target O/R address value under the O: &conditions specified in clause 18.4. &+DJA.3.3MHS O/R Name` LThe .I.ot:MHS O/R Name; attribute syntax characterizes an attribute each of L1 whose values is an O/R name.dJ P.I.va:mhs-or-name-syntax; ATTRIBUTE-SYNTAX SYNTAX ORName MATCHESP9 %FOR EQUALITY ::= id-as-mhs-or-name%b NA presented O/R name value is equal to a target O/R name value if the two are Nd Pidentical, attribute by attribute. Additionally, equality may be declared under P? +other conditions which are a local matter.+ aMAnnex B (to Recommendation X.402) Reference Definition of Object IdentifiersMK 7This annex is an integral part of this Recommendation.7b NThis annex defines for reference purposes various Object Identifiers cited in N@ ,the ASN.1 module of annex C. It uses ASN.1.,c OAll Object Identifiers this Recommendation assigns are assigned in this annex. Od PThe annex is definitive for all but those for ASN.1 modules and MHS itself. The Pa Mdefinitive assignments for the former occur in the modules themselves; other MV Breferences to them appear in IMPORT clauses. The latter is fixed.BJM ---------- d P.I.mo:MHSObjectIdentifiers; {joint-iso-ccitt mhs-motis(6) arch(5) PZ Fmodules(0) object-identifiers(0)} DEFINITIONS IMPLICIT TAGS ::= BEGINF  -- Prologue + -- Exports everything.,DJIMPORTS -- nothing -- ;4  .I.ty:ID; ::= OBJECT IDENTIFIER # -- MHS AspectsZ F.I.va:id-mhsac; ID ::= {joint-iso-ccitt mhs-motis(6) mhsac(0)} -- MHS Fd PApplication Contexts -- See Recommendation X.419. .I.va:id-ipms; ID ::=P`J L{joint-iso-ccitt mhs-motis(6) ipms (1)} -- Interpersonal LW CMessaging -- See Recommendation X.420. .I.va:id-asdc; ID ::= Cc O{joint-iso-ccitt mhs-motis(6) asdc (2)} -- Abstract Service Od PDefinition Conventions -- See Recommendation X.407. .I.va:id-mts; ID ::=Pc O{joint-iso-ccitt mhs-motis(6) mts (3)} -- Message Transfer Oc OSystem -- See Recommendation X.411. .I.va:id-ms; ID ::= {joint-iso-ccitt Od Pmhs-motis(6) ms (4)} -- Message Store -- See RecommendationPd PX.413. .I.va:id-arch; ID ::= {joint-iso-ccitt mhs-motis(6) arch (5)} -- OverallPVBArchitecture -- See this Recommendation. .I.va:id-group; ID ::= B\ H{joint-iso-ccitt mhs-motis(6) group(6)} -- Reserved.H" -- Categoriesd P.I.va:id-mod; ID ::= {id-arch 0} -- modules; not definitive .I.va:id-oc; ID ::=P` L{id-arch 1} -- object classes .I.va:id-at; ID ::= {id-arch 2} -- attribute LQ =types .I.va:id-as; ID ::= {id-arch 3} -- attribute syntaxes=  -- Modules c O.I.va:id-object-identifiers; ID ::= {id-mod 0} -- not definitive OcJMO.I.va:id-directory-objects-and-attributes; ID ::= {id-mod 1} -- not definitiveO& -- Object classesM 9.I.va:id-oc-mhs-distribution-list; ID ::= {id-oc 0} 9MDJ9.I.va:id-oc-mhs-message-store; ID ::= {id-oc 1} 9M 9.I.va:id-oc-mhs-message-transfer-agent; ID ::= {id-oc 2} 9M 9.I.va:id-oc-mhs-organizational-user; ID ::= {id-oc 3} 9M 9.I.va:id-oc-mhs-residential-user; ID ::= {id-oc 4} 9M 9.I.va:id-oc-mhs-user-agent; ID ::= {id-oc 5}9" -- AttributesU A.I.va:id-at-mhs-deliverable-content-length; ID ::= {id-at 0} AUJ A.I.va:id-at-mhs-deliverable-content-types; ID ::= {id-at 1} AU A.I.va:id-at-mhs-deliverable-eits; ID ::= {id-at 2} AU A.I.va:id-at-mhs-dl-members; ID ::= {id-at 3} AU A.I.va:id-at-mhs-dl-submit-permissions; ID ::= {id-at 4} AU A.I.va:id-at-mhs-message-store; ID ::= {id-at 5} AU A.I.va:id-at-mhs-or-addresses; ID ::= {id-at 6} AU A.I.va:id-at-mhs-preferred-delivery-methods; ID ::= {id-at 7} AU A.I.va:id-at-mhs-supported-automatic-actions; ID ::= {id-at 8} AUA.I.va:id-at-mhs-supported-content-types; ID ::= {id-at 9} AU A.I.va:id-at-mhs-supported-optional-attributes; ID ::= {id-at 10}A* -- Attribute syntaxesK 7.I.va:id-as-mhs-dl-submit-permission; ID ::= {id-as 0} 7d P.I.va:id-as-mhs-or-address; ID ::= {id-as 1} .I.va:id-as-mhs-or-name; P2  ID ::= {id-as 2}3 END -- of MHSObjectIdentifiers _DJKAnnex C (to Recommendation X.402) Reference Definition of Directory Object K+ Classes and AttributesK 7This annex is an integral part of this Recommendation.7c OThis annex, a supplement to annex A, defines for reference purposes the object Oa Mclasses, attributes, and attribute syntaxes specific to Message Handling. It Md Puses the OBJECT-CLASS, ATTRIBUTE, and ATTRIBUTE-SYNTAX macros of Recommendation P X.501.  ---------- dJ P.I.mo:MHSDirectoryObjectsAndAttributes; {joint-iso-ccitt mhs-motis(6) arch(5) PQ =modules(0) directory(1)} DEFINITIONS IMPLICIT TAGS ::= BEGIN=  -- Prologue + -- Exports everything.O ;IMPORTS -- MHS Object Identifiers ;b Nid-as-mhs-dl-submit-permission, id-as-mhs-or-address, id-as-mhs-or-name, NO ;id-at-mhs-deliverable-content-length, ;O ;id-at-mhs-deliverable-content-types, ;O;id-at-mhs-deliverable-eits, id-at-mhs-dl-members, ;O ;id-at-mhs-dl-submit-permissions, id-at-mhs-message-store, ;R >id-at-mhs-or-addresses, id-at-mhs-preferred-delivery-methods, >O ;id-at-mhs-supported-automatic-actions, ;OJM;id-at-mhs-supported-content-types, ;O ;id-at-mhs-supported-optional-attributes, ;O ;id-oc-mhs-distribution-list, id-oc-mhs-message-store, ;O ;id-oc-mhs-message-transfer-agent, ;d Pid-oc-mhs-organizational-user, id-oc-mhs-residential-user, id-oc-mhs-user-agent,P DJd P---- FROM MHSObjectIdentifiers {joint-iso-ccitt mhs-motis(6) arch(5) P_ Kmodules(0) object-identifiers(0)} -- MTS Abstract KY EService ORAddress, ORName, PreferredDeliveryMethod ---- FROM Ec OMTSAbstractService {joint-iso-ccitt mhs-motis(6) mts(3) O^ Jmodules(0) mTS-abstract-service(3)} -- Information Ja MFramework ATTRIBUTE, ATTRIBUTE-SYNTAX, Name, OBJECT-CLASS Ma M---- FROM InformationFramework {joint-iso-ccitt  ds(5) modules(1) MbJ NinformationFramework(1)} -- Selected Object Classes applicationEntity, N] IorganizationalPerson, residentialPerson, top ---- FROM Ia MSelectedObjectClasses {joint-iso-ccitt  ds(5) modules(1) M[ GselectedObjectClasses(6)} -- Selected Attribute Types commonName, G^ Jdescription, distinguishedNameSyntax, integerSyntax, JO ;objectIdentifierSyntax, organization, ;Y EorganizationalUnitName, owner, seeAlso ---- FROM Ea MSelectedAttributeTypes {joint-iso-ccitt  ds(5) modules(1) M/selectedAttributeTypes(5)}& -- OBJECT CLASSES- -- MHS Distribution Listd P.I.va:mhs-distribution-list; OBJECT-CLASS SUBCLASS OF top MUST POJM;CONTAIN { commonName, ;d Pmhs-dl-submit-permissions, mhs-or-addresses} MAYP] ICONTAIN { description, organization, I_ KorganizationalUnitName, owner, seeAlso, Kd Pmhs-deliverable-content-types, mhs-deliverable-eits,P $DJ& ;mhs-dl-members, ;S ?mhs-preferred-delivery-methods} ::= ?0 id-oc-mhs-distribution-list) -- MHS Message S DJsage-store; OBJECT-CLASS SUBCLASS OF Gc OapplicationEntity MAY CONTAIN { description, owner, O J O ;mhs-supported-optional-attributes, ;O ;mhs-supported-automatic-actions, ;S ?mhs-supported-content-types} ::= ?, id-oc-mhs-message-store2 -- MHS Message Transfer Agent[ G.I.va:mhs-message-transfer-agent; OBJECT-CLASS SUBCLASS OF Gc OapplicationEntity MAY CONTAIN { description, owner, O S ?mhs-deliverable-content-length} ::= ?5 !id-oc-mhs-message-transfer-agent!/JM-- MHS Organizational User[ G.I.va:mhs-organizational-user; OBJECT-CLASS SUBCLASS OF Gc OorganizationalPerson MUST CONTAIN { mhs-or-address} MAY OQ =CONTAIN { mhs-deliverable-content-length, =d Pmhs-deliverable-content-types, mhs-deliverable-eits,P DJO ;mhs-message-store, ;S ?mhs-preferred-delivery-methods} ::= ?2 id-oc-mhs-organizational-user, -- MHS Residential User[ G.I.va:mhs-residential-user; OBJECT-CLASS SUBCLASS OF Gc OresidentialPerson MUST CONTAIN { mhs-or-address} MAY OQ =CONTAIN { mhs-deliverable-content-length, =dJ Pmhs-deliverable-content-types, mhs-deliverable-eits,P  O ;mhs-message-store, ;S ?mhs-preferred-delivery-methods} ::= ?/ id-oc-mhs-residential-user& -- MHS User Agent[ G.I.va:mhs-user-agent; OBJECT-CLASS SUBCLASS OF GVBapplicationEntity MAY CONTAIN { owner, BO ;mhs-deliverable-content-length, ;d Pmhs-deliverable-content-types, mhs-deliverable-eits,P JM 6mhs-or-address} ::= id-oc-mhs-user-agent6" -- ATTRIBUTES6 "-- MHS Deliverable Content Length"d P.I.va:mhs-deliverable-content-length; ATTR JMZ FintegerSyntax SINGLE VALUE ::= id-at-mhs-deliverable-content-lengthF5DJ!-- MHS Deliverable Content Types!d P.I.va:mhs-deliverable-content-types; ATTRIBUTE WITH ATTRIBUTE-SYNTAXPS ?objectIdentifierSyntax MULTI VALUE ::= ?8 $id-at-mhs-deliverable-content-types$, -- MHS Deliverable EITsd P.I.va:mhs-deliverable-eits; ATTRIBUTE WITH ATTRIBUTE-SYNTAXPS ?objectIdentifierSyntax MULTI VALUE ::= ?/ id-at-mhs-deliverable-eits&J -- MHS DL Membersd P.I.va:mhs-dl-members; ATTRIBUTE WITH ATTRIBUTE-SYNTAXPS ?mhs-or-name-syntax MULTI VALUE ::= ?) id-at-mhs-dl-members1 -- MHS DL Submit Permissionsd P.I.va:mhs-dl-submit-permissions; ATTRIBUTE WITH ATTRIBUTE-SYNTAXP_ Kmhs-dl-submit-permission-syntax MULTI VALUE ::= K4  id-at-mhs-dl-submit-permissions )-- MHS O/R Addressesd P.I.va:mhs-or-addresses; ATTRIBUTE WITH ATTRIBUTE-SYNTAXPS ?mhs-or-address-syntax MULTI VALUE ::= ?+ id-at-mhs-or-addresses)JM-- MHS Message Stored P.I.va:mhs-message-store; ATTRIBUTE WITH ATTRIBUTE-SYNTAXPS ?distinguishedNameSyntax SINGLE VALUE ::= ?, id-at-mhs-message-store6 "-- MHS Preferred Delivery Methods"d P.I.va:mhs-preferred-delivery-methods; ATTRIBUTE WITH ATTRIBUTE-SYNTAXP_DJKPreferredDeliveryMethod MATCHES FOR EQUALITY MULTI VALUE ::= K9 %id-at-mhs-preferred-delivery-methods%7 #-- MHS Supported Automatic Actions#d P.I.va:mhs-supported-automatic-actions; ATTRIBUTE WITH ATTRIBUTE-SYNTAXPS ?objectIdentifierSyntax MULTI VALUE ::= ?: &id-at-mhs-supported-automatic-actions&3 -- MHS Supported Content Typesd P.I.va:mhs-supported-content-types; ATTRIBUTE WITH ATTRIBUTE-SYNTAXPSJ ?objectIdentifierSyntax MULTI VALUE ::= ?6 "id-at-mhs-supported-content-types"9 %-- MHS Supported Optional Attributes%d P.I.va:mhs-supported-optional-attributes; ATTRIBUTE WITH ATTRIBUTE-SYNTAXPS ?objectIdentifierSyntax MULTI VALUE ::= ?< (id-at-mhs-supported-optional-attributes(* -- ATTRIBUTE SYNTAXES0 -- MHS DL Submit PermissionVB.I.va:mhs-dl-submit-permission-syntax; ATTRIBUTE-SYNTAX SYNTAX BS ?DLSubmitPermission MATCHES FOR EQUALITY ::= ?3 id-as-mhs-dl-submit-permissionc O.I.ty:DLSubmitPermission; ::= CHOICE { individual [0] OcJMOORName, member-of-dl [1] ORName, pattern-match [2] OK 7ORNamePattern, member-of-group [3] Name}74  .I.ty:ORNamePattern; ::= ORName ' -- MHS O/R Address` L.I.va:mhs-or-address-syntax; ATTRIBUTE-SYNTAX SYNTAX ORAddress LJ 6MATCHES FOR EQUALITY ::= id-as-mhs-or-address6$DJ-- MHS O/R Named P.I.va:mhs-or-name-syntax; ATTRIBUTE-SYNTAX SYNTAX ORName MATCHESP9 %FOR EQUALITY ::= id-as-mhs-or-name%+ END -- of MHSDirectory G 3Annex D (to Recommendation X.402) Security Threats3D 0This annex is not a part of this Recommendation0d PAn overview of MHS security threats is provided in clause 15.1 of RecommendationP\ HX.400. This considers threats as they appear in an MHS: access threats, Hc Ointer-message threats, intra-message threats, and message store threats. These OD 0threats can appear in various forms as follows:0$ a)Masquerade, b)Message sequencing5 !c)Modification of information!+d)Denial of service0 e)Leakage of information% f)Repudiation+ g)Other MHS threatsdJMPIn addition, they may occur by accident or by malicious intent and may be activeP] Ior passive. Attacks on the MHS will address potential weaknesses and may Ib Ncomprise of a number of threats. This annex deals with individual threats and Nb Nalthough consideration is given to a number of broad classes of threat, it is N) not a complete list.aJ MTable 13/X.402 indicates how these threats can be met using the MHS security Mc Oservices. The list of threats given here is indicative rather than definitive.OD 0Table .T.:13/X.402 Use of MHS Security Services0dDJP+-------------------------------+-------------------------------+ | THREAT PV B | SERVICES | +- MASQUERADE Bd P------------------+-------------------------------+ | Impersonation and misuse Pb N | Message Origin Authentication | | of the MTS | Probe N^ JOrigin Authentication | | | Secure Access Jd PManagement | | Falsely acknowledge receipt | Proof of Delivery P` L | | Falsely claim to originate | Message Origin Authentication | | a Lc Omessage | | | Impersonation of Od Pan MTA to | Proof of submission | | an MTS-user |Pd PReport Origin Authentication | | | Secure Access Pd PManagement | | Impersonation of an MTA to | Report Origin AuthenticationPd P | | another MTA | Secure Access Management | +- MESSAGE Pd PSEQUENCING ----------+-------------------------------+ | Replay of messages P_ K | Message Sequence Integrity | | Re-ordering of messages | KdPMessage Sequence Integrity | | Pre-play of messages | Pd P | | Delay of messages | P\ H | +- MODIFICATION OF INFORMATION -+-------------------------------+ | Hd PModification of messages | Connection Integrity | | PdJMP | Content Integrity | | Destruction of messages Pd P | Message Sequence Integrity | | Corruption of routing and | Pd P | | other management information | P`J L | +- DENIAL OF SERVICE -----------+-------------------------------+ | Ld PDenial of communications | | | MTA flooding Pd P | | | MTS flooding PG 3 | | +- REPUDIATION 3d P-----------------+-------------------------------+ | Denial of origin P[DJG | Non-repudiation of Origin | | Denial of submission | GV BNon-repudiation of Submission | | Denial of delivery | BN :Non-repudiation of Delivery | +- LEAKAGE OF INFORMATION :^ J------+-------------------------------+ | Loss of confidentiality | J^ JConnection Confidentiality | | | Content J[ GConfidentiality | | Loss of anonymity | Message Flow Gd PConfidentiality | | Misappropriation of messages | Secure Access Management Pd P | | Traffic analysis | Message Flow Confidentiality | +- OTHER P^ JTHREATS ---------------+-------------------------------+ | Originator not Jd Pcleared for | Secure Access Management | | Message Security Label P` L | Message Security Labelling | | MTA/MTS-user not cleared for | Secure Ld PAccess Management | | Security Context | Pd P | | Misrouting | Secure Access Management | | P_ K | Message Security Labelling | | Differing KJ6labelling policies | | 6V B+-------------------------------+-------------------------------+B$ D.1Masqueraded PMasquerade occurs when an entity successfully pretends to be a different entity PdJMPand can take place in a number of ways. An unauthorized MTS-user may impersonatePdJ Panother to gain unauthorized access to MTS facilities or to act to the detrimentPb Nof the valid user, e.g., to discard his messages. An MTS-user may impersonate N` Lanother user and so falsely acknowledge receipt of a message by the "valid" L` Lrecipient. A message may be put into the MTS by a user falsely claiming the L` Lidentity of another user. An MTS-user, MS, or MTA may masquerade as another L* MTS-user, MS, or MTA.> *Masquerade threats include the following:*=DJ)a)Impersonation and misuse of the MTS)5 !b)Falsely acknowledge receipt!> *c)Falsely claim to originate a message*@ ,d)Impersonation of an MTA to an MTS-user,@ ,e)Impersonation of an MTA to another MTA,b NA masquerade usually consists of other forms of attack and in a secure system N^ Jmay involve authentication sequences from valid users, e.g., in replay or J. modification of messages., D.2Message Sequencing` LMessage sequencing threats occur when part or all of a message is repeated, L_ Ktime-shifted, or reordered. This can be used to exploit the authentication K` Linformation in a valid message and resequence ~}|{zyxwvutsrqponmlkjihgfedcba`_^]\[or time-shift valid messages. Lc OAlthough it is impossible to prevent replay with the MHS security services, it ON :can be detected and the effects of the threat eliminated.:F2Message sequencing threats include the following:2, a)Replay of messages0 b)Reordering of messages.J c)Pre-play of messages+JMd)Delay of messages5 !D.3Modification of Information!d PInformation for an intended recipient, routing information, and other managementPc Odata may be lost or modified without detection. This could occur to any aspect O\ Hof the message, e.g., its labelling, content, attributes, recipient, or Ha Moriginator. Corruption of routing or other management information, stored in Mb NMTAs or used by them, may cause the MTS to lose messages or otherwise operate N!  incorrectly. ODJ;Modification of information threats include the following:;2 a)Modification of messages1 b)Destruction of messagesQ =c)Corruption of routing and other management information.=+ D.4Denial of Service] IDenial of service occurs when an entity fails to perform its function or Id Pprevents other entities from performing their functions. This may be a denial ofPd Paccess, a denial of communications (leading to other problems like overload), a Pc Odeliberate suppression of messages to a particular recipient, or a fabrication Oa Mof extra traffic. The MTS can be denied if an MTA has been caused to fail or M^ Joperate incorrectly. In addition, an MTS-user may cause the MTS to deny a J] Iservice to other users by flooding the service with messages which might Ia Moverload the switching capability of an MTA or fill up all available message M# storage space.E1Denial of service threats include the following:12J a)Denial of communications% b)MTA failure& c)MTS flooding%JMD.5Repudiationa MRepudiation can occur when an MTS-user or the MTS may later deny submitting, M9 %receiving, or originating a message.%? +Repudiation threats include the following:+* a)Denial of origin. b)Denial of submission, c)Denial of delivery0 D.6Leakage of InformationWDJCInformation may be acquired by an unauthorized party by monitoring Cc Otransmissions, by unauthorized access to information stored in any MHS entity, Oc Oor by masquerade. In some cases, the presence of an MTS-user on the system may Od Pbe sensitive and its anonymity may have to be preserved. An MTS-user other than PX Dthe intended recipient may obtain a message. This might result from D] Iimpersonation and misuse of the MTS or through causing an MTA to operate I] Iincorrectly. Further details on the information flowing in an MTS may be I9 %obtained from observing the traffic.%J 6Leakage of information threats include the following:61 a)Loss of confidentiality+ b)Loss of anonymity6 "c)Misappropriation of messages"* d)Traffic analysis'J D.7Other ThreatsbNIn a multi- or single-level secure system, a number of threats may exist that N^ Jrelate to security labelling, e.g., routing through a node that cannot be Ja Mtrusted with information of particular value, or where systems use different Mb Nlabelling policies. Threats may exist to the enforcement of a security policy NcJMObased on logical separation using security labels. An MTS-user may originate a Ob Nmessage and assign it a label for which it is not cleared. An MTS-user or MTA Nb Nmay set up or accept an association with a security context for which it does N( not have clearance.9 %Other threats include the following:%Y Ea)Originator not cleared for message label (inappropriate submit)E> *b)MTA/MTS-user not cleared for context*$ c)Misrouting6DJ"d)Differing labelling policies" X DAnnex E (to Recommendation X.402) Provision of Security Services in D) Recommendation X.411K 7This annex is an integral part of this Recommendation.7d PTable 14/X.402 indicates which service elements from Recommendation X.411 may bePT @used to support the security services described in clause 10.2.@F 2Table .T.:14/X.402 MHS Security Service Provision2^ J+-------------------------------+-------------------------------------+ | JdJ PSERVICE | MTS ARGUMENTS/SERVICES | +- ORIGIN Pc OAUTHENTICATION SECURITY SERVICES ---------------------------+ | Message Origin Od PAuthentication | Message Origin Authentication Check | | PdP | Message Token | | Probe Origin Authentication |Pc OProbe Origin Authentication Check | | Report Origin Authentication | Report O^ JOrigin Authentication Check | | Proof of Submission | Proof of J\ HSubmission Request | | | Proof of HdJMPSubmission | | Proof of Delivery | Proof of DeliveryPd PRequest | | | Proof of Delivery PN : | +- SECURE ACCESS MANAGEMENT SECURITY SERVICES :Z F------------------------+ | Peer Entity Authentication | Initiator F\ HCredentials | | | Responder Hd PCredentials | | Security Context | Security Context PR > | +- DATA CONFIDENTIALITY SECURITY SERVICES >d P----------------------------+ | Connection Confidentiality | Not supported Pd P | | Content Confidentiality | Content Confidentiality Pd PAlgorithm | | | Identifier PdDJP | | | Message Token | | Pb NMessage Flow Confidentiality | Content Type | +- DATA Na MINTEGRITY SECURITY SERVICES ----------------------------------+ | Connection Md PIntegrity | Not supported | | Content Integrity Pd P | Content Integrity Check | | Pa M | Message Token | | | Md PMessage Origin Authentication Check | | Message Sequence Integrity | Message PdJ PSequence Number | | | Message Token PO ; | +- NON-REPUDIATION SECURITY SERVICES ;a M---------------------------------+ | Non-Repudiation of Origin | Content Md PIntegrity Check | | | Message Token P[ G | | | Message Origin GaMAuthentication Check | | Non-Repudiation of Submission | Proof of Submission Md PRequest | | | Proof of Submission Pd P | | Non-Repudiation of Delivery | Proof of Delivery Request P^ J| | | Proof of Delivery | J^JMJ+-------------------------------+-------------------------------------+ | Jd PMessage Security Labelling | Message Security Label | | Pd P | Message Token | | Pa M | Message Origin Authentication Check | +- SECURITY MANAGEMENT Md PSECURITY SERVICES -----------------------------+ | Change Credentials P_ K | Change Credentials | | Register | K: &Register | &\ H+-------------------------------+-------------------------------------+H c OAnnex F (to Recommendation X.402) Differences Between CCITT Recommendation and O!  ISO Standard E 1This annex is not a part of this Recommendation.1[ GThis annex lists all but the purely stylistic differences between this GUJ ARecommendation and the corresponding ISO International Standard.AM 9There are no differences between the two specifications.9d PCCITT Draft Recommendation X.402 MHS: Overall Architecture (Version 5, November P& 1987, Gloucester) -- --<(Annex G (to Recommendation X.402) Index(E 1This annex is not a part of this Recommendation.1d PThis annex indexes this Recommendation. It gives the number(s) of the page(s) onPc Owhich each item in each of several categories is defined. Its coverage of each O,JMcategory is exhaustive.S ?This annex indexes items (if any) in the following categories:?, a)Abbreviations (ab)$ b)Terms (gt)0 c)Information items (ot), d)ASN.1 modules (mo)+ e)ASN.1 macros (ma)* f)ASN.1 types (ty)+ g)ASN.1 values (va)3 h)Bilateral agreements (ba)6 "i)Items for further study (fs)"3 j)Items to be supplied (fs)  ---------- " .Begin Index."DJAbbreviationsJ  A/SYS 36  AC 5 ACs 62  ACSE 5, 62   ADMD 38  AE 4 APDU 4 AS/SYS 36  ASE 4  ASEs 56   ASN.1 5  JM AST/SYS 37   AT/SYS 36  AU 11 C 7!  COMPUSEC 22  D 7 DL 10 DSA 6 EIT 14 M 7  MASE 61  MD 38  MDSE 61 J MHE 8DJMHS 9  MRSE 61  MS 11  MSSE 61  MTA 12 MTS 10  MTSE 61  O 7OSI 5 P1 62 P3 62 P7 62JM PDAU 12  PDS 12  PRMD 38  RO 6  ROSE 6, 61  RT 6  RTSE 6, 62   S/SYS 36   ST/SYS 36   T/SYS 36  UA 11J UE 5 Terms2 access and storage system 363DJaccess and transfer system 36= )access, storage, and transfer system 37)& access system 36$ access unit 11) actual recipient 173 administration-domain-name 449 %administration management domain 38%$ affirmation 21#asymmetric 57" attribute 42' attribute list 42' attribute type 42(JMattribute value 42$ common-name 45# conditional 7& consuming ASE 58% consuming UE 58  content 13 % content type 14# conversion 21% country-name 45#J defaultable 7!  delivery 19 ' delivery agent 19( delivery report 15* described message 14*DJdirect submission 18# direct user 9* distribution list 10% DL expansion 20  domain 38 1 domain-defined attribute 421 encoded information type 14!  envelope 13  event 15 ( expansion point 20, explicit conversion 21  export 19 9JM%extension-O/R-address-components 45%G 3extension-physical-delivery-address-components 453) external routing 22* external transfer 18" formatted 51# Global MHS 40  grade 7 ,J immediate recipient 16, implicit conversion 21  import 18 , indirect submission 18% indirect user 9+ intended recipient 16) internal routing 22*DJinternal transfer 18  joining 20 0 local-postal-attributes 45* management domain 38!  mandatory 7   members 10 ) member recipient 17  message 13 (Message Handling 84  Message Handling Environment 8 / Message Handling System 9' Message Storage 8&JMmessage store 11( Message Transfer 8/ message transfer agent 120 Message Transfer System 10) messaging system 34-J mnemonic O/R address 50( name resolution 20  nested 10 ( network-address 45( non-affirmation 21% non-delivery 21, non-delivery report 150 numeric-user-identifier 46, numeric O/R address 51$DJO/R address 49!  O/R name 41   optional 7 * organization-name 462 organizational-unit-names 46$ origination 18# originator 16A -originator-specified alternate recipient 17-! PDS-name 46 & personal-name 467 #physical-delivery-country-name 47#6 "physical-delivery-office-name 47"8JM$physical-delivery-office-number 47$< (physical-delivery-organization-name 47(8 $physical-delivery-personal-name 47$*J Physical delivery 126 "physical delivery access unit 12"1 physical delivery system 12) physical message 12+ physical rendition 120 post-office-box-address 47$ postal-code 47+ postal O/R address 51/ poste-restante-address 47, potential recipient 17, private-domain-name 482DJprivate management domain 38  probe 14   receipt 19 " recipient 17? +recipient-assigned alternate recipient 17+$ redirection 21  report 15 " retrieval 19  routing 22 " splitting 20+ standard attribute 42  step 15 4JM storage and transfer system 36 'J storage system 36' street-address 48( subject message 15& subject probe 15# submission 18) submission agent 18* submit permission 10& supplying ASE 58% supplying UE 58" symmetric 57, terminal-identifier 48& terminal-type 48- terminal O/R address 51!DJ transfer 18 ( transfer system 36$ transmittal 15* transmittal event 15) transmittal step 15  type 42 $ unformatted 513 unformatted-postal-address 48+unique-postal-name 48 user 9# user agent 11J  value 42 &JMInformation Items7 #MHS Deliverable Content Length 65#6 "MHS Deliverable Content Types 65"- MHS Deliverable EITs 65. MHS Distribution List 63' MHS DL Members 651 MHS DL Submit Permission 672 MHS DL Submit Permissions 65. MHS Message Store 63, 663 MHS Message Transfer Agent 64( MHS O/R Address 67* MHS O/R Addresses 66% MHS O/R Name 680 MHS Organizational User 647DJ#MHS Preferred Delivery Methods 66#- MHS Residential User 648 $MHS Supported Automatic Actions 66$4  MHS Supported Content Types 66 : &MHS Supported Optional Attributes 67&' MHS User Agent 64" ASN.1 Modules9 %MHSDirectoryObjectsAndAttributes 71%-MHSObjectIdentifiers 69!J  ASN.1 Macros  None  ASN.1 Types /JMDLSubmitPermission 67, 74 ID 69* ORNamePattern 67, 74!  ASN.1 Values   id-arch 69   id-as 69 7 #id-as-mhs-dl-submit-permission 70#- id-as-mhs-or-address 70* id-as-mhs-or-name 70  id-asdc 69   id-at 69 = )id-at-mhs-deliverable-content-length 70)< (id-at-mhs-deliverable-content-types 70(3 id-at-mhs-deliverable-eits 70-DJid-at-mhs-dl-members 708 $id-at-mhs-dl-submit-permissions 70$0 id-at-mhs-message-store 70/ id-at-mhs-or-addresses 70= )id-at-mhs-preferred-delivery-methods 70)> *id-at-mhs-supported-automatic-actions 70*: &id-at-mhs-supported-content-types 70&@J ,id-at-mhs-supported-optional-attributes 70,<(id-directory-objects-and-attributes 70(!  id-group 69   id-ipms 69 !  id-mhsac 69 JM id-mod 69   id-ms 69   id-mts 69 . id-object-identifiers 70  id-oc 69 4  id-oc-mhs-distribution-list 70 0 id-oc-mhs-message-store 709 %id-oc-mhs-message-transfer-agent 70%6 "id-oc-mhs-organizational-user 70"3 id-oc-mhs-residential-user 70- id-oc-mhs-user-agent 70; 'mhs-deliverable-content-length 65, 73': &mhs-deliverable-content-types 65, 73&1 mhs-deliverable-eits 65, 732DJmhs-distribution-list 63, 72+ mhs-dl-members 65, 73< (mhs-dl-submit-permission-syntax 67, 74(6 "mhs-dl-submit-permissions 66, 73"6 "mhs-message-store 63, 66, 72, 73"7J #mhs-message-transfer-agent 64, 72#2 mhs-or-address-syntax 68, 74- mhs-or-addresses 66, 73/mhs-or-name-syntax 68, 744  mhs-organizational-user 64, 72 ; 'mhs-preferred-delivery-methods 66, 74'1 mhs-residential-user 64, 72<JM(mhs-supported-automatic-actions 66, 74(8 $mhs-supported-content-types 66, 74$> *mhs-supported-optional-attributes 67, 74*+ mhs-user-agent 64, 73) Bilateral Agreements$ routing 52, 53, Items for Further Study None) Items to Be Supplied None  .End Index. d Pterpersonal Messaging System | | T.330 | - | Telematic access toPd PIPMS vq lp { h d _ Z, = U @ @ @ B B Pd P @ ! ! = f" u"v" "qT$ c$l $ $gc. g.b 4 PR > 4]: :X @ A A A @ @ @ @ : A >[J GBy B OBwWB Bu B Bs B Cq C PCoXC GA -CmC Ck C -` L CCyfD DwD DuD Ds D Eq E @EoHE LH 4pEmxE EkE Ei 4d P E]F uFy~F Fw F FuF ,Gs3G xGqG GoGPC/ +Hm3H eHkmH /1 mHHy J Jt J d PJoQJ WJj[J \JeJ J`J J[ J 3H e @ @ @ @P` L @ @ J Jv K KqwK }KlK KgIL OLbTL LdJMPUL]M MXM 3H @ @ @ @ @ @ @ MMv M Mq Pd PM MlfN lNgnN oNbN N]N NXO 3H @ @ @ P^ J @ @ @ @ OOvO Oq O Ol O Og Q Qb Q Q]'U Jc OU[V 3H @ @ @ @ @ @ @ VdVviVtjVokVmqV Od PwVhVfVaV V\VZVU V V 3 @ @ @ @ @ P  @ a M V VvVtVoV VjVhVcW W W\ WW W M@DJ,WRV @ @ @ @ @ @ @ ,d P W Wy WtX XoXmXhX Xc Xa X\qY uYXYPS ? YT B A @ @ @ @ @ YZ Zy [ ?d P[w [r#[p$[k[ [f[d[_ \ \Z,\X B @ @ P[ G @ @ @ ! ,\-\v ] ]tL Ronmohq Gd Pwcza{\  Z  B ! @ @ @ @ @  yPa M w u  s\_ s_qu_ x_o{_ _m_ M< (_k_ _i ! ! ! ! ! ! ! ! !(dJ P_ _ _y ` &`ws` ~`ub bs/c FcqHc McoScPB . ecmd dhe A ! ! ! ! ! ! !.` Leev etfo f fj fhfcf fa f f\ gZ L] IgU9g @ @ @ @ @ @ 9g?gvJgtKgog Id Pgjghgcni qia~i i\iZiUi @ @ ! @ PcO@ @ @ iivitio i ijihic j j j\ O] IjWYj `jUj ! @ @ @ @ @ @ jjy2k I? +8ktIkrJkm k kkk ki+W Cl lgTl kleml xlczl @ ! ! ! ! @ @ ! CaJMMzllyl lw n nrn nm ok of o oa o_ MS ?oZ1p xlc @ @ @ @ A ! ! 1p;py p ?d Pptprpmp phpfpasq wq_r rZrXxl @ PJ 6 @ @ @ @ ! rrvr rq rosj t th t 6 , member-of-group [3] Name}74  .I.ty:ORNamePattern; ::= ORName ' -- MHS O/R Address` L.I.va:mhs-or-address-syntax; ATTRIBUTE-SYNTAX SYNTAX ORAddress LJ 6MATCHES FOR EQUALITY ::= id-as-mhs-or-address6$DJ-- MHS O/R Named \\ DZDZ0[Y-YBHPLASRMN N!  Front Matter d PCCITT Draft Recommendation X.402 MHS: Overall Architecture (Version 5, November P& 1987, Gloucester) -- --C /Message Handling Systems: Overall Architecture/; '(Version 5, November 1987, Gloucester)'dl LInternational Telegraph and Telephone Document AP IX-45-E8date.F 0       ~ h R < &   P @  VBcentral role in the Global MHS. By interconnecting to one another B ther O^ Jinternationally, they provide an international Message Transfer backbone. J[ GDepending upon national regulations, by interconnecting to one another GY Edomestically, they may also provide domestic backbones joined to the Eb Ninternational backbone. ADMDs also serve as primary naming authorities in the M3. The typical Directory name is more user-friendly and more stable than the Mtable than the Jg authorities upon which the Directory will eventually depend.H 3. ^ JThe typical Directory name is more user-friendly and more stable than the J'b Ntypical O/R address because the latter is necessarily couched in terms of the Na Morganizational or physical structure of the MHS while the former need not be.M in F the MTS includes an O/R address and possibly a Directory name in MaJMMeach O/R name it supplies to a message's recipient or to the originator of a M+] Ireport's subject message or probe. The Directory name is included if the Ic Ooriginator supplied it or if it was specified as the the member of an expanded O DL.d PNote Redirection or DL expansion may cause the ld Pd P convey the same information so that eiher of them can be safely ignored P(  upon receipt.h Printable and Teletex Strings are supplied, the two should O$c O convey the same information so  B  Q#  upon receipt.( d PThe length of each string and of each sequence of strings in an attribute shall P` an Gc Oorganization. As a national matter, this identification may be either relative Od Pto the country denoted by a country-name (so that organization names are unique Pd Pwithin the country), or relative to the MD identified by a private-domain-name, P? +or an administration-domain-name, or both.+ d P^^^^^^^The value of an organization-name is a Printable String, Teletex String, Pc Oor both. Whether Printable or Teletex, the string is chosen from a set of such O^ Jstrings that is administered for this purpose (and perhaps others) by the J. country alluded to above. f PNote - In countries choosing country-wide unique organization-names, a national LO ;registration authority for organization-names is required.; equired.  8sen from a set of such strings that is administered for this purpose by the O+ ADMD alluded to above. ^ HNote - In countries choosing country-wide unique PRMD names, a national DQ =registration authority for private-domain-names is required.= DJfor CCI-18.3.22Street-address^ JA .I.gl:street-address; is a standard attribute that specifies the s^ Jgeneral nature, attribute types in the second and third those specific to Ja Mphysical delivery. The fourth section encompasses domain-defined attributes.M kB sections. Attribute types in the first are those of a generalP  physical i> types in the second and third those specific to physical KXDdelivery. The fourth section encompasses domain-defined attributes.D+ Recommendation X.402 JMSJ ?MESSAGE HANDLING SYSTEMS OVERALL ARCHITECTURE?#  d PCCITT Draft Recommendation X.402 MHS: Overall Architecture (Version 5, November P& 1987, Gloucester) -- --BJ .MESSAGE HANDLING SYSTEMS OVERALL ARCHITECTURE. .  2 s="(c+x4]8=YE9OWajsyzpJ"Ee ]$ s&01KQ9V9RdPflow confidentiality. Other elements of this service, such V This document is theMe M same as COM VII-R 36 9 .  Melbourne, 1988   8 $IXth PLENARY ASSEMBLY - DOCUMENT 45$ 2 STUDY GROUP VII - REPORT R 362 =============================  J 6SOURCE: STUDY GROUP VII - DATA COMMUNICATION NETWORKS6 C /TITLE: FINAL REPORT TO THE PLENARY ASSEMBLY -/B . PART II.6 - DRAFT NEW RECOMMENDATIONS. " ^   e ONote by the CCITT Secretariat: The final report of Study Group VII to the IXth 2` LPlenary Assembly consists of the following four parts published in separate L  documents:  R >Part I: General report (published in AP IX-39/COM VII-R 30)> _ KPart II: Draft new Recommendations (published in AP IX-40/COM VII-R 31 toK5 ! AP IX-47/COM VII-R 38)! d PPart III: Draft revised Recommendations (published in AP IX-48/COM VII-R 39 to P5 ! AP IX-56/COM VII-R 47)! b NPart IV: Texts of Questions proposed for the next study period (published inN5 ! AP IX-57/COM VII/R 48)! _ KThe report of the final meeting of Study Group VII, 21-31 March^1988, Kc Ocovering aspects which have not been included in the above four parts, will be Od Pissued in another report (COM VII-R 29). Since this report is not requested for PZ Fthe Plenary Assembly, it will be prepared and issued at a later date.F 0       ~ h R < &   P  D ,CONTENTS#  b J PageE  S ?Recommendation X.402 - Message handling systems: overall ?] I architecture ................................. 1I Q =Recommendation X.403 - Message handling systems: conformance=] I testing ...................................... 1I V BRecommendation X.407 - Message handling systems: abstract serviceB] I definition conventions ....................... 1I   DJ    P hich is one OF 2of the argumen*CCITTISO.STYHPLASRMN HPLASRMN N!  Front Matter d PCCITT Draft Recommendation X.402 MHS: Overall Architecture (Version 5, November P=& 1987, Gloucester) -- --C /Message Handling Systems: Overall Architecture/; '(Version 5, November 1987, Gloucester)' d message or probe.\ HA report may comprise one or more delivery and/or non-delivery reports.H` LA message or probe may provoke several delivery and/or non-delivery reports L] Iconcerning a particular potential recipient. Each marks the passage of a IHA report may comprise one or more delivery and/or non-delivery reports.H; 'A message or probe may provoke several '6 "concerning a particular pB.217:? +a)application association; asZ Fsecond column the kinds of information objects--messages, probes, and FWW Cthat may be conveyed in such a step, the third column the kinds of Cd Pobjects--users, UAs, MSs, MTAs, and AUs--that may participate in such a step as P8 $the object's source or destination.$c OThe table is divided into three sections. The steps in the first sedDJcombination of these).- 7.2.3Message Storesb NA typical user must store the information objects it receives. The functional N^ Jobject that provides a (single) direct user with capabilities for Message Jd PStorage is called a .I.gl:message store; (.I.abd PAn MTA may, but need not stage a joining when it determines that the same eventsPd Pand next step are required t2on P  outingbDJNIn a .I.gl:routing; event, an MTA selects the "adjacent" MTA to which it will Na Mtransfer a message, probe, or report. This event incrementally determines an Md Pinformation object's route through the MTS and (obviously) may be taken only if P4  the MTS comprises several MTAs. b NThe following kinds of routing are distinguished, on the basis of the kind - Despite these security features, certain attacks may by be mounted F] Iagainst communication between a user and the MHS or against user-to-user IdJ Pcommunication (e.g. in the case of users accessing their UAs). To counter these PdJ Pattacks requires extensions to the present security model and services which areP)J for further study.J $J J ^ JIn maof type Y.#I 5Table .T.:7/X.402 Message Transfer Security Services5sY Pservices in each are listed in Table 7/X.402. An asterisk (*) under the heading PaJMMof the form X/Y indicates that the service can be provided from a functional M7 #object of type X to one of type Y.#) Table .T.:7/X.402 Mes& Security Services97 #object of type X to one of type Y.^'10.2.7.3MS-Register Security Service b NThe security service enables the establishment of the security label which ar N1 permissible for the MS-user.  ages  8.2Probes !  8.3Reports + 9.Operational Model% 9.1Transmittal+ 9.2Tra  + 10.3Security Elemtial data which mayP^ Jbe used in providing the Connection Confidentiality and/or the Connection Jc OIntegrity security service in underlying layers. Such an authenication is only O] Ivalid for the instant that it is made and the continuing validity of the Id Pauthenticated identity depends on whether the exchange of confidential data, or P` Lsome other mechanism, is used to establish a secure communication pL 8transferred credentials are either passwords or tokens.8predentials argument and the Responder P6 "Creden6 "Credentials result of the MTS-bind"0  transferred \ials argument and the Responder P^ JCredentials result of the MTS-bind and MTA-bind services. The transferred Jx@ ,credentials are either passwords or tokens.,KJM710.3.1.2Data Origin Authentication SecAI 510.3.2Secure Access Management Security Elements5^ JThese security elements are defined in order to support the Secure Access JV BManagement security service and the security management services.B@ ,10.3.2.1Security Context Security Element,_JMKWhen an MTS-user or an MTA binds to an MTA or MTS-user, the bind operation K_ Kspecifies the security context of the connection. Tnge arguments held by the MS relating to the O; 'retrieval of messages to that MS-user.'entiality Security Elements1a MThese security elements, based on the use of encipherment, are all concerned M` Lwith the provision of confidentiality of data passed from one MHS entity to L  another. G 310.3.3.1Content Confidentiality Security Element3d PThe Content Confidentiality securr 1 essag E 110.3.3Data Confidentiality Security Elements1a MThese security elements, based on the use of encipherment, are all concerned M` Lwith the provision of confidentiality of data passed from one MHS entity to L  another. G 310.3.3.1Content Confidentiality Security Element3d PThe Content Confidentiality securitY three sections. Attribute types in the first are of a general Lc O7#14.2Representative Configurations#d PMDs can be combined in various ways to form the MHS. The possible organizationalPb Nconfigurations are unbounded in number and thus cannot be enumerated. Several NaJMMimportant representative configurations, however, are described below and in M% Figure 10/X.402.c sed. a Mc) One physical-delivery-country-name and one postal-code, which together M_ K^^^^^^identify the geographical region in which the user takes delivery of K- ^^^^^^physical messages. in which the user takes delivery of physical N c)[ GOne physical-delivery-country-name and one postal-cod E'physical messages.::= ?5 !id-oc-mhs-message-transfer-agent!p Z MHS User s P^^^^^^^An MHS User object is a generic MHS user. (The generic user can have, forPd Pexample, a business address, a residential address, or both.) The attributes in PcJMOits entry identify the user's O/R address and, to the extent that the relevant O * A.1.4^^^MHS UserDJ of an ASE by means of which a UE supplies or Jd Pconsumes a service, but not both, depending upon how the ASE is configured. The P_ KASE for message delivery, e.g., is asymmetric because only the open system Kc Oembodying an MTA offers the associated service and only the other open system, O< (which embodies a UA or MS, consumes it.(cO+----+ DJrvices are listed in the Nd Pfirst column of Table 11/X.402. For each ASE listed, the second column indicatesP[ Gwhether it is symmetric or asymmetrDJ.O ;mhs-dl-members, ;S ?mhs-preferred-delivery-methods} ::= ?0 id-oc-mhs-distribution-list) -- MHS Message Store[ G.I.va:mhs-mesof the Set, etc.).d PThe ACs by means of which the various Message Handling services are provided areP_ Kspecified in Recommendation X.419. These protocols are known asJMJ 6mhs-or-address} ::= id-oc-mhs-user-agent6" -- ATTRIBUTES6 "-- MHS Deliverable Content Length"d P.I.va:mhs-deliverable-content-length; ATTRIBUTE WITH ATTRIBUTE-SYNTAXPare present in the O/R address at the discretion of, and inPb Naccordance with rules established by the ADMD denoted by the country-name and NbDJNadministration-domain-name attributes of the O/R address. The ADMD imposes no N] Iother constraints on the attributes in the O/R address. If a user is not Ia Maccessed through a PRMD, all conditional attributes except those specific to Md Ppostal O/R addresses are present in an O/R address at the discretion of, and in Pc Oaccordance with rules established by, the ADMD denoted by the country-name and O; 'administration-domain-name attributes.' d P^^^^^^All conditional attributes specific to postal O/R addresses are present orPd Pabsent in such O/R addresses so as to satisfy the postal addressing requirementsP7sent OX Dabsent in such O/R addreWXY      !"#$%&'()*+,-./0123