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