Network Working S.E. Hardcastle-Kille
Group ISODE Consortium
INTERNET-DRAFT July 1992
Expires: January 1993
MHS use of the Directory to support distribution lists
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.
Internet Drafts may be updated, replaced, or obsoleted by other
documents at any time. It is not appropriate to use Internet Drafts
as reference material or to cite them other than as a "working draft"
or "work in progress."
Please check the I-D abstract listing contained in each Internet Draft
directory to learn the current status of this or any other Internet
Draft.
Abstract
This document specifies a procedure for managing distribution lists
using the directory. This is an extension of the mechanism defined in
X.400 [MHS88].
This draft document will be submitted to the RFC editor as a protocol
standard. Distribution of this memo is unlimited. Please send
comments to the author or to the discussion group
<mhs-ds@mercury.udev.cdc.com>.
INTERNET--DRAFT Directory Distribution Lists July 1992
1 Model
This section describes the operation of Distribution Lists, including
use of the OSI Directory. There are two models of distribution list
expansion:
1. Following the standard
2. P2 level expansion
The standard mechanism needs no explanation here. The P2 model is
almost the same. The differences are
o The MTS originator is changed to a list manager.
o The MTS identifier is changed (doing the first without the second
is not really sensible).
o In terms of the model, the message is delivered, then the list is
expanded outside the MTS, and then the message is resubmitted.
Essentially, this makes list expansion a ``firewall''.
o DL Expansion history is submitted with the new message.
In practice, the P2 expansion is very close to the standard.
Disadvantages of the P2 approach are:
o It is non-standard
o It provides less information for elimination of duplicates
Features which can be argued as an advantage of either approach are:
o The only service which is lost, is the ability to return to the
originator errors which occur after expansion.
The argument in favour of this is that this is sometimes a useful
service.
The argument against this is that where such a service is
required, it is better to achieve this by originating UA expansion
of the list.
Expires: January 1993 Page 1
INTERNET--DRAFT Directory Distribution Lists July 1992
The advantages of the P2 level approach are:
o A cleaner model (the author's unbiased view)
o Where a list has a member on RFC 822 or X.400(84), errors will
always be sent to the list maintainer (they will go to the
originator if the standard is followed).
o Support for lists in the context of X.400(1984) and RFC 822.
o After the expansion, parameters (e.g. message priority) come
under the control of the list manager (whose policy can take the
initial parameters into consideration).
o It gives a basis for extension to more powerful variations of
distributed lists, where some additional processing is done at the
expansion point (e.g. moderated lists).
In cases where lists follow the UA level model, they must correctly
deal with other MTAs which follow the standard model.
2 Identifying Lists
It is important to be able to identify that an object is a list either
from its directory name, or from its O/R Address, and to be able to
determine the other form.
o When the distinguished name is used, it is identified as a list
from the object class of the entry (mhs-distribution-list) The
mhs-or-addresses attribute in the list entry should point at the
O/R Address form.
o When the O/R address form is used to identifies a list, it will
also be of object class listUA, as defined in Figure 1, and the
attribute distributionListName will point at the distinguished
name.
Lists may have aliases pointing to them. It seems very desirable to
establish a part of the DIT to hold well known lists, to facilitate
the location of such lists. For example, the list of the WG which is
discussing this might have an alias:
Expires: January 1993 Page 2
INTERNET--DRAFT Directory Distribution Lists July 1992
_______________________________________________________________________
listUA OBJECT-CLASS
SUBCLASS OF uA
MUST CONTAIN {distributionListName}
::= oc-list-ua
distributionListName ATTRIBUTE
SUBTYPE OF uAName
SINGLE VALUE
::= at-distribution-list-name
_____________Figure_1:__O/R_Address_of_Distribution_List_______________
CN=MHS-DS, OU=Lists, O=Internet
3 Schema Definitions
The use of the OSI Directory to provide distribution lists defined in
X.400 is a suitable basis for Distribution lists. The extensions
defined_in_this_specification_are_given_in_Figure_2.___________________
IMPORTS
mhs-distribution-list, mhs-dl-members, mhs-or-name-syntax;
FROM {X.402}
distributionList OBJECT-CLASS
SUBCLASS OF mhs-distribution-list
MAY CONTAIN {dlPolicy,
dlAccessControl, 10
dlErrorsToName
dlDynamicMembers}
::= oc-distribution-list
dlErrorsTo OBJECT-CLASS
SUBCLASS OF ua
dlErrorsToName ATTRIBUTE
WITH ATTRIBUTE-SYNTAX mhs-or-name-syntax
MULTI VALUE 20
Expires: January 1993 Page 3
INTERNET--DRAFT Directory Distribution Lists July 1992
::= at-dl-errors-to-name
dlPolicy ATTRIBUTE
WITH ATTRIBUTE-SYNTAX DlPolicy
SINGLE VALUE
MATCHES FOR EQUALITY
::= at-dl-policy
DlPolicy ::= SEQUENCE {
operation-mode [0] ENUMERATED { 30
standard(0),
p2-level(1)},
strip-trace [1] ENUMERATED {
strip-all(0),
leave-all(1),
leave-first-element(2)} DEFAULT leave-first-element,
futher-expansion-permitted [2] BOOLEAN DEFAULT TRUE,
conversion-prohibited [3] MappedBoolean DEFAULT original,
priority [4] ENUMERATED {
original (1), 40
low (2),
normal (3),
high (4)} DEFAULT low
supress-warnings [5] BOOLEAN DEFAULT TRUE,
submit-dn-only [6] BOOLEAN DEFAULT FALSE,
public-expansion-ok [7] BOOLEAN DEFAULT TRUE,
disclosure-of-recipients [8] MappedBoolean DEFAULT false
}
MappedBoolean ::= ENUMERATED { 50
original (1),
false (2),
true (3) }
dlDynamicMembers ATTRIBUTE
WITH ATTRIBUTE-SYNTAX DLDynamicMembers
::= at-dl-dynamic-members
DLDynamicMembers ::= SEQUENCE {
base DistinguishedName, 60
filter Filter }
dlAccesControl ::= ATTRIBUTE
WITH ATTRIBUTE-SYNTAX ENUMERATED {
Expires: January 1993 Page 4
INTERNET--DRAFT Directory Distribution Lists July 1992
no-specific-controls (0),
add-and-delete-self (1) }
::= at-dl-access-control
_____________________Figure_2:__List_Definitions_______________________
The additions to the standard are:
o Definition of an address to which errors are returned.
o Definition of an attribute to control the policy of list
expansion.
o Definition of a means for dynamic list expansion.
A list need not have any members. List management interfaces should
ensure that this is not done accidentally.
The dlErrorsToName attribute defines the O/R Name of where list errors
should be directed. Typically, this might follow the ``list-request''
convention. The O/R Address may be omitted from the O/R Name. In
this case a directory entry of this name must exist to identify the
O/R address. The object class dlErrorsTo is created for users created
solely for this purpose.
Note that the access control for managing the membership of the list
is dealt with by the normal Directory access control mechanisms. The
owner of the list may be identified by the ``owner'' attribute. This
identifies the user to whom queries about the list (e.g., requests to
be added) should be addressed.
The policy of list expansion is represented by the dlPolicy attribute.
This provides the following options:
operation-mode This defines whether expansion of the list should
follow X.400, or be P2 level as defined here.
strip-trace This only affects UA level expansion. If trace is
stripped, as full UA level expansion would require, the original
submission date is lost. Therefore, some or all trace may be
resubmitted.
futher-expansion-permitted This controls whether further DL expansion
Expires: January 1993 Page 5
INTERNET--DRAFT Directory Distribution Lists July 1992
of this list is allowed.
conversion-prohibited This allows the list to override the conversion
prohibition of the original message.
priority This allows the priority of the original message to be
overridden. Typically, the priority of all messages will be set
to low.
supress-warnings Don't send delay warnings to the error return
address.
submit-dn-only If the DN (Distinguished Name) is present, do not
submit the O/R address. This forces submit time directory name
lookup.
public-expansion-ok This allows any directory-capable MTA to expand
the list (not just the MTA responsible).
disclose-recipients Allows disclosure of recipients to be controlled
by the list manager. This will generally be set to false.
The dlDynamicMembers attribute defines a means for expressing members
of a list based on the directory search operation. This might, for
example, be used to define a list based on userclass of student. It
may be more useful to define a list in this way, than to explicitly
list members. This is expanded by a subtree search using the filter1.
If there is a sizelimit error, the message should be rejected, with an
appropriate error message. If there are no matches, the message
should be discarded. A local administrator should be warned.
The dlAccessControl attribute allows distribution list specific access
control to be enabled. In particular, it allows a distribution list
to be operated with add/delete self capability. To achieve this, the
supporting DSA will need to recognise the syntax of the mhs-dl-members
attribute and be able to recognise that the distinguished name in this
matches that of the bound UA.
There is a user requirement to annotate the membership of a list.
This (standard) approach does not provide a sensible means to achieve
----------------------------
1. It has been suggested that single level search is an alternate
option.
Expires: January 1993 Page 6
INTERNET--DRAFT Directory Distribution Lists July 1992
this, as there is no means to add per-user information.
4 Operation of Distribution Lists
Each distribution lists is represented as an Entry in the Directory.
They will be given names relative to an Organisation or Organisational
Unit. A set of sibling lists will usually be supported by a set of
MTAs.
The members of a list (mhs-dl-members) will be of three types:
o Directory Name only. This will force submission-time expansion.
o OR Address only. This will be for users not in the directory.
o Both, which should become increasingly common. The Directory Name
is the ``managed'' bit, with the OR Address derived as an
optimisation. The list management tool should be able to update
O/R Addresses. User interfaces should facilitate input of RFC 822
addresses.
The permission to submit (attribute mhs-dl-submit-premissions) is
handled in the following manner:
individual In the obvious way.
member-of-dl The members of the identified distribution list are
allowed to submit messages to the list. Where the identified
lists contains lists as members, this right is not conferred to
members of those sublists.
pattern-match As described in X.400. This might be extended slightly
after initial experience.
member-of-group Here, the property ``members'' of the name given
identifies users allowed to submit messages. This might be an
expensive calculation, as in many cases, the Directory Name of the
submitter will not be present. It might be sensible to avoid this
one for now.
If the attribute is omitted, this is interpreted as public rights:
Expires: January 1993 Page 7
INTERNET--DRAFT Directory Distribution Lists July 1992
that is any user may submit messages to the list
Note: It may be useful to extend submit permissions in a manner
analogous to DynamicMembers, in order to have dynamic control of
submission rights.
References
[HK92] S.E. Hardcastle-Kille. MHS use of the directory to support
MHS routing, April 1992. Internet Draft.
[MHS88] CCITT recommendations X.400 / ISO 10021, April 1988. CCITT
SG 5/VII / ISO/IEC JTC1, Message Handling: System and
Service Overview.
5 Security Considerations
Security considerations are not discussed in this INTERNET--DRAFT .
6 Author's Address
Steve Hardcastle-Kille
ISODE Consortium
PO Box 505
London
SW11 1DX
England
Phone: +44-71-223-4062
EMail: S.Kille@ISODE.COM
DN: CN=Steve Hardcastle-Kille,
O=ISODE Consortium, C=GB
UFN: S. Hardcastle-Kille, ISODE Consortium, GB
Expires: January 1993 Page 8
INTERNET--DRAFT Directory Distribution Lists July 1992
A Object Identifier Assignment
_______________________________________________________________________
mhs-ds OBJECT-IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1) private(4)
enterprises(1) isode-consortium (453) mhs-ds (3)}
list OBJECT IDENTIFIER ::= {mhs-ds 5}
oc OBJECT IDENTIFIER ::= {list 1}
at OBJECT IDENTIFIER ::= {list 2}
10
oc-list-ua OBJECT IDENTIFIER ::= {oc 1}
oc-distribution-list OBJECT IDENTIFIER ::= {oc 2}
at-distribution-list-name OBJECT IDENTIFIER ::= {at 1}
at-dl-errors-to-name OBJECT IDENTIFIER ::= {at 2}
at-dl-policy OBJECT IDENTIFIER ::= {at 3}
at-dl-dynamic-members OBJECT IDENTIFIER ::= {at 4}
at-dl-access-control OBJECT IDENTIFIER ::= {at 5}
_______________Figure_3:__Object_Identifier_Assignment_________________
Expires: January 1993 Page 9