in Index   Prev   Next

RFC 1327

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

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

ToP   noToC   RFC1327 - Page 91   prevText
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 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.

Appendix B - Mappings specific to the JNT Mail

   This Appendix is specific to the JNT Mail Protocol.  It describes
   specific changes in the context of this protocol.

   1.  Introduction

      There are five aspects of a gateway which are JNT Mail Specific.
      These are each given a section of this appendix.

   2.  Domain Ordering

      When interpreting and generating domains, the UK NRS domain
      ordering shall be used, both in headers, and in text generated for
      human description.

   3.  Addressing

      A gateway which maps to JNT Mail should recognise the Domain
      Defined Attribute JNT-MAIL.  The value associated with this
      attribute should be interpreted according to the JNT Mail
      Specification.  This DDA shall never be generated by a gateway.
      For this reason, the overflow mechanism is not required.

   4.  Acknowledge-To:

      This field has no direct functional equivalent in X.400.  However,
      it can be supported to an extent, and can be used to improve X.400

      If an Acknowledge-To: field is present when going from JNT Mail to
ToP   noToC   RFC1327 - Page 92
      X.400, there are two different situations.  The first case is
      where there is one address in the Acknowledge-To: field, and it is
      equal to the 822-MTS return address.  In this case, the
      shall be set for each recipient, and the Acknowledge-To: field
      discarded.  Here, X.400 can provide the equivalent service.

      In all other cases two actions are taken.

         1. Acknowledgement(s) may be generated by the gateway.  The
            text of these acknowledgements shall indicate that they are
            generated by the gateway, and do not correspond to delivery.

         2. The Acknowledge-To: field shall be passed as an extension

      When going from X.400 to JNT Mail, in cases where
      originator-report bit is set for all recipients (i.e., there is a
      user request for a positive delivery report for every recipeint),
      generate an Acknowledge-To: field containing the
      MTS.OtherMessageDeliveryFields.originator-name.  Receipt
      notification requests are not mapped onto Acknowledge-To:, as no
      association can be guaranteed between IPMS and MTS level
      addressing information.

   5.  Trace

      JNT Mail trace uses the Via: syntax.  When going from JNT Mail to
      X.400, a mapping similar to that for Received:  is used. No
      MTS.GlobalDomainIdentifier of the site making the trace can be
      derived from the Via:, so a value for the gateway is used.  The
      trace text, including the "Via:", is unfolded, truncated to
      MTS.ub-mta-name-length (32), and mapped to
      MTA.InternalTraceInformationElement.mta-name.  There is no JNT
      Mail specific mapping for the reverse direction.

   6.  Timezone specification

      The extended syntax of zone defined in the JNT Mail Protocol shall
      be used in the mapping of UTCTime defined in Chapter 3.

   7.  Lack of 822-MTS originator specification

      In JNT Mail the default mapping of the
      MTS.OtherMessageDeliveryFields.originator-name is to the Sender:
      field.  This can cause a problem when going from X.400 to JNT Mail
      if the mapping of IPMS.Heading has already generated a Sender:
ToP   noToC   RFC1327 - Page 93
      field.  To overcome this, new extended JNT Mail field is defined.
      This is chosen to align with the JNT recommendation for
      interworking with full RFC 822 systems [Kille84b].

              original-sender     = "Original-Sender" ":" mailbox

      If an IPM has no IPMS.Heading.authorizing-users component and
      IPMS.Heading.originator.formal-name is different from
      MTS.OtherMessageDeliveryFields.originator-name, map
      MTS.OtherMessageDeliveryFields.originator-name, onto the Sender:

      If an IPM has a IPMS.Heading.authorizing-users component, and
      IPMS.Heading.originator.formal-name is different from
      MTS.OtherMessageDeliveryFields.originator-name is mapped onto the
      Sender: field, and IPMS.Heading.originator mapped onto the
      Original-Sender: field.

      In other cases the MTS.OtherMessageDeliveryFields.originator-name,
      is already correctly represented.

Appendix C - Mappings specific to UUCP Mail

   Gatewaying of UUCP and X.400 is handled by first gatewaying the UUCP
   address into RFC 822 syntax (using RFC 976) and then gatewaying the
   resulting RFC 822 address into X.400.  For example, an X.400 address

           Country         US
           Organisation    Xerox
           Personal Name   John Smith

   might be expressed from UUCP as


   (assuming gate is a UUCP-ARPA gateway and gatehost.COM is an ARPA-
   X.400 gateway) or


   (assuming that Xerox.COM and /C=US/O=Xerox/ are equivalent.)

   In the other direction, a UUCP address Smith@ATT.COM, integrated into
   822, would be handled as any other 822 address.  A non-integrated
   address such as inthop!dest!user might be handled through a pair of
ToP   noToC   RFC1327 - Page 94
           Country         US
           ADMD            ATT
           PRMD            ARPA
           Organisation    GateOrg
           RFC-822         inthop!dest!user@gatehost.COM

   or through a single X.400 to UUCP gateway:

           Country         US
           ADMD            ATT
           PRMD            UUCP
           Organisation    GateOrg
           RFC-822         inthop!dest!user

Appendix D - Object Identifier Assignment

   An object identifier is needed for the extension IPMS element.  The
   following value shall be used.

   rfc-987-88 OBJECT IDENTIFIER ::=
       {ccitt data(9) pss(2342) ucl(234219200300) rfc-987-88(200)}

   id-rfc-822-field-list OBJECT IDENTIFIER ::= {rfc987-88 field(1)}

Appendix E - BNF Summary

        boolean = "TRUE" / "FALSE"

        numericstring = *DIGIT

        printablestring  = *( ps-char )
        ps-restricted-char      = 1DIGIT /  1ALPHA / " " / "'" / "+"
                           / "," / "-" / "." / "/" / ":" / "=" / "?"
        ps-delim         = "(" / ")"
        ps-char          = ps-delim / ps-restricted-char

        ps-encoded       = *( ps-restricted-char / ps-encoded-char )
        ps-encoded-char  = "(a)"               ; (@)
                         / "(p)"               ; (%)
                         / "(b)"               ; (!)
                         / "(q)"               ; (")
                         / "(u)"               ; (_)
                         / "(l)"               ; "("
                         / "(r)"               ; ")"
                         / "(" 3DIGIT ")"
ToP   noToC   RFC1327 - Page 95
        teletex-string   = *( ps-char / t61-encoded )
        t61-encoded      = "{" 1* t61-encoded-char "}"
        t61-encoded-char = 3DIGIT

        teletex-and-or-ps = [ printablestring ] [ "*" teletex-string ]

        labelled-integer ::= [ key-string ] "(" numericstring ")"

        key-string      = *key-char
        key-char        = <a-z, A-Z, 0-9, and "-">

        object-identifier  ::= oid-comp object-identifier
                        | oid-comp

        oid-comp ::= [ key-string ] "(" numericstring ")"

        encoded-info    = 1#encoded-type

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

        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)

        encoded-pn      = [ given "." ] *( initial "." ) surname

        given           = 2*<ps-char not including ".">

        initial         = ALPHA

        surname         = printablestring

        std-or-address  = 1*( "/" attribute "=" value ) "/"
        attribute       = standard-type
                        / "RFC-822"
                        / registered-dd-type
ToP   noToC   RFC1327 - Page 96
                        / dd-key "." std-printablestring
        standard-type   = key-string

                        = key-string
        dd-key          = key-string

        value           = std-printablestring

                        = *( std-char / std-pair )
        std-char        = <"{", "}", "*", and any ps-char
                                        except "/" and "=">
        std-pair        = "$" ps-char

        dmn-or-address  = dmn-part *( "." dmn-part )
        dmn-part        = attribute "$" value
        attribute       = standard-type
                        / "~" dmn-printablestring
        value           = dmn-printablestring
                        / "@"
        dmn-printablestring =
                        = *( dmn-char / dmn-pair )
        dmn-char        = <"{", "}", "*", and any ps-char
                                                except ".">
        dmn-pair        = "\."

        global-id = std-or-address

        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
ToP   noToC   RFC1327 - Page 97
        md-or-mta        = "MD" global-id
                         / "MTA" mta

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

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

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

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

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

        dr-recipient = dr-recip-success / dr-recip-failure

        dr-recip-success =
                        "Your message was successfully delivered to:"
                         mailbox "at" date-time

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

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

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

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

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

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

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

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

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

        report-point = [ "mta" word "in" ] global-id
        content-correlator = *word
        dl-history = 1#( mailbox "(" date-time ")")
ToP   noToC   RFC1327 - Page 99
        mts-field = "X400-MTS-Identifier" ":" mts-msg-id
                  / "X400-Originator" ":" mailbox
                  / "X400-Recipients" ":" 1#mailbox
                  / "Original-Encoded-Information-Types" ":"
                  / "X400-Content-Type" ":" mts-content-type
                  / "Content-Identifier" ":" printablestring
                  / "Priority" ":" priority
                  / "Originator-Return-Address" ":" 1#mailbox
                  / "DL-Expansion-History" ":" mailbox ";" date-time ";"
                  / "Conversion" ":" prohibition
                  / "Conversion-With-Loss" ":" prohibition
                  / "Requested-Delivery-Method" ":"
                                  1*( labelled-integer )
                  / "Delivery-Date" ":" date-time
                  / "Discarded-X400-MTS-Extensions" ":"
                                   1#( oid / labelled-integer )

        prohibition     = "Prohibited" / "Allowed"

        mts-msg-id       = "[" global-id ";" *text "]"

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

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

        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
ToP   noToC   RFC1327 - Page 100
        ipn-discarded = "was discarded for the following reason:"
                        discard-reason <CRLF>

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

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

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

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

        discard-reason     = "Expired" / "Obsoleted" /
                                "User Subscription Terminated"

        acknowledgement-mode = "Manually" / "Automatically"

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

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

        sensitivity     = "Personal" / "Private" /

        language        = 2*ALPHA [ language-description ]
ToP   noToC   RFC1327 - Page 101
        language-description = printable-string

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

        redirect-comment  =
                 [ "Originally To:" ] mailbox "Redirected"
                 [ "Again" ] "on" date-time
                 "To:"  redirection-reason

        redirection-reason =
                 "Recipient Assigned Alternate Recipient"
                 / "Originator Requested Alternate Recipient"
                 / "Recipient MD Assigned Alternate Recipient"

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

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

        destination   = mailbox / "MTA" word

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

Appendix F - Format of address mapping tables

   1.  Global Mapping Information

      The consistent operation of gateways which follow this
      specification relies of the existence of three globally defined

      1.   Domain Name Space -> O/R Address Space

      2.   O/R Address Space -> Domain Name Space

      3.   Domain Name Space -> O/R Address of preferred gateway
ToP   noToC   RFC1327 - Page 102
      All gateways conforming to this specification shall have access to
      these mappings.  The gateway may use standardised or private
      mechanisms to access this mapping information.

      One means of distributing this information is in three files.
      This appendix defines a format for these files.  Other
      standardised mechanisms to distribute the mapping information are
      expected.  In particular, mechanisms for using the Domain Name
      Scheme, and X.500 are planned.

      The definition of  global mapping information is being co-
      ordinated by the COSINE-MHS project, on behalf of the Internet and
      other X.400 and RFC 822 users.  For information on accessing this
      information contact:

           COSINE MHS Project Team
           Weinbergstrasse 18
           8001 Zuerich

           tel: +41 1 262 3143
           fax: +41 1 262 3151

   2.  Syntax Definitions

      An address syntax is defined, which is compatible with the syntax
      used for  By representing the O/R addresses as
      domains, all lookups can be mechanically implemented as domain ->
      domain mappings.  This syntax defined is initially for use in
      table format, but the syntax is defined in a manner which makes it
      suitable to be adapted for  use with the  Domain Name Service.
      This syntax allows for a general representation of O/R addresses,
      so that it can be used in other applications.  Not all attributes
      are used in the table formats defined.

      To allow the mapping of null attributes  to be represented, the
      pseudo-value "@" (not a printable string character) is used to
      indicate omission of a level in the hierarchy.  This is distinct
      from the form including the element with no value, although a
      correct X.400 implementation will interpret both in the same
ToP   noToC   RFC1327 - Page 103
      This syntax is not intended to be handled by users.

              dmn-or-address  = dmn-part *( "." dmn-part )
              dmn-part        = attribute "$" value
              attribute       = standard-type
                              / "~" dmn-printablestring
              value           = dmn-printablestring
                              / "@"
              dmn-printablestring =
                              = *( dmn-char / dmn-pair )
              dmn-char        = <"{", "}", "*", and any ps-char
                                                      except ".">
              dmn-pair        = "\."

      An example usage:


      The first example illustrates quoting of a ".", and the second
      omission of the ADMD level. There must be a strict ordering of all
      components in this table, with the most significant components on
      the RHS.   This allows the encoding to be treated as a domain.

      Various further restrictions are placed on the usage of dmn-or-
      address in the address space mapping tables.

      1.   Only C, ADMD, PRMD, O, and up to four OUs may be used.

      2.   No components shall be omitted from this hierarchy, although
           the hierarchy may terminate at any level.  If the mapping is
           to an omitted component, the "@" syntax is used.

   3.  Table Lookups

      When determining a match, there are aspects which apply to all
      lookups.  Matches are always case independent. The key for all
      three  tables is a domain. The longest possible match shall be
      obtained.  Suppose the table has two entries with the following


      Domain "A.B.C" will not return any matches.  Domain "I.J.K.L" will
      match the entry "J.K.L:.
ToP   noToC   RFC1327 - Page 104
   4.  Domain -> O/R Address format

      The BNF is:

              domain-syntax "#" dmn-or-address "#"

      Note that the trailing "#" is used for clarity, as the dmn-or-
      address syntax might lead to values with trailing blanks.  Lines
      staring with "#" are comments.

              For example:
              AC.UK#PRMD$UK\.AC.ADMD$GOLD 400.C$GB#

      A domain is looked up to determine the top levels of an O/R
      Address.  Components of the domain which are not matched are used
      to build the remainder of the O/R address, as described in Section

   5.  O/R Address -> Domain format

      The syntax of this table is:

              dmn-or-address "#" domain-syntax "#"

              For example:

              # Mapping table
              PRMD$UK\.AC.ADMD$GOLD 400.C$GB#AC.UK#

      The O/R Address is used to generate a domain key.  It is important
      to order the components correctly, and to fill in missing
      components in the hierarchy.  Use of this mapping is described in
      Section 4.3.2.

   6.  Domain -> O/R Address of Gateway table

      This uses the same format as the domain -> O/R address mapping.
      In this case, the two restrictions (omitted components and
      restrictions on components) do not apply.  Use of this mapping is
      described in Section 4.3.4.
ToP   noToC   RFC1327 - Page 105
Appendix G - Mapping with X.400(1984)

   This appendix defines modification 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.  One feature is used at the IPMS level, and this must be
   replaced by the RFC 987 approach.  All header information which would
   usually be mapped into the rfc-822-heading-list extension, together
   with any Comments: field in the RFC 822 header 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

   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 must 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 should be treated as an RFC 822
   address, which will usually lead to encoding as a DDA "RFC-822".

   It is possible that null attributes may be present in an O/R Address.
   This is not legal in 1988, except for ADMD where the case is
   explicitly described in Section 4.3.5.  Null attributes are
   deprecated (the attribute should be omitted), and should 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=/).

   If a non-Teletex Common Name (CN) is present, it should be mapped
   onto a Domain Defined Attribute "Common".  This is in line with RFC
   1328 on X.400 1988 to 1984 downgrading [Hardcastle-K92].
ToP   noToC   RFC1327 - Page 106
Appendix H - 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 acccess 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
            / "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 Content-Return allow
   for override of the default settings for MTS.PerMessageIndicators.

Appendix I - Conformance

   This appendix defines a number of options, which a conforming gateway
   should specify.  Conformance to this specification shall not be
   claimed if any of the mandatory features are not implemented.  In

   -    Formats for all fields shall be followed.

   -    Formats for subject lines, delivery reports and IPNs shall
        be followed.   A system which followed the syntax, but
        translated text into a language other than english would be

   -    RFC 1137 shall not be followed when mapping to SMTP or to
        JNT Mail

   -    All mappings of trace shall be implemented.

   -    There must be a mechanism to access all three global

   A gateway should specify:
ToP   noToC   RFC1327 - Page 107
   -    Which 822-MTS protocols are supported.  The relevant
        appendices must be followed to claim support of a given
        protocol: SMTP (A); JNT Mail (B); UUCP (C).

   -    Which X.400 versions  are supported (84 and/or 88).

   -    The means by which it can access the global mappings.
        Currently, the tables of the formats define in  Appendix F
        is the only means available.

   -    The approach taken when upper bounds are exceeded at the IPM
        level  (5.1.3)

   -    The approach taken to return of contents (5.2)

   -    The approach taken to body parts which cannot be converted

   -    The approach taken to multiple copies vs non-disclosure

   The following are optional parts of this specification.  A conforming
   implementation should specify which of these it supports.

   -    Generation of extended RFC 822 fields is mandatory.
        Optionally, they may be parsed and mapped back to X.400.  A
        gateway should should indicate if this is done.

   -    Support for the extension mappings of Appendix H.

   -    Support for returning illegal format content in a delivery

   -    Which address interpretation heuristics are supported

   -    If RFC 987 generated message ids are handled in a backwards
        compatible manner (

Appendix J - Change History: RFC 987, 1026, 1138, 1148

   RFC 987 was the original document, and contained the key elements of
   this specification.  It was specific to X.400(1984).  RFC 1026
   specified a small number of necessary changes to RFC 987.

   RFC 1138 was based on the RFC 987 work.  It contained an editorial
   error, and was reissued a few months later as RFC 1148.  RFC 1148
   will be referred to here, as it is the document which is widely
ToP   noToC   RFC1327 - Page 108
   referred to elsewhere. The major goal of RFC 1148 was to upgrade RFC
   987 to X.400(1988).  It did this, but did not obsolete RFC 987, which
   was recommended for use with X.400(1984).  This appendix summarises
   the changes made in going from RFC 987 to RFC 1148.

   RFC 1148 noted the following about its upgrade from RFC 987:
   Unnecessary change is usually a bad idea.  Changes on the RFC 822
   side are avoided as far as possible,  so that RFC 822 users do not
   see arbitrary differences between systems conforming to this
   specification, and those following RFC 987.  Changes on the X.400
   side are minimised, but are more  acceptable, due to the mapping onto
   a new set of services and protocols.

   1.  Introduction

      The model has shifted from a protocol based mapping to a service
      based mapping.  This has increased the generality of the
      specification, and improved the model.  This change affects the
      entire document.

      A restriction on scope has been added.

   2.  Service Elements

      -    The new service elements of X.400 are dealt with.

      -    A clear distinction is made between origination and

   3.  Basic Mappings

      -    Add teletex support

      -    Add object identifier support

      -    Add labelled integer support

      -    Make PrintableString <-> ASCII mapping reversible

      -    The printable string mapping is aligned to the NBS mapping
           derived from RFC 987.

   4.  Addressing

      -    Support for new addressing attributes

      -    The message ID mapping is changed to not be table driven
ToP   noToC   RFC1327 - Page 109
   5.  Detailed Mappings

      -    Define extended IPM Header, and use instead of second body
           part for RFC 822 extensions

      -    Realignment of element names

      -    New syntax for reports, simplifying the header and
           introducing a mandatory body format (the RFC 987 header
           format was unusable)

      -    Drop complex autoforwarded mapping

      -    Add full mapping for IP Notifications, defining a body

      -    Adopt an MTS Identifier syntax in line with the O/R Address

      -    A new format for X400 Trace representation on the RFC 822

   6.  Appendices

      -    Move Appendix on restricted 822 mappings to a separate RFC

      -    Delete Phonenet and SMTP Appendixes

Appendix K - Change History: RFC 1148 to this Document

   1.  General

      -    The scope of the document was changed to cover X.400(1984),
           and so obsolete RFC 987.

      -    Changes were made to allow usage to connect RFC 822 networks
           using X.400

      -    Text was tightened to be clear about optional and mandatory

      -    A good deal of clarification

      -    A number of minor EBNF errors

      -    Better examples are given

      -    Further X.400 upper bounds are handled correctly
ToP   noToC   RFC1327 - Page 110
   2.  Basic Mappings

      -    The encoding of object identifier is changed slightly

   3.  Addressing

      -    A global mapping of domain to preferred gateway is

      -    An overflow mechanism is defined for RFC 822 addresses of
           greater than 128 bytes.

      -    Changes were made to improve compatability with the PDAM on
           writing O/R Addresses.

      +         The PD and Terminal Type keywords were aligned to the
                PDAM.  It is believed that minimal use has been made of
                the RFC 1148 keywords.

      +         P and A are allowed as alternate keys for PRMD and ADMD

      +         Where keywords are different, the PDAM keywords are
                alternatives on input.  This is mandatory.

   4.  Detailed Mappings

      -    The format of the Subject: lines is defined.

      -    Illegal use (repetition) of the heading EXTENSION is
           corrected, and a new object identifier assigned.

      -    The Delivery Report format is extensively revised in light
           of operational experience.

      -    The handling of redirects is significantly changed, as the
           previous mechanism did not work.

   5.  Appendices

      -    An SMTP appendix is added, allowing optional use of the VRFY
           command to improve probe information.

      -    Handling of JNT Mail Acknowledge-To is changed slightly.

      -    A DDA JNT-MAIL is allowed on input.

      -    The format definitions of Appendix F are explained further,
           and a third table definition added.
ToP   noToC   RFC1327 - Page 111
      -    An appendix on use with X.400(1984) is added.

      -    Optional extensions are defined to give RFC 822 access to
           further X.400 facilities.

      -    An appendix on conformance is added.


           CCITT, "CCITT Recommendations X.408," Message Handling
           Systems: Encoded Information Type Conversion Rules, December

           CCITT/ISO, "CCITT Recommendations X.400/ ISO IS 10021-1,"
           Message Handling: System and Service Overview , December

           CCITT/ISO, "CCITT Recommendations X.420/ ISO IS 10021-7,"
           Message Handling Systems: Interpersonal Messaging System,
           December 1988.

           CCITT/ISO, "CCITT Recommendations X.411/ ISO IS 10021-4,"
           Message Handling Systems: Message Transfer System: Abstract
           Service Definition and Procedures, December 1988.

           CCITT/ISO, "Specification of Abstract Syntax Notation One
           (ASN.1)," CCITT Recommendation X.208 / ISO IS 8824, December

           CCITT/ISO, "Representation of O/R Addresses for Human
           Usage," PDAM to CCITT X.401 / ISO/IEC 10021-2, February

           Crocker, D., "Standard of the Format of ARPA Internet Text
           Messages," RFC 822, UDEL, August 1982.

           Hardcastle-Kille, S., "X.400 1988 to 1984 downgrading," RFC
           1328, UCL, May 1992.
ToP   noToC   RFC1327 - Page 112
           Horton, M., "UUCP Mail Interchange Format Standard," RFC
           976, February 1986.

           Kille, S., "Gatewaying between RFC 822 and JNT Mail," JNT
           Mailgroup Note 15, May 1984.

           Kille, S., (Editor), JNT Mail Protocol (revision 1.0), Joint
           Network Team, Rutherford Appleton Laboratory, March 1984.

           Kille, S., "Mapping Between X.400 and RFC 822," UK Academic
           Community Report (MG.19) / RFC 987, June 1986.

           Kille, S., "Addendum to RFC 987," UK Academic Community
           Report (MG.23) / RFC 1026, August 1987.

           Kille, S., "A String Encoding of Presentation Address," UCL
           Research Note 89/14, March 1989.

           Kille, S., "Mapping between full RFC 822 and RFC 822 with
           restricted encoding," RFC 1137, October 1989.

           Kille, S., "Mapping Between X.400(1988) / ISO 10021 and RFC
           822," RFC 1148, March 1990.

           Larmouth, J., "JNT Name Registration Technical Guide,"
           Salford University Computer Centre, April 1983.

           Postel J., and J. Reynolds, "Domain Requirements," RFC 920,
           USC/Information Sciences Institute, October 1984.

           Postel, J., "Simple Mail Transfer Protocol", RFC 821,
           USC/Information Sciences Institute, August 1982.

           Rose M., and E. Stefferud, "Proposed Standard for Message
           Encapsulation," RFC 934, January 1985.
ToP   noToC   RFC1327 - Page 113
           CEN/CENELEC/Information Technology/Working Group on Private
           Message Handling Systems, "FUNCTIONAL STANDARD A/3222,"
           CEN/CLC/IT/WG/PMHS N 17, October 1985.


   Security issues are not discussed in this memo.


   Steve Hardcastle-Kille
   Department of Computer Science
   University College London
   Gower Street
   WC1E 6BT

   Phone: +44-71-380-7294
   EMail: S.Kille@CS.UCL.AC.UK