Skip to content
Snippets Groups Projects
Commit 7ea7c51c authored by Kurt Zeilenga's avatar Kurt Zeilenga
Browse files

Add draft-lachman-ldap-mail-routing-03.txt

parent ccfba5f2
No related branches found
No related tags found
No related merge requests found
Hide whitespace changes
Inline Side-by-side
doc/drafts/draft-lachman-ldap-mail-routing-xx.txt 0 → 100644
+ 1067
− 0
View file @ 7ea7c51c
Network Working Group H. Lachman
INTERNET-DRAFT Netscape Communications Corp.
Intended Category: Informational October 1998
Expires: April 1999
Filename: draft-lachman-ldap-mail-routing-03.txt
LDAP Schema Definitions for Intranet Mail Routing -
The mailRecipient Object Class
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract
Directory services based on the Lightweight Directory Access Protocol
(LDAP) [1] and X.500 [2] provide a general-purpose means to store
information about users and other network entities. One of the many
possible uses of a directory service is to store information about
users' email accounts, such as their email addresses, and how
messages addressed to them should be routed. In the interest of
interoperability, it is desirable to have a common schema for such
email-related information.
This document defines an object class called 'mailRecipient' to
Lachman [Page 1]
INTERNET-DRAFT The mailRecipient Object Class October 1998
support SMTP [3] message transfer agents (MTAs) in routing RFC 822-
based email messages [4] within an organization. The intent is to
suggest a model for MTA interoperability via the directory, to
provide information about a solution that has been implemented and
deployed, and to stimulate discussion about whether and how to
standardize the functionality in question.
1. Background and Motivation
LDAP-based directory services are currently being used in many
organizations as a repository of information about users and other
network entities (such as groups of users, network resources, etc.).
Some information is stored in the directory for the consumption of
persons browsing for information (e.g., telephone numbers, postal
addresses, secretary's name). Other information (e.g., login name,
password, disk quota) is stored for use by one or more network
applications or services. This latter use of the directory suggests
the opportunity to centralize the storage and management of user
account information related to different services. In general, it is
advantageous for different network applications and services to refer
to the directory for user account information, rather than each
service keeping its own collection of user account records, which
requires the network administrator to separately create or destroy
user entities, passwords, etc., in many different systems each time a
user joins or leaves the organization. The goals of centralized user
management and sharing of information with other service types drove
our decision in the design of Netscape Messaging Server (an SMTP-
based mail server product) to use LDAP-based directory services as a
common repository for user account information.
Thus, in our implementation, all account information for a given mail
server user is stored in the directory entry that represents that
user. This includes the user's delivery options, access
restrictions, mailbox quota, and vacation status, among other things.
Now, if a given mail server can refer to the directory for its own
users' account information, it follows that that same information can
be made visible to other LDAP-aware mail servers in the same
organization, and therefore that information can aid those other mail
servers in correctly routing messages to users of the mail server in
question. This assumes that there is an agreed-upon set of per-user
attributes to support message routing among the mail servers in the
organization. If this assumption is met in our implementation, we
can obviate other means currently employed to specify per-user
message routing (such as the sendmail "aliases" database). The
benefit of this is to further consolidate per-user system
information.
If different vendors provide LDAP-aware mail server products, each
Lachman [Page 2]
INTERNET-DRAFT The mailRecipient Object Class October 1998
having its own schema for message routing, then the above benefits
can be achieved for single-vendor customers, but customers who have
multiple vendors' mail server products would not be well served.
They will likely expect interoperability, which will require a common
schema to be supported by the various vendors' products. Thus, it is
worthwhile to consider how to develop a common schema.
This document defines a schema designed to provide a means by which a
directory entry that represents a mail recipient can provide
information enabling MTAs to route messages to the recipient's "home"
MTA. This document considers only intra-enterprise SMTP message
routing using LDAP-based directory services. Solutions and issues
involving inter-enterprise routing, non-SMTP message handling, non-
LDAP directory services, and other messaging management topics not
related to message routing, are outside the scope of this document
(except that the concepts presented may also be applicable in the
case of any X.500-based directory service).
2. Overview of the Approach Implemented
In our design of Netscape Messaging Server, we identified all pieces
of per-user account information, and assigned attributes such that
the information for a given user can be held in the user's "LDAP
entry" (the directory entry representing the user in an LDAP-based
directory service). We segregated the attributes into two subsets:
those that are of interest only to the "target MTA" (i.e., the MTA
that considers the recipient to be local), and those that are of
interest to "intermediary MTAs" (i.e., MTAs that are not the target
MTA). Each subset of attributes is aggregated into an object class,
the former being 'nsMessagingServerUser' (see Appendix), and the
latter, 'mailRecipient'. It is the latter object class that is the
focus of this document.
The 'mailRecipient' object class provides attributes that may be used
to specify addressing and routing information pertaining to a given
recipient. This information may be used by an intermediary MTA to
route a message to the recipient's designated target MTA, i.e., to
the MTA that "takes responsibility" for messages to the recipient in
question. The target MTA then accepts the message and, regarding the
recipient as local, handles the message as specified by attributes
intended for use by the target MTA (such as those associated with the
'nsMessagingServerUser' object class).
Lachman [Page 3]
INTERNET-DRAFT The mailRecipient Object Class October 1998
Consider a network with three hosts that run MTAs:
+------+
local | |
handling | MDA2 |
layer | |
+------+
^
|
+------+ +------+ +------+
| | | | | |
routing | MTA1 | -----> | MTA2 | -----> | MTA3 |
layer | | | | | |
+------+ +------+ +------+
host1 host2 host3
The above illustrates a two-layer mail routing and delivery model.
The attributes provided by the 'mailRecipient' object class are used
by the lower layer (the routing layer) to support the routing of a
message to the correct target MTA. Other attributes may be used by
the upper layer, which roughly equates to what is commonly called an
MDA (message delivery agent), although the local handling may or may
not involve delivery of the message to a mailbox (e.g., the message
may be resent if the recipient is a mail group or a forwarded
account). (In this discussion, "target MTA" means "target Messaging
Server" which includes both MTA and MDA functionalities; while the
implementation is not necessarily layered internally as implied
above, the product nonetheless exhibits the functionality described.)
In our implementation, an LDAP entry that represents a mail recipient
will have two mail-related object classes, 'mailRecipient', plus an
additional one that may be used by the local handling layer to
determine the recipient type and how messages for the recipient are
to be handled on the target MTA. A mail user account will have
'mailRecipient' plus 'nsMessagingServerUser'. A mail group will have
'mailRecipient' plus 'mailGroup' [5]. An MTA need only look at
attributes associated with 'mailRecipient' to determine whether a
recipient is local, and if not, how to route the message. The
additional object class and attributes are of interest only if the
recipient is local.
(Note: While the Messaging Server fully implements this approach,
earlier versions of its account creation tool do not place all of the
above-mentioned object classes in the entries it creates. The
Messaging Server is compatible with both the old and the new object
class interpretations.)
Lachman [Page 4]
INTERNET-DRAFT The mailRecipient Object Class October 1998
A Netscape Messaging Server can route messages to recipients on other
vendors' MTAs if the users' LDAP entries have the 'mailRecipient'
object class and associated attributes. (Other vendors' MTA
implementations may or may not follow the above-described model of
indicating recipient type and MDA-level account configuration in
LDAP, since only 'mailRecipient' and associated attributes are
required for MTA-level recognition.)
Likewise, other vendors' MTAs can route messages to recipients on a
Netscape Messaging Server if they recognize and interpret the
'mailRecipient' object class and associated attributes as defined in
Sec. 3.
The intent of this model is to provide a framework within which any
vendor can define new types of mail recipients, without requiring
other vendors' implementations to have knowledge of the new recipient
types; they need only have a consistent interpretation and
application of the 'mailRecipient' object class and associated
attributes.
In short, the main advantage of the 'mailRecipient' object class is
to define a single object class that can serve to identify an LDAP
entry as an entity to which email can be addressed, and to aggregate
the attributes that can provide multivendor MTA interoperability via
the directory.
3. Object Class and Attribute Definitions
The 'mailRecipient' object class and associated attributes are
defined (using syntaxes given in [6]) as follows.
3.1 The mailRecipient Object Class
( 2.16.840.1.113730.3.2.3
NAME 'mailRecipient'
SUP top
AUXILIARY
MAY ( cn $ mail $ mailAlternateAddress $
mailHost $ mailRoutingAddress
)
)
The 'mailRecipient' object class signifies that the entry represents
an entity within the organization that can receive SMTP mail, such as
a mail user account or a mail group account (mailing list).
The 'cn' attribute (common name) is provided as a means for
administrators to identify the entry [7].
Lachman [Page 5]
INTERNET-DRAFT The mailRecipient Object Class October 1998
3.2 Address Attributes
( 0.9.2342.19200300.100.1.3
NAME 'mail'
DESC 'RFC 822 email address of this recipient'
EQUALITY caseIgnoreIA5Match
SYNTAX '1.3.6.1.4.1.1466.115.121.1.26{256}'
SINGLE-VALUE
)
The attribute name 'mail' is a synonym for 'rfc822Mailbox', as
defined earlier in [8]. This attribute specifies the recipient's
"primary" or "advertised" email address, i.e., that which might
appear on a business card; for example, "user@example.com".
( 2.16.840.1.113730.3.1.13
NAME 'mailAlternateAddress'
DESC 'alternate RFC 822 email address of this recipient'
EQUALITY caseIgnoreIA5Match
SYNTAX '1.3.6.1.4.1.1466.115.121.1.26{256}'
)
The 'mailAlternateAddress' attribute is used to specify alternate
email addresses, if any, for the recipient; for example,
"nickname@example.com".
When determining the disposition of a given message, an MTA may
search the directory for an entry with object class 'mailRecipient'
and a 'mail' or 'mailAlternateAddress' attribute matching the
message's recipient address. If exactly one matching entry is found,
the MTA may regard the message as being addressed to the entity that
is represented by the directory entry.
In short, address attributes may be used by an LDAP entry to answer
the question "what is/are this account's email address(es)?"
3.3 Routing Attributes
( 2.16.840.1.113730.3.1.18
NAME 'mailHost'
DESC 'fully qualified hostname of the SMTP MTA that
handles messages for this recipient'
EQUALITY caseIgnoreIA5Match
SYNTAX '1.3.6.1.4.1.1466.115.121.1.26{256}'
SINGLE-VALUE
)
The 'mailHost' attribute indicates which MTA considers the
Lachman [Page 6]
INTERNET-DRAFT The mailRecipient Object Class October 1998
recipient's mail to be locally handlable. This information can be
used for routing, in that an intermediary MTA may take it to be the
destination for messages addressed to this recipient.
( 2.16.840.1.113730.3.1.47
NAME 'mailRoutingAddress'
DESC 'RFC 822 address to use when routing messages to
the SMTP MTA of this recipient'
EQUALITY caseIgnoreIA5Match
SYNTAX '1.3.6.1.4.1.1466.115.121.1.26{256}'
SINGLE-VALUE
)
The 'mailRoutingAddress' attribute indicates a routing address for
the recipient. An intermediary MTA may use this information to route
the message to the MTA that handles mail for this recipient.
Only one of the above two attributes need be present in order to
route messages on behalf of the recipient. The 'mailRoutingAddress'
attribute is more explicit in terms of providing an address that can
be used to rewrite the SMTP envelope recipient address. With
'mailHost', the envelope address either is not rewritten, or is
rewritten according to implementation-specific rules and/or
configuration.
In short, routing attributes may be used by an LDAP entry to answer
the question "how should MTAs route mail to this account?"
(analogous to using the sendmail "aliases" database for per-user
routing within an organization). This is in contrast with
"forwarding" (see Appendix); forwarding and delivery options may be
used by an LDAP entry to answer the question "what happens to mail
once it arrives at this account?", which may include forwarding to
some other account within or outside the organization (analogous to
using the sendmail ".forward" file).
4. MTA Implementation Details
This section provides details of the algorithms followed by the
Netscape Messaging Server as they relate to the 'mailRecipient'
object class and associated attributes. Our implementation includes
features that go beyond what is minimally needed to support the
schema defined in Section 3, and other MTA implementations need not
match our implementation in every detail in order to be interoperable
(especially since various features described here can be disabled);
but, in general, the features described here are recommended.
4.1 Finding the LDAP Entry for a Given Email Address
Lachman [Page 7]
INTERNET-DRAFT The mailRecipient Object Class October 1998
When the MTA receives a message, it attempts to determine whether
there is an LDAP entry that represents the recipient. It takes the
SMTP envelope recipient address, and performs a search in LDAP,
spanning the directory subtree specified in the configuration, for an
entry that has the object class 'mailRecipient', and has either a
'mail' or 'mailAlternateAddress' attribute matching the recipient
address in question. If exactly one match is found, this is taken to
be the LDAP entry that represents the recipient.
If there were zero matches, but the domain part of the address
matches the local MTA's hostname, we perform a fallback search with
the same address except that the domain part is truncated to not
include the host part (e.g., the search for
"user@nsmail1.example.com" is retried as "user@example.com"). This
fallback search is optional, as per the server configuration.
If there were zero matches so far, but the domain part of the address
is considered to be local (by configurable criteria), we perform a
fallback search for an LDAP entry that has object class
'mailRecipient' and a 'uid' attribute (i.e., login name; synonym for
'userid' [8]) equal to the local part of the recipient address. This
fallback search is optional, as per the server configuration.
If the MTA finds the LDAP entry representing the recipient, it
proceeds with the logic discussed in Section 4.2. Otherwise, it will
rely on other information resources to determine whether to reject
the message or route it elsewhere.
Note that LDAP entries without the 'mailRecipient' object class are
ignored (except as may be needed for backward compatibility). This
is necessary because some sites have LDAP entries that do not
represent mail recipients, but have a 'mail' attribute nonetheless.
For example, a conference room might have an LDAP entry including an
email address, telephone number, etc., that are the same as for the
secretary who books reservations for the room. In this example, the
conference room's email address is for contact information only, and
is not intended to imply that it has an email account. Therefore,
the MTA correctly ignores the conference room's LDAP entry, and
avoids producing multiple matches on the search.
4.2 Deciding Whether a Message can be Handled Locally
If the MTA has found the LDAP entry representing the recipient, as
per Section 4.1, it checks the LDAP entry's 'mailHost' value to see
if it matches the MTA's local hostname. If so, it handles the
message locally. (Note that since accounts hosted on a Netscape MTA
are expected to have a 'mailHost' value, they typically do not have a
'mailRoutingAddress' value; other implementations could make
Lachman [Page 8]
INTERNET-DRAFT The mailRecipient Object Class October 1998
different design choices, and still be compatible.)
Otherwise, it routes the message as specified by the 'mailHost' value
and/or the 'mailRoutingAddress' value. See Section 4.3 for further
details.
If the recipient's LDAP entry contains no routing information (i.e.,
no 'mailHost' nor 'mailRoutingAddress'), the MTA will bounce (reject)
the message. There are two exceptions to this rule, to accommodate
location-independent accounts, as follows.
If the entry has no routing information, but is a mailing list (i.e.,
has object class 'mailGroup'), the message is handled locally, i.e.,
the MTA "receives" messages to the address in question, performs the
mail group expansion, and resends to the group members. Thus, a mail
group can be configured as "location-independent", meaning that it
does not require a particular Messaging Server to perform the mail
group expansion.
If the entry has no routing information, but has one or more
'mailForwardingAddress' attributes (see Appendix), it is handled
locally, i.e., the MTA "receives" messages to the address in question
under the assumption that it is a forwarding-only (or "redirect")
account, and forwards the message to the new address(es). Thus, it
is not necessary to designate a particular Messaging Server to
perform forwarding on behalf of a forwarding-only account. (This
exception may be deprecated in a future version, and then all
'nsMessagingServerUser' accounts will require a 'mailHost' value. If
location-independent redirects are still desired, a 'mailGroup' entry
can be used to achieve the same effect. Or, one could imagine a new
object class to combine with 'mailRecipient', say,
'mailForwardingAlias', that just provides a way to configure a
location-independent recipient that has a 'mailForwardingAddress',
but this may be overkill. One might also consider whether the
desired action is actually "routing", not "forwarding" - see Sec. 3.3
for clarification. The point is that a mail server should never
perform "forwarding" unless it also takes responsibility for the
account's other attributes that specify delivery-time handling, if
any; this is to ensure that all of the account's forwarding and
delivery preferences are acted upon exactly once in the life of a
message.)
Note that if there were a non-Netscape MTA in the environment that
implemented the 'mailRecipient' concept but did not mimic the
Netscape MTA behavior regarding the above exception cases, it would
probably be unadvisable for administrators to configure any accounts
as location-independent. (This suggests that if it is generally
useful to configure a certain recipient type as location-independent,
Lachman [Page 9]
INTERNET-DRAFT The mailRecipient Object Class October 1998
e.g., 'mailGroup', it ought to be standardized.)
4.3 Determining how to Route a Message
If the recipient is not local, but has a 'mailHost' and/or
'mailRoutingAddress' attribute in its LDAP entry, we route the
message as follows.
First, we determine a destination. If a 'mailHost' value is present,
that is taken to be the destination. Otherwise, the domain part of
the 'mailRoutingAddress' value is taken to be the destination.
Second, we determine whether and how to rewrite the SMTP envelope
recipient address. If a 'mailRoutingAddress' value is present, the
envelope address is rewritten to that. Otherwise, depending on the
configuration, the envelope address may be rewritten by combining the
'uid' value, if present, with the 'mailHost' value (e.g.,
"uid@mail.host"), or, it is rewritten by combining the original
envelope address local part with the 'mailHost' value (e.g.,
"orig.localpart@mail.host"), or it is not rewritten at all.
Third, we determine the next SMTP hop. This may or may not be the
same as the destination determined above. Given the destination, the
MTA will consult the routing table in the MTA configuration, and/or
consult DNS for "MX" and/or "A" records [9].
The message is then relayed to the next SMTP hop, with the SMTP
envelope recipient address set as determined above.
Note that if both 'mailHost' and 'mailRoutingAddress' are present,
the 'mailHost' attribute determines the destination while the
'mailRoutingAddress' attribute determines the envelope rewrite. It
is expected that specifying both is unnecessary, although not
inherently harmful, and may be useful in some peculiar cases.
Note also that envelope rewrites may be considered unnecessary (e.g.,
in Netscape-only MTA sites), and perhaps undesirable (e.g., if the
user has multiple addresses and the target MTA allows the user to
configure server-side filters that read the envelope; also, envelope
rewrites may increase the chances of "namespace crossovers" in
multi-domain sites, as mentioned in Sec. 5.8). Envelope rewrites
become necessary when routing to MTAs whose reckoning of their
accounts' email addresses is not consistent with the accounts'
respective LDAP entries (which could be the case with MTAs that are
not 'mailRecipient'-compatible).
5. Examples
Lachman [Page 10]
INTERNET-DRAFT The mailRecipient Object Class October 1998
The following is a set of directory entries, shown in LDIF [10]
format, that illustrates the use of the 'mailRecipient' object class.
Examples based on this set of entries are provided in the sections
that follow. Each example explains what happens when a message
arrives on nsmail1.example.com for the indicated recipient.
dn: cn=Joe Blow,o=Example Corp,c=US
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: mailRecipient
objectclass: nsMessagingServerUser
cn: Joe Blow
sn: Blow
uid: joeblow
userpassword: {crypt}y9LyrzNBT49Ao
mail: joeblow@example.com
mailhost: nsmail1.example.com
maildeliveryoption: mailbox
dn: cn=John Doe,o=Example Corp,c=US
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: mailRecipient
objectclass: nsMessagingServerUser
cn: John Doe
sn: Doe
uid: johndoe
userpassword: {crypt}y9LyrzNBT49Ao
mail: johndoe@example.com
mailalternateaddress: jonjon@example.com
mailhost: nsmail2.example.com
maildeliveryoption: mailbox
dn: cn=Scuba Group,o=Example Corp,c=US
objectclass: top
objectclass: groupOfUniqueNames
objectclass: mailRecipient
objectclass: mailGroup
cn: Scuba Group
mail: scuba@example.com
mgrprfc822mailmember: joeblow@example.com
mgrprfc822mailmember: johndoe@example.com
dn: cn=Tuba Group,o=Example Corp,c=US
Lachman [Page 11]
INTERNET-DRAFT The mailRecipient Object Class October 1998
objectclass: top
objectclass: groupOfUniqueNames
objectclass: mailRecipient
objectclass: mailGroup
cn: Tuba Group
mail: tuba@example.com
mailhost: nsmail2.example.com
mgrprfc822mailmember: joeblow@example.com
mgrprfc822mailmember: janeroe@example.com
dn: cn=Jane Roe,o=Example Corp,c=US
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: mailRecipient
objectclass: nsMessagingServerUser
cn: Jane Roe
sn: Doe
uid: janeroe
userpassword: {crypt}y9LyrzNBT49Ao
mail: janeroe@example.com
mailhost: nsmail1.example.com
maildeliveryoption: mailbox
mailforwardingaddress: babs@example.com
dn: cn=J Random User,o=Example Corp,c=US
objectclass: top
objectclass: mailRecipient
objectclass: nsMessagingServerUser
cn: J Random User
sn: User
mail: jruser@example.com
mailforwardingaddress: random@pu.edu
dn: cn=Babs Jensen,o=Example Corp,c=US
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: mailRecipient
objectclass: xyzMailUser
cn: Babs Jensen
sn: Jensen
uid: babs
userpassword: {crypt}y9LyrzNBT49Ao
mail: babs@example.com
mailalternateaddress: bj@schooldist12.k12.ca.us
Lachman [Page 12]
INTERNET-DRAFT The mailRecipient Object Class October 1998
mailroutingaddress: Babs_Jensen@xyz1.example.com
xyzPostOfficeName: Example_PO_1
xyzUserType: regular
xyzQuota: 1000000
dn: cn=Charlie Hacker,o=Example Corp,c=US
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: mailRecipient
objectclass: nsMessagingServerUser
cn: Charlie Hacker
sn: Hacker
uid: hacker
userpassword: {crypt}y9LyrzNBT49Ao
mail: hacker@schooldist12.k12.ca.us
mailhost: nsmail2.example.com
mailroutingaddress: hacker@schooldist12.k12.ca.us
maildeliveryoption: mailbox
mailforwardingaddress: babs@example.com
dn: cn=Conference Room 102,o=Example Corp,c=US
objectclass: top
objectclass: conferenceRoom
mail: babs@example.com
roomNumber: 102
5.1 Example #1
When a message arrives on nsmail1.example.com for
joeblow@example.com, the message is deposited in Joe Blow's mailbox.
5.2 Example #2
When a message arrives on nsmail1.example.com for johndoe@example.com
or for jonjon@example.com, the message is relayed to
nsmail2.example.com, with "johndoe@nsmail2.example.com" in the
envelope (assuming the "uid@mail.host" rewrite option is enabled on
nsmail1.example.com). On nsmail2.example.com, the message is
identified as belonging to John Doe by virtue of
"nsmail2.example.com" being local and "johndoe" being the 'uid' of
John Doe (assuming the 'uid' fallback search is enabled on
nsmail2.example.com). So the message is deposited in his mailbox on
nsmail2.example.com.
The above case would also succeed if the "truncate host part"
fallback search were enabled on nsmail2.example.com, or if no
Lachman [Page 13]
INTERNET-DRAFT The mailRecipient Object Class October 1998
fallback searches or envelope rewrites were configured on either
machine (in which case the envelope recipient address would remain
unchanged).
5.3 Example #3
When a message arrives on nsmail1.example.com for scuba@example.com,
the message is resent to joeblow@example.com and johndoe@example.com.
(The message is considered to be locally handlable since the
recipient is a mail group with no routing information.)
5.4 Example #4
When a message arrives on nsmail1.example.com for tuba@example.com,
the message is relayed to nsmail2.example.com with
"tuba@nsmail2.example.com" (assuming that the
"orig.localpart@mail.host" option is enabled). On
nsmail2.example.com, the message is identified as belonging to the
Tuba Group by virtue of the "truncate host part" fallback search, so
the message is accepted and resent to the group members.
As in Example #2, the above case would also succeed if no fallback
searches or envelope rewrites were configured on either machine.
5.5 Example #5
When a message arrives on nsmail1.example.com for
janeroe@example.com, the message is delivered to Jane's mailbox, and
is also forwarded to Babs. Perhaps Jane is on leave.
5.6 Example #6
When a message arrives on nsmail1.example.com for jruser@example.com,
it is forwarded to random@pu.edu. Perhaps he has left the company to
go back to school, and the company is forwarding his mail as a favor.
Note that the presence or absence of the usual object classes such as
'person' do not affect the Messaging Server. Also, the absence of
'uid' and 'userPassword' is probably a good idea since a person who
has left the company should not be able to login. Note also that a
'mailHost' could have been specified, e.g., as "nsmail2.example.com",
with no difference in overall effect, except that it would require
all messages addressed to this user to be passed to
nsmail2.example.com where the forward action would then be performed.
(This is an example of a location-independent "redirect" account,
which may be deprecated in a future release; see Sec. 4.2.)
Lachman [Page 14]
INTERNET-DRAFT The mailRecipient Object Class October 1998
5.7 Example #7
When a message arrives on nsmail1.example.com for babs@example.com,
or for bj@schooldist12.k12.ca.us (the company is doing a favor to a
local school district by hosting their mail accounts on the company
servers; Babs is both an employee in the company and a volunteer at
the school district, and so she has both addresses), the message is
relayed to the SMTP MTA on host xyz1.example.com (which may be an
SMTP-to-XYZ gateway), with "Babs_Jensen@xyz1.example.com" in the
envelope.
Note that Conference Room 102 is not identified by the MTA as a
recipient of mail addressed to babs@example.com, despite it's having
the matching 'mail' address. This is because it does not have the
'mailRecipient' object class.
5.8 Example #8
When a message arrives on nsmail1.example.com for
hacker@schooldist12.k12.ca.us, the message is relayed to
nsmail2.example.com with "hacker@schooldist12.k12.ca.us" in the
envelope. Mail arriving on nsmail2.example.com for this user is
deposited into his mailbox, and a copy is forwarded to Babs. Charlie
is a guest user from a local school district, and is not in the
company, and therefore does not have an address with "example.com".
The reason to force the envelope using 'mailRoutingAddress' is to
avoid having it rewritten to "hacker@nsmail2.example.com", which
would happen if envelope rewrites using 'mailHost' are enabled.
Thus, we avoid a "namespace crossover" that could result in
misdelivered mail if there were some other user with address
"hacker@example.com". This is one of the peculiar cases where having
both 'mailHost' and 'mailRoutingAddress' is useful, since
'mailRoutingAddress' overrides the default rewrite rule (although the
problem could also be solved by disabling envelope rewrites, assuming
they are not needed). Any site that hosts multiple domains (e.g., an
Internet service provider) must be especially careful in considering
whether and how envelopes are to be rewritten when mail is routed
among its MTAs. (See also Sec. 4.3.)
6. Security Considerations
As in all cases where account information is stored in an LDAP-based
directory service, network administrators must be careful to ensure
that their directory service controls users' access to the entries
and attributes stored therein, according to site policy (e.g.,
allowing users to modify, say, their 'mailForwardingAddress'
attribute, but not their 'mailHost' attribute). Mail server products
Lachman [Page 15]
INTERNET-DRAFT The mailRecipient Object Class October 1998
and their associated user management tools should help administrators
to ensure this, and should also help administrators avoid
configurations that would result in misdelivered mail due to
"namespace crossovers" and other reasons.
7. Acknowledgements
Many members of the Netscape Messaging Server and Directory Server
teams contributed to the design of this schema, including Bill
Fitler, Prabhat Keni, Mike Macgirvin, Bruce Steinback, John Myers,
Tim Howes, Mark Smith, and John Kristian (who coined the object class
name 'mailRecipient'). Special thanks to Leif Hedstrom, Netscape's
Chief Dogfood Taster, for his "real world" insights. Thanks also to
Jeff Hodges for contributing to the discussion that led to this memo,
and to Stuart Freedman for providing review comments.
8. References
[1] W. Yeong, T. Howes, S. Kille, "Lightweight Directory Access
Protocol", RFC 1777, March 1995.
[2] "Information Processing Systems - Open Systems Interconnection -
The Directory: Overview of Concepts, Models and Service", ISO/IEC JTC
1/SC21, International Standard 9594-1, 1988.
[3] J. Postel, "Simple Mail Transfer Protocol", STD 10, RFC 821,
August 1982.
[4] D. Crocker, "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, August 1982.
[5] B. Steinback, "Using LDAP for SMTP Mailing Lists and Aliases",
Internet-Draft (work in progress).
[6] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight X.500
Directory Access Protocol (v3): Attribute Syntax Definitions", RFC
2252, December 1997.
[7] M. Wahl, "A Summary of the X.500(96) User Schema for use with
LDAPv3", RFC 2256, December 1997.
[8] P. Barker, S. Kille, "The COSINE and Internet X.500 Schema", RFC
1274, November 1991.
[9] C. Partridge, "Mail routing and the domain system", STD 14, RFC
974, January 1986.
[10] G. Good, "The LDAP Data Interchange Format (LDIF) - Technical
Lachman [Page 16]
INTERNET-DRAFT The mailRecipient Object Class October 1998
Specification", Internet-Draft (work in progress).
[11] M. Smith, "The inetOrgPerson Object Class", Internet-Draft
(work in progress).
9. Author's Address
Hans Lachman
Netscape Communications Corp.
501 East Middlefield Road
Mountain View, CA 94043
Phone: (650) 254-1900
EMail: lachman@netscape.com
10. Appendix - nsMessagingServerUser Object Class and Attributes
The following is an informal description of the
'nsMessagingServerUser' object class and associated attributes. It
was designed to be used in combination with the 'mailRecipient' and
'inetOrgPerson' [11] object classes to define a Netscape Messaging
Server user account. This definition is not considered part of the
'mailRecipient' definition, and is provided here purely as
supplemental information. These attributes may change across
releases, and such changes would not affect MTA interoperability.
Object class: nsMessagingServerUser
Allowed attributes:
cn
Common name (person's full name).
mailAccessDomain
Domains and IP addresses from which user may do POP
or IMAP login.
mailAutoReplyMode
Auto-reply mode, may be one (or none) of: 'vacation'
(send reply text to sender, but only once per
vacation), 'reply' (send reply text unconditionally),
or 'echo' (like 'reply' but include original message
in the reply).
mailAutoReplyText
Reply text to use with 'mailAutoReplyMode'.
mailDeliveryOption
Mail delivery option, one or more of: 'mailbox'
(deliver to user's POP/IMAP mailbox), 'native'
(deliver with platform's native delivery method,
e.g., "/usr/bin/mail"), or 'program' (perform program
delivery). There must be at least one
'mailDeliveryOption' and/or 'mailForwardingAddress',
Lachman [Page 17]
INTERNET-DRAFT The mailRecipient Object Class October 1998
otherwise, mail to this account is undeliverable.
mailForwardingAddress
User-specifiable mail forwarding address(es). This
is different from 'mailRoutingAddress' in that it is
intended to be configurable by the user, and may be
multi-valued. Thus, forwarding and delivery options
may be thought of as "account preferences", while
routing attributes are used to get a message to the
MTA that will take responsibility for handling the
message as per the recipient's account preferences.
mailMessageStore
Identifier for the message store containing this
user's POP/IMAP mailbox.
mailProgramDeliveryInfo
Command text for program delivery.
mailQuota
Quota in bytes for user's POP/IMAP mailbox.
Lachman [Page 18]
INTERNET-DRAFT The mailRecipient Object Class October 1998
11. Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Lachman Expires: April 1999 [Page 19]
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment