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)