Sorry for the rather lengthy message but maybe it's of interest for others too: On Tue, 03 Oct 89 11:20:08 EST you said: >To my knowledge I didn't send any distribute any list update job from >BNLVMA. Do you have the spooled output from listserv that you could send >me to show the specifics. Is it possible that the file I included on my >mail to the lstsrv-l listserv group from bnlvma, not bnlvmxa, caused a >distribute? Currently bnlvmxa is an xa system that is connected to bnlvma >via ctca and is run as a guest. Some day (probably not for a year) >the nodename may change. Since bnlvmxa is currently just under test, >it is not in bitearn nodes or rscs direct and should be known only >to bnlvma. I apologize for any inconvenience the incident may have >caused you; I am interested in knowing more of the details, so I can >understand what triggered the list update job. Well, you did "hide" BNLVMXA. What BNLVMXA knows about the world I can't tell from here but I guess that at least YALEVM is accessible. What happened? I'll try a short explanation: 1) You defined one or more global lists on your XA-LISTSERV (xal). (Global means you didn't restrict access by means of a Service= or Confidential= keyword.) --- OR --- (this is what happened in your case) xal determined that it should send the monthly checksum report (every 30 days or if the global variable LASTFWD in LSVLDELT is empty) Remark: if you still have the console you will find something like Executing WAKEUP event... LSVLDELT and after that: .... the monthly checksum record is being sent. 2) Your xal sent out the checksum for distribution to the backbone LISTSERVs (every backbone holds a list of lists and some have also the database function enabled). In case of changes in the lists it would also have sent the appropriate DEL, HDR and REP commands. 3) Your xal forwarded the information to the nearest backbone (YALEVM). 4) YALEVM got the information together with an indication that it was the first backbone and that it should DISTRIBUTE the job to the other backbones. 5) Update jobs have a checksum added to ensure the integrity of the information. Since BNLVMXA didn't exist yet the checksums didn't match. When this happens the original sender is requested to send a complete list of it's list so that the checksums can again get in synch. So each backbone sent this kind of request to [log in to unmask] 6) BNLVMXA isn't known to RSCS the tiny little jobs got rejected and eventually transferred to the postmasters. You'll find part of the console below. That's the magic with LISTSERV - once started it does things on it's own :-). (lines starting with #### are comments ...) *----------------- Listserv's Console ----------------------------* #### here comes the DIST job ... 3 Oct 1989 08:24:22 Processing file (4562) from LISTSERV@CEARN 3 Oct 1989 08:24:23 From LISTSERV@CEARN: DIST2 FROM=LISTSERV@BNLVMXA I=Y FORW(VI A) HOST(24 24) TO LISTSERV AWIIMC11 LISTS (...) 3 Oct 1989 08:24:24 Distributing file "X-LUPD JOB" from LISTSERV@BNLVMXA... 3 Oct 1989 08:24:24 File "X-LUPD JOB" distributed to [log in to unmask] * File "X-LUPD JOB" from LISTSERV@BNLVMXA has been sent to you. 3 Oct 1989 08:24:25 File "X-LUPD JOB" distributed to [log in to unmask] 3 Oct 1989 08:24:25 End of distribution. #### The X-LUPD is processed ..... 3 Oct 1989 08:24:26 Processing file (4563) from LISTSERV@BNLVMXA 3 Oct 1989 08:24:27 From LISTSERV@BNLVMXA: X-LUPD FWD=NO DATE=1989100223:00:01 H DR=YES > CKS 760574276 #### The checksums don't match ... 3 Oct 1989 08:24:31 >>> Checksum error (0 vs the expected 760574276) <<< #### ... and a Refresh request is sent ... 3 Oct 1989 08:24:32 Refresh request sent to [log in to unmask] >>> 135 peered lists 3 Oct 1989 08:24:38 GLOBLIST FILE has been successfully updated. #### ... which is rejected by RSCS RDR FILE 4565 TRANSFERRED FROM RSCSEARN 3 Oct 1989 08:24:39 Sent information mail to REICHETZ@AWIIMC11 3 Oct 1989 08:24:41 RSCS message: FILE 4565 (4565) REJECTED -- INVALID DESTINATI ON ADDRESS