On Wed, 19 Nov 2014, Nicholas Boel wrote to mark lewis:

 NB>>> ROUTE_TO 1:3534/12 1:3534/ALL

 ml> obvious typo 3*6*34 but it doesn't matter for this example ;)

 NB> Yep, typo. My apologies.

no problem ;)

 NB>> I *think* it would take preference on the direct links before the
 NB>> routed ones. So, if a direct link is specified, it would be send
 NB>> direct. Then "ALL" links not specified otherwise, would be routed
 NB>> through Mark's system.

 ml> the order depends on the software...

 NB> We're talking about Synchronet's sbbsecho *specifically* here.

i know that but...

 NB> No other software.

actually, irex was in the conversation, too... that's where the old routing
table was... that's the table i was talking about converting over... if irex's
table is top-down and sbbsecho's table is bottom-up, then flipping the irex
table over will probably be a close starting place...

 NB> While one uses echocfg, the output it creates in sbbsecho.cfg is 
 NB> completely out of order.

i don't know what you mean by "out of order"... we've used echocfg on max's
synchronet once or twice and things were not as we expected to see them,
true... but that didn't cause things to operate majorly different than we
desired... we did, though, manually edit the sbbsecho.cfg file to conform to
our expected layout ;)

 NB> I choose to edit sbbsecho.cfg manually, and keep it in order. 
 NB> Therefore I'm letting him know what I think happens based on that 
 NB> information.

no problem there :)

 NB> [ explanation of what other softwares do trimmed ]

 NB>> Except inform the original sender not to set the CRASH bit on 
 NB>> mail going to that point, or any other system that you haven't 
 NB>> specifically setup for that.

 ml> can't do that if they are crashing the mail to the imtermediate 
 ml> link... crash works in several ways... in some software it means 
 ml> to go right now, period... in other software it means to go as 
 ml> soon as it is qualified in a mailer event... in either case, it is 
 ml> up to the intermediate system to ignore the crash bit in the 
 ml> message and only work with their local settings for the next 
 ml> intermediate system in the path toward the destination... if the 
 ml> local settings are crash to the next system, then the pkt will be 
 ml> crashed otherwise it will wait until normal processing takes 
 ml> effect and the mailer sends it onwards...

 NB> I'm only letting him know how sbbsecho handles those. I don't 
 NB> think it's right, either.. but Rob seems to say it's performing 
 NB> exactly how it is supposed to according to specs.

it may be that the question isn't being phrased clearly? i don't know... i've
been reading the synchronet areas but haven't caught much on this... that's
kinda why i prefer support stuff were confined to one central area... the
firewall i support has IRC and forum support areas and most of the time we're
referring folks to the forums where the information already resides or at least
more eyes can look over the problem and data presented...

 NB> I've tried already. If you care to test it and make sure it's not 
 NB> doing what it's supposed to, and then bring it up to him once 
 NB> again.. by all means feel free to do so. Instead, I've worked 
 NB> around it.

we'll have to see what happens... it is 04:20 and i've been up for 2 hours
already for no reason... i hate just waking up and then not being able to go
back to sleep... it is much too early for c0ffee or hot chocolate or tea...

)\/(ark