I may have a possible solution to the peering/distribute problem, as long
as I haven't overlooked some detail that will make this amount to nothing
more than wasted net-band-width :-) ...
 
DISTRIBUTE is superior for file/mail delivery over simple peering, simply
because simple peering cannot take advantage of any other non-peered
servers in the delivery stage.  PEERS= is superior for straightforward
user sanity; ie, its a nice 'warm fuzzy' to get your mail from the same
place you send it to, and being able to reply, plus having the nearest
point of service selected for you.
 
But... there is this 'peer linking' risk.  But... with the distribution
option of Mail-via now, WHY BOTHER LINKING THEM AT ALL?!?
 
If each participating 'peer' (ie, one that has a list header and lets
you subscribe) has a comprehensive 'Peers=' keyword in its header, there
is no need to link anything, nor define peer servers in the list (of
course, assuming Mail-via=Distribute).
 
A user subscribes.  The subscription is *already* automagically forwarded
to the nearest peer (from Peers= mind you, not peer entries in the list).
 
A user submits to a list.  You build a distribute job for your local list,
and since this is the *original* point of origin, you create a special
distribution job for *all* the 'Peers=' servers (excluding yourself) which
contains whatever necessary tag/flag/note/name/form/dist it takes to let
the peer know it has already been 'peer exploded'.
 
Bingo... no peer links, no loops, straightforward distribute with implied
peers.  And just in case, you can check to see that you don't send anything
to a 'Peer Distribution List' entry in the list.
 
You didn't have anything planned this weekend anyway, did you Eric?  :-)
 
<Jeff>
******************************
*  "Waste is a terrible thing to mind."
*    -- Sanitation Engineers Guild
******************************