LSTSRV-L Archives

LISTSERV Site Administrators' Forum

LSTSRV-L

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Chris Lewis <[log in to unmask]>
Wed, 4 Aug 1993 01:35:07 -0400
text/plain (122 lines)
On Aug 3, 23:54, Dave Gomberg wrote:
} Subject: Re: Re SCIFAQ-L errors
} Well, Chris, I can see a release date is clearly beyond what you can
} manage.  As such, I think you should look for a replacement for LISTSERV.
} Maybe MINDMANAGE will cover what you need.   Dave
 
Una?  You willing to switch to MINDMANAGE? ;-)
 
There is a gross misunderstanding here.  I had better repeat the
explanation of what is happening.
 
I have several FAQs that I manage.
 
Periodically (weekly, biweekly, whatever) a cron job that I have
written posts the FAQs via USENET news software to my USENET
"neighbor" machines.  Which in turn retransmit it to their
"neighbors".  There are 10's of thousands systems that run USENET
news.  This is essentially "broadcasting".  Once I've sent it
out to my neighboring USENET sites, I've essentially lost control
of where it goes.  I certainly haven't sent it to a LISTSERV.
 
Somewhere out in cyberspace someone decides that it would be useful,
nice, neat, a good thing, to gateway some postings into mail.
Or other newsgroups.  Or fidonet.  Or GEnie.  Or Compuserve.  Or Waffle.
Or PostalUnion. Or LISTSERV.  They do so, almost always without the
knowledge or permission of the originators - not that permission
wouldn't be granted, it's just that it's impossible to notify everybody
when you gateway a whole newsgroup, or all FAQs or whatever.  So,
people usually don't even try to notify the originators.  Even of FAQs.
 
With me so far?
 
Now, let us say that there is a transmission error somewhere out
in USENETland+random gatewaying elsewhere.  Where do you send
the error messages?  In a broadcast network, where the originator is
not specifically "ordering" distribution to specific sites, it
makes no sense, and is in fact a gross mistake, to send notifications
back to the originator.  In a broadcast network, there are times where
this can cause extreme deluges of mail on the originator.  Most news
software recognizes this philosophy, and will not send bounces
back to a non-local originator under any circumstances [keep quiet
mathew ;-)].
 
It's the administrator of the site encountering the problem that should
receive the notifications.  It isn't under *my* control that my message
got to the system with the error.  I don't want to hear about
transmission problems on other sites - because it ain't my problem
and there's nothing I can do about it.
 
LISTSERV (as do most other list servers) already recognizes this
principle.  For example, if I send a message to a LISTSERV, it ain't
my fault if one of the LISTSERV subscribers disappears or the destination
site died, or any of a myriad of other transmission errors occur -
it is the list-owner's concern.  So, the LISTSERV goes to great lengths
to prevent transmission errors being bounced back to the originator
of a message - it tries very hard to ensure that only the list-owner
(or designate) gets the bounces - because it is that person who
can do something about it.
 
Let me give one clear example of where originator bounces are extremely
stupid.  PostalUnion is a MAC gateway package.  If PostalUnion has
a problem of any kind (and it's pretty stupid software - ie: it balks
at more than 1024 messages in a "group"), it bounces a "NDN" (whatever
the hell that means) back to the originator.  Most of the time the
originator can't tell what message it was complaining about, what the
NDN means (the body of the message is gibberish), where the NDN
was transmitted from, or even who to contact for an explanation.  Even
if they knew what it meant, there's nothing the originator can do about
it - because these bounces are usually because of disk space depletion
or hitting internal implementation limits.  Actually, the PostalUnion
administrator's are mostly clueless on this too.  Still worse, PostalUnion
has even been known to post these NDNs back into USENET!  Which could
lead to news loops.
 
Now to our specific case: to shield LISTSERV subscribers, LISTSERV
will detect when mail loops or mailers going ga-ga occur by
detecting and refusing to propagate duplicates.  This is a *good*
thing.
 
However, this is one area where LISTSERV doesn't follow the "don't bug
the originator with bounces" rule.  It will send to the originator a
bounce if the article is a duplicate.
 
1) Originator-notification of a duplicate to a message originating in
   news is flat-out wrong.  Eric agrees with this assessment,
   but implementing something to detect that the message originated in
   news is difficult given current standards and existing practise, and
   impossible to get 100% right.
 
2) I also contend that originator-notification of non-news-originating
   duplicate is useless (and possibly dangerous) when the duplication
   is of the mailer ga-ga/mail loop variety.  The originator is unlikely
   to be able to do anything about it.
 
3) originator-notification of originator-induced duplicates is useful.
   Not particularly though, for the message did get through didn't it?
 
4) I contend that (3) is not useful enough to warrant implementing
   originator-notification if you cannot distinguish between (3) and
   (1) or (2).
 
5) As a stopgap kludge, FAQ writers can diddle the contents of their
   articles every time they send it if there are no other changes.  But
   this is solving the wrong problem.  The article is a duplicate.
   It is supposed to be.  If my FAQ poster went nuts, the LISTSERV
   will faithfully retransmit every copy - you don't want that do you?
 
   Secondly, this does not address the problem with non-FAQ postings
   and news regurgitations.
 
I respectfully suggest, therefore, that LISTSERV eliminate the
originator-notification of duplicate messages.  It is quite
reasonable that duplicates be dropped.  It makes sense that
the list-owner may want to see them (and contact the originator
if it looks as if it's originator-induced).  But the originator
should not be automatically notified of duplicates.
 
--
Chris Lewis; [log in to unmask]; Phone: Canada 613 832-0541
Psroff 3.0 info: [log in to unmask]
Ferret list: [log in to unmask]

ATOM RSS1 RSS2