Hi everyone,

For those of you running Synchronet / SBBS-Echo and with feeds with my system, a very friendly reminder to please double-check your setups to ensure that
any packets destined for my system are in fact destined for my system. Please take a moment to check your logs if in doubt.

There are at least three systems I'm seeing connecting here which are host-routing Echomail packets destined for other systems. I will respond to these by Netmail. My understanding is that its a simple typo or fix in one's configuration that causes this to happen.

Although I wrote code in my mailer to trap these misaddressed packets before they route elsewhere, its beginning to slam my inbound almost hourly here.

Thanks guys,

Nick

--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (1:229/426)

Re: Misrouted Synchronet packets
By: Atreyu to All on Fri Dec 06 2024 07:57 pm

For those of you running Synchronet / SBBS-Echo and with feeds with my system, a very friendly reminder to please double-check your setups to ensure that
any packets destined for my system are in fact destined for my system. Please take a moment to check your logs if in doubt.

I'm curous why/how this would be a Synchronet / SBBSecho specific problem. Do you have any details?
--
digital man (rob)

Rush quote #66:
He's old enough to know what's right, but young enough not to choose it
Norco, CA WX: 80.4øF, 12.0% humidity, 0 mph E wind, 0.00 inches rain/24hrs
--- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

On 07 Dec 24 11:40:13, Rob Swindell said the following to Atreyu:

I'm curous why/how this would be a Synchronet / SBBSecho specific problem. you have any details?

Yes. The systems in question are sending Echomail packets that are not destined for my system. When the Sysop fixes their SBBSecho config, the problem is resolved.

Nick

--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (1:229/426)

Re: Re: Misrouted Synchronet packets
By: Atreyu to Rob Swindell on Sat Dec 07 2024 02:45 pm

On 07 Dec 24 11:40:13, Rob Swindell said the following to Atreyu:

I'm curous why/how this would be a Synchronet / SBBSecho specific problem. you have any details?

Yes. The systems in question are sending Echomail packets that are not destined for my system. When the Sysop fixes their SBBSecho config, the problem is resolved.

Do you have any details? What about their SBBSecho config needed fixing exactly?
--
digital man (rob)

Breaking Bad quote #43:
Congratulations! You're now officially the cute one of the group.
Norco, CA WX: 80.9øF, 10.0% humidity, 3 mph WNW wind, 0.00 inches rain/24hrs --- SBBSecho 3.23-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

On 07 Dec 24 14:14:15, Rob Swindell said the following to Atreyu:

Yes. The systems in question are sending Echomail packets that are not destined for my system. When the Sysop fixes their SBBSecho config, the problem is resolved.

Do you have any details? What about their SBBSecho config needed fixing exactly?

No details but seemed to be a quick fix, would need to reach out to them directly... we can discuss via netmail

Nick

--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (1:229/426)

Re: Misrouted Synchronet packets
By: Rob Swindell to Atreyu on Sat Dec 07 2024 11:40:13

For those of you running Synchronet / SBBS-Echo and with feeds with my system, a very friendly reminder to please double-check your setups to ensure that
any packets destined for my system are in fact destined for my system. Please take a moment to check your logs if in doubt.

I'm curous why/how this would be a Synchronet / SBBSecho specific problem. Do you have any details?

what i run into is when removing linked systems that are gone or have move to another feed is that you have to manually remove them from the areas.bbs if they don't send an areafix delink message... so what
happens is sbbsecho sees them in the areas.bbs file, packs the mail, sees there's no link to them, and uses the overall (eg) 1:ALL to send the echomail upstream...

one must also be careful when removing no-longer-linked systems from the areas.bbs via search and replace methods... consider of you have (eg) 1:123/300 and 1:123/3000... 1:123/300 has gone so you search and
replace " 1:123/300" (yes with a leading space)... since 1:123/3000 also matches that search, you're left with a linked system with address 0 which sbbsecho dutifully packs mail for and sends onward via the
catchall 1:ALL or similar...

yes, that last one caught me out... i've since realized that the lines in areas.bbs have a trailing space so i have adjusted my search and replace to include the trailing space and leave out the leading
space...


)\/(ark
--- SBBSecho 3.11-Linux
* Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)

I'm curous why/how this would be a Synchronet / SBBSecho specific problem. Do you have any details?

what i run into is when removing linked systems that are gone or have move to another feed is that you have to manually remove them from the areas.bbs if they don't send an areafix delink message... so what
happens is sbbsecho sees them in the areas.bbs file, packs the mail, sees there's no link to them, and uses the overall (eg) 1:ALL to send the echomail upstream...

Sounds like that is something that could potentially happen to any tosser that uses an AREAS.BBS file and performs zone forwarding.

I have had a similar issue with netmail. I am an RC on an othernet. If a system passes netmail this way for a former connection here, if I have
already removed them from my sbbsecho.ini file, the mail will bounce back
and forth between me and the ZC until I find out and kill it.

There is probably a way to "trap" or "deadletter" mail to my net so that it doesn't bounce around through the '###:ALL' default routing that I haven't quite figured out yet.

Mike

* SLMR 2.1a * We all live in a yellow subroutine.
--- SBBSecho 3.20-Linux
* Origin: capitolcityonline.net * Telnet/SSH:2022/HTTP (1:2320/105)

Re: Misrouted Synchronet pack
By: Mike Powell to MARK LEWIS on Mon Dec 09 2024 11:04:00

what happens is sbbsecho sees them in the areas.bbs file, packs the
mail, sees there's no link to them, and uses the overall (eg) 1:ALL
to send the echomail upstream...

Sounds like that is something that could potentially happen to any
tosser that uses an AREAS.BBS file and performs zone forwarding.

true to a point... that point being tossers with configuration tools that do not manage the areas.bbs file... i never had the problem with tossers like fmail, gmail, fastecho and others, though... when a
node is deleted in their configuration programs, the areas.bbs file is also cleaned of those system addresses...

those tosser configuration programs import/export the areas.bbs data to/from their own configuration files... when an areafix message arrives, its commands deal with the requested changes in both, the
tossers config file as well as the areas.bbs file... some of those tosser configuration programs also allow the operator to add/remove systems to/from the message areas... this area management portion of
those other tossers would be a very nice addition to echocfg but is not really needed if echocfg would also clean the areas.bbs when systems are deleted... it is something that i have wanted to suggest and
possibly work on for a while but have never gotten a round tuit :/

in your other situation, it is like above... what i have done to stop those loops is to make sure i have a catch-all routing for my /0 node(s) so that errant mail gets routed to my /0 and will sit here...
there are still the cases where mail to systems outside of my /0 coverage(s) will loop, though... this can be mitigated by the tosser if it can read the via and path lines in net and echomail and not forward
that message on to other systems if one of its local addresses is listed... for echomail, this is known as CPD (circular path detection)... i don't recall a specific name for it in netmail but yeah,
detecting the loop in the via lines is the solution...


)\/(ark
--- SBBSecho 3.11-Linux
* Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)

in your other situation, it is like above... what i have done to stop those loops is to make sure i have a catch-all routing for my /0 node(s) so that errant mail gets routed to my /0 and will sit here...

Mark,
Thanks! I will try adding my /0 number as the default for my local net to
dead letter netmail for retired nodes.

Mike

* SLMR 2.1a * Your E-mail has been returned due to insufficient voltage
--- SBBSecho 3.20-Linux
* Origin: capitolcityonline.net * Telnet/SSH:2022/HTTP (1:2320/105)