Section Two - Abstract Models 6. Overview This section presents abstract models of Message Handling which provide the architectural basis for the more detailed specifications that appear in other Recommendations in the set. .I.gl:Message Handling; is a distributed information processing task that integrates the following intrinsically related sub-tasks: a) .I.gl:Message Transfer;: The non-real-time carriage of information objects between parties using computers as intermediaries. b) .I.gl:Message Storage;: The automatic storage for later retrieval of 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 Note Message Handling has a variety of applications, one of which is Interpersonal Messaging, described in Recommendation X.420. 7. Functional Model This clause provides a functional model of Message Handling. The concrete realization of the model is the subject of other Recommendations in the set. The .I.gl:Message Handling Environment; (.I.ab:MHE;) comprises "primary" functional objects of several types, the Message Handling System (MHS), users, and distribution lists. The MHS in turn can be decomposed into lesser, "secondary" functional objects of several types, the Message Transfer System (MTS), user agents, message stores, and access units. The MTS in turn can be decomposed into still lesser, "tertiary" functional objects of a single type, message transfer agents. The primary, secondary, and tertiary functional object types and selected access unit types are individually defined and described below. As detailed below, functional objects are sometimes tailored to one or more applications of Message Handling, e.g., Interpersonal Messaging (see Recommendations X.420 and T.330). A functional object that has been tailored to an application understands the syntax and semantics of the contents of messages exchanged in that application. As a local matter, functional objects may have capabilities beyond those specified in this Recommendation or others in the set. In particular, a typical user agent has message preparation, rendition, and storage capabilities that are not standardized. 7.1 Primary Functional Objects The MHE comprises the Message Handling System, users, and distribution lists. These primary functional objects interact with one another. Their types are defined and described below. The situation is depicted in Figure 1/X.402. +----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 | | 08 | | 09 | | 10 | | 11 | | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20 | | 21 | | 22 | | 23 | | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+ Figure .F.:1/X.402 The Message Handling Environment 7.1.1 The Message Handling System The principal purpose of Message Handling is to convey information objects from one party to another. The functional object by means of which this is accomplished is called the .I.gl:Message Handling System; (.I.ab:MHS;). The MHE comprises a single MHS. 7.1.2 Users The principal purpose of the MHS is to convey information objects between users. A functional object (e.g., a person) that engages in (rather than provides) Message Handling is called a .I.gl:user;. The following kinds of user are distinguished: a) .I.gl:direct user;: A user that engages in Message Handling by direct use of the MHS. b) .I.gl:indirect user;: A user that engages in Message Handling by indirect use of the MHS, i.e., through another communication system (e.g., a postal system or the telex network) to which the MHS is linked. The MHE comprises any number of users. 7.1.3 Distribution Lists By means of the MHS a user can convey information objects to pre-specified groups of users as well as to individual users. The functional object that represents a pre-specified group of users and other DLs is called a .I.gl:distribution list; (.I.ab:DL;). A DL identifies zero or more users and DLs called its .I.gl:members;. The latter DLs (if any) are said to be .I.gl:nested;. Asking the MHS to convey an information object (e.g., a message) to a DL is tantamount to asking that it convey the object to its members. Note that this is recursive. The right, or permission, to convey messages to a particular DL may be controlled. This right is called .I.gl:submit permission;. As a local matter the use of a DL can be further restricted. The MHE comprises any number of DLs. Note A DL might be further restricted, e.g., to the conveyance of messages of a prescribed content type. 7.2 Secondary Functional Objects The MHS comprises the Message Transfer System, user agents, message stores, and access units. These secondary functional objects interact with one another. Their types are defined and described below. The situation is depicted in Figure 2/X.402. +----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 | | 08 | | 09 | | 10 | | 11 | | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20 | | 21 | | 22 | | 23 | | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+ Figure .F.:2/X.402 The Message Handling System 7.2.1 The Message Transfer System The MHS conveys information objects to individual users and to the members of DLs. The functional object that actually does this is called the .I.gl:Message Transfer System; (.I.ab:MTS;). The MTS is a store-and-forward communication system and can be considered the backbone of the MHS. The MTS is general-purpose, supporting all applications of Message Handling. Additionally, the MTS may be tailored to one or more particular applications so it can carry out conversion. The MHS comprises a single MTS. 7.2.2 User Agents The functional object by means of which a single direct user engages in Message Handling is called a .I.gl:user agent; (.I.ab:UA;). A typical UA is tailored to one or more particular applications of Message Handling. The MHS comprises any number of UAs. Note A UA that serves a human user typically interacts with him by means of input/output devices (e.g., a keyboard, display, scanner, printer, or combination of these). 7.2.3 Message Stores A typical user must store the information objects it receives. The functional object that provides a (single) direct user with capabilities for Message Storage is called a .I.gl:message store; (.I.ab:MS;). Each MS is associated with one UA, but not every UA has an associated MS. Every MS is general-purpose, supporting all applications of Message Handling. Additionally, an MS may be tailored to one or more particular applications so that it can more capably submit and support the retrieval of messages associated with that application. The MHS comprises any number of MSs. Note As a local matter a UA may provide for information objects storage that either supplements or replaces that of an MS. 7.2.4 Access Units The functional object that links another communication system (e.g., a postal system or the telex network) to the MTS and via which its patrons engage in Message Handling as indirect users is called an .I.gl:access unit; (.I.ab:AU;). A typical AU is tailored to a particular communication system and to one or more particular applications of Message Handling. The MHS comprises any number of AUs. 7.3 Tertiary Functional Objects The MTS comprises message transfer agents. These tertiary functional objects interact. Their type is defined and described below. The situation is depicted in Figure 3/X.402. +----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 | | 08 | | 09 | | 10 | | 11 | | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20 | | 21 | | 22 | | 23 | | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+ Figure .F.:3/X.402 The Message Transfer System 7.3.1 Message Transfer Agents The MTS conveys information objects to users and DLs in a store-and-forward manner. A functional object that provides one link in the MTS' store-and-forward chain is called a .I.gl:message transfer agent; (.I.ab:MTA;). Every MTA is general-purpose, supporting all applications of Message Handling. Additionally, an MTA may be tailored to one or more particular applications so it can carry out conversion. The MTS comprises any number of MTAs. 7.4 Selected AU Types As described above, the MHS interworks with communication systems of other types via AUs. Several selected AU types--physical delivery, telematic, and telex--are introduced in the clauses below. 7.4.1 Physical Delivery A .I.gl:physical delivery access unit; (.I.ab:PDAU;) is an AU that subjects messages (but neither probes nor reports) to physical rendition and that conveys the resulting physical messages to a physical delivery system. The transformation of a message into a physical message is called .I.gl:physical rendition;. A .I.gl:physical message; is a physical object (e.g., a letter and its paper envelope) that embodies a message. A .I.gl:physical delivery system; (.I.ab:PDS;) is a system that performs physical delivery. One important kind of PDS is postal systems. .I.gl:Physical delivery; is the conveyance of a physical message to a patron of a PDS, one of the indirect users to which the PDAU provides Message Handling capabilities. Among the applications of Message Handling supported by every PDAU is Interpersonal Messaging (see Recommendation X.420). 7.4.2 Telematic Telematic access units, which support Interpersonal Messaging exclusively, are introduced in Recommendation X.420. 7.4.3 Telex Telex access units, which support Interpersonal Messaging exclusively, are introduced in Recommendation X.420. 8. Information Model This clause provides an information model of Message Handling. The concrete realization of the model is the subject of other Recommendations in the set. The MHS and MTS can convey information objects of three classes: messages, probes, and reports. These classes are listed in the first column of Table 4/X.402. For each listed class, the second column indicates the kinds of functional objects--users, UAs, MSs, MTAs, and AUs--that are the ultimate sources and destinations for such objects. Table .T.:4/X.402 Conveyable Information Objects +---------+-------------------+ | Infor- | Functional Object | | mation +--------- -----------+ | Object | user UA MS MTA AU | +---------+-------------------+ | message | SD - - - - | | probe | S - - D - | | report | D - - S - | +---------+-------------------+ +- Legend ---------------+ | S ultimate source | | D ultimate destination | +------------------------+ The information objects, summarized in the table, are individually defined and described in the clauses below. 8.1 Messages The primary purpose of Message Transfer is to convey information objects called .I.gl:message;s from one user to others. A message has the following parts, as depicted in Figure 4/X.402: a) .I.gl:envelope;: An information object whose composition varies from one transmittal step to another and that variously identifies the message's originator and potential recipients, documents its previous conveyance and directs its subsequent conveyance by the MTS, and characterizes its content. b) .I.gl:content;: An information object that the MTS neither examines nor modifies, except for conversion, during its conveyance of the message. +----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 | | 08 | | 09 | | 10 | | 11 | | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20 | | 21 | | 22 | | 23 | | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+ Figure .F.:4/X.402 A Message's Envelope and Content One piece of information borne by the envelope identifies the type of the content. The .I.gl:content type; is an identifier (an ASN.1 Object Identifier or Integer) that denotes the syntax and semantics of the content overall. This identifier enables the MTS to determine the message's deliverability to particular users, and enables UAs and MSs to interpret and process the content. Another piece of information borne by the envelope identifies the types of encoded information represented in the content. An .I.gl:encoded information type; (.I.ab:EIT;) is an identifier (an ASN.1 Object Identifier or Integer) that denotes the medium and format (e.g., IA5 text or Group 3 facsimile) of individual portions of the content. It further enables the MTS to determine the message's deliverability to particular users, and to identify opportunities for it to make the message deliverable by converting a portion of the content from one EIT to another. 8.2 Probes A second purpose of Message Transfer is to convey information objects called .I.gl:probe;s from one user up to but just short of other users (i.e., to the MTAs serving those users). A probe describes a class of message and is used to determine the deliverability of such messages. A message described by a probe is called a .I.gl:described message;. A probe comprises an envelope alone. This envelope contains much the same information as that for a message. Besides bearing the content type and encoded information types of a described message, the probe's envelope bears the length of its content. The submission of a probe elicits from the MTS largely the same behavior as would submission of any described message, except that DL expansion and delivery are forgone in the case of the probe. In particular, and apart from the consequences of the suppression of DL expansion, the probe provokes the same reports as would any described message. This fact gives probes their utility. 8.3 Reports A third purpose of Message Transfer is to convey information objects called reports to users. Generated by the MTS, a report relates the outcome or progress of a message's or probe's transmittal to one or more potential recipient. The message or probe that is the subject of a report is called its .I.gl:subject message; or .I.gl:subject probe;. A report concerning a particular potential recipient is conveyed to the originator of the subject message or probe unless the potential recipient is a member recipient. In the latter case, the report is conveyed to the DL of which the member recipient is a member. As a local matter (i.e., by policy established for that particular DL), the report may be further conveyed to the DL's owner; either to another, containing DL (in the case of nesting) or to the originator of the subject message or probe (otherwise); or both. The outcome that a single report may relate are of the following kinds: a) .I.gl:delivery report;: delivery, export, or affirmation of the subject message or probe, or DL expansion. b) .I.gl:non-delivery report;: non-delivery or non-affirmation of the subject message or probe. A report may comprise one or more delivery and/or non-delivery reports. A message or probe may provoke several delivery and/or non-delivery reports concerning a particular potential recipient. Each marks the passage of a different transmittal step or event. 9. Operational Model This clause provides an operational model of Message Handling. The concrete realization of the model is the subject of other Recommendations in the set. The MHS can convey an information object to individual users, DLs, or a mix of the two. Such conveyance is accomplished by a process called transmittal comprising steps and events. The process, its parts, and the roles that users and DLs play in it are defined and described below. 9.1 Transmittal The conveyance or attempted conveyance of a message or probe is called .I.gl:transmittal;. Transmittal encompasses a message's conveyance from its originator to its potential recipients, and a probe's conveyance from its originator to MTAs able to affirm the described messages' deliverability to the probe's potential recipients. Transmittal also encompasses the conveyance or attempted conveyance to the originator of any reports the message or probe may provoke. A transmittal comprises a sequence of transmittal steps and events. A .I.gl:transmittal step; (or .I.gl:step;) is the conveyance of a message, probe, or report from one functional object to another "adjacent" to it. A .I.gl:transmittal event; (or .I.gl:event;) is processing of a message, probe, or report within a functional object that may influence the functional object's selection of the next transmittal step or event. The information flow of transmittal is depicted in Figure 5/X.402. The figure shows the kinds of functional objects--direct users, indirect users, UAs, MSs, MTAs, and AUs--that may be involved in a transmittal, the information objects--messages, probes, and reports--that may be conveyed between them, and the names of the transmittal steps by means of which those conveyances are accomplished. The figure highlights the facts that a message or report may be retrieved repeatedly and that only the first conveyance of a retrieved object from UA to user constitutes receipt. +----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 | | 08 | | 09 | | 10 | | 11 | | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20 | | 21 | | 22 | | 23 | | 24 | | 25 | | 26 | | 27 | | 8 | | 29 | +----+ +- Legend ------------------------- ----------+ | M message ORG origination EXP export | | P probe SBM submission DLV delivery | | R report IMP import RTR retrieval | | TRN transfer REC receipt | +-------------------------------------------+ Figure .F.:5/X.402 The Information Flow of Transmittal One event plays a distinguished role in transmittal. Splitting replicates a message or probe and divides responsibility for its immediate recipients among the resulting information objects. The potential recipients associated with a particular instance of a message or probe are called the .I.gl:immediate recipient;s. An MTA stages a splitting if the next step or event required in the conveyance of a message or probe to some immediate recipients differs from that required in its conveyance to others. Each of the step and event descriptions which follow assumes that the step or event is appropriate for all immediate recipients, a situation that can be created, if necessary, by splitting. 9.2 Transmittal Roles Users and DLs play a variety of roles in a message's or probe's transmittal. These roles are informally categorized as "source" roles, "destination" roles, or statuses to which users or DLs can be elevated. A user may play the following "source" role in the transmittal of a message or probe: a) .I.gl:originator;: The user (but not DL) that is the ultimate source of a message or probe. A user or DL may play any of the following "destination" roles in the transmittal of a message or probe: a) .I.gl:intended recipient;: One of the users and DLs the originator specifies as a message's or probe's intended destinations. b) .I.gl:originator-specified alternate recipient;: The user or DL (if any) to which the originator requests that a message or probe be conveyed if it cannot be conveyed to a particular intended recipient. c) .I.gl:member recipient;: A user or DL to which a message (but not a probe) is conveyed as a result of DL expansion. d) .I.gl:recipient-assigned alternate recipient;: The user or DL (if any) to which an intended, originator-specified alternate, or member recipient may have elected to redirect messages. A user or DL may attain any of the following statuses in the course of a message's or probe's transmittal: a) .I.gl:potential recipient;: Any user or DL to (i.e., toward) which a message or probe is conveyed at any point during the course of transmittal. Necessarily an intended, originator-specified alternate, member, or recipient-assigned alternate recipient. b) .I.gl:actual recipient; (or .I.gl:recipient;): A potential recipient for which delivery or affirmation takes place. 9.3 Transmittal Steps The kinds of steps that may occur in a transmittal are listed in the first column of Table 5/X.402. For each listed kind, the second column indicates whether this Recommendation and others in the set standardize such steps, the third column the kinds of information objects--messages, probes, and reports-- that may be conveyed in such a step, the fourth column the kinds of functional objects--users, UAs, MSs, MTAs, and AUs--that may participate in such a step as the object's source or destination. The table is divided into three sections. The steps in the first section apply to the "creation" of messages and probes, those in the last to the "disposal" of messages and reports, and those in the middle section to the "relaying" of messages, probes, and reports. Table .T.:5/X.402 Transmittal Steps +------------------+--------+-------------+-------------------+ | | | Information | Functional | | | Stand- | Objects | Objec s | | | ard- +-------------+------------------ --+ | Transmittal Step | ized? | M P R | user UA MS MTA AU | +---------------- ---+--------+-------------+-------------------+ | origination | No | x x - | S D - - - | | submission | Yes | x x - | - S SD D - | +------------------+--------+-------------+-------------------+ | import | No | x x x | - - - D S | | transfer | Yes | x x x | - - - SD - | | export | No | x x x | - - - S D | +------------------+--------+-------------+-------------------+ | delivery | Yes | x - x | - D D S - | | retrieval | Yes | x - x | - D S - - | | receipt | No | x - x | D S - - - | +------------------+--------+-------------+-------------------+ +- Legend ------------------------------+ | M message S source x permitted | | P probe D destinati n | | R report | +----------- -----------------------------+ The kinds of transmittal steps, summarized in the table, are individually defined and described in the clauses below. 9.3.1 Origination In an .I.gl:origination; step, either a direct user conveys a message or probe to its UA, or an indirect user conveys a message or probe to the communication system that serves it. This step gives birth to the message or probe and is the first step in its transmittal. The user above constitutes the message's or probe's originator. In this step, the originator identifies the message's or probe's intended recipients. Additionally, for each intended recipient, the originator may (but need not) identify an originator-specified alternate recipient. 9.3.2 Submission In a .I.gl:submission; step, a message or probe is conveyed to an MTA and thus entrusted to the MTS. Two kinds of submission are distinguished: a) .I.gl:indirect submission;: A transmittal step in which the originator's UA conveys a message or probe to its MS and in which the MS effects direct submission. Such a step follows origination. This step may be taken only if the user is equipped with an MS. b) .I.gl:direct submission;: A transmittal step in which the originator's UA or MS conveys a message or probe to an MTA. Such a step follows origination or occurs as part of indirect submission. This step may be taken whether or not the user is equipped with an MS. Indirect and direct submission are functionally equivalent except that additional capabilities may be available with the former. Indirect submission may differ from direct submission in other respects (e.g., the number of open systems with which that embodying a UA must interact) and for that reason be preferable to direct submission. The UA or MS involved in direct submission is called the .I.gl:submission agent;. A submission agent is made known to the MTS by a process of registration, as a result of which the submission agent and MTS keep one another informed of their names, their locations, and any other characteristics required for their interaction. 9.3.3 Import In an .I.gl:import; step, an AU conveys a message, probe, or report to an MTA. This step injects into the MTS an information object born in another communication system, and follows its conveyance by that system. Note The concept of importing is a generic one. How this step is effected varies, of course, from one type of AU to another. 9.3.4 Transfer In a .I.gl:transfer; step, one MTA conveys a message, probe, or report to another. This step transports an information object over physical and sometimes organizational distances and follows direct submission, import, or (a prior) transfer. This step may be taken, of course, only if the MTS comprises several MTAs. The following kinds of transfer are distinguished, on the basis of the number of MDs involved: a) .I.gl:internal transfer;: A transfer involving MTAs within a single MD. b) .I.gl:external transfer;: A transfer involving MTAs in different MDs. 9.3.5 Export In an .I.gl:export; step, an MTA conveys a message, probe, or report to an AU. This step ejects from the MTS an information object bound for another communication system. It follows direct submission, import, or transfer. As part of this step, the MTA may generate a delivery report. Note The concept of exporting is a generic one. How this step is effected varies, of course, from one type of AU to another. 9.3.6 Delivery In a .I.gl:delivery; step, an MTA conveys a message or report to an MS or UA. The MS and UA are those of a potential recipient of the message, or the originator of the report's subject message or probe. This step entrusts the information object to a representative of the user and follows direct submission, import, or transfer. It also elevates the user in question to the status of an actual recipient. As part of this step, in the case of a message, the MTA may generate a delivery report. The MS or UA involved is called the .I.gl:delivery agent;. A delivery agent is made known to the MTS by a process of registration, as a result of which the delivery agent and MTS keep one another informed of their names, their locations, and any other characteristics required for their interaction. 9.3.7 Retrieval In a .I.gl:retrieval; step, a user's MS conveys a message or report to its UA. The user in question is an actual recipient of the message or the originator of the subject message or probe. This step non-destructively retrieves the information object from storage. This step follows delivery or (a prior) retrieval. This step may be taken only if the user is equipped with an MS. 9.3.8 Receipt In a .I.gl:receipt; step, either a UA conveys a message or report to its direct user, or the communication system that serves an indirect user conveys such an information object to that user. In either case, this step conveys the object to its ultimate destination. In the case of a direct user, this step follows the object's delivery or first retrieval (only). In the case of an indirect user, it follows the information object's conveyance by the communication system serving the user. In either case, the user is a potential recipient (and, in the case of a direct user, an actual recipient) of the message in question, or the originator of the subject message or probe. 9.4 Transmittal Events The kinds of events that may occur in a transmittal are listed in the first column of Table 6/X.402. For each listed kind, the second column indicates the kinds of information objects--messages, probes, and reports--for which such events may be staged, the third column the kinds of functional objects--users, UAs, MS , MTAs, and AUs-- -that may stage such events. All the events occur within the MTS. Table .T.:6/X.402 Transmittal Events +-------------------+-------------+-------------------+ | | Information | Functional | | | Objects | Objects | | +-------------+-------------------+ | Transmittal Event | M P R | user UA MS MTA AU | +-------------------+-------------+-------------------+ | splitting | x x - | - - - x - | | joining | x x x | - - - x - | | name resolution | x x - | - - - x - | | DL expansion | x - - | - - - x - | | redirection | x x - | - - - x - | | conversion | x x - | - - - x - | | non-delivery | x - x | - - - x - | | non-affirmation | - x - | - - - x - | | affirmation | - x - | - - - x - | | routing | x x x | - - - x - | +-------------------+----------- ---+-------------------+ +- Legend ---------------+ | M message x permitted | | P probe | | R report | +------------------------+ The kinds of transmittal events, summarized in the table, are individually defined and described in the clauses below. 9.4.1 Splitting In a .I.gl:splitting; event, an MTA replicates a message or probe, dividing responsibility for its immediate recipients among the resulting information objects. This event effectively allows an MTA to independently convey an object to various potential recipients. An MTA stages a splitting when the next step or event required in the conveyance of a message or probe to some immediate recipients differs from that required in its conveyance to others. 9.4.2 Joining In a .I.gl:joining; event, an MTA combines several instances of the same message or probe, or two or more delivery and\or non-delivery reports for the same subject message or probe. An MTA may, but need not stage a joining when it determines that the same events and next step are required to convey several highly related information objects to their destinations. 9.4.3 Name Resolution In a .I.gl:name resolution; event, an MTA adds the corresponding O/R address to the O/R name that identifies one of a message's or probe's immediate recipients. 9.4.4 DL Expansion In a .I.gl:DL expansion; event, an MTA resolves a DL among a message's (but not a probe's) immediate recipients to its members which are thereby made member recipients. This event removes indirection from the immediate recipients' specification. A particular DL is always subjected to DL expansion at a pre-established location within the MTS. This location is called the DL's .I.gl:expansion point; and is identified by an O/R address. As part of this event, the MTA may generate a delivery report. DL expansion is subject to submit permission. In the case of a nested DL, that permission must have been granted to the DL of which the nested DL is a member. Otherwise, it must have been granted to the originator. 9.4.5 Redirection In a .I.gl:redirection; event, an MTA replaces a user or DL among a message's or probe's immediate recipients with an originator-specified or recipient-assigned alternate recipient. 9.4.6 Conversion In a .I.gl:conversion; event, an MTA transforms parts of a message's content from one EIT to another, or alters a probe so it appears that the described messages were so modified. This event increases the likelihood that an information object can be delivered or affirmed by tailoring it to its immediate recipients. The following kinds of conversion are distinguished, on the basis of how the EIT of the information to be converted and the EIT to result from the conversion are selected: a) .I.gl:explicit conversion;: A conversion in which the originator selects both the initial and final EITs. b) .I.gl:implicit conversion;: A conversion in which the MTA selects the final EITs based upon the initial EITs. 9.4.7 Non-delivery In a .I.gl:non-delivery; event, an MTA determines that the MTS cannot deliver a message to its immediate recipients, or cannot deliver a report to the originator of its subject message or probe. This event halts the conveyance of an object the MTS deems unconveyable. As part of this event, in the case of a message, the MTA generates a non-delivery report. An MTA stages a non-delivery, e.g., when it determines that the immediate recipients are improperly specified, that they do not accept delivery of messages like that at hand, or that the message has not been delivered to them within pre-specified time limits. 9.4.8 Non-affirmation In a .I.gl:non-affirmation; event, an MTA determines that the MTS could not deliver a described message to a probe's immediate recipients. This event partially or fully determines the answer to the question posed by a probe. As part of this event, the MTA generates a non-delivery report. An MTA stages a non-affirmation, e.g., when it determines that the immediate recipients are improperly specified or would not accept delivery of a described message. 9.4.9 Affirmation In an .I.gl:affirmation; event, an MTA determines that the MTS could deliver any described message to a probe's immediate recipients. This event partially or fully determines the answer to the question posed by a probe, and elevates the immediate recipients to the status of actual recipients. As part of this event, the MTA may generate a delivery report. An MTA stages an affirmation once it determines that the immediate recipients are properly specified and, if the immediate recipients are users (but not DLs), would accept delivery of any described message. If the immediate recipients are DLs, and MTA stages an affirmation if the DL exists and the originator has the relevant submit permission. 9.4.10 Routing In a .I.gl:routing; event, an MTA selects the "adjacent" MTA to which it will transfer a message, probe, or report. This event incrementally determines an information object's route through the MTS and (obviously) may be taken only if the MTS comprises several MTAs. The following kinds of routing are distinguished, on the basis of the kind of transfer for which they prepare: a) .I.gl:internal routing;: A routing preparatory to an internal transfer (i.e., a transfer within an MD). b) .I.gl:external routing;: A routing preparatory to an external transfer (i.e., a transfer between MDs). An MTA stages a routing when it determines that it can stage no other event, and take no step, regarding an object. 10. Security Model This clause provides an abstract security model for Message Transfer. The concrete realization of the model is the subject of other Recommendations in the set. The security model provides a framework for describing the security services that counter potential threats (see annex D) to the MTS and the security elements that support those services. The security features are an optional extension to the MHS that can be used to minimise the risk of exposure of assets and resources to violations of a security policy (threats). Their aim is to provide features independently of the communications services provided by other lower or higher entities. Threats may be countered by the use of physical security, computer security (.I.ab:COMPUSEC;), or security services provided by the MHS. Depending on the perceived threats, certain of the MHS security services will be selected in combination with appropriate physical security and COMPUSEC measures. The security services supported by the MHS are described below. The naming and structuring of the services are based on ISO 7498-2. Note - Despite these security features, certain attacks may by be mounted against communication between a user and the MHS or against user-to-user communication (e.g. in the case of users accessing their UAs). To counter these attacks requires extensions to the present security model and services which are for further study. In many cases, the broad classes of threats are covered by several of the services listed. The security services are supported through use of service elements of the Message Transfer Service message envelope. The envelope contains security relevant arguments as described in Recommendation X.411. The description of the security services takes the following general form. In clause 10.2 the services are listed, with, in each case, a definition of the service and an indication of how it may be provided using the security elements in Recommendation X.411. In clause 10.3 the security elements are individually described, with, in each case, a definition of the service element and references to its constituent arguments in Recommendation X.411. Many of the techniques employed rely on encryption mechanisms. The security services in the MHS allow for flexibility in the choice of algorithms. However, in some cases only the use of asymmetric encryption has been fully defined in this Recommendation. A future version of this Recommendation may make use of alternative mechanisms based on symmetric encipherment. Note The use of the terms "security service" and "security element" in this clause are not to be confused with the terms "service" and "element of service" as used in Recommendation X.400. The former terms are used in the present clause to maintain consistency with ISO 7498-2. 10.1 Security Policies Security services in the MHS must be capable of supporting a wide range of security policies which extend beyond the confines of the MHS itself. The services selected and the threats addressed will depend on the individual application and levels of trust in parts of the system. A security policy defines how the risk to and exposure of assets can be reduced to an acceptable level. In addition, operation between different domains, each with their own security policy, will be required. As each domain will be subject to its own overall security policy, covering more than just the MHS, a bilateral agreement on interworking between two domains will be required. This must be defined so as not to conflict with the security policies for either domain and effectively becomes part of the overall security policy for each domain. 10.2 Security Services This clause defines the Message Transfer security services. The naming and structuring of the services are based on ISO 7498-2. MHS security services fall into several broad classes. These classes and the services in each are listed in Table 7/X.402. An asterisk (*) under the heading of the form X/Y indicates that the service can be provided from a functional object of type X to one of type Y. Table .T.:7/X.402 Message Transfer Security Services +-------------------------------+-------------------------------+ | | UA/UA MS/MTA UA/MTA MTA/UA | | SERVICE | UA/MS UA/M A MTA/MTA MS/UA | +- ORIGIN AUTHENTICATION -------+----------------------- ---------+ | Message Origin Authentication | * * - * - - - - | | Probe Origin Authentication | - - * * - - - - | | Report Origin Authentication | - - - - * * - - | | Proof of Submission | - - - - - - * - | | Proof of Delivery | * - - - - - - Note | +- SECURE ACCESS MANAGEMENT ----+-------------------------------+ | Peer Entity Authentication | - * * * * * * * | | Security Context | - * * * * * * * | +- DATA CONFIDENTIALITY --------+--------------------- -----------+ | Connection Confidentiality | - * * * * * * * | | Content Confidentiality | * - - - - - - - | | Message Flow Confidentiality | * - - - - - - - | +- DATA INTEGRITY SERVICES -----+-------- -----------------------+ | Connection Integrity | - * * * * * * * | | Content Integrity | * - - - - - - - | | Message Sequence Integrity | * - - - - - - - | +- NON-REPUDIATION ------------ --+-------------------------------+ | Non-repudiation of Origin | * - - * - - - - | | Non-repudiation of Submission | - - - - - - * - | | Non-repudiation of Delivery | * - - - - - - - | | Message Security Labelling | * * * * * * * * | +- SECURITY MANAGEMENT SERVICES +------ --------------------------+ | Change Credentials | - * - * * * * - | | Register | - * - * - - - - | +--------- -----------------------+-------------------------------+ Note This service is provided by the recipient's MS to the originator's UA. Throughout the security service definitions that follow, reference is made to Figure 6/X.402, which reiterates the MHS functional model in simplified form. The numeric labels are referenced in the text. +------+ +------+ | 1 | | 5 | | MTS- | | MT - | | user | | user | +------+ +-- -----+ | | +------+ +------+ +------+ | 2 | | 3 | | 4 | | MTA |-----| MTA |-----| MTA | | | | | | | +------+ +------+ +------+ Figure .F.:6/X.402 Simplified MHS Functional Model 10.2.1 Origin Authentication Security Services These security services provide for the authentication of the identity of communicating peer entities and sources of data. 10.2.1.1 Data Origin Authentication Security Services These security services provide corroboration of the origin of a message, probe, or report to all concerned entities (i.e., MTAs or recipient MTS-users). These security services cannot protect against duplication of messages, probes, or reports. 10.2.1.1.1 Message Origin Authentication Security Service The Message Origin Authentication Service enables the corroboration of the source of a message. This security service can be provided using either the Message Origin Authentication or the Message Argument Integrity security element. The former can be used to provide the security service to any of the parties concerned (1-5 inclusive in the figure), whereas the latter can only be used to provide the security service to MTS-users (1 or 5 in the figure). The security element chosen depends on the prevailing security policy. 10.2.1.1.2 Probe Origin Authentication Security Service The Probe Origin Authentication security service enables the corroboration of the source of a probe. This security service can be provided by using the Probe Origin Authentication security element. This security element can be used to provide the security service to any of the MTAs through which the probe is transferred (2-4 inclusive in the figure). 10.2.1.1.3 Report Origin Authentication Security Service The Report Origin Authentication security service enables the corroboration of the source of a report. This security service can be provided by using the Report Origin Authentication security element. This security element can be used to provide the security service to the originator of the subject message or probe, as well as to any MTA through which the report is transferred (1-5 inclusive in the figure). 10.2.1.2 Proof of Submission Security Service This security service enables the originator of a message to obtain corroboration that it has been received by the MTS for delivery to the originally specified recipient(s). This security service can be provided by using the Proof of Submission security element. 10.2.1.3 Proof of Delivery Security Service This security service enables the originator of a message to obtain corroboration that it has been delivered by the MTS to its intended recipient(s). This security service can be provided by using the Proof of Delivery security element. 10.2.2 Secure Access Management Security Service The Secure Access Management security service is concerned with providing protection for resources against their unauthorised use. It can be divided into two components, namely the Peer Entity Authentication and the Security Context security services. 10.2.2.1 Peer Entity Authentication Security Service This security service is provided for use at the establishment of a connection to confirm the identity of the connecting entity. It may be used on the links 1-2, 2-3, 3-4, or 4-5 in the figure and provides confidence, at the time of usage only, that an entity is not attempting a masquerade or an unauthorised replay of a previous connection. This security service is supported by the Authentication Exchange security element. Note that use of this security element may yield other data as a result of its operation that in certain circumstances can be used to support a Connection Confidentiality and/or a Connection Integrity security service. 10.2.2.2 Security Context Security Service This security service is used to limit the scope of passage of messages between entities by reference to the Security Labels associated with messages. This security service is therefore closely related to the Message Security Labelling security service, which provides for the association of messages and Security Labels. The Security Context security service is supported by the Security Context and the Register security elements. 10.2.3 Data Confidentiality Security Services These security services provide for the protection of data against unauthorised disclosure. 10.2.3.1 Connection Confidentiality Security Service The MHS does not provide a Connection Confidentiality security service. However, data for the invocation of such a security service in underlying layers may be provided as a result of using the Authentication Exchange security element to provide the Peer Entity Authentication security service. The security service may be required on any of links 1-2, 2-3, 3-4, or 4-5 in the figure. 10.2.3.2 Content Confidentiality Security Service The Content Confidentiality security service provides assurance that the content of a message is only known to the sender and recipient of a message. It may be provided using a combination of the Content Confidentiality and the Message Argument Confidentiality security elements. The Message Argument Confidentiality security element can be used to transfer a secret key which is used with the Content Confidentiality security element to encipher the message content. Using these security elements the service is provided from MTS-user 1 to MTS-user 5 in the figure, with the message content being unintelligible to MTAs. 10.2.3.3 Message Flow Confidentiality Security Service This security service provides for the protection of information which might be derived from observation of message flow. Only a limited form of this security service is provided by the MHS. The Double Enveloping Technique enables a complete message to become the content of another message. This could be used to hide addressing information from certain parts of the MTS. Used in conjunction with traffic padding (which is beyond the scope of this Recommendation) this could be used to provide message flow confidentiality. Other elements of this service, such as routing control or pseudonyms, are also beyond the scope of this Recommendation. 10.2.4 Data Integrity Security Services These security services are provided to counter active threats to the MHS. 10.2.4.1 Connection Integrity Security Service The MHS does not provide a Connection Integrity security service. However, data for the invocation of such a security service in underlying layers may be provided by using the Authentication Exchange security element to provide the Peer Entity Authentication security service. The security service may be required on any of links 1-2, 2-3, 3-4, or 4-5 in the figure. 10.2.4.2 Content Integrity Security Service This security service provides for the integrity of the contents of a single message. This takes the form of enabling the determination of whether the message content has been modified. This security service does not enable the detection of message replay, which is provided by the Message Sequence Integrity security service. This security service can be provided in two different ways using two different combinations of security elements. The Content Integrity security element together with the Message Argument Integrity security element and, in some cases, the Message Argument Confidentiality security element can be used to provide the security service to a message recipient, i.e., for communication from MTS-user 1 to MTS-user 5 in the figure. The Content Integrity security element is used to compute a Content Integrity Check as a function of the entire message content. Depending on the method used to compute the Content Integrity Check, a secret key may be required, which may be confidentially sent to the message recipient using the Message Argument Confidentiality security element. The Content Integrity Check is protected against change using the Message Argument Integrity security element. The integrity of any confidential message arguments is provided using the Message Argument Confidentiality security element. The Message Origin Authentication security element can also be used to provide this security service. 10.2.4.3 Message Sequence Integrity Security Service This security service protects the originator and recipient of a sequence of messages against re-ordering of the sequence. In doing so it protects against replay of messages. This security service may be provided using a combination of the Message Sequence Integrity and the Message Argument Integrity security elements. The former provides a sequence number to each message, which may be protected against change by use of the latter. Simultaneous confidentiality and integrity of the Message Sequence Number may be provided by use of the Message Argument Confidentiality security element. These security elements provide the service for communication from MTS-user 1 to MTS-user 5 in the figure, and not to the intermediate MTAs. 10.2.5 Non-Repudiation Security Services These security services provide irrevocable proof to a third party after the message has been submitted, sent, or delivered, that the submission, sending, or receipt did occur as claimed. Note that for this to function correctly, the security policy must explicitly cover the management of asymmetric keys for the purpose of non-repudiation services if asymmetric algorithms are being used. 10.2.5.1 Non-repudiation of Origin Security Service This security service provides the recipient(s) of a message with irrevocable proof of the origin of the message, its content, and its associated Message Security Label. This security service can be provided in two different ways using two different combinations of security elements. Note that its provision is very similar to the provision of the (weaker) Content Integrity security service. The Content Integrity security element together with the Message Argument Integrity security element and, in some cases, the Message Argument Confidentiality security element can be used to provide the service to a message recipient, i.e., for communication from MTS-user 1 to MTS-user 5 in the figure. The Content Integrity security element is used to compute a Content Integrity Check as a function of the entire message content. Depending on the method used to compute the Content Integrity Check, a secret key may be required, which may be confidentially sent to the message recipient using the Message Argument Confidentiality security element. The Content Integrity Check and, if required, the Message Security Label are protected against change and/or repudiation using the Message Argument Integrity security element. Any confidential message arguments are protected against change and/or repudiation using the Message Argument Confidentiality security element. If the Content Confidentiality security service is not required, the Message Origin Authentication security element may also be used as a basis for this security service. In this case the security service may be provided to all elements of the MHS, i.e., for all of 1-5 in the figure. 10.2.5.2 Non-Repudiation of Submission Security Service This security service provides the originator of the message with irrevocable proof that the message was submitted to the MTS for delivery to the originally specified recipient(s). This security service is provided using the Proof of Submission security element in much the same way as that security element is used to support the (weaker) Proof of Submission security service. 10.2.5.3 Non-Repudiation of Delivery Security Service This security service provides the originator of the message with irrevocable proof that the message was delivered to its originally specified recipient(s). This security service is provided using the Proof of Delivery security element in much the same way as that security element is used to support the (weaker) Proof of Delivery security service. 10.2.6 Message Security Labelling Security Service This security service allows Security Labels to be associated with all entities in the MHS, i.e., MTAs and MTS-users. In conjunction with the Security Context security service it enables the implementation of security policies defining which parts of the MHS may handle messages with specified associated Security Labels. This security service is provided by the Message Security Label security element. The integrity and confidentiality of the label are provided by the Message Argument Integrity and the Message Argument Confidentiality security elements. 10.2.7 Security Management Services A number of security management services are needed by the MHS. The only management services provided within Recommendation X.411 are concerned with changing credentials and registering MTS-user security labels. 10.2.7.1 Change Credentials Security Service This security service enables one entity in the MHS to change the credentials concerning it held by another entity in the MHS. It may be provided using the Change Credentials security element. 10.2.7.2 Register Security Service This security service enables the establishment at an MTA of the Security Labels which are permissible for one particular MTS-user. It may be provided using the Register security element. 10.2.7.3 MS-Register Security Service The security service enables the establishment of the security label which ar permissible for the MS-user. 10.3 Security Elements The following clauses describe the security elements available in the protocols described within Recommendation X.411 to support the security services in the MHS. These security elements relate directly to arguments in various services described in Recommendation X.411. The objective of this clause is to separate out each element of the Recommendation X.411 service definitions that relate to security, and to define the function of each of these identified security elements. 10.3.1 Authentication Security Elements These security elements are defined in order to support authentication and integrity security services. 10.3.1.1 Authentication Exchange Security Element The Authentication Exchange security element is designed to authenticate, possibly mutually, the identity of an MTS-user to an MTA, an MTA, an MS to a UA, or a UA to an MS to an MTS-user. It is based on the exchange or use of secret data, either passwords, asymmetrically encrypted tokens, or symmetrically encrypted tokens. The result of the exchange is corroboration of the identity of the other party, and, optionally, the transfer of confidential data which may be used in providing the Connection Confidentiality and/or the Connection Integrity security service in underlying layers. Such an authenication is only valid for the instant that it is made and the continuing validity of the authenticated identity depends on whether the exchange of confidential data, or some other mechanism, is used to establish a secure communication path. The establishment and use of a secure communication path. The establishment and use of a secure communication path is outside the scope of this Recommendation. This security element uses the Initiator Credentials argument and the Responder Credentials result of the MTS-bind, MS-bind and MTA-bind services. The transferred credentials are either passwords or tokens. 10.3.1.2 Data Origin Authentication Security Elements These security elements are specifically designed to support data origin authentication services, although they may also be used to support certain data integrity services. 10.3.1.2.1 Message Origin Authentication Security Element The Message Origin Authentication security element enables anyone who receives or transfers message to authenticate the identity of the MTS-user that originated the message. This may mean the provision of the Message Origin Authentication or the Non-repudiation of Origin security service. The security element involves transmitting, as part of the message, a Message Origin Authentication Check, computed as a function of the message content, the message Content Identifier, and the Message Security Label. If the Content Confidentiality security service is also required, the Message Origin Authentication Check is computed as a function of the enciphered rather than the unenciphered message content. By operating on the message content as conveyed in the overall message (i.e., after the optional Content Confidentiality security element), any MHS entity can check the overall message integrity without the need to see the plaintext message content. However, if the Content Confidentiality security service is used, the Message Origin Authentication security element cannot be used to provide the Non-repudiation of Origin security service. The security element uses the Message Origin Authentication Check, which is one of the arguments of the Message Submission, Message Transfer, and Message Delivery services. 10.3.1.2.2 Probe Origin Authentication Security Element Similar to the Message Origin Authentication security element, the Probe Origin Authentication security element enables any MTA to authenticate the identity of the MTS-user which originated a probe. This security element uses the Probe Origin Authentication Check, which is one of the arguments of the Probe Submission service. 10.3.1.2.3 Report Origin Authentication Security Element Similar to the Message Origin Authentication security element, the Report Origin Authentication security element enables any MTA or MTS-user who receives a report to authenticate the identity of the MTA which originated the report. This security element uses the Report Origin Authentication Check, which is one of the arguments of the Report Delivery service. 10.3.1.3 Proof of Submission Security Element This security element provides the originator of a message with the means to establish that a message was accepted by the MHS for transmission. The security element is made up of two arguments: a request for Proof of Submission, sent with a message at submission time, and the Proof of Submission, returned to the MTS-user as part of the Message Submission results. The Proof of Submission is generated by the MTS, and is computed as a function of all the arguments of the submitted message, the Message Submission Identifier, and the Message Submission Time. The Proof of Submission argument can be used to support the Proof of Submission security service. Depending on the security policy in force, it may also be able to support the (stronger) Non-repudiation of Submission security service. The Proof of Submission Request is an argument of the Message Submission service. The Proof of Submission is one of the results of the Message Submission service. 10.3.1.4 Proof of Delivery Security Element This security element provides the originator of a message with the means to establish that a message was delivered to the destination by the MHS. The security element is made up of a number of arguments. The message originator includes a Proof of Delivery Request with the submitted message, and this request is delivered to each recipient with the message. A recipient may then compute the Proof of Delivery as a function of a number of arguments associated with the message. The proof of delivery is returned by the MTS to the message originator, as part of a report on the results of the original Message Submission. The Proof of Delivery can be used to support the Proof of Delivery security service. Depending on the security policy in force, it may also be able to support the (stronger) Non-repudiation of Delivery security service. The Proof of Delivery Request is an argument of the Message Submission, Message Transfer, and Message Delivery services. The Proof of Delivery is both one of the results of the Message Delivery service and one of the arguments of the Report Transfer and Report Delivery services. Note - Non-receipt of a Proof of Delivery does not imply non-delivery. 10.3.2 Secure Access Management Security Elements These security elements are defined in order to support the Secure Access Management security service and the security management services. 10.3.2.1 Security Context Security Element When an MTS-user or an MTA binds to an MTA or MTS-user, the bind operation specifies the security context of the connection. This limits the scope of passage of messages by reference to the labels associated with messages. Secondly, the Security Context of the connection may be temporarily altered for submitted or delivered messages. The Security Context itself consists of one or more Security Labels defining the sensitivity of interactions that may occur in line with the security policy in force. Security Context is an argument of the MTS-bind and MTA-bind services. 10.3.2.2 Register Security Element The Register security element allows the establishment at an MTA of an MTS-user's permissible security labels. This security element is provided by the Register service. The Register service enables an MTS-user to change arguments, held by the MTS, relating to delivery of messages to that MTS-user. 10.3.2.3 MS-Register Security Element The MS-Register security element allows the establishment of the MS-user's permissible security labels. This security element is provided by the MS-Register service. The MS-Register services enables an MS-user to change arguments held by the MS relating to the retrieval of messages to that MS-user. 10.3.3 Data Confidentiality Security Elements These security elements, based on the use of encipherment, are all concerned with the provision of confidentiality of data passed from one MHS entity to another. 10.3.3.1 Content Confidentiality Security Element The Content Confidentiality security element provides assurance that the content of the message is protected from eavesdropping during transmission by use of an encipherment security element. The security element operates such that only the recipient and sender of the message know the plaintext message content. The specification of the encipherment algorithm, the key used, and any other initialising data are conveyed using the Message Argument Confidentiality and the Message Argument Integrity security elements. The algorithm and key are then used to encipher or decipher the message contents. The Content Confidentiality security element uses the Content Confidentiality Algorithm Identifier, which is an argument of the Message Submission, Message Transfer, and Message Delivery services. 10.3.3.2 Message Argument Confidentiality Security Element The Message Argument Confidentiality security element provides for the confidentiality, integrity, and, if required, the irrevocability of recipient data associated with a message. Specifically, this data will comprise any cryptographic keys and related data that is necessary for the confidentiality and integrity security elements to function properly, if these optional security elements are invoked. The security element operates by means of the Message Token. The data to be protected by the Message Argument Confidentiality security element constitutes the Encrypted Data within the Message Token. The Encrypted Data within the Message Token is unintelligible to all MTAs. The Message Token is an argument of the Message Submission, Message Transfer, and Message Delivery services. 10.3.4 Data Integrity Security Elements These security elements are provided to support the provision of data integrity, data authentication, and non-repudiation services. 10.3.4.1 Content Integrity Security Element The Content Integrity security element provides protection for the content of a message against modification during transmission. This security element operates by use of one or more cryptographic algorithms. The specification of the algorithm(s), the key(s) used, and any other initialising data are conveyed using the Message Argument Confidentiality and the Message Argument Integrity security elements. The result of the application of the algorithms and key is the Content Integrity Check, which is sent in the message envelope. The security element is only available to the recipient(s) of the message as it operates on the plaintext message contents. If the Content Integrity Check is protected using the Message Argument Integrity security element then, depending on the prevailing security policy, it may be used to help provide the Non-repudiation of Origin security service. The Content Integrity Check is an argument of the Message Submission, Message Transfer, and Message Delivery services. 10.3.4.2 Message Argument Integrity Security Element The Message Argument Integrity security element provides for the integrity, and, if required, the irrevocability of certain arguments associated with a message. Specifically, these arguments may comprise any selection of the Content Confidentiality Algorithm Identifier, the Content Integrity Check, the Message Security Label, the Proof of Delivery Request, and the Message Sequence Number. The security element operates by means of the Message Token. The data to be protected by the Message Argument Integrity security element constitutes the signed-data within the Message Token. The Message Token is an argument of the Message Submission, Message Transfer, and Message Delivery services. 10.3.4.3 Message Sequence Integrity Security Element The Message Sequence Integrity security element provides protection for the sender and recipient of a message against receipt of messages in the wrong order, or duplicated messages. A Message Sequence Number is associated with an individual message. This number identifies the position of a message in a sequence from one originator to one recipient. Therefore each originator-recipient pair requiring to use this security element will have to maintain a distinct sequence of message numbers. This security element does not provide for initialisation or synchronisation of Message Sequence Numbers. 10.3.5 Non-repudiation Security Elements There are no specific Non-repudiation security elements defined in Recommendation X.411. The non-repudiation services may be provided using a combination of other security elements. 10.3.6 Security Label Security Elements These security elements exist to support security labelling in the MHS. 10.3.6.1 Message Security Label Security Element Messages may be labelled with data as specified in the prevailing security policy. The Message Security Label is available for use by intermediate MTAs as part of the overall security policy of the system. A Message Security Label may be sent as a message argument, and may be protected by the Message Argument Integrity or the Message Origin Authentication security element, in the same manner as other message arguments. Alternatively, if both confidentiality and integrity are required, the Message Security Label may be protected using the Message Argument Confidentiality security element. In this case the Message Security Label so protected is an originator-recipient argument, and may differ from the Message Security Label in the message envelope. 10.3.7 Security Management Security Elements 10.3.7.1 Change Credentials Security Element The Change Credentials security element allows the credentials of an MTS-user or an MTA to be updated. The security element is provided by the MTS Change Credentials service. 10.3.8 Double Enveloping Technique Additional protection may be provided to a complete message, including the envelope parameters, by the ability to specify that the content of a message is itself a complete message, i.e., a Double Enveloping Technique is available. This technique is available though the use of the Content Type argument which makes it possible to specify that the content of a message is an Inner Envelope. This Content Type means that the content is itself a message (envelope and content) for forwarding by the recipient named on the outer envelope to the recipient named on the Inner Envelope. The Content Type is an argument of the Message Submission, Message Transfer, and Message Delivery services.