1INTERNET-DRAFT H. Lachman 2Intended Category: Informational Netscape Communications Corp. 3Filename: draft-lachman-laser-ldap-mail-routing-02.txt G. Shapiro 4 Sendmail, Inc. 5Expires: July 2001 January 2001 6 7 LDAP Schema for Intranet Mail Routing 8 9Status of this Memo 10 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 13 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 18 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 23 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 29 30 This draft is being discussed on the Laser mailing list at 31 <laser@sunroof.eng.sun.com>. Subscription requests can be sent to 32 <laser-request@sunroof.eng.sun.com> (send an email message with the 33 word "subscribe" in the body). More information on the mailing list 34 along with an archive of back messages is available at 35 <http://playground.sun.com/laser/>. 36 37 [[Section X will be removed before the document is submitted to the 38 IESG.]] 39 40Copyright Notice 41 42 Copyright (C) The Internet Society (1999-2001). All Rights Reserved. 43 44Abstract 45 46 This document defines an LDAP [1] object class called 47 'inetLocalMailRecipient' and associated attributes that provide a way 48 to designate an LDAP entry as one that represents a local (intra- 49 organizational) email recipient, to specify the recipient's email 50 address(es), and to provide routing information pertinent to the 51 recipient. This is intended to support SMTP [2] message transfer 52 agents in routing RFC 822-based email [3] within a private enterprise 53 only, and is not to be used in the process of routing email across 54 the public Internet. 55 56Lachman, et. al. [Page 1] 57 58INTERNET-DRAFT LDAP Schema for Intranet Mail Routing January 2001 59 601. Conventions Used in this Document 61 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 64 document are to be interpreted as described in [9]. 65 662. Background and Motivation 67 68 LDAP-based directory services are currently being used in many 69 organizations as a repository of information about users and other 70 network entities (such as groups of users, network resources, etc.). 71 In cases where LDAP entries are used to represent entities that are 72 email recipients (e.g., a mail user or a mailing list), the LDAP 73 entries provide a convenient place to store per-recipient data, such 74 as a recipient's email address. 75 76 In many organizations, an email recipient may have an email address 77 (e.g., "joe@example.com") that does not specify the host that 78 receives mail for that recipient (e.g., "host42.example.com"). A 79 message transfer agent (MTA) responsible for routing mail within the 80 organization needs some way to determine the appropriate target host 81 for such a recipient. A common solution is the sendmail "aliases" 82 database which may contain a record that provides the necessary per- 83 recipient routing information (e.g., "joe: joe@host42"). A drawback 84 of this solution is that if the organization hosts more than one DNS 85 domain (e.g., "example.com" and "example.org", with "joe" in each 86 domain being different recipients), a more explicit mapping is 87 desirable. The schema defined in this document provides a way to 88 represent such mappings in LDAP and X.500 [4] directory services. 89 90 An LDAP entry that represents an email recipient could conceivably 91 contain a variety of attributes related to email, such as disk quota 92 and delivery preferences. We consider here only attributes that 93 specify address information and routing information; these attributes 94 may be useful to multiple MTAs within the organization since one or 95 more MTAs may be responsible for intra-organizational routing. The 96 various MTAs in an organization may have been developed by different 97 implementors, so a common schema is desirable for such attributes. 98 993. Overview 100 101 Email systems deployed in large organizations must scale to support 102 large numbers of users and email servers. This means using email 103 addresses that are independent of particular mailbox server hosts; 104 thus an "email routing server" that receives mail sent to the 105 host-independent (or high-level or top-level or domain ...) address 106 and routes it to the appropriate mailbox server. For scalability 107 there should be many routing servers providing identical service. 108 A set of such servers and the mailbox servers they route to form an 109 "email domain". 110 111Lachman, et. al. [Page 2] 112 113INTERNET-DRAFT LDAP Schema for Intranet Mail Routing January 2001 114 115 This specification describes the basic function of the routing 116 server, including data elements to support per-recipient routing 117 info, and use of LDAP-based directory service to support multiple 118 servers sharing the routing info data. The routing function is 119 distinguished from other MTA-transfer operations. 120 121 The 'inetLocalMailRecipient' object class and associated attributes 122 identify an LDAP entry as representing an SMTP mail recipient (in the 123 sense "recipient" is used in [2]). A recipient may be a mail user, a 124 mailing list, an auto-responder of some kind (e.g., a mailing list 125 subscription program), a network device such as a printer or fax 126 machine, or other recipient type. Address attributes and routing 127 attributes are provided to aid SMTP MTAs in routing mail within an 128 organization to the appropriate target MTA for each recipient. 129 130 Once on the target MTA, a message is handled according to local 131 conventions (which may be specified using other auxiliary object 132 classes and is outside the scope of this document). For example, the 133 message may be delivered to a user mailbox, or to a program or 134 network device, and/or forwarded to another recipient. Or, the 135 target MTA may be a gateway to a non-SMTP mail routing and delivery 136 system including non-SMTP MTAs. Note that, in this discussion, 137 "target MTA" refers to the final SMTP destination of messages for the 138 recipient in question, as we are considering routing of mail only 139 among the SMTP MTAs within an organization. 140 141 Any domain that uses LDAP-based routing MUST support LDAP-based 142 routing at all MTAs responsible for the domain. All other MTAs that 143 do not support LDAP-based routing MUST forward mail for that domain 144 to MTAs that do, using MX records or other local conventions. 145 146 The target MTA checks to see if the destination domain of the 147 recipient address is one that it is responsible for and that uses 148 LDAP-based routing. If so, the MTA checks for matching e-mail 149 addresses in LDAP by looking up the envelope recipient address in 150 LDAP using the object class described in section 4.1 and the 151 attribute discussed in section 4.2. If an unambiguous match is 152 returned, the MTA interprets the routing attributes as described in 153 section 4.3. 154 155 Routing of mail between different organizations across the public 156 Internet is outside the scope of this document, as the mechanism for 157 this is already standardized [5,6]. An 'inetLocalMailRecipient' 158 entry represents a mail recipient that is local to the organization 159 in question, not recipients in other organizations. This means that 160 the domain names that appear within the 'mailLocalAddress' and 161 'mailHost' attribute values in an 'inetLocalMailRecipient' entry must 162 be DNS domain names that are local to the organization. (e.g., 163 within the organization's Intranet or by deemed local by other local 164 conventions outside the scope of this standard). An MTA should not 165 look for or use 'inetLocalMailRecipient' entries or attributes if 166 that MTA is not authoritative for the right-hand side of the 167 recipient address in question. 168 169Lachman, et. al. [Page 3] 170 171INTERNET-DRAFT LDAP Schema for Intranet Mail Routing January 2001 172 173 LDAP entries that are not 'inetLocalMailRecipient' entries should be 174 ignored by MTAs for the purpose of routing. An example is a 175 conference room whose LDAP entry contains contact information (e.g., 176 email address and telephone number) for the person who books 177 reservations for the room; the conference room is not a mail 178 recipient, and can safely be ignored by MTAs doing route 179 determination based on recipient address. 180 1814. Object Class and Attribute Definitions 182 183 The 'inetLocalMailRecipient' object class and associated attributes 184 are defined (using syntaxes given in [7]) as follows. 185 186 4.1 The inetLocalMailRecipient Object Class 187 188 ( 2.16.840.1.113730.3.2.[[TBD]] 189 NAME 'inetLocalMailRecipient' 190 SUP top 191 AUXILIARY 192 MAY ( mailLocalAddress $ 193 mailHost $ mailRoutingAddress 194 ) 195 ) 196 197 The 'inetLocalMailRecipient' object class signifies that the entry 198 represents an entity within the organization that can receive SMTP 199 mail, such as a mail user or a mailing list. In any case of an entry 200 containing the 'inetLocalMailRecipient' object class, attributes 201 defined in this document MUST be interpreted as specified in this 202 document. 203 204 4.2 Address Attribute 205 206 ( 2.16.840.1.113730.3.1.13 207 NAME 'mailLocalAddress' 208 DESC 'RFC 822 email address of this recipient' 209 EQUALITY caseIgnoreIA5Match 210 SYNTAX '1.3.6.1.4.1.1466.115.121.1.26{256}' 211 ) 212 213 The 'mailLocalAddress' attribute is used to specify email addresses, 214 for the recipient; for example, "nickname@example.com". The address 215 conforms to the syntax of an 'addr-spec' as defined in [3]. 216 217 The 'mailLocalAddress' attribute MUST contain all local addresses 218 that represent each recipient of the target MTA. Commonly, the value 219 of the 'mail' attribute should also be among the addresses listed in 220 the 'mailLocalAddress' attribute if it is expected to be used for 221 LDAP mail routing. 222 223Lachman, et. al. [Page 4] 224 225INTERNET-DRAFT LDAP Schema for Intranet Mail Routing January 2001 226 227 When determining the disposition of a given message, MTAs using LDAP 228 (directly or indirectly) to route mail MUST search for an entry with 229 object class 'inetLocalMailRecipient' and a 'mailLocalAddress' 230 attribute matching the message's recipient address. If exactly one 231 matching entry is found, MTAs MUST regard the message as being 232 addressed to the entity that is represented by the directory entry. 233 234 If multiple entries are found, the results of the lookup MUST be 235 treated as unsuccessful and should be handled by the MTA in some 236 locally-appropriate way, such as returning a DSN [10] to the sender. 237 238 If there is no match found by the above, MTAs SHOULD have the 239 capability of searching for the recipient domain against the 240 'mailLocalAddress' attribute using the "wildcard domain" address 241 "@<full-local-domain>" , e.g., "@example.org". In other words, if 242 mail arrives for "someone@example.org", and there is no recipient 243 with that address specified as 'mailLocalAddress', then the recipient 244 with the wildcard domain address should receive the mail. 245 246 MTAs MAY do other searches but only after the above are done. 247 248 In short, the address attribute 'mailLocalAddress' may be used by an 249 LDAP entry to answer the question "what is/are this account's email 250 address(es)?" 251 252 4.3 Routing Attributes 253 254 ( 2.16.840.1.113730.3.1.18 255 NAME 'mailHost' 256 DESC 'fully-qualified hostname of the MTA that is the final 257 SMTP destination of messages to this recipient' 258 EQUALITY caseIgnoreIA5Match 259 SYNTAX '1.3.6.1.4.1.1466.115.121.1.26{256}' 260 SINGLE-VALUE 261 ) 262 263 The 'mailHost' attribute indicates which SMTP MTA considers the 264 recipient's mail to be locally handleable. This information can be 265 used for routing, in that an intermediary MTA may take it to be the 266 destination for messages addressed to this recipient. Normal mail 267 routing requirements (i.e., use of MX records [5]) apply to the 268 specified hostname unless overridden by local conventions. In other 269 words, the mail should be sent to the specified host without changing 270 the recipient address. The hostname is specified as a 271 fully-qualified DNS hostname with no trailing dot (e.g., 272 "host42.example.com"). 273 274 If the 'inetLocalMailRecipient' object class is present, the 275 'mailHost' attribute for each entry MAY contain a value. If it does, 276 that value MUST be the fully qualified name of the server containing 277 the host MTA for this person. If 'mailHost' is present then it MUST 278 be taken as the host for this user, and all mail to this user MUST be 279 routed to this machine. 280 281Lachman, et. al. [Page 5] 282 283INTERNET-DRAFT LDAP Schema for Intranet Mail Routing January 2001 284 285 ( 2.16.840.1.113730.3.1.47 286 NAME 'mailRoutingAddress' 287 DESC 'RFC 822 address to use when routing messages to 288 the SMTP MTA of this recipient' 289 EQUALITY caseIgnoreIA5Match 290 SYNTAX '1.3.6.1.4.1.1466.115.121.1.26{256}' 291 SINGLE-VALUE 292 ) 293 294 The 'mailRoutingAddress' attribute indicates a routing address for 295 the recipient. The address MUST conform to the syntax of an 296 'addr-spec' in [3]. An intermediary MTA MUST use this information to 297 route the message to the MTA that handles mail for this recipient, 298 e.g., the envelope address MUST be rewritten to this value. This is 299 useful in cases where, for a given recipient, the target MTA prefers 300 a particular address to appear as the recipient address in the SMTP 301 envelope. 'mailRoutingAddress' MAY be used as an alternative to 302 'mailHost', and is intended to have the same effect as 'mailHost' 303 except that 'mailRoutingAddress' is an address for rewriting the 304 envelope. With 'mailHost', the envelope address either is not 305 rewritten, or is rewritten according to implementation-specific rules 306 and/or configuration. 307 308 If both 'mailHost' and 'mailRoutingAddress' are present, MTAs MUST 309 interpret it to mean that messages are to be routed to the host 310 indicated by 'mailHost', while rewriting the envelope as per 311 'mailRoutingAddress'. In theory, there could be peculiar cases where 312 this is necessary, but this is not normally expected. 313 314 Absence of both 'mailHost' and 'mailRoutingAddress' MAY be considered 315 an error, unless "location-independent" recipient types are supported 316 by the various MTAs within the organization. This would allow any 317 MTA in the organization to handle the processing of mail for, say, a 318 mailing list. This presumes that the various MTAs all recognize the 319 recipient type in question, suggesting a need to standardize 320 recipient types that could be "location-independent". 321 322 In short, routing attributes may be used by an LDAP entry to answer 323 the question "how should MTAs route mail to this account?" 324 (analogous to using the sendmail "aliases" database for per-user 325 routing within an organization). This is in contrast with 326 "forwarding"; forwarding and delivery options may be specified in an 327 LDAP entry to answer the question "what happens to mail once it 328 arrives at this account?", which may include forwarding to some other 329 account within or outside the organization (analogous to using the 330 sendmail ".forward" file). Such options are outside the scope of the 331 'inetLocalMailRecipient' schema definition. 332 333Lachman, et. al. [Page 6] 334 335INTERNET-DRAFT LDAP Schema for Intranet Mail Routing January 2001 336 337 The following possibilities exist as a result of an LDAP lookup on an 338 address: 339 340 mailHost is mailRoutingAddress is Results in 341 ----------- --------------------- ---------- 342 set to a set mail routed to 343 "local" host mailRoutingAddress 344 345 set to a not set delivered to 346 "local" host original address 347 348 set to a set relay to mailHost 349 remote host using mailRoutingAddress 350 351 set to a not set original address 352 remote host relayed to mailHost 353 354 not set set mail routed to 355 mailRoutingAddress 356 357 not set not set error or 358 "location-independent" 359 360 The term "local" host above means the host specified is one that the 361 local (target) MTA considers to be a local delivery. The local MTA 362 MAY rewrite the original address when mailRoutingAddress is not set 363 if local conventions warrant the change. 364 3655. Examples 366 367 The following examples illustrate possible uses of the 368 'inetLocalMailRecipient' object class. Note that the examples 369 include attributes defined outside of this document to demonstrate a 370 complete record. The existence of these attributes in the example is 371 not an indication that these attributes are used for LDAP-based mail 372 routing (e.g., the 'mail' is not used for mail routing). 373 374 Here is an example of an LDAP entry representing a mail user: 375 376 dn: uid=joe,o=Example Corp,c=US 377 objectClass: top 378 objectClass: person 379 objectClass: organizationalPerson 380 objectClass: inetOrgPerson 381 objectClass: inetLocalMailRecipient 382 objectClass: nsMessagingServerUser 383 cn: Joe User 384 sn: User 385 uid: joe 386 userPassword: {crypt}y2KxtbzMYnApU 387 mail: joe@example.com 388 389Lachman, et. al. [Page 7] 390 391INTERNET-DRAFT LDAP Schema for Intranet Mail Routing January 2001 392 393 mailLocalAddress: joe@example.com 394 mailLocalAddress: joe@another.example.com 395 mailHost: nsmail1.example.com 396 mailDeliveryOption: mailbox 397 mailQuota: 1000000 398 mailForwardingAddress: mary@example.com 399 400 Joe User is a user of a hypothetical mail system called NS Messaging. 401 Let's say mail arrives on an MTA called "mx.example.com", addressed 402 to "joe@example.com". That MTA searches the directory for a mail 403 recipient with that address, using an LDAP search filter [8] such as: 404 405 (&(objectClass=inetLocalMailRecipient) 406 (mailLocalAddress=joe@example.com)) 407 408 It finds Joe's LDAP entry, and routes the message to the target MTA 409 "nsmail1.example.com", while not rewriting the SMTP envelope 410 recipient address. Then, "nsmail1.example.com" receives the message, 411 searches for and finds the recipient in the directory, ascertains 412 that it is the recipient's target MTA, and handles the message as per 413 other attributes in the recipient's entry and/or the MTA 414 configuration (in this case, the message is delivered to a mailbox, 415 and forwarded to another recipient). 416 417 Note that this document does not specify the rules an MTA is to use 418 to ascertain whether or not it is the target MTA for a given 419 recipient (it could check the recipient's 'mailHost' value against 420 its own hostname, or check the recipient's 'mailRoutingAddress', or 421 check the MTA configuration, or some combination of these). 422 423 Here is another example of an LDAP entry representing a mail user: 424 425 dn: uid=john,o=Example Corp,c=US 426 objectClass: top 427 objectClass: person 428 objectClass: organizationalPerson 429 objectClass: inetOrgPerson 430 objectClass: inetLocalMailRecipient 431 objectClass: xyzMailUser 432 cn: John Doe 433 sn: Doe 434 uid: john 435 userPassword: {crypt}y2KxtbzMYnApU 436 mail: john@example.com 437 mailLocalAddress: john@example.com 438 mailRoutingAddress: John_Doe@xyz-gw.example.com 439 xyzPostOfficeName: PO_1 440 xyzClusterNumber: 3 441 xyzMessageStoreId: 9 442 443Lachman, et. al. [Page 8] 444 445INTERNET-DRAFT LDAP Schema for Intranet Mail Routing January 2001 446 447 John Doe is a user of a hypothetical mail system called XYZ Mail. 448 Let's say mail arrives on an MTA called "mx.example.com", addressed 449 to "john@example.com". That MTA searches the directory for a mail 450 recipient with that address, and routes the message to "xyz- 451 gw.example.com", rewriting the SMTP envelope recipient address to 452 "John_Doe@xyz-gw.example.com", as per the 'mailRoutingAddress'. On 453 "xyz-gw.example.com", the message is gatewayed into the XYZ Mail 454 system and then dealt with as per other attributes. 455 456 Here is an example of an LDAP entry representing a mailing list: 457 458 dn: cn=Scuba Group,o=Example Corp,c=US 459 objectClass: top 460 objectClass: groupOfUniqueNames 461 objectClass: inetLocalMailRecipient 462 objectClass: mailGroup 463 cn: Scuba Group 464 mail: scuba@example.com 465 mailLocalAddress: scuba@example.com 466 mailHost: host42.example.com 467 mgrpRFC822MailMember: joe@example.com 468 mgrpRFC822MailMember: john@example.com 469 470 The Scuba Group is a mail group (mailing list) that includes two 471 members. A message addressed to "scuba@example.com" is routed to 472 "host42.example.com" where it is then resent to the mailing list 473 members. 474 475 Here is an example of an LDAP entry representing a forwarding alias: 476 477 dn: cn=Jane Roe Forwarding Alias,o=Example,c=US 478 objectClass: top 479 objectClass: inetLocalMailRecipient 480 objectClass: mailForwardingAlias 481 mail: janeroe@example.org 482 mailLocalAddress: janeroe@example.org 483 mailHost: mail.example.org 484 mailForwardingAddress: janeroe@elsewhere.example.com 485 cn: Jane Roe Forwarding Alias 486 487 This entry uses a hypothetical object class 'mailForwardingAlias' 488 that is not specified here, but is used as an example of how an LDAP 489 entry might represent such a recipient type. A message addressed to 490 "janeroe@example.org" is routed to "mail.example.org" where it is 491 then forwarded. In this case, Jane Roe may be a former member of the 492 Example Organization, and they are forwarding her mail to her new 493 address elsewhere. 494 495Lachman, et. al. [Page 9] 496 497INTERNET-DRAFT LDAP Schema for Intranet Mail Routing January 2001 498 4996. Security Considerations 500 501 As in all cases where account information is stored in an LDAP-based 502 directory service, network administrators must be careful to ensure 503 that their directory service controls users' access to the entries 504 and attributes stored therein, according to site policy. In 505 particular, mail routing information should not be accessible from 506 outside the organization, since it is intended for use only by MTAs 507 within the organization. 508 5097. Acknowledgments 510 511 The 'inetLocalMailRecipient' object class is based on an earlier 512 design done by the Netscape Messaging and Directory Server teams, 513 which was implemented and deployed to customers as part of Netscape 514 Messaging Server. Various team members contributed to the design, 515 including Bill Fitler, Bruce Steinback, Prabhat Keni, Mike Macgirvin, 516 John Myers, John Kristian, Tim Howes, Mark Smith, and Leif Hedstrom. 517 Thanks also to Jeff Hodges of Stanford for contributing to the early 518 design discussions, and to the other participants in the IETF LASER 519 BOF, including, from Sun Microsystems, John Beck, Anil Srivastava, 520 and Darryl Huff. 521 5228. References 523 524 [1] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access 525 Protocol (v3)", RFC 2251, December 1997. 526 527 [2] J. Postel, "Simple Mail Transfer Protocol", STD 10, RFC 821, 528 August 1982. 529 530 [3] D. Crocker, "Standard for the Format of ARPA Internet Text 531 Messages", STD 11, RFC 822, August 1982. 532 533 [4] "Information Processing Systems - Open Systems Interconnection - 534 The Directory: Overview of Concepts, Models and Service", ISO/IEC JTC 535 1/SC21, International Standard 9594-1, 1988. 536 537 [5] C. Partridge, "Mail routing and the domain system", STD 14, RFC 538 974, January 1986. 539 540 [6] R. Braden, "Requirements for Internet hosts - application and 541 support", STD 3, RFC 1123, October 1989. 542 543 [7] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight X.500 544 Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 545 2252, December 1997. 546 547 [8] T. Howes, "The String Representation of LDAP Search Filters", 548 RFC 2254, December 1997. 549 550Lachman, et. al. [Page 10] 551 552INTERNET-DRAFT LDAP Schema for Intranet Mail Routing January 2001 553 554 [9] S. Bradner, "Key words for use in RFCs to Indicate Requirement 555 Levels", BCP 14, RFC 2119, March 1997. 556 557 [10] K. Moore, "SMTP Service Extension for Delivery Status 558 Notifications", RCP 1891, January 1996. 559 5609. Authors' Addresses 561 562 Hans Lachman 563 Netscape Communications Corp. 564 501 East Middlefield Road 565 Mountain View, CA 94043 566 Phone: (650) 254-1900 567 EMail: lachman@netscape.com 568 569 Gregory Neil Shapiro 570 Sendmail, Inc. 571 6603 Shellmound Street 572 Emeryville, CA 94608-1042 573 Phone: +1 510-594-5522 574 Fax: +1 510-594-5411 575 EMail: gshapiro@sendmail.org 576 577X. Change Summary 578 579X.1.1 Substantive changes between 580 draft-lachman-laser-ldap-mail-routing-00.txt and 581 draft-lachman-laser-ldap-mail-routing-01.txt 582 583 (i) Added Gregory Neil Shapiro as another author. 584 (ii) Changed Draft heaer. 585 (iii) Added "Conventions Used in this Document" section. 586 (iv) Replaced RFC mentions with reference numbers. 587 (v) Add new MUST/SHOULD/MAY sections to bring more in line with 588 RFC documents. 589 (vi) Clarify job of MTA in Overview by adding third paragraph. 590 (vii) mailRoutingAddress can be outside of administrative control. 591 (viii) Eliminated use of 'mail' attribute for mail routing. 592 (ix) Changed name of 'mailAlternateAddress' to 'mailLocalAddress'. 593 (x) Remove "routable" from 'mailLocalAddress' description. 594 (xi) Clarify which addresses MUST be in 'mailLocalAddress'. 595 (xii) Allow for multiple responses if they all have the same 596 routing attribute values. 597 (xiii) Clarify use of MX records on routing attributes. 598 (xiv) Add a table to clarify use of 'mailHost' and 599 'mailRoutingAddress'. 600 (xv) Remove document weakening statements from section 5. 601 (xvi) Only use reserved domains (example.com, example.org) in 602 examples. 603 (xvii) Clean up references 604 (xviii) Added section X to list the changes between draft versions. 605 606Lachman, et. al. [Page 11] 607 608INTERNET-DRAFT LDAP Schema for Intranet Mail Routing January 2001 609 610X.1.2 Substantive changes between 611 draft-lachman-laser-ldap-mail-routing-01.txt and 612 draft-lachman-laser-ldap-mail-routing-02.txt 613 614 (i) Changed Intended Category from Standard Track to Informational. 615 (ii) Removed references to mailGroup document which has expired. 616 (iii) Add additional Overview text from RL 'Bob' Morgan. 617 (iv) If a domain uses LDAP-based routing, require all MTAs in that 618 domain to either use LDAP for routing or forward mail to an 619 MTA which uses LDAP for routing. 620 (v) Add more text regarding "local" domain. 621 (vi) Tighten rules for better interoperability. Multiple, 622 matching results is now treated as an unsuccessful lookup. 623 (vii) Tighten rules for better interoperability. Change the action 624 for a lookup which returns both a 'mailHost' and 625 'mailRoutingAddress' to a MUST (from a MAY). 626 (viii) Point out that examples contain attributes which are not part of 627 this spec and should not be used for mail routing 628 (specifically, 'mail'). 629 (ix) Clean up text. 630 (x) NOTE: Still need vendor-neutral OIDs for the objectClass and 631 attributes. 632 63310. Full Copyright Statement 634 635 Copyright (C) The Internet Society (1999-2001). All Rights Reserved. 636 637 This document and translations of it may be copied and furnished 638 to others, and derivative works that comment on or otherwise 639 explain it or assist in its implementation may be prepared, copied, 640 published and distributed, in whole or in part, without 641 restriction of any kind, provided that the above copyright notice 642 and this paragraph are included on all such copies and derivative 643 works. However, this document itself may not be modified in any 644 way, such as by removing the copyright notice or references to the 645 Internet Society or other Internet organizations, except as needed 646 for the purpose of developing Internet standards in which case the 647 procedures for copyrights defined in the Internet Standards 648 process must be followed, or as required to translate it into 649 languages other than English. 650 651 The limited permissions granted above are perpetual and will not 652 be revoked by the Internet Society or its successors or assigns. 653 654 This document and the information contained herein is provided on 655 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 656 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 657 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 658 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 659 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 660 661Lachman, et. al. [Page 12] 662