One document matched: draft-steinback-ldap-mailgroups-00.txt
Network Working Group Bruce Steinback
INTERNET-DRAFT Netscape Communications Corp.
Expires: March 1998 September 1997
Intended Category: Informational
Using LDAP for SMTP Mailing Lists & Aliases
<draft-steinback-ldap-mailgroups-00.txt>
Status of this Memo
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), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Distribution of this document is unlimited. Editorial comments
should be sent directly to the author.
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 such use is
to store information on groups. There are LDAP standards established
for this purpose, e.g. the groupOfUniqueNames [3]. However,
currently there are no standards for a very important use of Groups,
as SMTP Mailing Lists or Aliases.
This document discusses how we at Netscape have made this extension,
with the intent of providing useful information towards perhaps
creating standards for this important use of LDAP.
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), while other information
(e.g., login name, password, disk quota) is stored for use by one or
more network applications or services. It is the latter kind of
information that is of interest in this discussion. 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
mail server product) to use LDAP-based directory services as a
common repository for mail delivery information.
One of the "network entities" that LDAP currently stores are groups
of users. In X.500 this was done in the groupOfNames objectClass -
at Netscape we have updated that to the groupOfUniqueNames
objectClass.
One thing that is not provided by this group is the capability of
sending mail thru that group to the members. In light of making
LDAP a central repository for information for all network servers,
it seems appropriate to add this capability. There are also obvious
advantages of handling mail to groups within LDAP, making use of the
storage of all other mail recipients there.
2. General Considerations of the mailGroup
Since SMTP is the internet standard for email, that is the only type
of email we considered for our purposes. Proprietary email companies
may have other needs.
As the groupOfUniqueNames objectClass was already published at the
time we embarked on email enabling groups, and because not all
groupOfUniqueNames require email enabling, it was decided to create a
new objectClass - a mailGroup. Since it would be common to wish to
send mail to a groupOfUniqueNames, a mailGroup class can be
'mixed-in' with groupOfUniqueNames (that is, for an LDAP entry to
contain both objects). This way, a groupOfUniqueNames can be
"mail-enabled", but a mailGroup can also stand on its own.
Looking at existing list managers such as ListProc or Majordomo,
there are a number of pieces of extra information for a mailGroup
other than just the members and the group mailing address. These
tend to fall into two groups: mail handling features (e.g.
restrictions on mail to the group, directing where to process a
group,...), and group management features (e.g. who has what rights
to alter group attributes, visibility of group to management tools
such as a mail list manager,...).
Since the management features do not require handling within the Mail
Server, they can be handled separately and so we do not include them
in the mailGroup attributes. Some of these features can be handled
by LDAP access control, and the rest we decided could be handled by a
separate (mix-in) objectClass. These features will not be covered in
this document. We hope to document these in a separate document at a
later time.
3. Details of the mailGroup attributes
The group mail handling features needed fall into 3 subclasses: Mail
processing attributes that define how to deliver to the group,
Membership attributes that define who belongs to the group, and Mail
restriction attributes that define who can send what to the group.
The following sections provide the details on these attributes.
3.1 URL type for attributes containing addresses
There are several mailGroup attributes that could reasonably contain
mail addresses, or DN's of LDAP entities. Because of the dual nature
of mailGroups (being both an LDAP and email entity), it would be
appropriate to allow both types of addressing. Therefore we made
these attributes (mgrpErrorsTo, mgrpAllowedBroadcaster, and
mgrpModerator) URL's [4], to allow this dual use. If preceded by
"mailto:" then the entry is taken as an SMTP RFC822 address [5]. If
preceded by "ldap://" then it is taken as an LDAP entry.
3.2 Mail processing attributes
There are two key mail processing features: how to address the mail
group, and which type of mail group is this (mailing list or alias).
In addition, there are two attributes that deal with the outgoing
headers of mail to the group, and two for optimized processing.
3.2.1 'mail' attribute (cis, 1)
( 0.9.2342.19200300.100.1.3
NAME 'mail'
DESC 'RFC822 email address for this person'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String(256)'
SINGLE-VALUE
)
For addressing the group the primary attribute, and the only required
attribute of this objectClass, is 'mail'. This contains the RFC822
mail name of the group.
3.2.2 'mailAlternateAddress' attribute (cis, 0-many)
(2.16.840.1.113730.3.1.13
NAME 'mailAlternateAddress'
DESC 'alternate RFC822 email addresses used to reach this person'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String(256)'
)
There may also be a need for more than one way to address the group.
There may be a desire for alternate names for the group (e.g.
marketing@acme.com and marketing_dept@acme.com). Or there may be a
requirement for more specific or alternate domains (e.g.
marketing@server.acme.com). For any of these cases, we created an
attribute 'mailAlternateAddress', which contains as many alternate
mail addresses for the group as desired. For our purposes, we found
no need to exclude the 'mail' entry from being duplicated in the
'mailAlternateAddress', but don't encourage it.
3.2.3 'mailHost' attribute (cis, 0-many)
(2.16.840.1.113730.3.1.18
NAME 'mailHost'
DESC 'the fully qualified mail server hostname for this person'
EQUALITY 'caseIgnoreMatch'
SYNTAX 'DirectoryString'
)
For the organization that has multiple MTA's, we include a mailHost
attribute, to optionally force handling of a mailGroup to a
particular server. Note that in our implementation this is not
required: if left empty then any Messaging Server can expand the
mailGroup. For various reasons it's use is generally not encouraged.
However, it may be advantageous in some circumstances to do this
(e.g. if may be desired to expand a very large mailGroup on an
underutilized server). Note that this must be entered as a Fully
Qualified Domain Name (e.g. "server.acme.com", not just "server").
3.2.4 'mgrpErrorsTo' attribute (ces, 0-1)
(2.16.840.1.113730.3.1.26
NAME 'mgrpErrorsTo'
DESC 'person or group to receive error messages for this group'
SYNTAX 'DirectoryString'
SINGLE-VALUE
)
In SMTP there are two notions that are roughly analogous to a 'group'
- a 'Mailing List' and an 'Alias'. The difference between them [6]
is whether list errors (e.g. bounce messages) are returned to the
sender of the message, or to a 'list administrator'. The former are
considered 'Aliases', and the later 'Mailing Lists'. In the later
case, the 'list administrator' address is then used as the envelope
'from' address for any mail sent to members of the group (so that
errors are returned to the 'list administrator' instead of the
sender.
It is reasonable to want mailGroup to be able to support both
entities, so we have the attribute 'mgrpErrorsTo' which contains an
address for the 'list administrator'. As mentioned in section 3.1
above, this is one of the fields that use a URL for entry. If an
LDAP URL for a DN is entered (e.g. ldap:///cn=Joe Jones, o=Ace, c=US)
then the 'mail' attribute of that DN will be retrieved for use as the
mail address for errors. If no 'mail' attribute is found for the DN
entry then it is thrown out. Implementation note: For our
implementation, if neither "mailto:" nor "ldap://" is found as a
prefix then the assumption is that the entry is an RFC822 address.
As the envelope 'from' address is only expected to be a single
address by some MTA's, we will only allow one 'mgrpErrorsTo' entry.
However, if an admin wishes errors for a group to be handled by more
then one person, that one entry may be the DN or address of a
mailGroup iteslf, causing error messages to go to all members of that
group.
3.2.5 'mgrpNoMatchAdds' attribute (Boolean, 0-1)
(
NAME 'mgrpNoMatchAdds'
DESC 'if true then no duplicate adding from this group'
SYNTAX 'BOOLEAN'
SINGLE-VALUE
)
One thing that an MTA should try to do is to keep from sending
duplicate messages to people who are members of the group and also
explicitly addressed in a message, or are in another group that's
also addressed in the message. However, this can take a large amount
of time and memory for a large list, and administrators may desire
the capability to turn this feature off. This attribute provides
that.
3.2.6 'mgrpRemoveHeader' and 'mgrpAddHeader' attributes (cis, 0-many)
(
NAME 'mgrpRemoveHeader'
DESC 'headers to remove from messages to group'
SYNTAX 'IA5String'
)
(
NAME 'mgrpAddHeader'
DESC 'headers and contents to add to messages to group'
SYNTAX 'DirectoryString'
)
There are some headers that administrators may want to add and remove
from messages being distributed to the group members. Examples of
these are Reply-To:, which list administrators may want to add the
list address to, or even remove the original sender from (when it is
desired to have all correspondence go by default thru the group).
Another example would be the Precedence: header, which is
controversial but is used in some cases.
3.3 Membership attributes
The other key requirement for a mail group is to be able to specify
members to receive mail.
3.3.1 Mixing with a groupOfUniqueNames for members
One way in which we accomplish this is to allow the mailGroup to
mix-in with a groupOfUniqueNames. This provides the uniqueMembers
from the groupOfUniqueNames as our mail recipients. The DN entry for
the uniqueMember would then have the information necessary in order
to send mail to them. Any interested in Netscape's method of routing
mail can view our draft [7].
3.3.2 'mgrpRFC822MailMember' attribute (cis, 0-many)
(2.16.840.1.113730.3.1.30
NAME 'mgrpRFC822MailMember'
DESC 'RFC822 mail address of email only member of group'
EQUALITY CaseIgnoreIA5Match
SYNTAX 'IA5String(256)'
)
However, there are other ways to specify mail members for the group.
One case is that group mail members may be desired that do not have
LDAP entries in our directory. For this reason we added the
attribute 'mgrpRFC822MailMember'. This contains members specified by
RFC822 mail address. Another motivation for this attribute is that
it can be used to specify people to receive mail sent to a group, but
not acquire the privileges given to the mixed-in uniqueMembers of the
groupOfUniqueNames.
NOTE on mgrpRFC822MailMember: The format for this does not just
include the mail address. There are optional parameters after the
address, of the form below. These are used for group management and
are not detailed here.
joe@acme.com %1(parameter) %2(parameter)...
3.3.3 'mgrpDeliverTo' attribute (ces, 0-many)
(2.16.840.1.113730.3.1.25
NAME 'mgrpDeliverTo'
DESC 'LDAP Search URL to describe group membership'
SYNTAX 'IA5String'
EQUALITY caseExactIA5Match
)
LDAP also provides us with a truly unique and powerful method of
specifying groups membership - with an attribute (mgrpDeliverTo) that
is an LDAP search URL [8]. This allows us to create a dynamic search
of the directory for entries that match a criteria, rather than
having to specify each individual member. This uses the LDAP URL
format to specify the criteria for a search. This URL has the form:
ldap://(server):(port)/(baseDN)?(attrs)?(scope)?(filter)
The attrs portion of the URL is not applicable for this use and is
ignored.
Implementation notes: If the 'server' and 'port' are missing then
they would default to the LDAP server being used by the MTA. The
'baseDN' specifies the base for the search and if not present then
the default is the baseDN being used by the MTA.
The 'scope' defines the tree levels searched and it's default value
is 'base' (standard for an LDAP URL). And finally, the default for
'filter' is "(mail=*)" since we only want to get mailable entities.
3.4 Mail Restriction attributes
There are also several restrictions that are useful on who can send
to a mail group, or what they can send. We instituted two optional
restrictions on senders, and one on messages. We also added an
attribute to define what to do with rejected messages, and one for
optional text to send back to the sender of a rejected message.
3.4.1 Sender Restrictions
First let it be noted that due to the inherent (alas) spoofability of
SMTP mail, these restrictions are not normally to be thought of as
security for the group, but merely a method of reducing the amount of
mail to a group. Exceptions that provide more security are the
mgrpApprovePassword, and the use of Certificates for
mgrpAllowedBroadcasters (see below).
3.4.1.2 'mgrpAllowedDomain' attribute (cis, 0-many)
(2.16.840.1.113730.3.1.23
NAME 'mgrpAllowedDomain'
DESC 'allowed domains for sender of mail to group'
SYNTAX 'IA5String'
)
The first Sender restriction is by domain. The domain of the
sender's address is compared against those in the attribute
'mgrpAllowedDomain'. If there are no entries in the attribute then
all domains are allowed. If no match is found then the mail is
rejected (see 3.3.3 below for handling).
3.4.1.3 'mgrpAllowedBroadcaster' attribute (cis, 0-many)
(2.16.840.1.113730.3.1.22
NAME 'mgrpAllowedBroadcaster'
DESC 'mailto: or LDAP: URL of allowed sender of mail to the group'
SYNTAX 'IA5String'
)
The other Sender restriction is by address. The attribute
'mgrpAllowedBroadcaster' contains the senders allowed to send mail to
this group. As in 'mgrpErrorsTo' above, either DN's or RFC822 mail
addresses may be used, and groups (groupOfUniqueNames or mailGroups)
may also be used. As in mgrpAllowedDomain, if there are no entries
for this attribute, then no restrictions are assumed.
3.4.2 Message Restrictions
There was only one restriction on messages that was considered
valuable enough to be worth using, that of message size. The
attribute mgrpMsgMaxSize contains the maximum number of bytes allowed
for a message to this group (as above, if empty then there is no
restriction).
3.4.3 Rejected Message Disposition - mgrpMsgRejectAction &
mgrpMsgRejectText
(2.16.840.1.113730.3.1.28
NAME 'mgrpRejectAction'
DESC 'The action to be taken for a rejected message to the group'
SYNTAX 'GroupRejectSyntax'
)
<GroupRejectSyntax> :: [<RejectType>] <RejectAction>
<RejectType> :: 'SIZE:' | 'DOMAIN:' | 'SENDER:'
<RejectAction> :: 'REPLY' | 'BOUNCE' | 'TOMODERATOR'
(2.16.840.1.113730.3.1.29
NAME 'mgrpRejectText'
DESC 'Text to be returned with a rejected message'
SYNTAX 'GroupRejectTextSyntax'
)
<GroupRejectTextSyntax> :: [<RejectType>] DirectoryString
<RejectType> :: 'SIZE:' | 'DOMAIN:' | 'SENDER:'
There are three different actions that are currently allowed on a
rejected message. These are controlled by the mgrpMsgRejectAction
attribute. Other actions may be added later, but no compelling ones
appear imminent. The current options are:
"REPLY" - sends an error reply back to the message sender.
"BOUNCE" - sends the reply as above, along with the original
message.
"TOMODERATOR" - sends the message to (a) moderator address(es).
The attribute mgrpModerator contains these addresses to mail to.
The addresses may include mailGroups. This may be used (as one
might guess from the title) for moderated groups, but also for
other uses, e.g. forwarding messages 'unworthy' of sending to the
whole group to a newsgroup, to be read by people interested in
them.
For the REPLY and BOUNCE options, the reply sent back is contained in
the attribute mgrpMsgRejectText. If desired, separate actions and/or
messages can be stored for any of the rejection types, by preceeding
the text in the entry by "SIZE:", "DOMAIN:" or "SENDER:". The
mgrpMsgRejectText message is '$-encoded' - that is, all carriage
returns/line feeds are encoded as "$", and any "$"s in the text are
encoded to "\36". [10]
3.4.4 Mailing List moderation
It is often useful to have moderated mailing lists. For this type of
group, all mail that does not pass the restrictions is sent to (a)
moderator(s), possibly being a program to automatically handle
moderation tasks. The moderator(s) would then forward the message
back to the mailing list to 'resubmit' it.
3.4.4.1 'mgrpApprovePassword' attribute (ces, 0-1)
(
NAME 'mgrpApprovePassword'
DESC 'password used for approval of message to a moderated group'
EQUALITY octetStringMatch
SYNTAX 'Password{128}'
SINGLE-VALUE
)
This contains the password used for moderated message approval. If
it is present, and moderators exist, then all messages submitted to
the group must have an Approval line which includes this password
(actual implementation of this is left to the MTA). Exceptions are
permitted only as given in section 3.4.4.2 below.
3.4.4.2 'mgrpBroadcasterModeration' attribute (ces, 0-1)
(
NAME 'mgrpBroadcasterModeration'
DESC 'controls functionality of allowedBroadcaster list'
SYNTAX 'groupBroadcasterModeration'
SINGLE-VALUE
)
<groupBroadcasterModeration>:: 'BROADCASTERS_OVERRIDE' |
'CERT_BROADCASTERS_OVERRIDE' | 'BROADCASTERS_ARE' |
'CERT_BROADCASTERS_ARE'
This attribute controls the relation of moderation to the
allowedBroadcaster list. This can have any one of the following
values:
BROADCASTERS_OVERRIDE - if the sender is a member of
allowedBroadcaster then their message is posted to the group even
if moderation is on. This is the default.
CERT_BROADCASTERS_OVERRIDE - same as above except the sender's
Certificate must be present and checked (see xxxxx above).
BROADCASTERS_ARE - allowedBroadcasters are given 'moderation'
priviledge.
CERT_BROADCASTERS_ARE - again same as above except the sender's
Certificate must be present and checked.
Each of the CERT_ options would require mail to be sent 'signed',
with an X.509 Certificate [11]. The MTA would then check that this
matches the Certificate stored for that person.
4.0 Other notes
We did not bother to add any 'physical location' type attributes to
the mailGroup class (e.g. Mailing Address, Phone Number,...), as none
are necessary for processing, and they would seem to be of marginal
use anyway.
There is a 'cn', which is as expected the name of the group.
5.0 mailGroup Schema
The following is the LDAP schema for the mailGroup objectClass:
(2.16.840.1.113730.3.2.4
NAME 'mailGroup'
SUP top
STRUCTURAL
MUST mail
MAY ( cn $ mailAlternateAddress $ mailHost $ mailRequireAuth $
mgrpAddHeader $ mgrpAllowedBroadcaster $ mgrpAllowedDomain $
mgrpApprovePassword $ mgrpBroadcasterModeration $ mgrpDeliverTo $
mgrpErrorsTo $ mgrpModerator $ mgrpMsgMaxSize $
mgrpMsgRejectAction $ mgrpMsgRejectText $ mgrpNoMatchAddrs $
mgrpRemoveHeader $ mgrpRFC822MailMember )
)
6.0 Examples
Some example mailGroups, and their operation, might be
useful. Here are some (in LDIF format):
6.1 Example #1
dn: cn=Birds, ou=sales, o=Writable, c=US
objectclass: top
objectclass: mailGroup
cn: Birds
mail: birds@Writable.com
mailalternateaddress: birds@server.writable.com
mgrpdeliverto: ldap:///ou=sales, o=Writable Corp, c=US??sub?(&
(objectClass=mailRecipient)(cn=*Bird))
mgrperrorsto: ldap:///cn=Mickey Mouse, ou=sales, o=Writable, c=US
mgrpmsgrejectaction: bounce
mgrpmsgrejecttext: This is a test of the emergency broad casting
network.
mgrpalloweddomain: grunge.com
This group will send mail to all inetOrgPersons in the Sales org unit
of Writable Corp, with a name ending in "Bird" (very useful - eh!).
It is a 'mailing list' (rather than an 'alias'), as mgrpErrorsTo is
set. It will reject any mail where the sender's domain is not
grunge.com - rejected messages will be 'bounced' back to the sender,
with a reply message of "This is a test of the emergency broad
casting network." Mail to this group can be sent to either
birds@writable.com or birds@server.writable.com.
6.2 Example #2
dn: cn=Real People, ou=sales, o=Writable, c=US
objectclass: top
objectclass: mailGroup
objectclass: groupOfUniqueNames
cn: Real People
mail: real@Writable.com
mgrprfc822mailmember: bruces@netscape.com
mgrpallowedbroadcaster: ldap:///cn=Real People, ou=sales,
o=Writable, c=US
mgrperrorsto: mailto:bruces@netscape.com
mgrpmsgrejectaction: size: toModerator
mgrpmsgrejectaction: reply
mgrpmsgrejecttext: Sorry, Charlie
mgrpmoderator: ldap:///cn=Marvin the Martian, ou=marketing,
o=Writable, c=US
mgrpmsgmaxsize: 2000000
uniquemember: cn=Rose Bird, ou=legal, o=Writable, c=US
uniquemember: cn=Larry Bird, ou=finance, o=Writable, c=US
uniquemember: cn=Bird Man of Alcatraz, ou=legal, o=Writable, c=US
This group gets it's members partly from a the uniqueMembers of a
mixedin groupOfUniqueNames and one mgrpRFC822MailMember
(bruces@netscape.com) that will receive email sent to the group, but
have none of the other privileges of the uniqueMembers. Messages
over 2meg will be sent to "Marvin the Martian", but senders not in
the Real People group will merely have a reply sent to them. Also
note that the mgrpErrorsTo is specified here as an email address, as
opposed to a DN above.
6.3 Example #3
dn: cn=big moderated group, o=Writable, c=US
cn: big moderated group
mail: big_mod@writable.com
mgrpdeliverto: ldap:///??sub?(objectClass=inetOrgPerson)
mgrpaddheader: Reply-To: big_mod@writable.com
mgrpremoveheader: Precedence:
mgrpallowedbroadcaster: bruces@netscape.com
mgrpapprovepassword: ohdear
mgrpbroadcastermoderation: BROADCASTERS_OVERRIDE
And this group is one that would mail to everyone in the company.
The baseDN is the default (which would assumedly be the base for the
organization), and this would include all 'people'. This is a
moderated group, with a password of ohdear. Any "Precedence:" header
in a message to this group would get stripped, and
big_mod@writable.com would be added as a "Reply-To:" address for any
message to the group (or the Reply-To: header added if not already
present).
6.4 Example #4
dn: cn=nester, o=Writable, c=US
objectclass: top
objectclass: mailGroup
objectclass: groupOfUniqueNames
cn: nester
mail: nester@writable.com
mgrprfc822mailmember: birds@writable.com
uniquemember: cn=Marvin the Martian, ou=bruce, o=Writable, c=US
mgrpnomatchadrs: TRUE
Finally, this group includes an mgrpRFC822MailMember that is another
group (birds@writable.com - see example #1 above). It is also an
'alias' (as opposed to a 'mailing list') as there is no mgrpErrorsTo
specified. There are no restrictions on who can mail to this list.
Also, mail sent to this group will not check to avoid duplicate
addresses, so multiple copies of this message could be sent to the
same person (mgrpnomatchadrs: TRUE).
7.0 Security Considerations
As mentioned in sections 3.4.1 and 3.4.4.2, one of the features of
mailGroups is to restrict who can send mail to the group. There are
several ways to accomplish this that vary significantly in how secure
they are, ranging from just trusting the sender's headers, to a clear
text password, and finally Certificates. The needs will be different
for different groups, hence the range of possibilities provided.
8.0 Acknowledgements
There were many people of great assistance in producing this
document, but special thanks go to: Bill Fitler, who made the
mistake of hiring me in the first place, Tien Tran, who cheerfully
brought me up to speed on our Mail Server, and John Kristian, who
has patiently steered me towards a better understanding of LDAP.
9.0 References
[1] W. Yeong, T. Howes, S. Kille, "Lightweight Directory Access
Protocol", RFC1777, 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] X.521 (groupOfUniqueNames)
[4] T. Berners-Lee, L Masinter, M. McCahill, "Uniform Resource
Locators", RFC 1738, December 1994
[5] D. Crocker, "Standard for the Format of ARPA Internet Text
Messages", RFC 822, August 1982.
[6] R. Braden, "Requirements for Internet Hosts", RFC 1123, October
1989 (specifically, section 5.3.6 "Mailing Lists and Aliases").
[7] H. Lachman, "LDAP-based Routing of SMTP Messages: Approach used
by Netscape", <draft-ietf-asid-email-routing-ns-00.txt>, March 1997.
[8] T. Howes, M. Smith, "An LDAP URL Format", RFC 1959, June 1996.
[9] J. Myers, "SMTP Service Extension for Authentication",
<draft-myers-smtp-auth-04.txt>, November 1996.
[10] ($-encoding)
[11] J. Galvin, S. Murphy, S. Crocker, "Security Multiparts for
MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October
1995.
Also S. Kent, "Privacy Enhancement for Internet Electronic Mail:
Part II: Certificate-Based Key Management", RFC 1422, February 1993.
9.0 Author's Address
Bruce Steinback
Netscape Communications Corp.
501 East Middlefield Rd. Mail Stop MV-029
Mountain View, CA 94943
USA
Phone Number: (415) 937-3466
Email: bruces@netscape.com
| PAFTECH AB 2003-2026 | 2026-04-24 03:31:45 |