4.4.  Repeated Mappings

   There are two types of repeated mapping:

   1.   A recursive mapping, where the repeat is within one gateway

   2    A source route, where the repetition occurs across multiple
        gateways

4.4.1.  Recursive Mappings

   It is possible to supply an address which is recursive at a single
   gateway.  For example:

              C          = "XX"
              ADMD       = "YY"
              O          = "ZZ"
              "RFC-822"  = "Smith(a)ZZ.YY.XX"

   This is mapped first to an RFC 822 address, and then back to the
   X.400 address:

              C          = "XX"
              ADMD       = "YY"
              O          = "ZZ"
              Surname    = "Smith"

   In some situations this type of recursion may be frequent.  It is
   important where this occurs, that no unnecessary protocol conversion
   occurs. This will minimise loss of service.

4.4.2.  Source Routes

   The mappings defined are symmetrical and reversible across a single
   gateway.  The symmetry is particularly useful in cases of (mail
   exploder type) distribution list expansion.  For example, an X.400
   user sends to a list on an RFC 822 system which he belongs to.  The
   received message will have the originator and any 3rd party X.400 OR
   Addresses in correct format (rather than doubly encoded).  In cases
   (X.400 or RFC 822) where there is common agreement on gateway
   identification, then this will apply to multiple gateways.

   When a message traverses multiple gateways, the mapping will always
   be reversible, in that a reply can be generated which will correctly
   reverse the path.  In many cases, the mapping will also be
   symmetrical, which will appear clean to the end user.  For example,
   if countries "AB" and "XY" have RFC 822 networks, but are
   interconnected by X.400, the following may happen:  The originator
   specifies:

          Joe.Soap@Widget.PTT.XY

   This is routed to a gateway, which generates:

              C               = "XY"
              ADMD            = "PTT"
              PRMD            = "Griddle MHS Providers"
              Organization    = "Widget Corporation"
              Surname         = "Soap"
              Given Name      = "Joe"

   This is then routed to another gateway where the mapping is reversed
   to give:

          Joe.Soap@Widget.PTT.XY

   Here, use of the gateway is transparent.

   Mappings will only be symmetrical where mapping equivalences are
   defined. In other cases, the reversibility is more important, due to
   the (far too frequent) cases where RFC 822 and X.400 services are
   partitioned.

   The syntax may be used to source route.  THIS IS STRONGLY
   DISCOURAGED.  For example:

      X.400 -> RFC 822  -> X.400

      C             = "UK"
      ADMD          = "Gold 400"
      PRMD          = "UK.AC"
      "RFC-822"     = "/PN=Duval/DD.Title=Manager/(a)Inria.ATLAS.FR"

   This will be sent to an arbitrary UK Academic Community gateway by
   X.400.  Then it will be sent by JNT Mail to another gateway
   determined by the domain Inria.ATLAS.FR (FR.ATLAS.Inria).  This will
   then derive the X.400 OR Address:

      C             = "FR"
      ADMD          = "ATLAS"
      PRMD          = "Inria"
      PN.S          = "Duval"
      "Title"       = "Manager"

   Similarly:

   RFC 822 -> X.400 -> RFC 822

   "/RFC-822=jj(a)seismo.css.gov/PRMD=AC/ADMD=BT/C=GB/"@monet.berkeley.edu

   This will be sent to monet.berkeley.edu by RFC 822, then to the
   AC PRMD by X.400, and then to jj@seismo.css.gov by RFC 822.

4.5.  Directory Names

   Directory Names are an optional part of OR Name, along with OR
   Address.  The RFC 822 addresses are mapped onto the OR Address
   component. As there is no functional mapping for the Directory Name
   on the RFC 822 side, a textual mapping is used.  There is no
   requirement for reversibility in terms of the goals of this
   specification.  There may be some loss of functionality in terms of
   third party recipients where only a directory name is given, but this
   seems preferable to the significant extra complexity of adding a full
   mapping for Directory Names.

   The Directory Name shall be represented within an RFC 822 comment
   using the comaptible formats of RFC 1484 or RFC 1485.  It is
   recommended that the directory string format of RFC 1485 is used
   [24].  The User Friendly Name form of RFC 1484 may be used [25].

4.6.  MTS Mappings

   The basic mappings at the MTS level are:

      1) SMTP originator ->
                    MTS.PerMessageSubmissionFields.originator-name
         MTS.OtherMessageDeliveryFields.originator-name ->
                    SMTP originator

      2) SMTP recipient ->
                    MTS.PerRecipientMessageSubmissionFields
         MTS.OtherMessageDeliveryFields.this-recipient-name ->
                    SMTP recipient

   SMTP recipients and return addresses are encoded as EBNF.822-address.

   The MTS Originator is always encoded as MTS.OriginatorName, which
   maps onto MTS.ORAddressAndOptionalDirectoryName, which in turn maps
   onto MTS.ORName.

4.6.1.  RFC 822 -> X.400 MTS Mappings

   From the SMTP Originator, use the basic ORAddress mapping, to
   generate MTS.PerMessageSubmissionFields.originator-name (MTS.ORName),
   without a DirectoryName.

   For recipients, the following settings are made for each component of
   MTS.PerRecipientMessageSubmissionFields.

   recipient-name
      This is derived from the SMTP recipient by the basic ORAddress
      mapping.

   originator-report-request
      This may either be set to "delivery-report", or set according to
      SMTP extensions as set out in Appendix A.

   explicit-conversion
      This optional component is omitted, as this service is not needed

   extensions
      The default value (no extensions) is used

4.6.2.  X.400 -> RFC 822 MTS Mappings

   The basic functionality is to generate the SMTP originator and
   recipients.  There is information present on the X.400 side, which
   cannot be mapped into analogous SMTP services.  For this reason, new
   RFC 822 fields are added for the MTS Originator and Recipients.  The
   information discarded at the SMTP level will be present in these
   fields. In some cases a (positive) delivery report will be generated.

4.6.2.1.  SMTP Mappings

   Use the basic ORAddress mapping, to generate the SMTP originator
   (return address) from MTS.OtherMessageDeliveryFields.originator-name
   (MTS.ORName).  If MTS.ORName.directory-name is present, it is
   discarded.  (Note that it will be presented to the user, as described
   in 4.6.2.2).

   The mapping  uses the MTA level information, and maps each value of
   MTA.PerRecipientMessageTransferFields.recipient-name, where the
   responsibility bit is set, onto an SMTP recipient.

      Note:The SMTP recipient is conceptually generated from
      MTS.OtherMessageDeliveryFields.this-recipient-name.  This is done
      by taking MTS.OtherMessageDeliveryFields.this-recipient-name, and
      generating an SMTP recipient according to the basic ORAddress

      mapping, discarding MTS.ORName.directory-name if present.
      However, if this model was followed exactly, there would be no
      possibility to have multiple SMTP recipients on a single message.
      This is unacceptable, and so layering is violated.

4.6.2.2.  Generation of RFC 822 Headers

   Not all per-recipient information can be passed at the SMTP level.
   For this reason, two new RFC 822 headers are created, in order to
   carry this information to the RFC 822 recipient.  These fields are
   "X400-Originator:"  and "X400-Recipients:".

   The "X400-Originator:" field is set to the same value as the SMTP
   originator.  In addition, if
   MTS.OtherMessageDeliveryFields.originator-name (MTS.ORName) contains
   MTS.ORName.directory-name then this Directory Name shall be
   represented in an 822.comment.

   Recipient names, taken from each value of
   MTS.OtherMessageDeliveryFields.this-recipient-name and
   MTS.OtherMessageDeliveryFields.other-recipient-names are made
   available to the RFC 822 user by use of the "X400-Recipients:" field.
   By taking the recipients at the MTS level, disclosure of recipients
   will be dealt with correctly.  However, this conflicts with a desire
   to optimise mail transfer.  There is no problem when disclosure of
   recipients is allowed. Similarly, there is no problem if there is
   only one RFC 822 recipient, as the "X400-Recipients" field is only
   given one address.

   There is a problem if there are multiple RFC 822 recipients, and
   disclosure of recipients is prohibited.  In this case, discard the
   per-recipient information.

   If any MTS.ORName.directory-name is present, it shall be represented
   in an 822.comment.

   If MTS.OtherMessageDeliveryFields.orignally-intended-recipient-name
   is present, then there has been redirection,  or there has been
   distribution list expansion.  Distribution list expansion is a per-
   message option, and the information associated with this is
   represented by the "DL-Expansion-History:" field described in Section
   5.3.6.  Other information is represented in an 822.comment associated
   with MTS.OtherMessageDeliveryFields.this-recipient-name, The message
   may be delivered to different RFC 822 recipients, and so several
   addresses in the "X400-Recipients:" field may have such comments.
   The non-commented recipient is the RFC 822 recipient. The EBNF of the
   comment is defined by redirect-comment.

         redirect-comment  = redirect-first *( redirect-subsequent )

         redirect-first = "Originally To:"  mailbox  "Redirected on"
            date-time "To:"  redirection-reason

         redirect-subsequent = mailbox  "Redirected Again on"
            date-time "To:"  redirection-reason

         redirection-history-item = "intended recipient" mailbox
            "redirected to"  redirection-reason
            "on" date-time

         redirection-reason =
            "Recipient Assigned Alternate Recipient"
            / "Originator Requested Alternate Recipient"
            / "Recipient MD Assigned Alternate Recipient"
            / "Directory Look Up"
            / "Alias"

   It is derived from
   MTA.PerRecipientMessageTransferFields.extension.redirection-history.
   The values are taken from the X.400(92) Implementor's guide (Version
   13, July 1995).   The first three values are in X.400(88).   The
   fourth value is in X.400(92), but has the name "recipient-directory-
   substitution-alternate-recipient". An example of this with two
   redirects is:

   X400-Recipients: postmaster@widget.com (Originally To:
             sales-manager@sales.widget.com
         Redirected on Thu, 30 May 91 14:39:40 +0100
             To: Originator Requested Alternate Recipient
             postmaster@sales.widget.com
         Redirected Again on Thu, 30 May 91 14:41:20 +0100
             To: Recipient MD Assigned Alternate Recipient)

   In addition the following per-recipient services from
   MTS.OtherMessageDeliveryFields.extensions are represented in comments
   if they are used.  None of these services can be provided on RFC 822
   networks, and so in general these will be informative strings
   associated with other MTS recipients. In some cases, string values
   are defined.  For the remainder, the string value shall be chosen by
   the implementor.   If the parameter has a default value, then no
   comment shall be inserted when the parameter has that default value.

   requested-delivery-method

   physical-forwarding-prohibited
        "(Physical Forwarding Prohibited)".

   physical-forwarding-address-request
        "(Physical Forwarding Address Requested)".

   physical-delivery-modes

   registered-mail-type

   recipient-number-for-advice

   physical-rendition-attributes

   physical-delivery-report-request
       "(Physical Delivery Report Requested)".

   proof-of-delivery-request
       "(Proof of Delivery Requested)".

4.6.2.3.  Delivery Report Generation

   If SMTP is used, the behaviour is specified in Appendix A.  In other
   cases, if MTA.PerRecipientMessageTransferFields.per-recipient-
   indicators requires a positive delivery notification, this shall be
   generated by the gateway.  Supplementary Information shall be set to
   indicate that the report is gateway generated.  This information
   shall include the name of the gateway generating the report.

4.6.3.  Message IDs (MTS)

   A mapping from 822.msg-id to MTS.MTSIdentifier is defined.  The
   reverse mapping is not needed, as MTS.MTSIdentifier is always mapped
   onto new RFC 822 fields.  The value of MTS.MTSIdentifier.local-part
   will facilitate correlation of gateway errors.

   To map from 822.msg-id, apply the standard mapping to 822.msg-id, in
   order to generate an MTS.ORAddress.  The Country, ADMD, and PRMD
   components of this are used to generate MTS.MTSIdentifier.global-
   domain-identifier.  MTS.MTSIdentifier.local-identifier is set to the
   822.msg-id, including the braces "<" and ">".   If this string is
   longer than MTS.ub-local-id-length (32), then it is truncated to this
   length.

   The reverse mapping is not used in this specification.  It would be
   applicable where MTS.MTSIdentifier.local-identifier is of syntax
   822.msg-id, and it algorithmically identifies MTS.MTSIdentifier.

4.7.  IPMS Mappings

   All RFC 822 addresses are assumed to use the 822.mailbox syntax.
   This includes all 822.comments associated with the lexical tokens of
   the 822.mailbox.  In the IPMS OR Names are encoded as MTS.ORName.
   This is used within the  IPMS.ORDescriptor, IPMS.RecipientSpecifier,
   and IPMS.IPMIdentifier.  An asymmetrical mapping is defined between
   these components.

4.7.1.  RFC 822 -> X.400

   To derive IPMS.ORDescriptor from an RFC 822 address.

   1.   Take the address, and extract an EBNF.822-address.  Any
        source routing shall be removed.  This can be derived trivially
        from either the 822.addr-spec or 822.route-addr syntax.  This is
        mapped to MTS.ORName as described above, and used as
        IMPS.ORDescriptor.formal-name.

   2.   A string shall be built consisting of (if present):

   -         The 822.phrase component if the 822.address is an
             822.phrase 822.route-addr construct.

   -         Any 822.comments, in order, retaining the parentheses.

         This string is then encoded into T.61 using a human oriented
         mapping (as described in Section 3.5).  If the string is not
         null, it is assigned to IPMS.ORDescriptor.free-form-name.

3.   IPMS.ORDescriptor.telephone-number is omitted.

   If IPMS.ORDescriptor is being used in IPMS.RecipientSpecifier,
   IPMS.RecipientSpecifier.reply-request and
   IPMS.RecipientSpecifier.notification-requests are set to default
   values (false and none).

   If the 822.group construct is present, any included 822.mailbox is
   encoded as above to generate a separate IPMS.ORDescriptor.  The
   822.group is  mapped to T.61 (as described in Section 3.5), and a
   IPMS.ORDescriptor with only an free-form-name component built from
   it.

4.7.2.  X.400 -> RFC 822

   Mapping from IPMS.ORDescriptor to RFC 822 address.  In the basic
   case, where IPMS.ORDescriptor.formal-name is present, proceed as
   follows.

   1.   Encode IPMS.ORDescriptor.formal-name (MTS.ORName) as
        EBNF.822-address.

   2a.  If IPMS.ORDescriptor.free-form-name is present, convert it
        to ASCII or T.61 (Section 3.5), and use this as the 822.phrase
        component of 822.mailbox using the 822.phrase 822.route-addr
        construct.

   2b.  If IPMS.ORDescriptor.free-form-name is absent.  If
        EBNF.822-address is parsed as 822.addr-spec use this as the
        encoding of 822.mailbox.  If EBNF.822-address is parsed as
        822.route 822.addr-spec, then an 822.phrase taken from
        822.local-part is added.

   3    If IPMS.ORDescriptor.telephone-number is present, this is
        placed in an 822.comment, with the string "Tel ".  The normal
        international form of number is used.  For example:

         (Tel +44-181-333-7777)

   4.   If IPMS.ORDescriptor.formal-name.directory-name is present,
        then a text representation is placed in a trailing 822.comment.

   5.   If IPMS.RecipientSpecifier.report-request has any non-
        default values, then an 822.comment "(Receipt Notification
        Requested)", and/or "(Non Receipt Notification Requested)",
        and/or "(IPM Return Requested)" may be appended to the address.
        "(Receipt Notification Requested)" may be used to infer "(Non
        Receipt Notification Requested)".  The effort of correlating P1
        and P2 information is too great to justify the gateway sending
        Receipt Notifications.

        In RFC 1327, inclusion of these comments was mandatory.
        Experience has shown that the clutter and confusion caused to
        RFC 822 users does not justify the information conveyed.
        Implementors are recommended to not include these comments.
        Unless an application is found where retention of these comments
        is desirable, they will be dropped from the next version.

   6.   If IPMS.RecipientSpecifier.reply-request is True, an
        822.comment "(Reply requested)"  is appended to the address.

   If IPMS.ORDescriptor.formal-name is absent, IPMS.ORDescriptor.free-
   form-name is converted to ASCII (see section 3.5), and used as
   822.phrase within the RFC 822 822.group syntax.  For example:

         Free Form Name ":" ";"

   Steps 3-6 are then followed.

4.7.3.  IP Message IDs

   There is a need to map both ways between 822.msg-id and
   IPMS.IPMIdentifier.  This allows for X.400 Receipt Notifications,
   Replies, and Cross References to reference an RFC 822 Message ID,
   which is preferable to a gateway generated ID.  A reversible and
   symmetrical mapping is defined.  This provides fully reversible
   mappings when messages pass multiple times across the X.400/RFC 822
   boundary.

   An important issue with messages identifiers is mapping to the exact
   form, as many systems use these ids as uninterpreted keys.  The use
   of table driven mappings is not always symmetrical, particularly in
   the light of alternative domain names, and alternative management
   domains.  For this reason, a purely algorithmic mapping is used.  A
   mapping which is simpler than that for addresses can be used for two
   reasons:

   -    There is no major requirement to make message IDs "natural"

   -    There is no issue about being able to reply to message IDs.
        (For addresses, creating a return path which works is more
        important than being symmetrical).

   The mapping works by defining a way in which message IDs generated on
   one side of the gateway can be represented on the other side in a
   systematic manner.  The mapping is defined so that the possibility of
   clashes is low enough to be treated as impossible.

4.7.3.1.  822.msg-id represented in X.400

   IPMS.IPMIdentifier.user is omitted.  The IPMS.IPMIdentifier.user-
   relative-identifier is set to a printable string encoding of the
   822.msg-id with the angle braces ("<" and ">") removed.  The upper
   bound on this component is 64.  The options for handling this are
   discussed in Section 5.1.3.

4.7.3.2.  IPMS.IPMIdentifier represented in RFC 822

   The 822.domain of 822.msg-id is set to the value "MHS". The
   822.local-part of 822.msg-id is constructed by building a string of
   syntax EBNF.id-loc from IPMS.IPMIdentifier.

          id-loc ::= [ printablestring ] "*"  [ std-or-address ]

   EBNF.printablestring is the IPMS.IPMIdentifier.user-relative-
   identifier, and EBNF.std-or-address being an encoding of the
   IPMS.IPMIdentifier.user derived according to this specification.
   822.local-part is derived from EBNF.id-loc, if necessary using the
   822.quoted-string encoding.  For example:

         <"147*/S=Dietrich/O=Siemens/ADMD=DBP/C=DE/"@MHS>

4.7.3.3.  822.msg-id -> IPMS.IPMIdentifier

   If the 822.local-part can be parsed as:

         [ printablestring ] "*"  [ std-or-address ]

   and the 822.domain is "MHS", then this ID was X.400 generated.  If
   EBNF.printablestring is present, the value is assigned to
   IPMS.IPMIdentifier.user-relative-identifier.  If EBNF.std-or-address
   is present, the OR Address components derived from it are used to set
   IPMS.IPMIdentifier.user.

   Otherwise, this is an RFC 822 generated ID.  In this case, set
   IPMS.IPMIdentifier.user-relative-identifier to a printable string
   encoding of the 822.msg-id without the angle braces and omit
   IPMS.IPMID.user.

4.7.3.4.  IPMS.IPMIdentifier -> 822.msg-id

   If IPMS.IPMIdentifier.user is absent, and IPMS.IPMIdentifier.user-
   relative-identifier mapped to ASCII and angle braces added parses as
   822.msg-id, then this is an RFC 822 generated ID.

   Otherwise, the ID is X.400 generated.  Use the
   IPMS.IPMIdentifier.user to generate an EBNF.std-or-address form
   string.  Build the 822.local-part of the 822.msg-id with the syntax:

         [ printablestring ] "*"  [ std-or-address ]

   The printablestring is taken from IPMS.IPMIdentifier.user-relative-
   identifier.  Use 822.quoted-string if necessary.  The 822.msg-id is
   generated with this 822.local-part, and "MHS" as the 822.domain.

4.7.3.5.  Phrase form

   In "In-Reply-To:" and "References:", the encoding 822.phrase may be
   used as an alternative to 822.msg-id.  To map from 822.phrase to
   IPMS.IPMIdentifier, assign IPMS.IPMIdentifier.user-relative-
   identifier to the phrase.  When mapping from IPMS.IPMIdentifier for
   "In-Reply-To:" and "References:", if IPMS.IPMIdentifier.user is

   absent and IPMS.IPMIdentifier.user-relative-identifier does not parse
   as 822.msg-id, generate an 822.phrase rather than adding the domain
   MHS.

4.7.3.6.  RFC 987 backwards compatibility

   The mapping defined here is different to that used in RFC 987, as the
   RFC 987 mapping lead to changed message IDs in many cases.  Fixing
   the problems is preferable to retaining backwards compatibility.  An
   implementation of this standard may recognise message IDs generated
   by RFC 987.  This is not recommended.

   RFC 987 generated encodings may be recognised as follows.  When
   mapping from X.400 to RFC 822, if the IPMS.IPMIdentifier.user-
   relative-identifier is "RFC-822" the id is RFC 987 generated. When
   mapping from RFC 822 to X.400, if the 822.domain is not "MHS", and
   the 822.local-part can be parsed as

         [ printablestring ] "*"  [ std-or-address ]

   then it is RFC 987 generated.  In each of these cases, it is
   recommended to follow the RFC 987 rules.

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: Detailed Mappings

   The mapping of RFC 822/MIME messages to X.400 InterPersonal Messages
   is described in Sections 5.1.1 to 5.1.7.   Mapping of NOTARY format
   delivery status notifications, which are all messages of type
   multipart/report and subtype delivery-status-notifications to X.400
   delivery reports is covered in Section 5.1.8.

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.

   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


   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"). All 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 is generated from the RFC 822 message
   body in the manner described in Section 5.1.5.

   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
   generated.

   When generating the IPM, the issue of upper bounds are handled as
   follows. 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.  This approach will cause
   more problems for some fields than others (e.g., truncating an OR
   Address component that would be used to route a reply would be a more
   severe problem than truncating a Free Form Name).  If the Free Form
   name is truncated, it shall be done so that it does not break RFC 822
   comments and RFC 1522 encoding.

   Note:This approach removes a choice of options given in RFC 1327,
        based on operational experience.

   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:

   Date:
        Ignore (Handled at MTS level)

   Received:
        Ignore (Handled at MTA level)

   Message-Id:
        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.

   From:
        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.

   Sender:
        Mapped to IPMS.Heading.originator.  Because X.400 does not have
        the same From/Sender distinction as RFC 822, this mapping is not
        always natural and may lead to unexpected results in some cases.

   Reply-To:
        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 shall either be mapped to a zero length sequence or
        mapped to a single recipient that has a free from name "BCC" and
        no other addressing information.  This alternate treatment is
        allowed because some X.400 systems cannot handle a zero lenght
        sequence of addresses.

   In-Reply-To:
        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 multiple values, this cannot be done as the X.400
        heading is single valued. In this case no IPMS.Heading.replied-
        to-IPM is generated and the values are mapped to
        IPMS.Heading.related-IPMs, along with any values from a
        "References:" field.

   References:
        Mapped to IPMS.Heading.related-IPMs.

   Keywords:
        Mapped onto a heading extension.

   Subject:
        Mapped to IPMS.Heading.subject.  The field-body uses the human
        oriented mapping referenced in Section 3.3.4.

   Comments:
        Mapped onto a heading extension.

        This is a change from 1327, which specified 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: " and that this body part shall precede the
        other one. Experience has shown that this complexity is not
        justified.  This text is retained to facilitate backwards
        compatibility.

   Encrypted:
        Mapped onto a heading extension.

   Resent-*
        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.

   Content-Language:
        This field is defined in RFC 1766 [7].  Map the first two
        characters of each value given onto the IPM Languages extension.
        If any comments or values longer than two characters occur, a
        header extension shall also be generated.

   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).

   The mapping of the following headings is defined in RFC 2157.

   MIME-Version: 5
   Content-Transfer-Encoding:
   Content-Type
   Content-ID
   Content-Description

5.1.4.  Generating the IPM Body

   Generation of the IPM Body is defined in RFC 2157.

5.1.5.  Mappings to the MTS Abstract Service

   The MTS.MessageSubmissionEnvelope comprises
   MTS.PerMessageSubmissionFields, and
   MTS.PerRecipientMessageSubmissionFields.  The mandatory parameters
   are defaulted as follows.

   MTS.PerMessageSubmissionFields.originator-name
      This is always generated from SMTP, as defined in Chapter 4.

   MTS.PerMessageSubmissionFields.content-type
      Set to the value implied by the encoding of the IPM (2 or 22).

   MTS.PerRecipientMessageSubmissionFields.recipient-name
      These will always be supplied from SMTP, 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.

   If SMTP is used, Appendix A shall be followed in setting these
   parameters.

   The trace is set to indicate conversion (described below) and the
   encoded information types in the trace is derived from the message
   generated by the gateway, and shall reflect all body parts (including
   those in enclosed messages).  In addition it shall include the
   Encoded Information Type "eit-mixer", which is defined in Appendix D.
   The presence of the EIT will indicate to the X.400 recipient that a
   MIXER conversion has occurred.
   MTS.PerMessageSubmissionFields.original-encoded-information-types
   will include all of the values used in the trace, unless specified
   otherwise in RFC 2157.

   This type of conversion will prevent the normal loop detection from
   working in certain circumstances, and introduces the possiblity of
   gateway loops.  MIXER gateways shall therefore count the number of
   MIXER conversions made.  If this count exceeds five in one direction,
   the message shall be treated as if a loop has been detected.

   The MTS.PerMessageSubmissionFields.content-correlator is encoded as
   IA5String, and contains the Subject:, Message-ID:, Date:,  and To:
   fields (if present) in this order.  This includes the strings
   "Subject:", "Date:", "To:", "Message-ID:", and appropriate folding to
   make the field appear readable.  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 shall 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 X.400(1984).

5.1.6.  Mappings to the MTA Abstract Service

   There is a need to map directly onto some aspects of the MTA Abstract
   service, for the following reasons:

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

   -    So that the submission date can be generated from the
        822.Date.

   -    To prevent loss of trace information

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

   The following mappings are defined.

   Message-Id:
      If this is present and no Resent: fields are present, the
      MTA.PerMessageTransferFields.message-identifier may be generated
      from it, using the mappings described in Chapter 4.

      This mapping arguably generates messages which do not conform to
      US GOSIP (1984 version only), which states:

      6.7.e MPDU Identifier Validation

      (1) Validation of the GlobalDomainIdentifier component of the MPDU
      Identifier is performed on reception of a message (i.e. the result
      of a TRANSFER.Indication).

      (2) The country name should be known to the validating domain, and
      depending on the country name, validation of the

      ADMD name may also be possible.

      (3) Additional validation of the GlobalDomainIdentifier is
      performed against the corresponding first entry in the
      TraceInformation. If inconsistencies are found during the
      comparison, a non-delivery notice with the above defined reason
      and diagnostic code is generated.

      (4) A request will be generated to the CCITT for a more meaningful
      diagnostic code (such as "InconsistentMPUTIdentifier").

   This applies to ADMDs only, and is specified in the 1984 version and
   not the 1988 version. Conformance depends on the interpretation of
   "inconsistency".   The specification makes the most sensible choice,
   and so is not being changed in the update from RFC 1327.

   Date: (and Resent-Date:)
      If one or more Resent-Date: fields is present, the most recent
      Resent-Date: field shall be used instead of the Date: field in the
      following description.

      The Date: field is used to set the first component of
      MTA.PerMessageTransferFields.trace-information
      (MTA.TraceInformationElement).  The SMTP originator is mapped into
      an MTS.ORAddress, and used to derive
      MTA.TraceInformationElement.global-domain-identifier.  The
      optional components of MTA.TraceInformationElement.domain-
      supplied-information are omitted, and the mandatory components are
      set as follows:

      MTA.DomainSuppliedInformation.arrival-time
         This is set to the date derived from Date:

      MTA.DomainSuppliedInformation.routing-action
         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.

   Received:
      All RFC 822 trace is used to derive
      MTA.PerMessageTransferFields.trace-information and
      MTA.PerMessageTransferFields.internal-trace-information.
      Processing of Received: lines  follows processing of Date:, and is
      done from the bottom to the top of the RFC 822 header (i.e., in
      chronological order).  When other trace elements (in particular
      X400-Received:)  are processed the relative ordering (top to
      bottom of the header) shall be retained correctly.

      The initial element of MTA.PerMessageTransferFields.trace-
      information shall be generated from Date: as described above,
      unless the message has previously been in X.400, when it will be
      derived from the X.400 trace information.

      For each  Received: field, the following processing shall be done.
      If the "by"  part of the received is present and there is an
      available MCGAM which can map this domain, use it to derive an
      MTS.GlobalDomainIdentifier.  Otherwise MTS.GlobalDomainIdentifier
      is set from local information.  If this is different from the one
      in the last element of MTA.PerMessageTransferFields.trace-
      information (MTA.TraceInformationElement.global-domain-identifier)
      create a new MTA.TraceInformationElement, and optionally remove
      MTA.PerMessageTransferFields.internal-trace-information.
      Requirements on trace stripping are discussed below.

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

         MTA.MTASuppliedInformation.arrival-time
            Derived from the date of the Received: line

         MTA.MTASuppliedInformation.routing-action
            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 computer-science.nottingham.ac.uk by
            vs6.Cs.Ucl.AC.UK via Janet with NIFTP  id aa03794;
            28 Mar 89 16:38 GMT

   Generates the string

         vs6.Cs.Ucl.AC.UK

   The gateway shall add in a single element of trace information,
   reflecting the gateway's local information and the time of
   conversion.  The MTA.InternalTraceInformationElement.mta-supplied-
   information (MTA.MTASuppliedInformation) is set as follows:

   MTA.DomainSuppliedInformation.arrival-time
      Set to the time of conversion

   MTA.DomainSuppliedInformation.routing-action
      Set to relayed

   MTA.AdditionalAcctions.converted-encoded-information-types Set to
   correct set of EITs for the message that is generated by the gateway.
   This trace element will thus reflect gateway operation as a
   conversion.

   This trace generation will often lead to generation of substantial
   amounts of trace information, which does not reflect X.400 transfers.
   Stripping of some of this trace may be necessary in some operational
   environments.   This stripping shall be considered a function of the
   associated X.400 MTA, and not of the MIXER gateway.

5.1.7.  Mapping New Fields

   This specification defines a number of new fields for Reports,
   Notifications and IP Messages. A gateway conforming to this
   specification shall  map all of these fields to X.400, except as
   defined below.

   The mapping of two  extended fields is particularly important, in
   order to prevent looping.  "DL-Expansion-History:" is mapped to
   MTA.PerMessageTransferFields.extensions.dl-expansion-history X400-
   Received: shall 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 shall 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:.

   The following fields shall not be mapped, and shall be

   -    Discarded-X400-MTS-Extensions:

   -    Message-Type:

   -    Discarded-X400-IPMS-Extensions:

   -    X400-Content-Type:

   -    X400-Originator:

   -    X400-Recipients:

   -    X400-MTS-Identifier:  Mapping this field would be useful in
        some circumstances, but very dangerous in others (e.g.,
        following an internet list expansion).  Therefore it is not
        mapped.

5.1.8.  Mapping Delivery Status Notifications to X.400

5.1.8.1.  Basic Model

   Internet Mail delivery status notifications (DSN) are mapped to X.400
   delivery reports.   With message mapping, information without a
   mapping is carried by an IPM Extension.   This cannot be done for
   delivery reports.   Two mechanisms are used for information where
   there is not a direct mapping.

   The first mechanism is to define extensions, which allow all of the
   DSN information to be carried in the delivery report.  This is not
   completely satisfactory for two reasons:

   1.   User defined extensions are supported by the ISO version of
        the standard, but not the CCITT one.  Therefore,
        implementation support for these extensions will not be
        universal.

   2.   X.400 User Agent implementations will not in general
        recognise these extensions.   Therefore, although the
        information will be present, it will often not be available
        to the user.    This may be very problematic, as this
        information may be critical to diagnosing the reason for a
        failure.

   Therefore a second mechanism is defined.  This shall always be used
   when the DSN contains non-delivery information, and may be used in
   other cases.  This mechanism is to map the whole DSN (as if it were
   an ordinary multipart) into the return of content.  This will make
   the DSN information available as a text body part in the outer
   message, with the real returned content as an enclosed message.  This
   mechanism will ensure that information is not lost at the gateway.

5.1.8.2.  DSN Extensions

   Two X.400 MTS extensions are defined as follows:

   dsn-header-list EXTENSION
      RFC822FieldList
      ::= id-dsn-header-list

   dsn-field-list EXTENSION
      RFC822FieldList
      ::= id-dsn-field-list

   The Object Identifiers id-dsn-header-list and id-dsn-field-list are
   defined in Appendix D.  Theses extensions are used in the same way as
   the IPM extension rfc-822-field, described in Section 5.1.2.   These
   extensions may only be used with ISO-10021, and not X.400 (which does
   not allow user extensions at the MTS level).

5.1.8.3.  DSN to Delivery Report Mapping

   Some DSNs are mapped to Delivery Reports and some to IPMs, according
   to the value of the action field.   The mapping to an IPM is exactly
   as for a normal IPM mapping.   The choice of IPM and Delivery report
   is made for each reported recipient.   If this choice is different
   for different reported recipients both a Delivery Report and an IPM
   shall be generated.

   Reports are not be submitted in the X.400 model, and so the report
   submission is considered in terms of the MTA Abstract Service.  An
   MTA.Report is constructed. The MTA.ReportTransferEnvelope.report-
   identifier is generated from the Message-Id of the DSN (if present)
   and otherwise generated as the MTA would generate one for a submitted
   message.

   The DSN has an RFC 822 header.  Trace is mapped in the same manner as
   for a message to MTA.ReportTransferEnvelope.trace-information.  All
   other headers are used to create a dsn-header-list extension, which
   is added to MTA.PerReportTransferFields.extensions.  The DSN will
   have a single SMTP recipient.   This is mapped to the
   MTA.ReportTransferEnvelope.report-destination-name.

   The DSN is then treated as a normal MIME message, and an X.400 IPM is
   generated.   This IPM is used as
   MTA.PerReportTransferFields.returned-content, and its type is used to
   set MTA.PerReportTransferFields.content-type.  The DSN body part is
   mapped as if it was IA5 text/plain.

   The mandatory MTA.PerReportTransferFields.subject-identifier shall be
   generated from the DSN.per-message-field original-envelope-id, if
   this starts with the string "X400-MTS-Identifier: ", and derived from
   the rest of the field, which is encoded as EBNF.mts-msg-id.  In other
   cases, this field shall be generated by the MIXER Gateway.

   All other mappings are made from the DSN body part. A dsn-field-list
   extension is created and added to
   MTA.ReportTransferFields.extensions.  This is referred to as the per
   report extension list.  The DSN.per-message-fields are mapped as
   follows:

   original-envelope-id-field
   reporting-mta-field
   dsn-gateway-field
   received-from-mta-field
   arrival-date-field
   extension-field
   other

      All of these fields are added to the per report extension list.
      Currently there are no other mappings defined.

   Each reported recipient is considered in turn, and a
   MTA.PerRecipientReportTransferFields created for each.  The
   parameters of this are defaulted as follows:

   originally-specified-recipient-number
      In general, these are not available, and so are assigned
      incrementally.

   last-trace-information
      The arrival-time is generated from DSN.arrival-date if present,
      and if not from the Date: of the DSN.  This is a strucutred field,
      and the Report element contains the key information on the
      recipient.  For a DeliveryReport, the type-ofMTS-user is defaulted
      to public and the message-deliery-time is set to the same as the
      arrival-time.  For a NonDeliveryReport, the code mappings are
      define in Section 5.1.8.4.

   A dsn-field-list extension is created  and added to
   MTA.PerRecipientTransferFields.extensions.  This is referred to as
   the per recipient extension list.  The DSN.per-recipient-fields are
   mapped as follows

   original-recipient-field
      Mapped to MTA.PerRecipientReportTransferFields.originally-
      intended-recipient-name.

   final-recipient-field
      Mapped to MTA.PerRecipientReportTransferFields.actual-recipient-
      name.

   action-field
      If this is set to "failed", a non-delivery report is generated.
      If this is set to "delivered" a delivery report is generated.
      Bit one or two of MTA.PerRecipientTransferFields.per-recipient-
      indicators is set accordingly.  This also controls the encoding of
      MTA.PerRecipientTransferFields.last-trace-information, and the
      selection of the report type.

      For other values of the action-field ("delayed", "relayed",
      "expanded"), an IPM is generated.   This enables the status
      information to be communicated to the X.400 user, without the
      confusion of multiple delivery reports.

   status-field
      This is added to the per report extension list.  For non-delivery,
      it is also used to generate the reason and diagnostic codes
      contained within MTA.PerRecipientReportTransferFields.last-trace.
      The mappings are defined below.

   remote-mta-field

   diagnostic-code-field

   last-attempt-date-field

   will-retry-until-field

   extension-field

   other
      All of these fields are added to the per recipient extension list.

5.1.8.4.  Status Value Mappings

   Status values are mapped to X.400 reason and diagnostic codes as
   follows.

   If a status value is found that is not in this table, the gateway may
   use the same mapping as for "X.n.0" (1/None or 0/None), or it may map
   to another, configurable code.  Implementors are requested to forward
   new codes to the mixer list for inclusion in future versions of this
   standard.  So for instance. "5.2.37", currently undefined, would map
   onto the same as "5.2.0", namely 1/None.

DSN code  Meaning                               X400 code Meaning

X.0.0     Other status                          1/None

X.1.0     Other Address Status                  1/None
X.1.1     Bad mailbox address                   1/0     Unrecognized
X.1.2     Bad system address                    1/0     Unrecognized
X.1.3     Bad mailbox address syntax            1/0     Unrecognized
X.1.4     Mailbox address ambiguous             1/1
X.1.5     Only used for positive reports, not applicable
X.1.6     Destination mailbox has moved         1/43  New addr unknown
X.1.7     Bad sender's mailbox address syntax   1/11  Invalid arguments
X.1.8     Bad sender's system address           1/11  Invalid arguments

X.2.0     Other or undefined mailbox status     1/None
X.2.1     Mailbox disabled, not accepting       1/4   Recipient unavail
X.2.2     Mailbox full                          1/4
X.2.3     Message length exceeds admin limit.   1/7     Content too long
X.2.4     Mailing list expansion problem        1/30  DL expansion fail

X.3.0     Other or undefined system status      0/None
X.3.1     System full                           1/2     MTS congestion
X.3.2     System not accepting network messages 1/2     MTS congestion
X.3.3     System not capable of selected feat   1/18    Unsupp crit func
X.3.4     Message too big for system            1/7
X.3.5     System incorrectly configured      1/None

X.4.0     Other or undefined network or routing 0/None
X.4.1     No answer from host                   0/None
X.4.2     Bad connection                        0/None
X.4.3     Routing server failure                6/None  Dir op unsucc.
X.4.4.    Unable to route                       0/None
X.4.5     Network congestion                    1/2     MTS congest.
X.4.6     Routing loop detected                 1/3
X.4.7     Delivery time expired                 1/5

X.5.0     Other or undefined protocol status    1/None

X.5.1     Invalid command                       1/14    Protocol viol.
X.5.2     Syntax error                          1/14
X.5.3     Too many recipients                   1/16
X.5.4     Invalid command arguments             1/14
X.5.5     Wrong protocol version                1/18    Unsupp.crit.func

X.6.0     Other or undefined media error        2/None  Conv. not perf
X.6.1     Media not supported                   1/6     EIT unsupp.
X.6.2     Conversion required and prohibited    1/9
X.6.3     Conversion required but not supported 2/8
X.6.4     Conversion with loss performed        POSITIVE only
X.6.5     Conversion failed                  2/47   Unable to downgrade

X.7.0     Other or undefined security status    1/46
X.7.1     Delivery not authorized, message ref  1/29  No DL submit perm
X.7.2     Mailing list expansion prohibited     1/28
X.7.3     Security conversion req but not poss  1/46  Secure mess. error
X.7.4     Security features not supported       1/46
X.7.5     Cryptographic failure                 1/46
X.7.6     Cryptographic algorithm not supported 1/46
X.7.7     Message integrity failure             1/46

5.1.8.5.  DSNs that originated in X.400

   The mapping of X.400 delivery reports to DSNs will in general provide
   sufficient information to make a useful reverse mapping.  Messages
   will often be mapped multiple times, commonly due to forwarding
   messages and to distribution lists.   Multiple mappings for delivery
   reports will be a good deal less common.  For this reason, the
   reverse mapping of the X.400 DSN extensions defined in MIXER is
   optional.

5.2.  Return of Contents

   RFC 1327 offered two approaches for return of content, as this
   service is optional in X.400 and expected in RFC 822.   MIXER simply
   requires that a gateway requests the return of content service from
   X.400.

5.3.  X.400 -> RFC 822: Detailed Mappings

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
   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 SMTP recipients.