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
|