RFC 1465
Routing Coordination for X.400 MHS Services Within a Multi Protocol / Multi Network Environment Table Format V3 for Static Routing
Network Working Group RFC 1465 💌
Routing Coordination for X.400 MHS Services Within a Multi Protocol / Multi Network Environment: Table Format V3 for Static Routing ✨
Author: U. Eppenberger, SWITCH 🦋 Date: May 1993 📅 Category: Experimental 🧪
This one is an Experimental Protocol, and the title block doesn't list anything it obsoletes or updates. 💅
Status of This Memo 📝
This memo defines an Experimental Protocol for the Internet community. 🧪 Discussion and suggestions for improvement are requested, so bestie, weigh in! 🫶 For the standardization state and status of this protocol, check the current edition of the "IAB Official Protocol Standards." 📚 Distribution of this memo is unlimited. 🌈
1. Introduction 💖
Okay so X.400 Message Handling System (MHS) usage is blowing up, especially in the commercial world 📈, but the academic and research community is super into it too 🎓. New networks and new addresses show up every single day 🌸. The underlying technology for different X.400 networks can vary depending on the transport network and the X.400 MHS implementations being used 🛠️. A ton of X.400 implementations now support multiple stacks, and that's the iconic part! ✨ It means a world wide message handling service can run on the same electronic mail standard 🌍, without needing gateways that reduce service 🙅♀️, and without being stuck on a single common transport network 🚫.
BUT (and this is the tea 🍵) this creates a couple of problems for the MHS manager, and two of them are:
- Where do I route new X.400 addresses and
- How do I connect to a MHS domain that uses an underlying technology that I do not support.
This document proposes short term solutions to these problems. 🎀 It lays out a strategy for maintaining and distributing routing information, and shows how messages can travel over different networks by using multi stack MTAs as relays. 🔁 The document formats and coordination procedures bridge the gap until an X.500 directory service is ready to store the needed connectivity and routing information. 🌉 The format is designed so the information can be stored in an X.500 directory service, while managers without directory service access can still use a table based approach. 🧚
The routing structure proposed can be applied to a global MHS service, but it may also be used at a national level or even within an organisation. 🏢
Many experts from the IETF X.400-Operations Group and RARE Working Group 1 on Message Handling Systems read drafts of this document and contributed ideas and solutions. 🫶 The author would especially like to thank Harald Alvestrand, Erik Huizer, Marko Kaittola, Allan Cargille and Paul-Andre Pays. 💜
This is the third version of a table format. 📋 The first one was in use within COSINE-MHS for about two years. Then a second version with major enhancements was proposed, and it has been in use for the past year. 🔥 The third version will probably be the last one before it becomes possible to switch to dynamic, directory service based routing. 👑
2. Terminology 🧠
MHS community 🌐
One or more MHS domains form an MHS community. Mail exchange between these MHS domains is defined by the coordination procedures within this document. 📬 Examples of such communities are the Global Open MHS service GO-MHS and the COSINE-MHS service. ✨
MHS domain 🏠
One or more MHS subtrees form an MHS domain. This is a purely administrative grouping of MHS subtrees. 🗂️ It's helpful if someone is responsible for several MHS subtrees to refer to an MHS domain instead of listing all the subtrees. 💅
MHS subtree 🌳
An MHS subtree consists of the total of the mailboxes addressable within a subtree of the X.400 OR address space. 📮
Example:
O=SWITCH; P=SWITCH; A=ARCOM; C=CH;That's the MHS domain of SWITCH in Switzerland, consisting of all mailboxes with O=SWITCH; P=SWITCH; A=ARCOM; C=CH; in the OR address. 🇨🇭🎀
RELAY-MTA 🔁
An X.400 MTA serving one or several MHS domains. 🦋 Heads up: the term WEP (Well Known Entry Point) was used from the early X.400ies (1987/88) until now, which gives the wrong impression of a single entry point, and therefore a single point of failure. 😬 This document proposes using the term RELAY-MTA instead, since it reflects the functionality of the MTA more clearly. 💖
COSINE-MHS 🇪🇺
The COSINE-MHS community is mainly formed by European X.400 service providers from the academic and research area, and each of them is a member of RARE. 🎓 The COSINE-MHS community is used in the annex as an example of using this document in a multinational environment. 🌍
3. Requirements 📏
X.400 MTAs can communicate using different transport and network protocol stacks. 🧦 For this document, the stacks used in a WAN environment need to be considered:
Stack 1 Stack 2 Stack 3 Stack 4
Transport Layer 4 TP0 TP4 RFC1006 TP0
Networkservice 1-3 X.25 CLNS TCP/IP CONSHaving a common protocol stack is not the only requirement for two MTAs to communicate. 🙈 The networks the MTAs belong to also need to be interconnected. 🔗 Some well known networks are listed here, together with the stacks they use:
Network Stack Abbreviation
Public Switched Packet Data Networks 1 Public-X.25
International X.25 Infrastructure EMPB 1,4 EMPB-X.25
US and European connectionless pilot 2 Int-CLNS
Internet 2,3 InternetNote that several stacks may be supported over a single network. 🧩 However, communication between MTAs is only possible if the MTAs share at least a common stack AND a common network. 🫵 That's the big catch! 😭
Unlike SMTP/TCP/IP systems, there is no directory service available that would let an MTA look up the next MTA to which it should submit a message. 😵 Routing within X.400 will stay table based until a solution using X.500 directory services is available. 🗺️
Furthermore, it is not generally allowed to connect to any MTA, even on the same network, without being registered on the destination MTA. 🚪 These restrictions call for a large coordination effort and carefully configured and updated systems. 🥲💅
4. Outline of the proposal 🗺️
This proposal offers a solution for describing information about X.400 message routing within an MHS community, in RELAY-MTA and DOMAIN documents. 📄 Basic information on the MHS community is documented in the corresponding COMMUNITY document. 🪧 All contact persons and RELAY-MTA administrators can be found in PERSON documents. 👩💻 A future X.500 based solution may need extended information to overcome still unsolved problems, like optimal routing or traffic optimization for messages with multiple recipients. 🔮 The information collected for the intermediate solution, however, is very basic. ✨ All established coordination procedures will help, and even speed up, the future introduction of an X.500 based solution. 🚀
4.1 The COMMUNITY document 🌈
For each MHS community there exists one single COMMUNITY document containing basic information. 📘 It starts with the contact information for the central coordination point, together with the addresses of the file server where all the documents are stored. 🗄️ It also lists the network names and stacks to be used in the RELAY-MTA and DOMAIN documents. 📝 An MHS community must agree on its own set of mandatory and optional networks and stacks. 🤝
4.2 The RELAY-MTA document 🔁
Every MHS domain in the community may designate one or more MTAs as RELAY-MTAs. 🧚♀️ These RELAY-MTAs accept incoming connections from the RELAY-MTAs of the other MHS domains, and in return they are allowed to send messages to those RELAY-MTAs. 💌 A RELAY-MTA is documented with all of its necessary connection information in the corresponding RELAY-MTA document. 📑
4.3 The DOMAIN document 🏡
An MHS domain has a responsible person who sets up the routing entries for the domain in the DOMAIN document. 🧑💼 The primary RELAY-MTAs listed in the DOMAIN document as serving this MHS domain must, TOGETHER, offer at least connectivity to all networks and stacks listed as mandatory in the COMMUNITY document. 🫂 Optional RELAY-MTAs may be added, generally with higher priority, to allow more precise routing. 🎯
An MHS domain may also decide not to operate a RELAY-MTA. 🙌 It will then only need agreements with one or more RELAY-MTAs from other MHS services which will relay for this domain. 🤙 The domain itself, however, must either create its own DOMAIN document or document its MHS subtrees jointly with another MHS domain. 🤝
The structure of the DOMAIN document is very straightforward. 🍓 It starts off with one or more MHS subtrees, each on its own line. 📏 After the domains comes a line indicating the responsible person for the MHS subtrees mentioned. 🧑💻 Finally, the responsible RELAY-MTA(s) are listed with appropriate priorities. 🏁
4.4 The PERSON document 🪪
All administrators and responsible persons are documented in PERSON documents. 📇 The RELAY-MTA and DOMAIN documents only contain keys pointing to a PERSON document. 🔑 If such a person can already be found in an X.500 directory service, the key consists of a Distinguished Name. Otherwise, the key is just their OR address. 💌
4.5 Coordination 🤝
This approach requires an identified coordination point. ☎️ It is up to the MHS community to decide on the level of coordination and support to be provided, and on the funding mechanisms for those activities. 💸 Basic information can be found in the COMMUNITY document. 📘 The following list of support activities is considered mandatory for an operational service:
- New RELAY-MTAs joining the service are tested, and support is given to create the RELAY-MTA document.
- New MHS domains joining the MHS community get assistance to set up RELAY-MTA(s) and/or find appropriate RELAY-MTA(s), and to create DOMAIN documents.
- Updated documents are announced to the RELAY-MTA managers and responsible persons for the DOMAIN documents, unless automatic distribution is used.
- All the RELAY-MTA, DOMAIN and PERSON documents are made available on a file server together with the COMMUNITY document. The file server must at least be reachable via email. MHS communities with a big number of documents may consider additional access methods like ftp and FTAM. 📂
- Tools should be made available to manage routing tables for the X.400 software used on the RELAY-MTAs, or to fill in and check the documents. The format of the documents has specifically been chosen to enable the use of automated tools. 🛠️
The RELAY-MTA managers must be aware that a large number of RELAY-MTAs in an MHS community may require significant operational resources to keep the local routing tables up-to-date and to constantly monitor the correct functioning of the connections. 😮💨 On the other hand, more than one RELAY-MTA with good connectivity to an MHS domain improves the overall robustness of the domain, and thus the QOS. 🛡️💖
MHS communities may decide on additional mandatory requirements for operating a RELAY-MTA. 📞 These may include a hot line, echo services, exchange of statistics, response time to problem reports, uptime of the RELAY-MTA, etc. ⏱️ This ensures a certain quality of service for the end users. 👑✨
4.6 Routing 🛣️
Okay so this proposal is built for MHS communities that span a bunch of different organisations 💅. But honestly? It can also be used to manage routing inside one single organisation, or even a whole global MHS community 🌍✨
There are two kinds of mail relays: primary RELAY-MTAs and secondary RELAY-MTAs 🎀. A primary or secondary RELAY-MTA MUST allow incoming connections from all other primary and secondary RELAY-MTAs with a common stack. Primary RELAY-MTAs MUST be able to connect to all other primary RELAY-MTAs which share a common stack 🫶. A secondary RELAY-MTA MUST connect to at least one primary RELAY-MTA 💖.
Each MHS community MUST define update procedures for the routing based on the documentation. Automated update has to be studied carefully 👀.
An MHS community SHOULD also define procedures for new RELAY-MTAs and MHS domains joining the service 🚪. Since the usage of X.400 is growing rapidly, a flexible but well coordinated way of integrating new members into an MHS community is needed 📈. The proposed documentation format supports this by allowing primary and secondary RELAY-MTAs. All RELAY-MTAs accept incoming connections from each other. Sending messages can be done by using the primary RELAY-MTAs only. This allows new RELAY-MTAs to join the community as secondary and to get primary status when traffic flow increases. Secondary RELAY-MTAs MAY also require a longer testing period 🧪.
5. The documents 📚
The definition is given in BNF-like syntax. The following conventions are used:
| means choice
\ is used for continuation of a definition over several lines
[] means optional
{} means repeated one or more times
() is used to group choices
\" is used for double quotes in a text string
<CR> is a Carriage Return and means that the next section starts
on its own line.The definition is complete only to a certain level of detail. Below this level, all expressions are to be replaced with text strings. Expressions without more detailed definition are marked with single quotes '. The format and semantics SHOULD be clear from the names of the expressions and the comments given.
Wherever the BNF definition requires a single blank, multiple blanks MAY be used to increase the readability. Please note that for some field values the number of spaces is significant 🤓.
Lines exceeding 80 characters SHOULD be wrapped at any convenient blank except at blanks which are significant. The line is continued with at least one leading blank.
Comments MAY be placed anywhere in the document but only on separate lines and without splitting wrapped lines. Such a comment line MUST either start with a '#' sign followed by white space and the comment or consist of a single '#' on a single line.
The documents MUST follow the case of the strings defined in BNF. Note that some values, especially connection parameters like TSEL or MTA password are case dependant too 🔠.
The BNF definitions are ordered top-down. See Appendix B for an alphabetically sorted list.
A set of one COMMUNITY document and several RELAY-MTA, DOMAIN and PERSON documents belong together. The detailed definitions can be found in the following chapters 🧚.
<X.400 routing coordination document set> ::= \
<COMMUNITY-document> \
{ <RELAY-MTA-document> } \
{ <DOMAIN-document> } \
{ <PERSON-document> }5.1 Common Definitions ✨
okay bestie, this is the glossary section 🫶 every definition below is a little grammar rule, and the way-too-cute prose after each one tells you what it actually means 💖 the grammar goes in code blocks so nothing gets lost in translation 🎀
DirectoryName 📇
<DirectoryName> ::= 'Distinguished Name'the string form of a Distinguished Name is defined in the RFCxxxx 💅 if you use a Distinguished Name as a key in the documents, you can grab the info straight from the directory instead of checking the document 👀 BUT, as long as not every manager in the same community has directory access, the same info also has to live in a document 🙈 and in the routing documents, Distinguished Names are just key strings that point to other documents 🦋
Community-Identifier 🌸
<Community-Identifier> ::= "Community: " \
('community name' | <DirectoryName>) <CR>the 'community name' is a string that names the MHS community, and it goes on the first line of every document ✨
UniqueRELAY-MTAkey 🔑
<UniqueRELAY-MTAkey> ::= (([ "P=" 'PRMDname' "; " ] \
["A=" 'ADMDname' "; " ] \
"C=" <Country-Code> "; " \
"MTAname=" 'MTAname')
| <DirectoryName> )every RELAY-MTA needs a unique key so it can be identified 🧚 besides the MTA name itself, the plan is to use the OR address attributes of the management domain where the RELAY-MTA lives 🏡 the ADMD and PRMD fields are both optional, but they can be used to guarantee uniqueness 💜 the values themselves don't matter, and even non-printable characters like @ or ! are fine 🙃 the result is a key string, not an address, and a Distinguished Name can be used instead 💅
UniquePersonKey 🧑💼
<UniquePersonKey> ::= (<X.400 address> | <DirectoryName> )this key is necessary so that any document needing a responsible person or an administrator can link to the PERSON documents 🔗 it's either the OR address of the person, or a Distinguished Name if the person is already registered in the directory 🌈
Country-Code 🗺️
<Country-Code> ::= 'Two Character Country Code ISO-3166'a two-character country code, per ISO-3166 🌍
X.400 address 📬
<X.400 address> ::= 'OR address, ISO 10021-2 Annex F'this format is used consistently all over the document, and it's also why the syntax of the <UniqueRELAY-MTAkey> and the <MHS-subtree> looks the way it does 🫶 examples:
S=user; O=org ltd.; OU1=sect1; P=org; A=rel400; C=aq;
DDA:RFC-822=we(a)sell.it; P=internet; A= ; C=xx;
G=john; I=w; S=doe; P=org; A=rel400; C=aq;EMail 📧
<EMail> ::= "Address: " <X.400 address> <CR>an email entry is the word "Address: " followed by an X.400 address 💌
tel-no-list, tel-number, int-pref, national number, extension 📞
<tel-no-list> ::= <tel-number> [{"; " <tel-number>}]<tel-number> ::= {"+" <int-pref> " " <national number> \
[" x" <extension>]}<int-pref> ::= 'international prefix'<national number> ::= 'national telephone number'<extension> ::= 'local extension'the tel-number syntax follows the attribute syntax of the X.500 directory, which is based on CCITT E.123 ☎️ a national number can be written with spaces and hyphens to group the figures, so it's easier to read 🥰
Phone 📱
<Phone> ::= "Phone: " <tel-no-list> <CR>one or more phone numbers 💕
Fax 📠
<Fax> ::= "Fax: " <tel-no-list> <CR>one or more FAX numbers 🖨️
Mail 📮
<Mail> ::= "Mail: " 'postal address information' <CR>the items of the postal address are separated by ' /' wherever the next item goes onto a new line on a printed address label 🏷️ if the document is for an international community, the address should include the person's country 🌏 example:
Mail: SWITCH Head Office / Urs Eppenberger /
Limmatquai 138 / CH-8001 Zurich / Switzerlandwhich gives you this mailing label:
SWITCH Head Office
Urs Eppenberger
Limmatquai 138
CH-8001 Zurich
SwitzerlandUpdate-info 🗓️
<Update-info> ::= "Update: FORMAT=V3; DATE=" 'yymmdd' \
"; START=" 'yymmdd' \
["; END=" 'yymmdd'] <CR>the Update-info also carries the format identifier 🪪 the date of the last update of a document is written as 'yymmdd' 📅 a start date must be set, and a document can be published this way before the information in it is actually valid ⏳ (this is especially useful when there aren't automated tools, because the RELAY-MTA managers get more time to get their systems ready 🛠️) an end date sets an expiration date for the document 🥀
P-address 🧭
<P-address> ::= 'String encoded Presentation Address'the format follows RFC1278, A string encoding of Presentation Address, and RFC1277, Encoding Network Addresses to support operation over non-OSI layers 🌐 see chapter 5.2 for how macros are used in a Presentation Address 🔍
Service-type 🛤️
<Service-type> ::= <Network-name> "/" \
<Network-service> "/" \
<Transport-Protocol>the service type is one string made of three parts joined with a "/": Network-name/Network-service/Transport-Protocol 🧩
Network-name, Network-service, Transport-Protocol 🌐
<Network-name> ::= 'Name of a network'<Network-service> ::= 'Name of a network service'<Transport-Protocol> ::= 'Name of a transport protocol'the network-name identifies a network 🛰️ a well known key word should be chosen for it, and no '/' character is allowed 🚫 examples of network names: Public-X.25, Internet, EMPB-X.25, Int-CLNS, WIN, Janet, 💫 network service examples: X.25, CONS, CLNS, TCP 🧃 transport protocol examples: TP0, TP2, TP4, RFC1006 🎀
since the network and stack info form one string, it's an easy way to tell whether two RELAY-MTAs have a connection possibility 🤝 the COMMUNITY document defines the strings to be used in the RELAY-MTA and DOMAIN documents 📝 some examples:
Internet/TCP/RFC1006
Public-X.25/X.25/TP0
RARE-IXI/CONS/TP0
RARE-CLNS/CLNS/TP4⚠️ tea time for this one: this string has nothing to do with the format of a presentation address, which is defined by Steve Hardcastle-Kille in RFC1278 🫖 the problem of networks that use the same address structure (X.121 DTEs, 4 Byte Internet addresses) but aren't connected to each other isn't addressed in RFC1278 🙃 it's solved by using the service identifier above in addition to the presentation address 💡 as long as there are network islands, there's no other way than adding an 'island'-identifier 🏝️
MHS-subtree 🌳
<MHS-subtree> ::= ["O=" 'Organization-name' "; "] \
["OU1="'OrganizationalUnit'"; "\
["OU2=" 'OrganizationalUnit' "; " \
["OU3=" 'OrganizationalUnit' "; " \
["OU4=" 'OrganizationalUnit' "; "]]]] \
["P=" 'PRMDname' "; "] \
"A=" 'ADMDname' "; " \
"C=" <Country-Code> ";"this is the X.400-style layout that the MHS-subtree uses, so the X.400 address section above explains the syntax here too 🪞
Operation ⏰
<Operation> ::= "Reachable: " {<time> "-" <time> "; "} \
<Time-zone> <CR><time> ::= 'hh:mm'<Time-zone> ::= ("UTC+" | "UTC-") 'hhmm'this operation info tells everyone what time someone is reachable, which matters a LOT for communities that span several time zones 🌏✨ the 'hhmm' is a four digit value: the first two digits are hours, and the second two digits are minutes 🕐 use "UTC+" for time zones east of Greenwich 🧭 to work out the current time at the remote place, use this simple formula:
local-time - local-displacement + remote-displacement =
remote-timefor example:
18:00 - (UTC + 0100) + (UTC - 0800) = 09:00the <Time-zone> entry can be followed by a comment line that says when Daylight Saving Time is in effect 🌞🌛 this is especially handy for MHS communities spanning continents on the northern and southern hemispheres 🦘
5.2. The COMMUNITY document ✨
okay bestie, this is the front page of the whole community's paperwork 📄💖 The very first line names the <Community-Identifier>, and every other document in that same community has to carry it in its header 🫶 It's also recommended to add a few comment lines describing the members of this MHS community. So cute 🌸
<COMMUNITY-document> ::= <Community-Identifier> \
<Update-info> \
<COMMUNITY-document-body>The body is the actual meat 🍓
<COMMUNITY-document-body> ::= <Coordination> \
[{<Macro-definition>}] \
{<Connections>}The coordination part is basically a contact card for the coordination point 💌 It has an email, a phone, a fax, a postal mail address, the operation details, and the file server info, all in one spot.
<Coordination> ::= <EMail> <Phone> <FAX> \
<Mail> <Operation> <File-server>Now the file server, which is giving main character energy 👑 All documents must be available, at the very least, to the managers of the MHS domains and the RELAY-MTAs through an email server. If FTAM and FTP are available too, writing automated update tools becomes way easier 🔥 It's suggested to have a single server. If there's only one, you only need one single X.400 OR address to reach it. For FTP and FTAM, though, you might have more system addresses, depending on how many network connections you have (or "service types," as this document calls them) 🦋
<File-server> ::= <email-server> [{<FTP-server>}] \
[{<FTAM-server>}]The email server line is simple: it's just the X.400 address of the file server 📧
<email-server> ::= "Mail-server: "<X.400 address> <CR>The FTP server gets a domain name, an account name, and optionally a password 🧚 Usually it's something like "anonymous" and "guest," lowkey the classic combo 🙈 Some servers want the RFC822 address of the user. You document that by writing the string 'user@domain' as the password entry. But the point is NOT to literally type 'user@domain' as your password when you log in (even though it would generally work, since the software often just checks for an @ sign). Instead, you use your own RFC822 email address 💅
<FTP-server> ::= "FTP-server: " 'domain name' "; " \
'account-name' ["; " 'password'] <CR>FTAM servers take a P-address, an account name, an optional password, and optionally a Distinguished Name from the X.500 directory 🌈 The account name is often case sensitive, so be careful, bestie 🙃 Some FTAM servers allow anonymous access with the account name ANON. And you can only document an FTAM server with a Distinguished Name if that server is registered in the directory. No shortcuts 💀
<FTAM-server> ::= "FTAM-server: " <P-address> "; "\
'account-name' ["; " 'password'] \
["; X.500 " <DirectoryName>] <CR>Macros are where it gets a little messy 🌀 Presentation addresses without macros are honestly unreadable. RFC1278 suggests a few macros, and all the macros that are allowed in a community must be defined in the COMMUNITY document. It's recommended to use the macros proposed in RFC1278 and add new ones if you need them ✨
<Macro-definition> ::= "Macro: " 'Macro name' " " \
'Macro value' <CR>Here are the example macros from RFC1278, which are very much the vibe 🎀
Macro: Int-X25(80) TELEX+00728722+X.25(80)+01+
Macro: Janet-X25(80) TELEX+00728722+X.25(80)+02+
Macro: Internet-RFC-1006 TELEX+00728722+RFC-1006+03+Last but not least, the connections. You have to list mandatory service types, and you can add optional ones too 🦋 Note that at least one mandatory service type is needed, so don't forget it 🫶
<Connections> ::= {<mandatory-service>} \
{[<optional-service>]}<mandatory-service> ::= "Mandatory-Service: " \
<Service-type> <CR><optional-service> ::= "Optional-Service: " \
<Service-type> <CR>5.3. The RELAY-MTA document 🧚
The RELAY-MTA document is the full profile for one single RELAY-MTA 💜 Only one community is allowed per document. Some of the info depends on the community, so it wouldn't really be possible to share one RELAY-MTA document across different communities 🙅♀️
<RELAY-MTA-document> ::= <Community-Identifier> \
<Update-info> \
<RELAY-MTA-document-Identifier> \
<RELAY-MTA-document-body>The identifier line is just the RELAY-MTA name, with a unique key 🏷️
<RELAY-MTA-document-Identifier> ::= \
"RELAY-MTA: " <UniqueRELAY-MTAkey> <CR><RELAY-MTA-document-body> ::= <Status> <connection-info> \
<contact-info>Status is either primary or secondary, and that's a big deal 👑 Check section 4.3 and 6 for more info on that.
<Status> ::= "Status: " ("primary" | "secondary") <CR>The connection info is where things get detailed 🔥 A RELAY-MTA that supports several networks and protocol stacks can have more than one set of connection information 🌸
<connection-info> ::= <password> <RTS> \
{<called-connection><calling-connection>}\
[<system>] \
[<local-domain>] \
[<echo-server>]Passwords have three options, and they're all a little different 🔐 If the keyword none is there, no password gets sent with the MTAname when this MTA starts an RTS connection or answers an incoming one. Like this:
Password: noneIf the keyword secret is there, the connection needs a password that is not publicly available. For example, a community might keep a list of the passwords at the central coordination point, and then fax the list to the RELAY-MTA managers 🙈
Password: secretA password you actually write out has to use the value="password" notation, and the double quotes are needed. Even a single blank counts as a password, so be precise 💅
Password: value=" "
Password: value="nume-n-ine"<password> ::= "Password: " \
("secret" | "none" | \
"value=\"" 'password' "\"") <CR>RTS is the dialog setup 🦋 The dialog mode is either TWA or MONOLOGUE. The checkpoint size and window size are optional, but they come as a pair if you use them 💖
<RTS> ::= <dialog-mode> \
[<checkpoint-size> <window-size>]<dialog-mode> ::= "RTS-dialog-mode: " \
("TWA" | "MONOLOGUE") <CR><checkpoint-size> ::= "RTS-checkpoint-size: " \
'checkpoint size' <CR><window-size> ::= "RTS-window-size: " \
'window size' <CR>Called-address is the destination side of a connection 📞 It has a service type, a P-address, an MTS value, and optionally a service priority.
<called-connection> ::= "Called-address: " \
<Service-type> "; " \
<P-address> "; " <MTS> \
["; " <Service-priority>] <CR>There are three MTS options, and each one maps to its own longer name 🌈 X.400(84) systems only support mts-transfer-protocol-1984, so that's the one they need 🙃 For more details, check ISO 10021-6, Section 3, chapter 11.1.
<MTS> ::= "MTS-T" | "MTS-TP" | "MTS-TP-84"
MTS-T: mts-transfer
MTS-TP: mts-transfer-protocol
MTS-TP-84: mts-transfer-protocol-1984The service priority is an integer from 0 to 99, and the lowest number is the highest priority, same as in DNS 🍓 You can set a different priority for each service type. That's useful if you want to spread the load across networks based on how much bandwidth each one has 🔥
<Service-priority> ::= 'Integer 0..99'Calling-address is the other side of the coin 📲 Called and calling network addresses can be different in some setups, and some X.400 systems check the calling network address during validation. So it's important to have this info in the RELAY-MTA document. Heads up though: a calling X.121 address can change if the X.25 switch gets reconfigured. If that happens, a RELAY-MTA that relies on address validation might stop connecting to other RELAY-MTAs, even though you didn't change anything at the higher layers! 😭
<calling-connection> ::= "Calling-address: " \
<Service-type> "; " \
<P-address> <CR>The system line is optional, and it holds the hardware, OS, and MHS software info 🖥️ Providing it isn't required, but experience has shown that a bunch of communication problems were way easier to identify and solve when this info was there and up to date ✨
<system> ::= "System: HW=" 'computer type' "; " \
"OS=" 'operating system' "; " \
"SW=" 'MHS software' <CR>The local domain is a useful extra, but it's still optional 🧚 The MHS subtree is local to the RELAY-MTA. Its attributes can be used together with S=nosuchuser; to run connectivity and availability tests 💜
<local-domain> ::= "LocalDomain: " <MHS-subtree> <CR>Some RELAY-MTAs offer an echo server, and it's smart to document that here for testing 🧪 This field is optional, obviously 🫶
<echo-server> ::= "EchoServer: " <X.400 address> <CR>Finally, the contact info. The contact details for the RELAY-MTA administrator live in the matching PERSON document 🎀 You can document a whole team with a distribution list if you really want to, but it's generally better to list one or more real persons 💅
<contact-info> ::= {"Administrator: " <UniquePersonKey> <CR>}5.4 The DOMAIN document 🗺️
Okay so the DOMAIN document is basically the community's routing map, and it has three parts: a community identifier, an update line, and the body. Here's the shape of it, bestie 💅
<DOMAIN-document> ::= <Community-Identifier> \
<Update-info> \
<DOMAIN-document-body>
<DOMAIN-document-body>::= {<Domain-entry>} <responsible> \
{<Relay>}
<Domain-entry> ::= "Domain: " <OR-matching> <MHS-subtree> <CR>Note that it is not allowed to have equal <Domain-entry> lines in different DOMAIN documents belonging to the same MHS community. A Domain-entry line can only appear in one DOMAIN document. No copy-paste duplicates, periodt 🙅♀️
The <OR-matching> qualifier is the vibe check for how the following OR address attributes get handled by the routing algorithm 🔍
<OR-matching> ::= ( "* " | "= " )If a * is present, a destination address of a message is matched by the "Domain:" entry if at least the OR address attributes in the "Domain:" entry are equal to the destination address. 🌸
If a = is present, a destination address of a message is matched by the "Domain:" entry if there are exactly the same OR attributes in the destination address as in the "Domain:" entry. (This restriction works for OU4, OU3, OU2, OU1, O, P, A and C only.) So strict, so iconic 😤
Here's an example to make it click ✨
a) Domain: * P=switch; A=arcom; C=ch;
b) Domain: = P=switch; A=arcom; C=ch;The address S=eppenberger; P=switch; A=arcom; C=ch; matches both cases, a) and b). 🎀
The address S=eppenberger; O=unibe; P=switch; A=arcom; C=ch; matches only case a). Because it has that extra O=unibe in there, the exact = version says nope 🙈
<responsible> ::= {"Administrator: " <UniquePersonKey> <CR>}This is the person responsible for the listed domains. Their job is to get the agreement of the relaying RELAY-MTAs and keep the DOMAIN document up-to-date. This person is the only one authorized to make changes to this document. Note that multiple administrators may be listed, so it's giving group project energy 👑
<Relay> ::= "Relay: " \
( 'UniqueRELAY-MTAkey' | \
"Internet-SMTP" ) "; " \
<RELAY-MTA-Priority> <CR>The priority is used to define the sequence in which different RELAY-MTAs may be tried in case of failure. A lower integer corresponds to a higher priority, just like DNS. Priorities 0..49 are used to indicate backup RELAY-MTAs 🛟 Priorities 50..99 are used for RELAY-MTAs not acting as backup but as relay service provider for a network service type not supported by the main RELAY-MTA. Different job, different range, no drama 💜
The keyword "Internet-SMTP" is a placeholder for an RFC1327 gateway connected to Internet. The RELAY-MTA manager selects a gateway of their choice 🌈
<RELAY-MTA-Priority> ::= <Integer 0..99>5.5 The PERSON document 🧚
The PERSON document is the contact card for each member of the community, and it's lowkey the cutest one 🎀
<PERSON-document> ::= <Community-Identifier> \
<Update-info> \
<PERSON-document-identifier> \
<PERSON-document-body>
<PERSON-document-identifier> ::= "Key: " <UniquePersonKey> <CR>
<PERSON-document-body>::= <Name> {<EMail>} {<RFC822>} \
<Phone> <Fax> <Mail> <Operation>The <Name> line is "Name: " followed by the name of the person. The issue of the character set problem is not addressed in this document. Especially international communities should restrict themselves to IA5 or ASCII, so keep it simple, bestie 🔤
<Name> ::= "Name: " 'name of person' <CR>The <RFC822> line is the RFC-822 address of the person. It is often a big help to know the RFC822 address of someone, for example if the X.400 system is not reachable. That's also the reason why it is possible to provide multiple OR and RFC822 addresses. The first one is considered the primary one, so it's the main character of the list 🦋
<RFC822> ::= "RFC822: " <RFC-822-address> <CR>6. Routing rules 🛣️
Okay, the routing rules are where it all comes together, and honestly so satisfying 🤩
All the users within the MHS community have the right to send messages to each other. The general agreement is that the RELAY-MTA infrastructure is used according to the following routing rules. More direct connections based on bilateral agreements are fully accepted, so if two friends want a direct line, go for it 🫶
A primary or secondary RELAY-MTA must allow incoming connections from all other primary and secondary RELAY-MTAs with a common stack. Primary RELAY-MTAs must be able to connect to all other primary RELAY-MTAs which share a common stack. A secondary RELAY-MTA must connect to at least one primary RELAY-MTA. Everyone's got a role and a responsibility here 💅
A message arriving at a RELAY-MTA must either be sent to the next RELAY-MTA based on the DOMAIN documents of the MHS community, or it is sent to an MTA closer to the destination based on local routing decisions. The following algorithm must be used when forwarding a message to the next RELAY-MTA 🔥
- Select the relevant DOMAIN document by searching for a match of the Recipient address in the message with the entries in the document.
If your own RELAY-MTA appears in this list, this indicates one of the following:
- You offered relay services for another RELAY-MTA with higher priority. Continue with step 2 to decide on the next RELAY-MTA.
- Your RELAY-MTA is the final destination according the DOMAIN document of your community. You need to forward the message to the final destination according local routing information.
- From the list of RELAY-MTAs select those that have at least one common network service type with your own RELAY-MTA. 🔍
- Now delete all secondary RELAY-MTAs from the list where no direct connection is desired. For remaining RELAY-MTAs in the list no difference is made anymore between primary and secondary status. Everybody's equal now ✨
- Select from this reduced set of RELAY-MTAs the one with the highest RELAY-MTA-priority. If there is more than one RELAY-MTA having the same priority, then select a RELAY-MTA of your choice. If your own RELAY-MTA appears in that list, then you are not allowed to send to a RELAY-MTA with lower or equal priority. No going backwards, no cap 🙅♀️
- If there are no service-priorities set in the corresponding RELAY-MTA document indicating which service type to use, you are free to choose the service type for connecting to the RELAY-MTA. However, if there are specific priorities set, then select the service type with the highest priority. 🎯
- If the connection fails, then try other service types in the sequence of descending priority. 🔁
- If no connection works for the selected RELAY-MTA, then check in the list for the one with the same priority, if possible, or else select one with the next lower priority. If there is another RELAY-MTA with a RELAY-MTA-priority between 0..49, then select it and proceed at step 5. Without another RELAY-MTA to try, the currently selected RELAY-MTA will be retried. Persistence is everything 💪
6.1 How to use RELAY-MTA-priorities 🌸
An example helps to explain the usage of RELAY-MTA-priorities, and this one is so good 😭
Internet/TCP/RFC1006 and Public-X.25/X.25/TP0 are mandatory service types in the community REMOTEmail. The MHS domain P=REMOTE; A=ARCOM; C=CH; operates MTA-B, which is only connected to public X.25. A second RELAY-MTA which is connected to both Internet and public X.25 is needed to offer relay services. A connection using Internet is considered cheap in this example. Both service types are available at MTA-A. Since MTA-B is the only RELAY-MTA responsible for relaying messages to P=REMOTE; A=ARCOM; C=CH; to the final destination, it must have the highest priority. 👑
Here's the config:
Community: REMOTEmail
Domain: * P=REMOTE; A=ARCOM; C=CH;
RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-B; 20
RELAY-MTA: P=MTA-C; A=ARCOM; C=CH;MTAname=MTA-C; 80
__________________________
+-------+ X.25 +-------+ ( )
| MTA-A +-------------+ MTA-B +-( P=REMOTE; A=ARCOM; C=CH; )
+-------+ +-------+ (__________________________)
\ /
TCP/IP \ /X.25
+-------+
| MTA-C |
+-------+If MTA-A needs to relay a message for P=REMOTE; A=ARCOM; C=CH;, then the rules of chapter 6 are evaluated, step by step 🧠
- MTA-B and MTA-C are possible destinations
- MTA-B and MTA-C are reachable from MTA-A
- MTA-B is a primary RELAY-MTA (not relevant in this example)
- MTA-B has the highest priority.
- MTA-B doesn't have specific service type lines documented. MTA-A chooses public X.25, since it is the only possibility to connect to MTA-B.
- No other service types are available if the connection fails.
- MTA-C has a priority of 80, it is not a backup RELAY-MTA. MTA-A must spool the message and try to connect directly to MTA-B.
The organisation running MTA-A could save money by sending messages for the MHS domain P=REMOTE; A=ARCOM; C=CH; via MTA-C. Since the connection between MTA-C and the destination MTA-B is also expensive, the organisation running MTA-C would have to pay for external relay traffic. Setting a lower priority for MTA-C forces the other RELAY-MTAs with public X.25 connectivity to take their share of the cost. That's the fairness plot twist 🥹
Note that forcing other RELAY-MTAs to use a specific stack should be avoided wherever possible by offering RELAY-MTAs with equal priority for all mandatory network services. This can be an important financial issue for MHS communities spanning several organisations, it is not relevant in general for an MHS community within a single organisation.
6.2 How to use RELAY-MTA-priorities for backup RELAY-MTAS 🛟
Two RELAY-MTAs offer real backup connectivity for the MHS domain P=REMOTE; A=ARCOM; C=CH;. It is therefore possible to set RELAY-MTA priorities in the range of 0..49 for both RELAY-MTAs. MTA-B will be the preferred one since it has the higher priority. If the connection to MTA-B fails, a sending RELAY-MTA may immediately try to connect to MTA-C. Backup squad assemble 🫡
Community: REMOTEmail
Domain: * P=REMOTE; A=ARCOM; C=CH;
RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-B; 10
RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-C; 30
__________________________
+-------+ +-------+ ( )
| MTA-A +-------------+ MTA-B +-( P=REMOTE; A=ARCOM; C=CH; )
+-------+ +-------+ (__________________________)
\ /
\ +-------+
-----------+ MTA-C |
+-------+6.3. Load Sharing 🎀
okay so load sharing is a whole vibe, but it's kinda tricky bestie 😭. You can give RELAY-MTAs equal priorities to try and share the load. BUT most implementations can't do random selection between RELAY-MTAs with equal priorities. They just follow a fixed config 💀. So if you really need load sharing, the suggested move is to split the MHS domain into several MHS subtrees, document each one separately, and give each set of RELAY-MTAs different priorities. 🦋
Here's the first option, with equal RELAY-MTA-priorities (iykyk 💅):
Community: REMOTEmail
Domain: * P=REMOTE; A=ARCOM; C=CH;
RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-B; 10
RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-C; 10
_ __________________________
) +-------+ ( )
)--+ MTA-B +--( P=REMOTE; A=ARCOM; C=CH; )
) +-------+ (__________________________)
) /
) +-------+/
)--+ MTA-C |
_) +-------+And here's an example where the MHS domain C=CH;ADMD=ARCOM;PRMD=REMOTE;O=Big-Org is documented with its own DOMAIN document. Note that in this example both RELAY-MTAs serve as backup RELAY-MTAs. 🫶
Community: REMOTEmail
Domain: * P=REMOTE; A=ARCOM; C=CH;
RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-B; 10
RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-C; 30
Community: REMOTEmail
Domain: * O=Big-Org; P=REMOTE; A=ARCOM; C=CH;
RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-C; 10
RELAY-MTA: P=REMOTE; A=ARCOM; C=CH;MTAname=MTA-B; 30
_ __________________________
) +-------+ ( )
)--+ MTA-B +--( P=REMOTE; A=ARCOM; C=CH; )
) +-------+ (__________________________)
) \/
) /\ _____________________________________
) +-------+ ( )
)--+ MTA-C |--( O=Big-Org; P=REMOTE; A=ARCOM; C=CH; )
_) +-------+ (_____________________________________)7. Open issues ✨
Right now there are about 35 RELAY-MTAs in the COSINE-MHS service, which is giving steady, healthy vibes 💖. A rough guess is that a network with about 60 RELAY-MTAs is still manageable, as long as there are automated tools for MTA configuration. If even more MTAs apply for RELAY-MTA status in an MHS community, then either an X.500 based solution should be ready, or a core set of about 30 well operated super-RELAY-MTAs should form a backbone, documented within a specific MHS community. 💜
Since the RELAY-MTA document contains info about the supported X.400 version (84 or 88), an X.400(88) system can select an (88)RELAY-MTA with higher priority. The rules in chapter 6 could be modified to select X.400(88) systems first if the sending RELAY-MTA is an (88) system itself. How to establish an X.400(88) RELAY-MTA infrastructure within an MHS community is for further study 🔥.
Appendix A: Document examples for the COSINE-MHS community 🌈
Instead of making up fake documents, this appendix has extracts from a real operational X.400 service, which is so much more iconic 🧚. The research and development community in Europe has been using X.400 for several years. This proposal was first written just for that community, to fix their urgent routing and coordination problems. Contributions from different experts made it more flexible, so hopefully it's useful for other MHS communities too ✨.
Appendix A1: The COMMUNITY document 🍓
Community: COSINE-MHS
# The COSINE-MHS service is a MHS community formed by the European
# academic and research networks with additional contacts in all
# other continents.
#
# The coordination is done by the COSINE-MHS project team.
#
Update: FORMAT=V3; DATE=921218; START=930201
#
Address: S=Project-Team; O=SWITCH; P=SWITCH; A=ARCOM; C=CH;
#
Phone: +41 1-262-31-43
Fax: +41 1-261-81-88
#
Mail: SWITCH Head Office /
MHS Coordination Service /
Limmatquai 138 /
CH-8001 Zurich /
Switzerland
#
Reachable: 09:00-12:00; 14:00-17:30; UTC+1
#
Mail-server: S=mhs-server; O=switch; OU1=nic;
P=SWITCH; A=ARCOM; C=CH;
FTP-server: nic.switch.ch; cosine; user@domain
#
Macro: Int-X25(80) TELEX+00728722+X.25(80)+01+
Macro: Internet-RFC-1006 TELEX+00728722+RFC-1006+03+
Macro: IXI TELEX+00728722+X.25(80)+06+
#
Mandatory-Service: Public-X.25/X.25/TP0
# The public X.25 network. X.25 is supported in most X.400
# applications and mandatory in X.400 anyhow.
#
Mandatory-Service: Internet/TCP/RFC1006
# The Internet, standing for the global TCP/IP network of the
# research and development community
# RFC1006 is considered a solution to ease migration to OSI. It will
# be replaced by TP4/CLNS as soon as a reliable service is
# available.
#
Optional-Service: Int-CLNS/CLNS/TP4
# The RARE Connectionless pilot service. Current participants are
# NORDUnet, SURFnet, CERN, NSFnet and SWITCH.
#
Optional-Service: EMPB-X.25/X.25/TP0
# The International X.25 Infrastructure covering most countries in
# Europe. The absence of volume tariffs make it a preferred choice.Appendix A2: Example of a RELAY-MTA document 🦋
Community: COSINE-MHS
#
Update: FORMAT=V3; DATE=921218; START=930201
#
RELAY-MTA: P=SWITCH; A=ARCOM; C=CH; MTAname=chx400.switch.ch
#
Status: primary
#
Password: none
RTS-dialog-mode: MONOLOGUE
#
Called-address: Public-X.25/X.25/TP0;
"591"/Int-X25(80)=22847971014520+CUDF+03010100;
MTS-TP-84
Calling-address: Public-X.25/X.25/TP0;
Int-X25(80)=22847971014520;
#
Called-address: Internet/TCP/RFC1006;
"591"/Internet-RFC-1006=chx400.switch.ch;
MTS-TP-84
Calling-address: Internet/TCP/RFC1006;
Internet-RFC-1006=chx400.switch.ch
#
Called-address: EMPB-X.25/X.25/TP0;
"591"/IXI=20432840100520+CUDF+03010100;
MTS-TP-84
Calling-address: EMPB-X.25/X.25/TP0;
IXI=20432840100520;
#
Calling-address: Int-CLNS/CLNS/TP4;
"591"/NS+39756F11111111010000014560AA00040005E100;
MTS-TP-84
Called-address: DCC+756+x11111111010000014560AA00040005E100
#
# For X.400(88) over CLNS
#
Calling-address: Int-CLNS/CLNS/TP4;
"592"/NS+39756F11111111010000014560AA00040005E100;
MTS-T
Called-address: DCC+756+x11111111010000014560AA00040005E100
#
System: HW=SUN 4/690MP; OS=SunOS 4.1.1; SW=PP-6.0
#
LocalDomain: O=switch; OU1=chx400; P=switch; A=arcom; C=ch;
#
EchoServer: S=echo; O=switch; OU1=chx400; P=switch; A=arcom; C=ch;
#
Administrator: CN=Felix Kugler, O=SWITCH, C=CH
Administrator: CN=Christoph Graf, O=SWITCH, C=CHAppendix A3: Example of a DOMAIN document 🧚
Community: COSINE-MHS
#
Update: FORMAT=V3; DATE=921218; START=930201
##
Domain: * P=SWITCH; A=ARCOM; C=CH;
Domain: * P=SANDOZ; A=ARCOM; C=CH;
Domain: * P=ABB; A=ARCOM; C=CH;
Domain: * P=UBS; A=ARCOM; C=CH;
Domain: * P=ISREC; A=ARCOM; C=CH;
Domain: * P=ALCATEL; A=ARCOM; C=CH;
Domain: * P=ITU; A=ARCOM; C=CH;
Domain: * P=OSILABMAIL; A=ARCOM; C=CH;
Domain: * P=WHO; A=ARCOM; C=CH;
Domain: * P=CERN; A=ARCOM; C=CH;
Domain: * P=CERBERUS; A=ARCOM; C=CH;
#
Administrator: CN=Christoph Graf, O=SWITCH, C=CH
Administrator: S=postmaster; O=SWITCH; P=SWITCH; A=ARCOM; C=CH;
#
RELAY-MTA: P=SWITCH; A=ARCOM; C=CH; MTAname=chx400.switch.ch; 0
#
RELAY-MTA: P=SWITCH; A=ARCOM; C=CH; MTAname=vms.switch; 10Appendix A4: Example of a PERSON document 💅
Community: COSINE-MHS
#
Update: FORMAT=V3; DATE=921218; START=930201
#
Key: CN=Christoph Graf, O=SWITCH, C=CH
#
Name: Christoph Graf
#
Address: S=Graf; O=SWITCH; P=SWITCH; A=ARCOM; C=CH;
RFC822: Graf@switch.ch
#
Phone: +41 1 2565454
Fax: +41 1 2618133
#
Mail: SWITCH Head Office /
Christoph Graf /
Limmatquai 138 /
CH-8001 Zurich /
Switzerland
#
Reachable: 09:00-12:00; 14:00-17:30; UTC+0100Appendix B: BNF Definitions ✨
Okay bestie, this is the whole grammar cheat sheet, copied exactly so nothing gets lost in translation. 🧚 Every rule is in one block below, so you can scroll and find whatever you need. 💜
<called-connection> ::= "Called-address: " \
<Service-type> "; " \
<P-address> "; " <MTS> \
["; " <Service-priority>] <CR>
<calling-connection> ::= "Calling-address: " \
<Service-type> "; " \
<P-address> <CR>
<checkpoint-size> ::= "RTS-checkpoint-size: " \
'checkpoint size' <CR>
<COMMUNITY-document> ::= <Community-Identifier> \
<Update-info> \
<COMMUNITY-document-body>
<COMMUNITY-document-body> ::= <Coordination> \
[{<Macro-definition>}] \
{<Connections>}
<Community-Identifier> ::= "Community: " \
('community name' | <DirectoryName>) <CR>
<connection-info> ::= <password> <RTS> \
{<called-connection><calling-connection>}\
[<system>] \
[<local-domain>] \
[<echo-server>]
<Connections> ::= {<mandatory-service>} \
{[<optional-service>]}
<contact-info> ::= {"Administrator: " <UniquePersonKey> <CR>}
<Coordination> ::= <EMail> <Phone> <FAX> \
<Mail> <Operation> <File-server>
<Country-Code> ::= 'Two Character Country Code ISO-3166'
<dialog-mode> ::= "RTS-dialog-mode: " \
("TWA" | "MONOLOGUE") <CR>
<DirectoryName> ::= 'Distinguished Name'
<DOMAIN-document> ::= <Community-Identifier> \
<Update-info> \
<DOMAIN-document-body>
<DOMAIN-document-body>::= {<Domain-entry>} <responsible> \
{<Relay>}
<Domain-entry> ::= "Domain: " <OR-matching> <MHS-subtree> <CR>
<echo-server> ::= "EchoServer: " <X.400 address> <CR>
<EMail> ::= "Address: " <X.400 address> <CR>
<email-server> ::= "Mail-server: "<X.400 address> <CR>
<extension> ::= 'local extension'
<Fax> ::= "Fax: " <tel-no-list> <CR>
<File-server> ::= <email-server> [{<FTP-server>}] \
[{<FTAM-server>]}
<FTAM-server> ::= "FTAM-server: " <P-address> "; "\
'account-name' ["; " 'password'] \
["; X.500 " <DirectoryName>] <CR>
<FTP-server> ::= "FTP-server: " 'domain name' "; " \
'account-name' ["; " 'password'] <CR>
<int-pref> ::= 'international prefix'
<local-domain> ::= "LocalDomain: " <MHS-subtree> <CR>
<Macro-definition> ::= "Macro: " 'Macro name' " " \
'Macro value' <CR>
<Mail> ::= "Mail: " 'postal address information' <CR>
<mandatory-service> ::= "Mandatory-Service: " \
<Service-type> <CR>
<MHS-subtree> ::= ["O=" 'Organization-name' "; "] \
["OU1="'OrganizationalUnit'"; "\
["OU2=" 'OrganizationalUnit' "; " \
["OU3=" 'OrganizationalUnit' "; " \
["OU4=" 'OrganizationalUnit' "; "]]]] \
["P=" 'PRMDname' "; "] \
"A=" 'ADMDname' "; " \
"C=" <Country-Code> ";"
<MTS> ::= "MTS-T" | "MTS-TP" | "MTS-TP-84"
<Name> ::= "Name: " 'name of person' <CR>
<national number> ::= 'national telephone number'
<Network-name> ::= 'Name of a network'
<Network-service> ::= 'Name of a network service'
<Operation> ::= "Reachable: " {<time> "-" <time> "; "} \
<Time-zone> <CR>
<optional-service> ::= "Optional-Service: " \
<Service-type> <CR>
<OR-matching> ::= ( "* " | "= " )
<P-address> ::= 'String encoded Presentation Address'
<password> ::= "Password: " \
("secret" | "none" | \
"value=\"" 'password' "\"") <CR>
<PERSON-document> ::= <Community-Identifier> \
<Update-info> \
<PERSON-document-identifier> \
<PERSON-document-body>
<PERSON-document-identifier> ::= "Key: " <UniquePersonKey> <CR>
<PERSON-document-body>::= <Name> {<EMail>} {<RFC822>} \
<Phone> ::= "Phone: " <tel-no-list> <CR>
<Relay> ::= "Relay: " \
'UniqueRELAY-MTAkey' "; " \
<RELAY-MTA-Priority> <CR>
<RELAY-MTA-document> ::= <Community-Identifier> \
<Update-info> \
<RELAY-MTA-document-Identifier> \
<RELAY-MTA-document-body>
<RELAY-MTA-document-body> ::= <Status> <connection-info> \
<contact-info>
<RELAY-MTA-document-Identifier> ::= \
"RELAY-MTA: " <UniqueRELAY-MTAkey> <CR>
<RELAY-MTA-Priority> ::= <Integer 0..99>
<responsible> ::= {"Administrator: " <UniquePersonKey> <CR>}
<RFC822> ::= "RFC822: " <RFC-822-address> <CR>
<RTS> ::= <dialog-mode> \
[<checkpoint-size> <window-size>]
<Service-priority> ::= 'Integer 0..99'
<Service-type> ::= <Network-name> "/" \
<Network-service> "/" \
<Transport-Protocol>
<Status> ::= "Status: " ("primary" | "secondary") <CR>
<system> ::= "System: HW=" 'computer type' "; " \
"OS=" 'operating system' "; " \
"SW=" 'MHS software' <CR>
<tel-no-list> ::= <tel-number> [{"; " <tel-number>}]
<tel-number> ::= {"+" <int-pref> " " <national number> \
[" x" <extension>]}
<time> ::= 'hh:mm'
<Time-zone> ::= ("UTC+" | "UTC-") 'hhmm'
<Transport-Protocol> ::= 'Name of a transport protocol'
<UniquePersonKey> ::= (<X.400 address> | <DirectoryName> )
<UniqueRELAY-MTAkey> ::= (([ "P=" 'PRMDname' "; " ] \
["A=" 'ADMDname' "; " ] \
"C=" <Country-Code> "; " \
"MTAname=" 'MTAname')
| <DirectoryName> )
<Update-info> ::= "Update: FORMAT=V3; DATE=" 'yymmdd' \
"; START=" 'yymmdd' \
["; END=" 'yymmdd'] <CR>
<window-size> ::= "RTS-window-size: " \
'window size' <CR>
<X.400 address> ::= 'OR address, ISO 10021-2 Annex F'
<X.400 routing coordination document set> ::= \
<COMMUNITY-document> \
{ <RELAY-MTA-document> } \
{ <DOMAIN-document> } \
{ <PERSON-document> }Security Considerations 🔒
Real talk, bestie: security issues are not discussed in this memo. 💀 So don't go hunting for a security section in here, because it isn't in this doc. ✨
Author's Address 🎀
The author is Urs Eppenberger 💖 from SWITCH Head Office in Zurich, Switzerland 🇨🇭. Here are the details, copied exactly:
Urs Eppenberger
SWITCH Head Office
Limmatquai 138
CH-8001 Zurich
Switzerland
Phone: +41 1 261 8112
Fax: +41 1 261 8133
EMail: Eppenberger@switch.ch
S=Eppenberger; O=SWITCH; P=SWITCH; A=ARCOM; C=CH;Comments to the document may also be sent to the distribution list wg-msg@rare.nl of the RARE Working Group on Mail and Messaging. 🦋
📦 where this page comes from
- ietf: rfc1465 1993-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms