Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!caip!brl-adm!brl-smoke!smoke!Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA Newsgroups: net.mail.headers Subject: A protocol for distribution lists and their managements Message-ID: <2091@brl-smoke.ARPA> Date: Thu, 10-Jul-86 16:18:27 EDT Article-I.D.: brl-smok.2091 Posted: Thu Jul 10 16:18:27 1986 Date-Received: Sat, 12-Jul-86 04:02:39 EDT Sender: news@brl-smoke.ARPA Lines: 221 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.