In fact, the  situation only gets tricky when you're  dealing with peered
lists. If  you have  a unique list,  it will take  the first  posting and
reject any  subsequent duplicate. Of  course the sender might  wonder why
messages are duplicated, and he's not the only one wondering :-), but the
other subscribers will never know about the problem.
 
Now let's say you have a peered lists with 3 hosts, A--B--C. Murphy's law
being what it  is, the duplication will not occur  between the poster and
A, but  between A and B.  From the point of  view of A, the  situation is
perfectly normal,  it got one copy  and distributed it, then  never heard
about it  again. B  on the other  hand got  20 copies from  A, so  it has
processed  one  and returned  19  to  the  sender,  who now  wonders  why
LISTSERV@B  is complaining  about  something which  he  (the sender)  had
posted to LISTSERV@A in the first place - obviously, the software must be
broken in some way :-)
 
That was the "simple" case where  all the peers involved are running with
16E-003o. Now let's assume B is running the old logic: it gets 20 copies,
it distributes 20. A never gets them back since they were all coming from
A; C does get 20 copies.
 
Case 1: C doesn't run 16E-003o. Well the sender will never know there was
a problem,  nor will the list  owner. Half of the  subscribers will start
complaining about  getting 20 copies  of everything, the other  half will
wonder why nobody has called the asylum  yet, the list owner will be at a
loss as to which part of the  user population he should believe and what,
if any, he should do about it (the answer is: get B and C to run 16E-003o
:-) ).
 
Case 2:  C runs 16E-003o.  We have  basically the same  situation whereby
some of  the recipients get 20  copies and some don't,  except the sender
will find out about  the problem. After a week or so  the users will have
learnt all the gory details and  the B recipients will start demanding to
be moved to A  or C so that they can stop getting  all that junk mail. In
other words, the users will demand that peer B be upgraded or removed; if
peer B is running 1.5o, the situation  gets more tricky as it is unlikely
that it  will be upgraded  within a reasonable  amount of time.  The list
owner will then have to decide whether  or not he wants to keep the peer,
based on a real-world problem which  is, admittedly, not the fault of the
staff at B and for which they  there is easy solution, even with the best
goodwill in the world.
 
  Eric