Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA (07/10/86)
INTERNET has a defined standard for messaging (RFC821, RFC822 etc.)
but has no defined standard for distribution lists and their management.
Within the AMIGO project, we are working on the definition of such
a standard.
(AMIGO is a joint project between seven European countries.)
The purpose of this message is to outline the main parts of what should
be in such a standard, in order to get comments and ideas.
We are planning to define the standard in such a way, that it will
be usable both for distribution lists in mail networks based on
the X.400 and on the various variants of the internet mail protocols,
and also for connected distribution lists over gateways between
X.400-based and internet mail-based nets, since we expect that
this will occur often in the future.
(We are also working on distribution list facilities specifically
for use in X.400, but that work is not the topic of this message.)
In the text below, I will try to present our thinking in internet
terms rather than X.400 terms in order to make it easier to understand
for the participants of header-people.
One important goal of our standard is that any kind of nesting
of distribution lists should be possible without any risk of loops.
We think that such a standard should cover the following topics:
Distribution list expansion
---------------------------
During expansion, we are considering the following procedure of
modifying the header of a message when sent from one distribution
list to another. The procedure is illustrated by an example of
a message passing four distribution list expansions from the
original sender to the final recipient:
Input from original sender to DL-1 (the first distribution list):
SMTP-sender: Original sender
SMTP-rcpt: DL-1
From: Original sender
To: DL-1
Output from DL-1:
SMTP-sender: DL-1-request (=auditor of DL-1)
SMTP-rcpt: DL-2
Resent-from: DL-1
From: Original sender
To: DL-1
Output from DL-2:
SMTP-sender: DL-2-request (=auditor of DL-2)
SMTP-rcpt: DL-3
Resent-from: DL-2
From: Original sender
To: DL-1
Output from DL-3:
SMTP-sender: DL-3-request (=auditor of DL-3)
SMTP-rcpt: DL-4
Resent-from: DL-3
Resent-to: DL-2
From: Original sender
Output from DL-4:
SMTP-sender: DL-4-request (=auditor of DL-4)
SMTP-rcpt: Final recipient
Resent-from: DL-4
Resent-to: DL-2, DL-3
From: Original sender
To: DL-1
In x.400-terms, "SMTP" above is replaced by "P3", "Resent-" by
"Forwarded IPMessageHeader" and the rest of the fields by the
inner "IPMessageHeader".
This procedure could formally described as follows:
- Add the name in the Resent-from field to the Resent-to field
if that name is not already in any of the recipient fields.
- Put the name of the expanding list in the Resent-from field.
- Put the name of the auditor of the list as SMTP-sender.
The advantage with the procedure shown by the example above
is that all the distribution lists, through which the message
passes will be included in the header, enabling efficient loop
control.
Loop control
------------
With the procedure described above, three kinds of loop control
will be possible, and *all* three should be implemented:
(1) When receiving a message, do not accept it if the name of
the DL is in the Resent-from or Resent-to fields.
(2) When expanding a list, do not forward the message to those
members of the list which are in the "To", "From", "Resent-to",
and "Resent-from" fields.
(3) Store the Message-ID-s of passing messages in a store of
at least two weeks validity. Do not expand a message if
its ID is in that list.
Note: If the message lacks a Message-ID, the list should
add such an ID, computed by a check-sum method. (In X.400,
if the IPMessageID lacks an OR-name part, such a part should
be added using the P2.originator, or, if that is lacking,
the P1.originator).
Question: Why not put the name of the recipient in the "Resent-to"
fields of outgoing messages from a list.
Answer: (a) For a large list, this would create a very large header
with all the list members.
(b) Loop control of type (1) would then not be possible.
Stored propoerties of a distribution list
-----------------------------------------
A distribution list should store the following information about
itself:
- Name of the list
- Textual description of the list
- Whether anyone is allowed to send messages to be expanded by the
list. Values TRUE or FALSE.
- List of those who are allowed to send messages to the list (if
the previous value was FALSE).
- List of those who are to recieve messages from the list.
- Name of the auditor of the list, who is to receive conformations
sent to the list, and who will be SMTP-sender (=P3.originator)
of outgoing messages from the list.
- Optional name to which messages are to be forwarded if sent by
someone who is not allowed to send via the list. (Typically this
can be the moderator of a moderated list. It need not be
identical with the auditor.)
- Charging algorithm valid for the list. Note that charging the
sender is probably only reasonable for lists with a restricted
list of allowed senders. Note that charging the sender in case of
nested lists is not easy.
- Whether this is a moderated list.
- Whether this is a digested list. (Digesting could, for non-
moderated lists, be done automatically by the DL software.)
Operations on the list
----------------------
The following list-management operations should be standardized.
It should be possible to transmit them as ASCII-text in the body
of messages. (Other forms, like direct-connection forms, of these
operations may also be possible.)
*Add member*: Adds one or more new members to a list.
*Delete member*: Deletes a member from a list.
*Get description*: Gets description and attributes of the list.
All the attributes described above should be retrievable. It
should be possible to input attributes to this operation to
control what data about the list which is requested. Note that
getting a list of all or some of the members of the list is
a special case of this operation.
*List lists*: Will return a list of all or some of the distribution
lists managed on a certain host.
*List personal mailboxes*: Will return a list of all or some of
the personal mailboxes managed on a certain host.
*Create list*: A newly created list will get default values on
all attributes. The creator will then if needed change these
with the operation "modify attributes".
*Modify attributes*: A general operation for modifying any
of the attributes of the list.
*Delete list*.
Access control
--------------
We are suggesting that in the simplified standard we are defining,
the rules for access control will not be standardized. However,
access control will certainly exist, and might cause some of
the operations described above, for some senders, not to be
performed or be performed only partially. For example, most people
will only be allowed to add and delete themselves from a list,
and a "list lists" operations may not return the names of local
closed lists.
Coding
------
The operations should be coded as ASCII text in the body of messages
sent to a special mailbox called "AMIGO-server" or something like
that, which should exist on each host.
Coding can be done either as human-writeable text (so that anyone
can code such an operation) or as machine-formatted text (requiring
anyone who wants to send such an oepration to have availabe a
program "directory user agent" to produce them).
A further question is whether several operations can be coded in
one message, and if so, if they can refer to each other, e.g.
one operation asking for a list of list names, and a second
operation asking for the description of each of them.stef@nrtc-gremlin.ARPA (07/12/86)
I am bothered by several things in your proposed standard. One is the excessive structure it implies, and the implication that all hosts in the entire ARPA Internet and the X.400 Internet will all have to implement list managers that behave as you specify. If that is a requirement, then it is not going to be implemented at many sites. As I see it, and have repeatedly pointed out once or twice each year for the last 5 years now, list distribution is something that must occur at the User Agent Level, with the list distributror operating with the "Authority of a User Agent". I essence, when a message arrives at a distributor, it is regarded by the MTA as having been delivered. If it cannot be delivered to the distributor, then a failure should go to the originator. If it is delivered, and is received by the distributor, then failures should not go to the originator. So we see that "delivery" suggests that it is now in the hands of a UA level entity. Furthermore (and Jacob's proposal includes this idea) the distributor opens up the 822 headers, or the P2 header, and modifies it in some way. According to all the rules, this is never to be done by any MTA, so this must be done by an entity operating with the authority of a UA. When the message is ready to be RePosted, then it reappears to the MTA as a new item, with indications to return failures to the "new originator" which is our "distributor". So, as I see it, if this is really a UA doing something to RePost modified versions of received mail, it can do anything it wishes in the way of adding legal new fields or changing the content of old ones to accomplish its objectives. In RFC822, it is possible to simply add fields with new unique names, such as Distributor-ID: and Distribution-Item-ID: to unambiguously identify the distribution agent and the item that is being distributed. I would then use this information to contol looping. If you see your own ID come back, or your ecognize your own item ID in a new arrival, you can take whatever actions seem correct, such as delete forthwith, or refer it to a human for evaluation, or something. (Distributor's Choice) In short, I would suggest finding a way to totally separate distribution indicators and controls from MTA operations, to keep from getting them entangled with each other. The distributor standard should accept both RFC822/821 and X.400-P1/P2 to be immutable as given, and work the problem entirely at the UA level, assuming UA authority as I have described it above. I don't think all that structure is needed in this simplified model. Also, I don't think that list management tools should be standardized in the same document that standardizes on the mechanisms of distribution 9given some list) and the mechanisms for loop control. These are two very differenet kinds of standards, and they should be kept totally separate so one can be replaced without affecting the other. The modularity concept is central to the whole idea of these kinds of standards. Cheers - Stef
Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA (07/14/86)
(a) Can you explain more fully what is wrong with using Message-ID-s for loop control? I can see one problem. And that is which message-ID to use for multi-body messages, and also finding the innermost message-ID when X.400 messages have been converted into RFC-style messages according to RFC987, where the inner message has become part of the text body of the RFC822 message. But those problems, I believe, are solvable. Another problem is that some people or message systems may be misusing Message-ID-s, for example by changing a message (e.g. by adding text) without changing the ID. But that happens so rarely that I do not see it as a problem. (b) If we want conformance with X.400, we cannot put anything into the IPMessageHeaders than is allowed by X.400. It would be possible to add extra header fields by putting them into the text of the message, but I intentionally tried to avoid adding extra header fields when a field occuring in both X.400 headers and RFC822 headers could be used reasonably well. (c) I agree with you that "RESENT-" may not be good to use, primarily because RFC987 does not recommend it in X.400 gateways. Instead, RFC987 recommends putting inner bodies as text, so I guess that is what one should do instead. This may cause some trouble for a DL handler to distinguish between text which are headers of forwardes messages, and text which is really text, but that problem is probably solvable.
Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA (07/14/86)
The only part of our proposal which it would be very valuable if all list expansion tools implemented is the loop controls, both the creation of loop control info and the use of it for loop controls. Apart from that, our proposal is intentionally written such that it could incorporate existing activities. Even those existing lists which are not willing to implement loop control could be handled, by just ensuring that they will not be part of any loops. I agree with you that it would be much neater to add RFC822 header fields for loop control. However, I do not believe this is possible. The reason for this is that the proposal should work also under X.400, and since CCITT seems to be firmly determined to put distribution lists in the P1 layer, there is very small changes of getting them to accept new P2 facilities for handling mailing lists.
stef@nrtc-gremlin.ARPA (07/14/86)
I am glad to hear that you intend for the main force of the Distribution List Standard to apply to the Looping Controls. I suggest that you make this more obvious, with the "Required Optional Facilties" set forth as being suggestions only. As for your problem with 822 vs X.400, I suggest that you do what you must to comply with X.400, and let that reflect into new RFC822 headers to be dealt with in the ARPA-X.400 Gateway, which I believe will not prsent any difficulties on the 822 side, or the X.400 side. RFC822 is extensible (Good Idea) so lets use the built in extensibility to solve the problem without requiring any changes to anyting on the ARPA Internet side. If CCITT and ISO want to muck about and make it difficult to do things at the P2 level, they are only hurting their own products and services. I am constantly amazed at how the European CCITT/ISO folks seem to feel a strong need to regulate what I put in my headers. Stef
Tommy_Ericson_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA (07/16/86)
I completely agree that distribution should be handled in UAL, not in MTL. I do however heard another story of who is advocating DL in MTL, possibly also with respect to restrictions on P2. But I still think that we can influence the CCITT/ISO work. Tommy