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