Ok, let's consider the situation in technical terms. A piece of mail is basically a header plus a body. When LISTSERV sends mail to a peer list, it adds special tags to the header. These tags do not appear on mail sent to non-peer subscribers. However, the header is still there, and if this non-peer subscriber happens to be a list, it can still know the actual origin of the mailfile etc. A file is basically a body without header, but with a small tag attached to it telling you the address of the sender. When LISTSERV sends a file to a backbone LISTSERV, it creates a kind of "header" (ie the DIST crap) to identify the file origin and destination. When the file is sent to a final user, this crap is removed and only the body is sent. The little tag points to the LISTSERV userid, not the original sender. If this final subscriber is a list, it is in deep trouble. The NJE address is a LISTSERV machine, which indicates that this file doesn't come from a user but from some list (which one?? No way to know). If the list is not peered, there is no problem since it cannot point back to the original list (whatever that original list may be), so the file can be distributed normally. Now if the list is peered, it probably points back to the original list and a loop will occur if the file is redistributed. This is what caused the dreaded DIST2 loop, and what caused the duplicata on NODUPD-D. Note that the file will always be sent with DIST header if the destination node's LISTSERV is on the backbone, in which case there is no problem. The DIST2 loop stemmed from the fact that UIUCVMD is on the DIST1 backbone but not on the DIST2 one. Solutions: 1. Rule out that non-backbone sites are not allowed to get peer lists, unless these lists have "Files= NO" in effect. You seem to think that this is unacceptable, so let's forget about it. 2. Rule out that non-backbone sites are forced to accept DISTRIBUTE jobs that contain ONLY recipients for their own site. This makes it possible to always send a DIST job and solves the problem PROVIDED THE DESTINATION NODE'S LISTSERV IS REGISTERED. I'm afraid people who want DISTRIBUTE off want it all the time, but maybe they could concede that if there are only local recipients... 3. Force a DIRECT send of the file to the destination site if the destination userid is a peer list and the destination LISTSERV is not on the backbone. Then the NJE address can be inspected to "cut off the source branch". You're going to have a loop if the peers are improperly linked. Note that besides the loop problem, you are in trouble if INFORM=MAIL is specified by the file sender. In that case, if the destination list is not on the backbone, it's going to get a raw copy of the file plus the standard notification mail. If it is in the backbone, DISTRIBUTE will not actually send anything to the list userid so it will be ok. Comments? Eric