Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 2156

MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME

Pages: 144
Proposed Standard
Obsoletes:  098710261138114813271495
Updates:  0822
Part 4 of 5 – Pages 87 to 119
First   Prev   Next

Top   ToC   RFC2156 - Page 87   prevText
5.3.2.  RFC 822 Settings

   An RFC 822 Message has a number of mandatory fields in the RFC 822
   Header.  Some SMTP services mandate specification of an SMTP
   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:

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

      A value will always be generated

      If this is not generated by the mapping, it is assigned equal to
      the SMTP 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
Top   ToC   RFC2156 - Page 88
      built-in-eit    = "Undefined"         ; undefined (0)
                      / "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 = "Supersedes" ":" 1*msg-id
             / "Expires" ":" date-time
             / "Reply-By" ":" date-time
             / "Importance" ":" importance
             / "Sensitivity" ":" sensitivity
             / "Autoforwarded" ":" boolean
             / "Incomplete-Copy" ":"
             / "Content-Language" ":" 1#language
             / "Message-Type" ":" message-type
             / "Discarded-X400-IPMS-Extensions" ":" 1#object-identifier
             / "Autosubmitted" ":" autosubmitted

importance      = "low" / "normal" / "high"
Top   ToC   RFC2156 - Page 89
sensitivity     = "Personal" / "Private" /

language        = 2*ALPHA [ "(" language-description ")" ]
     language-description = printable-string

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

autosubmitted   = "not-auto-submitted"
                / "auto-generated"
                / "auto-replied"
                / "auto-forwarded"

   The mappings and actions for the IPMS.Heading are 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
   shall be discarded, except 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:".
Top   ToC   RFC2156 - Page 90
      Mapped to the extended RFC 822 field "Supersedes:".   The replaces
      the RFC 1327 field "Obsoletes:".   Reverse mapping of the RFC 1327
      field may be supported.

      Mapped to "References:".

      Mapped to "Subject:".  The contents are converted to ASCII or T.61
      (as defined in Section 3.5).  CRLF will not be present in a valid
      X.400 field.  Any CRLF present are not mapped, but are used as
      points at which the subject field shall be folded, unless an RFC
      1522 encoding is used.

      Mapped to the extended RFC 822 field "Expires:".  The replaces the
      RFC 1327 field "Expiry-Date:".   Reverse mapping of the RFC 1327
      field may be supported.

      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  RFC 822 field "Content-Language:", defined in RFC
      1766 [7].  This mapping may be made without loss of information.

      Map to the extended RFC 822 field "Autosubmitted:".
Top   ToC   RFC2156 - Page 91
   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-
   IPMS-Extensions:".  Mapping the IPMS Body

   The mapping of the IPMS Body is defined in RFC 2157.  Example Message

   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
X400-Content-Type: P2-1984 (2)
X400-Content-Identifier: Email Problems
From: (Tel +44 71 217 3487)
Message-ID: <PC1000-910530172027-57D8*@MHS>
To: Jim Craigie <>,
    Tony Bates <>,
    Steve Kille <>
Subject: Email Problems
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=boundary-1

Content-Type: text/plain; charset=US-ASCII

Hope you gentlemen.......
Top   ToC   RFC2156 - Page 92

Stephen Harrison
UK GOSIP Project

Content-Type: message/rfc822

From: Urs Eppenberger <>
To: "Stephen.Harrison" <>
Subject: Response to Email link
Content-Type: multipart/mixed; boundary=boundary-2


Dear Mr Harrison......



5.3.5.  Mappings from an IP Notification

   Because of the service setting, IP Notifications will not usually
   need to be mapped by a MIXER gateway.  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 shall be used.

      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
Top   ToC   RFC2156 - Page 93
      Used for any discarded IPN extensions.

   The following EBNF is defined for the body of the Message.  This
   format is defined to ensure that all information from an
   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:"

         preferred-recipient = mailbox
         receipt-time        = date-time
         auto-comment        = printablestring
         ipn-suppl           = printablestring
Top   ToC   RFC2156 - Page 94
         discard-reason     = "Expired" / "Obsoleted" /
                     "User Subscription Terminated" / "IPM Deleted"

         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 EBNF.ipn-auto-

      Mapped to EBNF.discard-reason

      Mapped to

      This applies only to non-receipt notifications.  EBNF.ipn-
      content-return shall 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 the
      message is included.  In this case, the message is formatted as
      multipart/mixed, and the returned message included as
      message/rfc822 after the text body part. Otherwise the first
      option is chosen.

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

      Mapped to EBNF.receipt-time
Top   ToC   RFC2156 - Page 95
      Mapped to EBNF.acknowledgement-mode

      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
                   / "X400-Content-Identifier" ":" printablestring
                   / "Priority" ":" priority
                   / "Originator-Return-Address" ":" 1#mailbox
                   / "DL-Expansion-History" ":" mailbox ";" date-time
                   / "Conversion" ":" prohibition
                   / "Conversion-With-Loss" ":" prohibition
                   / "Delivery-Date" ":" date-time
                   / "Discarded-X400-MTS-Extensions" ":"
                      1#( object-identifier / labelled-integer )

         prohibition     = "Prohibited" / "Allowed"
Top   ToC   RFC2156 - Page 96
         mts-msg-id       = "[" global-id ";" *text "]"

         mts-content-type = "P2" /  labelled-integer
                          / object-identifier

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

   The mappings for each element of MTS.MessageDeliveryEnvelope can now
   be considered.  Where the specified action does not result in an
   extended element being mapped, the criticality associated with this
   element shall be considered.  If the element is marked as critical
   for transfer or for delivery, the message shall be non delivered by
   the gateway because a critical extension cannot be correctly handled.

      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.MessageDeliveryEnvelope.other-fields
   (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 used.

      Mapped to the SMTP 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 "Original-Encoded-

      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   ToC   RFC2156 - Page 97
      The handling of this element is described in Section 4.6.2.

      Discarded.  This information will be mapped in the trace.

      Mapped to Date:.

      Mapped to the extended RFC 822 field "X400-Content-Identifier:".
      In RFC 1327, this was "Content-Identifier:".  This has been
      changed to avoid confusion with MIME defined fields.   Gateways
      which reverse map, may support the old field.

   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 MTS.ConversionWithLossProhibited.conversion-with-loss-
      prohibited, then add the extended RFC 822 field "Conversion-With-

      Mapped to a comment, as described in Section

      Mapped to the extended RFC 822 field "Originator-Return-Address:".


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

Top   ToC   RFC2156 - Page 98

      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 an extended RFC 822 field "DL-
      Expansion-History:".  These fileds 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 SMTP 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, this specification allows either for multiple messages to be
   generated, or for the per-recipient information to be discarded.
Top   ToC   RFC2156 - Page 99
   The following EBNF is defined for extended RFC 822 headers:

   mta-field       = "X400-Received" ":" x400-trace
                   / "Deferred-Delivery" ":" date-time
                   / "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
   not 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.  X.400 does not make
   this information available at the MTS level on delivery, because it
   requires that this service is provided by the first MTA. In the event
   that the first MTA does not provide this service, 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.

   If MTA.PerMessageTransferFields.extensions.dl-expansion-prohibited is
   present and set to dl-expansion-probited, the gateway may reject that
   message on the basis that it is unable to control distribution list
   expansion beyond the gateway.  The service relating to this is
   described in Section  This approach was not specified in RFC
   1327.  If it is found to be useful, it may be made mandatory in
   future versions of MIXER.
Top   ToC   RFC2156 - Page 100
   If MTA.PerMessageTransferFields.extensions.recipient-reassignment-
   prohibited is present and set to recipeint-reassignment-probited, the
   gateway may reject that message on the basis that it is unable to
   control distribution list expansion beyond the gateway.  The service
   relating to this is described in Section  This approach was
   not specified in RFC 1327.  If it is found to be useful, it may be
   made mandatory in future versions of MIXER.

   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.

   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 MD /ADMD=Foo/C=GB/ ;
           Relayed, Expanded, Redirected ; Tue, 20 Jun 89 19:25:11 +0100

   The gateway itself shall add a single line of trace information,
   indicating MIXER conversion by use of a comment.  For example:

   Received: from by
          (MIXER Conversion following RFC 1327);
          Thu, 2 Jan 1997 14:46:03 +0000

   If SMTP is being used, Appendix A shall also be followed, which
   includes optional mappings to extension parameters.
Top   ToC   RFC2156 - Page 101
5.3.8.  Mappings from Report Delivery

   that only reports destined for the MTS user will be mapped.  Some
   additional services are also taken from the MTA service.  X.400
   Delivery Reports are Mapped onto Delivery Status Notifications, as
   defined by NOTARY [28].  MTS Mappings

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

   The enclosing message is a MIME message of content type
   multipart/report, with report-type=delivery-status, which is
   generated with the following fields:

        An administrator at the gateway system.

   To:  A mapping of the  This is
        also the SMTP recipient.

        Set to "Delivery Report".  This is strictly redundant, but
        retained for backwards compatibility with RFC 1327.

        The EBNF for the subject line is:

       subject-line  = "Delivery-Report" "(" status ")"
                       [ "for" destination ]

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

       destination   = mailbox / "MTA" word

   The subject is intended to give a clear indication as to the nature
   of the message, and summarise its contents. EBNF.status is set
   according to whether the recipients reported on are all successes,
   all failures, or a mixture.  It is common for a report to reference a
   single recipient, in which case a subject line giving using all of
   the options of EBNF.status can be used.  This gives useful
   information to the recipient.  Where information varies between
   reported recpients, the options cannot be used.  The EBNF.destination
   is used to indicate the addresses in the reports.  If the report is
   for a single address, EBNF.mailbox is used to give the RFC 822
Top   ToC   RFC2156 - Page 102
   representation of the address.  If all of the reported recpients
   reference the same MTA this is included in EBNF.word.   The MTA is
   determined from the delivery report's trace.

   The format of the body of the message follows the NOTARY delivery
   status notification format, and 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 the
   gateway, with three body parts. The first body part is ASCII text
   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.

   The second (mandatory)  body part is the NOTARY delivery status
   notification, which contains detailed information extracted from the
   report.  This information may be critical to diagnosing an obscure

   The third (optional) body part contains the returned message (return
   of content).  This structure is useful to the RFC 822 recipient, as
   it enables the original message to be extracted.  For negative
   reports it shall be included if the original message is available.
   For positive reports headers from the message shall be included if
   the original message is available.

   The first body part containing the user oriented description is of
   type text/plain.  The format of this body part is defined below as

         dr-user-info = dr-summary <CRLF>
                         dr-recipients <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   ToC   RFC2156 - Page 103
         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 report-point
         = [ "mta" mta-name "in" ] global-id content-correlator = *word
         mta-name = word

      The EBNF.content-correlator is taken from the content correlator
      (or content identifier if there is no content correlator) and the from the trace, as described in Section
      LWSP may be added to improve the layout of the body part.

      There is an element for each recipient in the delivery report.  In
      each case, EBNF.mailbox is taken from the RFC 822 form of the
      originally specified recipient, which is taken from the originally
      specified recipient element if present or from the actual
      recipient.  When reporting success, the message delivery time is
      used to derive  When reporting failure, the
      information includes a human readable interpretation of the X.400
      diagnostic and reason codes, and the supplementary information.

      This is set according to whether or not the content is being

   The EBNF of this body part is designed for english-speaking users.
   The language of the strings in the EBNF may be altered.
Top   ToC   RFC2156 - Page 104
   The EBNF used in the delivery status notification is:

      dr-per-message-fields =
         / "X400-Conversion-Date" ":" date-time
         / "X400-Subject-Submision-Identifier" ":"
         / "X400-Content-Identifier" ":" printablestring
         / "X400-Content-Type" ":" mts-content-type
         / "X400-Original-Encoded-Information-Types" ":"
         / "X400-Originator-and-DL-Expansion-History" ":"
                              mailbox ";" date-time ";"
         / "X400-Reporting-DL-Name" ":" mailbox
         / "X400-Content-Correlator" ":" content-correlator
         / "X400-Recipient-Info" ":" recipient-info
         / "X400-Subject-Intermediate-Trace-Information" ":"
         / dr-extensions

      dr-per-recipient-fields =
         / "X400-Redirect-Recipient" ":" "x400" ";" std-or
         / "X400-Mapped-Redirect-Recipient" ":" "rfc822" ";" mailbox
         / "X400-Converted-EITs" ":" encoded-info ";"
         / "X400-Delivery-Time" ":" date-time
         / "X400-Type-of-MTS-User" ":" labelled-integer
         / "X400-Last-Trace" ":" [ encoded-info ] date-time
         / "X400-Supplementary-Info" ":"
               <"> printablestring <"> ";"
         / "X400-Redirection-History" ":" redirect-history-item
         / "X400-Physical-Forwarding-Address" ":" mailbox
         / "X400-Originally-Specified-Recipient-Number" ":"
         / dr-extensions

      dr-extensions = "X400-Discarded-DR-Extensions" ":"
                        1# (object-identifier / labelled-integer)

      dr-diagnostic = "Reason" labelled-integer-2
                        [ ";" "Diagnostic" labelled-integer-2 ]

   A body part of type delivery status, as defined by NOTARY, is
   generated.  MIXER extends this delivery status notification (DSN)
   specification, by defining additional per message fields in EBNF.dr-
   per-message-fields and additional per recipient fields in EBNF.dr-
   per-recipient-fields.   These are used as extensions to DSN.per-
   message-fields and DSN.per-recipient-fields.  MIXER also defines a
   new NOTARY address type "x400", with encoding of EBNF.std-or.   A
   directory name may be inluded as an RFC 822 comment.
Top   ToC   RFC2156 - Page 105
   The following DSN.per-message-fields are always generated:

      The DSN.mta-name-type is set to "x400", and this string is
      reserved by MIXER.  The DSN.mta-name has its syntax specified by, with the information derived from the first
      element of the DR's trace.

      This is derived from the date of the
      of the first recipient in the report.

   The following two EBNF.per-message-fields are generated by the MIXER

      The type is set to "dns" and the  domain  set to the local domain
      of the gateway.

      The is set to the time of the MIXER conversion.

   The elements of MTS.ReportDeliveryEnvelope.per-report-fields are
   mapped as follows onto the DSN per message fields as follows:

      Mapped to DSN.original-envelope-id-field.  The encoding of this
      MTS Identifier follows the format EBNF.mts-msg-id.

      Mapped to X400-Content-Identifier:

      Mapped to X400-Content-Type:

      Mapped to X400-Encoded-Info:

   The extensions from MTS.ReportDeliveryEnvelope.per-report-
   fields.extensions are mapped as follows:

      Each element is mapped to an "X400-Originator-and-DL-Expansion-
      History:"  They shall be ordered so that the most recent expansion
      comes first in the header (same order as trace).
Top   ToC   RFC2156 - Page 106
      Mapped to X400-Reporting-DL-Name:

      If the content correlator starts with the string "SMTP/NOTARY
      ENVID: ", then the remainder of the content correlator is mapped
      to the DSN original-envelope-id field.  If this is not the case,
      the content correlator is mapped to X400-Content-Correlator:,
      provided that the encoding is IA5String (this will always be the


      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 report.  They
      shall be listed in the X400-Discarded-DR-Extensions: field.

   If there are any other DR extensions, they shall also be discarded
   and listed in the X400-Discarded-DR-Extensions: field.

   For each element of MTS.ReportDeliveryEnvelope.per-recipient-fields,
   a set of DSN.per-recipient-fields is generated.  The fields are
   filled in as follows:

      If originally-intended-recipient-name is not present, generate a
      DSN.original-recipient-field fields, with DSN.address-type of
      "rfc822", and with an RFC 822 mailbox generated from the address
      encoded as specified by NOTARY.  Also generate a
      recipient-field field, which holds the X.400 representation of the
      same address.  If the directory name is present, it shall be added
      as a trailing comment in the X.400 form.

      If originally-intended-recipient-name is present, generate an
      "X400-Mapped-Redirect-Recipient:" field, with DSN.address-type of
      "rfc822", and with an RFC 822 mailbox generated from the address
      encoded as specified by NOTARY.  Also generate an "X400-Redirect-
      Recipient:" field, which holds the X.400 representation of the
      same address.  If the directory name is present, it shall be added
      as a trailing comment in the X.400 form.
Top   ToC   RFC2156 - Page 107
      If it is, then set DSN.action-field to
      "delivered", and set "X400-Delivery-Time:" and "X400-Type-of-MTS-
      User:" from the information in the report.  DSN.status field is
      set to "2.0.0".

      If it is MTS.Report.non-delivery, then set DSN.action-field to
      "failed".   DSN.diagnostic-code-field is encoded according to the
      syntax EBNF.dr-diagnostic, with the labelled integers set from the
      reason and diagnostic codes.  DSN.status-field is derived from the
      reason and diagnostic codes, as described below.

      Set X400-Converted-EITs:

      Generate a field, with DSN.address-type
      of "rfc822", and with an RFC 822 mailbox generated from the
      address encoded as specified by NOTARY.  Also generate a
      DSN.original-recipient-field field, which holds the X.400
      representation of the same address.  If the directory name is
      present, it shall be added as a trailing comment in the X.400

      Set X400-Supplementary-Info:

      Generate an "X400-Redirection-History:" field for each redirect
      history element.  The fields are ordered with the earliest
      redirect first.

      Set X400-Physical-Forwarding-Address as a mailbox, with directory
      name in comment if present.



   Any unknown extensions shall be discarded, irrespective of
   criticality.  All discarded extensions shall be included in a "X400-
   Discarded-DR-Extensions:" field.
Top   ToC   RFC2156 - Page 108
   The number from the MTA.PerRecipientReportTransferFields.originally-
   specified-recipient-number shall be mapped to "X400-Originally-
   Specified-Recipient-Number:", in order to facilitate reverse mapping
   of delivery reports.

   The original message shall be included in the delivery status
   notification 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 is not a legal message format, a
   dump of the ASN.1 may be included, encoded as application/octet-
   string.  This is recommended, but not required.

   Where the original message is included, it shall be encoded according
   to the MIME specifications as content type message/rfc822.  Status Code Mappings

   This section defines the mappings from X.400 diagnostic and status
   codes to the NOTARY Status field.

C/D     X400 meaning                            DSN code        Means

0/Any   Transfer failure (may be temporary)     4.4.0 Other net/route
1/Any   Unable to transfer                      5.0.0 Other, unknown
2/Any   Conversion not performed                5.6.3 Conv not supported
3/Any   Physical rendition not performed        5.6.0 Other media error
4/Any   Physical delivery not performed         5.1.0 Other address
5/Any   Restricted delivery                     5.7.1
6/Any   Directory operation unsuccessful        5.4.3 Routing server
7/Any   Deferred delivery not performed         5.3.3 Not capable

1/0     Unrecognized OR name                    5.1.1
1/1     Ambiguous OR name                       5.1.4
1/2     MTS congestion                          4.3.1
1/3     Loop detected                           5.4.6
1/4     Recipient unavailable                   4.2.1
1/5     Delivery time expired                   4.4.7
1/6     Encoded information types unsupported   5.6.1 Media unsupp.
1/7     Content too long                        5.2.3
2/8     Conversion impractical                  5.6.3
2/9     Conversion prohibited                   5.6.3
1/10    Implicit conversion not subscribed      5.6.3
1/11    Invalid arguments                       5.5.2
1/12    Content syntax error                    5.5.2
1/13    Size constraint violation               5.5.2
1/14    Protocol violation                      5.5.0
Top   ToC   RFC2156 - Page 109
1/15    Content type not supported              5.6.1 Media unsupp.
1/16    Too many recipients                     5.5.3
1/17    No bilateral agreement                  5.4.4
1/18    Unsupported critical function           5.3.3 System not capable
2/19    Conversion with loss prohibited         5.6.2
2/20    Line too long                           5.6.0
2/21    Page split                              5.6.0
2/22    Pictorial symbol loss                   5.6.2
2/23    Punctuation symbol loss                 5.6.2
2/24    Alphabetic character loss               5.6.2
2/25    Multiple information loss               5.6.2
1/26    Recipient reassignment prohibited       5.4.0 Undefined net/route
1/27    Redirection loop detected               5.4.6
1/28    DL expansion prohibited                 5.7.2
1/29    No DL submit permission                 5.7.1 Delivery not
1/30    DL expansion failure                    4.2.4
4/31    Physical rendition attrs not supported  5.6.0 Undefined media
4/32-45 Various physical mail stuff             5.1.0 Other address
1/43    New address unknown                     5.1.6 Destination mbox
1/46    Secure messaging error                  5.7.0 Other security
2/47    Unable to downgrade                     5.3.3 System not capable
0/48    Unable to complete transfer             5.3.4 Message too big
0/49    Transfer attempts limit reached         4.4.7 Delivery time
                                                      expired  MTA Mappings

   The single SMTP 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, which results in fields
   in the outer header of the DSN.
      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   ToC   RFC2156 - Page 110

      Mapped onto the extended RFC 822 field "X400-Received:", as
      described in Section 5.3.7.  Date: is generated from the first
      element of trace.

   The following additional mappings are made, which result in per
   message fields in the DSN body part:

      Mapped to X400-Last-Trace:".

      information Mapped to "X400-Subject-Intermediate-Trace-
      Information:". These fields are ordered so that the most recent
      trace element comes first.  Example Delivery Reports

   This section contains sample delivery reports.   These are the same
   examples used in RFC 1327, and so they also illustrate the changes
   between RFC 1327 and this document.  Example Delivery Report 1:

   Received: from by
      via Delivery Reports Channel id <>;
      Thu, 7 Feb 1991 15:48:39 +0000 From: UCL-CS MTA
   <> To: Subject: Delivery
   Report (failure) for Message-Type: Delivery
   Report Date: Thu, 7 Feb 1991 15:48:39 +0000 Message-ID:
   <"bells.cs.u.694:"> X400-Content-
   Identifier: Greetings.  MIME-Version: 1.0 Content-Type:
   multipart/report; report-type=delivery-status;


   This report relates to your message:

           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
Top   ToC   RFC2156 - Page 111

   The Original Message follows:

   --boundary-1 content-type: message/delivery-status

   Reporting-MTA: x400; in /
   400/C=gb/ Arrival-Date: Thu, 7 Feb 1991 15:48:34 +0000 DSN-Gateway:
   dns; X400-Conversion-Date: Thu, 7 Feb 1991
   15:48:40 +0000 Original-Envelope-Id:
   400/C=gb/;<1803.665941698@UK.AC.UCL.CS>] X400-Content-Identifier:
   Greetings.  X400-Subject-Intermediate-Trace-Information:
   / 400/C=gb/;
            arrival Thu, 7 Feb 1991 15:48:20 +0000 action Relayed X400-
   Subject-Intermediate-Trace-Information:  /
            arrival Thu, 7 Feb 1991 15:48:18 +0000 action Relayed

   Original-Recipient: rfc822; Final-Recipient:
   400/C=gb/; Action: failure Status: 5.1.1 Diagnostic-Code: x400;
   Reason 1 (Unable-To-Transfer);
        Diagnostic 0 (Unrecognised-ORName) X400-Last-Trace: (ia5) Thu, 7
   Feb 1991 15:48:18 +0000; X400-Originally-Specified-Recipient-Number:
   1 X400-Supplementary-Info: "MTA '' gives error message  (USER)
       Unknown user name in """;

   --boundary-1 Content-Type: message/rfc822

   Received: from by
     with SMTP inbound id <>;
     Thu, 7 Feb 1991 15:48:21 +0000 To: 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


Top   ToC   RFC2156 - Page 112
   Example Delivery Report 2:

   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:46:11 +0000
   Message-ID: <"DLE/910207154840Z/000">
   X400-Content-Identifier: A useful mess...
   MIME-Version: 1.0
   Content-Type: multipart/report; report-type=delivery-status;


   This report relates to your message:
           A useful mess...

           of Thu, 7 Feb 1991 15:43:20 +0000

   Your message was not delivered to
           for the following reason:
           Bad Address
           DG 21187: (CEO POA) Unknown addressee.

   The Original Message is not available

   content-type: message/delivery-status

   Reporting-MTA: x400; /PRMD=DGC/ADMD=GOLD 400/C=GB/
   Arrival-Date: Thu, 7 Feb 1991 15:48:40 +0000
   DSN-Gateway: dns;
   X400-Conversion-Date: Thu, 7 Feb 1991 15:49:12 +0000
Top   ToC   RFC2156 - Page 113
     [/ 400/C=gb/;<1796.665941626@UK.AC.UCL.CS>]
   X400-Content-Identifier: A useful mess...

   Original-Recipient: rfc822;
   Final-Recipient: x400;
     /I=j/S=nosuchuser/OU=dle/O=cambridge/PRMD=DGC/ADMD=GOLD 400/C=GB/
   Action: failure
   Status: 5.1.1
   Diagnostic-Code: x400; Reason 1 (Unable-To-Transfer);
       Diagnostic 0 (Unrecognised-ORName)
   X400-Supplementary-Info: "DG 21187: (CEO POA) Unknown addressee."
   X400-Originally-Specified-Recipient-Number: 1


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.
Top   ToC   RFC2156 - Page 114
Appendix A - Mappings Specific to SMTP

   This Appendix is specific to the Simple Mail Transfer  Protocol (RFC
   821).  It describes specific changes in the context of this protocol.
   When MIXER is used with SMTP, conformance to this appendix is

   1.  Probes

   When servicing a probe, as described in section 5.3.9, use may be
   made of the SMTP VRFY command to increase the accuracy of information
   contained in the delivery report.

   2.  Long Lines

   SMTP is a text oriented protocol, and is required to support a line
   length of at least 1000 characters.   Some implementations do not
   support line lengths greater than 1000 characters.   This can cause
   problems.  Where body parts have long lines, it is recommended to use
   a MIME encoding that folds lines (quoted printable).

   3.  SMTP Extensions

   There are several RFCs that specify extensions to SMTP. Most of these
   are not relevant to MIXER.  The NOTARY work to support delivery
   report defines extensions which are relevant [29].  Use of these
   extensions by a MIXER gateway is optional.  If these extensions are
   used, they shall be used in the manner described below.

   3.1.  SMTP Extension mapping to X.400

   Mappings are defined for the following extensions:

      This is used to set the report and non-delivery bits of
      If the value is NEVER, both bits are zero.  If SUCCESS is present,
      the report bit is set.  Otherwise, the non-delivery-report bit is
      set.  If the gateway uses the NOTIFY command, it shall perform
      this mapping in all cases.

      If the address type of the original recipient is "x400" or
      "rfc822", this may be used at the MTS level, to generate an
      element of redirection history, with the redirection date being
      the date of conversion and the reason set to "alias".
Top   ToC   RFC2156 - Page 115
      If present, this may be used to generate a content correlator.
      This is used rather than the MTS Identifier, as the ENVID is
      unique for the UA only and is likely to be too large to map to an
      MTS identifier. The content correlator is encoded as an IA5 String
      containing the ENVID and prefixed by the string:

                            "SMTP/NOTARY ENVID: "

      If the ENVID starts with the string "X400-MTS-Identifier: ", then
      this ENVID was generated from an X.400 MTS Identifier.  The
      reverse mapping defined in Section 3.2 of Appendix A shall not be
      used, as this may cause problems in certain situations (e.g.,
      where the message was expanded by an Internet mailing list).

   3.2.  X.400 Mapping to SMTP Extensions

   The following extensions may be used as a part of the MIXER mapping:

      The originator-report and originator-non-delivery-report bits of
      determine how this is used.   If both bits are zero, the parameter
      is NEVER.  If the report bit is set, SUCCESS is used.   Otherwise,
      FAILURE is used.  If this is done, the gateway shall not generate
      a delivery report for this recipient, unless this is needed in the
      case where the originating MTA service report requirements differ
      from the user requirements.   Additional originating MTA
      requrirements are satisfied by the gateway.

      If the MTS.perRecipientDeliveryFields.originally-intended-
      recipient-name is present, the ORCPT command may be used to carry
      this value, using the "x400" syntax.

      This may be generated, with the value taken from the
      MTS.MessageDeliveryEnvelope.message-delivery-identifer.  If this
      is done, it shall be encoded as EBNF.mts-msg-id, preceded by the
      string "X400-MTS-Identifier: ".

      If MTA.PerMessageTransferFields.per-message-indicators.content-
      return-request is set to FALSE, the parameter RET may be set to
      HDRS, to specify return of headers only.
Top   ToC   RFC2156 - Page 116
Appendix B - Mapping with X.400(1984)

   This appendix defines modifications to the  mapping for use with

   The X.400(1984) protocols are a proper subset of X.400(1988).  When
   mapping from X.400(1984) to RFC 822, no changes to this specification
   are needed.

   When mapping from RFC 822 to X.400(1984), no use can be made of 1988
   specific features.   No use of such features is made at the MTS
   level.  The heading extension feature is used at the IPMS level, and
   this shall be replaced by the RFC 987 approach.  All header
   information which would usually be mapped into the rfc-822-heading-
   list extension is mapped into a single IA5 body part, which is the
   first body part in the message.  This body part will start with the
   string "RFC-822-Headers:" as the first line.  The headers then follow
   this line.  This specification requires correct reverse mapping of
   this format, either from 1988 or 1984.  RFC 822 extended headers
   which could be mapped into X.400(1988) elements, are also mapped to
   the body part.

   In an environment where RFC 822 is of major importance, it may be
   desirable for downgrading to consider the case where the message was
   originated in an RFC 822 system, and mapped according to this
   specification.  The rfc-822-heading-list extension may be mapped
   according to this appendix.

   When parsing std-or, the following restrictions shall be observed:

   -    Only the 84/88 attributes identified in the table in
        Section 4.2 are present.

   -    No teletex encoding is allowed.

   If an address violates this, it shall be treated as an RFC 822
   address, which will usually lead to encoding as a DDA "RFC-822".

   It is possible that attributes of zero length may be present
   in an OR Address.  This is not legal in 1988, except for ADMD
   where the case is explicitly described in Section 4.3.5.
   Attributes of zero length are deprecated (the attribute shall be
   omitted), and will therefore be unusual.  However, some systems
   generate them and rely on them.  Therefore, any null attribute
   shall be enoded using the std-or encoding (e.g., /O=/).
Top   ToC   RFC2156 - Page 117
   If a non-Teletex Common Name (CN) is present, it shall be
   mapped onto a Domain Defined Attribute "Common".  This is in line
   with RFC 1328 on X.400 1988 to 1984 downgrading [22].

   This specification defines a mapping of the Internet message
   framework to X.400.  Body part mappings are defined in RFC
   2157 [6], which relies on X.400(88) features.   Downgrading to
   X.400(84) for body parts is defined in RFC 1496 (HARPOON), which
   shall be followed in the context of this appendix [5].
Top   ToC   RFC2156 - Page 118
Appendix C - RFC 822 Extensions for X.400 access

   This appendix defines a number of optional mappings which may be
   provided to give access from RFC 822 to a number of X.400 services.
   These mappings are beyond the basic scope of this specification.
   There has been a definite demand to use extended RFC 822 as a
   mechanism to access X.400, and these extensions provide access to
   certain features.  If this functionality is provided, this appendix
   shall be followed.  The following headings are defined:

         extended-heading =
             "Prevent-NonDelivery-Report" ":"
             / "Generate-Delivery-Report" ":"
             / "Alternate-Recipient" ":" prohibition
             / "Disclose-Recipients" ":"  prohibition
             / "X400-Content-Return" ":" prohibition

   Prevent-NonDelivery-Report and Generate-Delivery-Report allow setting
   of MTS.PerRecipientSubmissionFields.originator-report-request.  The
   setting will be the same for all recipients.

   Alternate-Recipient, Disclose-Recipients, and X400-Content-Return
   allow for override of the default settings for

   Use of NOTARY mechanisms is a preferred meachanism for controlling
   these parameters.
Top   ToC   RFC2156 - Page 119
Appendix D - Object Identifier Assignment

   The following Object Identifiers shall be used.

   internet ::= OBJECT IDENTIFIER  { iso org(3) dod(6) 1 } -- from RFC

   mail OBJECT IDENTIFIER ::= { internet 7 }  -- IANA assigned

   mixer OBJECT IDENTIFIER ::= { mail mixer(1) } -- inherited from RFC
   mixer-core OBJECT IDENTIFIER ::= { mixer core(3) }

   id-rfc-822-field-list OBJECT IDENTIFIER ::= {mixer-core 2}
   id-dsn-header-list OBJECT IDENTIFIER ::= {mixer-core 3}
   id-dsn-field-list OBJECT IDENTIFIER ::= {mixer-core 4}

   eit-mixer OBJECT IDENTIFIER ::= {mixer-core 5}
                  -- the MIXER pseudo-EIT

   This object identifier for id-rfc-822-field-list is different to
   the one assigned in RFC 1327, which was erroneous.

(next page on part 5)

Next Section