Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
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
      assigned.

   Date:
      A value will always be generated

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

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

5.3.3.2.  Global Domain Identifier

   The following simple EBNF is used to represent
   MTS.GlobalDomainIdentifier:

      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" /
                  "Company-Confidential"

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

   IPMS.Heading.this-IPM
      Mapped to "Message-ID:".

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

   IPMS.Heading.authorizing-users
      Mapped to "From:".

   IPMS.Heading.primary-recipients
      Mapped to "To:".

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

   IPMS.Heading.blind-copy-recipients
      Mapped to "Bcc:".

   IPMS.Heading.replied-to-ipm
      Mapped to "In-Reply-To:".
Top   ToC   RFC2156 - Page 90
   IPMS.Heading.obsoleted-IPMs
      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.

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

   IPMS.Heading.subject
      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.

   IPMS.Heading.expiry-time
      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.

   IPMS.Heading.reply-time
      Mapped to the extended RFC 822 field "Reply-By:".

   IPMS.Heading.reply-recipients
      Mapped to "Reply-To:".

   IPMS.Heading.importance
      Mapped to the extended RFC 822 field "Importance:".

   IPMS.Heading.sensitivity
      Mapped to the extended RFC 822 field "Sensitivity:".

   IPMS.Heading.autoforwarded
      Mapped to the extended RFC 822 field "Autoforwarded:".

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

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

   language
      Mapped to the  RFC 822 field "Content-Language:", defined in RFC
      1766 [7].  This mapping may be made without loss of information.

   auto-submitted
      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:".

5.3.4.1.  Mapping the IPMS Body

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

5.3.4.2.  Example Message

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

Received: from mhs-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with
          NIFTP id <7906-0@bells.cs.ucl.ac.uk>;
          Thu, 30 May 1991 18:24:55 +0100
X400-Received: by mta "mhs-relay.ac.uk" in /PRMD=uk.ac/ADMD= /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
X400-Originator: Stephen.Harrison@gosip-uk.hmg.gold-400.gb
X400-MTS-Identifier:
     [/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: Stephen.Harrison@gosip-uk.hmg.gold-400.gb (Tel +44 71 217 3487)
Message-ID: <PC1000-910530172027-57D8*@MHS>
To: Jim Craigie <NTIN36@gec-b.rutherford.ac.uk>,
    Tony Bates <tony@ean-relay.ac.uk>,
    Steve Kille <S.Kille@cs.ucl.ac.uk>
Subject: Email Problems
Sender: Stephen.Harrison@gosip-uk.hmg.gold-400.gb
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=boundary-1

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

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

Stephen Harrison
UK GOSIP Project

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

From: Urs Eppenberger <Eppenberger@verw.switch.ch>
Message-ID:
<562*/S=Eppenberger/OU=verw/O=switch/PRMD=SWITCH/ADMD=ARCOM/C=CH/@MHS>
To: "Stephen.Harrison" <Stephen.Harrison@gosip-uk.hmg.gold-400.gb>
Cc: kimura@bsdarc.bsd.fc.nec.co.jp
Subject: Response to Email link
Content-Type: multipart/mixed; boundary=boundary-2


--boundary-2

Dear Mr Harrison......


--boundary-2--

--boundary-1--

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:

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

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

   Message-Type:
      Set to "InterPersonal Notification"

   References:
      Set to IPMS.IPN.subject-ipm
Top   ToC   RFC2156 - Page 93
   Discarded-X400-IPMS-Extensions:
      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
   manner.

         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-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:"
                 encoded-info

         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:

   subject-ipm
      Mapped to "References:"

   ipn-originator
      Mapped  to "From:".

   ipn-preferred-recipient
      Mapped to EBNF.preferred-recipient

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

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

   non-receipt-reason
      Used to select between EBNF.ipn-discarded and EBNF.ipn-auto-
      forwarded

   discard-reason
      Mapped to EBNF.discard-reason

   auto-forward-comment
      Mapped to EBNF.auto-comment

   returned-ipm
      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:

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

   suppl-receipt-info
      Mapped to EBNF.ipn-suppl

   An example notification is:

         From: Steve Kille <steve@cs.ucl.ac.uk>
         To: Julian Onions <jpo@computer-science.nottingham.ac.uk>
         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 <steve@cs.ucl.ac.uk>
         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" ":"
                      encoded-info
                   / "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.

   MTS.MessageDeliveryEnvelope.message-delivery-identifier
      Mapped to the extended RFC 822 field "X400-MTS-Identifier:".

   MTS.MessageDeliveryEnvelope.message-delivery-time
      Discarded, as this time will be represented in an appropriate
      trace element.

   The mappings for elements of MTS.MessageDeliveryEnvelope.other-fields
   (MTS.OtherMessageDeliveryFields) are:

   content-type
      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.

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

   original-encoded-information-types
      Mapped to the extended RFC 822 field "Original-Encoded-
      Information-Types:".

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

   delivery-flags
      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
   originally-intended-recipient-name
      The handling of this element is described in Section 4.6.2.

   converted-encoded-information-types
      Discarded.  This information will be mapped in the trace.

   message-submission-time
      Mapped to Date:.

   content-identifier
      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.

   conversion-with-loss-prohibited
      If set to MTS.ConversionWithLossProhibited.conversion-with-loss-
      prohibited, then add the extended RFC 822 field "Conversion-With-
      Loss:".

   requested-delivery-method
      Mapped to a comment, as described in Section 4.6.2.2.

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

   physical-forwarding-address-request
   physical-delivery-modes
   registered-mail-type
   recipient-number-for-advice
   physical-rendition-attributes
   physical-delivery-report-request
   physical-forwarding-prohibited


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

   originator-certificate
   message-token
   content-confidentiality-algorithm-identifier
Top   ToC   RFC2156 - Page 98
   content-integrity-check
   message-origin-authentication-check
   message-security-label
   proof-of-delivery-request

      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.

   redirection-history
      This is described in Section 4.6.2.

   dl-expansion-history
      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
        message

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

   -    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
   4.6.2.2, 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 ";"  ]
                       action-list
                    ";" 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
   used.

   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 2.3.1.2.  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 2.3.1.2.  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 isode.com by isode.com
          (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].

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

   From:
        An administrator at the gateway system.

   To:  A mapping of the
        MTA.ReportTransferEnvelope.report-destination-name.  This is
        also the SMTP recipient.

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

   Subject:
        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
        message.

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

   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
   EBNF.dr-user-info.

         dr-user-info = dr-summary <CRLF>
                         dr-recipients <CRLF>
                         dr-content-return

         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

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

   EBNF.dr-recipients
      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 EBNF.date-time.  When reporting failure, the
      information includes a human readable interpretation of the X.400
      diagnostic and reason codes, and the supplementary information.

   EBNF.dr-content-return
      This is set according to whether or not the content is being
      returned.

   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" ":"
                                   mts-msg-id
         / "X400-Content-Identifier" ":" printablestring
         / "X400-Content-Type" ":" mts-content-type
         / "X400-Original-Encoded-Information-Types" ":"
                              encoded-info
         / "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" ":"
                              x400-trace
         / 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" ":"
               integer
         / 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:

   DSN.reporting-mta-field
      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
      EBNF.report-point, with the information derived from the first
      element of the DR's trace.

   DSN.arrival-date-field
      This is derived from the date of the
      MTA.PerRecipientReportTransferFields.last-trace-info.arrival-time
      of the first recipient in the report.

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

   DSN.dsn-gateway-field
      The type is set to "dns" and the  domain  set to the local domain
      of the gateway.

   X400-Conversion-Date:
      The EBNF.date-time 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:

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

   content-identifier
      Mapped to X400-Content-Identifier:

   content-type
      Mapped to X400-Content-Type:

   original-encoded-information-types
      Mapped to X400-Encoded-Info:

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

   originator-and-DL-expansion-history
      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
   reporting-DL-name
      Mapped to X400-Reporting-DL-Name:

   content-correlator
      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
      case).

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

      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:

   actual-recipient-name
      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 DSN.final-
      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
   report
      If it is MTS.Report.delivery, 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.

   converted-encoded-information-types
      Set X400-Converted-EITs:

   originally-intended-recipient
      Generate a DSN.final-recipient-field 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
      form.

   supplementary-info
      Set X400-Supplementary-Info:

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

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

   recipient-certificate
      Discard

   proof-of-delivery
      Discard

   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.

5.3.8.2.  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
                                                      status
5/Any   Restricted delivery                     5.7.1
6/Any   Directory operation unsuccessful        5.4.3 Routing server
                                                      failure
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
                                                      authorized
1/30    DL expansion failure                    4.2.4
4/31    Physical rendition attrs not supported  5.6.0 Undefined media
                                                      error
4/32-45 Various physical mail stuff             5.1.0 Other address
                                                      status
1/43    New address unknown                     5.1.6 Destination mbox
                                                      moved
1/46    Secure messaging error                  5.7.0 Other security
                                                      status
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

5.3.8.3.  MTA Mappings

   The single SMTP recipient is constructed from
   MTA.ReportTransferEnvelope.report-destination-name, 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.

   MTA.ReportTransferEnvelope.report-destination-name
      This is used to generate the To: field.

   MTA.ReportTransferEnvelope.identifier
      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
   MTA.ReportTransferEnvelope.trace-information
      and
   MTA.ReportTransferEnvelope.internal-trace-information

      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:

   MTA.PerRecipientReportTransferFields.last-trace-information
      Mapped to X400-Last-Trace:".

   MTA.PerReportTransferFields.subject-intermediate-trace-
      information Mapped to "X400-Subject-Intermediate-Trace-
      Information:". These fields are ordered so that the most recent
      trace element comes first.

5.3.8.4.  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 cs.ucl.ac.uk by bells.cs.ucl.ac.uk
      via Delivery Reports Channel id <27699-0@bells.cs.ucl.ac.uk>;
      Thu, 7 Feb 1991 15:48:39 +0000 From: UCL-CS MTA
   <postmaster@cs.ucl.ac.uk> To: S.Kille@cs.ucl.ac.uk Subject: Delivery
   Report (failure) for H.Hildegard@bbn.com Message-Type: Delivery
   Report Date: Thu, 7 Feb 1991 15:48:39 +0000 Message-ID:
   <"bells.cs.u.694:07.01.91.15.48.34"@cs.ucl.ac.uk> X400-Content-
   Identifier: Greetings.  MIME-Version: 1.0 Content-Type:
   multipart/report; report-type=delivery-status;
       boundary=boundary-1

   --boundary-1

   This report relates to your message:
           Greetings.

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

   Your message was not delivered to
           H.Hildegard@bbn.com for the following reason:
           Bad Address
           MTA 'bbn.com' gives error message  (USER) Unknown user name
   in
Top   ToC   RFC2156 - Page 111
           "H.Hildegard@bbn.com"

   The Original Message follows:


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

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



   Original-Recipient: rfc822; H.Hildegard@bbn.com Final-Recipient:
   x400;
     /RFC-822=H.Hildegard(a)bbn.com/OU=cs/O=ucl/PRMD=uk.ac/ADMD=gold
   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 'bbn.com' gives error message  (USER)
       Unknown user name in "H.Hildegard@bbn.com"";


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

   Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk
     with SMTP inbound id <27689-0@bells.cs.ucl.ac.uk>;
     Thu, 7 Feb 1991 15:48:21 +0000 To: H.Hildegard@bbn.com 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
   <S.Kille@cs.ucl.ac.uk>


   Steve

   --boundary-1--
Top   ToC   RFC2156 - Page 112
   Example Delivery Report 2:

   Received: from cs.ucl.ac.uk by bells.cs.ucl.ac.uk
     via Delivery Reports Channel id <27718-0@bells.cs.ucl.ac.uk>;
     Thu, 7 Feb 1991 15:49:11 +0000
   X400-Received: by mta "bells.cs.ucl.ac.uk" in
     /PRMD=uk.ac/ADMD=gold 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 <postmaster@cs.ucl.ac.uk>
   To: S.Kille@cs.ucl.ac.uk
   Subject: Delivery Report (failure) for
            j.nosuchuser@dle.cambridge.DGC.gold-400.gb
   Message-Type: Delivery Report
   Date: Thu, 7 Feb 1991 15:46:11 +0000
   Message-ID: <"DLE/910207154840Z/000"@cs.ucl.ac.uk>
   X400-Content-Identifier: A useful mess...
   MIME-Version: 1.0
   Content-Type: multipart/report; report-type=delivery-status;
       boundary=boundary-1

   --boundary-1

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

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


   Your message was not delivered to
           j.nosuchuser@dle.cambridge.DGC.gold-400.gb
           for the following reason:
           Bad Address
           DG 21187: (CEO POA) Unknown addressee.

   The Original Message is not available


   --boundary-1
   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;  bells.cs.ucl.ac.uk
   X400-Conversion-Date: Thu, 7 Feb 1991 15:49:12 +0000
   Original-Envelope-Id:
Top   ToC   RFC2156 - Page 113
     [/PRMD=uk.ac/ADMD=gold 400/C=gb/;<1796.665941626@UK.AC.UCL.CS>]
   X400-Content-Identifier: A useful mess...


   Original-Recipient: rfc822; j.nosuchuser@dle.cambridge.DGC.gold-400.gb
   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

   --boundary-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
   mandatory.

   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:

   NOTIFY
      This is used to set the report and non-delivery bits of
      MTA.PerRecipientMessageTransferFields.per-recipient-indicators.
      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.

   ORCPT
      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
   ENVID
      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:

   NOTIFY
      The originator-report and originator-non-delivery-report bits of
      MTA.PerRecipientMessageTransferFields.per-recipient-indicators
      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.

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

   ENVID
      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: ".

   RET
      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
   X.400(1984).

   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
   MTS.PerMessageIndicators.

   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
   1155

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

   mixer OBJECT IDENTIFIER ::= { mail mixer(1) } -- inherited from RFC
   1495
   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