On Fri, 21 Jul 89 15:09:12 GMT Mark's message (some of which follows) was
forwarded to me from the EARNUCD account.
> ...
>It's to cut down on problems like the one Bill Sklar mentioned recently,
>where the non-delivery messages go back to the poster (who cannot do
>anything about them) instead of the list owner (who can).  Now, that
 
I think this is the answer to a different question.  Bouncing to the list
causes the non-delivery messages to be propagated to scores of people
who can do nothing about it, rather than just one (the poster, in Mark's
example.  If the reason for non-delivery persists,
then further non-delivery messages are created and propagated netwide.
 
>could be done by setting Sender: to some other address, such as that
>of the list owner or a special error mailbox, but neither carries the
>information that the mail is associated with the list (which some of
>us want to have).
 
Leonard Woren has commented on this point.  No reason not to use the
TO field.  Leonard also identified the opportunity to make savings in
bandwith and processing overhead.
>
>As I said to Bill offlist, the problem is that RFC822 never envisioned
>a system like LISTSERV, so LISTSERV has to make the best of a hostile
>environment.
>
>--Mark
 
I really have a problem with this last paragraph.  LISTSERV generates
mail headers which at least masquerade as RFC822 headers;  I would
prefer to say 'which *are* RFC822 headers', but who knows?  Rice MAIL
generates similar headers.  These headers are used because they are
well-defined and understood, and RFC822 contains clear prescriptions
for how the various fields should be used.  This allows mail
implementations running in different environments to interwork.
I suppose I don't need to tell everyone about the benefits of
standardization?
 
Now, RFC822 actually predated the Revised LISTSERV by some four years,
and the earlier LISTSERV by two years or so.  Moreover the 'Internet
community' has been using mailing lists for quite some number of
years very successfully, albeit without the clever features of
Revised LISTSERV, of which the one most visible to the end-user is
of course auto-subscription.  An increasing number of VAX/VMS nodes
in BITNET/EARN/NETNORTH/... are using PMDF to provide Internet-style
mailing lists.  It seems to me that there is a well-established and
far-from-hostile environment in which LISTSERV is increasingly
apparent as the maverick on account of its peculiar use of the
SENDER field.  This will be all the more so, as the BITNET II
implementation advances, and Internet styles of operation are
adopted on the growing number of TCP/IP hosts.
 
As I understand the history, the original (Hernandez) LISTSERV
used to enter 'LISTSERV@node' in the SENDER field for all lists,
and the receiving application, Rice MAIL, was unable to retrieve
sufficient information from the mail header to identify the
appropriate notebook for logging the message.
 
When the Revised (Thomas) LISTSERV was developed, its author
realized that Rice MAIL could retrieve the necessary information
from the SENDER field, and that inserting the list address in this
field would make life ever-so-much easier for the end user.  I don't
mind saying that this is something of which I take advantage all the
time, and find very useful.
 
However, LISTSERV's peculiar use of the SENDER field is becoming one
of the more significant causes of mail loops.  I know of three this week.
 
If you look at the code in LSVXMAIL EXEC, you can see that Eric Thomas
is indeed aware of this, and has built in some
heuristics to overcome the problem.  I have had to extend these from
time to time at IRLEARN in order to deal with specific sources of
rejection messages, and I understand that Eric has some ideas for
enhancing the heuristics in some future version.
 
It seems to me that it is not a good solution to address a problem
caused by an unfortunate design decision simply by burning more machine
cycles, even if the decision seemed a good one at the time (and it did).
 
I've already voiced some agreement with Leonard Woren.  I wonder what
problems arise (if any) from his proposal.
 
Niall