25 Oct 16 18:11, you wrote to me:   
      
    ml>> ahhhh... ok... i don't know that that is important in the grand scheme   
    ml>> of things but i noticed it and didn't see one in paul's example...   
      
    rc> And taking it out, doesn't seem to make it export.   
      
    ml>> FWIW: FTN echomail is not a hierarchy like so many were lead to   
    ml>> believe over the years... if you have only one connection, sure, that   
    ml>> may be viewed as your "feed" or "upstream" but if you have several   
    ml>> connections to an echo, they're all "feeds" and there's no real   
    ml>> "upstream" or "downstream"...   
      
    rc> Well ummm.. why would you have a feed of the SAME echo from different   
    rc> nodes????   
      
   reread my first statement after FWIW... there is no real hierarchy in   
   echomail...   
      
    rc> I can see if echo a is an echo on my system on not fed via NAB so   
    rc> nodes come to me to get it...   
      
   that is private distribution...   
      
    rc> BUT why would they also want to say add binkd as well??   
      
   because they can... because they want redundant feeds to ensure they get all   
   posts and get them as fast as possible... if any route breaks, the mail still   
   flows and only the broken system is out...   
      
   you mention the NAB... those three systems are a fully connected polygon...   
   there was, at one time, the Z1B... there were five or six systems (at least)   
   that were fully connected... today, there is what is loosely called the   
   FidoWeb... there is no top level set of systems in a fully connected   
   polygon... instead each system may connect to as many other systems as they   
   want for redundancy... some systems may be connected to ten or more other   
   systems which may be connected to those same ten or maybe not... the big thing   
   for today's echomail is that the tossers can be configured to /not/ strip   
   seenby lines from messages crossing zonal boundaries... there are no more   
   duplicate nets in fidonet so seenby stripping is not necessary and the seenbys   
   prevent duplicate messages from being sent out... used in conjunction with the   
   MSGID, it should be pretty fool proof...   
      
    rc> Especially in 2016, where for the most part the delay is the cycle on   
    rc> which a node runs their exporting process...and/or TZ for the users.   
      
   the processing cycle is different... on my system, i process mail once an hour   
   because there's a lot of work done on it... some times it takes a couple of   
   minutes while other times it takes 15 or 20 minutes... that's why i tell   
   systems polling here to poll after xx:30... note that polling is not   
   delivering your newly written outbound mail... polling is empty and you're   
   only looking to pick up waiting mail... other than that, unless i have a   
   system on hold for some reason, there's little to no reason to poll my system   
   at all... the mail will be delivered as soon as it is ready... i currently   
   have only two systems on hold and that only because i cannot connect to   
   them... i don't know why and their operators can't seem to figure out how to   
   get set up so that i can but they (supposedly) have callers connecting to   
   their systems... why they can get one working and not the other is beyond me...   
      
   )\/(ark   
      
   Always Mount a Scratch Monkey   
   Do you manage your own servers? If you are not running an IDS/IPS yer doin' it   
   wrong...   
   ... I wondered why the basketball was getting bigger. Then it hit me!   
   ---   
    * Origin:  (1:3634/12.73)