📄 rfc1801.txt
字号:
Network Working Group S. Kille
Request for Comments: 1801 ISODE Consortium
Category: Experimental June 1995
X.400-MHS use of the X.500 Directory to support X.400-MHS Routing
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. This memo does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
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
Kille Experimental [Page 1]
RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
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 71
List 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
Kille Experimental [Page 2]
RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
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 . . . . . . . . . 61
1. Introduction
MHS Routing is the problem of controlling the path of a message as it
traverses one or more MTAs to reach its destination recipients.
Routing starts with a recipient O/R Address, and parameters
associated with the message to be routed. It is assumed that this is
known a priori, or is derived at submission time as described in
Section 23.
The key problem in routing is to map from an O/R Address onto an MTA
(next hop). This shall be an MTA which in some sense is "nearer" to
the destination UA. This is done repeatedly until the message can be
directly delivered to the recipient UA. There are a number of things
which need to be considered to determine this. These are discussed
in the subsequent sections. A description of the overall routing
process is given in Section 25.
2. Goals
Application level routing for MHS is a complex procedure, with many
requirements. The following goals for the solution are set:
o 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.
o Economic, both in terms of network and computational resources.
Kille Experimental [Page 3]
RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
o Robust. Errors and out of date information shall cause minimal
and localised damage.
o 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.
o Load sharing. Information on routes shall allow "equal" routes
to be specified, and thus facilitate load sharing.
o Support format and protocol conversion
o Dynamic and automatic. There shall be no need for manual
propagation of tables or administrator intervention.
o Policy robust. It shall not allow specification of policies which
cause undesirable routing effects.
o Reasonably straightforward to implement.
o Deal with X.400, RFC 822, and their interaction.
o Extensible to other mail architectures
o Recognise existing RFC 822 routing, and coexist smoothly.
o Improve RFC 822 routing capabilities. This is particularly
important for RFC 822 sites not in the SMTP Internet.
o Deal correctly with different X.400 protocols (P1, P3, P7), and
with 1984, 1988 and 1992 versions.
o Support X.400 operation over multiple protocol stacks (TCP/IP,
CONS, CLNS) and in different communities.
o 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).
o Delay between message submission and delivery shall be minimised.
This has indirect impact on the routing approaches used.
o Interact sensibly with ADMD services.
o Be global in scope
Kille Experimental [Page 4]
RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
o Routing strategy shall deal with a scale of order of magnitude
1,000,000 -- 100,000,000 MTAs.
o Routing strategy shall deal with of order 1,000,000 -- 100,000,000
Organisations.
o Information about alterations in topology shall propagate rapidly
to sites affected by the change.
o 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.
o 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.
o Sufficient tracing and logging shall be available to track down
security violations and faults.
o Optimisation of routing messages with multiple recipients, in
cases where this involves selection of preferred single recipient
routes.
The following are not initial goals:
o 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.
o 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
A broad problem statement, and a survey of earlier approaches to the
problem is given in the COSINE Study on MHS Topology and Routing [8].
The interim (table-based) approach suggested in this study, whilst
not being followed in detail, broadly reflects what the research
X.400 (GO-MHS) community is doing. The evolving specification of the
RARE table format is defined in [5]. This document specifies the
envisaged longer term approach.
Kille Experimental [Page 5]
RFC 1801 X.400-MHS Routing using X.500 Directory June 1995
Some documents have made useful contributions to this work:
o 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].
o Initial ISO Standardisation work on MHS use of Directory for
routing [19]. Subsequent ISO work in this area has drawn from
earlier drafts of this specification.
o The work of the VERDI Project [3].
o Work by Kevin Jordan of CDC [6].
o The routing approach of ACSNet [4, 17] paper. This gives useful
ideas on incremental routing, and replicating routing data.
o A lot of work on network routing is becoming increasingly
relevant. As the MHS routing problem increases in size, and
network routing increases in sophistication (e.g., policy based
routing), the two areas have increasing amounts in common. For
example, see [2].
4. Direct vs Indirect Connection
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -