Fix 16E-003O  is now  available from LISTSERV@SEARN  (note that  the last
character in a fix  ID is always a letter - 'o' in  this case, not zero),
with the  corresponding source  code update  available as  16E-003A. This
"fix" introduces support for  automatic suppression of duplicate postings
to a  given distribution list, thus  providing a solution to  the problem
experienced recently  by the  LSTSRV-L and  INFO-VAX lists,  among others
(fortunately  for the  network, the  posting that  was duplicated  to the
INFO-VAX list contained only blank lines and all 200 copies were rejected
by the  peers running release  1.6; unfortunately, the peers  not running
1.6 did distribute it).
 
With  16E-003O,  the  body  of  each incoming  message  is  inspected  to
determine whether or not the message has been recently posted to the list
and,  if so,  it is  returned unprocessed  to its  originator. Since  the
headers are  not taken into  account and each  of the peers  (rather than
just  the  initial  one)  is   performing  the  verification,  a  message
erroneously posted to all the peers of a given list (for instance because
the sender thought these were  independent lists covering the same topic,
rather than the  very same list) will be distributed  only once, assuming
none  of the  copies  is delayed  long enough  to  fail being  considered
"recent" when it is received.
 
An interesting  side-effect is that  this will  stop most of  the mailing
loops  known  as  "burps  loop"   (LISTSERV  sends  posting  to  FOO@BAR,
MAILER@BAR sends  a reply to  the list with "Subject:  Message processed"
and message text of "Your message has been processed by the BAR gateway."
- in  other words,  the mailer  in question  generates a  delivery notice
whose sole  purpose is to express  its satisfaction at having  been fed a
piece of electronic mail, without  allowing the human reader to determine
which  mail  message is  being  referred  to);  unless the  "burps"  text
contains a  time stamp or  suchlike, it will  be distributed to  the list
only once, thus stopping a potential mailing loop.
 
Another  new  function  introduced   by  16E-003O  is  message  integrity
verification for  peered lists.  Those peers which  are running  with the
16E-003O code  applied will  automatically detect  any corruption  of the
message on  its way  between the  sending and  receiving peers;  in other
words, if 'NICELIST@FOO'  sends a message to its  'NICELIST@BAR' peer and
the message gets corrupted by some broken  RSCS or MAILER on its way from
FOO to  BAR, LISTSERV@BAR will detect  it (provided both FOO  and BAR run
with  16E-003O) and  forward the  message to  the list  owner instead  of
distributing it. If  there are pre-16E-003O peers in the  path, they will
not perform  any verification  themselves but will  not prevent  BAR from
checking the data coming from FOO.
 
Finally, the amount of extra disk space required for this new function is
approximately 4k for the software and 4k  for a new data file; unless the
postings  are  exceptionally  large,   the  CPU  overhead  is  negligible
(compared to the time it normally takes to distribute a posting).
 
  Eric