idnits 2.17.1 draft-ietf-asid-email-routing-ns-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. 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], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 188 has weird spacing: '...Address add...' -- 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 (March 1997) is 9903 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 974 (ref. '6') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 1959 (ref. '9') (Obsoleted by RFC 2255) Summary: 14 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 Expires: 30 September 1997 March 1997 5 Intended Category: Informational 7 LDAP-based Routing of SMTP Messages: 8 Approach Used by Netscape 9 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Abstract 31 Directory services based on the Lightweight Directory Access Protocol 32 (LDAP) [1] and X.500 [2] provide a general-purpose means to store 33 information about users and other network entities. One of the many 34 possible uses of a directory service is to store information about 35 users' email accounts, such as their email addresses, and how 36 messages addressed to them should be routed. In the interest of 37 interoperability, it is desirable to have a common schema for such 38 email-related information. 40 This document discusses some of the fundamental questions to be 41 considered in the development of a common schema for LDAP-based 42 routing of SMTP [3] messages, presents an approach that has been 43 implemented and deployed, and discusses possible extensions to that 44 approach that may serve to make it more complete and general. The 45 intent is to provide information about an existing implementation, 46 and to stimulate discussion about whether and how to standardize the 47 relevant aspects of LDAP-based messaging management. 49 1. Background and Motivation 51 LDAP-based directory services are currently being used in many 52 organizations as a repository of information about users and other 53 "network entities" (such as groups of users, network resources, 54 etc.). Some information is stored in the directory for the 55 consumption of persons browsing for information (e.g., telephone 56 numbers, postal addresses, secretary's name), while other information 57 (e.g., login name, password, disk quota) is stored for use by one or 58 more network applications or services. It is the latter kind of 59 information that is of interest in this discussion. In general, it 60 is advantageous for different network applications and services to 61 refer to the directory for user account information, rather than each 62 service keeping its own collection of user account records, which 63 requires the network administrator to separately create or destroy 64 user entities, passwords, etc., in many different systems each time a 65 user joins or leaves the organization. The goals of centralized user 66 management and sharing of information with other service types drove 67 our decision in the design of Netscape Messaging Server (an SMTP- 68 based mail server product) to use LDAP-based directory services as a 69 common repository for user account information. 71 Now, if a given mail server can refer to the directory for its own 72 users' account information, it follows that that same information is 73 visible to other LDAP-aware mail servers in the same organization, 74 and therefore that information can aid those other mail servers in 75 correctly routing messages to users of the mail server in question. 76 This assumes that there is an agreed-upon set of per-user attributes 77 to support message routing. If this assumption is met, we can 78 obviate other means currently employed to specify per-user message 79 routing (such as the Unix "aliases" database). The benefit of this 80 is to further consolidate per-user system information. 82 If each vendor's mail server product has its own schema for LDAP- 83 based message routing, then the above benefits can be achieved for 84 single-vendor customers, but customers who have multiple vendors' 85 mail server products would not be well served. They will likely 86 expect interoperability, which will require a common schema to be 87 supported by the various vendors' products. Thus, it is worthwhile 88 to consider how to develop a common schema. 90 This document does not attempt to define a standard. It does attempt 91 to define what the relevant questions are, and goes on to describe 92 one vendor's solution plus possible extentions to generalize it. It 93 is hoped that this discussion helps to characterize the issue, and 94 encourages the development of a common solution. 96 This document considers only intra-enterprise SMTP message routing 97 using LDAP-based directory services. Solutions and issues involving 98 inter-enterprise routing, non-SMTP message handling, non-LDAP 99 directory services, and other messaging management topics not related 100 to message routing, are outside the scope of this document (except 101 that the concepts presented may also be applicable in the case of 102 X.500 directory services). 104 2. Terminology 106 In the context of this document, a "mail server" is a Simple Mail 107 Transfer Protocol (SMTP) message transfer agent (MTA). It either 108 includes, or has associated with it, a local message delivery agent 109 (MDA) that performs delivery to accounts that are considered local to 110 the particular mail server. A mail server may offer related services 111 as well, such as providing a means for mail user agents (MUAs) to 112 pick up messages, but that is outside the scope of this discussion. 114 The term "account" is used to refer to any entity that can receive 115 mail. This includes mail user accounts, as well as mail group 116 accounts (mail distribution lists). A "delivery" is said to have 117 occured when an MTA passes a message to the local MDA, having first 118 ascertained that the message is destined for a particular account 119 that can be delivered to locally. The MDA may then place the message 120 in a local message store, and/or take other actions as specified by 121 the account's attributes. 123 "Routing" and "forwarding" are distinct actions. "Routing" is said 124 to have occured when an MTA passes a message to a "next-hop" MTA, 125 having ascertained that the addressed entity is not a local account 126 but may exist elsewhere. "Forwarding" is said to have occured when a 127 message has successfully arrived at a particular account and the MDA 128 determines that the message must be resent to one or more new 129 destinations as specified by the account's attributes. "Forwarding" 130 may be configurable by the user, while "routing" is normally 131 configurable only by a network administrator. With this definition, 132 it might also be said that when a message arrives at a mail group 133 account, and the MDA resends the message to all of the individual 134 group members, this is also "forwarding". 136 3. Questions to Consider 138 When a message arrives at an MTA, the MTA must determine whether to 139 deliver the message to a local account, route the message to another 140 MTA, or, in the case of an unresolvable recipient address, take some 141 remedial action such as "bouncing" the message. In the course of 142 making this determination, an MTA may reference information from a 143 variety of sources, including its own local configuration, one or 144 more directory services, and perhaps other sources. This document 145 discusses only per-account routing and addressing information 146 provided by an LDAP-based directory service, and what role that 147 information might play in helping the MTA determine what to do with a 148 message. 150 The question of how an MTA might use such information can be broken 151 down into three subquestions: 153 Question (1): For a given recipient address, which LDAP entry does 154 it belong to? 156 Question (2): For a given LDAP entry, should a message addressed to 157 it be delivered locally or routed? 159 Question (3): If a message addressed to a given LDAP entry needs to 160 be routed, to where should the message be routed? 162 In order for these questions to be answerable by the MTA, LDAP 163 entries that represent mail accounts should include attributes that 164 specify addressing and routing information. These attributes should 165 be advertised to (i.e., readable by) the MTAs that are expected to 166 act on them, and there should be a definition of what attributes are 167 involved and how they are to be interpreted. With this definition, 168 an MTA can be implemented or configured to correctly use such 169 information to answer the above questions, and therefore, correctly 170 handle messages addressed to accounts represented as LDAP entries. 172 4. Description of Solution Implemented 174 In the design of Netscape Messaging Server, we defined two new LDAP 175 object classes, 'mailRecipient', which is used to represent a mail 176 user account, and 'mailGroup', which is used to represent a mail 177 group account (mail distribution list). An LDAP entry of either 178 class may have attributes that are of an "account configuration" 179 nature and are used solely by the MDA handling mail for the account, 180 while other attributes are used by the account's "home" MTA as well 181 as other MTAs. It is this latter set of attributes that are of 182 interest in this discussion, since we are concerned with the behavior 183 of MTAs. 185 Our MTA implementation uses the following attributes: 187 mail primary email address 188 mailAlternateAddress additional email addresses 189 mailHost server hosting mail account 190 uid user id (login name) 192 The 'mail' and 'mailAlternateAddress' attributes are used to specify 193 the email addresses [4] that are considered valid for an account. 194 They must all be complete email addresses (e.g., "joe@example.com", 195 as opposed to "joe" or "joe@mars"). 'mailHost' is the fully- 196 qualified domain name [5] of the mail server that considers the 197 account to be locally deliverable (e.g., "mars.eng.example.com"). 198 'uid' is the user's login name. A 'mailGroup' is not expected to 199 have a 'uid' attribute, and may or may not have a 'mailHost' 200 attribute, but both attributes should be present for a 201 'mailRecipient'. For a detailed description of the 'mailRecipient' 202 and 'mailGroup' object classes and associated attributes, refer to 203 Appendices A and B. 205 Our MTA implementation looks for the above attributes, and uses them 206 to answer the three fundamental questions considered above, as 207 follows. 209 4.1. Mapping an Address to an LDAP Entry 211 To resolve Question (1), we take the recipient address from the SMTP 212 "envelope", and see if there is exactly one LDAP entry that 213 advertises that address as one of its valid addresses. Specifically, 214 we search for an LDAP entry that has a 'mail' or 215 'mailAlternateAddress' attribute whose value is the address in 216 question. The search is performed across all LDAP entries in a given 217 directory subtree, which is configured in the MTA as its "base 218 subtree" of interest. 220 If the above search fails, we may also perform a fallback search. 221 Specifically, if the above search yields zero matches, we split the 222 address in question at the "@" sign, yielding a "local part" and a 223 "domain part". If the MTA configuration specifies that it is the 224 final authority on messages addressed to the domain part in question 225 (i.e., it has the authority to bounce messages addressed to that 226 domain), then we search for an LDAP entry whose 'uid' attribute 227 equals the local part. If we get exactly one match, then we regard 228 this as a successful match. 230 In theory, the fallback search may not be required, but since our MTA 231 rewrites envelopes to 'uid'@'mailHost' (as discussed in Section 4.3), 232 it is clearly advantageous for receiving MTAs in this environment to 233 be able to unconditionally recognize an address thusly rewritten. 235 4.2. Determining Whether or not to Perform Local Delivery 237 To resolve Question (2), we look up the LDAP entry's 'mailHost' 238 attribute. If the value of this attribute matches the fully- 239 qualified domain name (FQDN) specified in the MTA configuration, then 240 the message is passed to the local MDA. 242 If the value of the 'mailHost' attribute does not match the MTA's 243 FQDN, then the message is routed. 245 If the LDAP entry has no 'mailHost' attribute, this is considered 246 invalid for a 'mailRecipient', but for a 'mailGroup', the MTA will 247 pass the message to the local MDA to perform group list expansion and 248 forwarding to the individual recipients. In other words, for a 249 'mailGroup', a missing 'mailHost' means any mail server may perform 250 group handling for the message. 252 4.3. Determining How to Route the Message 254 To resolve Question (3), we look up the LDAP entry's 'mailHost' and 255 'uid' attributes. The 'uid' attribute is normally present for a 256 'mailRecipeint', and is not normally present for a 'mailGroup'. If 257 the 'uid' attribute is present, we rewrite the recipient address in 258 the SMTP envelope to 'uid'@'mailHost', i.e., we combine the 259 respective values of these two attributes and add an "@" sign to 260 formulate a new recipient address. If the 'uid' attribute is not 261 present, we do not rewrite the recipient address. 263 The message is routed to the destination indicated in the 'mailHost' 264 attribute. This may or may not mean that the MTA will open an SMTP 265 connection to the host identified as the 'mailHost', since the MTA 266 configuration may specify routing rules that prevent this (e.g., in 267 sites that are configured so that all message traffic follows a fixed 268 "star" topology). Also, some sites may use DNS MX records [6] for 269 internal message routing. For example, an MTA "mail.example.com" may 270 receive a message for "joe@example.com", find that the 'mailHost' for 271 this account is "mars.eng.example.com", and then discover that mail 272 for "*.eng.example.com" is MX'ed to "hub.eng.example.com", which will 273 then be the "next hop". 275 5. Possible Ways to Generalize the Solution Implemented 277 The following are serveral ways our approach could be extended to 278 make it more general. None of these suggestions are reflected in our 279 existing implementation as of this writing. We have no specific 280 plans to follow or not follow these suggestions in any subsequent 281 implementation. The intent is to provide ideas as to what a more 282 general approach might look like. Whether or not these ideas should 283 be implemented, or should become the basis for a future standard, are 284 left as open questions. 286 5.1. More Flexible Envelope Rewrites 288 One might argue that it is not really necessary for MTAs to rewrite 289 envelopes when performing intra-enterprise message routing. The 290 argument is as follows. Taking an example from above, suppose Joe's 291 account is on "mars.eng.example.com", and Joe's account advertises 292 "joe@example.com" as one of its valid email addresses. One would 293 expect that Joe's "home" MTA knows what Joe's valid email addresses 294 are. When mail arrives on "mail.example.com" for "joe@example.com", 295 and it finds Joe's LDAP entry that advertises this address, it should 296 be able to route the message without rewriting the envelope under the 297 assumption that Joe's "home" MTA (and other MTAs such as 298 "hub.eng.example.com" that are "closer" to Joe's "home" MTA than 299 "mail.example.com") can also correctly identify the address as 300 belonging to Joe. 302 However, existing practice in sites that use SMTP-based messaging 303 often includes the rewriting of addresses to be host-specific. In 304 order to avoid going against existing practice, our MTA 305 implementation rewrites envelopes to 'uid'@'mailHost', as explained 306 above. This is a fixed behavior, and some sites may desire more 307 flexibility. 309 One way to provide more flexibility is to add an attribute, say: 311 mailRoutingAddress address for internal mail routing 313 This could be added to the 'mailRecipient' and 'mailGroup' object 314 classes as a way to explicitly specify how to rewrite the envelope 315 when routing a message. Then, if the 'mailRoutingAddress' is 316 present, the envelope is rewritten to the indicated address, 317 otherwise, the address is not rewritten. This provides flexibility 318 for site-specific policy governing whether or not envelopes are 319 rewritten, and if so, how they are to be rewritten. It obviates the 320 fixed 'uid'@'mailHost' behavior in our implementation (see Section 321 4.3), because the same information can then be stored in the 322 'mailRoutingAddress' attribute. 324 It should be noted that if the 'mailRoutingAddress' attribute were 325 used as described here, that attribute would need to be added to the 326 search specified in Section 4.1. That is, an MTA receiving a message 327 should search the directory for any entry whose 'mail', 328 'mailAlternateAddress', or 'mailRoutingAddress' is the address in 329 question, since any of those addresses could appear in the envelope. 331 Also, the 'uid'@'mailHost' search could be removed from the method 332 specified in Section 4.1, but some sites may still regard this as a 333 desirable fallback, although in this case the reasons to keep it are 334 more along the lines of the reasoning in Section 5.2. 336 One might observe that 'mailRoutingAddress' and 'mailHost' may be 337 partially redundant, and, in general, it is desirable to avoid 338 redundancy of information in the directory. Having both attributes 339 would be useful, however, if for some reason a network administrator 340 wanted to separately control "next-hop" determination and envelope 341 rewrites. So if both attributes were present, 'mailHost' would 342 determine where to route the message, and 'mailRoutingAddress' would 343 determine how to rewrite the envelope. If only 'mailRoutingAddress' 344 were present, then the right-hand side (the domain part) of the 345 routing address would determine the next destination. If only 346 'mailHost' were present, then the envelope would not be rewritten. 348 5.2. Localpart-only Searches 350 Our implementation performs searches on email addresses as complete 351 addresses (e.g., "joe@example.com"). We do not split the address at 352 the "@" sign and search on the "local part", except in the case 353 characterized above as a "fallback" search. This approach is 354 probably sufficient for most customers since they can always add more 355 addresses to an account as needed. It also reduces the risk of 356 "namespace crossovers" that could result if customers with multiple 357 distinct domains (e.g., with "joe" being a different person in each 358 domain) did localpart-only searches. 360 Nevertheless, some sites may desire the flexibility to configure 361 their MTAs to perform "localpart-only" searches, once the MTA has 362 ascertained that the domain part is considered to be "local". They 363 may then want the search to attempt matches against arbitrary 364 attributes, like 'uid', 'cn' (with spaces and other illegal 365 characters matching underscores or dots in the address), or some 366 attribute whose purpose is to contain localpart-only email addresses. 367 Site-specific needs can vary considerably in this area, and the most 368 appropriate solution may be to make this part of an MTA's 369 functionality as configurable as possible. 371 5.3. Mail Address Mappings 373 Some sites have a need to perform what might be called a "transit 374 service" whereby email sent to a given address is resent to another 375 address (say, for a person who wants their former Internet service 376 provider to resend their mail to their new account elsewhere). This 377 is often called an "alias", but, in a strict sense, "alias" means "an 378 alternate name for something" (which is the purpose of 379 'mailAlternateAddress'), so this might more properly be called a 380 "mail address mapping". 382 This effect can be accomplished with our existing implementation in 383 several ways. One way is to maintain a 'mailRecipient' entry that 384 includes a forwarding address ('mailForwardingAddress' attribute). 385 Another way is to maintain a "group of one" entry, i.e., a 386 'mailGroup' with only one member. 388 However, some network administrators may not wish to represent such 389 "transit" users in their directory service as being actual users or 390 groups. Therefore, it may be desirable to define a new object class 391 for this purpose, e.g.: 393 Object class: mailAddressMapping 394 Required attribute: 395 objectClass 396 Allowed attributes: 397 cn 398 mail 399 mailAlternateAddress 400 mailTransitAddress 402 The MTA would treat mail addressed to such an entry the same as it 403 would for a non-local user who has a 'mailRoutingAddress' specified 404 and no 'mailHost'; i.e., a message addressed to a 405 'mailAddressMapping' entry (as per its 'mail' or 406 'mailAlternateAddress' attributes) is resent to the address specified 407 as its 'mailTransitAddress'. The reason not to use 408 'mailRoutingAddress' for this purpose is that the transit address 409 must not participate in the Question (1) search (since doing so would 410 cause the search to yield duplicate matches in the case where the 411 targeted recipient is within the same organization). 413 5.4. More Configurability 415 In lieu of a standard, mail server vendors could also achieve 416 interoperability by providing a high degree of configurability in 417 their products. For example, each mail server product could provide 418 a means to configure or program its methods of resolving each of 419 Questions (1), (2), and (3); if all of the mail servers in a given 420 site were configured to use the same methods, then they would, in 421 theory, interoperate in terms of LDAP-based SMTP message routing as 422 described in this document. However, this approach to 423 interoperability simply shifts the burden of standardization to the 424 customer, and then there might still be a demand for a "recommended 425 configuration profile" (i.e., a standard) for customers who desire 426 solutions that work "right out of the box". 428 On the other hand, some level of configurability with regard to the 429 functionality discussed here may be desirable. 431 6. Security Considerations 433 As in all cases where account information is stored in an LDAP-based 434 directory service, network administrators must be careful to ensure 435 that their directory service controls users' access to the entries 436 and attributes stored therein, according to site policy (e.g., 437 allowing users to modify, say, their 'mailForwardingAddress' 438 attribute, but not their 'mailHost' attribute). Mail server products 439 and their associated user management tools should help administrators 440 to ensure this, and should also help administrators avoid 441 configurations that would result in misdelivered mail due to 442 "namespace crossovers" and other reasons. 444 7. References 446 [1] W. Yeong, T. Howes, S. Kille, "Lightweight Directory Access 447 Protocol", RFC 1777, March 1995. 449 [2] "Information Processing Systems - Open Systems Interconnection - 450 The Directory: Overview of Concepts, Models and Service", ISO/IEC JTC 451 1/SC21, International Standard 9594-1, 1988. 453 [3] J. Postel, "Simple Mail Transfer Protocol", RFC 821, August 454 1982. 456 [4] D. Crocker, "Standard for the Format of ARPA Internet Text 457 Messages", RFC 822, August 1982. 459 [5] P. Mockapetris, "Domain names - concepts and facilities", RFC 460 1034, November 1987. 462 [6] C. Partridge, "Mail routing and the domain system", RFC 974, 463 January 1986. 465 [7] M. Smith, "Definition of the inetOrgPerson Object Class", 466 Internet-Draft (work in progress), November 1996. 468 [8] "Information Processing Systems - Open Systems Interconnection - 469 The Directory: Selected Object Classes", Recommendation X.521, 470 ISO/IEC JTC 1/SC21, International Standard 9594-7, 1993. 472 [9] T. Howes, M. Smith, "An LDAP URL Format", RFC 1959, June 1996. 474 8. Author's Address 476 Hans Lachman 477 Netscape Communications Corp. 478 501 East Middlefield Road 479 Mountain View, CA 94043 480 USA 481 Phone: (415) 254-1900 482 EMail: lachman@netscape.com 484 Appendix A. mailRecipient Object Class and Attributes 486 The following is an informal description of the 'mailRecipient' 487 object class and associated attributes. It was designed to be used 488 as a "mix-in" object in combination with a person's LDAP entry (in 489 our implementation, an 'inetOrgPerson' entry [7]) to enable a person 490 to be recognized and handled as a mail user. 492 Object class: mailRecipient 493 Required attribute: 494 objectClass 495 Allowed attributes: 496 cn 497 Common name (person's full name). 498 mail 499 "Primary" email address. This is the address that 500 would likely be displayed by "white-pages" lookup 501 applications. Must be a complete email address 502 (e.g., "joe@example.com"). 503 mailAccessDomain 504 Domains and IP addresses from which user may do POP 505 or IMAP login. 506 mailAlternateAddress 507 Email addresses that are considered valid for this 508 user in addition to their 'mail' address. Must be 509 complete email addresses. 510 mailAutoReplyMode 511 Auto-reply mode, may be one of: 'vacation' (send 512 reply text to sender, but only once per vacation), 513 'reply' (send reply text unconditionally), or 'echo' 514 (like 'reply' but include original message in the 515 reply). 516 mailAutoReplyText 517 Reply text to use with 'mailAutoReplyMode'. 518 mailDeliveryOption 519 Mail delivery option, one or more of: 'mailbox' 520 (deliver to user's POP/IMAP mailbox), 'native' 521 (deliver with platform's native delivery method, 522 e.g., "/usr/bin/mail"), or 'program' (perform program 523 delivery). There must be at least one 524 'mailDeliveryOption' and/or 'mailForwardingAddress', 525 otherwise, mail to this account is undeliverable. 526 mailForwardingAddress 527 User-specifiable mail forwarding address(es). 528 mailHost 529 Fully-qualified domain name of the MTA that is the 530 final SMTP destination for mail addressed to this 531 account. Used for routing (see Section 4.3), and 532 also used to determine which LDAP entries represent 533 accounts that are to be considered local to a given 534 mail server (see Section 4.2). 535 mailMessageStore 536 Identifier for the message store containing this 537 user's POP/IMAP mailbox. Contains absolute path of 538 the message store directory (may be some other 539 identifier in the future). 540 mailProgramDeliveryInfo 541 Command text for program delivery. 542 mailQuota 543 Quota in bytes for user's POP/IMAP mailbox. 544 multiLineDescription 545 User-specifiable personal description. 546 uid 547 User's login name. 548 userPassword 549 User's password. 551 Appendix B. mailGroup Object Class and Attributes 553 The following is an informal description of the 'mailGroup' object 554 class and associated attributes. It was designed to be used as a 555 "mix-in" object in combination with an LDAP group entry (in 556 particular, a 'groupOfUniqueNames' entry [8]) to enable a group to be 557 recognized and handled as a mail group. 559 Object class: mailGroup 560 Required attributes: 561 objectClass 562 mail 563 "Primary" email address (as above). 564 Allowed attributes: 565 cn 566 Common name (name of the group). 567 mailAlternateAddress 568 Additional email addresses (as above). 569 mailHost 570 FQDN of the MTA (as above). For a group, if no 571 'mailHost' is specified, this implies that any mail 572 server may perform group handling for messages 573 addressed to this group (i.e., perform group list 574 expansion, and forward the message to the individual 575 recipients). 576 mgrpAllowedBroadcaster 577 RFC 1959-style [9] specification of users who may 578 send mail to the group (if such restriction is 579 desired). 580 mgrpAllowedDomain 581 Domains from which users may send mail to the group 582 (if such restriction is desired). 583 mgrpDeliverTo 584 RFC 1959-style filter expression specifying a search 585 criteria to identify users who should receive copies 586 of all messages to the group (in addition to the 587 formal group members, i.e., those who are specified 588 as members of the 'groupOfUniqueNames' with a 589 'uniqueMember' attribute), e.g., to include all 590 persons in the "Sales" organizational unit. 591 mgrpErrorsTo 592 RFC 1959-style specification of users whom to notify 593 of mail delivery problems. 594 mgrpModerator 595 RFC 1959-style specification of a user whom to send 596 rejected messages (rejected because they came from 597 other than an "allowed broadcaster" or from outside 598 of the "allowed domains"), but only if the 599 'mgrpMsgRejectAction' attribute is present with value 600 'toModerator'. 601 mgrpMsgMaxSize 602 Size in bytes of largest message that may be sent to 603 the group. 604 mgrpMsgRejectAction 605 Action to take if a message is rejected due to 606 violating "allowed broadcaster" and/or "allowed 607 domain" restrictions (if any). May be one of: 608 'reply' (send rejection notice to sender), 'bounce' 609 (send rejection notice to sender, including the 610 original message), or 'toModerator' (forward to 611 moderator). 612 mgrpMsgRejectText 613 Text of rejection notice to use with 614 'mgrpMsgRejectText'. 615 mgrpRfc822MailMember 616 Email addresses of users who should receive copies of 617 all messages to the group (in addition to the formal 618 group members). These users and those specified via 619 'mgrpDeliverTo' are also called "CC recipients", 620 since they are not formal group members. 621 owner 622 Distinguished name (DN) of the person responsible for 623 the group.