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