>  NB> Point taken. Basically _all_ mail goes through you, correct?    
      
    > NO! i get a huge amount of mail that janis' machine doesn't see /before/    
    > mine... no ZC truly has _ALL_ mail going thru their system... yes,   
    > it /may/ happen, but it is not dictated by policy or anything else...   
      
    NB> And where does it go /after/ your machine?    
      
   that depends on which way it is headed... and also which /type/ of mail it   
   is... you haven't specified which is being discussed, yet ;)   
      
   but, in the case of echomail, a lot of it goes no further than my machine when   
   it arrives from another machine... some gets passed on to other machines but   
   no where near as much as what comes in from my main echomail feed(s)...   
      
    NB> If it's to the NAB, then my question above still holds truth to    
    NB> it. It doesn't matter how it gets where it needs to go, I was only    
    NB> referring to the fact that in order for it to get dispersed to the    
    NB> general public of Fidonet, it goes through them at some point. Is    
    NB> this not true (netmail aside, of course)?   
      
   ahhh so we're talking about echomail... right now that may be true... at one   
   time there were two or three backbones in fidonet... two of them based in Z1   
   and the other had distribution hubs in numerous zones with... but we /still/   
   need to be specific about where things are and which direction they are   
   headed... read on...   
      
   no one has ever said that you must pull your echomail from anywhere in your   
   zone... indeed, they used to try to tell folk they had to pull echomail from   
   their net's NEC but that was quickly proven wrong... if you pull your mail   
   from whatever distribution system is in used in Z2 or Z3 and you chit-chat   
   with someone who also pulls from there, then you will not see the NAB systems   
   listed in the PATH of those messages between you two... if i happen to read   
   the same area and want to interject something into your conversation, then you   
   will see at least one NAB system in the PATH of /my/ messages because i am   
   connected to a NAB system for the huge majority of my echomail... then,   
   depending on the path to that distribution system over there, there may be   
   another NAB system listed... if someone else is making the link between the   
   two distribution systems, then you'll also see their system listed...   
      
   the same thing goes for regional areas... it is not likely that they are   
   available on the NAB backbone... they /might/ be made available by a NAB   
   system but only by special request that is verified by looking in the nodelist   
   to ensure that the requesting system is in the region the regional echo is   
   for... if regional echos are not carried by a NAB system then you won't see   
   them listed in the PATH... zonal echos are also in the same situation...   
      
   FWIW: here's what the distribution path of this particular area looks like...   
      
      
   3634/12   
    À123/500   
      Ã140/1ÄÂ120/544   
      ³      ³ Ã120/545.3   
      ³      ³ À120/546   
      ³      À7105/1   
      Ã250/100ÄÂ138/392   
      ³        À154/10   
      Ã261/38   
      ³ Ã230/150ÄÄ230/0   
      ³ Ã320/119   
      ³ ³ À203/0ÄÄ203/2   
      ³ À712/848ÄÄ633/267ÄÂ633/267.1   
      ³                   À633/267.7   
      À387/22   
      
      
      
   don't worry about the seenbys... they're not part of this discussion and when   
   the traffic crosses zonal boundaries, they are stripped out anyway to prevent   
   systems from not seeing the posts... consider if 1:123/456 and 2:123/456   
   exist, which they could very easily... since seenbys (and paths) are only 2D,   
   the zone is lost... if the seenbys weren't stripped, then the other system   
   would not see posts by the one because the net/node is already in the   
   seenbys...   
      
   yes, the PATH and SEENBYs should have been updated years ago to 3D   
   (zone:net/node) and 4D (zone:net/node.point)... 5D is different domains which   
   is othernets and thus must use another way of hopping the fence so that proper   
   information is retained so that netmail responses can travel back across the   
   fence...   
      
   )\/(ark   
      
    * Origin:  (1:3634/12)