>
> For a moment, consider a problem that could very well be a software
> development project for your machine.  You will be creating a program that
> retrieves mail sent to various mailboxes and redistributes that mail out
> to users on a list of addresses associated with that particular mail box.
> The requirements are as follows:  1. the original sender of the message
> must be identified  2. the name of the list itself must be identified so
> that automatic logging mail user agent programs can save the messages in
> the proper place  3. the name of the person to who the mail is addressed
> must be in the header since an SMTP transaction is not being used  4. a
> place to send rejection mail is identified so that such rejections can be
> directed to other that the whole list.  Now, how would UMASS design such
> a facility.  If this can be defined and documented, I'm sure it would be
> used.  Currently, requirement number 4 is not there and a method of
> recognizing rejections in "standard" format is used.
This is the well known LISTSERV problem. BTW: it does not only
exist in the RFC world, it exists even in the X.400 world, too:
 
When you an create a mailing and conferencing system in a centralized
way you can easily create sending user agents that:
 
determine whether an address is a "distribution list",
send copies to each recipient (this can be doen in an optimzed
way if you are in ONE system.)
determine whether a distribution list has some other attributes
like "append a copy to archive data set ....." etc etc.
 
Now: There are two different problems:
1: The simple redistribution of a message to other people.
   To my opinion this should be done at the sending sites
   user agent (at least virtually). I.e the
   receiving people should not be able to distinguish
   whethere the user had entered the list of all names in
   the list or the listname.
 
   Creating any visible difference will soon raise the
   question why that service cannot be enhanced to do
   something else, i.e. conferencing.
 
2: Computer conferencing is something else:
   Original version are centralized:
   You start with a dislogue to a server, then browse thru
   the conference, append new contributions etc.
   If you start and distribute this using RFC822 mail
   as a protocol to retrieve or contribute data you soon
   get many many problems when you try to contact
   existing implementations that started with 1)
 
-----
What to do with rejection notices?
If you use SMTP in ARPA you do not have a problem returning
the answers (you are in a dialogue). Only NON-SMTP transport
protocols have that problem. Now: What do we have in BITNET?
If a server machine talks to another server machine (or user)
and transfers MAIL, you can interprete the RSCS tag as
target for a rejection message (to a certain extent).
 
Trying to implement that now in the already existing chaos of
BITNET/EARN would require much work. If we would start and define
a document stating the protocols: How may servers would
use it:
 
What if some MAILER sends a message to a KERMSRV and KERMSRV
returns an error message which may in turn be interpreted
as a message which creates and error which ......
 
There are hundreds of places where people use the network
and the gateways to the network in arbitrary ways.
 
(end of chat)