Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utcs!mnetor!seismo!lll-crg!caip!brl-adm!brl-smoke!smoke!stef@nrtc-gremlin.ARPA
From: stef@nrtc-gremlin.ARPA
Newsgroups: net.mail.headers
Subject: Re: A protocol for distribution lists and their managements
Message-ID: <2145@brl-smoke.ARPA>
Date: Sat, 12-Jul-86 02:47:21 EDT
Article-I.D.: brl-smok.2145
Posted: Sat Jul 12 02:47:21 1986
Date-Received: Sat, 12-Jul-86 10:27:43 EDT
Sender: news@brl-smoke.ARPA
Lines: 55

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