For lists where mail-via=Dist2, and that should be most lists, although
I'm not sure it's the default yet, LISTSERV attempts to pass the mail on
to the LISTSERV nearest the user or the BITNET gateway to their domain.
So, list traffic at INDYCMS might be passed to PURCCVM for most
recipients, since PURCCVM is closer to most of them than INDYCMS.
PURCCVM might in turn pass them to UICVM, the next LISTSERV for most of
BITNET (from Purdue's perspective).
 
At UICVM a lot of traffic splits off:  Internet traffic.  UICVM hosts an
INTERBIT site, an official gateway between BITNET and INTERNET.  Even
though INDYCMS might have facilities to mail directly to the Internet,
LISTSERV ignores that and sends to the official gateway at UICVM.
(Other LISTSERVs use other INTERBITs closer to where they are.)
 
If the net-clogs are beyond UICVM's LISTSERV, then advocating changes to
Internet addresses might be wise, if there aren't specific other
gateways in BITNET which LISTSERV would try to use.  However, UICVM's
LISTSERV sometimes is a gating factor:  if UICVM is getting too many
spool files, that LISTSERV will take itself off-line until things
improve.  Under those conditions, not even mail to the Internet will
move; it's being held with mail to BITNET while UICVM waits to clear
up.
 
Also, I'd imagine that many (if not most?) systems with both BITNET and
Internet addresses have told the net about these equivilencies.  I think
LISTSERV treats those Internet addresses as their BITNET equivilences.
For example, if I sign up as [log in to unmask], LISTSERV will send
to me as if I'm [log in to unmask], because LISTSERV knows
vma.cc.nd.edu=IRISHVMA.BITNET.
 
Still with me?  :-) My point is, don't bother advocating Internet
addresses over BITNET addresses.  In many cases, LISTSERV won't be
fooled, and in other cases, the gateway LISTSERV will try to use might
still be behind a balky network node.
 
Hope this helps,
Nick
 
* [log in to unmask]
* [log in to unmask]