idnits 2.17.1 draft-lachman-ldap-mail-routing-03.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. 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. ** The abstract seems to contain references ([2], [3], [4], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 224: '... MAY ( cn $ mail $ mailAlter...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (October 1998) is 9325 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1777 (ref. '1') (Obsoleted by RFC 3494) ** Obsolete normative reference: RFC 821 (ref. '3') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 822 (ref. '4') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2252 (ref. '6') (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) ** Obsolete normative reference: RFC 2256 (ref. '7') (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4519, RFC 4523) ** Obsolete normative reference: RFC 1274 (ref. '8') (Obsoleted by RFC 4524) ** Obsolete normative reference: RFC 974 (ref. '9') (Obsoleted by RFC 2821) Summary: 18 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Lachman 3 INTERNET-DRAFT Netscape Communications Corp. 4 Intended Category: Informational October 1998 5 Expires: April 1999 6 Filename: draft-lachman-ldap-mail-routing-03.txt 8 LDAP Schema Definitions for Intranet Mail Routing - 9 The mailRecipient Object Class 11 Status of this Memo 13 This memo provides information for the Internet community. This memo 14 does not specify an Internet standard of any kind. Distribution of 15 this memo is unlimited. 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check the 28 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 29 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 30 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 31 ftp.isi.edu (US West Coast). 33 Copyright Notice 35 Copyright (C) The Internet Society (1998). All Rights Reserved. 37 Abstract 39 Directory services based on the Lightweight Directory Access Protocol 40 (LDAP) [1] and X.500 [2] provide a general-purpose means to store 41 information about users and other network entities. One of the many 42 possible uses of a directory service is to store information about 43 users' email accounts, such as their email addresses, and how 44 messages addressed to them should be routed. In the interest of 45 interoperability, it is desirable to have a common schema for such 46 email-related information. 48 This document defines an object class called 'mailRecipient' to 49 support SMTP [3] message transfer agents (MTAs) in routing RFC 822- 50 based email messages [4] within an organization. The intent is to 51 suggest a model for MTA interoperability via the directory, to 52 provide information about a solution that has been implemented and 53 deployed, and to stimulate discussion about whether and how to 54 standardize the functionality in question. 56 1. Background and Motivation 58 LDAP-based directory services are currently being used in many 59 organizations as a repository of information about users and other 60 network entities (such as groups of users, network resources, etc.). 61 Some information is stored in the directory for the consumption of 62 persons browsing for information (e.g., telephone numbers, postal 63 addresses, secretary's name). Other information (e.g., login name, 64 password, disk quota) is stored for use by one or more network 65 applications or services. This latter use of the directory suggests 66 the opportunity to centralize the storage and management of user 67 account information related to different services. In general, it is 68 advantageous for different network applications and services to refer 69 to the directory for user account information, rather than each 70 service keeping its own collection of user account records, which 71 requires the network administrator to separately create or destroy 72 user entities, passwords, etc., in many different systems each time a 73 user joins or leaves the organization. The goals of centralized user 74 management and sharing of information with other service types drove 75 our decision in the design of Netscape Messaging Server (an SMTP- 76 based mail server product) to use LDAP-based directory services as a 77 common repository for user account information. 79 Thus, in our implementation, all account information for a given mail 80 server user is stored in the directory entry that represents that 81 user. This includes the user's delivery options, access 82 restrictions, mailbox quota, and vacation status, among other things. 83 Now, if a given mail server can refer to the directory for its own 84 users' account information, it follows that that same information can 85 be made visible to other LDAP-aware mail servers in the same 86 organization, and therefore that information can aid those other mail 87 servers in correctly routing messages to users of the mail server in 88 question. This assumes that there is an agreed-upon set of per-user 89 attributes to support message routing among the mail servers in the 90 organization. If this assumption is met in our implementation, we 91 can obviate other means currently employed to specify per-user 92 message routing (such as the sendmail "aliases" database). The 93 benefit of this is to further consolidate per-user system 94 information. 96 If different vendors provide LDAP-aware mail server products, each 97 having its own schema for message routing, then the above benefits 98 can be achieved for single-vendor customers, but customers who have 99 multiple vendors' mail server products would not be well served. 100 They will likely expect interoperability, which will require a common 101 schema to be supported by the various vendors' products. Thus, it is 102 worthwhile to consider how to develop a common schema. 104 This document defines a schema designed to provide a means by which a 105 directory entry that represents a mail recipient can provide 106 information enabling MTAs to route messages to the recipient's "home" 107 MTA. This document considers only intra-enterprise SMTP message 108 routing using LDAP-based directory services. Solutions and issues 109 involving inter-enterprise routing, non-SMTP message handling, non- 110 LDAP directory services, and other messaging management topics not 111 related to message routing, are outside the scope of this document 112 (except that the concepts presented may also be applicable in the 113 case of any X.500-based directory service). 115 2. Overview of the Approach Implemented 117 In our design of Netscape Messaging Server, we identified all pieces 118 of per-user account information, and assigned attributes such that 119 the information for a given user can be held in the user's "LDAP 120 entry" (the directory entry representing the user in an LDAP-based 121 directory service). We segregated the attributes into two subsets: 122 those that are of interest only to the "target MTA" (i.e., the MTA 123 that considers the recipient to be local), and those that are of 124 interest to "intermediary MTAs" (i.e., MTAs that are not the target 125 MTA). Each subset of attributes is aggregated into an object class, 126 the former being 'nsMessagingServerUser' (see Appendix), and the 127 latter, 'mailRecipient'. It is the latter object class that is the 128 focus of this document. 130 The 'mailRecipient' object class provides attributes that may be used 131 to specify addressing and routing information pertaining to a given 132 recipient. This information may be used by an intermediary MTA to 133 route a message to the recipient's designated target MTA, i.e., to 134 the MTA that "takes responsibility" for messages to the recipient in 135 question. The target MTA then accepts the message and, regarding the 136 recipient as local, handles the message as specified by attributes 137 intended for use by the target MTA (such as those associated with the 138 'nsMessagingServerUser' object class). 140 Consider a network with three hosts that run MTAs: 142 +------+ 143 local | | 144 handling | MDA2 | 145 layer | | 146 +------+ 147 ^ 148 | 149 +------+ +------+ +------+ 150 | | | | | | 151 routing | MTA1 | -----> | MTA2 | -----> | MTA3 | 152 layer | | | | | | 153 +------+ +------+ +------+ 155 host1 host2 host3 157 The above illustrates a two-layer mail routing and delivery model. 158 The attributes provided by the 'mailRecipient' object class are used 159 by the lower layer (the routing layer) to support the routing of a 160 message to the correct target MTA. Other attributes may be used by 161 the upper layer, which roughly equates to what is commonly called an 162 MDA (message delivery agent), although the local handling may or may 163 not involve delivery of the message to a mailbox (e.g., the message 164 may be resent if the recipient is a mail group or a forwarded 165 account). (In this discussion, "target MTA" means "target Messaging 166 Server" which includes both MTA and MDA functionalities; while the 167 implementation is not necessarily layered internally as implied 168 above, the product nonetheless exhibits the functionality described.) 170 In our implementation, an LDAP entry that represents a mail recipient 171 will have two mail-related object classes, 'mailRecipient', plus an 172 additional one that may be used by the local handling layer to 173 determine the recipient type and how messages for the recipient are 174 to be handled on the target MTA. A mail user account will have 175 'mailRecipient' plus 'nsMessagingServerUser'. A mail group will have 176 'mailRecipient' plus 'mailGroup' [5]. An MTA need only look at 177 attributes associated with 'mailRecipient' to determine whether a 178 recipient is local, and if not, how to route the message. The 179 additional object class and attributes are of interest only if the 180 recipient is local. 182 (Note: While the Messaging Server fully implements this approach, 183 earlier versions of its account creation tool do not place all of the 184 above-mentioned object classes in the entries it creates. The 185 Messaging Server is compatible with both the old and the new object 186 class interpretations.) 187 A Netscape Messaging Server can route messages to recipients on other 188 vendors' MTAs if the users' LDAP entries have the 'mailRecipient' 189 object class and associated attributes. (Other vendors' MTA 190 implementations may or may not follow the above-described model of 191 indicating recipient type and MDA-level account configuration in 192 LDAP, since only 'mailRecipient' and associated attributes are 193 required for MTA-level recognition.) 195 Likewise, other vendors' MTAs can route messages to recipients on a 196 Netscape Messaging Server if they recognize and interpret the 197 'mailRecipient' object class and associated attributes as defined in 198 Sec. 3. 200 The intent of this model is to provide a framework within which any 201 vendor can define new types of mail recipients, without requiring 202 other vendors' implementations to have knowledge of the new recipient 203 types; they need only have a consistent interpretation and 204 application of the 'mailRecipient' object class and associated 205 attributes. 207 In short, the main advantage of the 'mailRecipient' object class is 208 to define a single object class that can serve to identify an LDAP 209 entry as an entity to which email can be addressed, and to aggregate 210 the attributes that can provide multivendor MTA interoperability via 211 the directory. 213 3. Object Class and Attribute Definitions 215 The 'mailRecipient' object class and associated attributes are 216 defined (using syntaxes given in [6]) as follows. 218 3.1 The mailRecipient Object Class 220 ( 2.16.840.1.113730.3.2.3 221 NAME 'mailRecipient' 222 SUP top 223 AUXILIARY 224 MAY ( cn $ mail $ mailAlternateAddress $ 225 mailHost $ mailRoutingAddress 226 ) 227 ) 229 The 'mailRecipient' object class signifies that the entry represents 230 an entity within the organization that can receive SMTP mail, such as 231 a mail user account or a mail group account (mailing list). 233 The 'cn' attribute (common name) is provided as a means for 234 administrators to identify the entry [7]. 236 3.2 Address Attributes 238 ( 0.9.2342.19200300.100.1.3 239 NAME 'mail' 240 DESC 'RFC 822 email address of this recipient' 241 EQUALITY caseIgnoreIA5Match 242 SYNTAX '1.3.6.1.4.1.1466.115.121.1.26{256}' 243 SINGLE-VALUE 244 ) 246 The attribute name 'mail' is a synonym for 'rfc822Mailbox', as 247 defined earlier in [8]. This attribute specifies the recipient's 248 "primary" or "advertised" email address, i.e., that which might 249 appear on a business card; for example, "user@example.com". 251 ( 2.16.840.1.113730.3.1.13 252 NAME 'mailAlternateAddress' 253 DESC 'alternate RFC 822 email address of this recipient' 254 EQUALITY caseIgnoreIA5Match 255 SYNTAX '1.3.6.1.4.1.1466.115.121.1.26{256}' 256 ) 258 The 'mailAlternateAddress' attribute is used to specify alternate 259 email addresses, if any, for the recipient; for example, 260 "nickname@example.com". 262 When determining the disposition of a given message, an MTA may 263 search the directory for an entry with object class 'mailRecipient' 264 and a 'mail' or 'mailAlternateAddress' attribute matching the 265 message's recipient address. If exactly one matching entry is found, 266 the MTA may regard the message as being addressed to the entity that 267 is represented by the directory entry. 269 In short, address attributes may be used by an LDAP entry to answer 270 the question "what is/are this account's email address(es)?" 272 3.3 Routing Attributes 274 ( 2.16.840.1.113730.3.1.18 275 NAME 'mailHost' 276 DESC 'fully qualified hostname of the SMTP MTA that 277 handles messages for this recipient' 278 EQUALITY caseIgnoreIA5Match 279 SYNTAX '1.3.6.1.4.1.1466.115.121.1.26{256}' 280 SINGLE-VALUE 281 ) 283 The 'mailHost' attribute indicates which MTA considers the 284 recipient's mail to be locally handlable. This information can be 285 used for routing, in that an intermediary MTA may take it to be the 286 destination for messages addressed to this recipient. 288 ( 2.16.840.1.113730.3.1.47 289 NAME 'mailRoutingAddress' 290 DESC 'RFC 822 address to use when routing messages to 291 the SMTP MTA of this recipient' 292 EQUALITY caseIgnoreIA5Match 293 SYNTAX '1.3.6.1.4.1.1466.115.121.1.26{256}' 294 SINGLE-VALUE 295 ) 297 The 'mailRoutingAddress' attribute indicates a routing address for 298 the recipient. An intermediary MTA may use this information to route 299 the message to the MTA that handles mail for this recipient. 301 Only one of the above two attributes need be present in order to 302 route messages on behalf of the recipient. The 'mailRoutingAddress' 303 attribute is more explicit in terms of providing an address that can 304 be used to rewrite the SMTP envelope recipient address. With 305 'mailHost', the envelope address either is not rewritten, or is 306 rewritten according to implementation-specific rules and/or 307 configuration. 309 In short, routing attributes may be used by an LDAP entry to answer 310 the question "how should MTAs route mail to this account?" 311 (analogous to using the sendmail "aliases" database for per-user 312 routing within an organization). This is in contrast with 313 "forwarding" (see Appendix); forwarding and delivery options may be 314 used by an LDAP entry to answer the question "what happens to mail 315 once it arrives at this account?", which may include forwarding to 316 some other account within or outside the organization (analogous to 317 using the sendmail ".forward" file). 319 4. MTA Implementation Details 321 This section provides details of the algorithms followed by the 322 Netscape Messaging Server as they relate to the 'mailRecipient' 323 object class and associated attributes. Our implementation includes 324 features that go beyond what is minimally needed to support the 325 schema defined in Section 3, and other MTA implementations need not 326 match our implementation in every detail in order to be interoperable 327 (especially since various features described here can be disabled); 328 but, in general, the features described here are recommended. 330 4.1 Finding the LDAP Entry for a Given Email Address 331 When the MTA receives a message, it attempts to determine whether 332 there is an LDAP entry that represents the recipient. It takes the 333 SMTP envelope recipient address, and performs a search in LDAP, 334 spanning the directory subtree specified in the configuration, for an 335 entry that has the object class 'mailRecipient', and has either a 336 'mail' or 'mailAlternateAddress' attribute matching the recipient 337 address in question. If exactly one match is found, this is taken to 338 be the LDAP entry that represents the recipient. 340 If there were zero matches, but the domain part of the address 341 matches the local MTA's hostname, we perform a fallback search with 342 the same address except that the domain part is truncated to not 343 include the host part (e.g., the search for 344 "user@nsmail1.example.com" is retried as "user@example.com"). This 345 fallback search is optional, as per the server configuration. 347 If there were zero matches so far, but the domain part of the address 348 is considered to be local (by configurable criteria), we perform a 349 fallback search for an LDAP entry that has object class 350 'mailRecipient' and a 'uid' attribute (i.e., login name; synonym for 351 'userid' [8]) equal to the local part of the recipient address. This 352 fallback search is optional, as per the server configuration. 354 If the MTA finds the LDAP entry representing the recipient, it 355 proceeds with the logic discussed in Section 4.2. Otherwise, it will 356 rely on other information resources to determine whether to reject 357 the message or route it elsewhere. 359 Note that LDAP entries without the 'mailRecipient' object class are 360 ignored (except as may be needed for backward compatibility). This 361 is necessary because some sites have LDAP entries that do not 362 represent mail recipients, but have a 'mail' attribute nonetheless. 363 For example, a conference room might have an LDAP entry including an 364 email address, telephone number, etc., that are the same as for the 365 secretary who books reservations for the room. In this example, the 366 conference room's email address is for contact information only, and 367 is not intended to imply that it has an email account. Therefore, 368 the MTA correctly ignores the conference room's LDAP entry, and 369 avoids producing multiple matches on the search. 371 4.2 Deciding Whether a Message can be Handled Locally 373 If the MTA has found the LDAP entry representing the recipient, as 374 per Section 4.1, it checks the LDAP entry's 'mailHost' value to see 375 if it matches the MTA's local hostname. If so, it handles the 376 message locally. (Note that since accounts hosted on a Netscape MTA 377 are expected to have a 'mailHost' value, they typically do not have a 378 'mailRoutingAddress' value; other implementations could make 379 different design choices, and still be compatible.) 381 Otherwise, it routes the message as specified by the 'mailHost' value 382 and/or the 'mailRoutingAddress' value. See Section 4.3 for further 383 details. 385 If the recipient's LDAP entry contains no routing information (i.e., 386 no 'mailHost' nor 'mailRoutingAddress'), the MTA will bounce (reject) 387 the message. There are two exceptions to this rule, to accommodate 388 location-independent accounts, as follows. 390 If the entry has no routing information, but is a mailing list (i.e., 391 has object class 'mailGroup'), the message is handled locally, i.e., 392 the MTA "receives" messages to the address in question, performs the 393 mail group expansion, and resends to the group members. Thus, a mail 394 group can be configured as "location-independent", meaning that it 395 does not require a particular Messaging Server to perform the mail 396 group expansion. 398 If the entry has no routing information, but has one or more 399 'mailForwardingAddress' attributes (see Appendix), it is handled 400 locally, i.e., the MTA "receives" messages to the address in question 401 under the assumption that it is a forwarding-only (or "redirect") 402 account, and forwards the message to the new address(es). Thus, it 403 is not necessary to designate a particular Messaging Server to 404 perform forwarding on behalf of a forwarding-only account. (This 405 exception may be deprecated in a future version, and then all 406 'nsMessagingServerUser' accounts will require a 'mailHost' value. If 407 location-independent redirects are still desired, a 'mailGroup' entry 408 can be used to achieve the same effect. Or, one could imagine a new 409 object class to combine with 'mailRecipient', say, 410 'mailForwardingAlias', that just provides a way to configure a 411 location-independent recipient that has a 'mailForwardingAddress', 412 but this may be overkill. One might also consider whether the 413 desired action is actually "routing", not "forwarding" - see Sec. 3.3 414 for clarification. The point is that a mail server should never 415 perform "forwarding" unless it also takes responsibility for the 416 account's other attributes that specify delivery-time handling, if 417 any; this is to ensure that all of the account's forwarding and 418 delivery preferences are acted upon exactly once in the life of a 419 message.) 421 Note that if there were a non-Netscape MTA in the environment that 422 implemented the 'mailRecipient' concept but did not mimic the 423 Netscape MTA behavior regarding the above exception cases, it would 424 probably be unadvisable for administrators to configure any accounts 425 as location-independent. (This suggests that if it is generally 426 useful to configure a certain recipient type as location-independent, 427 e.g., 'mailGroup', it ought to be standardized.) 429 4.3 Determining how to Route a Message 431 If the recipient is not local, but has a 'mailHost' and/or 432 'mailRoutingAddress' attribute in its LDAP entry, we route the 433 message as follows. 435 First, we determine a destination. If a 'mailHost' value is present, 436 that is taken to be the destination. Otherwise, the domain part of 437 the 'mailRoutingAddress' value is taken to be the destination. 439 Second, we determine whether and how to rewrite the SMTP envelope 440 recipient address. If a 'mailRoutingAddress' value is present, the 441 envelope address is rewritten to that. Otherwise, depending on the 442 configuration, the envelope address may be rewritten by combining the 443 'uid' value, if present, with the 'mailHost' value (e.g., 444 "uid@mail.host"), or, it is rewritten by combining the original 445 envelope address local part with the 'mailHost' value (e.g., 446 "orig.localpart@mail.host"), or it is not rewritten at all. 448 Third, we determine the next SMTP hop. This may or may not be the 449 same as the destination determined above. Given the destination, the 450 MTA will consult the routing table in the MTA configuration, and/or 451 consult DNS for "MX" and/or "A" records [9]. 453 The message is then relayed to the next SMTP hop, with the SMTP 454 envelope recipient address set as determined above. 456 Note that if both 'mailHost' and 'mailRoutingAddress' are present, 457 the 'mailHost' attribute determines the destination while the 458 'mailRoutingAddress' attribute determines the envelope rewrite. It 459 is expected that specifying both is unnecessary, although not 460 inherently harmful, and may be useful in some peculiar cases. 462 Note also that envelope rewrites may be considered unnecessary (e.g., 463 in Netscape-only MTA sites), and perhaps undesirable (e.g., if the 464 user has multiple addresses and the target MTA allows the user to 465 configure server-side filters that read the envelope; also, envelope 466 rewrites may increase the chances of "namespace crossovers" in 467 multi-domain sites, as mentioned in Sec. 5.8). Envelope rewrites 468 become necessary when routing to MTAs whose reckoning of their 469 accounts' email addresses is not consistent with the accounts' 470 respective LDAP entries (which could be the case with MTAs that are 471 not 'mailRecipient'-compatible). 473 5. Examples 474 The following is a set of directory entries, shown in LDIF [10] 475 format, that illustrates the use of the 'mailRecipient' object class. 476 Examples based on this set of entries are provided in the sections 477 that follow. Each example explains what happens when a message 478 arrives on nsmail1.example.com for the indicated recipient. 480 dn: cn=Joe Blow,o=Example Corp,c=US 481 objectclass: top 482 objectclass: person 483 objectclass: organizationalPerson 484 objectclass: inetOrgPerson 485 objectclass: mailRecipient 486 objectclass: nsMessagingServerUser 487 cn: Joe Blow 488 sn: Blow 489 uid: joeblow 490 userpassword: {crypt}y9LyrzNBT49Ao 491 mail: joeblow@example.com 492 mailhost: nsmail1.example.com 493 maildeliveryoption: mailbox 495 dn: cn=John Doe,o=Example Corp,c=US 496 objectclass: top 497 objectclass: person 498 objectclass: organizationalPerson 499 objectclass: inetOrgPerson 500 objectclass: mailRecipient 501 objectclass: nsMessagingServerUser 502 cn: John Doe 503 sn: Doe 504 uid: johndoe 505 userpassword: {crypt}y9LyrzNBT49Ao 506 mail: johndoe@example.com 507 mailalternateaddress: jonjon@example.com 508 mailhost: nsmail2.example.com 509 maildeliveryoption: mailbox 511 dn: cn=Scuba Group,o=Example Corp,c=US 512 objectclass: top 513 objectclass: groupOfUniqueNames 514 objectclass: mailRecipient 515 objectclass: mailGroup 516 cn: Scuba Group 517 mail: scuba@example.com 518 mgrprfc822mailmember: joeblow@example.com 519 mgrprfc822mailmember: johndoe@example.com 521 dn: cn=Tuba Group,o=Example Corp,c=US 522 objectclass: top 523 objectclass: groupOfUniqueNames 524 objectclass: mailRecipient 525 objectclass: mailGroup 526 cn: Tuba Group 527 mail: tuba@example.com 528 mailhost: nsmail2.example.com 529 mgrprfc822mailmember: joeblow@example.com 530 mgrprfc822mailmember: janeroe@example.com 532 dn: cn=Jane Roe,o=Example Corp,c=US 533 objectclass: top 534 objectclass: person 535 objectclass: organizationalPerson 536 objectclass: inetOrgPerson 537 objectclass: mailRecipient 538 objectclass: nsMessagingServerUser 539 cn: Jane Roe 540 sn: Doe 541 uid: janeroe 542 userpassword: {crypt}y9LyrzNBT49Ao 543 mail: janeroe@example.com 544 mailhost: nsmail1.example.com 545 maildeliveryoption: mailbox 546 mailforwardingaddress: babs@example.com 548 dn: cn=J Random User,o=Example Corp,c=US 549 objectclass: top 550 objectclass: mailRecipient 551 objectclass: nsMessagingServerUser 552 cn: J Random User 553 sn: User 554 mail: jruser@example.com 555 mailforwardingaddress: random@pu.edu 557 dn: cn=Babs Jensen,o=Example Corp,c=US 558 objectclass: top 559 objectclass: person 560 objectclass: organizationalPerson 561 objectclass: inetOrgPerson 562 objectclass: mailRecipient 563 objectclass: xyzMailUser 564 cn: Babs Jensen 565 sn: Jensen 566 uid: babs 567 userpassword: {crypt}y9LyrzNBT49Ao 568 mail: babs@example.com 569 mailalternateaddress: bj@schooldist12.k12.ca.us 570 mailroutingaddress: Babs_Jensen@xyz1.example.com 571 xyzPostOfficeName: Example_PO_1 572 xyzUserType: regular 573 xyzQuota: 1000000 575 dn: cn=Charlie Hacker,o=Example Corp,c=US 576 objectclass: top 577 objectclass: person 578 objectclass: organizationalPerson 579 objectclass: inetOrgPerson 580 objectclass: mailRecipient 581 objectclass: nsMessagingServerUser 582 cn: Charlie Hacker 583 sn: Hacker 584 uid: hacker 585 userpassword: {crypt}y9LyrzNBT49Ao 586 mail: hacker@schooldist12.k12.ca.us 587 mailhost: nsmail2.example.com 588 mailroutingaddress: hacker@schooldist12.k12.ca.us 589 maildeliveryoption: mailbox 590 mailforwardingaddress: babs@example.com 592 dn: cn=Conference Room 102,o=Example Corp,c=US 593 objectclass: top 594 objectclass: conferenceRoom 595 mail: babs@example.com 596 roomNumber: 102 598 5.1 Example #1 600 When a message arrives on nsmail1.example.com for 601 joeblow@example.com, the message is deposited in Joe Blow's mailbox. 603 5.2 Example #2 605 When a message arrives on nsmail1.example.com for johndoe@example.com 606 or for jonjon@example.com, the message is relayed to 607 nsmail2.example.com, with "johndoe@nsmail2.example.com" in the 608 envelope (assuming the "uid@mail.host" rewrite option is enabled on 609 nsmail1.example.com). On nsmail2.example.com, the message is 610 identified as belonging to John Doe by virtue of 611 "nsmail2.example.com" being local and "johndoe" being the 'uid' of 612 John Doe (assuming the 'uid' fallback search is enabled on 613 nsmail2.example.com). So the message is deposited in his mailbox on 614 nsmail2.example.com. 616 The above case would also succeed if the "truncate host part" 617 fallback search were enabled on nsmail2.example.com, or if no 618 fallback searches or envelope rewrites were configured on either 619 machine (in which case the envelope recipient address would remain 620 unchanged). 622 5.3 Example #3 624 When a message arrives on nsmail1.example.com for scuba@example.com, 625 the message is resent to joeblow@example.com and johndoe@example.com. 626 (The message is considered to be locally handlable since the 627 recipient is a mail group with no routing information.) 629 5.4 Example #4 631 When a message arrives on nsmail1.example.com for tuba@example.com, 632 the message is relayed to nsmail2.example.com with 633 "tuba@nsmail2.example.com" (assuming that the 634 "orig.localpart@mail.host" option is enabled). On 635 nsmail2.example.com, the message is identified as belonging to the 636 Tuba Group by virtue of the "truncate host part" fallback search, so 637 the message is accepted and resent to the group members. 639 As in Example #2, the above case would also succeed if no fallback 640 searches or envelope rewrites were configured on either machine. 642 5.5 Example #5 644 When a message arrives on nsmail1.example.com for 645 janeroe@example.com, the message is delivered to Jane's mailbox, and 646 is also forwarded to Babs. Perhaps Jane is on leave. 648 5.6 Example #6 650 When a message arrives on nsmail1.example.com for jruser@example.com, 651 it is forwarded to random@pu.edu. Perhaps he has left the company to 652 go back to school, and the company is forwarding his mail as a favor. 654 Note that the presence or absence of the usual object classes such as 655 'person' do not affect the Messaging Server. Also, the absence of 656 'uid' and 'userPassword' is probably a good idea since a person who 657 has left the company should not be able to login. Note also that a 658 'mailHost' could have been specified, e.g., as "nsmail2.example.com", 659 with no difference in overall effect, except that it would require 660 all messages addressed to this user to be passed to 661 nsmail2.example.com where the forward action would then be performed. 663 (This is an example of a location-independent "redirect" account, 664 which may be deprecated in a future release; see Sec. 4.2.) 666 5.7 Example #7 668 When a message arrives on nsmail1.example.com for babs@example.com, 669 or for bj@schooldist12.k12.ca.us (the company is doing a favor to a 670 local school district by hosting their mail accounts on the company 671 servers; Babs is both an employee in the company and a volunteer at 672 the school district, and so she has both addresses), the message is 673 relayed to the SMTP MTA on host xyz1.example.com (which may be an 674 SMTP-to-XYZ gateway), with "Babs_Jensen@xyz1.example.com" in the 675 envelope. 677 Note that Conference Room 102 is not identified by the MTA as a 678 recipient of mail addressed to babs@example.com, despite it's having 679 the matching 'mail' address. This is because it does not have the 680 'mailRecipient' object class. 682 5.8 Example #8 684 When a message arrives on nsmail1.example.com for 685 hacker@schooldist12.k12.ca.us, the message is relayed to 686 nsmail2.example.com with "hacker@schooldist12.k12.ca.us" in the 687 envelope. Mail arriving on nsmail2.example.com for this user is 688 deposited into his mailbox, and a copy is forwarded to Babs. Charlie 689 is a guest user from a local school district, and is not in the 690 company, and therefore does not have an address with "example.com". 692 The reason to force the envelope using 'mailRoutingAddress' is to 693 avoid having it rewritten to "hacker@nsmail2.example.com", which 694 would happen if envelope rewrites using 'mailHost' are enabled. 695 Thus, we avoid a "namespace crossover" that could result in 696 misdelivered mail if there were some other user with address 697 "hacker@example.com". This is one of the peculiar cases where having 698 both 'mailHost' and 'mailRoutingAddress' is useful, since 699 'mailRoutingAddress' overrides the default rewrite rule (although the 700 problem could also be solved by disabling envelope rewrites, assuming 701 they are not needed). Any site that hosts multiple domains (e.g., an 702 Internet service provider) must be especially careful in considering 703 whether and how envelopes are to be rewritten when mail is routed 704 among its MTAs. (See also Sec. 4.3.) 706 6. Security Considerations 708 As in all cases where account information is stored in an LDAP-based 709 directory service, network administrators must be careful to ensure 710 that their directory service controls users' access to the entries 711 and attributes stored therein, according to site policy (e.g., 712 allowing users to modify, say, their 'mailForwardingAddress' 713 attribute, but not their 'mailHost' attribute). Mail server products 714 and their associated user management tools should help administrators 715 to ensure this, and should also help administrators avoid 716 configurations that would result in misdelivered mail due to 717 "namespace crossovers" and other reasons. 719 7. Acknowledgements 721 Many members of the Netscape Messaging Server and Directory Server 722 teams contributed to the design of this schema, including Bill 723 Fitler, Prabhat Keni, Mike Macgirvin, Bruce Steinback, John Myers, 724 Tim Howes, Mark Smith, and John Kristian (who coined the object class 725 name 'mailRecipient'). Special thanks to Leif Hedstrom, Netscape's 726 Chief Dogfood Taster, for his "real world" insights. Thanks also to 727 Jeff Hodges for contributing to the discussion that led to this memo, 728 and to Stuart Freedman for providing review comments. 730 8. References 732 [1] W. Yeong, T. Howes, S. Kille, "Lightweight Directory Access 733 Protocol", RFC 1777, March 1995. 735 [2] "Information Processing Systems - Open Systems Interconnection - 736 The Directory: Overview of Concepts, Models and Service", ISO/IEC JTC 737 1/SC21, International Standard 9594-1, 1988. 739 [3] J. Postel, "Simple Mail Transfer Protocol", STD 10, RFC 821, 740 August 1982. 742 [4] D. Crocker, "Standard for the Format of ARPA Internet Text 743 Messages", STD 11, RFC 822, August 1982. 745 [5] B. Steinback, "Using LDAP for SMTP Mailing Lists and Aliases", 746 Internet-Draft (work in progress). 748 [6] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight X.500 749 Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 750 2252, December 1997. 752 [7] M. Wahl, "A Summary of the X.500(96) User Schema for use with 753 LDAPv3", RFC 2256, December 1997. 755 [8] P. Barker, S. Kille, "The COSINE and Internet X.500 Schema", RFC 756 1274, November 1991. 758 [9] C. Partridge, "Mail routing and the domain system", STD 14, RFC 759 974, January 1986. 761 [10] G. Good, "The LDAP Data Interchange Format (LDIF) - Technical 762 Specification", Internet-Draft (work in progress). 764 [11] M. Smith, "The inetOrgPerson Object Class", Internet-Draft 765 (work in progress). 767 9. Author's Address 769 Hans Lachman 770 Netscape Communications Corp. 771 501 East Middlefield Road 772 Mountain View, CA 94043 774 Phone: (650) 254-1900 775 EMail: lachman@netscape.com 777 10. Appendix - nsMessagingServerUser Object Class and Attributes 779 The following is an informal description of the 780 'nsMessagingServerUser' object class and associated attributes. It 781 was designed to be used in combination with the 'mailRecipient' and 782 'inetOrgPerson' [11] object classes to define a Netscape Messaging 783 Server user account. This definition is not considered part of the 784 'mailRecipient' definition, and is provided here purely as 785 supplemental information. These attributes may change across 786 releases, and such changes would not affect MTA interoperability. 788 Object class: nsMessagingServerUser 789 Allowed attributes: 790 cn 791 Common name (person's full name). 792 mailAccessDomain 793 Domains and IP addresses from which user may do POP 794 or IMAP login. 795 mailAutoReplyMode 796 Auto-reply mode, may be one (or none) of: 'vacation' 797 (send reply text to sender, but only once per 798 vacation), 'reply' (send reply text unconditionally), 799 or 'echo' (like 'reply' but include original message 800 in the reply). 801 mailAutoReplyText 802 Reply text to use with 'mailAutoReplyMode'. 803 mailDeliveryOption 804 Mail delivery option, one or more of: 'mailbox' 805 (deliver to user's POP/IMAP mailbox), 'native' 806 (deliver with platform's native delivery method, 807 e.g., "/usr/bin/mail"), or 'program' (perform program 808 delivery). There must be at least one 809 'mailDeliveryOption' and/or 'mailForwardingAddress', 810 otherwise, mail to this account is undeliverable. 811 mailForwardingAddress 812 User-specifiable mail forwarding address(es). This 813 is different from 'mailRoutingAddress' in that it is 814 intended to be configurable by the user, and may be 815 multi-valued. Thus, forwarding and delivery options 816 may be thought of as "account preferences", while 817 routing attributes are used to get a message to the 818 MTA that will take responsibility for handling the 819 message as per the recipient's account preferences. 820 mailMessageStore 821 Identifier for the message store containing this 822 user's POP/IMAP mailbox. 823 mailProgramDeliveryInfo 824 Command text for program delivery. 825 mailQuota 826 Quota in bytes for user's POP/IMAP mailbox. 828 11. Full Copyright Statement 830 Copyright (C) The Internet Society (1998). All Rights Reserved. 832 This document and translations of it may be copied and furnished to 833 others, and derivative works that comment on or otherwise explain it 834 or assist in its implementation may be prepared, copied, published 835 and distributed, in whole or in part, without restriction of any 836 kind, provided that the above copyright notice and this paragraph are 837 included on all such copies and derivative works. However, this 838 document itself may not be modified in any way, such as by removing 839 the copyright notice or references to the Internet Society or other 840 Internet organizations, except as needed for the purpose of 841 developing Internet standards in which case the procedures for 842 copyrights defined in the Internet Standards process must be 843 followed, or as required to translate it into languages other than 844 English. 846 The limited permissions granted above are perpetual and will not be 847 revoked by the Internet Society or its successors or assigns. 849 This document and the information contained herein is provided on an 850 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 851 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 852 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 853 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 854 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.