On Wed, 19 Nov 2014, Nicholas Boel wrote to Joe Delahaye:

 NB>> Or if you wanted, you could try routing all net 3534 traffic
 NB>> through him:

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

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

 JD> Yeah, but how would that work for those that I have a direct link 
 JD> with?

 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.

the order depends on the software... some want general routes listed first and
the more specific ones further down... this because they work from top to
bottom and update or change their internal table as they read the routing
list... others want the spcific stuff at the top because they drop out as soon
as they find a match which fits the message being handled... this makes them
faster than the others which build the table from the top down...

 NB>> Lastly, check to make sure the CRASH bit isn't set on that
 NB>> passthrough mail for the point. If it is, that's why your system
 NB>> is trying to send it directly to the point. THAT, I believe,
 NB>> would be a configuration error on the person's system that
 NB>> originally created the message(s), as Synchronet is handling it
 NB>> properly, but you just don't have a direct link setup with that
 NB>> point, so your mailer doesn't know what to do with it.

 JD> If the Crash flag is set, not much I can do about it

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

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

 NB> I just ran into something like that recently as well (if that's
 NB> your case). I'm not sure if it's an error on binkd's part since it
 NB> doesn't use an actual nodelist (with knowledge of hosts and
 NB> whatnot), and has no routing of it's own.. or the fact that people
 NB> shouldn't be setting the CRASH bit on netmail unless it has been
 NB> discussed with your uplink and a direct link has been setup to that
 NB> system.

 NB> I'm leaning towards a bit of both of those reasons, but probably
 NB> more of the first, since I'm sure other mailers handle that just
 NB> fine. BUT, if you have routing in both your tosser and your mailer,
 NB> it can probably be pretty easy to mess things up even worse, so.. I
 NB> digress. :)

actually, the tosser would take precedence if it is packing the mail... the
only time a mailer would do routing is if it is dynamically packing the mail
itself... i've done a combination of both over here in years past... some stuff
i had my tosser packing which took it out of view of the mailer other than the
PKTs themselves... since it could not see the packed messages, there was no
problem... other messages were left in the mailer's netmail area (which is
separate from the BBS netmail directory!) so the mailer's dynamic packing would
work with them based on the active mailer event... in some of my mailer events,
Z2 netmail (for example) would be routed to a Z2 system i connected with while
in other events the same netmail if it were still here would be routed to a Z1
system to pass on toward the destination Z2 system...

)\/(ark