> > I fully agree with Harry Williams on this.  The existing standards just
> > DO NOT cut it.  A NEW standard to augment what we have now is an absolute
> > MUST!!!
>
> I disagree.  Let me ask this:  how many loops have you seen that don't
> involve LISTSERV?  (I've seen one.  It was mostly my fault, with a
> little help from UCLA/Mail and from UCBJADE.  I fixed it.)
>
> I know this has been discussed before, but... can anyone convince me
> that having LISTSERV put
>    Sender:  LISTSERV@node
> instead of
>    Sender:  listname@node
> in outgoing mail will not solve a major fraction of the problems?  The
 
The other element involved is identifying the list so that the mail can be
filed properly.  The NEWSGROUP: solution can be a way to solve this as well.
Mail programs already use SENDER: just because NEWSGROUP: is apparently
(someone check into this, please) NOT an official standard and its format
is not formalized.
 
> NONCONFORMING mailers that do not conform to the requirement to send
> rejection messages to the Sender if present should be cut off.  It
 
If that's the field we agree on.  I can't find in the RFC where it says
to use this one that way.  Can someone cite and RFC/page?
 
> will be necessary to be mean.  How about this idea: (not totally
> facetious!)  LISTSERV keeps a "good guys" list, of nodes where it
> trusts the mailer to be reasonable.  Anytime it is about to send mail
 
I don't have space for that table, I only have a few thousand spare
cylinders.
 
> to a node that isn't in the "good guys" list, it "pings" the target
> mailer first with a test message to a (hopefully) invalid userid, and
> watches to see which address the rejection comes back to.  If it
 
How looooooooooooooooong will it be watching?
How MANY messages will have to be kept?  How will it recognize which
message should be sent out when it gets an "OK" rejection?
 
> comes back to any address other than the test Sender: address, add the
> node to a "bad guys" list and make one attempt to send a notification
> to Postpostma@node about his nonforming mailer, and refuse to send any
> more mail there.  SUBSCRIBE time might be a better time to do this
> check.
 
It already sends the subscribee a notice that at least SOMEONE should
get if it comes back.
 
> > Finally, such a standard should take into consideration the impact of
> > mailing lists OTHER THAN LISTSERV, especially those on ARPANET.
>
> Funny you should mention this.  Have you >ever< seen a loop on an
> arpanet mailing list?  I haven't.  (And BTW, it seems to me that most
 
They don't implement hardly any of the nice features, either.  Their
lists are fudged into SMTP.  Look at the headers.  The original TO:
is still there, so how did it get to YOU?  YOUR address was know by
SMTP which is only good as long as the mail stays in the SMTP "mailbag".
 
> arpanet mailing lists send the sender a copy of his own posting.  I do
> not like the fact that LISTSERV doesn't do this.  I realize that this
 
They don't allow peers and have only the limited DIST function that SMTP
has.
 
> is the first line of defense against loops, but wouldn't be necessary
> if the Sender: was not unreasonable.)  This is why I claim that the
> loop fix must involve some alteration to LISTSERV's *outgoing* mail,
> not more/better screens, etc, or more mail headers.  I have not seen
> any argument to convince me that a Sender: of the post-to address is
> reasonable.  This is what causes 99% of the loops that I've seen.
 
There are actually 4 uses for 3 existing fields and which goes to which
are ambiguous.  whenever any 2 of the 4 are the same, you can get away
with certain (false?) assumptions.  When mail crosses "boundaries" of
these assuptions, trouble develops.
 
> /Leonard
 
It seems in the final analysis that the problem might stem from the
fact that BITNET is a network that essentially does NOT use SMTP and
certainly is not using TCP/IP.  To make LISTSERV work like lists on
Arpanet would require implementing SMTP everywhere.  I then question
why two standards like that even need to exist; why not merge them into
one uniform standard?  Many standards as it is define more than one level
in one standard.  How many other networks do not use SMTP?
 
/Phil