1 INTERNET-DRAFT H. Lachman
2 Intended Category: Standards Track Netscape Communications Corp.
3 Filename: draft-lachman-laser-ldap-mail-routing-01.txt G. Shapiro
5 Expires: April 2000 October 1999
7 LDAP Schema for Intranet Mail Routing
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-
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 <laser@sunroof.eng.sun.com>. Subscription requests can be sent to
32 <laser-request@sunroof.eng.sun.com> (send an email message with the
33 word "subscribe" in the body). More information on the mailing list
34 along with an archive of back messages is available at
35 <http://playground.sun.com/laser/>.
37 [[Section X will be removed before the document is submitted to the
42 Copyright (C) The Internet Society (1999). All Rights Reserved.
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
56 Lachman, et. al. [Page 1]
58 INTERNET-DRAFT LDAP Schema for Intranet Mail Routing October 1999
60 1. Conventions Used in this Document
62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
64 document are to be interpreted as described in [10].
66 2. Background and Motivation
68 LDAP-based directory services are currently being used in many
69 organizations as a repository of information about users and other
70 network entities (such as groups of users, network resources, etc.).
71 In cases where LDAP entries are used to represent entities that are
72 email recipients (e.g., a mail user or a mailing list), the LDAP
73 entries provide a convenient place to store per-recipient data, such
74 as a recipient's email address.
76 In many organizations, an email recipient may have an email address
77 (e.g., "joe@example.com") that does not specify the host that
78 receives mail for that recipient (e.g., "host42.example.com"). A
79 message transfer agent (MTA) responsible for routing mail within the
80 organization needs some way to determine the appropriate target host
81 for such a recipient. A common solution is the sendmail "aliases"
82 database which may contain a record that provides the necessary per-
83 recipient routing information (e.g., "joe: joe@host42"). A drawback
84 of this solution is that if the organization hosts more than one DNS
85 domain (e.g., "example.com" and "example.org", with "joe" in each
86 domain being different recipients), a more explicit mapping is
87 desirable. The schema defined in this document provides a way to
88 represent such mappings in LDAP and X.500 [4] directory services.
90 An LDAP entry that represents an email recipient could conceivably
91 contain a variety of attributes related to email, such as disk quota
92 and delivery preferences. We consider here only attributes that
93 specify address information and routing information; these attributes
94 may be useful to multiple MTAs within the organization since one or
95 more MTAs may be responsible for intra-organizational routing. The
96 various MTAs in an organization may have been developed by different
97 implementors, so a common schema is desirable for such attributes.
101 The 'inetLocalMailRecipient' object class and associated attributes
102 identify an LDAP entry as representing an SMTP mail recipient (in the
103 sense "recipient" is used in [2]). A recipient may be a mail user, a
104 mailing list, an auto-responder of some kind (e.g., a mailing list
105 subscription program), a network device such as a printer or fax
106 machine, or other recipient type. Address attributes and routing
107 attributes are provided to aid SMTP MTAs in routing mail within an
108 organization to the appropriate target MTA for each recipient.
110 Lachman, et. al. [Page 2]
112 INTERNET-DRAFT LDAP Schema for Intranet Mail Routing October 1999
114 Once on the target MTA, a message is handled as per the recipient
115 type and options (which may be specified using other auxiliary object
116 classes and is outside the scope of this document). For example, the
117 message may be delivered to a user mailbox, or to a program or
118 network device, and/or forwarded to another recipient. Or, the
119 target MTA may be a gateway to a non-SMTP mail routing and delivery
120 system including non-SMTP MTAs. Note that, in this discussion,
121 "target MTA" refers to the final SMTP destination of messages for the
122 recipient in question, as we are considering routing of mail only
123 among the SMTP MTAs within an organization.
125 The target MTA checks to see if the destination domain of the
126 recipient address is one that it is responsible for LDAP-based
127 routing. If so, checks for matching e-mail addresses in LDAP by
128 looking up the envelope recipient address in LDAP using the object
129 class described in section 4.1 and the attribute discussed in section
130 4.2. If it gets back an unambiguous match, it interprets the routing
131 attributes as described in section 4.3.
133 Routing of mail between different organizations across the public
134 Internet is outside the scope of this document, as the mechanism for
135 this is already standardized [5,6]. An 'inetLocalMailRecipient'
136 entry represents a mail recipient that is local to the organization
137 in question, not recipients in other organizations. This means that
138 the domain names that appear within the 'mailLocalAddress' and
139 'mailHost' attribute values in an 'inetLocalMailRecipient' entry must
140 be DNS domain names that are within the administrative authority of
141 the organization in question (i.e., the organization within which
142 MTAs are accessing such entries and using these attributes for mail
145 LDAP entries that are not 'inetLocalMailRecipient' entries should be
146 ignored by MTAs for the purpose of routing. An example is a
147 conference room whose LDAP entry contains contact information (e.g.,
148 email address and telephone number) for the person who books
149 reservations for the room; the conference room is not a mail
150 recipient, and can safely be ignored by MTAs doing route
151 determination based on recipient address.
153 4. Object Class and Attribute Definitions
155 The 'inetLocalMailRecipient' object class and associated attributes
156 are defined (using syntaxes given in [7]) as follows.
158 Lachman, et. al. [Page 3]
160 INTERNET-DRAFT LDAP Schema for Intranet Mail Routing October 1999
162 4.1 The inetLocalMailRecipient Object Class
164 ( 2.16.840.1.113730.3.2.[[TBD]]
165 NAME 'inetLocalMailRecipient'
168 MAY ( mailLocalAddress $
169 mailHost $ mailRoutingAddress
173 The 'inetLocalMailRecipient' object class signifies that the entry
174 represents an entity within the organization that can receive SMTP
175 mail, such as a mail user or a mailing list. In any case of an entry
176 containing the 'inetLocalMailRecipient' object class, attributes
177 defined in this document MUST be interpreted as specified in this
180 4.2 Address Attribute
182 ( 2.16.840.1.113730.3.1.13
183 NAME 'mailLocalAddress'
184 DESC 'RFC 822 email address of this recipient'
185 EQUALITY caseIgnoreIA5Match
186 SYNTAX '1.3.6.1.4.1.1466.115.121.1.26{256}'
189 The 'mailLocalAddress' attribute is used to specify email addresses,
190 for the recipient; for example, "nickname@example.com". The address
191 conforms to the syntax of an 'addr-spec' as defined in [3].
193 The 'mailLocalAddress' attribute MUST contain all addresses that
194 represent each recipient of the target MTA. Commonly, the value of
195 the 'mail' attribute should also be among the addresses listed in
196 the 'mailLocalAddress' attribute if it is expected to be used for
199 When determining the disposition of a given message, MTAs using LDAP
200 (directly or indirectly) to route mail MUST search for an entry
201 with object class 'inetLocalMailRecipient' and a 'mailLocalAddress'
202 attribute matching the message's recipient address. If exactly one
203 matching entry is found, MTAs MUST regard the message as being
204 addressed to the entity that is represented by the directory entry.
206 If multiple entries are found, but all share an identical match for
207 both mailRoutingAddress and mailHost (e.g., their presence or absence
208 is the same as well as their values if present), the MTA MAY treat
209 this as a single match. Duplicate entries that return different
210 routing attributes or contradict each other are errors, however, and
211 should be handled by the MTA in some locally-appropriate way, such as
212 returning a DSN [11] to the sender.
214 Lachman, et. al. [Page 4]
216 INTERNET-DRAFT LDAP Schema for Intranet Mail Routing October 1999
218 If there is no match found by the above, MTAs SHOULD have the
219 capability of searching for the recipient domain against the
220 'mailLocalAddress' attribute using the "wildcard domain" address
221 "@<full-local-domain>" , e.g., "@example.org". In other words, if
222 mail arrives for "someone@example.org", and there is no recipient
223 with that address specified as 'mailLocalAddress', then the recipient
224 with the wildcard domain address should receive the mail.
226 MTAs MAY do other searches but only after the above are done.
228 In short, the address attribute 'mailLocalAddress' may be used by an
229 LDAP entry to answer the question "what is/are this account's email
232 4.3 Routing Attributes
234 ( 2.16.840.1.113730.3.1.18
236 DESC 'fully-qualified hostname of the MTA that is the final
237 SMTP destination of messages to this recipient'
238 EQUALITY caseIgnoreIA5Match
239 SYNTAX '1.3.6.1.4.1.1466.115.121.1.26{256}'
243 The 'mailHost' attribute indicates which SMTP MTA considers the
244 recipient's mail to be locally handleable. This information can be
245 used for routing, in that an intermediary MTA may take it to be the
246 destination for messages addressed to this recipient. Normal mail
247 routing requirements (i.e., use of MX records) apply to the specified
248 hostname unless overridden by local conventions. In other words, the
249 mail should be sent to the specified host without changing the
250 recipient address. The hostname is specified as a fully-qualified
251 DNS hostname with no trailing dot (e.g., "host42.example.com").
253 If the 'inetLocalMailRecipient' object class is present, the
254 'mailHost' attribute for each entry MAY contain a value. If it does,
255 that value MUST be the fully qualified name of the server containing
256 the host MTA for this person. If 'mailHost' is present then it MUST
257 be taken as the host for this user, and all mail to this user MUST be
258 routed to this machine.
260 ( 2.16.840.1.113730.3.1.47
261 NAME 'mailRoutingAddress'
262 DESC 'RFC 822 address to use when routing messages to
263 the SMTP MTA of this recipient'
264 EQUALITY caseIgnoreIA5Match
265 SYNTAX '1.3.6.1.4.1.1466.115.121.1.26{256}'
269 Lachman, et. al. [Page 5]
271 INTERNET-DRAFT LDAP Schema for Intranet Mail Routing October 1999
273 The 'mailRoutingAddress' attribute indicates a routing address for
274 the recipient. The address MUST conform to the syntax of an
275 'addr-spec' in [3]. An intermediary MTA MUST use this information to
276 route the message to the MTA that handles mail for this recipient,
277 e.g., the envelope address MUST be rewritten to this value. This is
278 useful in cases where, for a given recipient, the target MTA prefers
279 a particular address to appear as the recipient address in the SMTP
280 envelope. 'mailRoutingAddress' MAY be used as an alternative to
281 'mailHost', and is intended to have the same effect as 'mailHost'
282 except that 'mailRoutingAddress' is an address for rewriting the
283 envelope. With 'mailHost', the envelope address either is not
284 rewritten, or is rewritten according to implementation-specific rules
285 and/or configuration.
287 If both 'mailHost' and 'mailRoutingAddress' are present, MTAs MAY
288 interpret it to mean that messages are to be routed to the host
289 indicated by 'mailHost', while rewriting the envelope as per
290 'mailRoutingAddress'. In theory, there could be peculiar cases where
291 this is necessary, but this is not normally expected.
293 Absence of both 'mailHost' and 'mailRoutingAddress' MAY be considered an
294 error, unless "location-independent" recipient types are supported by
295 the various MTAs within the organization. This would allow any MTA in
296 the organization to handle the processing of mail for, say, a mailing
297 list. This presumes that the various MTAs all recognize the recipient
298 type in question, suggesting a need to standardize recipient types that
299 could be "location-independent".
301 In short, routing attributes may be used by an LDAP entry to answer
302 the question "how should MTAs route mail to this account?"
303 (analogous to using the sendmail "aliases" database for per-user
304 routing within an organization). This is in contrast with
305 "forwarding"; forwarding and delivery options may be specified in an
306 LDAP entry to answer the question "what happens to mail once it
307 arrives at this account?", which may include forwarding to some other
308 account within or outside the organization (analogous to using the
309 sendmail ".forward" file). Such options are outside the scope of the
310 'inetLocalMailRecipient' schema definition.
312 The following possibilities exist as a result of an LDAP lookup on an
315 mailHost is mailRoutingAddress is Results in
316 ----------- --------------------- ----------
317 set to a set mail routed to
318 "local" host mailRoutingAddress
320 set to a not set delivered to
321 "local" host original address
323 Lachman, et. al. [Page 6]
325 INTERNET-DRAFT LDAP Schema for Intranet Mail Routing October 1999
327 set to a set MAY relay to mailHost
328 remote host using mailRoutingAddress
330 set to a not set original address
331 remote host relayed to mailHost
333 not set set mail routed to
336 not set not set error or
337 "location-independent"
339 The term "local" host above means the host specified is one that the
340 local (target) MTA considers to be a local delivery. The local MTA
341 MAY rewrite the original address when mailRoutingAddress is not set
342 if local conventions warrant the change.
346 The following examples illustrate possible uses of the
347 'inetLocalMailRecipient' object class.
349 Here is an example of an LDAP entry representing a mail user:
351 dn: uid=joe,o=Example Corp,c=US
354 objectClass: organizationalPerson
355 objectClass: inetOrgPerson
356 objectClass: inetLocalMailRecipient
357 objectClass: nsMessagingServerUser
361 userPassword: {crypt}y2KxtbzMYnApU
362 mail: joe@example.com
363 mailLocalAddress: joe@example.com
364 mailLocalAddress: joe@another.example.com
365 mailHost: nsmail1.example.com
366 mailDeliveryOption: mailbox
368 mailForwardingAddress: mary@example.com
370 Joe User is a user of a hypothetical mail system called NS Messaging.
371 Let's say mail arrives on an MTA called "mx.example.com", addressed
372 to "joe@example.com". That MTA searches the directory for a mail
373 recipient with that address, using an LDAP search filter [8] such as:
375 (&(objectClass=inetLocalMailRecipient)
376 (mailLocalAddress=joe@example.com))
378 Lachman, et. al. [Page 7]
380 INTERNET-DRAFT LDAP Schema for Intranet Mail Routing October 1999
382 It finds Joe's LDAP entry, and routes the message to the target MTA
383 "nsmail1.example.com", while not rewriting the SMTP envelope
384 recipient address. Then, "nsmail1.example.com" receives the message,
385 searches for and finds the recipient in the directory, ascertains
386 that it is the recipient's target MTA, and handles the message as per
387 other attributes in the recipient's entry and/or the MTA
388 configuration (in this case, the message is delivered to a mailbox,
389 and forwarded to another recipient).
391 Note that this document does not specify the rules an MTA is to use
392 to ascertain whether or not it is the target MTA for a given
393 recipient (it could check the recipient's 'mailHost' value against
394 its own hostname, or check the recipient's 'mailRoutingAddress', or
395 check the MTA configuration, or some combination of these).
397 Here is another example of an LDAP entry representing a mail user:
399 dn: uid=john,o=Example Corp,c=US
402 objectClass: organizationalPerson
403 objectClass: inetOrgPerson
404 objectClass: inetLocalMailRecipient
405 objectClass: xyzMailUser
409 userPassword: {crypt}y2KxtbzMYnApU
410 mail: john@example.com
411 mailLocalAddress: john@example.com
412 mailRoutingAddress: John_Doe@xyz-gw.example.com
413 xyzPostOfficeName: PO_1
417 John Doe is a user of a hypothetical mail system called XYZ Mail.
418 Let's say mail arrives on an MTA called "mx.example.com", addressed
419 to "john@example.com". That MTA searches the directory for a mail
420 recipient with that address, and routes the message to "xyz-
421 gw.example.com", rewriting the SMTP envelope recipient address to
422 "John_Doe@xyz-gw.example.com", as per the 'mailRoutingAddress'. On
423 "xyz-gw.example.com", the message is gatewayed into the XYZ Mail
424 system and then dealt with as per other attributes.
426 Lachman, et. al. [Page 8]
428 INTERNET-DRAFT LDAP Schema for Intranet Mail Routing October 1999
430 Here is an example of an LDAP entry representing a mailing list:
432 dn: cn=Scuba Group,o=Example Corp,c=US
434 objectClass: groupOfUniqueNames
435 objectClass: inetLocalMailRecipient
436 objectClass: mailGroup
438 mail: scuba@example.com
439 mailLocalAddress: scuba@example.com
440 mailHost: host42.example.com
441 mgrpRFC822MailMember: joe@example.com
442 mgrpRFC822MailMember: john@example.com
444 The Scuba Group is a mail group (mailing list) that includes two
445 members. A message addressed to "scuba@example.com" is routed to
446 "host42.example.com" where it is then resent to the mailing list
447 members. The 'mailGroup' object class is specified elsewhere [9].
449 Here is an example of an LDAP entry representing a forwarding alias:
451 dn: cn=Jane Roe Forwarding Alias,o=Example,c=US
453 objectClass: inetLocalMailRecipient
454 objectClass: mailForwardingAlias
455 mail: janeroe@example.org
456 mailLocalAddress: janeroe@example.org
457 mailHost: mail.example.org
458 mailForwardingAddress: janeroe@elsewhere.example.com
459 cn: Jane Roe Forwarding Alias
461 This entry uses a hypothetical object class 'mailForwardingAlias'
462 that is not specified here, but is used as an example of how an LDAP
463 entry might represent such a recipient type. A message addressed to
464 "janeroe@example.org" is routed to "mail.example.org" where it is
465 then forwarded. In this case, Jane Roe may be a former member of the
466 Example Organization, and they are forwarding her mail to her new
469 6. Security Considerations
471 As in all cases where account information is stored in an LDAP-based
472 directory service, network administrators must be careful to ensure
473 that their directory service controls users' access to the entries
474 and attributes stored therein, according to site policy. In
475 particular, mail routing information should not be accessible from
476 outside the organization, since it is intended for use only by MTAs
477 within the organization.
479 Lachman, et. al. [Page 9]
481 INTERNET-DRAFT LDAP Schema for Intranet Mail Routing October 1999
485 The 'inetLocalMailRecipient' object class is based on an earlier
486 design done by the Netscape Messaging and Directory Server teams,
487 which was implemented and deployed to customers as part of Netscape
488 Messaging Server. Various team members contributed to the design,
489 including Bill Fitler, Bruce Steinback, Prabhat Keni, Mike Macgirvin,
490 John Myers, John Kristian, Tim Howes, Mark Smith, and Leif Hedstrom.
491 Thanks also to Jeff Hodges of Stanford for contributing to the early
492 design discussions, and to the other participants in the IETF LASER
493 BOF, including, from Sun Microsystems, John Beck, Anil Srivastava,
498 [1] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
499 Protocol (v3)", RFC 2251, December 1997.
501 [2] J. Postel, "Simple Mail Transfer Protocol", STD 10, RFC 821,
504 [3] D. Crocker, "Standard for the Format of ARPA Internet Text
505 Messages", STD 11, RFC 822, August 1982.
507 [4] "Information Processing Systems - Open Systems Interconnection -
508 The Directory: Overview of Concepts, Models and Service", ISO/IEC JTC
509 1/SC21, International Standard 9594-1, 1988.
511 [5] C. Partridge, "Mail routing and the domain system", STD 14, RFC
514 [6] R. Braden, "Requirements for Internet hosts - application and
515 support", STD 3, RFC 1123, October 1989.
517 [7] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight X.500
518 Directory Access Protocol (v3): Attribute Syntax Definitions", RFC
521 [8] T. Howes, "The String Representation of LDAP Search Filters",
522 RFC 2254, December 1997.
524 [9] B. Steinback, "Using LDAP for SMTP Mailing Lists and Aliases",
525 Internet-Draft (work in progress).
527 [10] S. Bradner, "Key words for use in RFCs to Indicate Requirement
528 Levels", BCP 14, RFC 2119, March 1997.
530 [11] K. Moore, "SMTP Service Extension for Delivery Status
531 Notifications", RCP 1891, January 1996.
533 Lachman, et. al. [Page 10]
535 INTERNET-DRAFT LDAP Schema for Intranet Mail Routing October 1999
537 9. Authors' Addresses
540 Netscape Communications Corp.
541 501 East Middlefield Road
542 Mountain View, CA 94043
543 Phone: (650) 254-1900
544 EMail: lachman@netscape.com
548 6603 Shellmound Street
549 Emeryville, CA 94608-1042
550 Phone: +1 510-594-5522
552 EMail: gshapiro@sendmail.org
556 X.1.1 Substantive changes between
557 draft-lachman-laser-ldap-mail-routing-00.txt and
558 draft-lachman-laser-ldap-mail-routing-01.txt
560 (i) Added Gregory Neil Shapiro as another author.
561 (ii) Changed Draft heaer.
562 (iii) Added "Conventions Used in this Document" section.
563 (iv) Replaced RFC mentions with reference numbers.
564 (v) Add new MUST/SHOULD/MAY sections to bring more in line with
566 (vi) Clarify job of MTA in Overview by adding third paragraph.
567 (vii) mailRoutingAddress can be outside of administrative control.
568 (viii) Eliminated use of 'mail' attribute for mail routing.
569 (ix) Changed name of 'mailAlternateAddress' to 'mailLocalAddress'.
570 (x) Remove "routable" from 'mailLocalAddress' description.
571 (xi) Clarify which addresses MUST be in 'mailLocalAddress'.
572 (xii) Allow for multiple responses if they all have the same
573 routing attribute values.
574 (xiii) Clarify use of MX records on routing attributes.
575 (xiv) Add a table to clarify use of 'mailHost' and
576 'mailRoutingAddress'.
577 (xv) Remove document weakening statements from section 5.
578 (xvi) Only use reserved domains (example.com, example.org) in
580 (xvii) Clean up references
581 (xviii) Added section X to list the changes between draft versions.
583 Lachman, et. al. [Page 11]
585 INTERNET-DRAFT LDAP Schema for Intranet Mail Routing October 1999
587 10. Full Copyright Statement
589 Copyright (C) The Internet Society (1999). All Rights Reserved.
591 This document and translations of it may be copied and furnished
592 to others, and derivative works that comment on or otherwise
593 explain it or assist in its implementation may be prepared, copied,
594 published and distributed, in whole or in part, without
595 restriction of any kind, provided that the above copyright notice
596 and this paragraph are included on all such copies and derivative
597 works. However, this document itself may not be modified in any
598 way, such as by removing the copyright notice or references to the
599 Internet Society or other Internet organizations, except as needed
600 for the purpose of developing Internet standards in which case the
601 procedures for copyrights defined in the Internet Standards
602 process must be followed, or as required to translate it into
603 languages other than English.
605 The limited permissions granted above are perpetual and will not
606 be revoked by the Internet Society or its successors or assigns.
608 This document and the information contained herein is provided on
609 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
610 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
611 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
612 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
613 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
615 Lachman, et. al. [Page 12]