RFC 2162

MaXIM-11 - Mapping between X.400 / Internet mail and Mail-11 mail

📅 published January 1998, from ietf

RFC 2162: MaXIM-11, Mapping Between X.400 / Internet Mail and Mail-11 Mail 🎀

okay bestie, this one is a whole mapping guide between three mail worlds: X.400, Internet mail (RFC822/MIME), and the Mail-11 (DECnet mail) system. 💅

Author: C. Allocchio, I.N.F.N. - Italy 🦋
Category: Experimental 🧪
Date: January 1998 📅
Obsoletes: RFC 1405 (the older version, which was a joint effort from the TERENA Working Group on Messaging and the IETF X.400 Ops Working Group) 🌸

The update was prepared by the IETF MIXER working group, so MIXER is kinda the sister spec here. ✨

Status of this Memo 🌈

This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. 💜

Copyright Notice 🔒

Abstract ✨

okay so this document lays out a bunch of mappings so that systems running the ISO/IEC 10021 - CCITT (now ITU) X.400 Recommendations on Message Handling Systems can talk to systems running Mail-11 (aka DECnet mail or VMSmail). 🫶 The rules are valid both in DECnet Phase IV and in the DECnet/OSI addressing and routing scheme. 🧚

It also looks at the whole X.400 / MIME / Mail-11 situation, because things get messy when a message goes through multiple gateways. 🙈

Mainly, this doc covers the X.400 O/R address to and from Mail-11 address mapping, plus the RFC822 to and from Mail-11 one. The other mappings are based on the MIXER specs. Bodypart mappings are NOT specified here. MIXER and MIME-MHS can be applied to map bodyparts between X.400, MIME and Mail-11 too, and MIME encoding can be used without modifications inside Mail-11 text bodyparts. 🦋

And as I said, this document obsoletes RFC 1405. 💖

Chapter 1 - Introduction 🎀

1.1. X.400

The standard referred to as "X.400" in this document is the ISO/IEC 10021 - CCITT 1984, 1988 and 1992 X.400 Series Recommendations, which cover the Message Oriented Text Interchange Service (MOTIS). This document covers only the Inter Personal Messaging System (IPMS). 💅

1.2. Mail-11

Mail-11, also known as DECnet mail (and often improperly called VMSmail), is the proprietary protocol Digital Equipment Corporation (DEC) built for real-time text messaging between systems running DECnet Phase IV and DECnet/OSI (CLNS) networking protocols. 💻

1.3. RFC822 / MIME

RFC822 was defined as the standard for personal messaging in the DARPA Internet, and it's now spread over lots of different transfer protocols like SMTP, UUCP, BITNET, JNT Grey Book and CSnet. 🌍

MIME lets you send non-textual stuff inside RFC822 messages. Its mapping with X.400 is fully described in MIXER and MIME-MHS. In this doc, we'll also look at how it relates to Mail-11. 🫶

1.4. The user community

The MIME and X.400 messaging communities keep growing all over the world. 📈 But there are still a bunch of huge Mail-11 communities that want to talk easily with X.400 Message Handling Systems and with MIME systems. Some of the big DECnet networks include the High Energy Physics network (HEPnet) and the Space Physics Analysis Network (SPAN). 🔭

Lots of smaller local communities also use Mail-11 mailing protocols internally. Like any other "non standard" mail protocol, using non-standard mapping techniques between Mail-11 and standard mail systems can give unpredictable results. 😭

So, for all these reasons, this document describes a set of rules for converting between Mail-11 and X.400 or MIME. 🌸

This document also covers Mail-11 systems that implement the "foreign mail protocol", which lets Mail-11 interface with other mail systems, including RFC822-based ones. 🍓

Chapter 2 - Message Elements 💖

2.1. Service Elements

Okay, the big picture: Mail-11 only has a very restricted set of elements for composing an Inter Personal Message (IPM), while X.400 and RFC822/MIME support a huge amount of service elements. 😳 So if a message is relayed between two X.400 MHS or MIME Message Transport System (MTS) hops through a Mail-11 system, you could end up losing almost all the info. 💀

To keep that from happening, any X.400 or MIME service element that doesn't map directly to a Mail-11 equivalent (under this spec) gets included in the Mail-11 text body parts as an extra RFC822-like header. This extra header is inserted between the Mail-11 P2 headers (From:, To:, CC:, Subj:) and the other Mail-11 bodyparts. X.400 elements are also converted to a textual representation before they get inserted. 🧚

Here's an example, where a multimedia message got encoded into Mail-11 after crossing a MIME-MHS (MIXER conformant) gateway: 🖼️

  From:  smtp%"Admin@SURFnet.nl"  "Erik"  18-OCT-1994 13:55:00.49
  To:    ALLOCCHIO
  CC:    smtp%"netman@MailFLOW.dante.net"
  Subj:  enjoy this nice picture!

  X400-Originator: root@sun3.SURFnet.nl
  X400-Recipients: Allocchio@elettra.ts.it, netman@MailFLOW.dante.net
  Sender: Erik Newmann <root@SURFnet.nl>
  Organisation: SURFnet bv
  Mime-Version: 1.0
  Content-Type: multipart/mixed; boundary="----- =_aaaaaa0"
  Content-ID: <21223.78342785@SURFnet.nl>

  ------- =_aaaaaa0
  Content-Type: text/plain; charset="us-ascii"
  Content-ID: <21223.78342785@SURFnet.nl>

  look... you never saw this one!!
  I just include the picture in the next bodypart
  and I hope you get it fine.

  regards,

  Erik                                         (continues...)

  ------- =_aaaaaa0                            (continued...)
  Content-Type: image/gif
  Content-ID: <21223.78342785@SURFnet.nl>
  Content-Description: a nice snapshot!
  Content-Transfer-Encoding: base64

  RAV8372FAASD83D721NSHDHD3ASDFJKHWEHKJHCBASDFA829CA8SDB29B132RBAKDFA
  9KSJ2KJAA0SDFNAL20DDKFALJ20AJDLFB239B9SC9B29BA9BDFADSDF03998ASDFASD

  ------- =_aaaaaa0

We also need to think about the case where a message starts in an RFC822/MIME network, goes through Mail-11, and then lands in an X.400 MHS, or the other way around. 🔁

Whenever an X.400 element that isn't covered here needs to be turned into text (to go into a Mail-11 RFC822-like header or text bodypart), we apply the rules in MIXER (the X.400 to RFC822/MIME sections). ✨

And the reverse: the MIXER spec (RFC822/MIME to X.400 sections) also gives the right rules for turning the textual representations in a Mail-11 RFC822-like header or bodyparts back into X.400 elements. 🦋

RFC822/MIME headers that this spec doesn't cover get included "as they are" in the Mail-11 RFC822-like header and bodyparts. That makes the trip back from Mail-11 to the RFC822/MIME structure pretty straightforward. 🌈

All of these methods give maximum transparency, with minimal or no information loss even when Mail-11 is in the middle. 👑

2.2. Mail-11 service elements to X.400 service elements.

All envelope (P1) and header (P2) Mail-11 service elements are supported in the conversion to X.400. Heads up: Mail-11 P1 is made up only of P1-11.From and P1-11.To, and every other Mail-11 element belongs to Mail-11 P2. 📝

P1-11.From maps to P1.Originator
P1-11.To maps to P1.Primary Recipient
P2-11.'From:' usually maps to P2.Originator (see section 2.6)
P2-11.'To:' maps to P2.Primary Recipient
P2-11.'CC:' maps to P2.Copy Recipient
P2-11.Date maps to P2.Submission Time Stamp
P2-11.'Subj:' maps to P2.Subject

Any RFC822-like text header in a Mail-11 body part gets interpreted as specified in MIXER. 🫶

2.3. X.400 service elements to Mail-11 service elements

These X.400 service elements are supported directly in the Mail-11 conversion: 💅

P1.Originator maps to P1-11.'From:'
P1.Primary Recipients maps to P1-11.'To:'
P2.Originator usually maps to P2-11.'From:' (see section 2.6)
P2.Primary Recipients maps to P2-11.'To:'
P2.Copy Recipients maps to P2-11.'CC:'
P2.Submission Time Stamp maps to P2-11.Date
P2.Subject maps to P2-11.'Subj:'

This X.400 service element is only partially supported in the Mail-11 conversion: 🙈

P2.Blind Copy Recipient: to keep the privacy that's required whenever a message has a BCC address, the following actions occur:
- a new message is created, containing the body parts;
- a new envelope is added to the new message, containing only the originator and the BCC recipient addresses;
- a note is added to the message, telling the BCC recipient that the message was a BCC;
- the new message is delivered separately;
- a note is added to the message delivered to the TO and CC recipients, telling them that there were some BCC recipients too.

Any other X.400 service element support is done according to MIXER, including the mapped element in the RFC822-like header inside the Mail-11 body part. 🌸

2.4. Mail-11 service elements to RFC822/MIME service elements.

All envelope (P1) and header (P2) Mail-11 service elements are supported in the conversion to RFC822/MIME: 🍓

P1-11.From maps to 822-MTS.Originator
P1-11.To maps to 822-MTS.Primary Recipient
P2-11.'From:' usually maps to 822.'From:' (see section 2.6)
P2-11.'To:' maps to 822.'To:'
P2-11.'CC:' maps to 822.'Cc:'
P2-11.Date maps to 822.'Date:'
P2-11.'Subj:' maps to 822.'Subject:'

Any RFC822-like text header in a Mail-11 body part gets re-inserted into the RFC822/MIME message "as it is". 🎀

Chapter 2 - Message Elements (continued) 💖

2.5. RFC822/MIME service elements to Mail-11 service elements 🦋

okay so these are the RFC822 service elements that get converted straight over into Mail-11, no detours 💅

822-MTS.Originator maps to P1-11.From
822-MTS.Primary Recipients maps to P1-11.To
822.'From:' usually maps to P2-11.'From:' (see section 2.5)
822.'To:' maps to P2-11.'To:'
822.'Cc:' maps to P2-11.'CC:'
822.'Date:' maps to P2-11.Date
822.'Subject:' maps to P2-11.'Subj:'

next up is 822.'Bcc:', which is only partially supported 🙈 it's giving privacy drama, so to protect the hidden recipients, the converter does a whole reshuffle when a message has a BCC address:

a brand new message gets created, carrying the body parts 📦
that new message gets its own envelope, holding just the originator and the BCC recipient addresses 🔒
a note gets added so the BCC recipient knows the message came to them as a BCC 🤫
the new message is delivered separately 🚀
the people getting it through TO and CC get a note too, saying there were some BCC recipients as well 👀

anything else from RFC822/MIME? no stress. it just gets copied "as it is" into the RFC822-like header and into a Mail-11 body part, no edits, no drama 🌸

2.6. Rules to define the Mail-11 P2-11.'From:' element 💌

okay this one is SO important, bestie. Mail-11 User Agents (usually VMSmail) use the P2-11.'From:' element as the destination whenever someone issues the REPLY command, and they totally ignore other stuff like Sender:, Reply-To:, Return-Path: etc. 😭 A bunch of automatic responders also rely on this field alone to address their messages. so it's lowkey the main character field 👑

which means you HAVE to put the right information in there, meaning the correct address where a REPLY or any automatically generated message should actually go, following the X.400 or RFC822 rules. no cap, this is the whole point 💅

to pick what goes in this field, use the rules in RFC822, section 4.4.4 as your selection criterion 🎀

here's the tea: if P2-11.'From:' isn't generated from the P2.Originator (X.400) or from the 822.'From:' (RFC822), then it's essential to keep the original info from P2.Originator or 822.'From:' in a 'From:' record of the RFC822-like header. protect that original info at all costs 🫶

going the other way, when converting from Mail-11 into X.400 or RFC822/MIME, whatever is in the 'From:' field of the RFC822-like header (if there is one) wins and supersedes what's in the Mail-11 P2-11.'From:'. here's an example, babe 🧚

From:  smtp%"Admin@SURFnet.nl"  "Erik"  18-OCT-1994 13:55:00.49
To:    ALLOCCHIO
CC:    smtp%"netman@MailFLOW.dante.net"
Subj:  enjoy this nice picture!

From: Erik Newmann <root@SURFnet.nl>
Reply-To: Admin@SURFnet.nl
Organisation: SURFnet bv
Message-Id: <21235.25442281@SURFnet.nl>

and when converting back into RFC822, the header comes out like this ✨

From: Erik Newmann <root@SURFnet.nl>
Reply-To: Admin@SURFnet.nl
To: Allocchio@elettra.ts.it
Cc: netman@MailFLOW.dante.net
Subject: enjoy this nice picture!
Organisation: SURFnet bv
Message-Id: <21235.25442281@SURFnet.nl>

ngl, this method technically bends the canonical conversion principles 🙈 but it gives users the maximum functionality they need, and it keeps things consistent when a single message gets converted more than once 💜

Chapter 3 - Basic Mappings 🍓

the basic mappings listed in MIXER and its updates should be fully used, periodt 💅

now, encoding RFC822 addresses that contain quotes ('"') into Mail-11 needs some extra care 🎀 Mail-11 addresses can't contain that character, because it's reserved for delimiting "quoted strings" themselves (like when you're using the Mail-11 foreign mail protocol). so an address like this one

"John Poe"@Mixergw.local.ca.us    (RFC822)

can't go into a Mail-11 foreign mail protocol address 'as is', since the quotes in the LHS section cause chaos 😭 so the quotes have to be encoded. MIXER spells out exactly how to encode quotes and other characters when translating RFC822 addresses into X.400. Mail-11 addresses aren't limited to printablestring the way X.400 is, but a subset of the MIXER encoding can be used for the quotes character and, as a direct consequence, for open and closed round brackets '(' and ')' 🌈 like this:

smtp%"(q)John Poe(q)@Mixergw.local.ca.us"

Chapter 4 - Addressing - Mail-11 / X.400 🦋

4.1. Mail-11 addressing 📮

Mail-11 addressing can go from super simple to pretty complex, especially if other Mail-11 to "something-else" gateways are involved 🌸 but no matter what, a Mail-11 address is an ASCII string made up of different elements.

4.2. X.400 addressing 🌍

on the other hand, an X.400 O/R address is a collection of attributes, and it can still be shown as an IA5 textual representation, as defined in RFC1685 and CCITT F.401, Annex B ✨

4.3. Mail-11 address components 🧩

let's break down the parts of a Mail-11 address, because the syntax is a little different between Phase IV and DECnet/OSI, so pay attention bestie 👀

Phase IV: we look at a Mail-11 address as made up of 3 parts:

[route] [node::] local-part

here route and node are optional, and only local-part is compulsory 💅

DECnet/OSI: we look at a Mail-11 address as made up of 3 parts too:

[net:] [node-clns::] local-part

here net and node-clns are optional, and only local-part is compulsory 💖

here's the formal definition of these elements, no cap, it's a whole vibe 🎀

node = *(ALPHA/DIGIT) / *DIGIT / *DIGIT "." *DIGIT

route = *(node "::")

subdomain = *(ALPHA/DIGIT)
node-clns = *("." subdomain)

net = *(ALPHA/DIGIT)

local-part = username / nickname / for-protocol

username = *(ALPHA/DIGIT)

nickname = <printablestring - <" " and HTAB>>

for-protocol = (f-pref f-sep <">f-address<">)

f-pref = *(ALPHA/DIGIT)

f-sep = "%" / "::"

f-address = printablestring / RFC822-address / X400-text-address

X400-text-address = <textual representation of an X.400 O/R addr>

one thing to note: in x400-text-address, both the ";" notation and the "/" notation are equivalent and allowed (see the examples in the different sections) 🌟

here are some examples for Phase IV 🍓

route           node    local-part
-----------------------------------------------------------
                        USER47
                MYNODE::BETTY
BOSTON::CLUS02::GOOFY1::MARY34
                        IN%"M.P.Tracy@Dicdum.cc.edu"
        UCLA13::MVAX93::MRGATE::"MBOX1::MBX34::MYC3::BOB"
                MIAMI2::George.Rosenthal
        CCUBVX::VS3100::Jnet%"IAB3425@IBAX23L"
                        MRGATE::"C=xx::A=bbb::P=ppp::S=Joe"
                MAINVX::IN%"path1!path2!user%dom"
                GWX400::gw%"C=xx;ADMD=aaa;PRMD=ppp;S=Lee;"
                GX409A::x400%"/C=xx/A=aaa/P=ppp/S=Lee"
                        smtp%"postmast@nodeb.bitnet"
        MICKEY::PRFGAT::profs%"NANCY@IBMB"
                        edu%"HU427BD%CSUNIB@abc.acme.edu"

and now some examples for DECnet/OSI 💜

net  node              local-part
-----------------------------------------------------------
                        USER47
     .IT.MYDOM1.MYNODE::BETTY
OMNI:.US.GOV.LB.GOOFY1::MARY34
                        IN%"M.P.Tracy@Dicdum.cc.edu"
NET1:.SALES.ADM.MVAX93::MRGATE::"MBOX1::MBX34::MYC3::BOB"
       .FR.LYON.MIAMI2::George.Rosenthal
     .AU.ABXY2W.VS3100::Jnet%"IAB3425@IBAX23L"
                        MRGATE::"C=xx::A=bbb::P=ppp::S=Joe"
 INT:.GB.3LABV56.MAINV::IN%"path1!path2!user%dom"
                GWX400::gw%"C=xx;ADMD=aaa;PRMD=ppp;S=Lee;"
                        smtp%"postmast@nodeb.bitnet"
OMNI:.DE.TEST.V1.GWY32::GX409A::x400%"/C=xx/A=aaa/P=ppp/S=Lee"

also, DECnet/OSI can have Phase IV-like node names, the so-called "Phase IV compatibility node names", but no route term is allowed in front of them 🙈 if the address has a DECnet/OSI net and/or node specification plus an old Phase IV node address (like the last one in the examples above), then the old Phase IV node name (GX409A) counts as the local-part 🫶

Chapter 5 - Mapping - Mail-11 / X.400 🌈

5.1. Mapping scheme ✨

okay so the DECnet phase IV address field is literally a "flat land" 🌸 with some obliged routes to reach hidden areas. That means a truly hierarchical mapping scheme using mapping rules (like the ones that work for RFC822) is not the move here. Instead we define a fixed set of encoding rules that use DDAs support 💅.

The DECnet/OSI address field is different. It's hierarchical, a real domain style organization that looks super similar to RFC822 domain addresses 😭. BUT the old Phase IV flat addressing schema is still valid in DECnet/OSI networks too, especially the so called 'Phase IV short aliases' 🙈. So to keep the mapping as simple as possible, the same set of fixed rules using DDAs encoding is used for both Phase IV and DECnet/OSI addresses 🎀.

Another big thing is that DECnet phase IV has many disjoint networks sharing the same DECnet address space. A common X.400 and/or RFC822 mailing system acts as the glue connecting these different isolated Mail-11 islands 🦋. In DECnet/OSI this is handled more canonically, with the concept of 'net', a unique name identifying the single internally fully interconnected DECnet network that shares the same DECnet/OSI name space.

To uniquely identify each DECnet Phase IV network, we extend the DECnet/OSI concept of 'net' to this case too ✨. We define 'net' in Phase IV as a unique ASCII string identifying the DECnet network we are connected to. If the Phase IV network is already migrating and interconnected to DECnet/OSI areas, the 'net' identifier already used in those DECnet/OSI areas is automatically extended to the whole DECnet community 👑.

If the network still uses Phase IV protocols only, a 'net' identifier must be chosen. In this case the 'net' element identifies the DECnet community being served, but it could differ from the actual official network name. It is recommended that the same 'net' identifier be adopted unmodified when the eventual migration to DECnet/OSI takes place within that DECnet community 🫶.

Aliases are allowed for the 'net' identifier. Some well known identifiers and aliases:

    net = 'OMNI'         the High Energy Physics & Space Physics
                         DECnet network;

aliases:

    net = 'HEPnet'       alias for 'OMNI'
    net = 'SPAN'         alias for 'OMNI'

The need to label each DECnet network with its name also comes from the requirement to implement the 'intelligent' gateway. That's the gateway that understands it can connect directly to the specified DECnet network, even if the O/R address specifies a path to a different gateway 🧚. A more detailed discussion of the problem is in 5.3 and 5.5.

A registry of 'net' attributes must be established to make sure names are unique 🔥. This registry is the same one created for migration to DECnet/OSI. A simple table coupling 'net' and the gateway address is also used, in a syntax similar to the 'gate1' and 'gate2' tables used in MIXER. An example:

     OMNI#OU$Cosine-gw.O$@.PRMD$infn.ADMD$garr.C$IT#
     OMNI#O$ESRIN1.PRMD$esa.ADMD$Master400.C$it#
     HEPnet#OU$Cosine-gw.O$@.PRMD$infn.ADMD$garr.C$IT#
     HEPnet#O$ESRIN1.PRMD$esa.ADMD$Master400.C$it#
     SPAN#OU$Cosine-gw.O$@.PRMD$infn.ADMD$garr.C$IT#
     SPAN#O$ESRIN1.PRMD$esa.ADMD$Master400.C$it#

Ambiguous left entries are allowed. Gateway implementations can simply choose one of the specified gateways, or try them all in cyclic order to get better performance 💜.

Aliases are set up in this gate table too. You just add equivalent entries to the table, like the 'HEPnet' and 'SPAN' entries 🌈. BUT, aliases must only be used to let users use commonly used names. Any gateway implementing this specification must generate addresses with official 'net' names only (so 'OMNI' for the table above) 💀.

The Mail-11 gateways table is, however, just the list of the appropriate MIXER address translation) RFC822 world. Any other gateway implementing this specification (and the related ones) should use its local name as first choice for the Mail-11 'net' it can reach, and use the official Mail-11 gateway table only to reach the ones it is not connected to. This list of Mail-11 gateway entries is supposed to contain the 'net' tags and their aliases. Since this list is usually small, we currently don't take into account distribution mechanisms for this information other than a static table 🍓.

In order to keep the mapping rules very simple, we avoid the need to analyse Mail-11 addresses to distinguish the 'route', 'node', and Attributes (DDAs) needed to cover the mapping problem 🙈.

5.2. Mail-11 --> X.400

We define the following Domain Defined Attributes to map a Mail-11 address:

     DD.Dnet
     DD.Mail-11

So the Mail-11 Phase IV mapping rule is:

     route::node::localpart

which maps into:

     C=xx; ADMD=yyy; PRMD=zzz; O=ooo; OU=uuu; DD.Dnet=net;
     DD.Mail-11=route::node::localpart;

Meanwhile, the mapping rule for Mail-11 DECnet/OSI is:

     net:node-clns::localpart

which maps into:

     C=xx; ADMD=yyy; PRMD=zzz; O=ooo; OU=uuu; DD.Dnet=net;
     DD.Mail-11=node-clns::localpart;

with:

xx = country code of the gateway performing the conversion
yyy = Admd of the gateway performing the conversion
zzz = Prmd of the gateway performing the conversion
ooo = Organisation of the gateway performing the conversion
uuu = Org. Unit(s) of the gateway performing the conversion
net = name of the DECnet network (e.g., OMNI, HEPnet, SPAN,...)

(zzz, ooo, and uuu are used or dropped as needed to identify the gateway performing the conversion uniquely within the X.400 MHS 💅.)

The following defaults also apply:

If 'node' (or 'node-clns') is missing and we are mapping the Mail-11 originator (From), then 'node' (or 'node-clns') defaults to the DECnet node name of the gateway (gwnode).
If 'node' (or 'node-clns') is missing and we are mapping the Mail-11 recipient (To, Cc), then 'node' (or 'node-clns') defaults to the DECnet node name of the 'From' address.
If 'net' is missing, it defaults to a value defined locally by the gateway. If the gateway is connected to one DECnet network only, then 'net' is the name of that unique network. If the gateway is connected to more than one DECnet network, the gateway establishes a 'first choice' DECnet network, and 'net' defaults to this value.

The 'node' syntax (DECnet/OSI or Phase IV) depends on the DECnet protocol implemented and on the value of a system parameter (usually the MAIL$SYSTEM_FLAGS one) on the gateway host 🖥️.

If 'local-part' contains 'x400-text-address', see also section 6.4.3.

If 'local-part' contains 'RFC822-address', see also section 6.4.4.

5.2.1. Examples

Let's suppose that:

the DECnet network name (net) is 'OMNI';
the DECnet node name of the gateway (gwnode) is '.IT.DM.X4TDEC', alias 'X4TDEC' in Phase IV;
the Country Code of the gateway is 'IT' and its ADMD is 'garr' (and these two fields are enough to identify the gateway uniquely within the X.400 MHS).

Then the examples look like this 🎀:

USER47
 C=it; ADMD=garr; DD.Dnet=OMNI; DD.Mail-11=.IT.DM.X4TDEC::USER47;

MYNODE::BETTY
 C=it; ADMD=garr; DD.Dnet=OMNI; DD.Mail-11=MYNODE::BETTY;

BOSTON::GOOFY1::MARY34
 C=it; ADMD=garr; DD.Dnet=OMNI; DD.Mail-11=BOSTON::GOOFY1::MARY34;

.DE.UNI-BN.PHYS.NODE18::MARY34
 C=it; ADMD=garr; DD.Dnet=OMNI;
 DD.Mail-11=.DE.UNI-BN.PHYS.NODE18::MARY34;

UCLA13::MVAX93::MRGATE::"MBOX1::MBX34:MYC3::BOB"
 C=it; ADMD=garr; DD.Dnet=OMNI;
 DD.Mail-11=UCLA13::MVAX93::MRGATE::(q)MBOX1::MBX34::MYC3::BOB(q)

ENET:.US.CENTRAL.MIAMI2::George.Rosenthal
 C=it; ADMD=garr; DD.Dnet=ENET;
 DD.Mail-11=.US.CENTRAL.MIAMI2::George.Rosenthal;

MRGATE::"C=xx::A=bbb::P=ppp::S=Joe"
 C=it; ADMD=garr; DD.Dnet=OMNI;
 DD.Mail-11=X4TDEC::MRGATE::(q)C=xx::A=bbb::P=ppp::S=Joe(q)

MAINVX::In%"path1!path2!user%dom"
 C=it; ADMD=garr; DD.Dnet=OMNI;
 DD.Mail-11=MAINVX::In(p)(q)path1(b)path2(b)user(p)dom(q)

5.3. X.400 encoding of Mail-11 --> Mail-11

To make sure path reversibility holds when a message crosses multiple Mail-11/X.400 gateways, we have to distinguish two cases 🦋.

Case one: DD.Dnet=net is known to the gateway as one of the DECnet networks it is connected to. In this case the mapping is trivial:

C=xx; ADMD=yyy; PRMD=zzz; O=ooo; OU=uuu; DD.Dnet=net;
DD.Mail-11=route::node::localpart;

(see sect. 5.2 for explication of 'xx','yyy','zzz','ooo','uuu','net')

maps into:

route::node::localpart

And for DECnet/OSI addresses:

C=xx; ADMD=yyy; PRMD=zzz; O=ooo; OU=uuu; DD.Dnet=net;
DD.Mail-11=node-clns::localpart;

maps into:

net:node-clns::localpart

Case two: DD.Dnet=net is NOT known to the gateway as one of the DECnet networks it is connected to. In this case the mapping rule described in section 5.4 applies:

C=xx; ADMD=yyy; PRMD=www; DD.Dnet=net;
DD.Mail-11=route::node::localpart;

maps into:

gwnode::gw%"C=xx;ADMD=yyy;PRMD=www;DD.Dnet=net;
DD.Mail-11=route::node::localpart;"

Again, for DECnet/OSI addresses:

C=xx; ADMD=yyy; PRMD=www; DD.Dnet=net;
DD.Mail-11=node-clns::localpart;

maps into:

gwnode::gw%"C=xx;ADMD=yyy;PRMD=www;DD.Dnet=net;
DD.Mail-11=node-clns::localpart;"

5.3.1. Examples

Let's suppose that:

the DECnet network name (net) is 'OMNI';
the DECnet node name of the gateway (gwnode) is '.IT.DM.X4TDEC', alias 'X4TDEC' in Phase IV;
the Country Code of the gateway is 'IT' and its ADMD is 'garr';

(and these two fields are enough to identify the gateway uniquely within the X.400 MHS).

C=it; ADMD=garr; DD.Dnet=OMNI;
DD.Mail-11=X4TDEC::MRGATE::(q)C=ab::A=dsa::P=qwty::OU=mie::S=Cly(q)
  MRGATE::"C=ab::A=dsa::P=qwty::OU=mie::S=Cly"

C=it; ADMD=garr; DD.Dnet=EASYNET; DD.Mail-11=ROM01::CARLO;
  X4TDEC::gw%"C=it;ADMD=garr;DD.Dnet=EASYNET;
  DD.Mail-11=ROM01::CARLO;"

(in the above example 'EASYNET' is supposed to be not connected to our gateway located on the .IT.DM.X4TDEC DECnet node 🌸).

5.4. X.400 --> Mail-11

The mapping of an X.400 O/R address into Mail-11 is done by encoding the various attributes into the X400-text-address, as defined in chapter 4 of MIXER, and including this as 'f-address'. A 'f-pref' and a the DECnet node name of the gateway are involved too 💌.

So:

x400-text-address

will be encoded like:

gwnode::gw%"x400-text-address"

with the spaces dividing attributes being optional ✨.

5.4.1. Example

Let's suppose that:

the DECnet node name of the gateway (gwnode) is '.IT.DM.X4TDEC', alias 'X4TDEC' in Phase IV, and 'net' is 'OMNI'.

So:

C=gb; ADMD=G400; PRMD=AC.UK; O=ucl; S=Clay;

will be encoded like:

X4TDEC::gw%"/C=gb/A=G400/P=AC.UK/O=ucl/S=Clay"

or, with the ";" notation and the DECnet/OSI 'node', its equivalent:

OMNI:.IT.DM.X4TDEC::gw%"C=gb;ADMD=G400;PRMD=AC.UK;O=ucl;S=Clay;"

5.5. Mail-11 encoding of X.400 --> X.400 ✨

Okay so, it can happen that Mail-11 is used to relay messages between X.400 systems 🫶 That means multiple X.400/Mail-11 gateway crossings, and we'll run into Mail-11 addresses containing embedded X.400 informations. To keep path reversibility intact, we have to distinguish two cases 💅

the embedded X.400 address belongs to a domain whose naming and routing rules are known to the global X.400 MHS. In this case the mapping is trivial:

route::gwnode::gw%"x400-text-address"

or (for DECnet/OSI)

net:gwnode::gw%"x400-text-address"

maps into

x400-text-address

'route' and 'gwnode' are mapped into X.400 Trace service elements.

the encoded X.400 domain does not belong to the global X.400 name space. In this case the mapping rule described into section 5.2 apply:

route::gwnode::gw%"x400-text-address"

maps into

C=xx; ADMD=yyy; DD.Dnet=net;
DD.Mail-11=route::gwnode::gw(p)(q)x400-text-address(q);

and (for DECnet/OSI)

net:gwnode::gw%"x400-text-address"

maps into

C=xx; ADMD=yyy; DD.Dnet=net;
DD.Mail-11=gwnode::gw(p)(q)x400-text-address(q);

The latter case is deprecated and must be regarded as a possible temporary solution only, while waiting to include into the global X.400 MHS also this domain. ⚠️

5.5.1. Examples 🧚

Let's suppose that:

the DECnet network name (net) is 'OMNI';
the DECnet node name of the gateway (gwnode) is '.IT.DM.X4TDEC' alias 'X4TDEC' in Phase IV;
the Country Code of the gateway is 'IT' and its ADMD is 'garr'; (and these two fields are enough to identify uniquely the gateway within the X.400 MHS).

X4TDEC::gw%"C=fr;ADMD=atlas;PRMD=ifip;O=poly;S=Moreau;"
  C=fr; ADMD=atlas; PRMD=ifip; O=poly; S=Moreau;

X4TDEC::gw%"C=zz;ADMD= ;PRMD=Botwa;O=Miner;S=Chiuaw;"
  C=it; ADMD=garr; DD.Dnet=OMNI;
  DD.Mail-11=X4TDEC::gw(p)(q)C=zz;ADMD= ;
  PRMD=Botwa;O=Miner;S=Chiuaw;(q)

(in the above example C=zz is unknown to the global X.400 MHS) 🙈

Chapter 6 - Mapping - Mail-11 / RFC822 💌

6.1 Introduction 🌸

The implementation of a Mail-11 - RFC822 gateway was faced by many software developers independently, and was included in many mail products which were running on both VMS and UNIX systems. As there was not a unique standard mapping way, the implementations resulted into a number of possible variant methods to map a Mail-11 address into an RFC822 one. Some of these products became then largely widespread, starting to create a number of de facto mapping methods.

In this chapter some sort of standardisation of the mapping problem is considered, trying to be compatible with the existing installed software. We must also remind that, in some cases, only simple Mail-11 addresses could be mapped into RFC822, having complex ones producing all sort of quite strange results. In case DECnet/OSI Mail-11 addresses are involved we must also notice that only one mapping method can be used from/to RFC822 addresses.

On the other hand, the mapping of an RFC822 address in Mail-11 was quite straightforward, resulting in a common definition which uses "Mail-11 foreign mail protocol" to design an RFC822 address:

[[node::][node::]...]prot%"rfc-822-address"

[node::][node::]...]prot::"rfc-822-address"

or again for DECnet/OSI addresses

[net:][node-clns::]prot%"rfc-822-address"

[net:][node-clns::]prot::"rfc-822-addres"

6.2 De facto implementations 🍓

A considerable number of de-facto implementations of Mail-11/RFC822 gateways is existing. As said in the introduction, the mapping of RFC822 addresses in Mail-11 is accomplished using the foreign mail protocol syntax and is thus unique.

On the other hand, Mail-11 addresses are encoded in RFC822 syntax in various ways. Here are the most common ones:

a) "node::user"@gateway-address
b) user%node@gateway-address
c) user@node.decnet.domains
d) user%node.dnet@gateway-address

Let's have a quick look to these different choices. 👀

a - This form simply encloses as quoted Left Hand Side string the original Mail-11 address into the RFC822 address of the Mail-11/RFC822 gateway. This method is fully conformant with RFC822 syntax, and the Mail-11 address is left untouched; thus no encoding rules need to applied to it. This method applies also easily to DECnet/OSI Mail-11 addresses. 💖

b - As one will immediately notice, this form has nothing in it indicating the address is a Mail-11 one; this makes the encoding indistinguishable from a similar encoding of RSCS (BITnet) addresses used by some IBM VM Mailer systems. It should thus be deprecated. 🙅‍♀️

c - In this case a sort of 'reserved word' (DECnet) embedded into the address itself identifies the presence of a Mail-11 original address preceding it. The decoding is possible, dropping 'domains' and extracting 'user' and 'node' parts. However complex Mail-11 addresses cannot be mapped properly in this syntax, and there is no specific rule for adding the 'domains' part of the address. 🤔

d - In this case again there is a 'reserved word' (dnet) which make possible the identification of the original Mail-11 address; 'gateway-address' points to the Mail-11/RFC822 gateway and 'node' and 'user' information can be easily drawn from the address. However complex Mail-11 addresses cannot be embedded easily into this syntax. 🫠

Note the only methods a) can be successfully used for DECnet/OSI Mail-11 addresses, while the other cases are already too complex to encode in a unique way such addresses in RFC822. 📌

6.3 Recommended mappings 🎀

From the examples seen in the previous paragraphs we can derive a canonical form for representing the mapping between Mail-11 and RFC822.

6.3.1 RFC822 mapped in Mail-11 🦋

The mapping of an RFC822 address in Mail-11 is straightforward, using the "Mail-11 foreign mail protocol" syntax. The two possible variants for Phase IV are:

[[node::][node::]...]prot%"rfc-822-address"

[node::][node::]...]prot::"rfc-822-address"

The equivalent two possible variants for DECnet/OSI are:

[net:][node-clns::]prot%"rfc-822-address"

[net:][node-clns::]prot::"rfc-822-address"

6.3.2 Mail-11 mapped in RFC822 🌈

RFC822 foresee a canonical form for representing non-RFC822 addresses: put the foreign address in local part (Left Hand Side, LHS) is a form as similar as possible to its original syntax. Thus the suggested mapping both for Phase IV and DECnet/OSI is:

"Mail-11-address"@gateway-address

This format assures also the return path via the appropriate gateway. 🛤️

6.3.3 Mail-11 (foreign mail protocol) mapped in RFC822 💜

A Mail-11 address containing a foreign mail protocol syntax can also contain the percent '%' character as a separator between the foreign protocol name and the actual address itself. In some cases the address part can also be an unquoted string. Some examples:

deliver%swan
myprot%root.owner
listserv%my-private.list.A1

If these addresses are encoded into an RFC822 address using the "natural" method described in 6.3.2, they will result in something which can be easily mismatched with an address using the percent hack in LHS for source routing.

"myprot%root.owner"@lohost.mydom.edu    (Mail-11 address)

"LISTSERV%IBMB.BITnet"@bitgate.anu.edu  (% routing address)

The percent hack is strongly deprecated, and thus should be avoided; the second address above shoud be expressed as: 🚫

@bitgate.anu.edu:"LISTSERV@IBMB.BITnet"

However, in order to assure maximum functionality and avoid problems, it is recommended to encode Mail-11 addresses containing the foreign protocol specification in RFC822 syntax using the DD.Mail-11 and DD.dnet qualifiers, i.e.

"/DD.Mail-11=myprot%root.owner/DD.dnet=OMNI"@lohost.mydom.edu

The DD.dnet defaults as indicated in the similar cases for the Mail-11 / X.400 mappings. This encoding method can, of course, also be used to map any other Mail-11 address in RFC822, and is the only one which enable to specify the network name ('OMNI' in the above example) for DECnet Phase IV Mail-11 addresse. The method is fully compatible with the results also produced by gateways following the MIXER specification for Mail-11 addresses encoded in X.400 and then translated into RFC822. 🥰

Chapter 7 - Complex mapping - X.400 / Mail-11 / RFC822 🔥

7.1. The protocol triangle 🔺

The bilateral mappings described in chapters 5 and 6 must be extended in order to cover also the case in which also RFC822 addressing is involved, and the following triangular situation occurs:

                               X.400
                               /  \
                              /    \
                             /      \
                         Mail-11----RFC822

The X.400 - RFC822 side is fully covered by MIXER, and the previous chapters in this document cover the Mail-11 - X.400 side and the Mail-11 - RFC822 one. 🧩

7.2. RFC822 mapped in Mail-11 📬

The 'RFC822-address' is usually included in 'local-part' as

route::gwnode::gw%"rfc822-address"

or the equivalent in DECnet/OSI:

net:gwnode::gw%"rfc822-address"

An example in Phase IV

NVXA23::SMTPGW::in%"M.T.Rose@CS.UCLA.edu"

and another one in DECnet/OSI

OMNI:.FR.INET.LABOL.SMTPGW::in%"M.T.Rose@CS.UCLA.edu"

7.3. Mail-11 mapped in RFC822 💅

There are different styles in mapping a Mail-11 address in RFC822; let's have a short summary of what was traditionally done in some implementations.

7.3.1 Mail-11 address encoded in "Left Hand Side" (LHS) of RFC822 address, using "%" syntax or "::" syntax 🫧

route::node::localpart      (Phase IV)

maps to

localpart%node%route@gw-domains

"route::node::localpart"@gw-domains

Again, let's consider the DECnet/OSI case:

net:node-clns::localpart      (DECnet/OSI)

maps to

"net:node-clns::localpart"@gw-domains

(note that "%" encoding does not exist for this case)

where 'gw-domains' identify uniquely the Mail-11 / RFC822 gateway.

7.3.2 Mail-11 address maps partly to LHS and partly to 'domain' part of RFC822 address 🌷

node::localpart

maps to

localpart@node.gw-domains

note that this kind of mapping does not exists with DECnet/OSI Mail-11 addresses.

7.3.3 Mail-11 address is completely hidden by a mapping table 🙈

In this case the resultant RFC822 address contains no trace at all of the original Mail-11 address.

7.4. Multiple conversions 🔁

Let us now examine briefly the possible situations which involve multiple conversions, having one protocol as a relay between the other two. This summary suggest some possible enhanced solutions to avoid heavy and unduly mappings, but the 'step by step' approach, considering blindly one conversion as disjointed to the other, as described in the previous sections, can always be used. ✨

7.4.1. X.400 --> RFC822 --> Mail-11 💅

Okay bestie, step one: we run the MIXER rules, and that gives us an RFC822 address 🎀 Then that address can be mapped into Mail-11 using the 'f-address' field, just like we saw in section 7.2 ✨

an example:

C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Jim; S=Clay;

maps accordingly to MIXER to

Jim.Clay@cs.UCL.AC.UK

and finally becomes

SMTPGW::In%"Jim.Clay@cs.UCL.AC.UK"

and finally becomes

SMTPGW::In%"Jim.Clay@cs.UCL.AC.UK"

where 'SMTPGW' is the DECnet Phase IV node name of the machine running the RFC822 to Mail-11 gateway 🌸 And if the machine running that gateway is a DECnet/OSI one (like OMNI:.US.VA.CENTRL), we get this instead 🦋

OMNI:.US.VA.CENTRL::In%"Jim.Clay@cs.UCL.AC.UK"

7.4.2. Mail-11 --> RFC822 --> X.400 🧚

Okay, so some of the mappings from section 7.3 for Phase IV work on the Mail-11 address, and they hide its origin completely 🙈 MIXER handles the last step 💜

an example:

RELAY::MYNODE::BETTY

could map into RFC822 as

BETTY%MYNODE@RELAY.dnet.gw1.it

and accordingly to MIXER

C=it; A=garr; P=dom1; O=gw1; OU=RELAY; S=BETTY(p)MYNODE;

where 'dnet.gw1.it' is the domain of the machine running the Mail-11 to RFC822 gateway 🍓

7.4.3. X.400 --> Mail-11 --> RFC822 🫶

So the X.400 address gets stored in the Mail-11 'f-address' element, as described in sections 5.3 and 5.4 🎀 Then, if the Mail-11 to RFC822 gateway can spot an 'x400-text-address' inside the Mail-11 address, it applies MIXER to it and encodes header. Otherwise, it applies the rules from 7.3 instead 🔥

an example:

C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Jim; S=Clay;

will be encoded like

X4TDEC::gw%"/C=gb/A=Gold 400/P=AC.UK/O=UCL/OU=cs/G=Jim/S=Clay"

If the Mail-11 to RFC822 gateway recognises the x400-text-address, then the address becomes, accordingly to MIXER

Jim.Clay@cs.UCL.AC.UK

and the following RFC822 header line is added

Received: from X4TDEC with DECnet (Mail-11) on xx-xxx-xxxx.

Otherwise one of the dumb rules could produce

gw%"/C=gb/A=Gold 400/P=AC.UK/O=UCL/OU=cs/G=Jim/S=Clay"@X4TDEC.doms

The DECnet/OSI Mail-11 case is conceptually identical 🌈

7.4.4. RFC822 --> Mail-11 --> X.400 💖

The RFC822 address gets encoded into the Mail-11 f-address element, as described in sect. 7.2 ✨ Then, if the Mail-11 to X.400 gateway can understand an 'RFC822-address' inside the Mail-11 address, it applies MIXER to it, encodes 'route', and applies the rules from 5.2 and 5.5 💅

an example:

Jim.Clay@cs.UCL.AC.UK

will be encoded like

SMTPGW::In%"Jim.Clay@cs.UCL.AC.UK"

If the Mail-11 to X.400 gateway recognises the RFC822-address, then the address becomes, accordingly to MIXER

C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Jim; S=Clay;

and a 'trace' record gets added into the X.400 P1 data, saying a node named SMTPGW was crossed 👑

Otherwise the dumb rule produces

C=it; ADMD=garr; DD.Dnet=HEP;
DD.Mail-11=SMTPGW::In(p)(q)Jim.Clay(a)cs.UCL.AC.UK(q)

Again, the DECnet/OSI Mail-11 addresses are conceptually identical 🦋

7.4.5. RFC822 --> X.400 --> Mail-11 🌸

We apply MIXER to the first conversion, which gives us an X.400 address ✨ Then the rules from sections 5.3 and 5.4 store that X.400 address as 'x400-text-address' inside the Mail-11 🎀

an example:

Jim.Clay@cs.UCL.AC.UK

maps accordingly to MIXER to

C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Jim; S=Clay;

and finally becomes

SMTPGW::gw%"/C=gb/A=Gold 400/P=AC.UK/O=UCL/OU=cs/G=Jim/S=Clay"

where 'SMTPGW' is the DECnet Phase IV node name of the machine running the X.400 to Mail-11 gateway 🧚 No differences for DECnet/OSI Mail-11 addresses either, no cap 💜

7.4.6. Mail-11 --> X.400 --> RFC822 🍓

The Mail-11 address gets encoded as specified in sections 5.2 and 5.5, and then MIXER converts it into RFC822 🫶

an example:

RELAY::MYNODE::BETTY

maps into X.400 as

C=it; ADMD=garr; DD.Dnet=OMNI; DD.Mail-11=RELAY::MYNODE::BETTY;

and accordingly to MIXER

"/C=it/A=garr/DD.Dnet=OMNI/DD.Mail-11=RELAY::MYNODE::BETTY"@gw2.it

where 'gw2.it' is the domain of the machine running the MIXER gateway 💅

7.4. Conclusions 🎀

Okay, the big takeaway: a standard way of mapping Mail-11 addresses into RFC822 and back is totally feasible ✨ So the suggestion is to unify all existing and future implementations 🦋 It's worth noting, though, that for DECnet Phase IV it could be impossible to specify the name of the decnet community that owns the encoded address in these mappings. You can always do that for X.400, so the 'intelligent' gateway might not be possible in this case 🥺

Chapter 8 - Notifications and Probes 🌈

8.1. Overview 💜

Mail-11 is a real time protocol, which means the connection goes straight to the destination node 🧚 That makes some nice services possible, like checking an address and delivery confirmation ✨

Mail-11 User Agents usually don't support notification or probe services, though 🙈 You can still deliver the result of a notification or a probe to Mail-11, though. This section briefly covers the level of service you can get for these when Mail-11 is involved 💅

8.2. Delivery of Notifications via Mail-11 🫶

As we covered in the previous chapters, complex information can be transported over Mail-11 with minimal loss, and that includes Notifications 🎀 In RFC822/MIME, Notifications are encoded as MIME multipart messages, so there's no problem carrying them over Mail-11 like any other MIME message 🌸 X.400 Notifications can be transported and delivered via Mail-11 too, because MIXER describes how to convert them into MIME multipart messages, which takes us back to the previous situation 👑

Even when Mail-11 is just an intermediate step for a Notification message, this consideration still enables support for the service 🔥

8.3. Generation of Notifications and Probes from Mail-11 🌸

Mail-11 doesn't support Notification or Probe, but the service could still be supported at gateway level 💖 Because Mail-11 is real time, the gateway could be reasonably sure whether delivery to the other end of the Mail-11 path succeeded or failed (and it could try to verify whether delivery is feasible when a Probe is requested) 🧚 However, Mail-11 could just be an intermediate relay service, and then the value of that information vanishes 😭

So implementing this kind of service at gateway level is questionable. If it's done, it should clearly state the situation where it was generated, and the "confidence level" it conveys 🫶

Security Considerations 💀

Security issues are not discussed in this memo. 😭 Be careful out there, bestie: this document doesn't cover them, so don't assume anything about security from it 🔥

Acknowledgements 🫶

I want to thank everyone who read the first draft and gave us such useful suggestions for this revision, especially RARE WG1, the IETF X.400 ops group members, and S. E. Kille 💖

Thanks also to a bunch of implementors (including Ned Freed, Julian Onions, and the Hebrew University of Tel Aviv Pine VMS support team), to the HEPnet Mail Technical Committee, and to all my Mail-11 "end users", especially Enzo Valente 🌸 Your suggestions and wishes helped me so much with this revision of former RFC1405 🥹✨

References 📚

[1] CCITT, "CCITT Recommendations X.400-X.430", Message Handling Systems: Red Book, October 1984.
[2] CCITT, "CCITT Recommendations X.400-X.420", Message Handling Systems: Blue Book, November 1988.
[3] CCITT/ISO, "CCITT Recommendations X.400/ ISO IS 10021-1," Message Handling: System and Service Overview , December 1992.
[4] Crocker D., "Standard of the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDel, August 1982.
[5] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, January 1998.
[6] Alvestrand H., Kille S., Miles R., Rose M., and Thompson S., (MIME-MHS) "Mapping between X.400 and RFC-822 Message Bodies," RFC 1495, Aug 1993.
[7] Digital Equipment Corp., "VMS Mail Utility".
[8] Joiner Associates Inc., "Jnet User's Manual".
[9] PMDF User's Guide.
[10] Alvestrand, H. "Writing X.400 O/R Names", UNINETT / RFC1685, August 1994.
[11] CCITT, "F.401 CCITT Message Handling Services - Operations and Definitions of Service - Naming and Addressing for Public Message Handling Services, Annex B (08/92)", August 1992.

Author's Address 🦋

Claudio Allocchio
Sincrotrone Trieste
SS 14 Km 163.5 Basovizza
I 34012 Trieste
Italy

Phone:   +39 40 3758523
Fax:     +39 40 3758565
EMail:  Claudio.Allocchio@elettra.Trieste.it
        C=it; A=garr; P=Trieste; O=Elettra; S=Allocchio; G=Claudio;

Full Copyright Statement ⭐

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

📦 where this page comes from

ietf: rfc2162 1998-01
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms