Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 1327

Mapping between X.400(1988) / ISO 10021 and RFC 822

Pages: 113
Obsoletes:  0987102611381148
Obsoleted by:  2156
Updates:  0822
Updated by:  1495
Part 3 of 4 – Pages 59 to 91
First   Prev   Next

ToP   noToC   RFC1327 - Page 59   prevText
Chapter 5 - Detailed Mappings

   This chapter specifies  detailed mappings for the functions outlined
   in Chapters 1 and 2.  It makes extensive use of the notations and
   mappings defined in Chapters 3 and 4.

5.1.  RFC 822 -> X.400

5.1.1.  Basic Approach

   A single IP Message is generated from an RFC 822 message The RFC 822
   headers are used to generate the IPMS.Heading.  The IP Message will
   have one IA5 IPMS.BodyPart containing the RFC 822 message body.

   Some RFC 822 fields cannot be mapped onto a standard IPM Heading
   field, and so an extended field is defined in Section 5.1.2.  This is
   then used for fields which cannot be mapped onto existing services.

   The message is submitted to the MTS, and the services required can be
   defined by specifying MTS.MessageSubmissionEnvelope.  A few
   parameters of the MTA Abstract service are also specified, which are
   not in principle available to the MTS User.  Use of these services
   allows RFC 822 MTA level parameters to be carried in the analogous
   X.400 service elements.  The advantages of this mapping far outweigh
   the layering violation.

5.1.2.  X.400 Extension Field

   An IPMS Extension is defined:

        rfc-822-field HEADING-EXTENSION
                VALUE RFC822FieldList
                ::= id-rfc-822-field-list
ToP   noToC   RFC1327 - Page 60
        RFC822FieldList ::= SEQUENCE OF RFC822Field

        RFC822Field ::= IA5String

   The Object Identifier id-rfc-822-field-list is defined in Appendix D.

   To encode any RFC 822 Header using this extension, an RFC822Field
   element is built using the 822.field omitting the trailing CRLF
   (e.g., "Fruit-Of-The-Day: Kiwi Fruit"). Structured fields shall be
   unfolded.  There shall be no space before the ":".  The reverse
   mapping builds the RFC 822 field in a straightforward manner.  This
   RFC822Field is appended to the RFC822FieldList, which is added to the
   IPM Heading as an extension field.

5.1.3.  Generating the IPM

   The IPM (IPMS Service Request) is generated according to the rules of
   this section. The IPMS.IPM.body usually consists of one IPMS.BodyPart
   of type IPMS.IA5TextBodyPart with
   IPMS.IA5TextBodyPart.parameters.repertoire set to the default (ia5)
   which contains the body of the RFC 822 message.  The exception is
   where there is a "Comments:" field in the RFC 822 header.

   If no specific 1988 features are used, the IPM generated is encoded
   as content type 2.  Otherwise, it is encoded as content type 22.  The
   latter will always be the case if extension heading fields are

   When generating the IPM, the issue of upper bounds must be
   considered.  At the MTS and MTA level, this specification is strict
   about enforcing upper bounds. Three options are available at the IPM
   level.  Use of any of these options conforms to this standard.

   1.   Ignore upper bounds, and generate messages in the natural
        manner.  This assumes that if any truncation is done, it
        will happen at the recipient UA.  This will maximise
        transfer of information, but is likely break some recipient

   2.   Reject any inbound message which would cause a message
        violating constraints to be generated.  This will be robust,
        but may prevent useful communication.

   3.   Truncate fields to the upper bounds specified in X.400.

        This will prevent problems with UAs which enforce upper
        bounds, but will sometimes discard useful information.
ToP   noToC   RFC1327 - Page 61
        If the Free Form name is truncated, it may lead to breaking
        RFC 822 comments, which will cause an awkward reverse

   These options have different advantages and disadvantages, and the
   choice will depend on the exact application of the gateway.

   The rest of this section concerns IPMS.IPM.heading (IPMS.Heading).
   The only mandatory component of IPMS.Heading is the
   IPMS.Heading.this-IPM (IPMS.IPMIdentifier).  A default is generated
   by the gateway.  With the exception of "Received:", the values of
   multiple fields are merged (e.g., If there are two "To:" fields, then
   the mailboxes of both are merged to generate a single list which is
   used in the IPMS.Heading.primary-recipients.  Information shall be
   generated from the standard RFC 822 Headers as follows:

        Ignore (Handled at MTS level)

        Ignore (Handled at MTA level)

        Mapped to IPMS.Heading.this-IPM.  For these, and all other
        fields containing 822.msg-id the mappings of Chapter 4 are
        used for each 822.msg-id.

        If Sender: is present, this is mapped to
        IPMS.Heading.authorizing-users.  If not, it is mapped to
        IPMS.Heading.originator.  For this, and other components
        containing addresses, the mappings of Chapter 4 are used for
        each address.

        Mapped to IPMS.Heading.originator.

        Mapped to IPMS.Heading.reply-recipients.

   To:  Mapped to IPMS.Heading.primary-recipients

   Cc:  Mapped to IPMS.Heading.copy-recipients.

   Bcc: Mapped to IPMS.Heading.blind-copy-recipients if there is at
        least one BCC:  recipient.  If there are no recipients in
        this field, it should be mapped to a zero length sequence.
ToP   noToC   RFC1327 - Page 62
        If there is one value, it is mapped to
        IPMS.Heading.replied-to-IPM, using the 822.phrase or
        822.msg-id mapping as appropriate.  If there are several
        values, they are mapped to IPMS.Heading.related-IPMs, along
        with any values from a "References:" field.

        Mapped to IPMS.Heading.related-IPMs.

        Mapped onto a heading extension.

        Mapped to IPMS.Heading.subject.  The field-body uses the
        human oriented mapping referenced in Chapter 3 from ASCII to

        Generate an IPMS.BodyPart of type IPMS.IA5TextBodyPart with
        IPMS.IA5TextBodyPart.parameters.repertoire set to the
        default (ia5), containing the value of the fields, preceded
        by the string "Comments: ".  This body part shall precede
        the other one.

        Mapped onto a heading extension.

        Mapped onto a heading extension.

        Note that it would be possible to use a ForwardedIPMessage
        for these fields, but the semantics are (arguably) slightly
        different, and it is probably not worth the effort.

   Other Fields

        In particular X-* fields, and "illegal" fields in common
        usage (e.g., "Fruit-of-the-day:") are mapped onto a heading
        extension, unless covered by another section or appendix of
        this specification.  The same treatment is applied to RFC
        822 fields where the content of the field does not conform
        to RFC 822 (e.g., a Date: field with unparseable syntax).

5.1.4.  Mappings to the MTS Abstract Service

   The MTS.MessageSubmissionEnvelope comprises
   MTS.PerMessageSubmissionFields, and
ToP   noToC   RFC1327 - Page 63
   MTS.PerRecipientMessageSubmissionFields.  The mandatory parameters
   are defaulted as follows.

        This is always generated from 822-MTS, as defined in
        Chapter 4.

        Set to the value implied by the encoding of the IPM (2 or

        These will always be supplied from 822-MTS, as defined in
        Chapter 4.

   Optional components are omitted, and default components defaulted.
   This means that disclosure of recipients is prohibited and conversion
   is allowed.  There are two exceptions to the defaulting. For
   MTS.PerMessageSubmissionFields.per-message-indicators, the following
   settings are made:

   -    Alternate recipient is allowed, as it seems desirable to
        maximise the opportunity for (reliable) delivery.

   -    Content return request is set according to the issues
        discussed in Section 5.2.

   MTS.PerMessageSubmissionFields.original-encoded-information-types is
   a set of one element BuiltInEncodedInformationTypes.ia5-text.

   The MTS.PerMessageSubmissionFields.content-correlator is encoded as
   IA5String, and contains the Subject:, Message-ID:, Date:,  and

   To: fields (if present).  This  includes the strings "Subject:",
   "Date:", "To:", "Message-ID:", and appropriate folding.  This shall
   be truncated to MTS.ub-content-correlator-length (512) characters.
   In addition, if there is a "Subject:" field, the
   MTS.PerMessageSubmissionFields.content-identifier, is set to a
   printable string representation of the contents of it.   If the
   length of this string is greater than MTS.ub-content-id-length (16),
   it should be truncated to 13 characters and the string "..."
   appended. Both are used, due to the much larger upper bound of the
   content correlator, and that the content id is available in

5.1.5.  Mappings to the MTA Abstract Service

   There is a need to map directly onto some aspects of the MTA Abstract
ToP   noToC   RFC1327 - Page 64
   service, for the following reasons:

   -    So the the MTS Message Identifier can be generated from the
        RFC 822 Message-ID:.

   -    So that the submission date can be generated from the

   -    To prevent loss of trace information

   -    To prevent RFC 822/X.400 looping caused by distribution
        lists or redirects

   The following mappings are defined.

        If this is present, the
        MTA.PerMessageTransferFields.message-identifier is generated
        from it, using the mappings described in Chapter 4.

        This is used to set the first component of
        (MTA.TraceInformationElement).  The 822-MTS originator is
        mapped into an MTS.ORAddress, and used to derive  The
        optional components of
        MTA.TraceInformationElement.domain-supplied-information are
        omitted, and the mandatory components are set as follows:

             This is set to the date derived from Date:

             Set to relayed.

        The first element of
        MTA.PerMessageTransferFields.internal-trace-information is
        generated in an analogous manner, although this can be
        dropped later in certain circumstances (see the procedures
        for "Received:").  The
        MTA.InternalTraceInformationElement.mta-name is derived from
        the 822.domain in the 822 MTS Originator address.

        All RFC 822 trace is used to derive
        MTA.PerMessageTransferFields.trace-information and
ToP   noToC   RFC1327 - Page 65
        Processing of Received: lines  follows processing of Date:,
        and is be done from the the bottom to the top of the RFC 822
        header (i.e., in chronological order).  When other trace
        elements are processed (X400-Received: in all cases and Via:
        if Appendix B is supported), the relative ordering shall be
        retained correctly.  The initial element of
        MTA.PerMessageTransferFields.trace-information will be
        generated already (from Date:), unless the message has
        previously been in X.400, when it will be derived from the
        X.400 trace information.

        Consider the Received: field in question.  If the "by"  part
        of the received is present, use it to derive an
        MTS.GlobalDomainIdentifier.  If this is different from the
        one in the last element of
        create a new MTA.TraceInformationElement, and optionally
        This removal shall be done in cases where the message is
        being transferred to another MD where there is no bilateral
        agreement to preserve internal trace beyond the local MD.
        The trace creation is as for internal trace described below,
        except that no MTA field is needed.

        Then add a new element (MTA.InternalTraceInformationElement)
        to MTA.PerMessageTransferFields.internal-trace-information,
        creating this if needed.  This shall be done, even if
        inter-MD trace is created.  The
        is set to the value derived.  The
        (MTA.MTASuppliedInformation) is set as follows:

             Derived from the date of the Received: line

             Set to relayed

        The MTA.InternalTraceInformationElement.mta-name is taken
        from the "by" component of the "Received:" field, truncated
        to MTS.ub-mta-name-length (32).  For example:

           Received: from by
              vs6.Cs.Ucl.AC.UK via Janet with NIFTP  id aa03794;
              28 Mar 89 16:38 GMT
ToP   noToC   RFC1327 - Page 66
   Generates the string


   Note that before transferring the message to some ADMDs, additional
   trace stripping may be required, as the implied path through multiple
   MDs would violate ADMD policy.   This will depend on bilateral
   agreement with the ADMD.

5.1.6.  Mapping New Fields

   This specification defines a number of new fields for Reports,
   Notifications and IP Messages in Section 5.3.  As this specification
   only aims to preserve existing services, a gateway conforming to this
   specification does not need to map all of these fields to X.400.

   Two  extended fields must be mapped, in order to prevent looping.
   "DL-Expansion-History:" is mapped to

   MTA.PerMessageTransferFields.extensions.dl-expansion-history X400-
   Received: must be mapped to MTA.PerMessageTransferFields.trace-
   information and MTA.PerMessageTransferFields.internal-trace-
   information.  In cases where X400-Received: is present, the usual
   mapping of Date: to generate the first element of trace should not be
   done.   This is because the message has come from X.400, and so the
   first element of trace can be taken from the first X400-Received:.

   Some field that shall not be mapped, and should be discarded.  The
   following cannot be mapped back:

   -    Discarded-X400-MTS-Extensions:

   -    Message-Type:

   -    Discarded-X400-IPMS-Extensions:

   If Message-Type: is set to "Multiple Part", then the messge is
   encoded according to RFC 934, and this may be mapped on to the
   corresponding X.400 structures.

   The following may cause problems, due to other information not being
   mapped back (e.g., extension numbers), or due to changes made on the
   RFC 822 side due to list expansion:

   -    X400-Content-Type:

   -    X400-Originator:
ToP   noToC   RFC1327 - Page 67
   -    X400-Recipients:

   -    X400-MTS-Identifier:

   Other fields may be either discarded or mapped to X.400.  It is
   usually desirable and beneficial to do map, particularly to
   facilitate support of a message traversing multiple gateways.  These
   mappings may be onto MTA, MTS, or IPMS services.  The level of
   support for this reverse mapping should be indicated in the gateway
   conformace statement.

5.2.  Return of Contents

   It is not clear how widely supported the X.400 return of contents
   service will be.  Experience with X.400(1984) suggests that support
   of this service may not be universal.  As this service is expected in
   the RFC 822 world, two approaches are specified.  The choice will
   depend on the use of X.400 return of contents withing the X.400
   community being serviced by the gateway.

   In environments where return of contents is widely supported, content
   return can be requested as a service.  The content return service can
   then be passed back to the end (RFC 822) user in a straightforward

   In environments where return of contents is not widely supported, a
   gateway must make special provision to handle return of contents.
   For every message passing from RFC 822 -> X.400, content return
   request will not be requested, and report request always will be.
   When the delivery report comes back, the gateway can note that the
   message has been delivered to the recipient(s) in question.  If a
   non-delivery report is received, a meaningful report (containing some
   or all of the original message) can be sent to the 822-MTS
   originator.  If no report is received for a recipient, a (timeout)
   failure notice shall be sent to the 822-MTS originator.  The gateway
   may retransmit the X.400 message if it wishes.  When this approach is
   taken, routing must be set up so that error reports are returned
   through the same MTA.  This approach may be difficult to use in
   conjunction with some routing strategies.

5.3.  X.400 -> RFC 822

5.3.1.  Basic Approach

   A single RFC 822 message is generated from the incoming IP Message,
   Report, or IP Notification.   All IPMS.BodyParts are mapped onto a
   single RFC 822 body.  Other services are mapped onto RFC 822 header
   fields.  Where there is no appropriate existing field, new fields are
ToP   noToC   RFC1327 - Page 68
   defined for IPMS, MTS and MTA services.

   The gateway mechanisms will correspond to MTS Delivery.  As with
   submission, there are aspects where the MTA (transfer) services are
   also used. In particular, there is an optimisation to allow for
   multiple 822-MTS recipients.

5.3.2.  RFC 822 Settings

   An RFC 822 Service requires to have a number of mandatory fields in
   the RFC 822 Header.  Some 822-MTS services mandate specification of
   an 822-MTS Originator.  Even in cases where this is optional, it is
   usually desirable to specify a value.  The following defaults are
   defined, which shall be used if the mappings specified do not derive
   a value:

   822-MTS Originator
        If this is not generated by the mapping (e.g., for a
        Delivery Report), a value pointing at a gateway
        administrator shall be assigned.

        A value will always be generated

   From:If this is not generated by the mapping, it is assigned
        equal to the 822-MTS Originator.  If this is gateway
        generated, an appropriate 822.phrase shall be added.

   At least one recipient field
        If no recipient fields are generated, a field "To: list:;",
        shall be added.

   This will ensure minimal RFC 822 compliance.  When generating RFC 822
   headers, folding may be used.  It is recommended to do this,
   following the guidelines of RFC 822.

5.3.3.  Basic Mappings  Encoded Information Types

   This mapping from MTS.EncodedInformationTypes is needed in several
   disconnected places.  EBNF is defined as follows:

           encoded-info    = 1#encoded-type

           encoded-type    = built-in-eit / object-identifier

           built-in-eit    = "Undefined"         ; undefined (0)
ToP   noToC   RFC1327 - Page 69
                           / "Telex"             ; tLX (1)
                           / "IA5-Text"          ; iA5Text (2)
                           / "G3-Fax"            ; g3Fax (3)
                           / "TIF0"              ; tIF0 (4)
                           / "Teletex"           ; tTX (5)
                           / "Videotex"          ; videotex (6)
                           / "Voice"             ; voice (7)
                           / "SFD"               ; sFD (8)
                           / "TIF1"              ; tIF1 (9)

   MTS.EncodedInformationTypes is mapped onto EBNF.encoded-info.
   MTS.EncodedInformationTypes.non-basic-parameters is ignored.  Built
   in types are mapped onto fixed strings (compatible with X.400(1984)
   and RFC 987), and other types are mapped onto EBNF.object-identifier.  Global Domain Identifier

   The following simple EBNF is used to represent

           global-id = std-or-address

   This is encoded using the std-or-address syntax, for the attributes
   within the Global Domain Identifier.

5.3.4.  Mappings from the IP Message

   Consider that an IPM has to be mapped to RFC 822.  The IPMS.IPM
   comprises an IPMS.IPM.heading and IPMS.IPM.body.   The heading is
   considered first.  Some EBNF for new fields is defined:

        ipms-field = "Obsoletes" ":" 1#msg-id
                   / "Expiry-Date" ":" date-time
                   / "Reply-By" ":" date-time
                   / "Importance" ":" importance
                   / "Sensitivity" ":" sensitivity
                   / "Autoforwarded" ":" boolean
                   / "Incomplete-Copy" ":"
                   / "Language" ":" language
                   / "Message-Type" ":" message-type
                   / "Discarded-X400-IPMS-Extensions" ":" 1#oid

        importance      = "low" / "normal" / "high"

        sensitivity     = "Personal" / "Private" /
ToP   noToC   RFC1327 - Page 70

        language        = 2*ALPHA [ language-description ]
        language-description = printable-string

        message-type    = "Delivery Report"
                        / "InterPersonal Notification"
                        / "Multiple Part"

   The mappings and actions for the IPMS.Heading is now specified for
   each element.  Addresses, and Message Identifiers are mapped
   according to Chapter 4.  Other mappings are explained, or are
   straightforward (algorithmic).  If a field with addresses contains
   zero elements, it should be discarded, execpt for
   IPMS.Heading.blind-copy-recipients, which can be mapped onto BCC:
   (the only RFC 822 field which allows zero recipients).

        Mapped to "Message-ID:".

        If IPMS.Heading.authorizing-users is present this is mapped
        to Sender:, if not to "From:".

        Mapped to "From:".

        Mapped to "To:".

        Mapped to "Cc:".

        Mapped to "Bcc:".

        Mapped to "In-Reply-To:".

        Mapped to the extended RFC 822 field "Obsoletes:"

        Mapped to "References:".
ToP   noToC   RFC1327 - Page 71
        Mapped to "Subject:".  The contents are converted to ASCII
        (as defined in Chapter 3).  Any CRLF are not mapped, but are
        used as points at which the subject field must be folded.

        Mapped to the extended RFC 822 field "Expiry-Date:".

        Mapped to the extended RFC 822 field "Reply-By:".

        Mapped to "Reply-To:".

        Mapped to the extended RFC 822 field "Importance:".

        Mapped to the extended RFC 822 field "Sensitivity:".

        Mapped to the extended RFC 822 field "Autoforwarded:".

   The standard extensions (Annex H of X.420 / ISO 10021-7) are
   mapped as follows:

        Mapped to the extended RFC 822 field "Incomplete-Copy:".

        Mapped to the extended RFC 822 field "Language:", filling in
        the two letter code. The language-description may filled in
        with a human readable description of the language, and it is
        recommended to do this.

   If the RFC 822 extended header is found, this shall be mapped onto an
   RFC 822 header, as described in Section 5.1.2.

   If a non-standard extension is found, it shall be discarded, unless
   the gateway understands the extension and can perform an appropriate
   mapping onto an RFC 822 header field.  If extensions are discarded,
   the list is indicated in the extended RFC 822 field "Discarded-X400-

   The IPMS.Body is mapped into the RFC 822 message body.  Each
   IPMS.BodyPart is converted to ASCII as follows:
ToP   noToC   RFC1327 - Page 72
        The mapping is straightforward (see Chapter 3).

        The X.400 -> RFC 822 mapping  is recursively applied, to
        generate an RFC 822 Message.  If present, the is used
        for the MTS Abstract Service Mappings.  If present, the is mapped to
        the extended RFC 822 field "Delivery-Date:".

        If other body parts can be mapped to IA5, either by use of
        mappings defined in X.408 [CCITT88a], or by other reasonable
        mappings, this shall be done unless content conversion is

   If some or all of the body parts cannot be converted there are three
   options.  All of these conform to this standard.  A different choice
   may be made for the case where no body part can be converted:

   1.   The first option is to reject the message, and send a non-
        delivery notification.  This must always be done if
        conversion is prohibited.

   2.   The second option is to map a missing body part to something
        of the style:


                There was a foobarhere

                The widget gateway ate it


        This will allow some useful information to be transferred.
        As the recipient is likely to be a human (IPMS), then
        suitable action will usually be possible.

   3.   Finally both may be done.  In this case, the supplementary
        information in the (positive) Delivery Report shall make
        clear that something was sent on to the recipient with
        substantial loss of information.

   Where there is more than one IPMS.BodyPart, the mapping defined by
   Rose and Stefferud in [Rose85a], is used to map the separate
   IPMS.BodyParts in the single RFC 822 message body.  If this is done,
ToP   noToC   RFC1327 - Page 73
   a "Message-Type:" field with value "Multiple part" shall be added,
   which will indicate to a receiving gateway that the message may be
   unfolded according to RFC 934.

   Note:There is currently work ongoing to produce an upgrade to RFC
        934, which also allows for support of body parts with non-
        ASCII content (MIME).  When this work is released as an RFC,
        this specification will be updated to refer to it instead
        for RFC 934.

   For backwards compatibility with RFC 987, the following procedures
   shall also be followed.  If there are two IA5 body parts, and the
   first starts with the string "RFC-822-Headers:" as the first line,
   then the remainder of this body part shall be appended to the RFC 822

   An example message, illustrating a number of aspects is given below.

Received: from by via JANET
          with NIFTP id <>;
          Thu, 30 May 1991 18:24:55 +0100
X400-Received: by mta "" in
               / /C=gb/; Relayed;
               Thu, 30 May 1991 18:23:26 +0100
X400-Received: by /PRMD=HMG/ADMD=GOLD 400/C=GB/; Relayed;
               Thu, 30 May 1991 18:20:27 +0100
Message-Type: Multiple Part
Date: Thu, 30 May 1991 18:20:27 +0100
     [/PRMD=HMG/ADMD=GOLD 400/C=GB/;PC1000-910530172027-57D8]
Original-Encoded-Information-Types: ia5, undefined
X400-Content-Type: P2-1984 (2)
Content-Identifier: Email Problems
From: (Tel +44 71 217 3487)
Message-ID: <PC1000-910530172027-57D8*@MHS>
To: Jim Craigie <>
 (Receipt Notification Requested) (Non Receipt Notification Requested),
 Tony Bates <> (Receipt Notification Requested),
 Steve Kille <> (Receipt Notification Requested)
Subject: Email Problems

------------------------------ Start of body part 1

Hope you gentlemen.......
ToP   noToC   RFC1327 - Page 74

Stephen Harrison
UK GOSIP Project

------------------------------ Start of forwarded message 1

From: Urs Eppenberger <>
To: "Stephen.Harrison" <>
Subject: Response to Email link

- ------------------------------ Start of body part 1

Dear Mr Harrison......

- ------------------------------ End of body part 1

------------------------------ End of forwarded message 1

5.3.5.  Mappings from an IP Notification

   A message is generated, with the following fields:

        Set to the IPMS.IPN.ipn-originator.

   To:  Set to the recipient from MTS.MessageSubmissionEnvelope.
        If there have been redirects, the original address should be

        Set to the string  "X.400 Inter-Personal Notification" for a
        receipt notification and to "X.400 Inter-Personal
        Notification (failure)" for a non-receipt notification.

        Set to "InterPersonal Notification"

        Set to IPMS.IPN.subject-ipm

   The following EBNF is defined for the body of the Message.  This
   format is defined to ensure that all information from an
ToP   noToC   RFC1327 - Page 75
   interpersonal notification is available to the end user in a uniform

        ipn-body-format = ipn-description <CRLF>
                        [ ipn-extra-information <CRLF> ]
                        [ ipn-content-return ]

        ipn-description = ipn-receipt / ipn-non-receipt

        ipn-receipt = "Your message to:" preferred-recipient <CRLF>
                 "was received at" receipt-time <CRLF> <CRLF>
                 "This notification was generated"
                 acknowledgement-mode <CRLF>
                 "The following extra information was given:" <CRLF>
                 ipn-suppl <CRLF>

        ipn-non-receipt "Your message to:"
                preferred-recipient <CRLF>

        ipn-reason = ipn-discarded / ipn-auto-forwarded

        ipn-discarded = "was discarded for the following reason:"
                        discard-reason <CRLF>

        ipn-auto-forwarded = "was automatically forwarded." <CRLF>
                        [ "The following comment was made:"
                                auto-comment ]

        ipn-extra-information =
                 "The following information types were converted:"

        ipn-content-return = "The Original Message is not available"
                        / "The Original Message follows:"
                          <CRLF> <CRLF> message

        preferred-recipient = mailbox
        receipt-time        = date-time
        auto-comment        = printablestring
        ipn-suppl           = printablestring

        discard-reason     = "Expired" / "Obsoleted" /
                                "User Subscription Terminated"
ToP   noToC   RFC1327 - Page 76
        acknowledgement-mode = "Manually" / "Automatically"

   The mappings for elements of the common fields of IPMS.IPN
   (IPMS.CommonFields) onto this structure and the message header are:

        Mapped to "References:"

        Mapped  to "From:".

        Mapped to EBNF.preferred-recipient

        Mapped to EBNF.encoded-info in EBNF.ipn-extra-information

   The mappings for elements of IPMS.IPN.non-receipt-fields
   (IPMS.NonReceiptFields) are:

        Used to select between EBNF.ipn-discarded and

        Mapped to EBNF.discard-reason

        Mapped to

        This applies only to non-receipt notifications.
        EBNF.ipn-content-return should always be omitted for receipt
        notifications, and always be present in non-receipt
        notifications.  If present, the second option of
        EBNF.ipn-content-return is chosen, and an RFC 822 mapping of
        the message included.  Otherwise the first option is chosen.

   The mappings for elements of IPMS.IPN.receipt-fields
   (IPMS.ReceiptFields) are:

        Mapped to EBNF.receipt-time

        Mapped to EBNF.acknowledgement-mode
ToP   noToC   RFC1327 - Page 77
        Mapped to EBNF.ipn-suppl

   An example notification is:

           From: Steve Kille <>
           To: Julian Onions <>
           Subject: X.400 Inter-personal Notification
           Message-Type: InterPersonal Notification
           References: <1229.614418325@UK.AC.NOTT.CS>
           Date: Wed, 21 Jun 89 08:45:25 +0100

           Your message to: Steve Kille <>
           was automatically forwarded.
           The following comment was made:
                   Sent on to a random destination

           The following information types were converted: g3fax

5.3.6.  Mappings from the MTS Abstract Service

   This section describes the MTS mappings for User Messages (IPM and
   IPN).  This mapping is defined by specifying the mapping of
   MTS.MessageDeliveryEnvelope.  The following extensions to RFC 822 are
   defined to support this mapping:

        mts-field = "X400-MTS-Identifier" ":" mts-msg-id
                  / "X400-Originator" ":" mailbox
                  / "X400-Recipients" ":" 1#mailbox
                  / "Original-Encoded-Information-Types" ":"
                  / "X400-Content-Type" ":" mts-content-type
                  / "Content-Identifier" ":" printablestring
                  / "Priority" ":" priority
                  / "Originator-Return-Address" ":" 1#mailbox
                  / "DL-Expansion-History" ":" mailbox ";" date-time ";"
                  / "Conversion" ":" prohibition
                  / "Conversion-With-Loss" ":" prohibition
                  / "Requested-Delivery-Method" ":"
                                  1*( labelled-integer )
                  / "Delivery-Date" ":" date-time
                  / "Discarded-X400-MTS-Extensions" ":"
                                   1#( oid / labelled-integer )

        prohibition     = "Prohibited" / "Allowed"

        mts-msg-id       = "[" global-id ";" *text "]"
ToP   noToC   RFC1327 - Page 78
        mts-content-type = "P2" /  labelled-integer
                        / object-identifer

        priority        = "normal" / "non-urgent" / "urgent"

   The mappings for each element of MTS.MessageDeliveryEnvelope can now
   be considered.

        Mapped to the extended RFC 822 field "X400-MTS-Identifier:".

        Discarded, as this time will be represented in an
        appropriate trace element.

   The mappings for elements of
   (MTS.OtherMessageDeliveryFields) are:

        Mapped to the extended RFC 822 field "X400-Content-Type:".
        The string "P2" is retained for backwards compatibility with
        RFC 987. This shall not be generated, and either the
        EBNF.labelled-integer  or EBNF.object-identifier encoding

        Mapped to the 822-MTS originator, and to the extended RFC
        822 field "X400-Originator:".  This is described in
        Section 4.6.2.

        Mapped to the extended RFC 822 field

        Mapped to the extended RFC 822 field "Priority:".

        If the conversion-prohibited bit is set, add an extended RFC
        822 field "Conversion:".

   this-recipient-name and other-recipient-names

        The handling of these elements is described in
        Section 4.6.2.
ToP   noToC   RFC1327 - Page 79
        Discarded, as it will always be IA5 only.

        Mapped to Date:.

        Mapped to the extended RFC 822 field "Content-Identifier:".

   If any extensions (MTS.MessageDeliveryEnvelope.other-
   fields.extensions) are present, and they are marked as critical for
   transfer or delivery, then the message shall be rejected.  The
   extensions (MTS.MessageDeliveryEnvelope.other-fields.extensions) are
   mapped as follows.

     If set to
     then add the extended RFC 822 field "Conversion-With-Loss:".

        Mapped to the extended RFC 822 field

        Mapped to the extended RFC 822 field


        These elements are only appropriate for physical delivery.
        They are represented as comments in the "X400-Recipients:"
        field, as described in Section

ToP   noToC   RFC1327 - Page 80
        These elements imply use of security services not available
        in the RFC 822 environment.  If they are marked as critical
        for transfer or delivery, then the message shall be
        rejected.  Otherwise they are discarded.

        This is described in Section 4.6.2.

        Each element is mapped to the extended RFC 822 field
        "DL-Expansion-History:".  They shall be ordered in the
        message header, so that the most recent expansion comes
        first (same order as trace).

   If any MTS (or MTA) Extensions not specified in X.400 are present,
   and they are marked as critical for transfer or delivery, then the
   message shall be rejected.  If they are not so marked, they can
   safely be discarded.  The list of discarded fields shall be indicated
   in the extended header "Discarded-X400-MTS-Extensions:".

5.3.7.  Mappings from the MTA Abstract Service

   There are some mappings at the MTA Abstract Service level which are
   done for IPM and IPN.  These can be derived from
   MTA.MessageTransferEnvelope.  The reasons for the mappings at this
   level, and the violation of layering are:

   -    Allowing for multiple recipients to share a single RFC 822

   -    Making the X.400 trace information available on the RFC 822

   -    Making any information on deferred delivery available

   The 822-MTS recipients are calculated from the full list of X.400
   recipients.  This is all of the members of
   MTA.MessageTransferEnvelope.per-recipient-fields being passed through
   the gateway, where the responsibility bit is set.  In some cases, a
   different RFC 822 message would be calculated for each recipient, due
   to differing service requests for each recipient.  As discussed in
   4.6.2..2, this specification allows either for multiple messages to
   be generated, or for the per- recipient information to be discarded.

   The following EBNF is defined for extended RFC 822 headers:

        mta-field       = "X400-Received" ":" x400-trace
                        / "Deferred-Delivery" ":" date-time
ToP   noToC   RFC1327 - Page 81
                        / "Latest-Delivery-Time" ":" date-time

        x400-trace       = "by" md-and-mta ";"
                         [ "deferred until" date-time ";" ]
                         [ "converted" "(" encoded-info ")" ";" ]
                         [ "attempted" md-or-mta ";"  ]
                            ";" arrival-time

        md-and-mta       = [ "mta" mta "in" ]  global-id
        mta              = word
        arrival-time     = date-time

        md-or-mta        = "MD" global-id
                         / "MTA" mta

        Action-list      = 1#action
        action           = "Redirected"
                         / "Expanded"
                         / "Relayed"
                         / "Rerouted"

   Note the EBNF.mta is encoded as 822.word.  If the character set does
   no allow encoding as 822.atom, the 822.quoted-string encoding is

   If MTA.PerMessageTransferFields.deferred-delivery-time is present, it
   is used to generate a Deferred-Delivery: field.  For some reason,
   X.400 does not make this information available at the MTS level on
   delivery.  X.400 profiles, and in particular the CEN/CENELEC profile
   for X.400(1984) [Systems85a], specify that this element must be
   supported at the first MTA.  If it is not, the function may
   optionally be implemented by the gateway: that is, the gateway may
   hold the message until the time specified in the protocol element.
   Thus, the value of this element will usually be in the past.  For
   this reason, the extended RFC 822 field is primarily for information.

   Merge MTA.PerMessageTransferFields.trace-information, and
   MTA.PerMessageTransferFields.internal-trace-information to produce a
   single ordered trace list.  If Internal trace from other management
   domains has not been stripped, this may require complex interleaving.
   Where an element of internal trace and external trace are identical,
   except for the MTA in the internal trace, only the internal trace
   element shall be presented. Use this to generate a sequence of
   "X400-Received:" fields. The only difference between external trace
   and internal trace will be the extra MTA information in internal
   trace elements.
ToP   noToC   RFC1327 - Page 82
   When generating an RFC 822 message all trace fields (X400-Received
   and Received) shall be at the beginning of the header, before any
   other fields.  Trace shall be in chronological order, with the most
   recent element at the front of the message.  This ordering is
   determined from the order of the fields, not from timestamps in the
   trace, as there is no guarantee of clock synchronisation.  A simple
   example trace (external) is:

   X400-Received: by /PRMD=UK.AC/ADMD=Gold 400/C=GB/ ; Relayed ;
           Tue, 20 Jun 89 19:25:11 +0100

   A more complex example (internal):

   X400-Received: by mta "UK.AC.UCL.CS"
         in  /PRMD=UK.AC/ADMD=Gold 400/C=GB/ ;
         deferred until  Tue, 20 Jun 89 14:24:22 +0100 ;
         converted (undefined, g3fax) ";" attempted /ADMD=Foo/C=GB/ ;
         Relayed, Expanded, Redirected ; Tue, 20 Jun 89 19:25:11 +0100

5.3.8.  Mappings from Report Delivery

   Delivery reports are mapped at the MTS service level.  This means
   that only reports destined for the MTS user will be mapped.  Some
   additional services are also taken from the MTA service.  MTS Mappings

   A Delivery Report service will be represented as
   MTS.ReportDeliveryEnvelope, which comprises of per-report-fields
   (MTS.PerReportDeliveryFields) and per-recipient-fields.

   A message is generated with the following fields:

        An administrator at the gateway system.  This is also the
        822-MTS originator.

   To:  A mapping of the  This is
        also the 822-MTS recipient.

        Set to "Delivery Report".

        The EBNF for the subject line is:
ToP   noToC   RFC1327 - Page 83
         subject-line  = "Delivery-Report" "(" status ")"
                         [ "for" destination ]

         status        = "success" / "failure" / "success and failures"

         destination   = mailbox / "MTA" word

   The format of the body of the message is defined to ensure that all
   information is conveyed to the RFC 822 user in a consistent manner.
   The format is structured as if it was a message coming from X.400,
   with the description in one body part, and a forwarded message
   (return of content) in the second.  This structure is useful to the
   RFC 822 recipient, as it enables the original message to be
   extracted.  The first body part is structured as follows:

1.   A few lines giving keywords to indicate the original

2.   A human summary of the status of each recipient being
     reported on.

3.   A clearly marked section which contains detailed information
     extracted from the report.  This is marked clearly, as it
     will not be comprehensible to the average user.  It is
     retained, as it may be critical to diagnosing an obscure

     This section may be omitted in positive DRs, and it is
     recommended that this is appropriate for most gateways.

        dr-body-format = dr-summary <CRLF>
                        dr-recipients <CRLF>
                        dr-administrator-info-envelope <CRLF>

        dr-content-return = "The Original Message is not available"
             / "The Original Message follows:"

        dr-summary = "This report relates to your message:" <CRLF>
                        content-correlator <CRLF> <CRLF>
                     "of" date-time <CRLF> <CRLF>

        dr-recipients = *(dr-recipient <CRLF> <CRLF>)

        dr-recipient = dr-recip-success / dr-recip-failure
ToP   noToC   RFC1327 - Page 84
        dr-recip-success =
                        "Your message was successfully delivered to:"
                         mailbox "at" date-time

        dr-recip-failure = "Your message was not delivered to:"
                                mailbox <CRLF>
                        "for the following reason:" *word

        dr-administrator-info-envelope = 3*( "*" text <CRLF> )

        dr-administrator-info =
         "**** The following information is directed towards"
         "the local administrator" <CRLF>
         "**** and is not intended for the end user" <CRLF> <CRLF>
         "DR generated by:" report-point <CRLF>
         "at" date-time <CRLF> <CRLF>
         "Converted to RFC 822 at" mta <CRLF>
         "at" date-time <CRLF> <CRLF>
         "Delivery Report Contents:" <CRLF> <CRLF>
         drc-field-list <CRLF>
         "***** End of administration information"

        drc-field-list       = *(drc-field <CRLF>)

        drc-field = "Subject-Submision-Identifier" ":"
                  / "Content-Identifier" ":" printablestring
                  / "Content-Type" ":" mts-content-type
                  / "Original-Encoded-Information-Types" ":"
                  / "Originator-and-DL-Expansion-History" ":"
                  / "Reporting-DL-Name" ":" mailbox
                  / "Content-Correlator" ":" content-correlator
                  / "Recipient-Info" ":" recipient-info
                  / "Subject-Intermediate-Trace-Information" ":"

        recipient-info  = mailbox "," std-or ";"
                    [ "converted eits" encoded-info ";" ]
                    [ "originally intended recipient"
                            mailbox "," std-or ";" ]
                    [ "last trace" [ encoded-info ] date-time ";" ]
ToP   noToC   RFC1327 - Page 85
                    [ "supplementary info" <"> printablestring <"> ";" ]
                    [ "redirection history" 1#redirection ";"
                    [ "physical forwarding address"
                                          printablestring ";" ]

        report-type     = "SUCCESS" drc-success
                        / "FAILURE" drc-failure

        drc-success     = "delivered at" date-time ";"
                        [ "type of MTS user" labelled-integer ";" ]

        drc-failure     = "reason" labelled-integer ";"
                        [ "diagnostic" labelled-integer ";" ]

        report-point = [ "mta" word "in" ] global-id
        content-correlator = *word
        dl-history = 1#( mailbox "(" date-time ")")

   The format is defined as a fixed definition of an the outer level
   (EBNF.dr-body-format).  The element EBNF.dr-administrator-info-
   envelope, provides a means of encapsulating a section of the header
   in a manner which is clear to the end user.  Each line of this
   section begins with "*".  Each element of EBNF.text within %EBNF.dr-
   administrator-info-envelope must not contain <CRLF>.  This is used to
   wrap up EBNF.dr-administrator-info, which will generate a sequenece
   of lines not starting with "*".  EBNF.drc-fields may be folded using
   the RFC 822 folding rules.

   The elements of MTS.ReportDeliveryEnvelope.per-report-fields are
   mapped as follows onto extended RFC 822 fields:

        Mapped to EBNF.drc-field (Subject-Submission-Identifier)

        Mapped to EBNF.drc-field (Content-Identifier).  This should
        also be used in EBNF.dr-summary if there is no Content
        Correlator present.

        Mapped to EBNF.drc-field (Content-Type)

        Mapped to EBNF.drc-field (Encoded-Info)
ToP   noToC   RFC1327 - Page 86
   The extensions from MTS.ReportDeliveryEnvelope.per-report-
   fields.extensions are mapped as follows:

        Mapped to EBNF.drc-field (Originator-and-DL-Expansion-

        Mapped to EBNF.drc-field (Reporting-DL-Name)

        Mapped to EBNF.content-correlator, provided that the
        encoding is IA5String (this will always be the case).  This
        is used in EBNF.dr-summary and EBNF.drc-field-list.  In the
        former, LWSP may be added, in order to improve the layout of
        the message.

   message-security-label reporting-MTA-certificate report-origin-

        These security parameters will not be present unless there
        is an error in a remote MTA.  If they are present, they
        shall be discarded in preference to discarding the whole

   For each element of MTS.ReportDeliveryEnvelope.per-recipient-fields,
   a value of EBNF.dr-recipient, and an EBNF.drc-field (Recipient-Info)
   is generated.  The components are mapped as follows.

        Used to generate the first EBNF.mailbox and EBNF.std-or in
        EBNF.recipient-info.  Both RFC 822 and X.400 forms are
        given, as there may be a problem in the mapping tables.  It
        also generates the EBNF.mailbox in EBNF.dr-recip-success or

        If it is, then set EBNF.dr-recipient to
        EBNF.dr-recip-success, and similarly set,
        filling in EBNF.drc-success.  If it is a failure, set
        EBNF.dr-recipient to EBNF.dr-recip-failure, making a human
        interpretation of the reason and diagnostic codes, and
        including any supplementary information.  EBNF.drc-failure
        is filled in systematically.

        Set EBNF.drc-field ("converted eits")
ToP   noToC   RFC1327 - Page 87
        Set the second ("originally intended recipient") mailbox and
        std-or in EBNF.drc-field.

        Set EBNF.drc-field ("supplementary info"), and include this
        information in EBNF.dr-recip-failure.

        Set EBNF.drc-field ("redirection history")

        Set ENBF.drc-field ("physical forwarding address")



   Any unknown extensions shall be discarded, irrespective of

   The original message, or an extract from it, shall be included in the
   delivery port if it is available.  The original message will usually
   be available at the gateway, as discussed in Section 5.2.  If the
   original message is available, but of erroneous format, a dump of the
   ASN.1 may be included.  This is recommended, but not required.  MTA Mappings

   The single 822-MTS recipient is constructed from, using the
   mappings of Chapter 4.  Unlike with a user message, this information
   is not available at the MTS level.

   The following additional mappings are made:
        This is used to generate the To: field.

        Mapped to the extended RFC 822 field "X400-MTS-Identifier:".
        It may also be used to derive a "Message-Id:" field.

ToP   noToC   RFC1327 - Page 88
        Mapped onto the extended RFC 822 field "X400-Received:", as
        described in Section 5.3.7.  The first element is also used
        to generate the "Date:" field, and the

        Mapped to EBNF.recipient-info (last trace)

        information Mapped to EBNF.drc-field (Subject-Intermediate-
        Trace-Information). These fields are ordered so that the
        most recent trace element comes first.  Example Delivery Reports

   Example Delivery Report 1:

   Return-Path: <>
   Received: from by
      via Delivery Reports Channel id <>;
      Thu, 7 Feb 1991 15:48:39 +0000
   From: UCL-CS MTA <>
   Subject: Delivery Report (failure) for
   Message-Type: Delivery Report
   Date: Thu, 7 Feb 1991 15:48:39 +0000
   Message-ID: <"bells.cs.u.694:">
   Content-Identifier: Greetings.

   ------------------------------ Start of body part 1

   This report relates to your message: Greetings.
           of Thu, 7 Feb 1991 15:48:20 +0000

   Your message was not delivered to
  for the following reason:
           Bad Address
           MTA '' gives error message  (USER) Unknown user
           name in ""

***** The following information is directed towards the local
***** administrator and is not intended for the end user
* DR generated by mta
*         in / 400/C=gb/
*         at Thu, 7 Feb 1991 15:48:34 +0000
ToP   noToC   RFC1327 - Page 89
* Converted to RFC 822 at
*         at Thu, 7 Feb 1991 15:48:40 +0000
 ..... continued on next page

* Delivery Report Contents:
* Subject-Submission-Identifier:
*      [/ 400/C=gb/;<1803.665941698@UK.AC.UCL.CS>]
* Content-Identifier: Greetings.
* Subject-Intermediate-Trace-Information:
           / 400/C=gb/;
*          arrival Thu, 7 Feb 1991 15:48:20 +0000 action Relayed

* Subject-Intermediate-Trace-Information:
           / 400/C=gb/;
*          arrival Thu, 7 Feb 1991 15:48:18 +0000 action Relayed
* Recipient-Info:,
*  /RFC-822=H.Hildegard(a)
          / 400/C=gb/;
*         FAILURE reason Unable-To-Transfer (1);
*         diagnostic Unrecognised-ORName (0);
*         last trace (ia5) Thu, 7 Feb 1991 15:48:18 +0000;
*         supplementary info "MTA '' gives error message  (USER)
*         Unknown user name in """;
****** End of administration information

The Original Message follows:

------------------------------ Start of forwarded message 1

Received: from by
  with SMTP inbound id <>;
  Thu, 7 Feb 1991 15:48:21 +0000
Subject: Greetings.
Phone: +44-71-380-7294
Date: Thu, 07 Feb 91 15:48:18 +0000
Message-ID: <1803.665941698@UK.AC.UCL.CS>
From: Steve Kille <>


------------------------------ End of forwarded message 1
Example Delivery Report 2:
ToP   noToC   RFC1327 - Page 90
Return-Path: <>
Received: from by
  via Delivery Reports Channel id <>;
  Thu, 7 Feb 1991 15:49:11 +0000
X400-Received: by mta in
  / 400/C=gb/;
  Relayed; Thu, 7 Feb 1991 15:49:08 +0000
X400-Received: by /PRMD=DGC/ADMD=GOLD 400/C=GB/; Relayed;
  Thu, 7 Feb 1991 15:48:40 +0000
From: UCL-CS MTA <>
Subject: Delivery Report (failure) for
Message-Type: Delivery Report
Date: Thu, 7 Feb 1991 15:49:11 +0000
Message-ID: <"DLE/910207154840Z/000">
Content-Identifier: A useful mess...

This report relates to your message: A useful mess...
Your message was not delivered to
        for the following reason:
        Bad Address
        DG 21187: (CEO POA) Unknown addressee.

***** The following information is directed towards the local
***** administrator and is not intended for the end user
* DR generated by /PRMD=DGC/ADMD=GOLD 400/C=GB/
*         at Thu, 7 Feb 1991 15:48:40 +0000
* Converted to RFC 822 at
*         at Thu, 7 Feb 1991 15:49:12 +0000
* Delivery Report Contents:
* Subject-Submission-Identifier:
*  [/ 400/C=gb/;<1796.665941626@UK.AC.UCL.CS>]
* Content-Identifier: A useful mess...
* Recipient-Info:,
*     /I=j/S=nosuchuser/OU=dle/O=cambridge/PRMD=DGC/ADMD=GOLD 400/C=GB/;
*     FAILURE reason Unable-To-Transfer (1);
*     diagnostic Unrecognised-ORName (0);
*     supplementary info "DG 21187: (CEO POA) Unknown addressee.";
****** End of administration information

The Original Message is not available
ToP   noToC   RFC1327 - Page 91
5.3.9.  Probe

   This is an MTS internal issue.  Any probe shall be serviced by the
   gateway, as there is no equivalent RFC 822 functionality.  The value
   of the reply is dependent on whether the gateway could service an MTS
   Message with the values specified in the probe.  The reply shall make
   use of MTS.SupplementaryInformation to indicate that the probe was
   serviced by the gateway.

(page 91 continued on part 4)

Next Section