RFC 1801
MHS use of the X.500 Directory to support MHS Routing
RFC 1801 💖
X.400-MHS use of the X.500 Directory to support X.400-MHS Routing
Okay bestie, here's the title block 🎀 This is Request for Comments 1801, from the Network Working Group. The author is S. Kille of the ISODE Consortium. It's in the Experimental category 🧪 and dated June 1995 🗓️. The title block doesn't list anything it obsoletes or updates, so there's no drama there 🙈
Status of this Memo ✨
So this memo defines an Experimental Protocol for the Internet community 🧪. It does not specify an Internet standard of any kind, so don't go treating it like one 💅. Discussion and suggestions for improvement are requested 💬, so share your thoughts. Distribution of this memo is unlimited 🌈.
Table of Contents 📚
1 Introduction 3
2 Goals 3
3 Approach 5
4 Direct vs Indirect Connection 6
5 X.400 and RFC 822 8
6 Objects 9
7 Communities 10
8 Routing Trees 11
8.1 Routing Tree Definition . . . . . . . 12
8.2 The Open Community Routing Tree . . . . . 12
8.3 Routing Tree Location . . . . . . . 13
8.4 Example Routing Trees . . . . . . . 13
8.5 Use of Routing Trees to look up Information . . 13
9 Routing Tree Selection 14
9.1 Routing Tree Order . . . . . . . . 14
9.2 Example use of Routing Trees . . . . . . 15
9.2.1 Fully Open Organisation . . . . . 15
9.2.2 Open Organisation with Fallback . . . 15
9.2.3 Minimal-routing MTA . . . . . . 16
9.2.4 Organisation with Firewall . . . . . 16
9.2.5 Well Known Entry Points . . . . . 16
9.2.6 ADMD using the Open Community for Advertising 16
9.2.7 ADMD/PRMD gateway . . . . . . . 17
10 Routing Information 17
10.1 Multiple routing trees . . . . . . . 20
10.2 MTA Choice . . . . . . . . . . 22
10.3 Routing Filters . . . . . . . . . 25
10.4 Indirect Connectivity . . . . . . . 26
11 Local Addresses (UAs) 27
11.1 Searching for Local Users . . . . . . 30
12 Direct Lookup 30
13 Alternate Routes 30
13.1 Finding Alternate Routes . . . . . . . 30
13.2 Sharing routing information . . . . . . 31
14 Looking up Information in the Directory 31
15 Naming MTAs 33
15.1 Naming 1984 MTAs . . . . . . . . . 35
16 Attributes Associated with the MTA 35
17 Bilateral Agreements 36
18 MTA Selection 38
18.1 Dealing with protocol mismatches . . . . . 38
18.2 Supported Protocols . . . . . . . . 39
18.3 MTA Capability Restrictions . . . . . . 39
18.4 Subtree Capability Restrictions . . . . . 40
19 MTA Pulling Messages 41
20 Security and Policy 42
20.1 Finding the Name of the Calling MTA . . . . 42
20.2 Authentication . . . . . . . . . 42
20.3 Authentication Information . . . . . . 44
21 Policy and Authorisation 46
21.1 Simple MTA Policy . . . . . . . . 46
21.2 Complex MTA Policy . . . . . . . . 47
22 Delivery 49
22.1 Redirects . . . . . . . . . . 49
22.2 Underspecified O/R Addresses . . . . . . 50
22.3 Non Delivery . . . . . . . . . . 51
22.4 Bad Addresses . . . . . . . . . 51
23 Submission 53
23.1 Normal Derivation . . . . . . . . 53
23.2 Roles and Groups . . . . . . . . . 53
24 Access Units 54
25 The Overall Routing Algorithm 54
26 Performance 55
27 Acknowledgements 55
28 References 56
29 Security Considerations 57
30 Author's Address 58
A Object Identifier Assignment 59
B Community Identifier Assignments 60
C Protocol Identifier Assignments 60
D ASN.1 Summary 61
E Regular Expression Syntax 71List of Figures 🖼️
1 Location of Routing Trees . . . . . . 12
2 Routing Tree Use Definition . . . . . . 14
3 Routing Information at a Node . . . . . 17
4 Indirect Access . . . . . . . . . 25
5 UA Attributes . . . . . . . . . 27
6 MTA Definitions . . . . . . . . . 33
7 MTA Bilateral Table Entry . . . . . . 36
8 Bilateral Table Attribute . . . . . . 37
9 Supported MTS Extensions . . . . . . . 39
10 Subtree Capability Restriction . . . . . 40
11 Pulling Messages . . . . . . . . . 41
12 Authentication Requirements . . . . . . 43
13 MTA Authentication Parameters . . . . . 45
14 Simple MTA Policy Specification . . . . . 46
15 Redirect Definition . . . . . . . . 48
16 Non Delivery Information . . . . . . . 50
17 Bad Address Pointers . . . . . . . . 52
18 Access Unit Attributes . . . . . . . 53
19 Object Identifier Assignment . . . . . . 59
20 Transport Community Object Identifier Assignments 60
21 Protocol Object Identifier Assignments . . . 61
22 ASN.1 Summary . . . . . . . . . 611. Introduction ✨
Okay so MHS routing is basically the question of steering a message as it hops through one or more MTAs until it reaches its destination recipients 📬. Routing kicks off with a recipient O/R Address, plus the parameters attached to the message being routed 🎀. It's assumed this is known a priori, or it gets derived at submission time, see Section 23 💅.
The big one is mapping an O/R Address onto an MTA (the next hop) 🦋. That MTA shall be one that is, in some sense, "nearer" to the destination UA 🌸. You keep doing that over and over until the message can be delivered directly to the recipient UA 🔁. There's a whole bunch to consider, and we get into it in the following sections 🧠. The full picture of the overall routing process is in Section 25 🖼️.
2. Goals 🎯
Application level routing for MHS is a complex procedure with many requirements, so these are the goals we set for the solution 💖:
- Straightforward to manage. Non-trivial configuration of routing for current message handling systems is a black art 🖤, often involving gathering and processing many tables, and editing complex configuration files. Many problems are solved in a very ad hoc manner 😭. Managing routing for MHS is the most serious headache for most mail system managers 💀.
- Economic, both in terms of network and computational resources 💸.
- Robust. Errors and out of date information shall cause minimal and localised damage 🛡️.
- Deal with link failures. There needs to be some ability to choose alternative routes. In general, it is desirable that the routing approach be redundant 🔀.
- Load sharing. Information on routes shall allow "equal" routes to be specified, and thus facilitate load sharing ⚖️.
- Support format and protocol conversion 🔄.
- Dynamic and automatic. There shall be no need for manual propagation of tables or administrator intervention 🤖.
- Policy robust. It shall not allow specification of policies which cause undesirable routing effects 🚫.
- Reasonably straightforward to implement 🛠️.
- Deal with X.400, RFC 822, and their interaction 📨.
- Extensible to other mail architectures 🌈.
- Recognise existing RFC 822 routing, and coexist smoothly 🫶.
- Improve RFC 822 routing capabilities. This is particularly important for RFC 822 sites not in the SMTP Internet 🌍.
- Deal correctly with different X.400 protocols (P1, P3, P7), and with 1984, 1988 and 1992 versions 📚.
- Support X.400 operation over multiple protocol stacks (TCP/IP, CONS, CLNS) and in different communities 🧩.
- Messages shall be routed consistently. Alternate routing strategies, which might introduce unexpected delay, shall be used with care (e.g., routing through a protocol converter due to unavailability of an MTA) ⚠️.
- Delay between message submission and delivery shall be minimised ⏱️. This has indirect impact on the routing approaches used.
- Interact sensibly with ADMD services 🤝.
- Be global in scope 🌏.
- Routing strategy shall deal with a scale of order of magnitude 1,000,000 -- 100,000,000 MTAs 📈.
- Routing strategy shall deal with of order 1,000,000 -- 100,000,000 Organisations 🏢.
- Information about alterations in topology shall propagate rapidly to sites affected by the change ⚡.
- Removal, examination, or destruction of messages by third parties shall be difficult. This is hard to quantify, but "difficult" shall be comparable to the effort needed to break system security on a typical MTA system 🔐.
- As with current Research Networks, it is recognised that prevention of forged mail will not always be possible. However, this shall be as hard as can be afforded 🕵️.
- Sufficient tracing and logging shall be available to track down security violations and faults 🔍.
- Optimisation of routing messages with multiple recipients, in cases where this involves selection of preferred single recipient routes 🎯.
The following are not initial goals 🙈:
- Advanced optimisation of routing messages with multiple recipients, noting dependencies between the recipients to find routes which would not have been chosen for any of the single recipients 🧮.
- Dynamic load balancing. The approach does not give a means to determine load. However, information on alternate routes is provided, which is the static information needed for load balancing ⚖️.
3. Approach 🎀
Okay so the big-picture problem and a survey of earlier approaches are in the COSINE Study on MHS Topology and Routing [8] 📚. The interim table-based approach from that study isn't followed in detail, but it basically matches what the research X.400 (GO-MHS) community is doing 🌸. The evolving RARE table format is defined in [5]. This document specifies the envisaged longer-term approach ✨.
Some documents made really useful contributions, bestie 🫶:
- A paper by the editor on MHS use of directory, which laid out the broad approach of mapping the O/R Address space on to the DIT [7] 🗺️
- Initial ISO standardisation work on MHS use of Directory for routing [19]. Later ISO work in this area drew from earlier drafts of this specification 💜
- The work of the VERDI Project [3] 🦋
- Work by Kevin Jordan of CDC [6] 💅
- The routing approach of the ACSNet [4, 17] paper. It has great ideas on incremental routing and replicating routing data 🔥
- Network routing is getting super relevant too 👀. As the MHS routing problem grows and network routing gets more sophisticated (e.g., policy based routing), the two areas have more and more in common. For example, see [2] 🌈
4. Direct vs Indirect Connection 🌊
Two extreme approaches to routing connectivity are 💀:
- High connectivity between MTAs. An example of this is the way the Domain Name Server system is used on the DARPA/NSF Internet. Essentially, all MTAs are fully interconnected 🌐.
- Low connectivity between MTAs. An example of this is the UUCP network 🐢.
In general an intermediate approach is desirable 💖. Too sparse a connectivity is inefficient and leads to undue delays 😭. However, full connectivity is not desirable, for the reasons discussed below 🙅. A number of general relaying issues are considered next. The reasons for avoiding relaying are clear. These include:
- Efficiency. If there is an open network, it is desirable that it be used ✨.
- Extra hops introduce delay and increase the (very small) possibility of message loss 😬. As a basic principle, hop count SHALL be minimised 👑.
- Busy relays or Well Known Entry points can introduce high delay and lead to a single point of failure 💀.
- One hop is easy. If there is only one hop, it's straightforward for the user to monitor the progress of messages submitted. If a message is delayed, the user can take appropriate action 🧚.
- Security vibes. Many users like the security of direct transmission. It is an argument often given very strongly for use of SMTP 🔐.
Despite these very powerful arguments, there are a number of reasons why some level of relaying is desirable 🤔:
- Charge optimisation. If there is an expensive network or link to be traversed, it MAY make sense to restrict its usage to a small number of MTAs. This would allow for optimisation with respect to the charging policy of this link 💸.
- Copy optimisation. If a message is being sent to two remote MTAs which are close together, it is usually optimal to send the message to one of the MTAs (for both recipients), and let it pass a copy to the other MTA 📨.
- To access an intermediate MTA for some value added service. In particular for:
- Message Format Conversion
- Distribution List expansion
- Dealing with different protocols. The store and forward approach allows for straightforward conversion 🔄. Relevant cases include:
- Provision of X.400 over different OSI Stacks (e.g., Connectionless Network Service).
- Use of a different version of X.400.
- Interaction with non-X.400 mail services.
- To compensate for inadequate directory services. If tables are maintained in an ad hoc manner, the manual effort to gain full connectivity is too high 🥲.
- To hide complexity of structure. If an organisation has many MTAs, it MAY still be advantageous to advertise a single entry point to the outside world. It will be more efficient to have an extra hop than to (widely) distribute the information required to connect directly. This will also encourage stability, as organisations need to change internal structure much more frequently than their external entry points. For many organisations, establishing such firewalls is high priority 🧱.
- To handle authorisation, charging and security issues. In general, it is desirable to deal with user oriented authorisation at the application level. This is essential when MHS specific parameters SHALL be taken into consideration 🔒. It MAY well be beneficial for organisations to have a single MTA providing access to the external world, which can apply a uniform access policy (e.g., as to which people are allowed access). This would be particularly true in a multi-vendor environment, where different systems would otherwise have to enforce the same policy, using different vendor-specific mechanisms 🛡️.
In summary, there are strong reasons for an intermediate approach. This will be achieved by providing mechanisms for both direct and indirect connectivity. The manager of a configuration will then be able to make appropriate choices for the environment 🎯.
Two models of managing large-scale routing have evolved:
- Use of a global directory/database. This is the approach proposed here.
- Use of a routing table in each MTA, which is managed either by a management protocol or by directory. This is coupled with means to exchange routing information between MTAs. This approach is more analogous to how network level routing is commonly performed. It has good characteristics in terms of managing links and dealing with link related policy. However, it assumes limited connectivity and does not adapt well to a network environment with high connectivity available.
5. X.400 and RFC 822 📮
This document defines mechanisms for X.400 message routing. It's important that this can be integrated with RFC 822 based routing, because many MTAs will work in both communities 🤝. This routing document is written with this problem in mind, and some work to verify this has been done 🔍. Support for RFC 822 routing using the same basic infrastructure is defined in a companion document [13]. In addition, support for X.400/RFC 822 gatewaying is needed to support interaction. Directory based mechanisms for this are defined in [16]. The advantages of the approach defined by this set of specifications are:
- Uniform management for sites which wish to support both protocols.
- Simpler management for gateways.
- Improved routing services for RFC 822 only sites.
For sites which are only X.400 or only RFC 822, the mechanisms associated with gatewaying or with the other form of addressing are not needed 🙅.
6. Objects 🧸
It's useful to start with a manager's perspective 💼. Here is the set of object classes used in this specification. It's important that all information entered relates to something which is being managed. If this is achieved, configuration decisions are much more likely to be correct 💯. In the examples, distinguished names are written using the String Syntax for Distinguished Names [11]. The list of objects used in this specification is:
User: An entry representing a single human user. This will typically be named in an organisational context. For example:
CN=Edgar Smythe,
O=Zydeco Services, C=GBThis entry would have associated information, such as telephone number, postal address, and mailbox 📇.
MTA: A Message Transfer Agent. In general, the binding between machines and MTAs will be complex. Often a small number of MTAs will be used to support many machines, by use of local approaches such as shared filestores. MTAs MAY support multiple protocols, and will identify separate addressing information for each protocol 🧩.
To achieve support for multiple protocols, an MTA is modelled as an Application Process, which is named in the directory. Each MTA will have one or more associated Application Entities. Each Application Entity is named as a child of the Application Process, using a common name which conveniently identifies the Application Entity relative to the Application Process. Each Application Entity supports a single protocol, although different Application Entities MAY support the same protocol. Where an MTA only supports one protocol, or where the addressing information for all of the protocols supported have different attributes to represent addressing information (e.g., P1(88) and SMTP), the Application Entity(ies) MAY be represented by the single Application Process entry 🌸.
User Agent (Mailbox): This defines the User Agent (UA) to which mail MAY be delivered. It will define the account with which the UA is associated, and MAY also point to the user(s) associated with the UA. It will identify which MTAs are able to access the UA. (In the formal X.400 model, there will be a single MTA delivering to a UA. In many practical configurations, multiple MTAs can deliver to a single UA. This will increase robustness, and is desirable 💪.)
Role: Some organisational function. For example:
CN=System Manager, OU=Sales,
O=Zydeco Services, C=GBThe associated entry would indicate the occupant of the role 🎭.
Distribution Lists: There would be an entry representing the distribution list, with information about the list, the manager, and members of the list 📣.
7. Communities 🌈
There are two basic types of agreement in which an MTA MAY participate in order to facilitate routing:
Bilateral Agreements: An agreement between a pair of MTAs to route certain types of traffic. This MTA pair agreement usually reflects some form of special agreement, and in general bilateral information SHALL be held for the link at both ends. In some cases, this information SHALL be private 🤫.
Open Agreements: An agreement between a collection of MTAs to behave in a cooperative fashion to route traffic. This MAY be viewed as a general bilateral agreement 🤝.
It's important to ensure that there are sufficient agreements in place for all messages to be routed. This will usually be done by having agreements which correspond to the addressing hierarchy. For X.400, this is the model where a PRMD connects to an ADMD, and the ADMD provides the inter PRMD connectivity, by the ability to route to all other ADMDs. Other agreements MAY be added to this hierarchy, in order to improve the efficiency of routing 📈. In general, there MAY be valid addresses which cannot be routed to, either for connectivity or policy reasons 🚧.
We model these two types of agreements as communities. A community is a scope in which an MTA advertises its services and learns about other services. Each MTA will:
- Register its services in one or more communities.
- Look up services in one or more communities.
In most cases an MTA will deal with a very small number of communities, very often one only. There are a number of different types of community 🫧.
The open community: This is a public/global scope. It reflects routing information which is made available to any MTA which wishes to use it 🌍.
The local community: This is the scope of a single MTA. It reflects routing information private to the MTA. It will contain an MTA's view of the set of bilateral agreements in which it participates, and routing information private and local to the MTA 🦋.
- Hierarchical communities 🏘️ A hierarchical community is a subtree of the O/R Address tree. For example, it might be a management domain, an organisation, or an organisational unit. This sort of community will allow for firewalls to be established. A community can have complex internal structure, and register a small subset of that in the open community. 🧱
- Closed communities 🤝 A closed community is a set of MTAs which agrees to route amongst themselves. Examples of this might be ADMDs within a country, or a set of PRMDs representing the same organisation in multiple countries. 🌍
Formally, a community indicates the scope over which a service is advertised. In practice, it will tend to reflect the scope of services offered. It does not make sense to offer a public service and only advertise it locally. 📣 Public advertising of a private service makes more sense, and this is shown below. In general, having a community offer services corresponding to the scope in which they are advertised will lead to routing efficiency. ⚡ Examples of how communities can be used to implement a range of routing policies are given in Section 9.2. 💖
8. Routing Trees ✨
Communities are a useful abstract definition of the routing approach taken by this specification. 🧠 Each community is represented in the directory as a routing tree. There will be many routing trees instantiated in the directory. Typically, an MTA will only be registered in and make use of a small number of routing trees. In most cases, it will register in and use the same set of routing trees. 🌳
8.1. Routing Tree Definition
Each community has a model of the O/R address space. Within a community, there is a general model of what to do with a given O/R Address. This is structured hierarchically, according to the O/R address hierarchy. 🪜 A community can register different possible actions, depending on the depth of match. This might include identifying the MTA associated with a UA which is matched fully, and providing a default route for an O/R address where there is no match in the community --- and all intermediate forms. The name structure of a routing tree follows the O/R address hierarchy, which is specified in a separate document [15]. Where there is any routing action associated with a node in a routing tree, the node is of object class routingInformation, as defined in Section 10. 🎯
8.2. The Open Community Routing Tree
The routing tree of the open community starts at the root of the DIT. 🌐 This routing tree also serves the special function of instantiating the global O/R Address space in the Directory. Thus, if a UA wishes to publish information to the world, this hierarchy allows it to do so. 📢
The O/R Address hierarchy is a registered tree, which may be instantiated in the directory. Names at all points in the tree are valid, and there is no requirement that the namespace is instantiated by the owner of the name. For example, a PRMD may make an entry in the DIT, even if the ADMD above it does not. In this case, there will be a "skeletal" entry for the ADMD, which is used to hang the PRMD entry in place. 🪝 The skeletal entry contains the minimum number of entries which are needed for it to exist in the DIT (Object Class and Attribute information needed for the relative distinguished name). This entry may be placed there solely to support the subordinate entry, as its existence is inferred by the subordinate entry. Only the owner of the entry may place information into it. 🔐 An analogous situation in current operational practice is to make DIT entries for Countries and US States. 🇺🇸
---------------------------------------------------------------------
routingTreeRoot OBJECT-CLASS ::= {
SUBCLASS OF {routingInformation|subtree}
ID oc-routing-tree-root}
Figure 1: Location of Routing Trees
---------------------------------------------------------------------8.3. Routing Tree Location
All routing trees follow the same O/R address hierarchy. Routing trees other than the open community routing tree are rooted at arbitrary parts of the DIT. 🗺️ These routing trees are instantiated using the subtree mechanism defined in the companion document "Representing Tables and Subtrees in the Directory" [15]. A routing tree is identified by the point at which it is rooted. An MTA will use a list of routing trees, as determined by the mechanism described in Section 9. Routing trees may be located in either the organisational or O/R address structured part of the DIT. All routing trees, other than the open community routing tree, are rooted by an entry of object class routingTreeRoot, as defined in Figure 1. 🌸
8.4. Example Routing Trees
Consider routing trees with entries for O/R Address:
P=ABC; A=XYZMail; C=GB;In the open community routing tree, this would have a distinguished name of:
PRMD=ABC, ADMD=XYZMail, C=GBConsider a routing tree which is private to:
O=Zydeco Services, C=GBThey might choose to label a routing tree root "Zydeco Routing Tree", which would lead to a routing tree root of:
CN=Zydeco Routing Tree, O=Zydeco Services, C=GBThe O/R address in question would be stored in this routing tree as:
PRMD=ABC, ADMD=XYZMail
C=GB, CN=Zydeco Routing Tree,
O=Zydeco Services, C=GB8.5. Use of Routing Trees to look up Information
Lookup of an O/R address in a routing tree is done as follows: 🔍
- Map the O/R address onto the O/R address hierarchy described in [15] in order to generate a Distinguished Name.
- Append this to the Distinguished Name of the routing tree, and then look up the whole name.
- Handling of errors will depend on the application of the lookup, and is discussed later.
Note that it is valid to look up a null O/R Address, as the routing tree root may contain default routing information for the routing tree. 🎁 This is held in the root entry of the routing tree, which is a subclass of routingInformation. The open community routing tree does not have a default. 🙅
Routing trees may have aliases into other routing trees. This will typically be done to optimise lookups from the first routing tree which a given MTA uses. Lookup needs to take account of this. 🔗
9. Routing Tree Selection 👑
The list of routing trees which a given MTA uses will be represented in the directory. This uses the attribute defined in Figure 2.
---------------------------------------------------------------------
routingTreeList ATTRIBUTE ::= {
WITH SYNTAX RoutingTreeList
SINGLE VALUE
ID at-routing-tree-list}
RoutingTreeList ::= SEQUENCE OF RoutingTreeName
RoutingTreeName ::= DistinguishedName
Figure 2: Routing Tree Use Definition
---------------------------------------------------------------------This attribute defines the routing trees used by an MTA, and the order in which they are used. Holding these in the directory eases configuration management. 🛠️ It also enables an MTA to calculate the routing choice of any other MTA which follows this specification, provided that none of its routing trees have access restrictions. This will facilitate debugging routing problems. 🐛
9.1. Routing Tree Order
The order in which routing trees are used will be critical to the operation of this algorithm. 🚨 A common approach will be:
- Access one or more shared private routing trees to access private routing information.
- Utilise the open routing tree.
- Fall back to a default route from one of the private routing trees.
Initially, the open routing tree will be very sparse, and there will be little routing information in ADMD level nodes. Access to many services will only be via ADMD services, which in turn will only be accessible via private links. 🔒 For most MTAs, the fallback routing will be important, in order to gain access to an MTA which has the right private connections configured. 🪂
In general, for a site, UAs will be registered in one routing tree only, in order to avoid duplication. They may be placed into other routing trees by use of aliases, in order to gain performance. For some sites, Users and UAs with a 1:1 mapping will be mapped onto single entries by use of aliases. 💫
9.2. Example use of Routing Trees
Some examples of how this structure might be used are now given. Many other combinations are possible to suit organisational requirements. 🎨
9.2.1. Fully Open Organisation
The simplest usage is to place all routing information in the open community routing tree. An organisation will simply establish O/R addresses for all of its UAs in the open community tree, each registering its supporting MTA. This will give access to all systems accessible from this open community. 🌈
9.2.2. Open Organisation with Fallback
In practice, some MTAs and MDs will not be directly reachable from the open community (e.g., ADMDs with a strong model of bilateral agreements). These services will only be available to users/communities with appropriate agreements in place. Therefore it will be useful to have a second (local) routing tree, containing only the name of the fallback MTA at its root. In many cases, this fallback would be to an ADMD connection. 🛟
Thus, open routing will be tried first, and if this fails the message will be routed to a single selected MTA. 🎯
9.2.3. Minimal-routing MTA
The simplest approach to routing for an MTA is to deliver messages to associated users, and send everything else to another MTA (possibly with backup). 📬
An organisation using MTAs with this approach will register its users as for the fully open organisation. A single routing tree will be established, with the name of the organisation being aliased into the open community routing tree. Thus the MTA will correctly identify local users, but use a fallback mechanism for all other addresses. 🧭
9.2.4. Organisation with Firewall
An organisation can establish an organisation community to build a firewall, with the overall organisation being registered in the open community. This is an important structure, which it is important to support cleanly. 🏰
- Some MTAs are registered in the open community routing tree to give access into the organisation. This will include the O/R tree down to the organisational level. Full O/R Address verification will not take place externally.
- All users are registered in a private (organisational) routing tree.
- All MTAs in the organisation are registered in the organisation's private routing tree, and access information in the organisation's community. This gives full internal connectivity. 🫶
- Some MTAs in the organisation access the open community routing tree. These MTAs take traffic from the organisation to the outside world. These will often be the same MTAs that are externally advertised. 🌍
9.2.5. Well Known Entry Points
Well known entry points will be used to provide access to countries and MDs which are oriented to private links. A private routing tree will be established, which indicates these links. This tree would be shared by the well known entry points. 🚪
9.2.6. ADMD using the Open Community for Advertising
An ADMD uses the open community for advertising. It advertises its existence and also restrictive policy. This will be useful for: 🪧
- Address validation
- Advertising the mechanism for a bilateral link to be established
9.2.7 ADMD/PRMD gateway 🌸
okay so an MTA can act as a gateway from a PRMD into an ADMD 🚪✨ and here's the thing bestie: a lot of X.400 MDs just don't use the directory at all, and honestly? that's totally valid 🙌 nobody's doing anything wrong. this trick is how you register access into those communities from the directory-using side 💅
- The MTA registers the ADMD in its local community (private link) 🔒
- The MTA registers itself in the PRMD's community to give access to the ADMD 🦋
10. Routing Information 🎀
okay the routing trees we just talked about are the framework that holds all the routing info 🌳💖 every node in a routing tree (except for skeletal ones) carries some information, and that info is defined by the object class routingInformation in Figure 3. this is the core of the whole spec, so it's giving "read it very carefully" energy 🧐🔥
routingInformation OBJECT-CLASS ::= {
SUBCLASS OF top
KIND auxiliary
MAY CONTAIN {
subtreeInformation|
routingFilter|
routingFailureAction|
mTAInfo|
accessMD| 10
nonDeliveryInfo|
badAddressSearchPoint|
badAddressSearchAttributes}
ID oc-routing-information}
-- No naming attributes as this is not a
-- structural object class
subtreeInformation ATTRIBUTE ::= { 20
WITH SYNTAX SubtreeInfo
SINGLE VALUE
ID at-subtree-information}
SubtreeInfo ::= ENUMERATED {
all-children-present(0),
not-all-children-present(1) }
routingFilter ATTRIBUTE ::= { 30
WITH SYNTAX RoutingFilter
ID at-routing-filter}
RoutingFilter ::= SEQUENCE{
attribute-type OBJECT-IDENTIFIER,
weight RouteWeight,
dda-key String OPTIONAL,
regex-match IA5String OPTIONAL,
node DistinguishedName } 40
String ::= CHOICE {PrintableString, TeletexString}
routingFailureAction ATTRIBUTE ::= {
WITH SYNTAX RoutingFailureAction
SINGLE VALUE
ID at-routing-failure-action}
RoutingFailureAction ::= ENUMERATED {
next-level(0), 50
next-tree-only(1),
next-tree-first(2),
stop(3) }
mTAInfo ATTRIBUTE ::= {
WITH SYNTAX MTAInfo
ID at-mta-info}
MTAInfo ::= SEQUENCE { 60
name DistinguishedName,
weight [1] RouteWeight DEFAULT preferred-access,
mta-attributes [2] SET OF Attribute OPTIONAL,
ae-info SEQUENCE OF SEQUENCE {
aEQualifier PrintableString,
ae-weight RouteWeight DEFAULT preferred-access,
ae-attributes SET OF Attribute OPTIONAL} OPTIONAL
}
RouteWeight ::= INTEGER {endpoint(0), 70
preferred-access(5),
backup(10)} (0..20)
Figure 3: Routing Information at a Nodelet's do an example 🧁 say the node is the PRMD one:
PRMD=ABC, ADMD=XYZMail, C=GBif that node sits in the open community routing tree, the info is what the PRMD owner published about public access to that PRMD 📢 but if it lives in some other routing tree, it's the owner of that tree sharing access info about the referenced PRMD 🤝 the attributes on a routingInformation node spill the following tea 🫖:
Implicit: the node matches a partial or entire valid O/R address 💯 this is implicit, just from the entry existing.Object Class: if the node is a UA 🤖, it'll be of object classroutedUA. more on that in Section 11. if it's not that class, it's just an intermediate node in the O/R Address hierarchy.routingFilter: a set of routing filters, defined by theroutingFilterattribute 🔍 this is how you route on info in the unmatched part of the O/R Address. see Section 10.3.subtreeInformation: this one tells you whether the node is authoritative for the level below it 👑 if it's authoritative (valueall-children-present), it gives you the basis for permanently rejecting invalid O/R Addresses ❌ it's encoded as enumerated because partial authority (for certain attribute types, say) might get added later 🔮 if the attribute is missing, the node is assumed non-authoritative (not-all-children-present).all-children-presentonly means that all child entries are present, so you can spot invalid addresses, and it says nothing about whether routing info exists 🙃 so you can verify a whole address, but you can only route on one of the higher level components.
ok so for example, look at this node:
MHS-O=Zydeco, PRMD=ABC, ADMD=XYZMail, C=GBan org with a bilateral agreement with this one has this entry in its routing tree, with no children 🤝 it's marked non-authoritative. then Zydeco keeps a second routing tree with all the children of this node, marked authoritative 🏆 when we consider this O/R Address:
MHS-G=Random + MHS-S=Unknown, MHS-O=Zydeco,
PRMD=ABC, ADMD=XYZMail, C=GBonly that second, authoritative tree can prove the address is invalid 💀 in practice, the manager setting up the non-authoritative tree gets to choose whether an MTA using it goes for full verification or routes based on the partly verified info 🎛️
mTAInfo: a list of MTAs and their associated info, defined by themTAInfoattribute 📦 more on this in Sections 15 and 18. this is the key info on the node 🔑 when a node gets matched in a lookup, it tells you whether the route is valid and gives you a set of MTAs to connect to. selection of MTAs is covered in Sections 18 and Section 10.2.routingFailureAction: the action to take if none of the MTAs can be used directly (or if there aren't any MTAs at all) 🆘 it's defined by theroutingFailureActionattribute. how this works with multiple routing trees is in Section 10.1.accessMD: discussed in Section 10.4 🚪 this attribute indicates MDs that give indirect access to the part of the tree being routed to.badAddressSearchPoint/badAddressSearchAttributes: these are covered in Section 17 🕵️ they come into play when an address has been rejected, and they let you find info on alternative addresses.
10.1 Multiple routing trees 🌳🌳
a routing decision usually uses info from multiple routing trees 🧠 this section explains the algorithms for using them. the X.500 stuff and error handling are in Section 14. a routing decision works by checking a series of entries (nodes) across one or more routing trees, and that info is summed up in Figure 3 📋 each entry might have info on possible next-hop MTAs. once you hit an entry that lets the message get routed, one of the routing options determined at that point gets picked, and a routing decision is made ✅ it's possible more entries get checked to work out other routing options, but that kind of heuristic isn't discussed here 🤷♀️
with a single routing tree, you find the longest possible match for the O/R address being routed to 🎯 that entry, then each of its parents in turn, gets considered, ending at the routing tree root node (except for the open routing tree, which doesn't have one) 🌱 with multiple trees, the basic move is to treat them in a defined order 📚 and there's a backup plan too: if a matched node can't be used directly, the algorithm can either move up a level in the current tree, or jump to the next tree with the option to come back to the first tree later 🔄 that "come back" option exists for the super common case where a tree is doing two jobs:
- Routing info private to the MTA (e.g., local UAs or routing info for bilateral links) 🔐
- Default routing info for when other routing has failed 🛟
the actions let you follow a tree for the private info, then try other trees, and finally fall back to the default situation 🪜 for really complicated setups, you might need to split it into two trees ✂️ these are the options defined by routingFailureAction, for when the info in the entry doesn't give a direct route:
next-level: move up a level in the current routing tree 🪜⬆️ this is the action implied if the attribute is left out. it'll usually be the best one in the open community routing tree 🌍next-tree-only: move to the next tree, and do no further processing on the current tree 🏃♀️ this is a useful optimisation for a routing tree where you already know there's no useful extra routing info higher up 💨next-tree-first: move to the next tree, then default back to the next level in this tree once all the processing on the subsequent trees is done 🔁 this is useful for an MTA running this sequence:- Check for optimised private routes 🔒
- Try other available information 🔍
- Fall back to a local default route 🏠
stop: this address is unroutable 🚫 no processing shall be done in any trees.
for the root entry of a routing tree, the default action and next-level are interpreted as next-tree-only 🌱✨
10.2 MTA Choice ✨
okay bestie, this section is about how we pick between alternate MTAs 🫶 but first we need to know why an MTA gets put into a node of the routing tree in the first place, bc it's not random 💅
- The manager for the node of the tree shall place it there. This is a formality, but it's literally critical for overall authority 👑
- The MTA manager shall agree to it being placed there. For a well operated MTA, the access policy of the MTA will be set to enforce this 🔒
- The MTA will in general (for some class of message) be prepared to route to any valid O/R address in the subtree implied by the address. The only exception is where the MTA will route to a subset of the tree that can't easily be expressed by making entries at the level below. An example might be an MTA prepared to route to all of the subtree, with certain explicit exceptions 🦋
Info on each MTA is stored in an mTAInfo attribute, which is defined in Figure 3. This attribute contains:
nameThe Distinguished Name of the MTA (Application Process) 🎀weightA weighting factor (Route Weight) which gives a basis to choose between different MTAs. This is described in Section 10.2.mta-attributesAttributes from the MTA's entry. Information on the MTA will always be stored in the MTA's entry. The MTA is represented here as a structure, which lets some of that entry information show up in the routing node. This is effectively a maintained cache, and it can lead to considerable performance optimisation. For example, if ten MTAs were represented at a node, another MTA making a routing decision might need to make ten directory reads to get the information it needs. If any attributes are present here, all of the attributes needed to make a routing decision shall be included, and also all attributes at the Application Entity level.ae-infoWhere an MTA supports a single protocol only, or the protocols it supports have address information that can be represented in non-conflicting attributes, then the MTA may be represented as an application process only. In this case, theae-infostructure (which gives information on associated application entities) may be omitted, because the MTA is represented by a single application entity that has the same name as the application process. In other cases, the names of all application entities shall be included. A weight is associated with each application entity so the MTA can indicate a preference between its application entities 🍓
The structure of information within ae-info is as follows:
ae-qualifierA printable string (e.g.,"x400-88"), which is the value of the common name of the relative distinguished name of the application entity. This can be used with the application process name to derive the application entity title.ae-weightA weighting factor (Route Weight) which gives a basis to choose between different Application Entities (not between different MTAs). This is described below.ae-attributesAttributes from the AEs entry.
Info in the mta-attributes and ae-info is present as a performance optimisation, so routing choices can be made with a much smaller number of directory operations. Using this information, whose presence is optional, is equivalent to looking up the information in the MTA. If this information is present, it shall be maintained to be the same as the information stored in the MTA entry. Even with that maintenance requirement, using this performance optimisation data is optional, and the information may always be looked up from the MTA entry 🧚
Note: It has been suggested that substantial performance optimisation will be achieved by caching, and that the performance gained from maintaining these attributes does not justify the effort of maintaining the entries. If this is borne out by operational experience, this will be reflected in future versions of this specification.
Route weighting is a mechanism to distinguish between different route choices. A routing weight may be associated with the MTA in the context of a routing tree entry, because routing weight will always be context dependent. This allows machines that have other functions to be used as backup MTAs. The Route Weight is an integer in the range 0--20. The lower the value, the better the choice of MTA. Where the weight is equal, and no other factors apply, the choice between the MTAs shall be random to facilitate load balancing. If the MTA itself is in the list, it shall only route to an MTA of lower weight. The exact values will be chosen by the manager of the relevant part of the routing tree. For guidance, three fixed points are given:
0For an MTA which can deliver directly to the entire subtree implied by the position in the routing tree. 💯5For an MTA which is preferred for this point in the subtree.10For a backup MTA.
When an organisation registers in multiple routing trees, the route weight used depends on the context of the subtree. In general it is not possible to compare weights between subtrees. In some cases, route weighting can be used to divert traffic away from expensive links 💸
Attributes present in an MTA Entry are defined in various parts of this specification. A summary and pointers to these sections are given in Section 16 📚
Attributes that are available in the MTA entry and will be needed for making a routing choice are:
protocolInformationapplicationContextmhs-deliverable-content-lengthresponderAuthenticationRequirementsinitiatorAuthenticationRequirementsresponderPullingAuthenticationRequirementsinitiatorPullingAuthenticationRequirementsinitiatorP1ModeresponderP1ModepolledMTAsCurrent MTA shall be in list if message is to be pulled.mTAsAllowedToPollsupportedMTSExtensions
If any MTA attributes are present in the mTAInfo attribute, all of the attributes that may affect the routing choice shall be present. Other attributes may be present too. A full list of MTA attributes, with summaries of their descriptions, is given in Section 16, with a formal definition in Figure 6 🎀
10.3 Routing Filters 🌈
This attribute lets you route on information in the unmatched part of the O/R Address, including:
- Routing on the basis of an O/R Address component type
- Routing on the basis of a substring match of an O/R address component. This might be used to route X121 addressed faxes to an appropriate MTA 📠
When present, the procedures for analysing the routing filters shall be followed before other actions. The routing filter overrides the mTAInfo and accessMD attributes, which means the routing filter must be considered first. Only in the event that no routing filters match shall the mTAInfo and accessMD attributes be considered. The components of the routingFilter attribute are:
attribute-typeThis gives the attribute type to be matched, and is selected from the attribute types which have not been matched to identify the routing entry. The filter applies to this attribute type. If there is no regular expression present (as defined below), the filter is true if the attribute is present. The value is the object identifier of the X.500 attribute type (e.g.,at-prmd-name).weightThis gives the weight of the filter, which is encoded as a Route Weight, with lower values indicating higher priority. If multiple filters match, the weight of each matched filter is used to select between them. If the weight is the same, then a random choice shall be made.dda-keyIf the attribute is domain defined, then this parameter may be used to identify the key.
accessMD ATTRIBUTE ::= {
SUBTYPE OF distinguishedName
ID at-access-md}Figure 4: Indirect Access
regex-matchThis string is used to give a regular expression match on the attribute value. The syntax for regular expressions is defined in Appendix E.nodeThis distinguished name specifies the entry which holds routing information for the filter. It shall be an entry with object classroutingInformation, which can be used to determine the MTA or MTA choice. All of the attributes from this entry should be used, as if they had been directly returned from the current entry (i.e., the procedure recurses). The current entry does not set defaults.
An example of routing filters is now given, showing how to route on X121 address to a fax gateway in Germany. Consider the routing point:
PRMD=ABC, ADMD=XYZMail, C=GBThe entry associated with it would have two routing filters:
- One with type
x121and no regular expression, to route to a default fax gateway. - One with type
x121and a regular expression^9262, to route all German faxes to a fax gateway located in Germany with which there is a bilateral agreement. This would have a lower weight, so it would be selected over the default fax gateway 🇩🇪
10.4 Indirect Connectivity 🔁
In some cases a part of the O/R Address space will be accessed indirectly. For example, an ADMD without access from the open community might have an agreement with another MD to provide this access. This is achieved by using the accessMD attribute defined in Figure 4. If this attribute is found, the routing algorithm shall read the entry pointed to by this distinguished name. It shall be an entry with object class routingInformation, which can be used to determine the MTA or MTA choice, and route according to the information retrieved to this access MD. All of the attributes from this entry should be used, as if they had been directly returned from the current entry (i.e., the procedure recurses). The current entry does not set defaults.
The attribute is called an MD, as that is descriptive of its normal use. It might point to a more closely defined part of the O/R Address space.
It is possible for both an access MD and MTAs to be specified. This might be done if the MTAs only support access over a restricted set of transport stacks. In this case, the access MD shall only be routed to if it is not possible to route to any of the MTAs.
This structure can also be used as an optimisation, where a set of MTAs provides access to several parts of the O/R Address space. Rather than repeat the MTA information (list of MTAs) in each reference to the MD, a single access MD is used as a means of grouping the MTAs. The Distinguished Name of the access MD will probably not be meaningful in this case (e.g., it might be the name "Access MTA List", within the organisation.) 🗂️
If the MTA routing is unable to access the information in the Access MD due to directory security restrictions, the routing algorithm shall continue as if no MTA information was located in the routing entry.
11. Local Addresses (UAs) ✨
okay so local addresses (UAs) are a special case for routing, and honestly they're the endpoint, bestie 🎀 the definition of the routedUA object class is in Figure 5. it identifies a User Agent in a routing tree, and it's needed for a few reasons:
routedUA OBJECT-CLASS ::= {
SUBCLASS OF {routingInformation}
KIND auxiliary
MAY CONTAIN {
-- from X.402
mhs-deliverable-content-length|
mhs-deliverable-content-types|
mhs-deliverable-eits|
mhs-message-store| 10
mhs-preferred-delivery-methods|
-- defined here
supportedExtensions|
redirect|
supportingMTA|
userName|
nonDeliveryInfo}
ID oc-routed-ua}
supportedExtensions ATTRIBUTE ::= { 20
SUBTYPE OF objectIdentifier
ID at-supported-extensions}
supportingMTA ATTRIBUTE ::= {
SUBTYPE OF mTAInfo
ID at-supporting-mta}
userName ATTRIBUTE ::= {
SUBTYPE OF distinguishedName
ID at-user-name} 30
Figure 5: UA Attributes- To allow UAs to be defined without having an entry in another part of the DIT.
- To identify which (leaf and non-leaf) nodes in a routing tree are User Agents. In a pure X.400 environment, a UA (as distinct from a connecting part of the O/R address space) is simply identified by object class. Thus an organisation entry can itself be a UA. A UA need not be a leaf, and can thus have children in the tree.
- To allow UA parameters as defined in X.402 (e.g., the
mhs-deliverable-eits) to be determined efficiently from the routing tree, without having to go to the user's entry. - To provide access to other information associated with the UA, as defined below.
the following attributes are defined associated with the UA. 💅
supportedExtensions: MTS extensions supported by the MTA, which affect delivery.
supportingMTA: the MTAs which support a UA directly are noted in the supportingMTA attribute, which may be multi-valued. in the X.400 model, only one MTA is associated with a UA. in practice, though, it is possible and useful for several MTAs to be able to deliver to a single UA 🙌 this attribute is a subtype of mTAInfo, and it defines access information for an MTA which is able to deliver to the UA. there may also be an mTAInfo attribute in the entry. components of the supportingMTA attribute are interpreted in the same manner as mtaInfo is for routing, with one exception. the values of the Route Weight are interpreted in the following manner:
0. A preferred MTA for delivery.5. A backup MTA.10. A backup MTA, which is not presferred.
the supportingMTA attribute shall be present, unless the address is being non-delivered or redirected, in which case it may be omitted. ✨
redirect: the redirect attribute controls redirects, as described in Section 22.1.
userName: the attribute userName points to the distinguished Name of the user, as defined by the mhs-user in X.402. the pointer from the user to the O/R Address is achieved by the mhs-or-addresses attribute. this makes the UA/User linkage symmetrical 🦋
nonDeliveryInfo: the attribute nonDeliveryInfo mandates non-delivery to this address, as described in Section 22.3.
when routing to a UA, an MTA will read the supportingMTA attribute. if it finds its own name present, it will know that the UA is local, and invoke appropriate procedures for local delivery (e.g., co-resident or P3 access information). the cost of holding these attributes for each UA at a site will often be reduced by use of shared attributes (as defined in X.500(93)). 🧚
Misconfiguration of the supportingMTA attribute could have serious operational and possibly security problems, although for the most part no worse than general routing configuration problems. An MTA using this attribute may choose to perform certain sanity checks, which might be to verify the routing tree or subtree that the entry resides in. 💀 this one is serious, bestie, so double-check your configs.
the linkage between the UA and User entries was noted above. it's also possible to use a single entry for both User and UA, as there is no conflict between the attributes in each of the objects. in this case, the entries shall be in one part of the DIT, with aliases from the other. because the UA and User are named with different attributes, the aliases shall be at the leaf level. 🌸
11.1. Searching for Local Users
the approach defined in this specification performs all routing by use of reads. this is done for performance reasons, as it is a reasonable expectation that all DSA implementations will support a high performance read operation. for local routing only, an MTA in cooperation with the provider of the local routing tree may choose to use a search operation to perform routing. the major benefit of this is that there will not be a need to store aliases for alternate names, and so the directory storage requirement and alias management will be reduced. the difficulty with this approach is that it is hard to define search criteria that would be effective in all situations and well supported by all DUAs. there are also issues about determining the validity of a route on the basis of partial matches. 🤔
12. Direct Lookup 🍓
where an O/R address is registered in the open community and has one or more "open" MTAs which support it, this will be optimised by storing MTA information in the O/R address entry. in general, the Directory will support this by use of attribute inheritance or an implementation will optimise the storage or repeated information, and so there will not be a large storage overhead implied. this is a function of the basic routing approach. as a further optimisation of this case, the User's distinguished name entry may contain the mTAInfo attribute. this can be looked up from the distinguished name, and thus routing on submission can be achieved by use of a single read. ⚡
Note: This performance optimisation has a management overhead, and further experience is needed to determine if the effort justifies the performance improvement.
13. Alternate Routes 🦋
13.1. Finding Alternate Routes
the routing algorithm selects a single MTA to be routed to. it could be extended to find alternate routes to a single MTA with possibly different weights. how far this is done is a local configuration choice. provision of backup routing is desirable, and leads to robust service, but excessive use of alternate routing is not usually beneficial. it will often force messages onto convoluted paths, when there was only a short outage on the preferred path. it is important to note that this strategy will lead to picking the first acceptable route. it is important to configure the routing trees so that the first route identified will also be the best route. 🫶
13.2. Sharing routing information
so far, only single addresses have been considered. improving routing choice for multiple addresses is analogous to dealing with multiple routes. this section defines an optional improvement. when multiple addresses are present, and alternate routes are available, the preferred routes may be chosen so as to maximise the number of recipients sent with each message. 💜
specification of routing trees can facilitate this optimisation. suppose there is a set of addresses (e.g., in an organisation) which have different MTAs, but have access to an MTA which will do local switching. if each address is registered with the optimal MTA as preferred, but has the "hub" MTA registered with a higher route weight, then optimisation may occur when a message is sent to multiple addresses in the group. 👑
14. Looking up Information in the Directory 🔥
the description so far has been abstract about lookup of information. this section considers how information is looked up in the Directory. consider that an O/R Address is presented for lookup, and there is a sequence of routing trees. at any point in the lookup sequence, there is one of a set of actions that can take place:
Entry Found: information from the entry (node) is returned and shall be examined. the routing process continues or terminates, based on this information.
Entry Not Found: return information on the length of best possible match to the routing algorithm.
Temporary Reject: the MTA shall stop the calculation, and repeat the request later. repeated temporary rejects should be handled in a similar manner to the way the local MTA would handle the failure to connect to a remote MTA.
Permanent Reject: administrative error on the directory which may be fixed in future, but which currently prevents routing. the routing calculation should be stopped and the message non-delivered. 😭
the algorithm proceeds by a series of directory read operations. if the read operation is successful, the Entry Found procedure should be followed. errors from the lookup (directory read) shall be handled in terms of the above procedures as follows. the following handling is used when following a routing tree:
AttributeError: this leads to a Permanent Reject.
NameError: Entry Not Found is used. the matched parameter is used to determine the number of components of the name that have matched (possibly zero). the read may then repeated with this name. this is the normal case, and allows the "best" entry in the routingn tree to be located with two reads. 🧚
Referral: the referral shall be followed, and then the procedure recurses.
SecurityError: Entry Not Found is used. return a match length of one less than the name provided.
ServiceError: this leads to a Temporary Reject.
there will be cases where the algorithm moves to a name outside of the routing tree being followed (following an accessMD attribute, or a redirect or a matched routing filter). the handling will be the same as above, except:
NameError: this leads to a Permanent Reject.
SecurityError: this leads to a Permanent Reject.
when reading objects which of not of object class routingInformation, the following error handling is used:
AttributeError: this leads to a Permanent Reject.
NameError: this leads to a Permanent Reject.
Referral: the referral shall be followed, and then the procedure recurses.
SecurityError: in the case of an MTA, treat as if it is not possible to route to this MTA. in other cases, this leads to a Permanent Reject.
ServiceError: this leads to a Temporary Reject.
the algorithm specifies the object class of entries which are read. if an object class does not match what is expected, this shall lead to a permanent reject. 🎀
15. Naming MTAs ✨
okay so MTAs need names in the DIT, but bestie, the name has zero routing significance 🙅♀️. It's literally just a unique key. The attributes for naming MTAs are in Figure 6, which also lists the attributes an MTA entry might have. We'll get into what most of them do in later sections 💅. The mTAName and globalDomainID attributes are the ones that matter for trace information (what an MTA writes into trace) 🔍. And as we said before, an MTA is represented as an Application Process with one or more Application Entities 🧚
mTAName ATTRIBUTE ::= {
SUBTYPE OF name
WITH SYNTAX DirectoryString{ub-mta-name-length}
SINGLE VALUE
ID at-mta-name}
-- used for naming when
-- MTA is named in O=R Address Hierarchy
globalDomainID ATTRIBUTE ::= { 10
WITH SYNTAX GlobalDomainIdentifier
SINGLE VALUE
ID at-global-domain-id}
-- both attributes present when MTA
-- is named outside O=R Address Hierarchy
-- to enable trace to be written
mTAApplicationProcess OBJECT-CLASS ::= {
SUBCLASS OF {application-process}
KIND auxiliary 20
MAY CONTAIN {
mTAWillRoute|
globalDomainID|
routingTreeList|
localAccessUnit|
accessUnitsUsed
}
ID oc-mta-application-process}
mTA OBJECT CLASS ::= { -- Application Entity 30
SUBCLASS OF {mhs-message-transfer-agent}
KIND structural
MAY CONTAIN {
mTAName|
globalDomainID| -- per AE variant
responderAuthenticationRequirements|
initiatorAuthenticationRequirements|
responderPullingAuthenticationRequirements|
initiatorPullingAuthenticationRequirements|
initiatorP1Mode| 40
responderP1Mode|
polledMTAs|
protocolInformation|
respondingRTSCredentials|
initiatingRTSCredentials|
callingPresentationAddress|
callingSelectorValidity|
bilateralTable|
mTAWillRoute|
mhs-deliverable-content-length| 50
routingTreeList|
supportedMTSExtensions|
mTAsAllowedToPoll
}
ID oc-mta}Figure 6: MTA Definitions
Okay, so in X.400 (1984), MTAs are named by MD plus a single string 🎀. That naming style is still supported, so MTAs get named in the O/R Address tree relative to the root of the DIT (or maybe in a different routing tree). The mTAName attribute is what names them in this case 💖. For X.400(88), the Distinguished Name shall be passed as an AE Title 📝. An MTA can also be named with any other DN, and that DN can live in the O/R Address or the Organisational DIT hierarchy. There are a few reasons an MTA might get named differently, and honestly they're all very relatable 🥹:
- The flat naming space is inadequate to support large MDs. MTA name assignment using the directory would be awkward 😩.
- An MD does not wish to register its MTAs in this way. Basically, it prefers to give them private names in the directory 🙈.
- An organisation has a policy for naming application processes, which does not fit this approach 🏢.
In this case, the MTA entry shall contain the correct information to be inserted in trace 🔍. The mTAName and globalDomainID attributes are used to do this. They are single value. If an MTA inserts different trace in different circumstances, a more complex approach would be needed, and that's a whole other chapter 📚.
An MD may choose to name its MTAs outside of the O/R address hierarchy, and then link some or all of them with aliases 🦋. A pointer from that space may help when you're resolving information based on MTA Trace.
Now the main case, where an MTA supports one application context (protocol). The MTA is represented in the directory by a single directory entry, with no subordinate applicationEntity entries. That name counts as the name of the MTA and its Application Process Title 👑. The MTA has no Application Entity Qualifier, so this is also the Application Entity Title. When an MTA supports more than one application context, the Application Process Title is exactly the same as above, but it also has one or more subordinate applicationEntity entries 🌈. Each of those subordinate entries is associated with a single application context. The relative distinguished name of the subordinate applicationEntity entry is the Application Entity Qualifier of the Application Entity Title. The Application Entity Title is the distinguished name of the applicationEntity. And the term MTA Name is used to refer to the Application Process Title ✨.
15.1. Naming 1984 MTAs
Some simplifications are necessary for 1984 MTAs, and only one naming approach may be used 🍓. This is because Directory Names are not carried in the protocol, so the name has to be derivable algorithmically from the parameters that do get carried 🧠. In X.400, MTAs are named by MD and a single string. That style is supported, with MTAs named in the O/R Address tree relative to the root of the DIT (or possibly in a different routing tree). The MTAName attribute is used to name MTAs in this case 💅.
16. Attributes Associated with the MTA
This section is the cheat sheet 🧾. It lists the attributes that may be associated with an MTA as defined in Figure 6, and points you to the sections that describe each one 🫶.
mTANameSection 15.globalDomainIDSection 15.protocolInformationSection 18.1.applicationContextSection 18.2.mhs-deliverable-content-lengthSection 18.3.responderAuthenticationRequirementsSection 20.2.initiatorAuthenticationRequirementsSection 20.2.responderPullingAuthenticationRequirementsSection 20.2.initiatorPullingAuthenticationRequirementsSection 20.2.initiatorP1ModeSection 19.responderP1ModeSection 19.polledMTAsSection 19.mTAsAllowedToPollSection 19.respondingRTSCredentialsSection 20.3.initiatingRTSCredentialsSection 20.3.callingPresentationAddressSection 20.3.callingSelectorValiditySection 20.3.bilateralTableSection 17.mTAWillRouteSection 21.routingTreeListSection 9.supportedMTSExtensionsSection 18.3.
mTABilateralTableEntry OBJECT-CLASS ::=
SUBCLASS OF {mTA| distinguishedNameTableEntry}
ID oc-mta-bilateral-table-entry}Figure 7: MTA Bilateral Table Entry
17. Bilateral Agreements
Every MTA has an entry in the DIT 📇. That entry holds information which is globally valid, and it's useful for general info about the MTA and anything shared by all its connections. In lots of cases, that's all you need 💖. This global information may be restricted by access control, so it doesn't have to be globally available 🔒. But some MTAs keep bilateral and multilateral agreements, which hold authentication and related info that is NOT globally valid 🤫. This section describes a way to group that info into tables. That lets an MTA have bilateral information, or lets a group of MTAs share multilateral information 🤝. The description focuses on bilateral info, but it applies equally to multilateral agreements.
For a bilateral agreement, the MTA is treated as an application entity 🎀. That means that when this is distinct from the application process, the agreements are protocol specific.
A bilateral agreement is represented by one entry for each MTA in the agreement 💜. From one end, the agreement info is keyed by the name of the MTA at the other end. Each party sets up the entry that represents its half of the agreed policy 💅. The fact that the two halves correspond is controlled by the external agreement. In many cases, only one half is in the directory. The other half might be in an ADMD MTA configuration file 📁.
MTA bilateral information is stored in a table, as defined in [15] 📚. An MTA has access to a sequence of these tables, and each one controls agreements in both directions for a given MTA. If an MTA is represented in multiple tables, the first agreement shall be used 🥇. That's what lets an MTA join multilateral agreements while still having private agreements that override them 👑. The entries in this table are defined in Figure 7. This table will usually be access controlled, so that only a single MTA, or selected MTAs that appear externally as one MTA, can access it 🔐.
bilateralTable ATTRIBUTE ::= {
WITH SYNTAX SEQUENCE OF DistinguishedName
SINGLE VALUE
ID at-bilateral-table}Figure 8: Bilateral Table Attribute
Each entry in the table is of the object class distinguishedNameTableEntry, which names the entry by the distinguished name of the MTA 🏷️. In some cases discussed in Section 20.1, there will also be aliases of type textTableEntry 🦋. The MTA attributes needed as part of the bilateral agreement (typically MTA Name/Password pairs), as described in Section 20.3, will always be present 🔑. Other MTA attributes (for example, presentation address) may be present for one of two reasons:
- As a performance optimisation ⚡
- Because the MTA does not have a global entry 🫥
Every MTA with bilateral agreements will define a bilateral MTA table 🗂️. When a connection from a remote MTA is received, its Distinguished Name is used to generate the name of the table entry. For 1984, the MTA Name exchanged at the RTS level is used as a key into the table 🔑. The location of the bilateral tables used by the MTA, and the order they're used in, are defined by the bilateralTable attribute in the MTA entry, which is defined in Figure 8 💅.
All of the MTA information described in Section 16 may be used in the bilateral table entries 🌸. That allows bilateral control of a wide range of parameters, which is honestly so powerful 😭.
Note: For some bilateral connections there is a need to control various other functions, such as trace stripping and originator address manipulation. For now, this is left to implementation specific extensions. This is expected to be reviewed in light of implementation experience.
18. MTA Selection ✨
18.1. Dealing with protocol mismatches ✨
Okay so MTAs don't all run the same stack 🙈 some of them literally can't talk to each other directly. Even when the protocols match, there can still be reasons a direct connection isn't possible. A place where there's full connectivity over one single stack is called a transport community [9] 🫶. The set of transport communities an MTA supports is specified with the protocolInformation attribute from X.500(93). It also gets its own separate attribute, just to make routing decisions easier 💅.
Figure 9: Supported MTS Extensions
supportedMTSExtensions ATTRIBUTE ::= {
SUBTYPE OF objectIdentifier
ID at-supported-mts-extensions}A community is identified by an object identifier, so the mechanism is totally good with both well known and private communities 🌈. A list of object identifiers for the well known communities is in Appendix B 🦋.
18.2. Supported Protocols
It's super important to know an MTA's protocol capabilities 👑. This is handled by the application context. There are standard definitions for the following 1988 protocols:
- P3 (with and without RTS, both user and MTS initiated)
- P7 (with and without RTS).
- P1 (various modes). Strictly, this is the only one that matters for routing.
To support P1(1984) and P1(1988) in X.410 mode, the application contexts that define them are given in Appendix C 🧚. Heads up though: this context is for use in the directory only, and would never be exchanged over the network 🙈.
For routing purposes, a message store that isn't co-resident with an MTA is represented as if it had a co-resident MTA, configured with a single link to its supporting MTA 💖.
When the UA is involved in exchanges, the UA will be of object class mhs-user-agent, which allows appropriate communication information to be registered 🎀.
18.3. MTA Capability Restrictions
On top of the policy restrictions described in Section 21 💅, an MTA may have capability restrictions. The maximum size of MPDU is defined by the standard attribute mhs-deliverable-content-length. The supported MTS extensions are defined by a new attribute specified in Figure 9 ✨.
restrictedSubtree OBJECT-CLASS ::= {
SUBCLASS OF {top}
KIND auxiliary
MAY CONTAIN {
subtreeDeliverableContentLength|
subtreeDeliverableContentTypes|
subtreeDeliverableEITs}
ID oc-restricted-subtree}
10
subtreeDeliverableContentLength ATTRIBUTE ::= {
SUBTYPE OF mhs-deliverable-content-length
ID at-subtree-deliverable-content-length}
subtreeDeliverableContentTypes ATTRIBUTE ::= {
SUBTYPE OF mhs-deliverable-content-types
ID at-subtree-deliverable-content-types}
subtreeDeliverableEITs ATTRIBUTE ::= {
SUBTYPE OF mhs-deliverable-eits 20
ID at-subtree-deliverable-eits}Figure 10: Subtree Capability Restriction
It may be useful to define other capability restrictions, for example to enable routing of messages around MTAs with specific deficiencies 🔧. It has been suggested using MTA capabilities as an optimised means of expressing the capabilities of all users associated with the MTA. This is felt to be undesirable 🙅.
18.4. Subtree Capability Restrictions
In many cases, users of a subtree share the same capabilities 🌸. You can specify that with attributes, as defined in Figure 10. This lets restrictions be determined in cases where there's no entry for the user or O/R Address. It's a useful optimisation when UA capability information isn't available from the directory, either for policy reasons or because it simply isn't there 🍓. This information may also be present in the domain tree (RFC 822).
This shall be implemented as a collective attribute, so that it's available to all entries in the subtree below the entry. It can also be used for setting defaults in the subtree 💜.
initiatorP1Mode ATTRIBUTE ::= {
WITH SYNTAX P1Mode
SINGLE VALUE
ID at-initiator-p1-mode}
responderP1Mode ATTRIBUTE ::= {
WITH SYNTAX P1Mode
SINGLE VALUE
ID at-responder-p1-mode} 10
P1Mode ::= ENUMERATED {
push-only(0),
pull-only(1),
twa(2) }
polledMTAs ATTRIBUTE ::= {
WITH SYNTAX PolledMTAs
ID at-polled-mtas}
20
PolledMTAs ::= SEQUENCE {
mta DistinguishedName,
poll-frequency INTEGER OPTIONAL --frequency in minutes
}
mTAsAllowedToPoll ATTRIBUTE ::= {
SUBTYPE OF distinguishedName
ID at-mtas-allowed-to-poll}Figure 11: Pulling Messages
19. MTA Pulling Messages ✨
Pulling messages between MTAs, typically by use of two way alternate, is for bilateral agreement 🤝. It's not the common case. There are two circumstances where it can come up:
- Making use of a connection that was opened to push messages.
- Explicitly polling in order to pull messages
Attributes to support this are defined in Figure 11. These attributes indicate the capabilities of an MTA to pull messages, and allow a list of polled MTAs to be specified. If omitted, the normal case of push-only is specified. In the MTA Entry, the polledMTAs attribute indicates MTAs which are to be polled, and the mTAsAllowedToPoll attribute indicates MTAs that may poll the current MTA 🫶.
20. Security and Policy 🔐
20.1. Finding the Name of the Calling MTA
A key issue for authentication is for the called MTA to find the name of the calling MTA 😤. It needs that to be able to look up information on a bilateral agreement.
Where X.400(88) is used, the name is available as a distinguished name from the AE-Title, which is derived from the AP-Title and AE-Qualifier in the A-Associate. For X.400(84), it won't be possible to derive a global name from the bind. The MTA Name exchanged in the RTS Bind will provide a key into the private bilateral agreement table (or tables), where the connection information can be verified. So for X.400(1984), it'll only be possible to have bilateral inbound links or no authentication of the calling MTA 💀.
Note: CDC use a search here, as a mechanism to use a single table and an 88/84 independent access. This may be considered for general adoption. It appears to make the data model cleaner, possibly at the expense of some performance. This will be considered in the light of implementation experience.
20.2. Authentication
The levels of authentication an MTA requires will have an impact on routing 🔑. For example, if an MTA requires strong authentication, not all MTAs will be able to route to it. The attributes which define the authentication requirements are in Figure 12.
The attributes specify authentication levels for the following cases:
Responder: These are the checks that the responder will make on the initiator's credentials.
Initiator: These are the checks that the initiator will make on the responders credentials. Very often, no checks are needed --- establishing the connection is sufficient.
Responder Pulling: These are responder checks when messages are pulled. These will often be stronger than for pushing.
Initiator Pulling: For completeness.
If an attribute is omitted, no checks are required. If multiple checks are required, then each of the relevant bits shall be set. The attribute is single value, which implies that the MTA must set a single authentication policy 🧠.
responderAuthenticationRequirements ATTRIBUTE ::= {
WITH SYNTAX AuthenticationRequirements
SINGLE VALUE
ID at-responder-authentication-requirements}
initiatorAuthenticationRequirements ATTRIBUTE ::= {
WITH SYNTAX AuthenticationRequirements
SINGLE VALUE
ID at-initiator-authentication-requirements} 10
responderPullingAuthenticationRequirements ATTRIBUTE ::= {
WITH SYNTAX AuthenticationRequirements
SINGLE VALUE
ID at-responder-pulling-authentication-requirements}
initiatorPullingAuthenticationRequirements ATTRIBUTE ::= {
WITH SYNTAX AuthenticationRequirements
SINGLE VALUE
ID at-initiator-pulling-authentication-requirements} 20
AuthenticationRequirements ::= BITSTRING {
mta-name-present(0),
aet-present(1),
aet-valid(2),
network-address(3),
simple-authentication(4),
strong-authentication(5),
bilateral-agreement-needed(6)}Figure 12: Authentication Requirements
The values of the authentication requirements mean:
mta-name-present: That an RTS level MTA parameter shall be present for logging purposes.
aet-present: That a distinguished name application entity title shall be provided at the ACSE level.
aet-valid: As for aet-present, and that the AET be registered in the directory. This may be looked up as a part of the validation process. If mta-name-present is set, the RTS value of mta and password shall correspond to those registered in the directory 🪪.
network-address: This can only be used for the responder. The AET shall be looked up in the directory, and the callingPresentationAddress attribute matched against the calling address. This shall match exactly at the network level. The validity of selectors will be matched according to the callingSelectorValidity attribute 📡.
simple-authentication: All MTA and password parameters needed for simple authentication shall be used. This will usually be in conjunction with a bilateral agreement.
strong-authentication: Use of strong authentication 💪.
bilateral-agreement-needed: This means that this MTA will only accept connections in conjunction with a bilateral or multilateral agreements. This link cannot be used unless such an agreement exists 🚫.
These attributes may also be used to specify UA/MTA authentication policy. They may be resident in the UA entry in environments where this information cannot be modified by the user. Otherwise, it will be present in an MTA table (represented in the directory) 📒.
An MTA could choose to have different authentication levels related to different policies (Section 21). This is seen as too complex, so they are kept independent. The equivalent function can always be achieved by using multiple Application Entities with the application process 🌈✨
20.3. Authentication Information ✨
okay so this bit is all about the connection info P1 needs 🫶 it's basically the RTS setup used for authentication 🔐 it's laid out in Figure 13. ngl the confidential bilateral stuff is implied by these attributes, so it lives in the bilateral information agreement 🤫 and it shall have appropriate access control applied, no exceptions 💅 also heads up: sometimes MTA info gets split across a private entry and a public one 👀
respondingRTSCredentials ATTRIBUTE ::= {
WITH SYNTAX RTSCredentials
SINGLE VALUE
ID at-responding-rts-credentials}
initiatingRTSCredentials ATTRIBUTE ::= {
WITH SYNTAX RTSCredentials
SINGLE VALUE 10
ID at-initiating-rts-credentials}
RTSCredentials ::= SEQUENCE {
request [0] MTAandPassword OPTIONAL,
response [1] MTAandPassword OPTIONAL }
MTAandPassword ::= SEQUENCE {
MTAName, 20
Password } -- MTAName and Password
-- from X.411
callingPresentationAddress ATTRIBUTE ::= {
SUBTYPE OF presentationAddress
MULTI VALUE
ID at-calling-presentation-address}
callingSelectorValidity ATTRIBUTE ::= { 30
WITH SYNTAX CallingSelectorValidity
SINGLE VALUE
ID at-calling-selector-validity}
CallingSelectorValidity ::= ENUMERATED {
all-selectors-fixed(0),
tsel-may-vary(1),
all-selectors-may-vary(2) }
Figure 13: MTA Authentication Parameters mTAWillRoute ATTRIBUTE ::= {
WITH SYNTAX MTAWillRoute
ID at-mta-will-route}
MTAWillRoute ::= SEQUENCE {
from [0] SET OF ORAddressPrefix OPTIONAL,
to [1] SET OF ORAddressPrefix OPTIONAL,
from-excludes [2] SET OF ORAddressPrefix OPTIONAL,
to-excludes [3] SET OF ORAddressPrefix OPTIONAL } 10
ORAddressPrefix ::= DistinguishedName
Figure 14: Simple MTA Policy SpecificationThe parameters are:
- Initiating Credentials 🔑 the credentials used when the local MTA initiates the association. They're the ones to insert into the request, and the ones expected back in the response.
- Responding Credentials 🔁 the credentials used when the remote MTA initiates the association. This is the one expected in the request, and the ones to be inserted into the response.
- Remote Presentation Address 📍 the valid presentation addresses the remote MTA may connect from.
If an MTA/Password pair is left out, the MTA shall default to the local MTA Name, and the password shall default to a zero-length OCTET STRING ✨
Note: future versions of this specification may add more info here about parameters needed for strong authentication 👀
21. Policy and Authorisation 🎀
21.1. Simple MTA Policy
so the routing trees are usually set up to figure out which MTAs will route to a destination 🗺️ there's a simple way to spell out an MTA's policy, and it's defined in Figure 14. if this attribute is omitted, the MTA shall route all traffic to the implied destinations, from the context of the routing tree, for any MTAs that have valid access to that routing tree 🦋
the multi-valued attribute gives a set of policies the MTA will route. O/R Addresses are shown as a prefix, which picks out a subtree, and they use a distinguished name encoding of the O/R Address. here are the components:
- from 📤 the set of O/R addresses that get permission from this attribute value. if it's omitted,
"all"is implied. - to 📥 the set of acceptable destinations. if it's omitted,
"all"is implied. - from-excludes 🚫 subtrees of the O/R address tree (by prefix) that get explicitly carved out of the "from" definition. if it's omitted, there are no exclusions.
- to-excludes 🙅 subtrees of the O/R address tree (by prefix) that get explicitly carved out of the "to" definition. if it's omitted, there are no exclusions.
this simple policy is enough for most cases 💖 especially the real situations where a policy choice is forced, and where applying the policy would otherwise stop a message from being routed at all.
this simple prefixing approach doesn't deal with alias dereferencing directly. the prefixes refer to O/R addresses where aliases have already been dereferenced. to match against them, O/R addresses being matched need to be "normalised by being looked up in the directory to resolve alias values. if the lookup fails, the provided address shall be assumed to already be normalised. this means policy may be misread for parts of the DIT that aren't referenced in the directory 🫠
the originator is the MTS originator, and the recipient is the MTS recipient, after any list expansion or redirect has happened. this simple policy does not apply to delivery reports 🚫 any advertised route shall work for delivery reports, and regulating them based on the sender doesn't make sense.
21.2. Complex MTA Policy
MTAs will usually have a way more complex policy mechanism, like the one provided by PP MTA [10] 🧠 representing that as part of the routing decision isn't done here, but it might get addressed in future versions. some of the issues that need sorting out are:
- Use of charging and non-charging nets 💸
- Policy dependent on message size 📦
- Different policy for delivery reports 📬
- Policy dependent on attributes of the originator or recipient (e.g., mail from students) 🎓
- Content type and encoded information types 🖼️
- The path which the message has traversed to reach the MTA 🛤️
- MTA bilateral agreements 🤝
- Pulling messages 🎣
- Costs. This sort of policy information may also be for information only 🏷️
MTAs may apply more complex routing policies. however, this shall not lead to the rejection of messages which might otherwise be correctly routed on the published policy information. policies relating to submission don't need to be public, and they can be private to the MTA 🤫
redirect ATTRIBUTE ::= {
WITH SYNTAX Redirect
SINGLE VALUE
ID at-redirect}
Redirect ::= SEQUENCE OF SEQUENCE {
or-name ORName,
reason RedirectionReason, -- from X.411
filter CHOICE { 10
min-size [1] INTEGER,
max-size [2] INTEGER,
content [3] ContentType,
eit [4] ExternalEncodedInformationType } OPTIONAL
}
Figure 15: Redirect Definition22. Delivery 🚚
22.1. Redirects
we need a way to specify redirects in the Directory 📖 this is handy for alternate names where a synonym defined by an alias just doesn't feel natural. an example would be redirecting mail to a new O/R address when a user has changed organisation 🏢 there's also a mechanism for conditional (filtered) redirects, so you can treat different types of messages differently. small messages, large messages, or messages containing specific EITs or content can all get redirected ✨ the definitions are in Figure 15.
redirection is specified by the redirect attribute 🎯 if it's present, this attribute shall be processed before supportingMTA and nonDeliveryInfo. those two shall only be considered if it's been determined that no redirection applies. the redirect attribute is a sequence of elements, and they get considered in the order specified, one at a time. the first element that applies gets used, and no further elements are examined 🛑 using an element for redirection shall follow the X.400 procedures for redirection, and an element shall not be used if a service control prevents it. if the redirect attribute gets processed and no redirection is generated, processing shall continue regardless of service controls. if non-delivery is intended in that case, it shall be achieved using the nonDeliveryInfo attribute 📭
here's what the components mean 👇
- or-name 🏷️ this X.400 O/R Name is used for the redirection. it can contain an optional directory name and an optional O/R address, and one or both of them must be present. if the O/R Address element is present, the Directory Name (if there is one) is for information only, and it's to be placed in the X.400 redirection. if the O/R Address element is absent, the Directory Name shall be present and shall be looked up to find the O/R address of the redirected recipient. the O/R Address of the intended recipient will either be present or derived by lookup, and routing shall be done based on this O/R Address 🗺️
- reason 💬 this is the reason information to be placed in the X.400 redirect. it shall take one of the following values of RedirectReason defined in X.411:
recipient-assigned-alternate-recipientrecipient-MD-assigned-alternate-recipientalias
it shall not have the value originator-requested-alternate-recipient 🙅
- filter 🔍 if
filteris absent, the redirect is mandatory and shall be followed. if the filter is present, whether the redirect under consideration gets used depends on the type of filter, as follows:min-sizefollow the redirect if the message (MT content) is larger than min-size (measured in kBytes) 📏max-sizefollow the redirect if the message (MT content) is smaller than max-size (measured in kBytes) 📐contentfollow the redirect if the message content is of type content 🧾eitfollow the redirect if the encoded information types registered in the envelope contain eit 🏷️
when a delivery report gets sent to an address that would be redirected, X.400 would ignore the redirect 🙃 that means every O/R address would need a valid means of delivery, which sounds super awkward to manage. so, the redirect shall be followed, and the delivery report is delivered to the redirected address instead 💌
these redirects are handled directly by the MTA. redirects can also be initiated by the UA, for example in the context of a P7 interaction 🦋
nonDeliveryInfo ATTRIBUTE ::= {
WITH SYNTAX NonDeliveryReason
SINGLE VALUE
ID at-non-delivery-info}
NonDeliveryReason ::= SEQUENCE {
reason INTEGER (0..ub-reason-codes),
diagnostic INTEGER (0..ub-diagnostic-codes) OPTIONAL,
supplementaryInfo PrintableString OPTIONAL } 10
Figure 16: Non Delivery Information22.2. Underspecified O/R Addresses ✨
okay so X.400 has rules for how some underspecified O/R Addresses get handled, like when a surname shows up with no initials or given name 🫠. If one of those is supposed to be treated as a different O/R Address, an alias SHALL be used 💅. If it's getting rejected as ambiguous instead, an entry SHALL be created in the DIT, with forced non-delivery specified for that reason 🚫.
Note: It's also possible to handle this by searching 🔍. An MTA conforming to this specification MAY handle underspecified addresses that way. The choice of mechanism will be reviewed after operational experience with both approaches.
22.3. Non Delivery 🚫
It's possible for a manager to define an address that non-delivers, with a specified reason and diagnostic codes 🙈. This could be handy for a range of management purposes. The attribute for this is defined in Figure 16. If a nonDeliveryInfo attribute is present, any supportingMTA attribute SHALL be ignored and the message non-delivered 💀.
22.4. Bad Addresses 🔍
okay so if there's a bad address, it's desirable to do a directory search to find alternatives 🧚. This is a helpful user service and MAY be supported. The function gets invoked after address checking has failed, and only where there's no user-supplied alternate recipient. It's basically an MTA-chosen alternative to an administratively assigned alternate recipient 🫶.
Attributes to support handling bad addresses are defined in Figure 17. They are:
badAddressSearchPoint: this gives the point (or list of points) to search from.badAddressSearchAttributes: this gives the set of attribute types to search on. The default is common name.
badAddressSearchPoint ATTRIBUTE ::= {
SUBTYPE OF distinguishedName
ID at-bad-address-search-point}
badAddressSearchAttributes ATTRIBUTE ::= {
WITH SYNTAX AttributeType
ID at-bad-address-search-attributes}
alternativeAddressInformation EXTENSION 10
AlternativeAddressInformation
::= id-alternative-address-information
-- X.400(92) continues to use MACRO notation
AlternativeAddressInformation ::= SET OF SEQUENCE {
distinguished-name DistinguishedName OPTIONAL,
or-address ORAddress OPTIONAL,
other-useful-info SET OF Attribute }
Figure 17: Bad Address PointersSearches are always single level and always use approximate match 🎯. If a small number of matches come back, they're returned to the originator through the per recipient AlternativeAddressInformation in the delivery report (DR). This SHALL be marked non-critical, so it won't cause the DR to be discarded (for example when downgrading to X.400(1984)) 🙏. This attribute lets the Distinguished Name and O/R Address of possible alternate recipients get returned with the delivery report. There's also room to attach extra information as directory attributes, which is typically used to return attributes of the entry that matched the search 🦋. A summary of the information SHALL also be returned in the delivery report supplementary information field, for example: "your message could not be delivered to smith, try J. Smith or P. Smith". That way, user agents that don't support this extension still get the info 💖. Note that the length restriction on this field is 256 (ub-supplementary-info-length) in X.400(1988).
If the directory search fails, or no matches are returned, a delivery report SHALL be returned as if this extra check had never been made 🌸.
Note: It might be useful to allow control of search type, and also single level vs subtree. This issue is for further study.
localAccessUnit ATTRIBUTE ::= {
WITH SYNTAX AccessUnitType
ID at-local-access-unit}
AccessUnitType ::= ENUMERATED {
fax (1),
physical-delivery (2),
teletex (3),
telex (4) } 10
accessUnitsUsed ATTRIBUTE ::= {
WITH SYNTAX SelectedAccessUnit
ID at-access-units-used}
SelectedAccessUnit ::= SEQUENCE {
type AccessUnitType,
providing-MTA DistinguishedName,
filter SET OF ORAddress OPTIONAL }
Figure 18: Access UnitAttributes23. Submission 📮
A message may be submitted with Distinguished Name only. If the MTA it's submitted to supports this service, this section explains how the mapping works 🎀.
23.1. Normal Derivation 🔎
The Distinguished Name gets looked up to find the attribute mhs-or-addresses. If the attribute is single valued, it's straightforward. If there are multiple values, one O/R address SHALL be selected at random 🎲.
23.2. Roles and Groups 👑
There's some support for roles here 💜. If there's no O/R address and the entry is of object class role, then the roleOccupant attribute SHALL be dereferenced, and the message submitted to each of the role occupants. Same vibe for groups: if the entry is of object class group, the groupMember attribute is used 🫂.
24. Access Units 🌈
Attributes needed for supporting Access Units, as defined in X.400(88), are defined in Figure 18. The attributes defined are:
localAccessUnit: this defines the list of access units the MTA supports.accessUnitsUsed: this defines which access units the MTA uses, giving the type and MTA. An O/R Address filter is provided to control which access unit is used for a given recipient. For a filter to match an address, all attributes specified in the filter SHALL match the given address. This is specified as an O/R Address, so routing to access units can be filtered on attributes that aren't mapped onto the directory (for example, postal attributes) 📬. Where a remote MTA is used, it may be necessary to use source routing 🧭.
Note 1: This mechanism might be used to replace the routefilter mechanism of the MTS routing. Comments are solicited.
Note 2: It has been proposed to add a more powerful filter mechanism. Comments are solicited.
Note 3: The usefulness of this specification as a mechanism to route faxes and other non-MHS messages has been noted, but not explored. Comments on how and if this should be developed are solicited.
These three issues are for further study 🔮.
25. The Overall Routing Algorithm 🗺️
Now that we've covered all the pieces, here's a summary of how routing works 🔥.
The core of X.400 routing is described in Section 10. A sequence of routing trees gets followed. As nodes of the routing tree match, a set of MTAs gets identified for evaluation as possible next hops. If all of these get rejected, the trees keep being followed further. (One could argue the trees should be followed to find alternate routes when only one MTA is acceptable. That's not proposed 🙃.) A set of MTAs is evaluated on the following criteria:
- If an MTA is the local MTA, deliver locally.
- Supported protocols. The MTA SHALL support a protocol that the current MTA supports, as described in Section 18.2.
(Note that this could be an RFC 822 protocol, as well as an X.400 protocol.)
- The protocols SHALL share a common transport community, as described in Section 18.1.
- There SHALL be no capability restrictions in the MTA that prevent transfer of the current message, as described in Section 18.3.
- There SHALL be no policy restrictions in the MTA that prevent transfer of the current message, as described in Section 21.
- The authentication requirements of the MTA SHALL be met by the local MTA, as described in Section 20.2.
- If the authentication (Section 20.2) indicates that a bilateral agreement is present, the MTA SHALL be listed in the local set of bilateral agreements, as described in Section 17.
- In cases where the recipient UA's capabilities can be determined, there SHOULD either be no mismatch, or there SHALL be an ability to use local or remote reformatting capabilities, as described in [12] 🛠️.
26. Performance ⚡
The routing algorithm was designed with performance in mind 💅. In particular, care was taken to use only the read function, which will generally be optimised. Routing trees may be configured so that routing decisions can be made with only two directory reads. More complex configurations won't need a substantially larger number of operations. Lowkey impressive 🥹.
27. Acknowledgements 🫶
This memo is the central document of a series of specifications [14, 15, 16], and of other work in progress. The acknowledgements for all of this work are given here. Previous work that significantly influenced these specifications is described in Section 3. This led to an initial proposal by the editor, which was later split into eight documents. Work on these specifications was done by the IETF MHS-DS working group. Special credit goes to the joint chairs of this group: Harald Alvestrand (Uninett) and Kevin Jordan (CDC) 👑. Credit also goes to all members of the WG. Those who made active contributions include: Piete Brooks (Cambridge University); Allan Cargille (University of Wisconsin); Jim Craigie (JNT); Dennis Doyle (SSS); Urs Eppenberger (SWITCH); Peter Furniss; Christian Huitema (Inria); Marko Kaittola (Dante); Sylvain Langlois (EDF); Lucy Loftin (AT&T GIS); Julian Onions (NEXOR); Paul-Andre Pays (Inria); Colin Robbins (NEXOR); Michael Roe (Cambridge University); Jim Romaguera (Netconsult); Michael Storz (Leibniz Rechenzentrum); Mark Wahl (ISODE Consortium); Alan Young (ISODE Consortium) 🌟.
This work was partly funded by the COSINE Paradise project 💜.
28. References ✨
okay bestie, this is the reading list 📚🎀 every source the author leaned on, and yes, they're all there in full.
- [1] The Directory --- overview of concepts, models and services, 1993. CCITT X.500 Series Recommendations.
- [2] J.N. Chiappa. A new IP routing and addressing architecture, 1991.
- [3] A. Consael, M. Tschicholz, O. Wenzel, K. Bonacker, and M. Busch. DFN-Directory nutzung durch MHS, April 1990. GMD Report.
- [4] P. Dick-Lauder, R.J. Kummerfeld, and K.R. Elz. ACSNet - the Australian alternative to UUCP. In EUUG Conference, Paris, pages 60--69, April 1985.
- [5] Eppenberger, U., "Routing Coordination for X.400 MHS Services Within a Multi Protocol / Multi Network Environment Table Format V3 for Static Routing", RFC 1465, SWITCH, May 1993.
- [6] K.E. Jordan. Using X.500 directory services in support of X.400 routing and address mapping, November 1991. Private Note.
- [7] S.E. Kille. MHS use of directory service for routing. In IFIP 6.5 Conference on Message Handling, Munich, pages 157--164. North Holland Publishing, April 1987.
- [8] S.E. Kille. Topology and routing for MHS. COSINE Specification Phase 7.7, RARE, 1988.
- [9] Kille, S., "Encoding Network Addresses to support operation over non-OSI lower layers", RFC 1277, Department of Computer Science, University College London, November 1991.
- [10] S.E. Kille. Implementing X.400 and X.500: The PP and QUIPU Systems. Artech House, 1991. ISBN 0-89006-564-0.
- [11] Kille, S., "A Representation of Distinguished Names (OSI-DS 23 (v5))", RFC 1485, Department of Computer Science, University College London, January 1992.
- [12] Kille, S., Mhs use of X.500 directory to support mhs content conversion, Work in Progress, July 1993.
- [13] Kille, S., "Use of the X.500 directory to support routing for RFC 822 and related protocols", Work in Progress, July 1993.
- [14] Kille, S., "Representing tables and subtrees in the X.500 directory", Work in Progress, September 1994.
- [15] Kille, S., "Representing the O/R Address hierarchy in the X.500 directory information tree", Work in Progress, September 1994.
- [16] Kille, S., "Use of the X.500 directory to support mapping between X.400 and RFC 822 addresses", Work in Progress, September 1994.
- [17] Lauder, P., Kummerfeld, R., and A. Fekete. Hierarchical network routing. In Tricomm 91, 1991.
- [18] CCITT recommendations X.400 / ISO 10021, April 1988. CCITT SG 5/VII / ISO/IEC JTC1, Message Handling: System and Service Overview.
- [19] Zen and the ART of navigating through the dark and murky regions of the message transfer system: Working document on MTS routing, September 1991. ISO SC 18 SWG Messaging.
29. Security Considerations 🔒
okay this section is SHORT but it's giving main character drama 😭 Security issues are not discussed in this memo. so if you're looking for the security tea, it's not in here, bestie 🙈 go check somewhere else before you ship anything 💀
30. Author's Address 💌
this is where you find the author, Steve Kille, over at ISODE Consortium 🧚
Steve Kille
ISODE Consortium
The Dome
The Square
Richmond
TW9 1DT
England
Phone: +44-81-332-9091
EMail: S.Kille@ISODE.COM
X.400: I=S; S=Kille; O=ISODE Consortium; P=ISODE;
A=Mailnet; C=FI;
DN: CN=Steve Kille,
O=ISODE Consortium, C=GB
UFN: S. Kille, ISODE Consortium, GBA. Object Identifier Assignment 🦋
this appendix is the OID hall of fame, where every routing object gets its own little number tag 💜
mhs-ds OBJECT-IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1)
private(4) enterprises(1) isode-consortium (453) mhs-ds (7)}
routing OBJECT IDENTIFIER ::= {mhs-ds 3}
oc OBJECT IDENTIFIER ::= {routing 1}
at OBJECT IDENTIFIER ::= {routing 2}
id OBJECT IDENTIFIER ::= {routing 3}
oc-mta OBJECT IDENTIFIER ::= {oc 1}
oc-mta-bilateral-table-entry OBJECT IDENTIFIER ::= {oc 2}
oc-routing-information OBJECT IDENTIFIER ::= {oc 3}
oc-restricted-subtree OBJECT IDENTIFIER ::= {oc 4}
oc-routed-ua OBJECT IDENTIFIER ::= {oc 8}
oc-routing-tree-root OBJECT IDENTIFIER ::= {oc 6}
oc-mta-application-process OBJECT IDENTIFIER ::= {oc 7}
at-access-md OBJECT IDENTIFIER ::= {at 1}
at-access-units-used OBJECT IDENTIFIER ::= {at 2}
at-subtree-information OBJECT IDENTIFIER ::= {at 3}
at-bad-address-search-attributes OBJECT IDENTIFIER ::= {at 4}
at-bad-address-search-point OBJECT IDENTIFIER ::= {at 5}
at-calling-selector-validity OBJECT IDENTIFIER ::= {at 7}
at-global-domain-id OBJECT IDENTIFIER ::= {at 10}
at-initiating-rts-credentials OBJECT IDENTIFIER ::= {at 11}
at-initiator-authentication-requirements OBJECT IDENTIFIER ::= {at 12}
at-initiator-p1-mode OBJECT IDENTIFIER ::= {at 13}
at-initiator-pulling-authentication-requirements
OBJECT IDENTIFIER ::= {at 14}
at-local-access-unit OBJECT IDENTIFIER ::= {at 15}
at-redirect OBJECT IDENTIFIER ::= {at 46}
at-mta-info OBJECT IDENTIFIER ::= {at 40}
at-mta-name OBJECT IDENTIFIER ::= {at 19}
at-mta-will-route OBJECT IDENTIFIER ::= {at 21}
at-calling-presentation-address OBJECT IDENTIFIER ::= {at 22}
at-responder-authentication-requirements OBJECT IDENTIFIER ::= {at 23}
at-responder-p1-mode OBJECT IDENTIFIER ::= {at 24}
at-responder-pulling-authentication-requirements
OBJECT IDENTIFIER ::= {at 25}
at-responding-rts-credentials OBJECT IDENTIFIER ::= {at 26}
at-routing-failure-action OBJECT IDENTIFIER ::= {at 27}
at-routing-filter OBJECT IDENTIFIER ::= {at 28}
at-routing-tree-list OBJECT IDENTIFIER ::= {at 29}
at-subtree-deliverable-content-length OBJECT IDENTIFIER ::= {at 30}
at-subtree-deliverable-content-types OBJECT IDENTIFIER ::= {at 31}
at-subtree-deliverable-eits OBJECT IDENTIFIER ::= {at 32}
at-supporting-mta OBJECT IDENTIFIER ::= {at 33}
at-transport-community OBJECT IDENTIFIER ::= {at 34}
at-user-name OBJECT IDENTIFIER ::= {at 35}
at-non-delivery-info OBJECT IDENTIFIER ::= {at 47}
at-polled-mtas OBJECT IDENTIFIER ::= {at 37}
at-bilateral-table OBJECT IDENTIFIER {at 45}
at-supported-extension OBJECT IDENTIFIER {at 42}
at-supported-mts-extension OBJECT IDENTIFIER {at 43}
at-mtas-allowed-to-poll OBJECT IDENTIFIER {at 44}
id-alternative-address-information OBJECT IDENTIFIER ::= {id 1}Figure 19: Object Identifier Assignment 🌸
B. Community Identifier Assignments 🌈
this one's all about the transport communities, the different "neighbourhoods" the messages can travel through 🏘️✨
ts-communities OBJECT-IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1)
private(4) enterprises(1) isode-consortium (453) ts-communities (4)}
tc-cons OBJECT IDENTIFIER ::= {ts-communities 1} -- OSI CONS
tc-clns OBJECT IDENTIFIER ::= {ts-communities 2} -- OSI CLNS
tc-internet OBJECT IDENTIFIER ::= {ts-communities 3}-- Internet+RFC1006
tc-int-x25 OBJECT IDENTIFIER ::= {ts-communities 4} -- International X.25
-- Without CONS
tc-ixi OBJECT IDENTIFIER ::= {ts-communities 5} -- IXI (Europe)
tc-janet OBJECT IDENTIFIER ::= {ts-communities 6} -- Janet (UK)Figure 20: Transport Community Object Identifier Assignments 💜
C. Protocol Identifier Assignments 📮
the mail protocols get their own OIDs here, so each one can be told apart at a glance 💅
mail-protocol OBJECT-IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1)
private(4)n enterprises(1) isode-consortium (453) mail-protocol (5)}
ac-p1-1984 OBJECT IDENTIFIER ::= {mail-protocol 1} -- p1(1984)
ac-smtp OBJECT IDENTIFIER ::= {mail-protocol 2} -- SMTP
ac-uucp OBJECT IDENTIFIER ::= {mail-protocol 3} -- UUCP Mail
ac-jnt-mail OBJECT IDENTIFIER ::= {mail-protocol 4} -- JNT Mail
(UK)
ac-p1-1988-x410 OBJECT IDENTIFIER ::= {mail-protocol 5} -- p1(1988) in
X.410 mode
ac-p3-1984 OBJECT IDENTIFIER ::= {mail-protocol 6} -- p3(1984)Figure 21: Protocol Object Identifier Assignments 🧚
D. ASN.1 Summary 🎀
and last but not least, the big ASN.1 summary! this is where all the routing object classes and attributes get laid out, so grab your snacks, bestie 🍓
MHS-DS-Definitions
DEFINITIONS ::=
BEGIN
-- assign OID to module
-- define imports and exports
routingTreeRoot OBJECT-CLASS ::= {
SUBCLASS OF {routingInformation|subtree}
ID oc-routing-tree-root}
routingTreeList ATTRIBUTE ::= {
WITH SYNTAX RoutingTreeList
SINGLE VALUE
ID at-routing-tree-list}
RoutingTreeList ::= SEQUENCE OF RoutingTreeName
RoutingTreeName ::= DistinguishedName
routingInformation OBJECT-CLASS ::= {
SUBCLASS OF top
KIND auxiliary
MAY CONTAIN {
subtreeInformation|
routingFilter|
routingFailureAction|
mTAInfo|
accessMD|
nonDeliveryInfo|
badAddressSearchPoint|
badAddressSearchAttributes}
ID oc-routing-information}
-- No naming attributes as this is not a
-- structural object class
subtreeInformation ATTRIBUTE ::= {
WITH SYNTAX SubtreeInfo
SINGLE VALUE
ID at-subtree-information}
SubtreeInfo ::= ENUMERATED {
all-children-present(0),
not-all-children-present(1) }
routingFilter ATTRIBUTE ::= {
WITH SYNTAX RoutingFilter
ID at-routing-filter}
RoutingFilter ::= SEQUENCE{
attribute-type OBJECT-IDENTIFIER,
weight RouteWeight,
dda-key String OPTIONAL,
regex-match IA5String OPTIONAL,
node DistinguishedName }
String ::= CHOICE {PrintableString, TeletexString}
routingFailureAction ATTRIBUTE ::= {
WITH SYNTAX RoutingFailureAction
SINGLE VALUE
ID at-routing-failure-action}
RoutingFailureAction ::= ENUMERATED {
next-level(0),
next-tree-only(1),
next-tree-first(2),
stop(3) }
mTAInfo ATTRIBUTE ::= {
WITH SYNTAX MTAInfo
ID at-mta-info}
MTAInfo ::= SEQUENCE {
name DistinguishedName,
weight [1] RouteWeight DEFAULT preferred-access,
mta-attributes [2] SET OF Attribute OPTIONAL,
ae-info SEQUENCE OF SEQUENCE {
aEQualifier PrintableString,
ae-weight RouteWeight DEFAULT preferred-access,
ae-attributes SET OF Attribute OPTIONAL} OPTIONAL
}
RouteWeight ::= INTEGER {endpoint(0),
preferred-access(5),
backup(10)} (0..20)
accessMD ATTRIBUTE ::= {
SUBTYPE OF distinguishedName
ID at-access-md}
routedUA OBJECT-CLASS ::= {
SUBCLASS OF {routingInformation}
KIND auxiliary
MAY CONTAIN {
-- from X.402
mhs-deliverable-content-length|
mhs-deliverable-content-types|
mhs-deliverable-eits|
mhs-message-store|
mhs-preferred-delivery-methods|
-- defined here
supportedExtensions|
redirect|
supportingMTA|
userName|
nonDeliveryInfo}
ID oc-routed-ua}
supportedExtensions ATTRIBUTE ::= {
SUBTYPE OF objectIdentifier
ID at-supported-extensions}
supportingMTA ATTRIBUTE ::= {
SUBTYPE OF mTAInfo
ID at-supporting-mta}
userName ATTRIBUTE ::= {
SUBTYPE OF distinguishedName
ID at-user-name}okay so this part is all ASN.1 definitions, the schema bits that say what each attribute and object class looks like on the wire 💅🧚 and the MTA stuff is giving full routing main character energy 🦋
mTAName ATTRIBUTE ::= {
SUBTYPE OF name
WITH SYNTAX DirectoryString{ub-mta-name-length}
SINGLE VALUE 130
ID at-mta-name}
-- used for naming when
-- MTA is named in O=R Address Hierarchy
globalDomainID ATTRIBUTE ::= {
WITH SYNTAX GlobalDomainIdentifier
SINGLE VALUE
ID at-global-domain-id}
-- both attributes present when MTA
-- is named outside O=R Address Hierarchy 140
-- to enable trace to be written
mTAApplicationProcess OBJECT-CLASS ::= {
SUBCLASS OF {application-process}
KIND auxiliary
MAY CONTAIN {
mTAWillRoute|
globalDomainID|
routingTreeList|
localAccessUnit| 150
accessUnitsUsed
}
ID oc-mta-application-process}
mTA OBJECT CLASS ::= { -- Application Entity
SUBCLASS OF {mhs-message-transfer-agent}
KIND structural
MAY CONTAIN {
mTAName|
globalDomainID| -- per AE variant 160
responderAuthenticationRequirements|
initiatorAuthenticationRequirements|
responderPullingAuthenticationRequirements|
initiatorPullingAuthenticationRequirements|
initiatorP1Mode|
responderP1Mode|
polledMTAs|
protocolInformation|
respondingRTSCredentials|
initiatingRTSCredentials| 170
callingPresentationAddress|
callingSelectorValidity|
bilateralTable|
mTAWillRoute|
mhs-deliverable-content-length|
routingTreeList|
supportedMTSExtensions|
mTAsAllowedToPoll
}
ID oc-mta} 180
mTABilateralTableEntry OBJECT-CLASS ::=
SUBCLASS OF {mTA| distinguishedNameTableEntry}
ID oc-mta-bilateral-table-entry}
bilateralTable ATTRIBUTE ::= {
WITH SYNTAX SEQUENCE OF DistinguishedName
SINGLE VALUE
ID at-bilateral-table}
190
supportedMTSExtensions ATTRIBUTE ::= {
SUBTYPE OF objectIdentifier
ID at-supported-mts-extensions}
restrictedSubtree OBJECT-CLASS ::= {
SUBCLASS OF {top}
KIND auxiliary
MAY CONTAIN {
subtreeDeliverableContentLength|
subtreeDeliverableContentTypes| 200
subtreeDeliverableEITs}
ID oc-restricted-subtree}
subtreeDeliverableContentLength ATTRIBUTE ::= {
SUBTYPE OF mhs-deliverable-content-length
ID at-subtree-deliverable-content-length}
subtreeDeliverableContentTypes ATTRIBUTE ::= {
SUBTYPE OF mhs-deliverable-content-types
ID at-subtree-deliverable-content-types} 210
subtreeDeliverableEITs ATTRIBUTE ::= {
SUBTYPE OF mhs-deliverable-eits
ID at-subtree-deliverable-eits}
initiatorP1Mode ATTRIBUTE ::= {
WITH SYNTAX P1Mode
SINGLE VALUE
ID at-initiator-p1-mode} 220
responderP1Mode ATTRIBUTE ::= {
WITH SYNTAX P1Mode
SINGLE VALUE
ID at-responder-p1-mode}
P1Mode ::= ENUMERATED {
push-only(0),
pull-only(1),
twa(2) } 230
polledMTAs ATTRIBUTE ::= {
WITH SYNTAX PolledMTAs
ID at-polled-mtas}
PolledMTAs ::= SEQUENCE {
mta DistinguishedName,
poll-frequency INTEGER OPTIONAL --frequency in minutes
}
240
mTAsAllowedToPoll ATTRIBUTE ::= {
SUBTYPE OF distinguishedName
ID at-mtas-allowed-to-poll}
responderAuthenticationRequirements ATTRIBUTE ::= {
WITH SYNTAX AuthenticationRequirements
SINGLE VALUE
ID at-responder-authentication-requirements}
250
initiatorAuthenticationRequirements ATTRIBUTE ::= {
WITH SYNTAX AuthenticationRequirements
SINGLE VALUE
ID at-initiator-authentication-requirements}
responderPullingAuthenticationRequirements ATTRIBUTE ::= {
WITH SYNTAX AuthenticationRequirements
SINGLE VALUE
ID at-responder-pulling-authentication-requirements}
260
initiatorPullingAuthenticationRequirements ATTRIBUTE ::= {
WITH SYNTAX AuthenticationRequirements
SINGLE VALUE
ID at-initiator-pulling-authentication-requirements}
AuthenticationRequirements ::= BITSTRING {
mta-name-present(0),
aet-present(1),
aet-valid(2),
network-address(3), 270
simple-authentication(4),
strong-authentication(5),
bilateral-agreement-needed(6)}
respondingRTSCredentials ATTRIBUTE ::= {
WITH SYNTAX RTSCredentials
SINGLE VALUE
ID at-responding-rts-credentials}
280
initiatingRTSCredentials ATTRIBUTE ::= {
WITH SYNTAX RTSCredentials
SINGLE VALUE
ID at-initiating-rts-credentials}
RTSCredentials ::= SEQUENCE {
request [0] MTAandPassword OPTIONAL,
response [1] MTAandPassword OPTIONAL }
290
MTAandPassword ::= SEQUENCE {
MTAName,
Password } -- MTAName and Password
-- from X.411
callingPresentationAddress ATTRIBUTE ::= {
SUBTYPE OF presentationAddress
MULTI VALUE 300
ID at-calling-presentation-address}
callingSelectorValidity ATTRIBUTE ::= {
WITH SYNTAX CallingSelectorValidity
SINGLE VALUE
ID at-calling-selector-validity}
CallingSelectorValidity ::= ENUMERATED {
all-selectors-fixed(0),
tsel-may-vary(1), 310
all-selectors-may-vary(2) }
mTAWillRoute ATTRIBUTE ::= {
WITH SYNTAX MTAWillRoute
ID at-mta-will-route}
MTAWillRoute ::= SEQUENCE {
from [0] SET OF ORAddressPrefix OPTIONAL,
to [1] SET OF ORAddressPrefix OPTIONAL,
from-excludes [2] SET OF ORAddressPrefix OPTIONAL, 320
to-excludes [3] SET OF ORAddressPrefix OPTIONAL }
ORAddressPrefix ::= DistinguishedName
redirect ATTRIBUTE ::= {
WITH SYNTAX Redirect
SINGLE VALUE
ID at-redirect}
Redirect ::= SEQUENCE OF SEQUENCE { 330
or-name ORName,
reason RedirectionReason, -- from X.411
filter CHOICE {
min-size [1] INTEGER,
max-size [2] INTEGER,
content [3] ContentType,
eit [4] ExternalEncodedInformationType } OPTIONAL
}
nonDeliveryInfo ATTRIBUTE ::= { 340
WITH SYNTAX NonDeliveryReason
SINGLE VALUE
ID at-non-delivery-info}
NonDeliveryReason ::= SEQUENCE {
reason INTEGER (0..ub-reason-codes),
diagnostic INTEGER (0..ub-diagnostic-codes) OPTIONAL,
supplementaryInfo PrintableString OPTIONAL }
badAddressSearchPoint ATTRIBUTE ::= { 350
SUBTYPE OF distinguishedName
ID at-bad-address-search-point}
badAddressSearchAttributes ATTRIBUTE ::= {
WITH SYNTAX AttributeType
ID at-bad-address-search-attributes}
alternativeAddressInformation EXTENSION
AlternativeAddressInformation
::= id-alternative-address-information 360
-- X.400(92) continues to use MACRO notation
AlternativeAddressInformation ::= SET OF SEQUENCE {
distinguished-name DistinguishedName OPTIONAL,
or-address ORAddress OPTIONAL,
other-useful-info SET OF Attribute }
localAccessUnit ATTRIBUTE ::= {
WITH SYNTAX AccessUnitType
ID at-local-access-unit} 370
AccessUnitType ::= ENUMERATED {
fax (1),
physical-delivery (2),
teletex (3),
telex (4) }
accessUnitsUsed ATTRIBUTE ::= {
WITH SYNTAX SelectedAccessUnit
ID at-access-units-used} 380
SelectedAccessUnit ::= SEQUENCE {
type AccessUnitType,
providing-MTA DistinguishedName,
filter SET OF ORAddress OPTIONAL }
mhs-ds OBJECT-IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1) private(4)
enterprises(1) isode-consortium (453) mhs-ds (7)}
routing OBJECT IDENTIFIER ::= {mhs-ds 3}
390
oc OBJECT IDENTIFIER ::= {routing 1}
at OBJECT IDENTIFIER ::= {routing 2}
id OBJECT IDENTIFIER ::= {routing 3}
oc-mta OBJECT IDENTIFIER ::= {oc 1}
oc-mta-bilateral-table-entry OBJECT IDENTIFIER ::= {oc 2}
oc-routing-information OBJECT IDENTIFIER ::= {oc 3}
oc-restricted-subtree OBJECT IDENTIFIER ::= {oc 4}
oc-routed-ua OBJECT IDENTIFIER ::= {oc 8} 400
oc-routing-tree-root OBJECT IDENTIFIER ::= {oc 6}
oc-mta-application-process OBJECT IDENTIFIER ::= {oc 7}
at-access-md OBJECT IDENTIFIER ::= {at 1}
at-access-units-used OBJECT IDENTIFIER ::= {at 2}
at-subtree-information OBJECT IDENTIFIER ::= {at 3}
at-bad-address-search-attributes OBJECT IDENTIFIER ::= {at 4}
at-bad-address-search-point OBJECT IDENTIFIER ::= {at 5}
at-calling-selector-validity OBJECT IDENTIFIER ::= {at 7} 410
at-global-domain-id OBJECT IDENTIFIER ::= {at 10}
at-initiating-rts-credentials OBJECT IDENTIFIER ::= {at 11}
at-initiator-authentication-requirements OBJECT IDENTIFIER ::= {at 12}
at-initiator-p1-mode OBJECT IDENTIFIER ::= {at 13}
at-initiator-pulling-authentication-requirements
OBJECT IDENTIFIER ::= {at 14}
at-local-access-unit OBJECT IDENTIFIER ::= {at 15}
at-redirect OBJECT IDENTIFIER ::= {at 46}
at-mta-info OBJECT IDENTIFIER ::= {at 40} 420
at-mta-name OBJECT IDENTIFIER ::= {at 19}
at-mta-will-route OBJECT IDENTIFIER ::= {at 21}
at-calling-presentation-address OBJECT IDENTIFIER ::= {at 22}
at-responder-authentication-requirements OBJECT IDENTIFIER ::= {at 23}
at-responder-p1-mode OBJECT IDENTIFIER ::= {at 24}
at-responder-pulling-authentication-requirements
OBJECT IDENTIFIER ::= {at 25}
at-responding-rts-credentials OBJECT IDENTIFIER ::= {at 26}
at-routing-failure-action OBJECT IDENTIFIER ::= {at 27}
at-routing-filter OBJECT IDENTIFIER ::= {at 28} 430
at-routing-tree-list OBJECT IDENTIFIER ::= {at 29}
at-subtree-deliverable-content-length OBJECT IDENTIFIER ::= {at 30}
at-subtree-deliverable-content-types OBJECT IDENTIFIER ::= {at 31}
at-subtree-deliverable-eits OBJECT IDENTIFIER ::= {at 32}
at-supporting-mta OBJECT IDENTIFIER ::= {at 33}
at-transport-community OBJECT IDENTIFIER ::= {at 34}
at-user-name OBJECT IDENTIFIER ::= {at 35}
at-non-delivery-info OBJECT IDENTIFIER ::= {at 47}
at-polled-mtas OBJECT IDENTIFIER ::= {at 37}
at-bilateral-table OBJECT IDENTIFIER {at 45} 440
at-supported-extension OBJECT IDENTIFIER {at 42}
at-supported-mts-extension OBJECT IDENTIFIER {at 43}
at-mtas-allowed-to-poll OBJECT IDENTIFIER {at 44}
id-alternative-address-information OBJECT IDENTIFIER ::= {id 1}
ts-communities OBJECT-IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1)
private(4) enterprises(1) isode-consortium (453) ts-communities (4)}
450
tc-cons OBJECT IDENTIFIER ::= {ts-communities 1} -- OSI CONS
tc-clns OBJECT IDENTIFIER ::= {ts-communities 2} -- OSI CLNS
tc-internet OBJECT IDENTIFIER ::= {ts-communities 3}-- Internet+RFC1006tc-int-x25 OBJECT IDENTIFIER ::= {ts-communities 4} -- International X.25
-- Without CONS
tc-ixi OBJECT IDENTIFIER ::= {ts-communities 5} -- IXI (Europe)
tc-janet OBJECT IDENTIFIER ::= {ts-communities 6} -- Janet (UK)
mail-protocol OBJECT-IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1)
private(4) enterprises(1) isode-consortium (453) mail-protocol (5)} 460
ac-p1-1984 OBJECT IDENTIFIER ::= {mail-protocol 1} -- p1(1984)
ac-smtp OBJECT IDENTIFIER ::= {mail-protocol 2} -- SMTP
ac-uucp OBJECT IDENTIFIER ::= {mail-protocol 3} -- UUCP Mail
ac-jnt-mail OBJECT IDENTIFIER ::= {mail-protocol 4} -- JNT Mail (UK)
ac-p1-1988-x410 OBJECT IDENTIFIER ::= {mail-protocol 5}
-- p1(1988) in X.410 mode
ac-p3-1984 OBJECT IDENTIFIER ::= {mail-protocol 6} -- p3(1984)
ENDFigure 22: ASN.1 Summary
E. Regular Expression Syntax 💅
Okay so this appendix is all about a little regex flavour for pattern matching 🧚 It's borrowed from the regex stuff you'd find in common UNIX tools like egrep(1) 🌸 The one twist is that the matching is case insensitive 🙈
A regular expression (RE) is basically a way to describe a set of character strings you want to match against, like "any string containing digits 5 through 9" 🔥 Any string in that set counts as being matched by the regular expression ✨
When there are multiple matches in a line, the regular expression grabs the longest of the leftmost matching strings 💜
Regular expressions get built up from these "single-character" RE's:
cmeans any ordinary character not listed below. An ordinary character just matches itself 🎀\is backslash. When it's followed by a special character, the RE matches the "quoted" character, which cancels the special nature of that character 🦋.is dot. It matches any single character 🌈^as the leftmost character is a caret (or circumflex) that constrains the RE to match the leftmost portion of a string. This is called an "anchored match" because it's "anchored" to a specific place in the string ⭐ The^loses its special meaning if it shows up anywhere else at the start of the RE 💀$as the rightmost character is a dollar sign that constrains the RE to match the rightmost portion of a string 🍓 The$loses its special meaning if it appears anywhere other than the end of the RE 🫶^RE$constrains the RE to match the entire string 👑[c...]is a nonempty string of characters enclosed in square brackets, and it matches any single character in the string. For example,[abcxyz]matches any single character from the setabcxyz. When the first character of the string is a caret (^), the RE matches any character except those in the rest of the string. For example,[^45678]matches any character except45678. A caret in any other position is just an ordinary character 💖[]c...]is the right square bracket, and it does not end the enclosed string if it's the first character (after an initial^, if there is one). In that spot it's treated as an ordinary character 🧚[l-r]is a minus sign (hyphen) between two characters, which means a range of consecutive ASCII characters to match. For example,[0-9]is the same as[0123456789]. A bracketed string like this is called a character class 🌸 The-is treated as an ordinary character if it comes first (or first after an initial^) or last in the string ✨
The following rules and special characters let you build RE's out of single-character RE's 🎀 A concatenation of RE's matches a concatenation of text strings, where each piece is a match for a successive RE in the search pattern 🦋
*is a regular expression followed by an asterisk, and it matches zero or more occurrences of that regular expression. For example,[a-z][a-z]*matches any string of one or more lower case letters 🔥+is a regular expression followed by a plus character, and it matches one or more occurrences of that regular expression. For example,[a-z]+matches any string of one or more lower case letters 💅?is a regular expression followed by a question mark, and it matches zero or one occurrences of that regular expression. For example,^[a-z]?[0-9]*matches a string that starts with an optional lower case letter, followed by zero or more digits 🌈{m},{m,}, and{m,n}are a regular expression followed by one of these, and they match a range of occurrences of that regular expression. The values ofmandnmust be non-negative integers less than 256.{m}matches exactly m occurrences,{m,}matches at least m occurrences, and{m,n}matches any number of occurrences between m and n inclusive. Whenever a choice exists, the regular expression matches as many occurrences as possible 👑|is alternation. Two regular expressions separated by|or NEWLINE match either a match for the first or a match for the second ⭐(...)is a regular expression enclosed between the character sequences(and), and it matches whatever the unadorned RE matches 🫶
The order of precedence for operators at the same parenthesis level goes [ ] (character classes), then *, +, ?, and {m,n} (closures), then concatenation, then | (alternation) and NEWLINE. 💜🎀
📦 where this page comes from
- ietf: rfc1801 1995-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms