🚀 go-pugleaf

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.