RFC 1649

Operational Requirements for X.400 Management Domains in the GO-MHS Community

📅 published July 1994, from ietf

Part 1 of 3 🎀

RFC 1649: Operational Requirements for X.400 Management Domains in the GO-MHS Community 🦋

Okay bestie, let's get into RFC 1649 💅 It's from the Network Working Group, written by R. Hagens (Advanced Network & Services, Inc.) and A. Hansen (UNINETT), dated July 1994. The category is Informational. It doesn't list anything it obsoletes or updates, so it's giving total main character energy 👑

Status of this Memo ✨

This memo gives info to the Internet community 📚 It does not specify an Internet standard of any kind, and distribution of it is unlimited 💌

1. Introduction ✨

Okay so there are already several big, operational X.400 services out there 🌍 A lot of the organizations in them are connected to the Internet, and a bunch more Internet-connected orgs are starting their own internal X.400 services (like U.S. government orgs following U.S. GOSIP). The whole point of this doc is to foster a Global Open Message Handling System (GO-MHS) Community that's fully interoperable with the existing E-mail service based on RFC-822 (STD-11). It's giving email unity 💖

The goal is to unite regionally operated X.400 services on the various continents into one GO-MHS Community (as seen from an end-user's point of view) 🫶 Examples of these regional services are the COSINE MHS Service in Europe and the XNREN service in the U.S.

A successful GO-MHS Community depends on decisions at both the national and international level 🌈 National X.400 service providers are responsible for implementing the minimum requirements defined in this document. On top of those minimum requirements, national requirements MAY be defined by each national service provider.

This doc refers to other documents published as RFCs. They're [1], [2], [3], [4], [6] and [7] in the reference list 📖

This doc handles X.400 1984 and X.400 1988 to 1984 downgrading. Issues about pure X.400 1988 are left for further study 🔍

Huge thanks to Allan Cargille and Lawrence Landweber for their input and guidance 🫶 This paper also came out of discussions in the IETF X.400 Operations WG and the RARE WG-MSG (former RARE WG1 (on MHS)).

1.1. Terminology

This doc defines requirements, recommendations and conventions 📝 A requirement is specified with the word SHALL. A recommendation is specified with the word SHOULD. A convention is specified with the word might. Conventions are there to make life easier for RFC-822 systems that don't follow the host requirements.

1.2. Profiles

Different communities have different profile requirements, so here's the list of profiles 💅

  • U.S. GOSIP - unspecified version
  • ENV - 41201
  • UK GOSIP for X.400(88)

When mail goes from the RFC-822 mail service to the GO-MHS Community, the automatic return of contents when mail is non-delivered SHOULD be requested by RFC 1327 gateways and SHOULD be supported at the MTA that generates the non-delivery report 📬 But ngl, it SHOULD be noted that this practice maximizes the cost associated with delivery reports 💸

2. Architecture of the GO-MHS Community 🏗️

To get a coherent deployment of X.400 in the GO-MHS Community, we need to lay out the overall structure and organization of the X.400 service in general terms ✨ This section is split into parts that cover management domains, lower layer connectivity, and overall routing.

The GO-MHS Community will operate as a single MHS community, as defined in reference [1] 💖

2.1. Management Domains

The X.400 model supports connectivity between communities with different service requirements, and the architectural vehicle for that is a Management Domain. Management domains are needed when different administrations have different specific requirements. The X.400 model defines two types: an Administration Management Domain (ADMD) and a Private Management Domain (PRMD) 🎀

Different countries have different organizational policies for MDs, and all of them are legal according to the X.400 standard 🌏 Currently, X.400 service providers in a country (inside or outside the GO-MHS Community) are organized as:

  • a) One or several ADMDs.
  • b) One or several PRMDs and with no ADMDs present in the country, or that are not connected to any ADMD.
  • c) One or several PRMDs connected to one or several ADMDs.

Or in combinations of a), b) and c). It isn't possible yet to say which model is the most effective 🙈

Thus, the GO-MHS Community SHALL allow every model.

2.2. The RELAY-MTA

The X.400 message routing decision process takes the destination O/R address as input and gives back as output the name (and perhaps connection information) of the MTA that will take responsibility for delivering the message to the recipient 🚚 The store and forward model lets a message pass through multiple MTAs. But it's generally accepted that the most efficient path is a direct connection from the originator to the recipient's MTA 🏹

Large-scale deployment of X.400 in the GO-MHS Community will require a well-deployed directory infrastructure to support routing. In the GO-MHS Community, X.500 is considered the best protocol for that kind of infrastructure 🗂️ In this environment, a routing decision can be made by searching the directory with a destination O/R address to get the name of the next hop MTA. That MTA MAY be a central entry point into an MD, or it MAY be the destination MTA within an MD.

Without a well-deployed Directory infrastructure, you'll need static tables to store routing information. These tables, keyed on O/R addresses, will be used to map a destination O/R address to a next hop MTA 🗺️ For efficient routing, one could build a table that contains info about every MTA in every MD. But that table would be enormous and super dynamic, so it's not feasible in practice 😭 Therefore, we need the concept of a RELAY-MTA.

The purpose of a RELAY-MTA is to act as a default entry point into an MD 🚪 The MTA that acts as a RELAY MTA for an MD SHALL be capable of accepting responsibility for all messages it receives that are destined for well-defined recipients in that MD.

Using a RELAY-MTA for routing is defined by reference [1] 📘

RELAY-MTAs in the GO-MHS Community SHALL route according to reference [1].

2.3. Lower Layer Stack Incompatibilities

Okay, this one's a bit of a plot twist 🌀 A big requirement for the GO-MHS Community to work is that all users can exchange messages. The GO-MHS Community is not dependent on the traditional TCP/IP lower layer protocol suite. A variety of lower layer suites are used as carriers of X.400 messages 🚛

Let's look at Figure 1 as an example 👀

     -----------------------------------------------------
     !                                                   !
     !            PRMD A                                 !
     !        --------------------                       !
     !        !   o       x      !                       !
     !        !                  !                       !
     !        !     o        w   !                       !
     !        !          z       !                       !
     !        --------------------                       !
     !                                PRMD B             !
     !                            ------------------     !
     !                            !      o     o   !     !
     !    PRMD C                  !  o             !     !
     !  ------------------        !      o     z   !     !
     !  !       o        !        !                !     !
     !  !  o        x    !        ------------------     !
     !  !     o        w !                               !
     !  !        o       !                               !
     !  ------------------                               !
     !                                                   !
     !               Key: Each character the in          !
     !                    the boxes illustrates an MTA.  !
     !                                                   !
     !                    x: TP0/RFC1006/TCP RELAY-MTA   !
     !                    w: TP4/CLNP RELAY-MTA          !
     !                    z: TP0/CONS/X.25 RELAY-MTA     !
     !                    o: MTA                         !
     -----------------------------------------------------

Figure 1: A Deployment Scenario

Now the tea ☕ PRMD A has three RELAY-MTAs that together support the TP0/CONS/X.25, TP0/RFC1006, and TP4/CLNS stacks. (Side note: it is acceptable for a single RELAY-MTA to support more than one stack. Three RELAY-MTAs are shown in this figure just for clarity.) So PRMD A is reachable via these stacks. But since PRMD B only supports the TP0/CONS/X.25 stack, it is not reachable from the TP0/RFC 1006 or the TP4/CLNS stack. PRMD C supports TP0/RFC1006 and TP4/CLNS. Since PRMD B and PRMD C don't share a common stack, how is a message from PRMD C supposed to reach a recipient in PRMD B? 🤔

One fix is to require that PRMD B implement a stack in common with PRMD C. However, this may not be a politically acceptable answer for PRMD B 😬

Another option is to implement a transport service bridge (TSB) between TP0/RFC 1006 in PRMD C and TP0/CONS in PRMD B. This will solve the problem for PRMD C and B. However, the lack of coordinated deployment of TSB technology makes this answer alone unacceptable on an international scale 🌐

The solution to this problem is to define a coordinated mechanism that allows PRMD B to advertise to the world that it has made a bilateral agreement with PRMD A to support reachability to PRMD B from the TP0/RFC 1006 stack ✨

This solution does not require that every MTA or MD directly support all stacks. However, it is a requirement that if a particular stack is not directly supported by an MD, the MD will need to make bilateral agreements with other MD(s) in order to assure that connectivity from that stack is available 🤝

Thus, in the case of Figure 1, PRMD B can make a bilateral agreement with PRMD A which provides for PRMD A to relay messages which arrive on either the TP4/CLNP stack or the TP0/RFC 1006 stack to PRMD B using the TP0/CONS stack 🎁

The policies described in reference [1] define this general purpose solution. It is a requirement that all MDs follow the rules and policies defined by reference [1] 📜

3. Description of GO-MHS Community Policies 🎀

A GO-MD is a Management Domain in the GO-MHS Community 💜

The policies in this section are a minimum set of common policies for GO-MDs. They are specified to ensure interoperability between:

  • all GO-MDs.
  • all GO-MDs and the RFC-822 mail service (SMTP).
  • all GO-MDs and other X.400 service providers.

3.1. X.400 Address Registration ✨

Okay so, an O/R address is basically a descriptive name for a UA that has certain characteristics helping Service Providers find it 🔍. Every O/R address is an O/R name, but not every O/R name is an O/R address, bestie. There's more on this in reference [5], chapter 3.1 📚.

Uniqueness of X.400 addresses SHALL be used to make sure end users can actually reach each other 💌. No cap, this is the whole point.

Mailboxes SHALL be addressed using the description of O/R names, Form 1, Variant 1 (see reference [5], chapter 3.3.2) 🎀. The attributes SHALL be treated as a hierarchy, like this:

Country name (C)
Administration domain name (ADMD)
[Private domain name] (PRMD)
[Organization name] (O)
[Organizational Unit Names] (OUs)
[Personal name] (PN)
[Domain-defined attributes] (DDAs)

Anything in square brackets is OPTIONAL 🫶. At least one of PRMD, O, OU and PN names SHALL be present in an O/R address. At least one of PN and DDA SHALL be present too 💅.

In general, a subordinate address element SHALL be unique within the scope of its immediately superior element 🧩. PRMD is the exception here (more on that in section 3.1.3) 👀. There SHALL exist registration authorities for each level, or mechanisms SHALL be available to make sure that uniqueness happens 🔒.

3.1.1. Country (C) 🌍

The top level element, Country, SHALL be defined by the set of two letter country codes, or numeric country codes in ISO 3166 🗺️.

3.1.2. Administration Management Domain (ADMD) 🏛️

ADMD values are decided on a national basis 🇺🇳. Every national decision made within the GO-MHS community SHALL be supported by a GO-MD ✨.

3.1.3. Private Management Domain (PRMD) 🏠

PRMD values SHOULD be unique within a country 🌸.

3.1.4. Organization (O) 🏢

Organization values SHALL be unique within the context of the subscribed PRMD, or the ADMD if there is no PRMD 💼. For clarification, this situation is legal (iykyk) 👇:

1) C=FI; ADMD=FUMAIL; O=FUNET.
2) C=FI; ADMD=FUMAIL; PRMD=NOKIA; O=FUNET.

So 1) and 2) are different addresses 🦋. (Note that 2) is a hypothetical address at this point 🙈.) O=FUNET is a subscriber at ADMD=FUMAIL, which is 1), and also at PRMD=NOKIA, which is 2) 💜. Two places, one org, zero drama 💅.

3.1.5. Organizational Units (OUs) 🧁

If OUs are used, a unique hierarchy of OUs SHALL be implemented 🌳. The top level OU is unique within the scope of the immediately superior address element, which means Organization, PRMD or ADMD 🎯. Use of multiple OUs MAY be confusing, so bestie, be careful out there 😭.

3.1.6. Given Name, Initials, Surname (G I S) 🧸

Each Organization can define its own Given-names, Initials, and Surnames to be used inside that Organization 🌷. When Surnames aren't unique within an O or OU, the Given-name and/or Initial SHALL be used to identify the Originator/Recipient 🫧. In the rare case that more than one user would have the same combination of G, I, S under the same O and/or OUs, each organization is free to find a practical solution and give those users unique O/R addresses 🌈.

Either one of Given-name or Initials SHOULD be used, not both 💖. Periods SHALL NOT be used in Initials 🚫.

To avoid problems when mapping X.400 addresses to RFC-822 addresses, the following rules might be used 🪄. ADMD, PRMD, O, and OU values SHOULD be made of characters from the alphabet (A-Z), digits (0-9), and minus ✨. Blank or Space characters SHOULD be avoided 🫠. Upper and lower case aren't distinguished, so no drama there 🎀. The last character SHALL NOT be a minus sign or period 🙅‍♀️. The first character SHOULD be either a letter or a digit (see reference [6] and [7]) 💫.

3.1.7. Domain Defined Attributes (DDAs) 🎁

The GO-MHS Community SHALL allow the use of domain defined attributes 💜. Heads up: support for DDAs is mandatory in the functional profiles, and all software MUST upgrade to support DDAs 🚨. The following DDAs SHALL be supported by a GO-MD 🫶:

"RFC-822" - defined in reference [3].

The following DDAs SHOULD be supported by a GO-MD too 🍓:

"COMMON" - defined in reference [2].

3.2. X.400 88 -> 84 Downgrading 🔁

The requirements in reference [2] SHOULD be implemented in GO-MDs 🛠️.

3.3. X.400 / RFC-822 address mapping 🗺️

All GO-MHS Community end-users SHALL be reachable from all end-users in the RFC-822 mail service on the Internet (SMTP), and vice versa 💌. It's giving two-way street, bestie 🛣️.

The address mapping issue is split into two parts 🧩:

  1. Specification of RFC-822 addresses seen from the X.400 world.
  2. Specification of X.400 addresses seen from the RFC-822 world.

The mapping of X.400 and RFC-822 addresses SHALL be performed according to reference [3] ✨.

3.3.1. Specification of RFC-822 Addresses seen from the X.400 World 🌐

There are two scenarios here 👯:

  • A. The RFC-822 end-user belongs to an organization with no defined X.400 standard attribute address space.
  • B. The RFC-822 end-user belongs to an organization with a defined X.400 standard attribute address space.

An organization is in scenario B if its X.400 addresses are registered according to the requirements in section 3.1 📝.

3.3.1.1. An Organization with a defined X.400 Address Space 🏫

An RFC-822 address for an RFC-822 mail user in an organization like this SHALL be in the same address space as a normal X.400 address for X.400 users in that same organization 💅. So RFC-822 addresses and X.400 addresses share the same address space, literally twins 👯‍♀️. Example time 🎀:

University of Wisconsin-Madison is registered under C=US; ADMD=Internet; PRMD=XNREN; with O=UW-Madison, and they use OU=cs to address end-users in the CS-department 🖥️. The RFC-822 address for RFC-822 mail users in the same department is user@cs.wisc.edu 💻.

An X.400 user in the GO-MHS Community will address the RFC-822 mail user in the CS-department with this X.400 address 📬:

C=US; ADMD=Internet; PRMD=xnren; O=UW-Madison; OU=cs; S=user;

That's the same address space used for X.400 end-users in the same department 🫶.

3.3.1.2. An Organization with no defined X.400 Address Space 🌙

RFC-822 addresses SHALL be expressed using X.400 domain defined attributes 🪐. The mechanism used to define the RFC-822 recipient will vary from country to country 🌎.

For example, in the U.S., a special PRMD named "Internet" is defined to make RFC-822 addresses easier to specify 🇺🇸. An X.400 user can address an RFC-822 recipient in the U.S. by building an X.400 address like this 💫:

C=us; ADMD=Internet; PRMD=Internet; DD.RFC-822=user(a)some.place.edu;

The first part of this address 👇:

C=us; ADMD=Internet; PRMD=Internet;

denotes the U.S. portion of the Internet community, not a specific "gateway" 🙌. The second part 👇:

DD.RFC-822=user(a)some.place.edu

is the RFC-822 address of the RFC-822 mail user, after non-printable characters are substituted according to reference [3] 🔤. The RFC-822 address goes into an X.400 Domain Defined Attribute of type RFC-822 (DD.RFC-822) 🎀.

Each country gets to choose its own method for defining the RFC-822 community, and that's giving independence 🗽. For example, in Italy an X.400 user would refer to an RFC-822 user like this 🍕:

C=IT; ADMD=MASTER400; DD.RFC-822=user(a)some.place.it

In the UK, an X.400 user would refer to an RFC-822 user like this ☕:

C=GB; ADMD= ; PRMD=UK.AC; O=MHS-relay; DD.RFC-822=user(a)some.place.uk

3.3.2. Specification of X.400 Addresses seen from the RFC-822 World 🌏

If an X.400 organization has a defined RFC-822 address space, RFC-822 users will be able to address X.400 recipients using RFC-822/Internet terms 🥰. So from an RFC-822 user's point of view, the X.400 user's address will usually look like this 👀:

Firstname.Lastname@some.place.edu

where some.place.edu is a registered Internet domain 🌐.

This means address mapping tables have to be maintained and distributed to all participating RFC-1327 gateways 📋. The mapping tables SHALL be globally consistent 🧠. Effective mapping table coordination procedures are needed 🤝.

If an organization does not have a defined RFC-822 address space, an escape mapping (defined in reference [3]) SHALL be used 🔐. In this case, the X.400 user's address, seen from an RFC-822 user, will look like this 👇:

"/G=Firstname/S=Lastname/O=org name/PRMD=foo/ADMD=bar/C=us/"@
                                some.gateway.edu

Note that reference [7] specifies that quoted left-hand side addresses MUST be supported, and that these addresses MAY be greater than 80 characters long 📏. Wild, right? 😭

This escape mapping SHALL also be used for X.400 addresses which don't map cleanly to RFC-822 addresses 🧷.

It is RECOMMENDED that an organization with no defined RFC-822 address space SHOULD register RFC-822 domains with the appropriate registration entity 📝. This will minimize the number of addresses which MUST use the escape mapping 🥳. Less escape mapping, more slay 💅.

If the escape mapping is not used, RFC-822 users won't see any difference between an Internet RFC-822 address and an address in the GO-MHS Community 👻. For example, this X.400 address 👇:

C=us; ADMD=ATTMail; PRMD=CDC; O=CPG; S=Lastname; G=Firstname;

will look like this from an RFC-822 user's side 👇:

    Firstname.Lastname@cpg.cdc.com

3.4. Routing Policy 🚦

To make routing work in the GO-MHS Community before an X.500 infrastructure is deployed, two documents are defined: a RELAY-MTA document and a Domain document 🧭. These documents are formally defined in reference [1] 📖. Using them is necessary to solve the routing crisis we have today 😩. But honestly, this is a temporary fix that will eventually be replaced by X.500 🦋.

The RELAY-MTA document defines the names of RELAY-MTAs and their associated connection data, including selector values, NSAP addresses, supported protocol stacks, and supported X.400 protocol version(s) 🎀.

Each entry in the Domain document is a sub-tree hierarchy of an X.400 address, followed by a list of MTAs that are willing to accept mail for that address or provide a relay service for it 💌. Each MTA name is associated with a priority value 🔢. Together, the MTA names in the Domain document make the given address reachable from all protocol stacks ✨. The MTAs MAY also provide redundant paths to the address, and in that case the priority value shows the preferred path, or the order in which alternative routes SHOULD be tried 🛤️. Main character energy for the preferred route 👑.

The RELAY-MTA and Domain documents are coordinated by the group specified in the Community document 🤝. The procedures for gathering and distributing document information are for further study 🔮.

3.5. Minimum Statistics/Accounting ✨

okay so these are not required for every MTA 🙈 but they're totally helpful guidelines for MTA managers! 📊 They help you see how much the service gets used and how well it's performing, which is very main character behavior 💅

This section spells out the data each MTA should keep 🗂️ but there are no constraints on how you store it (the encoding, i.e., format). Store it however you like, bestie 🫶

For every message or report that passes through the MTA, you should collect this stuff:

  • Date
  • Time
  • Priority
  • Local MTA Name
  • Size

These fields are conditionally collected 🌸

  • From MTA Name (fm)
  • To MTA Name (tm)
  • Delta Time (dt)
  • Message-id (id)

At least one of fm and tm should be present. If one of fm and tm is not present, id should be present. If both fm and tm are present, then dt tells you how many minutes the message was delayed in the MTA ⏰

If id can't be mapped locally because of log file formats, then id is not present and every message creates two lines 👯 One line has fm empty and the other has tm empty. In this case, date and time on the first line are when the message entered the MTA, and on the second line they're when the message left the MTA. It's giving organized chaos 😭

These fields are optionally collected 🎀

  • From Domain (fd)
  • To Domain (td)

For route tracing, fd and td are super useful 🦋 They represent X.400 OU's, O, PRMD, ADMD and C, and they can be supplied up to any level of detail 🧚

4. Community Document 💖

For the GO-MHS community there will be one single COMMUNITY document with the basic info defined in reference [1] 📄 It starts with the contact info for the central coordination point, plus the addresses for the file server where all the documents live 🗄️ It also lists the network names and stacks to be used in the RELAY-MTA and DOMAIN documents. The GO-MHS community must agree on its own set of mandatory and optional networks and stacks 🤝

5. Security Considerations 🙈

Okay bestie, the security stuff is a whole plot twist: security issues are not discussed in this memo 😭💀 Nothing about security is covered here, so keep that in mind as you read!

6. Authors' Addresses 💜

Here are our two authors, the girlies behind this document 🫶

Robert Hagens
Advanced Network & Services, Inc.
1875 Campus Commons Drive
Suite 220
Reston, VA 22091
U.S.A.

Phone: +1 703 758 7700
Fax:   +1 703 758 7717
EMail: hagens@ans.net
DDA.RFC-822=hagens(a)ans.net; P=INTERNET; C=US


Alf Hansen
UNINETT
Elgesetergt. 10
Postbox 6883, Elgeseter
N-7002 Trondheim
Norway

Phone: +47 7359 2982
Fax:   +47 7359 6450
EMail: Alf.Hansen@uninett.no
G=Alf; S=Hansen; O=uninett; P=uninett; C=no

References 📚

[1] Eppenberger, U., Routing Coordination for X.400 MHS-Services Within a Multi Protocol / Multi Network Environment, RFC 1465, SWITCH, May 1993.

[2] Hardcastle-Kille, S., "X.400 1988 to 1984 downgrading, RFC 1328, University College London, May 1992.

[3] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021 and RFC 822, RFC 1327, May 1992.

[4] Cargille, A., "Postmaster Convention for X.400 Operations", RFC 1648, University of Wisconsin, July 1994.

[5] International Telecommunications Union, CCITT. Data Communications Networks, Volume VIII, Message Handling Systems, ITU: Geneva 1985.

[6] Harrenstien, K., Stahl, M., and E. Feinler, "DOD Internet Host Table Specification", RFC 952, SRI, October 1985.

[7] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, USC/Information Sciences Institute, October 1989.

📦 where this page comes from