🚀 go-pugleaf

[ Here is another list extracted from RFC-1327 - sdm ]

RFC 1327        Mapping between X.400(1988) and RFC 822         May 1992

2.2.  RFC 822

   RFC 822 does not explicitly define service elements, as distinct from
   protocol elements.  However, all of the RFC 822 header fields, with
   the exception of trace, can be regarded as corresponding to implicit
   RFC 822 service elements.

2.2.1.  Origination in RFC 822

   A mechanism of mapping, used in several cases, is to map the RFC 822
   header into a heading extension in the IPM (InterPersonal Message).
   This can be regarded as partial support, as it makes the information
   available to any X.400 implementations which are interested in these
   services. Communities which require significant RFC 822 interworking
   are recommended to require that their X.400 User Agents are able to
   display these heading extensions.  Support for the various service
   elements (headers) is now listed.

   Date:
        Supported.

   From:
        Supported.  For messages where there is also a sender field,
        the mapping is to "Authorising Users Indication", which has
        subtly different semantics to the general RFC 822 usage of
        From:.

   Sender:
        Supported.

   Reply-To:
        Supported.

   To:  Supported.

   Cc:  Supported.

   Bcc: Supported.

   Message-Id:
        Supported.

   In-Reply-To:
        Supported, for a single reference.  Where multiple
        references are given, partial support is given by mapping to
        "Cross Referencing Indication".  This gives similar
        semantics.

   References:
        Supported.

   Keywords:
        Supported by use of a heading extension.

   Subject:
        Supported.

   Comments:
        Supported by use of an extra body part.


   Encrypted:
        Supported by use of a heading extension.

   Resent-*
        Supported by use of a heading extension.  Note that
        addresses in these fields are mapped onto text, and so are
        not accessible to the X.400 user as addresses.  In
        principle, fuller support would be possible by mapping onto
        a forwarded IP Message, but this is not suggested.

   Other Fields
        In particular X-* fields, and "illegal" fields in common
        usage (e.g., "Fruit-of-the-day:") are supported by use of
        heading extensions.

2.2.2.  Reception by RFC 822

   This considers reception by an RFC 822 User Agent of a message
   originated in an X.400 system and transferred across a gateway.  The
   following standard services (headers) may be present in such a
   message:

   Date:

   From:

   Sender:

   Reply-To:

   To:

   Cc:

   Bcc:

   Message-Id:

   In-Reply-To:

   References:

   Subject:

   The following non-standard services (headers) may be present.  These
   are defined in more detail in Chapter 5 (5.3.4, 5.3.6, 5.3.7):

   Autoforwarded:

   Content-Identifier:

   Conversion:

   Conversion-With-Loss:

   Delivery-Date:

   Discarded-X400-IPMS-Extensions:

   Discarded-X400-MTS-Extensions:

   DL-Expansion-History:

   Deferred-Delivery:

   Expiry-Date:

   Importance:

   Incomplete-Copy:

   Language:

   Latest-Delivery-Time:

   Message-Type:

   Obsoletes:

   Original-Encoded-Information-Types:

   Originator-Return-Address:

   Priority:

   Reply-By:

   Requested-Delivery-Method:

   Sensitivity:

   X400-Content-Type:

   X400-MTS-Identifier:

   X400-Originator:

   X400-Received:

   X400-Recipients: