Network Working S.E. Hardcastle-Kille Group ISODE Consortium INTERNET-DRAFT July 1992 Expires: January 1993 Use of the Directory to support routing for RFC 822 and related protocols Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Abstract This document defines a mechanism to route RFC 822 using the OSI Directory. The basic mechanisms are being developed for routing X.400 [HK92]. These offer a number of benefits relative to the current mechanisms available for RFC 822 routing. The prime goal of this specification is to provide integrated routing management for sites using both RFC 822 and X.400 [Cro82, MHS88]. This draft document will be submitted to the RFC editor as a protocol standard. Distribution of this memo is unlimited. Please send comments to the author or to the discussion group . INTERNET--DRAFT RFC 822 routing using X.500 July 1992 The domain hierarchy of an RFC 822 mailbox information are represented in the directory according to RFC 1279 [HK91]. This will allow domains and mailboxes to be verified. This information is used primarily for address checking and for mapping onto specific RFC 822 protocols. Protocol modules should utilise native RFC 822 directory and routing services (e.g., SMTP should use DNS) [Pos82, Moc87a, Moc87b]. Authoritative answers can be given for parts of the DNS tree where registration is complete (i.e., all of the children are present, and so any other purported child will be illegal). This is achieved by the authoritativeAddress attribute defined in Figure 1. Once validity is determined, routing must be done. This information is not relevant to a site without RFC 822 support, as it will not be doing domain based routing. Some additional information needed for RFC 822 routing (binding) is given in Figure 1. The attribute x400Domain indicates that some or all of the subtree under the domain specified uses X.400. If the value is ``x400-only'', the domain exists purely to represent X.400 addresses in the RFC 822 world, and X.400 routing should be used if possible. If the value is ``x400-and-822'', then protocol choice should reflect local policy (e.g., to prefer X.400 or to avoid protocol conversion). By default, PP will route to avoid protocol conversion. For sites with SMTP on the Internet, any valid domain may be routed through SMTP. DNS Information is also available in the tree, to facilitate route calculation (RFC 1279 and RFC 974 [Par86]). For sites with JNT Mail support, the jNTMailSupport attribute indicates that the domain supports JNT Mail, and gives sufficient information to make a routing decision. This mechanism is included to show how the directory can handle RFC 822 mail routing beyond SMTP. Local addresses are handled in the same way as for X.400, as described in [HK92]. The approach is designed to be convenient for either environment. Where a site supports both, the appropriate bits of the O/R Address and Domain namespaces should be linked by aliases. The object pointed to should be of object class domain-component and or-address component. The location of the master should be chosen according to the volume of inbound traffic for each protocol. Note: May need to define an attribute to point, as aliasing may not be possible in all cases. Expires: January 1993 Page 1 INTERNET--DRAFT RFC 822 routing using X.500 July 1992 _______________________________________________________________________ 822Node OBJECT-CLASS SUBCLASS OF domain MAY CONTAIN { authoritativeAddress, x400Domain, badAddressSearchPoint, badAddressSearchAttributes} ::= oc-822-node x400Domain ATTRIBUTE 10 WITH ATTRIBUTE-SYNTAX X400DomainType ::= at-x400-domain X400DomainType ::= ENUMERATED { x400-only(1), x400-and-822(2) } jNTMailNode OBJECT-CLASS SUBCLASS OF 822Node 20 MAY CONTAIN { jntMailSupport } ::= oc-jnt-mail-node jNTMailSupport ATTRIBUTE WITH ATTRIBUTE-SYNTAX JNTMailSupport ::= at-jnt-mail-support JNTMailSupport ::= SEQUENCE { supported-nets BITSTRING { 30 janet(1), pss(2), ipss(3), ixi(4) } application-relay DistinguishedName } _________________Figure_1:__RFC_822_Node_Information___________________ Expires: January 1993 Page 2 INTERNET--DRAFT RFC 822 routing using X.500 July 1992 An MTA identifies a local address by finding its own name as one of the MTAs that supports the UA in question. This is the same as for O/R Address checking. One problem with bootstrapping this approach is that there is a need to load the DNS namespace information into the DIT. This can only be done gradually. Fortunately, there is no requirement for all of the domain name information to be in the DIT. The minimum needed is: o Users local to the MTA, and the tree leading down to that o All of the top level domains o Information needed to verify or deny partially qualified domains. PP will allow use of DNS as an alternative checking mechanism at this point. The disadvantages of doing this are: o No mailbox (UA) checking o No support for multiple RFC 822 protocols Multiple Domain Routing Trees can be established analogously to O/R Address routing trees. This is important for: o Sites with RFC 822 support, but not JNT Mail or SMTP. o Sites which gateway RFC 822 to other protocols (e.g., UUCP). References [Cro82] D.H. Crocker. Standard of the format of ARPA internet text messages. Request for Comments 822, University of Delaware, August 1982. [HK91] S.E. Hardcastle-Kille. X.500 and domains. Request for Comments RFC 1279, Department of Computer Science, University College London, November 1991. [HK92] S.E. Hardcastle-Kille. MHS use of the directory to support MHS routing, April 1992. Internet Draft. Expires: January 1993 Page 3 INTERNET--DRAFT RFC 822 routing using X.500 July 1992 [MHS88] CCITT recommendations X.400 / ISO 10021, April 1988. CCITT SG 5/VII / ISO/IEC JTC1, Message Handling: System and Service Overview. [Moc87a] P. Mockapetris. Domain names - concepts and facilities. Request for Comments RFC 1034, USC/Information Sciences Institute, November 1987. [Moc87b] P. Mockapetris. Domain names - implementation and specification. Request for Comments RFC 1035, USC/Information Sciences Institute, November 1987. [Par86] C. Partridge. Mail routing and the domain system. Request for Comments 974, DDN Network Information Center, SRI International, February 1986. [Pos82] J.B. Postel. Simple Mail Transfer Protocol. Request for Comments 821, DDN Network Information Center, SRI International, August 1982. 1 Security Considerations Security considerations are not discussed in this INTERNET--DRAFT . 2 Author's Address Steve Hardcastle-Kille ISODE Consortium PO Box 505 London SW11 1DX England Phone: +44-71-223-4062 EMail: S.Kille@ISODE.COM DN: CN=Steve Hardcastle-Kille, O=ISODE Consortium, C=GB Expires: January 1993 Page 4 INTERNET--DRAFT RFC 822 routing using X.500 July 1992 UFN: S. Hardcastle-Kille, ISODE Consortium, GB Expires: January 1993 Page 5 INTERNET--DRAFT RFC 822 routing using X.500 July 1992 A Object Identifier Assignment _______________________________________________________________________ rfc-822 OBJECT IDENTIFIER ::= {mhs-ds 6} oc OBJECT IDENTIFIER ::= {rfc-822 1} at OBJECT IDENTIFIER ::= {rfc-822 2} oc-822-node OBJECT IDENTIFIER ::= {oc 1} oc-jnt-mail-node OBJECT IDENTIFIER ::= {oc 2} 10 at-x400-domain OBJECT IDENTIFIER ::= {at 1} at-jnt-mail-support OBJECT IDENTIFIER ::= {at 2} _______________Figure_2:__Object_Identifier_Assignment_________________ Expires: January 1993 Page 6