@INTL 24:150/1 24:100/1
@INTL 24:150/1 24:100/1
@PID: Synchronet 3.17a-Win32 Nov 25 2017 MSC
@INTL 24:150/1 24:100/1
@TZUTC: -0500
@Via: 24:100/1 @20171127.233556.UTC SBBSecho 3
@Via: 24:24/1 @20171127.233839.UTC SBBSecho 3
Hiya Rob...
Not sure if this is right. When I create netmail at say 24:100/1 going to 24:150/1 and route it through 24:24/1 the message gets delivered properly BUT, when the person at 24:150/1 replies, it replies to the 24:24/1 address rather than the 24:100/1.
Here are the headers...
@INTL 24:150/1 24:100/1
@INTL 24:150/1 24:100/1
@PID: Synchronet 3.17a-Win32 Nov 25 2017 MSC
@INTL 24:150/1 24:100/1
@TZUTC: -0500
@Via: 24:100/1 @20171127.233556.UTC SBBSecho 3
@Via: 24:24/1 @20171127.233839.UTC SBBSecho 3
Why would routing change the originating address? With the way things are going now, a reply would be sent to 24:24/1 and just sit there.
Not sure if this is right. When I create netmail at say 24:100/1
going to
24:150/1 and route it through 24:24/1 the message gets delivered
properly BUT, when the person at 24:150/1 replies, it replies to the 24:24/1 address rather than the 24:100/1.
Here are the headers...
@INTL 24:150/1 24:100/1
@INTL 24:150/1 24:100/1
@PID: Synchronet 3.17a-Win32 Nov 25 2017 MSC
@INTL 24:150/1 24:100/1
@TZUTC: -0500
@Via: 24:100/1 @20171127.233556.UTC SBBSecho 3
@Via: 24:24/1 @20171127.233839.UTC SBBSecho 3
Why would routing change the originating address? With the way things
are going now, a reply would be sent to 24:24/1 and just sit there.
There were a couple of SBBSecho bugs fixed with routed netmail fairly recently.
If one of the hops is running an older version/revision of SBBSecho, that could
explain it.
That's the same issue I was having with zone 1 netmail that routed
through an older sbbs system. My node address was being rewritten to
that of the hub so I'd never get a response if someone
replied...unless I had an account on the hub in which case it would
stop there.
@INTL 24:150/1 24:100/1
@INTL 24:150/1 24:100/1
@PID: Synchronet 3.17a-Win32 Nov 25 2017 MSC
@INTL 24:150/1 24:100/1
@TZUTC: -0500
@Via: 24:100/1 @20171127.233556.UTC SBBSecho 3
@Via: 24:24/1 @20171127.233839.UTC SBBSecho 3
Those are technical control lines (aka "kludge lines"), not headers.
In any case, the "Via" lines were truncated. It'd be helpful to know
which revisions of SBBSecho 3 it went through.
I don't think you should have more than one "INTL" control line in a single message. Are these all taken from the the same message?
There were a couple of SBBSecho bugs fixed with routed netmail fairly recently. If one of the hops is running an older version/revision of SBBSecho, that could explain it.
Seems you may be missing a route statement for 24:100/1 on your hub.
Going from your system, it seems you have a proper route statement to route all
24:ALL traffic to 24:24/1, and then 24:24/1 has a proper route
statement for 24:150/1. However, if 24:150/1 sends a netmail and it
stops at 24:24/1, there must not be a proper route statement for
24:100/1 at the hub.
That's the same issue I was having with zone 1 netmail that routed
through an older sbbs system. My node address was being rewritten to
that of the hub so I'd never get a response if someone
replied...unless I had an account on the hub in which case it would
stop there. You should get your uplinks to update their SBBS and that should fix the issue, as Rob said.
Yes. The system that received it was a Mystic system so I'm not
really sure which end it is on now that I think about it.
There were a couple of SBBSecho bugs fixed with routed netmail fairly recently. If one of the hops is running an older version/revision of SBBSecho, that could explain it.
As you can see both the originating and routing versions are the
same.
I will route a netmail to another Synch system to see if sbbsecho is causing the issue or it's the way Mystic is forming their reply.
Re: routed netmail
By: Digital Man to Bill McGarrity on Mon Nov 27 2017 19:49:08
Hiya Rob....
@INTL 24:150/1 24:100/1
@INTL 24:150/1 24:100/1
@PID: Synchronet 3.17a-Win32 Nov 25 2017 MSC
@INTL 24:150/1 24:100/1
@TZUTC: -0500
@Via: 24:100/1 @20171127.233556.UTC SBBSecho 3
@Via: 24:24/1 @20171127.233839.UTC SBBSecho 3
Those are technical control lines (aka "kludge lines"), not headers.
In any case, the "Via" lines were truncated. It'd be helpful to know which revisions of SBBSecho 3 it went through.
OK... 24:100/1 is using:
SBBSecho 3.03-Win32 r3.61 Nov 25 2017 MSC 1800 invoked with options:
24:24/1 is using:
SBBSecho v3.03-Linux r3.61 Nov 27 2017 GCC 4.9.2 invoked with options:
I don't think you should have more than one "INTL" control line in a single message. Are these all taken from the the same message?
Yes. The system that received it was a Mystic system so I'm not really sure which end it is on now that I think about it.
There were a couple of SBBSecho bugs fixed with routed netmail fairly recently. If one of the hops is running an older version/revision of SBBSecho, that could explain it.
As you can see both the originating and routing versions are the same.
I will route a netmail to another Synch system to see if sbbsecho is causing the issue or it's the way Mystic is forming their reply.
Re: routed netmail
By: Accession to Bill McGarrity on Mon Nov 27 2017 21:39:30
Hiya Nick...
Seems you may be missing a route statement for 24:100/1 on your hub.
Don't think so... but let's see.
Going from your system, it seems you have a proper route statement to route all
Correct...
24:ALL traffic to 24:24/1, and then 24:24/1 has a proper route statement for 24:150/1. However, if 24:150/1 sends a netmail and it stops at 24:24/1, there must not be a proper route statement for 24:100/1 at the hub.
OK... under Linked nodes for 24:24/1's Route To entry I have: 24:ALL. If my mind is working correctly (granted at times it's void) if it processes the routing correcty outbound for all z24 nodes then it should process return mail to 24:100/1 as well.
The issue is on the other side when they're replying back to me. Their package is addressing the reply to 24:24/1, not 24:100/1 so it's getting hung up at 24:24/1.
As I told DM, I'll test it out sending netmail to another z24 node I know is running the latest version of sbbsecho and see if the problem is the same. It just may be Mystic that's not processing the control lines properly.
The issue is on the other side when they're replying back to me. Their
package is addressing the reply to 24:24/1, not 24:100/1 so it's getting
hung up at 24:24/1.
As I told DM, I'll test it out sending netmail to another z24 node I
know is running the latest version of sbbsecho and see if the problem is
the same. It just may be Mystic that's not processing the control lines
properly.
There should not be multiple INTL lines in a single message either. If you're seeing that, then someone's tosser is doing something wrong.
24:ALL traffic to 24:24/1, and then 24:24/1 has a proper route
statement for 24:150/1. However, if 24:150/1 sends a netmail and
it stops at 24:24/1, there must not be a proper route statement
for
24:100/1 at the hub.
OK... under Linked nodes for 24:24/1's Route To entry I have: 24:ALL.
If my mind is working correctly (granted at times it's void) if it processes the routing correcty outbound for all z24 nodes then it
should process return mail to 24:100/1 as well.
The issue is on the other side when they're replying back to me. Their package is addressing the reply to 24:24/1, not 24:100/1 so it's
getting hung up at 24:24/1.
As I told DM, I'll test it out sending netmail to another z24 node I
know is running the latest version of sbbsecho and see if the problem
is the same. It just may be Mystic that's not processing the control
lines properly.
OK.... just sent a netmail to another Synch system routed through
24:24/1. They're reply was addressed correctly back to 24:100/1
without changing it from 24:24/1.
I'm going to send another netmail to a non-Mystic/Synch board to see
if indeed the control lines are processed properly for a reply
netmail.
However, in say Fidonet you would have catchall statements after any direct links so that any unconfigured node numbers would go to your uplink. This rule doesn't apply when you are the ZC of your own
network though - since you don't have any uplinks.. only downlinks.
If indeed you are using 24:ALL on your hub system, where in the world
are you routing that statement to? ;)
Digital Man wrote to Bill McGarrity on 11-28-17 14:50 <=-
Re: routed netmail
By: Bill McGarrity to Accession on Tue Nov 28 2017 11:55 am
Re: routed netmail
By: Accession to Bill McGarrity on Mon Nov 27 2017 21:39:30
Hiya Nick...
Seems you may be missing a route statement for 24:100/1 on your hub.
Don't think so... but let's see.
Going from your system, it seems you have a proper route statement to route all
Correct...
24:ALL traffic to 24:24/1, and then 24:24/1 has a proper route statement for 24:150/1. However, if 24:150/1 sends a netmail and it stops at 24:24/1, there must not be a proper route statement for 24:100/1 at the hub.
OK... under Linked nodes for 24:24/1's Route To entry I have: 24:ALL. If my mind is working correctly (granted at times it's void) if it processes the routing correcty outbound for all z24 nodes then it should process return mail to 24:100/1 as well.
That sounds backwards to me. Instead, you should have a Linked Node
with an address fo "24:ALL" and a Route To value of "24:24/1" (or
whoever your uplink is).
The issue is on the other side when they're replying back to me. Their package is addressing the reply to 24:24/1, not 24:100/1 so it's getting hung up at 24:24/1.
As I told DM, I'll test it out sending netmail to another z24 node I know is running the latest version of sbbsecho and see if the problem is the same. It just may be Mystic that's not processing the control lines properly.
There should not be multiple INTL lines in a single message either. If you're seeing that, then someone's tosser is doing something wrong.
Accession wrote to Bill McGarrity on 11-28-17 16:52 <=-
Hello Bill,
On Tue Nov 28 2017 11:55:20, Bill McGarrity wrote to Accession:
24:ALL traffic to 24:24/1, and then 24:24/1 has a proper route
statement for 24:150/1. However, if 24:150/1 sends a netmail and
it stops at 24:24/1, there must not be a proper route statement
for
24:100/1 at the hub.
OK... under Linked nodes for 24:24/1's Route To entry I have: 24:ALL.
If my mind is working correctly (granted at times it's void) if it processes the routing correcty outbound for all z24 nodes then it
should process return mail to 24:100/1 as well.
No sir. Try setting your leaf node's route statement to route
everything 24:ALL
to 24:24/1. Then your hub system should have a separate route statement for each and every link you want a direct link with. So you would need
to route 24:100/1.ALL to 24:100/1.
The issue is on the other side when they're replying back to me. Their package is addressing the reply to 24:24/1, not 24:100/1 so it's
getting hung up at 24:24/1.
Since your hub system doesn't seem to have a valid route statement for your 24:100/1 leaf node, it would stop on your hub system and go no further.
As I told DM, I'll test it out sending netmail to another z24 node I
know is running the latest version of sbbsecho and see if the problem
is the same. It just may be Mystic that's not processing the control
lines properly.
It very well could be, however, it also doesn't seem like you're
routing netmail from your hub to your leaf node properly.
snip<=-
snip<=-
The one thing I don't understand is the FTC has guidelines on proper handling of Netmail and why aren't all packages using those guidelines. I am 100% satisfied that Rob and Synchronet follow those FTC guidelines properly.
Let me state, this issue just started happening and that for the past 9 months all netmail has been routed properly from all nodes within Sportnet using the config I originally setup from day one. As I've always done when an issue arrises is to discuss with Rob and offer him as much information as possible. As stated above, I've never had issue with routed netmail until this instance with a Mystic system. I've also tested this with another Synchronet system where they received routed netmail from 24:100/1, through 24:24/1 and their system used 24:100/1 as a reply address. Their message was then routed through 24:24/1 to 24:100/1 where I received it. My 'HUB' works but Mystic seems to be broken. I have forwarded this info to Rob so he can be assured it is NOT Synchronet's problem.
However, in say Fidonet you would have catchall statements after
any direct links so that any unconfigured node numbers would go
to your uplink. This rule doesn't apply when you are the ZC of
your own network though - since you don't have any uplinks.. only
downlinks.
warning will robinson! warning!
this isn't necessarially true... it depends on the network layout
That sounds backwards to me. Instead, you should have a Linked
Node with an address fo "24:ALL" and a Route To value of
"24:24/1" (or whoever your uplink is).
24:24/1 is the main hub for all nodes. Everything centers around that address. I do have a 24:all linked node in there as well with 24:24/1
as it's Route To.
No sir. Try setting your leaf node's route statement to route
everything 24:ALL
The leaf node (24:100/1) already has a Route To statement of 24:24/1
so all outgoing netmail will go to there first where it gets
distributed properly.
24:100/1 is a leaf off of 24:24/1 so why would those statements be
needed as I already have a Route To statement in the 24:100/1 config
that points to
24:24/1.
Since your hub system doesn't seem to have a valid route
statement for your 24:100/1 leaf node, it would stop on your hub
system and go no further.
Ofcourse it would as it's addressed TO 24:24/1 which it shouldn't be. That's the entire point. If I put a Route To statement in 24:24/1
that points to
24:100/1 then everything coming into 24:24/1 will be forwarded to 24:100/1.
The entire process had to do with a Mystic system that was looking at
the @VIA statements and addressing the REPLY to 24:24/1 rather than
the original sending address of 24:100/1. This issue was forwarded to James and he's already acknowledged the issue is probably Mystic's as
he's make changes to comply with
BBBS and their netmail issues.
The one thing I don't understand is the FTC has guidelines on proper handling of Netmail and why aren't all packages using those
guidelines. I am 100% satisfied that Rob and Synchronet follow those
FTC guidelines properly.
Let me state, this issue just started happening and that for the past
9 months all netmail has been routed properly from all nodes within Sportnet using the config I originally setup from day one. As I've
always done when an issue arrises is to discuss with Rob and offer him
as much information as possible. As stated above, I've never had issue with routed netmail until this instance with a Mystic system. I've
also tested this with another Synchronet system where they received
routed netmail from 24:100/1, through 24:24/1 and their system used 24:100/1 as a reply address. Their message was then routed through
24:24/1 to 24:100/1 where I received it. My 'HUB' works but Mystic
seems to be broken. I have forwarded this info to Rob so he can be assured it is NOT Synchronet's problem.
As per James, the author of Mystic....
I can't say for sure because I haven't looked at it yet, but its
probably an issue with Mystic. I just recently changed the way all of that works because of the way BBBS processes mail with its "security" option, and it breaks the way Mystic got the reply netmail address.
I don't think its a Synchronet issue, so you can probably pass what I
said back to Rob so he's not wasting his time chasing a non-existant
issue in Synchronet. If for some reason I am wrong I can follow back
up with you or him.
warning will robinson! warning!
If indeed you are using 24:ALL on your hub system, where in the world are you routing that statement to? ;)
in this instance, that is an execellent question! :)
Digital Man wrote to Bill McGarrity on 11-29-17 11:10 <=-
Re: routed netmail
By: Bill McGarrity to Accession on Wed Nov 29 2017 11:45 am
The one thing I don't understand is the FTC has guidelines on proper handling of Netmail and why aren't all packages using those guidelines. I am 100% satisfied that Rob and Synchronet follow those FTC guidelines properly.
The FTSC documents are written by volunteers and in many cases,
amateurs, so they can be hard to follow. Also, programmers, including
me, make mistakes.
Let me state, this issue just started happening and that for the past 9 months all netmail has been routed properly from all nodes within Sportnet using the config I originally setup from day one. As I've always done when an issue arrises is to discuss with Rob and offer him as much information as possible. As stated above, I've never had issue with routed netmail until this instance with a Mystic system. I've also tested this with another Synchronet system where they received routed netmail from 24:100/1, through 24:24/1 and their system used 24:100/1 as a reply address. Their message was then routed through 24:24/1 to 24:100/1 where I received it. My 'HUB' works but Mystic seems to be broken. I have forwarded this info to Rob so he can be assured it is NOT Synchronet's problem.
SBBSecho had a long standing (forever) bug, actually a couple, with routing netmail *through* it (it handled NetMail direct delivery just
fine and routing of local netmail just fine). I don't think many FTN
hubs used SBBSecho as their tosser so the problem was never reported to me. It wasn't until Nigel Reed was recently experimenting with routed NetMail that these problems came to light. They've been fixed in the current SBBSecho v3 development builds, but it's entirely possible that SBBSecho could be doing something *else* wrong with routed NetMails,
that I'm not aware of. The whole process of packetizing and routing netmail is not straight forward and the FTSC documents are pretty light
on this subject, so it's not surprising that some programmers
(including me) could get it wrong.
Accession wrote to Bill McGarrity on 11-29-17 13:39 <=-
On Wed Nov 29 2017 10:21:00, Bill McGarrity wrote to Digital Man:
That sounds backwards to me. Instead, you should have a Linked
Node with an address fo "24:ALL" and a Route To value of
"24:24/1" (or whoever your uplink is).
24:24/1 is the main hub for all nodes. Everything centers around that address. I do have a 24:all linked node in there as well with 24:24/1
as it's Route To.
24:ALL should *NOT* be used on your hub to route traffic to the same system!
Accession wrote to Bill McGarrity on 11-29-17 13:40 <=-
On Wed Nov 29 2017 11:45:00, Bill McGarrity wrote to Accession:
No sir. Try setting your leaf node's route statement to route
everything 24:ALL
The leaf node (24:100/1) already has a Route To statement of 24:24/1
so all outgoing netmail will go to there first where it gets
distributed properly.
It won't get distributed properly if your HUB system is using the
24:ALL catchall route statement. This should only be used by leaf nodes with an UPLINK. Your hub system doesn't have any uplinks, only
downlinks. So you need to route directly to all of your downlinks.
24:100/1 is a leaf off of 24:24/1 so why would those statements be
needed as I already have a Route To statement in the 24:100/1 config
that points to
24:24/1.
That statement definitely isn't needed, but that is the only place you should be using 24:ALL if you were to use it. It should NOT be used on your hub system
at all.
Since your hub system doesn't seem to have a valid route
statement for your 24:100/1 leaf node, it would stop on your hub
system and go no further.
Ofcourse it would as it's addressed TO 24:24/1 which it shouldn't be. That's the entire point. If I put a Route To statement in 24:24/1
that points to
24:100/1 then everything coming into 24:24/1 will be forwarded to 24:100/1.
Only if it is originally addressed to 24:100/1.
Right now it seems like your catchall 24:ALL on your hub system is
routing the mail back to your hub system (hopefully not changing the destination address in
the process).
Okay, you did your part in finding and letting people know of the
matter.
However, both Rob and myself have told you that 24:ALL should not be
used on your HUB system. Will you believe me now that my original statement was correct
in the first place?
I wasn't telling you what was broken, I was specifically trying to describe how
netmail routing works. The only reason you haven't run into a problem
is because you must have a direct route statement to your leaf node
above your catchall statement.
As per James, the author of Mystic....
I can't say for sure because I haven't looked at it yet, but its
probably an issue with Mystic. I just recently changed the way all of that works because of the way BBBS processes mail with its "security" option, and it breaks the way Mystic got the reply netmail address.
So the person you were dealing with obviously uses an ALPHA (or better yet, PREALPHA) version of Mystic, that is NOT recommended to use for a production system. Good thing you let James know about it!
I don't think its a Synchronet issue, so you can probably pass what I
said back to Rob so he's not wasting his time chasing a non-existant
issue in Synchronet. If for some reason I am wrong I can follow back
up with you or him.
I never said it was a Synchronet issue. I told you that using the
24:ALL catchall statement on your HUB is a very bad idea, and if you
miss one direct netmail config option with one of your links, any
netmails to said link will stay on your system and do nothing. Since
that catchall on your hub system is routing to yourself (back to your
hub system).
Rob has also confirmed this, so maybe you'll believe me now. ;(
warning will robinson! warning!
Warning what?
Have you heard of the TV show "Lost In Space"? One of the famous quotes is "Danger, Will Robinson!"
I know... that's deleted now. :) and all links are direct.
As stated, when you first brought it up I added it... saw it was going down in flames and removed it.
Nick, that last part was James' reply. I never said that you were
wrong. The original which started all this in motion was not the
24:All statement but a reply to a message originating from 24:100/1
being answered to 24:24/1. Being the netmail was sitting on 24:24/1, sbbsecho did exactly what it was supposed to do.
Never doubted you in the least. I think the problem was on how we
were looking at the problem... which is fine. I didn't have teh
24:ALL originally but added it thinking that's what you and Rob
wanted. It created issues so I removed it and everything is back to normal.
sbbsecho is preforming just as stated...
warning will robinson! warning!
Warning what?
Have you heard of the TV show "Lost In Space"? One of the famous
quotes is "Danger, Will Robinson!"
Have you heard of the TV show "Lost In Space"? One of the famous
quotes is "Danger, Will Robinson!"
Wonder what happened to that Billy Mummy?
Not sure he did any work after Lost In Space.
SBBSecho had a long standing (forever) bug, actually a couple, with routing netmail *through* it (it handled NetMail direct delivery just fine and routing of local netmail just fine). I don't think many FTN hubs used SBBSecho as their tosser so the problem was never reported to me.
SBBSecho had a long standing (forever) bug, actually a couple,
with routing netmail *through* it (it handled NetMail direct
delivery just fine and routing of local netmail just fine). I
don't think many FTN hubs used SBBSecho as their tosser so the
problem was never reported to me.
I use SBBS (naturally) and am a hub; I don't think routed netmail is a thing in Z1 anymore. It's just as easy to crashmail when we're all connected via TCP/IP.
Wonder what happened to that Billy Mummy? Not sure he did any work after Lost In Space.
Re: routed netmail
By: Digital Man to Bill McGarrity on Wed Nov 29 2017 11:10 am
SBBSecho had a long standing (forever) bug, actually a couple, with routing netmail *through* it (it handled NetMail direct delivery just fine and routing of local netmail just fine). I don't think many FTN hubs used SBBSecho as their tosser so the problem was never reported to me.
I use SBBS (naturally) and am a hub; I don't think routed netmail is a thing in Z1 anymore. It's just as easy to crashmail when we're all connected via TCP/IP.
I use SBBS (naturally) and am a hub; I don't think routed netmail is a thing in Z1 anymore.
It's just as easy to crashmail when we're all connected via TCP/IP.
no, actually it is not... try connecting to an link of your boss node
when you are a point... some mailers complain when the passwords
aren't right because they assume the point is the boss... some of us
have been working hard to ensure that routed netmail works properly...
why would you say that?? he is a very talented well-known musician, songwriter, recording artist, and writer. he's got over 80 acting credits in movies and TV shows... check wikipedia, IMDB, or even his web site... www.billmumy.com
He carried on with acting. He's popped up in a number of things, including a regular role on Babylon 5 (which I enjoyed in the '90s, but would be painful to watch now).
It's just as easy to crashmail when we're all connected via TCP/IP.
no, actually it is not... try connecting to an link of your boss node when you are a point... some mailers complain when the passwords aren't right because they assume the point is the boss...
some of us have been working
hard to ensure that routed netmail works properly...
warning will robinson! warning!
Warning what?
Have you heard of the TV show "Lost In Space"? One of the famous quotes is N>"Danger, Will Robinson!"
Accession wrote to Bill McGarrity on 11-29-17 19:44 <=-
On Wed Nov 29 2017 16:45:00, Bill McGarrity wrote to Accession:
I know... that's deleted now. :) and all links are direct.
Okay.
As stated, when you first brought it up I added it... saw it was going down in flames and removed it.
In one of your (if not THE) original messages you stated your hub
system was using 24:ALL. I pointed it out and soon after Rob asked you about it and said it "sounded backwards". So how did you add it after I brought anything up? ;)
Nick, that last part was James' reply. I never said that you were
wrong. The original which started all this in motion was not the
24:All statement but a reply to a message originating from 24:100/1
being answered to 24:24/1. Being the netmail was sitting on 24:24/1, sbbsecho did exactly what it was supposed to do.
I had only started replying to your messages when you mentioned that
your hub system was using the catchall, that *maybe* that was your problem.
Never doubted you in the least. I think the problem was on how we
were looking at the problem... which is fine. I didn't have teh
24:ALL originally but added it thinking that's what you and Rob
wanted. It created issues so I removed it and everything is back to normal.
That's not what you said in your original message. We only questioned
what you had already stated.
sbbsecho is preforming just as stated...
It usually does. ;)
The CGI looks like a bad home-made YouTube SF film. It wasn't that great even back then, though. Liked the story, though.
Sorry to say, but it's nice to see some systems that trapped netmail
and read it before sending on leave us.
It's just as easy to crashmail when we're all connected via TCP/IP.
no, actually it is not... try connecting to an link of your boss node
when you are a point... some mailers complain when the passwords
aren't right because they assume the point is the boss...
Let me rephrase - "when all nodes are connected via TCP/IP." Point
issues aside.
some of us have been working hard to ensure that routed netmail works
properly...
Are you implying that the rest of us aren't doing our part?
Re: routed netmail
By: mark lewis to Mickey on Wed Nov 29 2017 10:02 pm
why would you say that?? he is a very talented well-known musician, songwriter, recording artist, and writer. he's got over 80 acting credits in movies and TV shows... check wikipedia, IMDB, or even his web site... www.billmumy.com
The high point being his work in Barnes and Barnes, where they created the timeless hit "Fish Heads".
"Fish Heads" became my son's favorite lullaby. Long story.
Wonder what happened to that Billy Mummy? Not sure he did any work after Lost >In Space.
In one of your (if not THE) original messages you stated your hub
system was using 24:ALL. I pointed it out and soon after Rob
asked you about it and said it "sounded backwards". So how did
you add it after I brought anything up? ;)
The 24:ALL I was speaking of was in the Linked Nodes section for
24:24/1. The Route to there is 24:ALL. When you and Rob first asked about the 24:ALL I thought you meant it AS a separate linked node.
That's what I added and that's what caused the problems with the
looping. I deleted the 24:ALL under Linked nodes but the Route To
entry under 24:24/1 remains at 24:ALL. The logic behind this is that anything coming into 24:24/1 will them be passed TO the
final destination. It's been working all these months perfectly.
I had only started replying to your messages when you mentioned
that your hub system was using the catchall, that *maybe* that
was your problem.
Under the 24:24/1 node. I thought you and Rob meant AS a linked node.
that's Billy Mumy...
Not sure he did any work after Lost In Space.
why would you say that?? he is a very talented well-known musician, songwriter,
He carried on with acting. He's popped up in a number of things, including a regular role on Babylon 5 (which I enjoyed in the '90s, but would be painful to watch now).
---
Accession wrote to Bill McGarrity on 12-01-17 08:35 <=-
Hello Bill,
On Thu Nov 30 2017 09:50:00, Bill McGarrity wrote to Accession:
In one of your (if not THE) original messages you stated your hub
system was using 24:ALL. I pointed it out and soon after Rob
asked you about it and said it "sounded backwards". So how did
you add it after I brought anything up? ;)
The 24:ALL I was speaking of was in the Linked Nodes section for
24:24/1. The Route to there is 24:ALL. When you and Rob first asked about the 24:ALL I thought you meant it AS a separate linked node.
That's what I added and that's what caused the problems with the
looping. I deleted the 24:ALL under Linked nodes but the Route To
entry under 24:24/1 remains at 24:ALL. The logic behind this is that anything coming into 24:24/1 will them be passed TO the
final destination. It's been working all these months perfectly.
What you're not understanding here is that 24:24/1 *IS* the final destination. So having 24:ALL anywhere on 24:24/1 is creating a loop to itself.
The only reason it has been working all these months perfectly is
because you have all your direct links setup above that. Try sending a netmail to a node number you don't have setup as a direct link at that system and see what happens.
It seems you refuse to believe me or Rob here. And as long as it's
working perfectly for you I guess it will go unnoticed. I'm just trying
to enlighten you on the fact you shouldn't be doing it that way. Maybe
at some point it'll bite you in the ass, or maybe not.. but I'm not
going to sit here and argue about it.
I had only started replying to your messages when you mentioned
that your hub system was using the catchall, that *maybe* that
was your problem.
Under the 24:24/1 node. I thought you and Rob meant AS a linked node.
No. I/we meant exactly what we said. Having 24:ALL anywhere on 24:24/1
is ass-backwards. Hopefully you'll understand this:
24:100/1 setup:
24:ALL route-to 24:24/1
As a downlink of 24:24/1 with no other uplinks, (ie: you don't make connections
to anyone else for zone 24), the above statement would route all
traffic for that zone to your single uplink, 24:24/1. No other route statements are needed on this system.
24:24/1 setup:
24:100/1.* route-to 24:100/1
(rinse and repeat for every link)
That is all that is needed.
If you have a 24:ALL anywhere on 24:24/1, it will loop any netmail for
any _un_configured link. Kind of like an email bouncing back to you.
While it's great that it's been working all these months perfectly, you obviously haven't run into the issue yet, which is great. However, some day it very well may happen, and then maybe you'll look back on this conversation and realize you were forewarned that your configuration is wrong. ;)
Any instance of 24:ALL has been removed from the sbbsecho.ini
Let's see.... :)
that's Billy Mumy...
Not sure he did any work after Lost In Space.
why would you say that?? he is a very talented well-known musician,
songwriter,
That will teach me to ask a simple question. Moron.
or maybe to ask uncle google first? ;) ;) O:)
)\/(ark
| Sysop: | Winzlo |
|---|---|
| Location: | Minnesota, USA |
| Users: | 11 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 495942:03:59 |
| Calls: | 82 |
| Files: | 1,070 |
| D/L today: |
27 files (11,920K bytes) |
| Messages: | 286,996 |