RFC 987

Mapping between X.400 and RFC 822

📅 published June 1986, from ietf

RFC 987: Mapping between X.400 and RFC 822 💌✨

  • RFC number: 987
  • Title: Mapping between X.400 and RFC 822
  • Author: S.E. Kille, University College London 🎓
  • Series: UCL Technical Report 120, Mailgroup Note 19
  • Working group: Network Working Group
  • Date: June 1986 📅
  • Status: a proposed protocol for the ARPA-Internet community 🦋
  • Obsoletes / Updates: neither is listed in this header

Status of This Memo 💜

okay so this RFC is basically a proposal for the ARPA-Internet crowd, and it's literally asking everyone to talk about it and suggest fixes 🫶 Distribution is unlimited, so share it with your whole group chat.

This doc describes a set of mappings so that systems running the CCITT X.400 (1984) protocols 🌸 [CCITT84a] can talk to systems using RFC 822 mail, or protocols built on RFC 822 [Crocker82a]. The goal is to keep as many services working across the boundary as possible, without making the mappings super complicated. And nothing has to change on the end systems, which is iconic 💅

Use this spec when the mapping happens on the ARPA-Internet or in the UK Academic Community. It might get tweaked based on what people learn from implementing it, but no big changes are expected ✨

Chapter 1 -- Overview 🎀

1.1. X.400 🧚

so X.400 is CCITT's thing, defined to give us an Interpersonal Messaging Service (IPMS) that runs on top of a store and forward Message Transfer Service. It's expected to get implemented everywhere 😭 Besides the base standard (X.400), people are also working on functional standards and profiles that explain how X.400 gets used in different communities. Lots of the big ones (CEPT, CEN/CENELEC, and NBS) are likely to look similar. Some choices in this document are based on that work. No reference is given, because those docs aren't stable yet 🙈

1.2. RFC 822 💖

RFC 822 started out as a messaging standard on the DARPA (the US Defense Advanced Research Projects Agency) Internet. It's currently used on the ARPA-Internet alongside two other standards: RFC 821, also known as Simple Mail Transfer Protocol (SMTP) [Postel82a], and RFC 920, a spec for a domain name system and a distributed name service [Postel84a]. RFC 822, or protocols derived from it, also show up in a bunch of other networks. Specifically:

  • UUCP Networks 🍓 UUCP is the UNIX to UNIX CoPy protocol <0>, usually used over dialup telephone networks for a simple message transfer mechanism. There are some extensions to RFC 822, especially in the addressing. They're likely to use domains that conform to RFC 920, but not the corresponding domain nameservers [Horton86a].
  • CSNET 🌈 Some portions of CSNET will follow the ARPA-Internet protocols. The dialup portion of CSNET uses the Phonenet protocols as a replacement for RFC 821. This portion is likely to use domains that conform to RFC 920, but not the corresponding domain nameservers.
  • BITNET 🦋 Some parts of BITNET use RFC 822 related protocols, with EBCDIC encoding.
  • JNT Mail Networks 👑 A bunch of X.25 networks, especially the ones tied to the UK Academic Community, use the JNT (Joint Network Team) Mail Protocol, also known as Greybook [Kille84a]. This is used with domains and name service specified by the JNT NRS (Name Registration Scheme) [Larmouth83a].

The mappings in this specification are appropriate for all of these networks ✨

1.3. The Need for Conversion 💌

There's a huge community using RFC 822 based protocols for mail, and they're going to want to talk to X.400 systems. That's a requirement, even for communities that plan to move over to X.400, because conversion is needed to make the switch smooth 🫶 More than one gateway <1> is expected, and this specification helps them all behave in a consistent way. Gateways are sometimes called mail relays. Consistency between gateways is desirable because it gives you:

  1. Consistent service to users.
  2. The best service in cases where a message passes through multiple gateways.

1.4. General Approach 🔥

The details of this specification are built on a few basic principles:

  1. The specification should be pragmatic. There should not be a requirement for complex mappings for 'Academic' reasons. Complex mappings should not be required to support trivial additional functionality.
  2. Subject to 1), functionality across a gateway should be as high as possible.
  3. It is always a bad idea to lose information as a result of any transformation. Hence, it is a bad idea for a gateway to discard information in the objects it processes. This includes requested services which cannot be fully mapped.
  4. All mail gateways actually operate at exactly one level above the layer on which they conceptually operate. This implies that the gateway must not only be cognisant of the semantics of objects at the gateway level, but also be cognisant of higher level semantics. If meaningful transformation of the objects that the gateway operates on is to occur, then the gateway needs to understand more than the objects themselves.

1.5. Gatewaying Model 🧩

1.5.1. X.400 🌸

The CCITT X.400 series recommendations specify a number of services and protocols. The services are specified in X.400. Two of these services are fundamental to this document:

  1. The Message Transfer Service, which can be provided by either the P1 or P3 protocols, which are specified in X.411 [CCITT84b]. This document talks in terms of P1, but the mappings are equally applicable to P3.
  2. The Interpersonal Messaging Service (IPMS), which is provided by the P2 protocol specified in X.420 [CCITT84c].

This document considers only IPMS, not any other usage of the Message Transfer Service. That's reasonable, because RFC 822, broadly speaking, provides a service corresponding to IPMS, and no services other than IPMS have been defined over the Message Transfer Service. None of the RTS (Reliable Transfer Service) service elements is available to the IPMS user, so this level and the lower levels are of no concern in this gatewaying specification. Note that in this memo "IP" means "InterPersonal" (not Internet Protocol) 🙈

The Message Transfer Service defines an end-to-end service over a series of Message Transfer Agents (MTA). It also defines a protocol, P1, which is used between a pair of MTAs. This protocol is simply a file format (Message Protocol Data Unit, or MPDU), transferred between two MTAs using the RTS. There are three types of MPDU:

  • User MPDU 💖 This contains envelope information and uninterpreted contents. The envelope includes an ID, an originator, a list of recipients, and trace information. It's used to carry data for higher level services.
  • Probe 🦋 This contains only envelope information. It's used to determine whether a User UMPDU could be delivered to a given O/R (originator/recipient) name.
  • Delivery Report ✨ This contains envelope information and specified contents. It's used to indicate delivery success or failure of a User or Probe MPDU over the Message Transfer Service.

IPMS (P2) specifies two content types for the P1 User MPDU (User Agent Protocol Data Units or UAPDU):

  • Interpersonal Message (IM-UAPDU) 💌 This has two components: a heading and a body. The body is structured as a sequence of body parts, which may be basic components (e.g. IA5 text, or G3 fax), or IP Messages. The header contains end to end user information, such as subject, primary recipients (To:), and priority. The validity of these fields is not guaranteed by the Message Transfer Service. This provides the basic IPMS.
  • Status Report (SR-UAPDU) 🌈 This UAPDU has defined contents. It's used to indicate that a message has been received by a User Agent. It does not have to be implemented.

1.5.2. RFC 822 🍓

RFC 822 is based on the assumption that there's an underlying service, called here the 822-P1 service. The 822-P1 service provides three basic functions:

  1. Identification of a list of recipients.
  2. Identification of an error return address.
  3. Transfer of an RFC 822 message.

It's possible to achieve 2) within the RFC 822 header. Some 822-P1 protocols, in particular SMTP, can provide additional functionality, but since these are neither mandatory in SMTP nor available in other 822-P1 protocols, they aren't considered here. Details of aspects specific to a number of 822-P1 protocols are given in appendices B to E. An RFC 822 message consists of a header and content, which is uninterpreted ASCII text. The header is divided into fields, which are the protocol elements. Most of these fields are analogous to P2 header elements, although some are analogous to P1 envelope elements 🫶

1.5.3. The Gateway 👑

Now that we have a functional description of both protocols, we can think about what a gateway actually does. It would be elegant to map the 822-P1 service onto P1 and RFC 822 onto P2, but reality just doesn't fit like that 😭 So one has to accept that P1 (or P1 + P2) on one side gets mapped into RFC 822 + 822-P1 on the other side in a slightly tangled way. The details of the tangle will be made clear in chapter 5. The following basic mappings are proposed:

  • When going from RFC 822 to X.400, an RFC 822 message and its associated 822-P1 information are always mapped into an IM-UAPDU and the associated P1 envelope.
  • Going from X.400 to RFC 822, an RFC 822 message and its associated 822-P1 information may be derived from:
    1. A Delivery Report MPDU
    2. An SR-UAPDU and the associated P1 envelope.
    3. An IM-UAPDU and the associated P1 envelope.

Probe MPDUs must be processed by the gateway, which is discussed in chapter 5. Any other User MPDUs are not mapped by the gateway, and should be rejected at the gateway 💅

1.6. Document Structure 🧚

This document has five chapters:

  1. Overview - this document.
  2. Service Elements - This describes the (end user) services mapped by a gateway. 💖
  3. Basic mappings: This is the part where we get our notation sorted. It covers the basic notation used in chapters 3-5, the mappings between character sets, and some fundamental protocol elements. 🧚
  4. Addressing: This one looks at how X.400 O/R names map onto RFC 822 addresses. It's a fundamental gateway component, so it's kind of the main event. 💅
  5. Protocol Elements: This covers the details of all the other mappings. 📝

There are also six appendices, and they're giving bonus material:

  • A. Quoted String Encodings. 🎀
  • B. Mappings Specific to JNT Mail. 💌
  • C. Mappings Specific to Internet Mail. 🌐
  • D. Mappings Specific to Phonenet Mail. 📞
  • E. Mappings Specific to UUCP Mail. 🐚
  • F. Format of Address Tables. 🗂️

1.7. Acknowledgements ✨

This document is super eclectic, so it's only fair to credit everyone who helped put it together. 🫶

  • We studied the EAN X.400 system code, which performs this function [Neufeld85a]. The DFN report on EAN [Bonacker85a] added some detailed clarification.
  • An unpublished ICL report looked at a subset of the problem [ICL84a]. 🕵️
  • A document by Marshall Rose [Rose85a]. 📄
  • A document by Mark Horton [Horton85a]. The string encodings of chapter 3 came straight from this work, and so does a lot of chapter 4. 🙌
  • Discussion on a number of electronic mailing lists. 💬
  • Meetings in the UK and the US. ✈️

Chapter 2 -- Service Elements 🎀

RFC 822 and X.400 both offer a bunch of services to the end user. This document describes how far each service can be supported across an X.400 <-> RFC 822 gateway. The cases considered are single transfers across such a gateway, although the problems of multiple crossings get called out where they matter. ✨

So what does it mean when a service element is described as supported? Basically, when a message originator specifies this element for a recipient behind a gateway, the gateway maps it so the service implied by the element still gets provided. For example, if an RFC 822 originator sets a Subject: field, that counts as supported, because an X.400 recipient will get a subject indication. 💖 Support implies:

  • Semantic correspondence. 🤝
  • No loss of information. 🧠
  • Any actions required by the service element. ⚡

For some services, the protocol elements line up nicely, so the service can be fully provided. 🌈 In other cases, the service just can't be provided, because there's a complete mismatch. 💀 And in the remaining cases, the service can be partially fulfilled. The level of partial support is summarised below.

NOTE: It should be clear that support of service elements on reception is not a gatewaying issue. It is assumed that all outbound messages are fully conforming to the appropriate standards. 👀

2.1. RFC 822 🌸

RFC 822 doesn't explicitly define service elements separately from protocol elements, but that's fine, we can work with it. 🧚 All of the RFC 822 header fields, except trace, can be regarded as corresponding to implicit RFC 822 service elements. One mapping trick used in several cases is to put the text of the header into the body of the IP Message. This can usually be regarded as partial support, since it gets the information to the end user even though there's no matching X.400 protocol element. Here's how each service element (header) shakes out:

Date: Supported. 📅

From: Supported. When a message also has a sender field, the mapping goes to "Authorising Addresses", which has subtly different semantics from 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 in msg-id form. Other cases are passed in the message text. 💬

References: Supported. 🔗

Keywords: Passed in the message text. 🏷️

Subject: Supported. 💅

Comments: Passed in the message text. 🗨️

Encrypted: Passed in the message text. This may not be very useful, bestie. 🙈

Resent-* Passed in the message text. In principle these could be supported in a fuller manner, but that's not suggested. 🤷‍♀️

Other Fields In particular X-* fields, and "illegal" fields in common usage (e.g. Fruit-of-the-day:), are passed in the message text. 🍓 Iconic behaviour, honestly.

2.2. X.400 👑

When mapping from X.400 to RFC 822, the plan is not to map any elements into the body of an RFC 822 message. Instead, new RFC 822 headers get defined. These fields are intended to be registered, so that cooperating RFC 822 systems can use them. Where these new fields are used and no system action is implied, the service can be regarded as almost supported. Chapter 5 describes how to map these new headers in both directions. 🔄 Other elements are provided, in part, by the gateway, since they can't be provided by RFC 822 itself.

Some service elements are marked N/A (not applicable). These elements only apply to User Agent / Message Transfer Agent interaction and have no end-to-end implication, so the gateway doesn't need to map them. 🙅‍♀️

2.2.1. Message Transfer Service Elements 📬

Access Management N/A. 🚪

Content Type Indication Not mapped. Since it can only have one value (P2), there's not much point in creating a new RFC 822 header field for it, unless it's used to distinguish delivery reports. 🤏

Converted Indication Supported by a new RFC 822 header. ✨

Delivery Time Stamp Indication N/A. ⏰

Message Identification Supported, by use of a new RFC 822 header. This new header is required, because X.400 has two message-ids whereas RFC 822 has only one. 🆔👯

Non-delivery Notification Not supported. In general, though, an RFC 822 system will return errors as IP messages. Other elements treat this pragmatic result as effective support of this service element. 💌

Original Encoded Information Types Indication Supported as a new RFC 822 header. 🏷️

Registered Encoded Information Types N/A. 📚

Submission Time Stamp Indication Supported. 🕰️

Alternate Recipient Allowed Not supported. Any value is ignored by the gateway. 🙃

Deferred Delivery Support is optional. The framework is provided so that messages may be held at the gateway. However, a gateway following this specification does not have to do this. This is in line with the emerging functional standards. 🌙

Deferred Delivery Cancellation Supported. 🛑

Delivery Notification Supported at the gateway. So a notification is sent by the gateway to the originator <2>. 📨

Disclosure of Other Recipients Supported by use of a new RFC 822 header. 👀

Grade of Delivery Selection Supported as a new RFC 822 header. In general, this will only be for user information in the RFC 822 world. 🎚️

Multi-Destination Delivery Supported. 📣

Prevention of Non-delivery Notification Not supported, as there's no control over this in the RFC 822 world (but see Non-delivery Notification). 🙅

Return of Contents This is normally the case, although the user has no control over it (but see Non-delivery Notification). 📦

Conversion Prohibition Supported. Note that in practice this support is restricted by the nature of the gateway. 🚧

Explicit Conversion Supported, for appropriate values (see the IPMS Typed Body service element). 🔁

Implicit Conversion Supported, in the sense that there will be implicit conversion to IA5 in cases where this is practical. 🪄

Probe Supported at the gateway (i.e. the gateway services the probe). 🔍

Alternate Recipient Assignment N/A. 🎁

Hold for Delivery N/A. ✋

2.2.2. Interpersonal Message Service Elements 💜

IP-message Identification Supported. 🪪

Typed Body Supported. IA5 is fully supported. ForwardedIPMessage is supported, with some loss of information. A subset of TTX is supported (see section 5 for the specification of this subset), also with some loss of information. SFD may be supported, with some loss of information. TTX and SFD are only supported when conversion is allowed. Other types are not supported. 🧩

Blind Copy Recipient Indication Supported. 🙊

Non-receipt Notification Not supported. 🙅‍♀️

Receipt Notification Not supported. 🧾

Auto-forwarded Indication Supported as a new RFC 822 header. ↪️

Originator Indication Supported. ✍️

Authorising User's Indication Supported, although the mapping (From:) is not quite the same. 🫡

Primary and Copy Recipients Indication Supported. 🎀

Expiry Date Indication Supported as a new RFC 822 header. In general, only human action can be expected here. ⌛

Cross Referencing Indication Supported. 🔀

Importance Indication Supported as a new RFC 822 header. 🚨

Obsoleting Indication Supported as a new RFC 822 header. 🗑️

Sensitivity Indication Supported as a new RFC 822 header. 🤫

Subject Indication Supported. 💖

Reply Request Indication Supported as a comment next to the address. 💬

Forwarded IP-message Indication Supported, with some loss of information. 🔂

Body Part Encryption Indication Not supported. 🔐

Multi-part Body Supported, with some loss of information, because the structuring can't be formalised in RFC 822. 🧱

Chapter 3 -- Basic Mappings ✨

3.1. Notation 🧩

P1 and P2 are encoded in a structured way, following X.409, but RFC 822 is plain text. So if you want a detailed mapping, you have to point at specific protocol elements in each format. That's what this bit is for 💖

3.1.4. RFC 822

Structured text is defined with the Extended Backus Naur Form (EBNF) from section 2 of RFC 822 [Crocker82a]. For the EBNF in this spec, the syntax rules in Appendix D of RFC 822 are assumed 🎀 When these EBNF tokens show up outside an EBNF definition, they get the string "882." stuck on the front (e.g. 822.addr-spec). Extra syntax rules that get used all through this spec are defined in this chapter, so keep your eyes peeled ✨

The EBNF gets used in two ways 👀

  1. To describe the parts of RFC 822 messages (or of 822-P1 components). For this, the lexical analysis from section 3 of RFC 822 should be used. When these new EBNF tokens get referred to outside an EBNF definition, they're marked with the string "EBNF." on the front (e.g. EBNF.bilateral-info).
  2. To describe the structure of IA5 or ASCII info that isn't inside an RFC 822 message. In these cases the tokens will either be self delimiting, or be delimited by self delimiting tokens. Comments and LWSP don't count as delimiters 🫶

3.1.5. X.409

An element is referred to with the following syntax, which is defined in EBNF 🧚

element        = protocol "." definition *( "." definition )
protocol       = "P1" / "P2"
definition     = identifier / context
identifier     = ALPHA *< ALPHA or DIGIT or "-" >
context        = "[" 1*DIGIT "]"

For example, P2.Heading.subject is the subject element of the P2 heading 💅 The same syntax also gets used for element values. For example, P1.EncodedInformationTypes.[0].g3Fax refers to a value of P1.EncodedInformationTypes.[0] 🌸

3.2. ASCII and IA5 🦋

A gateway will interpret all IA5 as ASCII. So for the rest of this document, they're treated the exact same way, no cap 💜

3.3. Universal Primitives 🍓

There's a need to convert between ASCII text and some of the Universal Primitive types defined in X.409 [CCITT84d]. For each case, there's an EBNF syntax definition that gets used across this whole spec. All EBNF syntax definitions of Universal Primitives are lower case, while X.409 primitives get referred to with the first letter capitalised. Except where it's noted, every mapping is symmetrical ✨

3.3.1. Boolean

Boolean is encoded as:

boolean = "TRUE" / "FALSE"

3.3.2. NumericString

NumericString is encoded as:

numericstring = *DIGIT

3.3.3. PrintableString

PrintableString is a restricted IA5String, defined as:

printablestring  = *( ps-char / ps-delim )

ps-char          = 1DIGIT /  1ALPHA / " " / "'" / "+" / ")"
                   / "," / "-" / "." / "/" / ":" / "=" / "?"

ps-delim         = "("

A structured subset of EBNF.printablestring is defined next. It can be used to encode ASCII in the PrintableString character set, so this part is kind of the main event 🔥

ps-encoded       = *( ps-char / ps-encoded-char )

ps-encoded-char  =   "(a)"               ; (@)
                   / "(p)"               ; (%)
                   / "(b)"               ; (!)
                   / "(q)"               ; (")
                   / "(u)"               ; (_)
                   / "(" 3DIGIT ")"

The 822.3DIGIT in EBNF.ps-encoded-char must have range 0-127 (Decimal), and it's read in decimal as the matching ASCII character. There are special encodings for the at sign (@), percent (%), exclamation mark/bang (!), double quote ("), and underscore (_). These characters aren't in PrintableString, but they show up all the time in RFC 822 addresses, so they get their own abbreviations. That makes it way easier to write RFC 822 addresses coming from an X.400 system 💖

Now, an asymmetric mapping between PrintableString and ASCII can be defined <3>. To encode ASCII as PrintableString, the EBNF.ps-encoded syntax is used, with all EBNF.ps-char AND EBNF.ps-delim mapped directly <4>. Every other 822.CHAR gets encoded as EBNF.ps-encoded-char. There are two cases for decoding PrintableString back into ASCII. If the PrintableString can be parsed as EBNF.ps-encoded, then the previous mapping should be reversed. If it can't, it should be read as EBNF.printablestring 🙈

Here are some examples. Look at the arrows, because they show the asymmetrical mappings:

PrintableString           ASCII

'a demo.'         <->   'a demo.'
foo(a)bar         <->   foo@bar

(q)(u)(p)(q)      <->   "_%"
(a)               <->   @
(a)               <-    (a)
(040)a(041)       ->    (a)
(040)(a)          ->    (@
((a)              <-    (@

The algorithm is built to be simple to use in all the common cases, to be general, and to be straightforward to code. It's not trying to cover every pathological case, and honestly that's a good trade-off 💅

3.3.4. T.61String

T.61 strings are, in general, only used for carrying human-interpreted information. So the aim of a mapping should be to render the characters properly in the remote character set, rather than to maximise reversibility 🌈 The mappings defined in the CEN/CENELEC X.400 functional standard should be used [CEN/CENELEC/85a]. These are based on the mappings of X.408 (sections 4.2.2 and 5.2.2).

3.3.5. UTCTime

UTCTime and the RFC 822 822.date-time syntax both contain: Year (lowest two digits), Month, Day of Month, hour, minute, second (optional), and Timezone. 822.date-time also has an optional day of the week, but that's redundant. So a symmetrical mapping can be made between these constructs <5> ⭐ The UTCTime format that specifies the timezone offset should be used, in line with CEN/CENELEC recommendations.

Chapter 4 -- Addressing 🦋

Addressing is probably the trickiest problem of an X.400 <-> RFC 822 gateway, which is why it gets its own chapter 😭 This chapter also, as a side effect, defines a standard textual representation of X.400 addresses.

To start, we consider an address in the (human) mail user sense of "what is typed at the mailsystem to reference a human". A basic RFC 822 address is defined by the EBNF EBNF.822-address:

822-address     = [ route ] addr-spec

In an 822-P1 protocol, the originator and each recipient should be considered to be defined by a construct like this. In an RFC 822 header, the EBNF.822-address gets wrapped in the 822.address syntax rule, and there may also be comments attached. None of this extra info has any semantics, other than to the end user 💜

The basic X.400 address is defined by P1.ORName. In P1, all recipient P1.ORnames are encapsulated within P1.RecipientInfo, and in P2, all P2.ORNames <6> are encapsulated within P2.ORDescriptor.

So RFC 822 822.address has to be mapped with P2.ORDescriptor, and RFC 822 EBNF.822-address has to be mapped with P1.ORName (originator) and P1.RecipientInfo (recipients) 🎀

This chapter is laid out like this:

   4.1  Introduction.

   4.2  A textual representation of P1.ORName.  This is needed for
        the later mappings, and as a side effect provides a standard
        representation for O/R names.

   4.3  Mapping between EBNF.822-address and P1.ORName

   4.4  The Full P1 / 822-P1 Mapping

   4.5  The Full P2 / RFC 822 Mapping

   4.6  Mapping Message-IDs.

4.1. A textual representation of P1.ORName. 🌸

P1.ORName is structured as a set of attribute value pairs. It's clearly necessary to be able to encode this in ASCII for gatewaying purposes. A general encoding is given here, which can be used as a basis for a user interface, as well as for the defined gateway mapping ✨

4.1.1. Basic Representation

A series of BNF definitions is given for each possible attribute value pair. Each one has a 1:1 mapping with the X.400 encoding. The rest of the mapping then talks in terms of these BNF components, and the mapping to X.400 encoding is trivial 🧁

attributevalue = c / admd / prmd / x121 / t-id / o / ou
                / ua-id / pn.g / pn.i / pn.s / pn.gq / dd.value

c        = printablestring       ; P1.CountryName
admd     = printablestring       ; P1.AdministrationDomainName
prmd     = printablestring       ; P1.PrivateDomainName
x121     = numericstring         ; P1.X121Address
t-id     = numericstring         ; P1.TerminalID
o        = printablestring       ; P1.OrganisationName
ou       = printablestring       ; P1.OrganisationalUnit
ua-id    = numericstring         ; P1.UniqueUAIdentifier
pn.s     = printablestring       ; P1.PersonalName.surName
pn.g     = printablestring       ; P1.PersonalName.givenName
pn.i     = printablestring       ; P1.PersonalName.initials
pn.gq    = printablestring       ; P1.PersonalName.generation
                                   Qualifier
dd.value = printablestring       ; P1.DomainDefined
                                   Attribute.value

For attributes that can be encoded as either a PrintableString or a NumericString (Country, ADMD, PRMD), it's assumed that the NumericString encoding will be used whenever it's possible. This stops PrintableString being used where all the characters are numbers. The spec says this restriction seems preferable to the added complexity of a general solution 🤓 In the same way, we can define a set of attribute types:

dd.type = printablestring      ; P1.DomainDefinedAttribute.type

standard-type =
          "C"           ; P1.CountryName
        / "ADMD"        ; P1.AdministrationDomainName
        / "PRMD"        ; P1.PrivateDomainName
        / "X121"        ; P1.X121Address
        / "T-ID"        ; P1.TerminalID
        / "O"           ; P1.OrganisationName
        / "OU"          ; P1.OrganisationalUnit
        / "UA-ID"       ; P1.UniqueUAIdentifier
        / "S"           ; P1.PersonalName.surName
        / "G"           ; P1.PersonalName.givenName
        / "I"           ; P1.PersonalName.initials
        / "GQ"          ; P1.PersonalName.generationQualifier

standard-dd-type =
          "RFC-822"     ; dd.type = "RFC-822"
        / "JNT-Mail"    ; dd.type = "JNT-Mail"
        / "UUCP"        ; dd.type = "UUCP"

4.1.2. Encoding of Personal Name 🎀

Okay bestie, handling a Personal Name with just the EBNF.standard-type syntax from up above is gonna be so clumsy 😭. The "human" way people write names is way cuter, so this section proposes a syntax for it 💅. It's built for the common O/R Name cases where:

  1. There is no generational qualifier 🎀
  2. Initials contain only letters <7>.
  3. Given Name does not contain full stop ("."), and is at least two characters long.
  4. If Surname contains full stop, then it may not be in the first two characters, and either initials or given name is present.

The EBNF looks like this:

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

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

initial         = ALPHA

surname         = printablestring

Subject to the restrictions above, this is a reversible mapping ✨. Here are some examples:

GivenName       = "Marshall"
Surname         = "Rose"

Maps with  "Marshall.Rose"

Initials        = "MT"
Surname         = "Rose"

Maps with  "M.T.Rose"

GivenName       = "Marshall"
Initials        = "MT"
Surname         = "Rose"

Maps with  "Marshall.M.T.Rose"

Note that CCITT guidelines suggest that Initials is used to encode ALL initials 🙈. So the proposed encoding is "natural" when either GivenName or Initials, but not both, are present. The case where both are present can be encoded, but honestly that feels contrived!

4.1.3. Two encodings of P1.ORName 🦋

Now that we have this structure, we can write a BNF representation of an O/R Name:

std-orname      = 1*( "/" attribute "=" value ) "/"
attribute       = standard-type
                / "PN"
                / standard-dd-type
                / registered-dd-type
                / "DD." std-printablestring
value           = std-printablestring
registered-dd-type
                = std-printablestring
std-printablestring =
                = *( std-char / std-pair )
std-char        = <ps-delim, and any ps-char except "/"
                  and "=">
std-pair        = "$" ( ps-delim / ps-char )

If the type is PN, the value is interpreted according to EBNF.encoded-pn, and the components of P1.PersonalName get derived accordingly. If the value is registered-dd-type, and the value is registered at the SRI NIC as an accepted Domain Defined Attribute type, then the value should be interpreted accordingly 🌸. This restriction maximises the syntax checking which can be done at a gateway ✨.

Another syntax is now defined. It's meant to be compatible with the syntax used for 822.domains, and it's not intended to be handled by users 🙈.

dmn-orname      = dmn-part *( "." dmn-part )
dmn-part        = attribute "$" value
attribute       = standard-type
                / "~" dmn-printablestring
value           = dmn-printablestring
dmn-printablestring =
                = *( dmn-char / dmn-pair )
dmn-char        = <ps-delim, and any ps-char except ".">
dmn-pair        = "\."

For example:

C$US.ADMD$ATT.~ROLE$Big\.Chief

4.2. Mapping between EBNF.822-address and P1.ORName 🧚

Ideally the mapping would be totally symmetrical and global, so addresses could be referred to transparently in the remote system, with the choice of gateway left up to the Message Transfer Service. Two fundamental reasons make this not possible 😭:

  1. The syntaxes are sufficiently different to make this awkward.
  2. In the general case, there would not be the necessary administrative co-operation between the X.400 and RFC 822 worlds, which would be needed for this to work.

So an asymmetrical mapping is defined 💜.

4.2.1. X.400 encoded in RFC 822 💌

The std-orname syntax is used to encode O/R Name information in the 822.local-part of EBNF.822-address. Further O/R Name information may be associated with the 822.domain component. This can't be used in the general case, basically due to character set problems and the lack of order in X.400 O/R Names 💀. The only way to encode the full PrintableString character set in a domain is by using the 822.domain-ref syntax. This is likely to cause problems on many systems. In practice, the effective character set of domains is reduced from the RFC 822 set, thanks to restrictions from domain conventions and policy.

A generic 822.address is made up of an 822.local-part and a sequence of 822.domains, like this:

<@domain1,@domain2:user@domain3>

Everything except the 822.domain associated with the 822.local-part (domain3 in this case) should be considered to specify routing within the RFC 822 world, and the gateway won't interpret it (though they may have identified the gateway from within the RFC 822 world 👀). The 822.domain associated with the 822.local-part may also identify the gateway from within the RFC 822 world. This final 822.domain may be used to determine some number of O/R Name attributes. The following O/R Name attributes are considered a hierarchy, and may be specified by the domain. In order of hierarchy, they are:

Country, ADMD, PRMD, Organisation, Organisational Unit

There may be multiple Organisational Units 🌈.

Associations may be defined between domain specifications and some set of attributes. This association works hierarchically: if a domain implies ADMD, it also implies country. If one of the hierarchical components is omitted from an X.400 structure, that information can be associated with the corresponding domain (so a domain can be mapped onto a Country/ADMD/Organisation tuple). Subdomains under this are associated according to the O/R Name hierarchy. For example:

=> "AC.UK" might be associated with
                                          C="234", ADMD="BT", PRMD="DES"

then domain "R-D.Salford.AC.UK" maps with
       C="234", ADMD="BT", PRMD="DES", O="Salford", OU="R-D"

There are two basic reasons why a domain/attribute mapping might be kept, instead of just using subdomains 🤔:

  1. As a shorthand to avoid redundant X.400 information. In particular, there will often be only one ADMD per country, so it doesn't need to be given explicitly 🍓.
  2. To deal with cases where attribute values don't fit the syntax:
domain-syntax   = ALPHA [ *alphanumhyphen alphanum ]
alphanum        = <ALPHA or DIGIT>
alphanumhyphen  = <ALPHA or DIGIT or HYPHEN>

Although RFC 822 allows for a more general syntax, this restricted syntax is chosen because it's the one the various domain service administrations picked 👑.

This provides a general aliasing mechanism ✨.

This set of mappings only needs to be known by the gateways relaying between the RFC 822 world and the O/R Name namespace associated with the mapping in question. However, it's desirable (for the optimal mapping of third party addresses) for all gateways to know these mappings. A format for exchanging this information is defined in Appendix F 📚.

From the standpoint of the RFC 822 Message Transfer System, the domain specification is simply used to route the message in the standard manner. The standard domain mechanisms are used to identify gateways, and to select appropriate gateways for the corresponding O/R Name namespace. In most cases, this is done by registering the higher levels and assuming that the gateway can handle the lower levels 🫶.

As a further mechanism to simplify the encoding of common cases, where the only attributes to be encoded on the LHS are Personal Name attributes that comply with the restrictions of 4.2.2, the 822.local-part may be encoded as EBNF.encoded-pn 🎀. An example encoding is:

/PN=J.Linnimouth/GQ=5/@Marketing.Xerox.COM

This encodes the P1.ORName consisting of:

P1.CountryName                  = "US"
P1.AdministrationDomainName     = "ATT"
P1.OrganisationName             = "Xerox"
P1.OrganisationalUnit           = "Marketing"
P1.PersonalName.surName         = "Linnimouth"
P1.PersonalName.initials        = "J"
P1.PersonalName.GenerationQualifier = "5"

If the GenerationQualifier isn't present, the encoding J.Linnimouth@Marketing.Xerox.COM could be used instead.

Note that in this example, the first three attributes are determined by the domain Xerox.COM. The OrganisationalUnit is determined systematically 💖.

There's been an implicit assumption that an RFC 822 domain is either X.400 or RFC 822. This is pragmatic, but not ideal 😤, because the namespace should be structured on a logical basis that doesn't necessarily match the choice of Message Transfer protocols. The restriction can be lifted, provided that the nameservice deals with multiple message transfer protocols. This can happen in a straightforward way for the UK NRS, as explained in [Kille86a]. It could also be achieved with the DARPA Domain Nameserver scheme by using the WKS mechanism 🌟.

4.2.2. RFC 822 Encoded in X.400 🍬

In some cases, the encoding defined above may be reversed, to give a "natural" encoding of genuine RFC 822 addresses. This depends largely on the allocation of appropriate management domains 🌸.

The general case is mapped using domain defined attributes. Three are defined, depending on the full environment used to interpret the RFC 822 information:

  1. Domain defined type "RFC-822". This string is to be interpreted in the context of RFC 822, and RFC 920 [Crocker82a,Postel84a].
  2. Domain defined type "JNT-Mail". This string is to be interpreted in the context of the JNT Mail protocol, and the NRS [Kille84a,Larmouth83a].
  3. Domain defined type "UUCP". This is interpreted according to the constraints of the UUCP world [Horton86a].

These three are the values currently known to be useful. Further recognised values may be defined, and they'll be maintained in a list at the SRI Network Information Center 🦋.

Other O/R Name attributes will be used to identify a context in which the O/R Name gets interpreted. This might be a Management Domain, or some part of a Management Domain that identifies a gateway MTA. For example:

            1)

            C               = "GB"
            ADMD            = "BT"
            PRMD            = "AC"
            "JNT-Mail"      = "Jimmy(a)UK.CO.BT-RESEARCH-LABS"

            2)

            C               = "US"
            ADMD            = "Telemail"
            PRMD            = "San Fransisco"
            O               = "U Cal"
            OU              = "Berkeley"
            "RFC-822"       = "postel(a)usc-isib.arpa"

Okay bestie, look at these two examples 👀🎀 Both of them spell "@" as "(a)", because that's how PrintableString writes it. In the first one, the "JNT-Mail" domain defined attribute gets read everywhere inside the (Administrative or Private) Management Domain, so it's giving consistency 💅. The second one is messier. It needs extra attributes inside the Management Domain just to find a gateway 🚪. The vibe is that this scheme works with different levels of Management Domain co-operation, so it's flexible af ✨.

4.2.3. RFC 822 -> X.400 🦋

There are two basic cases:

  1. X.400 addresses encoded in RFC 822. This will also include RFC 822 addresses which are given reversible encodings.
  2. "Genuine" RFC 822 addresses.

The mapping should proceed as follows, by first assuming case 1) 🧚

STAGE 1.

  1. If the 822-address is not of the form:
local-part "@" domain

go to stage 2.

  1. Attempt to parse domain as:
*( domain-syntax "." ) known-domain

Where known-domain is the longest possible match in a list of gatewayed domains. If this fails, and the domain does not explicitly identify the local gateway, go to stage 2. If it succeeds, allocate the attributes associated with EBNF.known-domain, and systematically allocate the attributes implied by each EBNF.domain-syntax component.

  1. Map 822.local-part to ASCII, according to the definition of Appendix A. This step should be applied:
    • A. If the source network cannot support 822.quoted-string (as discussed in Appendix A).
    • B. If the address is an 822-P1 recipient.

This mapping is always applied in case B, as it increases the functionality of the gateway, and does not imply any loss of generality. Mapping case B allows sites which cannot generate 822.quoted-string to address recipients the gateway, without the gateway having to know this explicitly. There is no loss of functionality, as the quoting character of Appendix A (#) is not in PrintableString. This seems desirable. It should not be applied in to other addresses, as a third party RFC#822 address containing the sequence EBNF.atom-encoded (as defined in Appendix A) would be transformed asymmetrically. 🙈

  1. Map the result of 3) to EBNF.ps-encoded according to section 3.
  2. Parse the result of 4) according to the EBNF EBNF.std-orname. If this parse fails, parse the result of 4) according to the EBNF EBNF.encoded-pn. If this also fails, go to stage 2. Otherwise, the result is a set of type/value pairs.
  3. Associate the EBNF.attribute-value syntax (determined from the identified type) with each value, and check that it conforms. If not, go to stage 2.
  4. Ensure that the set of attributes conforms both to the X.411 P1.ORName specification and to the restrictions on this set given in X.400. If not go to stage 2.
  5. Build the O/R Name from this information.

STAGE 2.

This will only be reached if the RFC 822 EBNF.822-address is not a valid X.400 encoding. If the address is an 822-P1 recipient address, it must be rejected, as there is a need to interpret such an address in X.400. For the 822-P1 return address, and any addresses in the RFC 822 header, they should now be encoded as RFC 822 addresses in an X.400 O/R Name:

  1. Convert the EBNF.822-address to PrintableString, as specified in chapter 3.
  2. The domain defined attribute ("RFC-822", "JNT-Mail" or "UUCP") appropriate to the gateway should be selected, and its value set.
  3. Build the rest of the O/R Name in the local Management Domain agreed manner, so that the O/R Name will receive a correct global interpretation.

4.2.4. X.400 -> RFC 822 🌸

There are two basic cases:

  1. RFC 822 addresses encoded in X.400.
  2. "Genuine" X.400 addresses. This may include symmetrically encoded RFC 822 addresses.

When a P1 Recipient O/R Name is interpreted, gatewaying will be selected if there is a single special domain defined attribute present ("RFC-822", "JNT-Mail" or "UUCP"). In this case, use mapping A. For other O/R Names which:

  1. Contain the special attribute.

AND

  1. Identify the local gateway with the other attributes.

Use mapping A. In other cases, use mapping B. 💖

Mapping A

  1. Map the domain defined attribute value to ASCII, as defined in chapter 3.
  2. Where appropriate (P1 recipients), interpret the string according to the semantics implied by the domain defined attribute.

Mapping B.

This will be used for X.400 addresses which do not use the explicit RFC 822 encoding.

  1. Noting the hierarchy specified in 4.3.1, determine the maximum set of attributes which have an associated domain specification. If no match is found, allocate the domain as the domain specification of the local gateway, and go to step 4.
  2. Following the 4.3.1 hierarchy, if each successive component exists, and conforms to the syntax EBNF.domain-syntax (as defined in 4.3.1), allocate the next subdomain.
  3. If the remaining components are personal-name components, conforming to the restrictions of 4.2.2, then EBNF.encoded-pn should be derived to form 822.local-part. In other cases the remaining components should simply be encoded as a 822.local-part using the EBNF.std-orname syntax. Where registered domain defined types exist, the DD. syntax should not be used.
  4. If this step is reached for an 822-P1 recipient, then the address is invalid. For other addresses, if the derived 822.local-part can only be encoded by use of 822.quoted-string, the gateway may optionally use the ASCII to 822.local-part mapping defined in Appendix A, dependent on the mail protocols of the networks being relayed to. Use of this encoding is discouraged. 🫶

4.3. Repeated Mappings 🔁

The mappings defined are symmetrical across a single gateway, except in certain pathological cases (see chapter 3). However, it is always possible to specify any valid address across a gateway. This symmetry is particularly useful in cases of (mail exploder type) distribution list expansion. For example, an X.400 user sends to a list on an RFC 822 system which he belongs to. The received message will have the originator and any 3rd party X.400 O/R names in correct format (rather than doubly encoded). In cases (X.400 or RFC 822) where there is common agreement on gateway identification, then this will apply to multiple gateways.

However, the syntax may be used to source route.

For example: X.400 -> RFC 822 -> X.400

   C               = "UK"
   ADMD            = "BT"
   PRMD            = "AC"
   "JNT-Mail"      = "/PN=Duval/DD.Title=Manager/(a)FR.PTT.Inria"

This will be sent to an arbitrary UK Academic Community gateway by X.400. Then by JNT Mail to another gateway determined by the domain FR.PTT.Inria. This will then derive the X.400 O/R Name:

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

Similarly: RFC 822 -> X.400 -> RFC 822

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

         /C=UK/ADMD=BT/PRMD=AC/RFC-822=jj#l#a#r#seismo.css.gov/
                                                     @monet.berkeley.edu

The second case uses the Appendix A encoding to avoid 822.quoted-text. This will be sent to monet.berkeley.edu by RFC 822, then to the AC PRMD by X.400, and then to jj@seismo.css.gov by RFC 822. ✨

4.4. The full P1 / 822-P1 mapping 🎀

There are two basic mappings at the P1 level:

  1. 822-P1 return address <-> P1.UMPDUEnvelope.originator
  2. 822-P1 recipient <-> P1.RecipientInfo

822-P1 recipients and return addresses are encoded as EBNF.822-address. As P1.UMPDUEnvelope.originator is encoded as P1.ORName, mapping 1) has already been specified. P1.RecipientInfo contains a P1.ORName and additional information. The handling of this additional information is now specified.

4.4.1. RFC 822 -> X.400 🌷

The following default settings should be made for each component of P1.RecipientInfo.

  • P1.ExtensionIdentifier: This can be set systematically by the X.400 system.
  • P1.RecipientInfo.perRecipientFlag: Responsibility Flag should be set. Report Request should be set according to content return policy, as discussed in section 5.3. User Report Request should be set to Basic.
  • P1.ExplicitConversion: This optional component should be omitted.

4.4.2. X.400 -> RFC 822 🌈

The mapping only takes place in cases where P1.RecipientInfo.perRecipientFlag Responsibility Flag is set. The following treatment should be given to the other P1.RecipientInfo components.

  • P1.ExtensionIdentifier: Not used.
  • P1.RecipientInfo.perRecipientFlag: If ReportRequest is Confirmed or Audit-and-Confirmed then a delivery report indicating success should be sent by the gateway. This report should use each P1.ReportedRecipientInfo.SupplementaryInformation to indicate the identity of the gateway, and the nature of the report (i.e. only as far as the gateway). Failures will be handled by returning RFC 822 messages, and so User Report Request set to No report is ignored.
  • P1.ExplicitConversion: If present, the O/R name should be rejected, unless the requested conversion can be achieved. None of the currently recognised values of this parameter are appropriate to a gateway using this specification.

4.5. The full P2 / RFC 822 mapping 💜

Okay bestie, so every RFC 822 address is assumed to use the 822.mailbox syntax 💌 and that includes all the 822.comments hanging off the lexical tokens of the 822.mailbox ✨. Every P2.ORName gets encoded inside a P2.ORDescriptor or P2.Recipient (or inside Message IDs) 🎀. The mapping is asymmetrical, so the trip back isn't the same road 🦋

4.5.1. RFC 822 -> X.400 ✨

The following sequence is followed. 💅

  1. Take the address and extract an EBNF.822-address. This can be derived trivially from either the 822.addr-spec or 822.route-addr syntax. This is mapped to P2.ORName as described above.
  2. A string should be built consisting of (if present):
    • The 822.phrase component if it is a 822.phrase 822.route-addr construct.
    • Any 822.comments, in order, retaining the parentheses.

This string should then be encoded into T.61 (as described in chapter 3). If the string is not null, it should be assigned to P2.ORDescriptor.freeformName. 🫶

  1. P2.ORDescriptor.telephoneNumber should be omitted.
  2. In cases of converting to P2.Recipient, P2.Recipient.replyRequest and P2.Recipient.reportRequest should be omitted.

If the 822.group construct is present, each included 822.mailbox should be encoded as above. The 822.group should be mapped to T.61, and a P2.ORDesciptor with only a freeformName component built from it. 🌸

4.5.2. X.400 -> RFC 822 ✨

In the basic case, where P2.ORName is present, proceed as follows. 🧚

1. Encode P2.ORName as EBNF.822-address.

2a. If P2.ORDescriptor.freeformName is present, convert it to ASCII (chapter 3), and use use this as the 822.phrase component of 822.mailbox using the 822.phrase 822.route-addr construct.

2b. If P2.ORDescriptor.freeformName is absent, if EBNF.822-address is parsed as 822.addr-spec use this as the encoding of 822.mailbox. If EBNF.822-address is parsed as 822.route 822.addr-spec, then a 822.phrase taken from 822.local-part should be added. 💖

3. If P2.ORDescriptor.telephoneNumber is present, this should be placed in a trailing 822.comment.

4. If P2.Recipient.reportRequest has the receiptNotification bit set, then an 822.comment "(Receipt Notification Requested)" should be appended to the address. The effort of correlating P1 and P2 information is too great to justify the gateway sending Receipt Notifications. 😭

5. If P2.Recipient.replyRequest is present, an 822.comment "(Reply requested)" or "(Reply not requested)" should be appended to the address, dependent on its value. ✨

If P2.ORName is absent, P2.ORDescriptor.freeformName should be converted to ASCII, and used with the RFC 822 822.group syntax:

freeformname ":" ";"

Steps 3-5 should then be followed. 🎀

4.6. Message IDs 🦋

There is a need to map both ways between 822.msg-id and P2.IPMessageID. A mapping is defined which is symmetrical for non-pathological cases. 🌈 The mapping allows for the fact that P2.IPMessageID.PrintableString is mandatory for the Cen/Cenelec profile. This allows for good things to happen when messages pass multiple times across the X.400/RFC 822 boundary 💅. A mapping between 822.msg-id and P1.MPDUIdentifier is defined. This allows for X.400 error messages to reference an RFC 822 ID, which is preferable to a gateway generated ID.

4.6.1. P2.IPMessageID -> 822.msg-id 🍓

P2.IPMessageID.ORName is used to generate an 822.addr-spec, as defined above. P2.IPMessageID.PrintableString is mapped to ASCII, as defined in chapter 3. This string (if it is present and if the value is not "RFC-822") is appended to the front of the 822.local-part of the 822.msg-id, with "*" as a separator. If no ORName is present, an 822.msg-id of the form "PrintableString*@gateway-domain" is generated.

4.6.2. 822.msg-id -> P2.IPMessageID 🔥

822.local-part is parsed as:

[ printablestring "*" ] real-local-part

If EBNF.printablestring is found, it is mapped to PrintableString, and used as P2.IPMessageID.PrintableString. Otherwise P2.IPMessageID.PrintableString is set to "RFC-822". This arbitrary value allows for conformance to Cen/Cenelec. If EBNF.real-local-part is not present, no P2.IPMessageID.ORName is generated. Otherwise, 822.local-part is replaced with EBNF.real-local-part, and 822.addr-spec is mapped to P2.IPMessageID.ORName as defined above. 👑

4.6.3. 822.msg-id -> P1.MPDUIdentifier 🧁

P1.CountryName is assigned to "", P1.AdministrationDomainName to 822.domain (from 822.msg-id) and P1.MPDUIdentifier.IA5String to 822.local-part (from 822.msg-id).

4.6.4. P1.MPDUIdentifier -> 822.msg-id 💜

822.local-part is set to P1.MPDUIdentifier.IA5String, with any CRLF mapped to SPACE. If P1.CountryName is "", 822.domain is set to P1.AdministrationDomainName; Otherwise to P1.AdministrationDomainName ".." P1.CountryName. If there are any specials, the domain literal encoding should be used.

Chapter 5 -- Protocol Elements ✨

This chapter gives detailed mappings for the functions outlined in chapters 1 and 2. It makes extensive use of the notations and mappings defined in chapters 3 and 4. This chapter is structured as follows: 🌸

   5.1. Basic RFC 822 -> X.400 mappings

   5.2. A definition of some new RFC 822 elements, and their mapping
        to X.400.

   5.3  Some special handling associated with Return of Contents.

   5.4. X.400 -> RFC 822

5.1. RFC 822 -> X.400 🦋

First, the basic functions of an 822-P1 protocol should be mapped as follows. 💖

  • 822-P1 Originator: Mapped to P1.UMPDUEnvelope.originator (see chapter 4).
  • 822-P1 Recipient: Mapped to P1.RecipientInfo (see chapter 4).

The RFC 822 headers are used to generate both a P1.UMPDUEnvelope and a P2.Heading. The IP Message will have either one or two P2.BodyParts which will be type P2.IA5Text with no P2.IA5Text.repertoire component. The last P2.BodyPart will contain the RFC 822 message body. If there are any RFC 822 headers which indicate mapping into the P2.BodyPart, then two P2.BodyParts are generated. If a revised version of P2 allowed for extensible header specification, this would be seen as a preferable mapping. The first body part will start with the line: 🧚

RFC-822-Headers:

The rest of this body part will contain all of the headers not otherwise mapped (both 822.field-name and 822.field-body). The order of any such headers should be preserved. Similarly, ordering within P2.Heading and P1.UMPDUEnvelope should reflect ordering within the RFC 822 header. No P1 or P2 optional fields are generated unless specified.

A pro-forma X.400 message is now specified. Some of these defaults may be changed by the values in the RFC 822 message being mapped. The mandatory P1 and P2 components have the following defaults. 🎀

  • P1.MPDUIdentifier: The default should be unique value generated by the gateway.
  • P1.OriginatorORName: Always generated from 822-P1.
  • P1.ContentType: P1.ContentType.p2
  • P1.RecipientInfo: These will always be supplied from 822-P1.
  • P1.Trace: The last P1.TraceInformation component is generated such that: P1.TraceInformation.GlobalDomainIdentifier is set to the local vaglue. P1.DomainSuppliedInfo.action is set to relayed. P1.DomainSuppliedInfo.arrival is set to the current time. P1.DomainSuppliedInfo.previous may be set if there is anything sensible to set it to.
  • P2.IPMessageID: The default should be a unique value generated by the gateway.

The following optional parameters should be set: 🌈

  • P1.PerMessageFlag: The P1.PerMessageFlag.contentReturnRequest bit should be set according to the discussion in section 5.3. The P1.PerMessageFlag.alternateRecipientAllowed bit should be set, as it seems desirable to maximise opportunity for (reliable) delivery.

The RFC 822 headings should be mapped as follows: 💅

  • Received:: Fudged onto P1.TraceInformation (try not to grimace too much). P1.DomainSuppliedInfo.action is set to relayed. P1.DomainSuppliedInfo.arrival is set to the date-time component P1.TraceInformation.GlobalDomainIdentifier has P1.CountryName as a null string, and P1..AdministrationDomainName as the domain of the receiving host (if present - null string if not). P1.DomainSuppliedInfo.previous has P1.CountryName as a null string, and P1.AdministrationDomainName has the domain of the sending host with all other information enclosed in round parentheses. The encoding of ASCII to PrintableString (chapter 3) should be used if needed. For example: 🍓
Received: from 44e.cs.ucl.ac.uk by vax2.Cs.Ucl.AC.UK
               with SMTP  id a002110; 18 Dec 85 10:40 GMT

   maps to -

   P1.GlobalDomainIdentifier
      CountryName                  = ""
      AdministrationDomainName     = "vax2.Cs.Ucl.AC.UK"
   P1.DomainSuppliedInfo
      arrival                      = 18 Dec 85 10:40 GMT
      action                       = relayed
      previous
         CountryName               = ""
         AdministrationDomainName  =
                "44e.cs.ucl.ac.uk (with SMTP id a002110)"
  • Date:: This is used to set the first component of P1.TraceInformation. The mandatory components are set as follows:
P1.GlobalDomainIdentifier
   CountryName                  = ""
   AdministrationDomainName     = ""
P1.DomainSuppliedInfo
   arrival                      = time derived from Date:
   action                       = relayed

No optional fields are used in the trace. ⭐

  • Message-Id:: Mapped to P2.IPMessageID. If the RFC 822 message does not contain a P1-Message-ID: field, the Message-Id: field is also mapped to P1.MPDUIdentifier. For these, and all other fields containing msg-id the mappings of chapter 4 are used for each msg-id. 🔥
  • From:: If Sender: is present, this is mapped to P2.AuthorisingUsers. If not, it is mapped to P2.Originator. For this, and other components containing addresses, the mappings of chapter 4 are used for each address. 👑
  • Sender:: Mapped to P2.Originator. 🫶
  • Reply-To:: Mapped to P2.Heading.replyToUsers. 🌸
  • To:: Mapped to P2.Heading.primaryRecipients 🦋
  • Cc:

Mapped to P2.Heading.copyRecipients.

  • Bcc:
    • Mapped to P2.Heading.blindCopyRecipients. 💌
  • In-Reply-To:
    • Mapped to P2.Heading.inReplyTo for the first (if any) 822.msg-id component. If the field contains an 822.phrase component, or there are multiple 822.msg-id components, the ENTIRE field is passed in the P2.BodyPart. 🧵
  • References:
    • Mapped to P2.Heading.crossReferences. 🔗
  • Keywords:
    • Passed in the P2.BodyPart. 🏷️
  • Subject:
    • Mapped to P2.Heading.subject. The field-body uses the mapping referenced in chapter 3 from ASCII to T.61. 📝
  • Comments:
    • Passed in the P2.BodyPart. 💬
  • Encrypted:
    • Passed in the P2.BodyPart. 🔐
  • Resent-*
    • Passed in the P2..BodyPart <8>. 📨
  • Other Fields
    • In particular X-* fields, and "illegal" fields in common usage (e.g. "Fruit-of-the-day:") are passed in the P2.BodyPart. The same treatment should be applied to RFC 822 fields where the content of the field does not conform to RFC 822 (e.g. a Date: field with unparsable syntax). 🍓 Honestly, the gateway just keeps the weird stuff safe. Iconic. 🫶

5.2. Extended RFC 822 Elements -> X.400

First, an EBNF definition of a bunch of extended fields, and then the mapping to X.400. In most cases the RFC 822 syntax is set up to make this mapping super straightforward, so there's no need for a long explanation. 🦋

extended-field  = "P1-Message-ID" ":" p1-msg-id
                / "X400-Trace" ":" x400-trace
                / "Original-Encoded-Information-Types"
                   ":"encoded-info
                / "P1-Content-Type" ":" p1-content-type
                / "UA-Content-ID" ":" printablestring
                / "Priority" ":" priority
                / "P1-Recipient" : 1 mailbox
                / "Deferred-Delivery" ":" date-time
                / "Bilateral-Info" ":" bilateral-info
                / "Obsoletes" ":" 1 msg-id
                / "Expiry-Date" ":" date-time
                / "Reply-By" ":" date-time
                / "Importance" ":" importance
                / "Sensitivity" ":" sensitivity
                / "Autoforwarded" ":" boolean

p1-msg-id       = global-id ";" *text

p1-content-type = "P2" / atom

x400-trace      = global-id ";"
                "arrival" date-time
                [ "deferred" date-time ]
                [ "action" action ]
                [ "converted" "(" encoded-info ")" ]
                [ "previous" global-id ]

action          = "Relayed" / "Rerouted" / escape

global-id       = c "*" admd [ "*" prmd ]

encoded-info    = 1 encoded-type

encoded-type    = "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)
                / escape

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

bilateral-info  = c "*" admd "*" *text

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

sensitivity     = "Personal" / "Private"
                / "Company-Confidential" / escape

escape          = 1*DIGIT

Except for "Bilateral-Info:" and "X400-Trace:", there must be no more than one of each of these fields in an RFC 822 header. Any field beginning with the String "Autoforwarded-" is valid if the field would be syntactically valid with this string removed. 🎀

The mappings to X.400 go like this:

  • P1-Message-ID:
    • Mapped to P1.UMPDUEnvelope.MPDUIdentifier. This take precedence over any value derived from Message-ID:. 🆔
  • X400-Trace:
    • Mapped to the next component of P1.UMPDUEnvelope.Traceinformation. Care should be taken to preserve order. If one or more of these mappings is made, then a trace component should NOT be generated from the Date: field which should be redundant. This is because the message has previously come from X.400, and the Date: information will be redundant. Note that all trace information (Received: and "X400-Trace:") in the RFC 822 message will be in strict order, with the most recent at the top. This order should be preserved in the mapping. 🕰️ Order is everything here, bestie.
  • Original-Encoded-Information-Types:
    • This is used to set P1.UMPDUEnvelope.original. P1.EncodedInformationTypes.[0] has bits set according to each of the encoded-info components in this field. Any escape values should not be encoded. 🔢
  • P1-Content-Type:
    • If the value is anything other than "P2", the mapping should not be performed (unless the new value has some semantics to the gateway). 🙅‍♀️
  • UA-Content-ID:
    • Mapped to P1.UMPDUEnvelope.UAContentID. 🪪
  • Priority:
    • Mapped to P1.UMPDUEnvelope.Priority. An escape value should be encoded as P1.Priority.normal. 🚦
  • P1-Recipient:
    • If this field is set, the P1.PerMessageFlag.discloseRecipients bit should be set. Any of the addresses here which do not correspond to 822-P1 recipients should be added to the P1 recipient list, with the responsibility bit turned off. 👀
  • Deferred-Delivery:
    • Mapped to P1.UMPDUEnvelope.deferredDelivery. Note that the value of this field should always be in the past, as this field should only be present in messages which have come originally from X.400. Thus there should be no implied action. See also the comments on the reverse mapping. ⏳
  • Bilateral-Info:
    • No attempt is made to reconvert this information back to X.400. 🤐
  • Obsoletes:
    • Mapped to P2.Heading.obsoletes. 🗑️
  • Expiry-Date:
    • Mapped to P2.Heading.expiryDate. ⌛
  • Reply-By:
    • Mapped to P2.Heading.replyBy. 💭
  • Importance:
    • Mapped to P2.Heading.importance. An escape value should be encoded as P2.Heading.importance.normal. ❗
  • Sensitivity:
    • Mapped to P2.Heading.sensitivity. An escape value should be encoded as P2.Heading.sensitivity.normal. 🤫
  • Autoforwarded:
    • If this field is present and the value is "TRUE", there will be zero or more field names beginning "Autoforwarded-".
    • These should be taken, and the string "Autoforwarded-" stripped. These fields, in conjunction with the 822-P1 information, should be used to build an IP Message. Any implied actions should be taken. P2.Heading.autoforwarded is set in this message. The other RFC 822 fields are used to build another IP Message, which is used as the single body part of the first message. This mechanism does not nest. 🔁 No infinite loops, periodt. 💅

5.3. Return of Contents

It's not clear how widely supported the X.400 return of contents service will be. However, profiling work suggests that most systems will not support this service. Since this service is expected in the RFC 822 world, two approaches are specified (it's not so necessary in the X.400 world, since delivery reports are distinguished from messages). The choice will depend on the service level of the X.400 community being serviced by the gateway. 🤔

In environments where return of contents is widely supported, the P1.PerMessageFlag content return request bit will be set, and the Report Request bit in P1.PerRecipientFlag will be set to Confirmed, for every message passing from RFC 822 -> X.400. The content return service can then be passed back to the end (RFC 822) user in a straightforward manner. 🌈

In environments where return of contents is not widely supported, a gateway must make special provisions to handle return of contents. For every message passing from RFC 822 -> X.400, the P1.PerMessageFlag content return request bit will be set, and the Report Request bit in P1.PerRecipientFlag will be set to Confirmed. When the delivery report comes back, the gateway can note that the message has been delivered to the recipient(s) in question. If a non-delivery report is received, a meaningful report (containing some or all of the original message) can be sent to the 822-P1 originator. If no report is received for a recipient, a (timeout) failure notice should be sent to the 822-P1 originator. The gateway may retransmit the X.400 message if it wishes. Delivery confirmations should only be sent back to the 822-P1 originator if the P1.PerRecipientFlag User Report Request bit is set to Confirmed. 🧩 This part is a whole main character arc, ngl. 😭

5.4. X.400 -> RFC 822

5.4.1. General

This section describes how to build a pro-forma message, and then explains how these defaults may be overridden. It should be noted that RFC 822 folding of headers should be used in an appropriate manner. 📐

5.4.2. Service MPDU

5.4.2.1. Probe

Any P1.ProbeMPDU should 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 a User MPDU with the values specified in the probe. The reply should make use of P1.SupplementaryInformation to indicate that the probe was serviced by the gateway. 🔍

5.4.2.2. Delivery Report

The 822-P1 components are constructed as follows:

  • 822-P1 Originator
    • This is set to an 822.addr-spec pointing to an administrator at the gateway. 🧑‍💻
  • 822-P1 Recipient
    • The single recipient is constructed from P1.DeliveryReportEnvelope.originator, using the mappings of chapter 4. 📬

The mandatory RFC 822 headers for an RFC 822 pro-forma are constructed as follows:

  • Date:
    • From the P1.DomainSuppliedInfo.arrival component of the first P1.TraceInformation component. 📅
  • From:
    • This is set to the same as the 822-P1 originator. An appropriate phrase component may be added (e.g. giving the name of the gateway). 🏠
  • To:
    • The same as the 822-P1 recipient. 💖

A Subject: field should be added, which contains some appropriate words (e.g. "Delivery Report"). ✨

The other two P1.DeliveryReportEnvelope parameters should be mapped as follows:

  • P1.DeliveryReportEnvelope.report
    • This should be mapped to a P1-Message-Id: field. 🪄
  • P1.DeliveryReportEnvelope.TraceInformation

okay so each component gets mapped into its own X400-Trace: field 🎀 and the RFC 822 and X.400 ordering has to stay intact (peep 5.3 for the deets) 💅

the P1.DeliveryReportContent parameters get turned into a whole bunch of brand new RFC 822 headers 🦋 these are meant for the RFC 822 world to process, and nobody is trying to reverse the mappings (not me 💀)

   drc-field    = "Delivery-Report-Content-Original"
                ":" msg-id
              / "Delivery-Report-Content-Intermediate-Trace"
                ":" x400-trace
              / "Delivery-Report-Content-UA-Content-ID"
                ":" printablestring
              / "Delivery-Report-Content-Billing-Information"
                ":" *text
              / "Delivery-Report-Content-Reported-Recipient-Info"
                ":" drc-info

   drc-info     = mailbox ";"
                 last-trace ";"
                 "ext" 1*DIGIT
                 "flags" 2DIGIT
                 [ "intended" mailbox ] ";"
                 [ "info" printablestring ]

   last-trace   = drc-report ";"
                 date-time ";"
                 [ "converted" "(" encoded-info ")"

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

   drc-success  = date-time ";" 1*DIGIT

   drc-failure  = *text [ ";" *text ] ";"

there can be multiple Delivery-Report-Content-Intermediate-Trace: and Delivery-Report-Content-Reported-Recipient-Info: fields, periodt 🌸 the msg-id for Delivery-Report-Content-Original gets derived using the chapter 4 mapping ✨ EBNF.drc-failure can use numeric values or a textual explanation, but the textual one is preferred 💖 every P1.DeliveryReportContent parameter maps to its matching component, and the Delivery-Report-Content-Intermediate-Trace: fields go in order with the most recently stamped one first 🫶

the body of the RFC 822 message should be a human readable description of the critical bits of the P1.DeliveryReportContent 📝 the big things are the failed recipients and the failure reason, obvi 😭 some or all of the original message can be included in the delivery report too, and the original message will be available at the gateway, as covered in section 5.3 🧚

5.4.3. User MPDU ✨

these elements are the basis for both Status Report and IP Message 💜

the 822-P1 components get built like this:

822-P1 Originator

this is derived from P1.UMPDUEnvelope.originator 👑

822-P1 Recipient

each recipient is constructed from the P1.RecipientInfo, as described in chapter 4. this one covers actions as well as format mappings 🦋

the mandatory RFC 822 field pro-forma is derived as follows 🎀 in most cases where the P1.UMPDUContent is an IP Message, these defaults get overridden, so don't panic:

Date:

from the P1.DomainSuppliedInfo.arrival component of the first P1.TraceInformation component ⏰

From:

from the P1.UMPDUEnvelope.originator, as defined in chapter 4 🌈

To:

this default is only required if the generated RFC 822 message has no destination specification 🙈 if P1.PerMessageFlag.discloseRecipients is set, then it should contain the ORName in each P1.RecipientInfo component. if it isn't set, then it should be set to To: No Recipients Specified : ; (the it should be set to thing is in the original, bestie 😭)

the mappings, and any actions for each P1.UserMPDU element, are now up next 💅

P1.MPDUIdentifier

mapped to the extended RFC 822 field P1-Message-ID:. the sequence CRLF gets mapped to SPACE, which makes the mapping irreversible for those cases 💀

P1.UMPDUEnvelope.original

mapped to the extended RFC 822 field Original-Encoded-Information-Types:. if it contains only P2.IA5Text, the RFC 822 field may be omitted 🍓

P1.ContentType

this can currently only have one value, so it isn't mapped, on the basis that it's redundant 🙄 if the field contains any value other than P2, then the UMPDU should be rejected 🚫

P1.UAContentID

mapped to the extended RFC 822 field UA-Content-Id: 🌸

P1.Priority

mapped to the extended RFC 822 field Priority: 🔥

P1.PerMesageFlag

this one has a few components, so let's go 🌈

  • discloseRecipients: if this bit is set, a P1-Recipient: field should be generated, and it should contain each of the P1 recipients 💖
  • conversionProhibited: if this bit is set, the message should be rejected if it contains a P2.BodyPart that is not P2.IA5Text or P2.ForwardedIPMessage 🚫
  • alternateRecipientAllowed: the value of this bit is ignored 🙃
  • contentReturnRequest: the value of this bit is ignored 🙃

P1.UMPDUEnvelope.deferredDelivery

this should be mapped to the extended RFC 822 field Deferred-Delivery: 🕰️ X.400 profiles, and in particular the CEN/CENELEC profile [CEN/CENELEC/85a], specify that this element must be supported at the first MTA. so it's expected that the value of this element will always be in the past 🙌 if it isn't, the function may optionally be implemented by the gateway, meaning the gateway should hold the message until the time specified in the protocol element. so the extended RFC 822 field is just for information ✨

P1.PerDomainBilateralInformation

each component should be encoded in the extended RFC 822 field Bilateral-Info: 🎀 P1.BilateralInfo should be mapped into ASCII in a way that fits its contents. this submapping is not reversible 💅

P1.TraceInformation

this should be mapped to X400-Trace:, same as for the delivery report 🦋

5.4.4. Status Report ✨

the entire status report gets mapped into the body of the RFC 822 message, the same way as a Delivery Report 📬 an appropriate Subject: field should be generated. status reports can't be requested from the RFC 822 world, so this mapping probably won't get used a great deal 🥲

5.4.5. IP Message ✨

the P1.UMPDUEnvelope pro-forma specification makes sure all the 822-P1 information is there, plus a minimal (legal) RFC 822 message 🫶 the mappings and actions for the P2.Heading components are next. basically these get interpreted as actions and/or mappings into RFC 822 fields 🧚 the following mappings are specified:

P2.IPMessageID

mapped to the field Message-ID:, according to section 4 🎀

P2.Heading.originator

if P2.Heading.authorisingUsers is present, this is mapped to Sender:; if not, it goes to From: 👑

P2.Heading.authorisingUsers

mapped to From: 💖

P2.Heading.primaryRecipients

mapped to To: 💜

P2.Heading.copyRecipients

mapped to Cc: 🌈

P2.Heading.blindCopyRecipients

mapped to Bcc: 🤫

P2.Heading.inReplyTo

mapped to In-Reply-To: 🦋

P2.Heading.obsoletes

mapped to the extended RFC 822 field Obsoletes: 🍓

P2.Heading.crossReferences

mapped to References: 🌸

P2.Heading.subject

mapped to subject. the contents get converted to ASCII (as defined in chapter 3). any CRLF are not mapped, but they're used as points where the subject field must be folded. line. 🙃

P2.Heading.expiryDate

mapped to the extended RFC 822 field Expiry-Date: ⏳

P2.Heading.replyBy

mapped to the extended RFC 822 field Reply-By: 💅

P2.Heading.replyToUsers

mapped to Reply-To: 🫶

P2.Heading.importance

mapped to the extended RFC 822 field Importance: 🔥

P2.Heading.sensitivity

mapped to the extended RFC 822 field Sensitivity: 🔒

P2.Heading.autoforwarded

if it's set to FALSE, it's simply mapped to the extended RFC 822 field Autoforwarded:. if it's set to TRUE and the P2.Body does not consist of a single P2.ForwardedIPMessage, then that's an X.400 error and the message should be bounced 💀 otherwise, these steps happen:

  1. the mappings for all of the message, except the body part, are completed.
  2. prepend each RFC 822 fieldname with the string Autoforwarded-. mapped to the extended RFC 822 field Autoforwarded:.
  3. add the field Autoforwarded: with value TRUE.
  4. convert the syntax of the P2.ForwardedIPMessage to generate the remaining RFC 822 fields.

the P2.Body gets mapped into the RFC 822 message body 📦 each P2.BodyPart is converted to ASCII. if the P2.Body contains a P2.BodyPart that isn't listed here, the entire message should be rejected 🚫 if there are exactly two P2.IA5Text body parts, and the first line of the first one is RFC-822-Headers:, then the rest of that first body part should be treated as additional header information for the RFC 822 message 🧁 if there's an In-Reply-To: field, it should be used to replace any generated In-Reply-To: field.

in other cases of multiple P2.BodyPart, the mapping defined by Rose and Stefferud in [Rose85b] should be used to separate the P2.BodyParts in the single RFC 822 message body 🌷

individual body parts get mapped like this:

P2.IA5Text

the mapping is trivial 😌

P2.TTX

if any P1.Teletex.NonBasicParams are set, the message should be rejected. otherwise, it should be converted to ASCII according to chapter 3 🖋️

P2.SFD

an SFD should be converted to ASCII as if it was being rendered on a 79 column ASCII only VDU 🖥️ it seems likely that many gateways won't support this conversion. in those cases, the message should be rejected 🙅‍♀️

P2.ForwardedIPMessage

the P2.ForwardedIPMessage.delivery and P2.ForwardedIPMessage.DeliveryInformation are discarded <9> 🗑️ the IM-UAPDU should have its syntax mapped (recursively) according to this gatewaying specification. clearly, it makes no sense to apply any of the actions defined here 💀

Appendix A -- Quoted String Encodings ✨

okay bestie, this appendix is all about a quoting trick 🎀 that lets RFC 822 and its lookalike variants (the ones that can't handle 822.quoted-string) interwork with each other. it matters SO much bc the basic X.400 <-> RFC 822 mapping leans on 822.quoted-string 😭

1. ASCII <-> 822.atom

the grammar is spelled out in EBNF like this 💅

atom-encoded    = *( a-char / a-encoded-char )
a-char          = <any CHAR except specials, SPACE,
                              CTL, "_", and "#">
a-encoded-char  = "_"                   ; (space)
                / "#u#"                 ; (_)
                / "#l#"                 ; <(>
                / "#r#"                 ; <)>
                / "#m#"                 ; (,)
                / "#c#"                 ; (:)
                / "#b#"                 ; (\)
                / "#h#"                 ; (#)
                / "#e#"                 ; ($=)
                / "#s#"                 ; ($/)
                / "#" 3DIGIT "#"
NOTE: there are two encodings for double characters 🙈 so systems using this encoding don't also have to know about the "$" quoting mechanism from chapter 4.

the 822.3DIGIT in EBNF.a-encoded-char must have range 0-127 (Decimal), and it's read in decimal as the matching ASCII character. the special abbreviations were picked (instead of octal) bc of how this mapping gets used most: encoding PrintableString components of O/R names as atoms 🦋. so there are special encodings for every PrintableString character that isn't in EBNF.a-char, except ".". space gets its own single-character encoding bc it's (expected) super common, and backslash is the RFC 822 single quote character ✨

to encode (ASCII -> atom): all EBNF.a-char get used directly, and all other CHAR get encoded as EBNF.a-encoded-char. to decode (822.atom -> ASCII): if 822.atom can be parsed as EBNF.encoded-atom, reverse the previous mapping. if it can't be parsed that way, map the characters directly 💖

2. 822.local-part <-> ASCII

a related transformation is for 822.local-part (or any other element defined as '822.word ("." 822.word)') where 822.quoted-text isn't used. to encode (ASCII -> 822.local-part), all EBNF.a-char and "." get used directly, and all other 822.CHAR get encoded as EBNF.a-encoded-char. to decode (822.local-part -> ASCII), first try to parse 822.local-part as '822.atom *("." 822.atom)'. if that fails, or if each 822.atom can't be parsed as EBNF.atom-encoded, map each character directly. otherwise, map each "." directly and each atom as in the previous section 🌸

there are places where you need to convert between PrintableString or IA5Text (X.400) and 822.word (RFC 822). a word may be encoded as 822.atom (which has a restricted character set) or as 822.quoted-string, which can handle all ASCII characters. if 822.quoted-string is used, the PrintableString mappings from Chapter 3 give a straightforward mapping. but some RFC 822 based networks can't handle the 822.quoted-string format in every case, and that's where this Appendix comes in. the major requirement for this mapping is the UNIX world, but it may well be needed in other places too 🐚

these mappings are kinda artificial, so their usage is discouraged, except in cases where there's no alternative.

Appendix B -- Mappings Specific to JNT Mail 🧚

this Appendix is specific to the JNT Mail Protocol. it describes the specific changes in the context of this protocol. addressing isn't discussed here bc it's covered in Appendix A 💅

1. Introduction

there are four aspects of a gateway that are JNT Mail specific, on top of the ones relating to addressing. each one gets its own section of this appendix 🎀

2. Acknowledge-To:

this field has no direct functional equivalent in X.400. however, it can be supported to an extent, and it can be used to improve X.400 support 💜

when going from JNT Mail to X.400, the User Report Request bits of each P1.RecipientInfo.perRecipientFlag should be set to confirmed. if there is more than one address in the Acknowledge-To: field, or if the one address isn't equivalent to the 822-P1 return address, then:

a. acknowledgement(s) should be generated by the gateway. the text of these acknowledgements should indicate that they were generated by the gateway.

b. the Acknowledge-To: field should also be passed in the first P2.BodyPart.

when going from X.400 to JNT Mail, in cases where P1.RecipientInfo.perRecipientFlag has the user bits set to confirmed, the copy of the message to that recipient should have an Acknowledge-To: field containing the P.UMPDUEnvelope.originator. no attempt should be made to map Receipt notification requests onto Acknowledge-To:. this is because no association can be guaranteed between P2 and P1 level addressing information 🙈

3. Trace

JNT Mail trace uses the Via: syntax. when going from JNT Mail to X.400, the following mapping onto P1.TraceInformation is used 🦋

P1.DomainSuppliedInfo.action is set to relayed.

P1.DomainSuppliedInfo.arrival is set to the date-time component of the Via: field. P1.DomainSuppliedInfo.previous has P1.CountryName as a null string, and P1.AdministrationDomainName as the domain specified in the Via: field. P1.TraceInformation.GlobalDomainIdentifier has P1.CountryName as a null string, and P1.AdministrationDomainName as any commented information in the Via: field. for example:

Via: UK.AC.Edinburgh ; 17 Jun 85 9:15:29 BST (EMAS V7)

maps to 👇

P1.GlobalDomainIdentifier
   CountryName                  = ""
   AdministrationDomainName     = "(EMAS V7)"
P1.DomainSuppliedInfo
   arrival                      = 17 Jun 85 9:15:29 BST
   action                       = relayed
   previous
      CountryName               = ""
      AdministrationDomainName  = "UK.AC.Edinburgh"

4. Timezone specification

the extended syntax of zone defined in the JNT Mail Protocol should be used when mapping the UTCTime defined in chapter 3 🌈

5. Lack of separate 822-P1 originator specification

in JNT Mail, the default mapping of the P1.MPDUEnvelope.originator is to the Sender: field. this can cause a problem if the mapping of P2.Heading has already generated a Sender: field. to fix that, a new extended JNT Mail field is defined. it's chosen to line up with the JNT recommendation for interworking with full RFC 822 systems [Kille84b] ✨

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

if an IPM has no P2.heading.authorisingUsers component, and P2.Heading.originator.ORName is different from P1.UMPDUEnvelope.originator, map P1.MPDUEnvelope.originator onto the Sender: field.

if an IPM has a P2.heading.authorisingUsers component, and P2.Heading.originator.ORName is different from P1.UMPDUEnvelope.originator, P1.MPDUEnvelpoe.originator should be mapped onto the Sender: field, and P2.Heading.originator mapped onto the Original-Sender: field.

in other cases, the P1.MPDUEnvelope.Originator is already correctly represented 💖

heads up: in some pathological cases, this mapping is asymmetrical 💀

Appendix C -- Mappings Specific to Internet Mail 🌸

the Simple Mail Transfer Protocol [Postel82a] is used in the ARPA-Internet, and in any network following the US DoD standards for internetwork protocols. this appendix is specific to those hosts that use SMTP to exchange mail 📬

1. Mapping between O/R names and SMTP addresses

the mappings of Chapter 4 are to be used 🎀

2. Use of the ARPA Domain System

whenever possible, domain-qualified addresses should be be used to specify encoded O/R names. these domain encodings naturally should be independent of any routing information 🦋

3. Identification of gateways

the ARPA-Internet Network Information Center (NIC) will maintain a list of registered X.400 gateways in the ARPA Internet 🧚

Appendix D -- Mappings Specific to Phonenet Mail 📞

there are currently no mappings specific to Phonenet Mail. it's giving quiet 🤫

Appendix E -- Mappings Specific to UUCP Mail 🐚

gatewaying UUCP and X.400 is handled by first gatewaying the UUCP address into RFC 822 syntax (using RFC 976) [Horton86a], and then gatewaying the resulting RFC 822 address into X.400. for example, an X.400 address

Country         US
Organization    Xerox
Personal Name   John Smith

might be expressed from UUCP as

inthop!gate!gatehost.COM!/C=US/O=Xerox/PN=John.Smith/

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

inthop!gate!Xerox.COM!John.Smith

(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 gateways:

Country         US
ADMD            ATT
PRMD            ARPA
Organization    GateOrg
RFC-822         inthop!dest!user@gatehost.COM

or through a single X.400 to UUCP gateway:

Country         US
ADMD            ATT
PRMD            UUCP
Organization    GateOrg
UUCP            inthop!dest!user

Appendix F -- Format of Address Mapping Tables 🗺️

there's a need to specify the association between the domain and X.400 namespaces described in 4.2.1. this is defined as a table syntax, but the syntax is designed so it's suitable for use with domain nameservers (such as the DARPA Domain nameservers or the UK NRS). the symmetry of the mapping isn't clear, so a separate table is specified for each direction 💅

for domain -> X.400:

domain-syntax "#" dmn-orname "#"

for example:

AC.UK#PRMD$DES.ADMD$BT.C$UK#
XEROX.COM#O$Xerox.ADMD$ATT.C$US#

for X.400 -> domain:

dmn-orname "#" domain-syntax "#"

EBNF.domain-syntax will be interpreted according to RFC 920. EBNF.dmn-orname will have components ordered as defined in section 4.2.1, with the most significant component on the RHS ✨

References ✨

  • Bonacker85a. K.H. Bonacker, U. Pankoke-Babatz, and H. Santo, "EAN - Conformity to X.400 and DFN-Pflichtenheft," GMD (Gesellschaft fur Mathematik und Datenverarbeitung) report, June 1985. 💌
  • CCITT84a. CCITT SG 5/VII, "Recommendations X.400," Message Handling Systems: System Model - Service Elements, October 1984. 📬
  • CCITT84b. CCITT SG 5/VII, "Recommendations X.411," Message Handling Systems: Message Transfer Layer, October 1984. 🚚
  • CCITT84c. CCITT SG 5/VII, "Recommendations X.420," Message Handling Systems: Interpersonal Messaging User Agent Layer, October 1984. 🧑‍💻
  • CCITT84d. CCITT SG 5/VII, "Recommendations X.409," Message Handling Systems: Presentation Transfer Syntax and Notation, October 1984. 🔤
  • CEN/CENELEC/85a. CEN/CENELEC/Information Technology/Working Group on Private Message Handling Systems, "FUNCTIONAL STANDARD A/3222," CEN/CLC/IT/WG/PMHS N 17, October 1985. 🇪🇺
  • Crocker82a. D.H. Crocker, "Standard of the Format of ARPA Internet Text Messages," RFC 822, August 1982. 🎀
  • Horton85a. M.R. Horton, "Draft Standard for ARPA/MHS Addressing Gateways," AT&T Bell Laboratories, October 1985. 🌉
  • Horton86a. M.R. Horton, "UUCP Mail Interchange Format Standard", RFC 976, February 1986. 🦋
  • ICL84a. ICL, "Comparison of service elements of Grey Book Mail and X.400," Mailgroup Note 18: Extract from unpublished report for ITSU (Information Technology Standards Unit), July 1984. 📝
  • Kille84a. S.E. Kille, (editor), JNT Mail Protocol (revision 1.0), Joint Network Team, Rutherford Appleton Laboratory, March 1984. 🌸
  • Kille84b. S.E. Kille, "Gatewaying between RFC 822 and JNT Mail," JNT Mailgroup Note 15, May 1984. 🧚
  • Kille86a. S.E. Kille, "O/R Names in the UK Academic Community," UK Working Document, March 1986. 🇬🇧
  • Larmouth83a. J. Larmouth, "JNT Name Registration Technical Guide," Salford University Computer Centre, April 1983. 📚
  • Neufeld85a. G. Neufeld, J. Demco, B. Hilpert, and R. Sample, "EAN: an X.400 message system," in Second International Symposium on Computer Message Systems, Washington, pp. 1-13, North Holland, September 1985. 🧠
  • Postel82a. J. Postel, "Simple Mail Transfer Protocol," RFC 821, August 1982. 💜
  • Postel84a. J. Postel and J. Reynolds, "Domain Requirements," RFC 920, October 1984. 🌐
  • Rose85a. M.T. Rose, "Mapping Service Elements between ARPA and MHS," Draft proposal, October 1985. 🗺️
  • Rose85b. M.T. Rose and E.A. Stefferud, "Proposed Standard for Message Encapsulation," RFC 934, January 1985. 📦

Notes 💅

  • <0> UNIX is a trademark of Bell Laboratories. ™️ Just a little reminder, bestie. 🫶
  • <1> okay so the term gateway is used to describe a component performing the protocol mappings between RFC 822 and X.400. This is standard usage amongst mail implementors, but transport and network service implementors should note it carefully. 🌉 (Sometime called a "mail relay".)
  • <2> If the remote protocol is JNT Mail, a notification may also be sent by the recipient UA. 🔔
  • <3> The asymmetry shows up where an ASCII string contains the sequence EBNF.ps-encoded-char. That would be mapped directly to PrintableString, but the reverse mapping would be to the value implied by the sequence. 🔁
  • <4> It might be suggested that, for reasons of elegance, EBNF.ps-delim (left parenthesis) is encoded as EBNF.ps-encoded-char. This is not done, because it would never be possible to represent a PrintableString containing the character ( in ASCII. An ( in ASCII would be mapped to the encoding in PrintableString. 🙈
  • <5> In practice, a gateway will need to parse various illegal variants of 822.date-time. In cases where 822.date-time cannot be parsed, it is recommended that the derived UTCTime is set to the value at the time of translation. ⏰
  • <6> P2.ORname is defined as P1.ORName. 🔗
  • <7> This recommendation may change in the light of CCITT or CEN/CENELEC guidelines on the use of initials. 🧾
  • <8> It would be possible to use a ForwardedIPMessage for these fields, but the semantics are (arguably) slightly different, and it is probably not worth the effort. 🤷‍♀️
  • <9> Although this violates chapter 1, part 4, principles 2 and 3, it is suggested that this is justified by principle 1. Principle 1 really carries the day here, periodt. 👑
📦 where this page comes from