Oh, but that is a bug in the loop detection algorithm. I had inadvertently assumed that the *name* LISTSERV puts in the "Sender:" tag would NOT be trashed by the mailer. Evidently I was wrong as the UMASS mailer trashed everything to only keep the USERID@NODE which LISTSERV was not able to recognize, unfortunate ly. I'll fix that in the next release. The PUT command for LINKSWT FILE was successfully processed at FRECP11 and BNANDP11 but seems to have been trashed at CEARN, there is probably a bug some- where. Well I never tested this before... Anyway I'll resend the file in the next shipment. Peter, what you suggest is not totally possible and/or can't completely solve the problem. LISTSERV will not send to ALL peers but to the nearest one, who will forward to the nearest, etc. The first server will assign a LISTSERV node- id to each of the recipients but keeps this information to itself: I was attemp ting not to place any information that could be recreated later in the jobfile. Well I could change that. But still, the nodes tables would have to be used. Let's say I distribute to X@CEARN, X@DEARN, [log in to unmask] LISTSERV@FRECP11 assigns the recipients to CEARN, DEARN and HEARN respectively, and forwards the file to CEARN. CEARN knows that X@DEARN is serviced by DEARN and X@HNYxxxx is serviced by HEARN but must still use its node table to determine that the file should only be sent to DEARN who will forward it later then. It is not possible nor desirable to prepare the complete "path" in the original server. First, it would take an *awful* lot of CPU time and would take a lot of space in the distributed job. And second, the nodes tables are more likely to be accurate near the places where changes have been made than somewhere else. Let's say that tomorrow Israel is unplugged from Italy and connected to Germany. Tables in the US will probably be incorrect but you can expect the DEARN and TAUNIVM tables to have been updated. So, it may help the problem to have the first server impose its list of "servers who will serve this or that person" but it's not a PERFECT solution and you may still have a few problems. A good solution is to add some error- recovery routines which would manage to distribute the file anyway, with a warning to the sender and postmaster though. Eric