how do you prevent binkd from connecting to one of its own AKAs?

i see this from time to time and it results in a loop of the traffic being attempted to be sent...


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

Hello mark!

On Mon, 13 Jan 2020 at 10:28 -0500, you wrote to All:

how do you prevent binkd from connecting to one of its own AKAs?

i see this from time to time and it results in a loop of the traffic
being attempted to be sent...

The easiest way is to not create outboud for own AKA. Or if it is really necessary, create it with _hold_ flavor.


... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)

SeaMonkey/2.49.5

how do you prevent binkd from connecting to one of its own AKAs?

i see this from time to time and it results in a loop of the traffic
being attempted to be sent...

"node 1:3634/12 do.not.poll."

It may try, but it wont connect. ;)

'Tommi

---
* Origin: nntps://news.fidonet.fi (2:221/6.0)

Or if it is really necessary, create it with _hold_ flavor.

This is exactly the situation here, I have multiple tossers that send
mail bundles to BSO to be sent to the others by "diskpoll".

HPT is able to create bundles to any directory, but GEcho for example is
not.

And to be sure, just block own akas like I wrote before. There may be a
more sophisticated way, but that one works. ;)

'Tommi

--- Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:52.0) Gecko/20100101 SeaMonkey/2.49.5
* Origin: nntp://rbb.fidonet.fi - Lake Ylo - Finland (2:221/360.0)

Re: binkd connecting to own AKA
By: Alexey Fayans to mark lewis on Mon Jan 13 2020 19:10:10

how do you prevent binkd from connecting to one of its own AKAs?

i see this from time to time and it results in a loop of the traffic
being attempted to be sent...

The easiest way is to not create outboud for own AKA. Or if it is really

necessary, create it with _hold_ flavor.

not really viable options... especially when it may be due to what may be a routing problem on one or both sides of the connection...

in the specific case i'm looking at, the problem is a netmail from a node's point to the node but the node forwarded it here... apparently there is no automatic routing in place with the software i'm using that routes netmails from points to their boss node... in this instance, there was a routing problem on the boss node which resulted in the point netmail being sent here... that's been fixed but my system was following its routing table and sending all mail for that boss' points to the NC for forwarding to the node... since i'm also the NC for that net (and a few others) binkd was calling itself which just seems weird...

so i hope to draw a simple diagram for what happened...



point system (1:123/xxx.y)
|
V
boss system (1:123/xxx.0)
|
V
my HUB in different net (1:3634/12)
|
V
my tosser on 1:3634/12 routes to net123 NC 1:123/0
|
V
my binkd is 1:3634/12, 1:3634/0, 1:123/0, 1:18/0
| ^
V |
my binkd calls itself over and over --



so far, i've fixed this case by deleting the ?ut file and adjusting my routing to specifically routes this node's point netmails to the node but to have to specifically set routes for all nets' nodes' points to avoid this if i'm also the NC of that net is painful to say the least :/

it may also be a tosser problem not recognizing messages that may be routed to one of its AKAs...

it just seems that a mailer should recognize mail destined to itself and refuse to make the attempt with an appropraite log notice... possibly in the .try file that monitoring software may use to display the last attemptted connection status...

i can imagine what a single node system on POTS would do trying to call itself... a multinode POTS system calling one of its other lines might be noticible due to modem sound but this is TCP/IP so there's no modem sound to possibly hear...

i'm still researching prevention possibilities... routing, tosser AKA recognition, both(?)...


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

Re: binkd connecting to own AKA
By: Tommi Koivula to mark lewis on Mon Jan 13 2020 18:27:24

how do you prevent binkd from connecting to one of its own AKAs?

i see this from time to time and it results in a loop of the traffic
being attempted to be sent...

"node 1:3634/12 do.not.poll."

It may try, but it wont connect. ;)

HA! that's funny but it would work i guess LUL

it was actually calling one of my administrative AKAs for HOST routing... i'm still looking at options...

FWIW: i did, at one time, have to put in a routing statement for my system to route to itself because it was sending the netmail to one of my upstream links which was sending it right back... that was a similar loop problem... i'll get it figured out somehow... i just don't really recall other mailers being able to connect to themselves over POTS or, as in this case, TCP/IP... it just seems proper that the mailer would recognize the destination as one of its own addresses and simply refuse to make the attempt at all... maybe with a configurable option? i dunno...


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

Hello Tommi!

On Mon, 13 Jan 2020 at 18:38 +0200, you wrote to me:

Or if it is really necessary, create it with _hold_ flavor.

This is exactly the situation here,

Are you saying that binkd is calling nodes that only have something on hold? I can't imagine why this can be happening.


... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)

Hello mark!

On Mon, 13 Jan 2020 at 11:48 -0500, you wrote to me:

in the specific case i'm looking at, the problem is a netmail from a node's point to the node but the node forwarded it here... apparently there is no automatic routing in place with the software i'm using
that routes netmails from points to their boss node... in this
instance, there was a routing problem on the boss node which resulted
in the point netmail being sent here... that's been fixed but my
system was following its routing table and sending all mail for that
boss' points to the NC for forwarding to the node... since i'm also
the NC for that net (and a few others) binkd was calling itself which
just seems weird...

This is indeed a routing problem and should be fixed instead of trying to stop binkd from doing its work.

so far, i've fixed this case by deleting the ?ut file and adjusting my routing to specifically routes this node's point netmails to the node
but to have to specifically set routes for all nets' nodes' points to avoid this if i'm also the NC of that net is painful to say the least
:/

Routing should handle every case and never pack anything to your own AKA. This is easily achieved with RNtrack, for example. My system will always resolve final destination properly before packing anything (or discard mail that can't be routed and send notification to sender).

it just seems that a mailer should recognize mail destined to itself
and refuse to make the attempt with an appropraite log notice...

I do not agree. Mailer reads outbound and delivers what can be delivered.

i can imagine what a single node system on POTS would do trying to
call itself...

It would do exactly the same. Single line node would receive BUSY all the time though.


... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)

Hi Alexey.

13 Jan 20 20:56:16, you wrote to me:

Or if it is really necessary, create it with _hold_ flavor.

This is exactly the situation here,

Are you saying that binkd is calling nodes that only have something on

hold?

No, I'm saying that I put mail on hold to my outbound NOT to be sent out by mailer. :)

'Tommi

---
* Origin: - rbb.fidonet.fi - Finland - (2:221/360)

Re: binkd connecting to own AKA
By: Alexey Fayans to mark lewis on Mon Jan 13 2020 20:59:59

This is indeed a routing problem and should be fixed instead of trying to stop binkd from doing its work.

i'm not trying to stop binkd from doing its work... i'm trying to prevent it from doing useless busy work that may be caused by something else... there is never a need for a mailer to call itself and deliver files from its outbound right back into its inbound and keep looping endlessly like that until someone notices a problem...

in my case, i noticed it when i saw a netmail with several dozen VIA lines all from my own system... that was when i realized it wasn't a loop between my system and another like i have had to deal with in the past... that's also probably why i have a routing statement in place to route my net's mail back to my system... it stopped that looping problem and now we have this one that i'm trying to understand and fix... frontdoor never called itself unless there was some specific settings in place... settings that would never have been done accidentally...


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

Hello mark!

On Mon, 13 Jan 2020 at 18:07 -0500, you wrote to me:

This is indeed a routing problem and should be fixed instead of
trying to stop binkd from doing its work.

i'm not trying to stop binkd from doing its work... i'm trying to
prevent it from doing useless busy work that may be caused by
something else... there is never a need for a mailer to call itself
and deliver files from its outbound right back into its inbound and
keep looping endlessly like that until someone notices a problem...

Not sure if it's better than having something packed for your own AKA and never noticed.


... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)

Re: binkd connecting to own AKA
By: Alexey Fayans to mark lewis on Tue Jan 14 2020 03:23:21

This is indeed a routing problem and should be fixed instead of
trying to stop binkd from doing its work.

i'm not trying to stop binkd from doing its work... i'm trying to
prevent it from doing useless busy work that may be caused by
something else... there is never a need for a mailer to call itself
and deliver files from its outbound right back into its inbound and
keep looping endlessly like that until someone notices a problem...

Not sure if it's better than having something packed for your own AKA and

never

noticed.

that's why i specifically mentioned about having something in the .try file that monitoring software could use to raise a more noticible alert... for example, this (broken for formatting) line from my waitingoutmail script uses the time stamp in the .hld file and the result value in the .try file...

d 1:123/130@fidonet (007b0082) : netmail : 2 days 04:09:08
Next Delivery Attempt: 2020-01-14 05:46:57 -0500
Last Delivery Status: Connection timed out

so like maybe the last attempt status in the .try file could be something like

Will not attempt delivery to self!

or similar...


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

Hello mark,

On Monday January 13 2020 18:07, you wrote to Alexey Fayans:

This is indeed a routing problem and should be fixed instead of
trying to stop binkd from doing its work.

I agree with Alexey. The problem should be adressed at the source.

i'm not trying to stop binkd from doing its work... i'm trying to
prevent it from doing useless busy work that may be caused by
something else... there is never a need for a mailer to call itself
and deliver files from its outbound right back into its inbound

1) Over the years you have made a point of emphesising that binkd is not a mailer. You called it a filer. Have you changed your mind?

2) Widen your horizon. I have made binkd call itself for testing purposes.

frontdoor never called itself unless there was some specific
settings in place...

"binkd is not Frontdoor"

settings that would never have been done accidentally...

Same with binkd. It never accidentally calls itself. I also never accidentally address snail mail to myself. But if I do, it gets delivered. The snail mail system just follows orders and if it is ordered to deliver mail to the address of the sender it just does so.

And so does binkd. Binkd just moves files from the sender's outbound to the receiver's inboud. It follows the orders it gets via the *.?lo files. If it is ordered to move files from its own outbound to its own inbound, it just does so. As it should.

If the result is not what is desired, it is the agency issuing the orders that is at fault. Maiming/complicating binkd to solve that problem is the wrong line of attack.

It is your tosser/netmail packer/whatever else/ that orders your binkd to call itself. It may be a bug or configuration error in your software, or that software may get confused by an error in software upstream. Binkd just follows orders.

I recently encounterad a routing problem caused by a combination of software used by half of the ZCs and Synchronet. The ZC's software added a second INTL conflicting with the first one... It confused Synchronet used at another node to go into zonegate mode.

Instead of trying to compensate for the error(s) at my end, it was eventually dealt with at the source. As it should...


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.eu (2:280/5555)

I recently encounterad a routing problem caused by a combination of software used by half of the ZCs and Synchronet. The ZC's software added
a second INTL conflicting with the first one...

It did not.

A file was imported which contained an INTL, the software did not add one.

\%/@rd

--- D'Bridge 4
* Origin: Do not meddle in the affairs of wizards (2:292/854)

On 14 Jan 20 14:05:28, Michiel Van Der Vlist said the following to Mark Lewis:

I recently encounterad a routing problem caused by a combination of softwar used by half of the ZCs and Synchronet. The ZC's software added a second IN conflicting with the first one... It confused Synchronet used at another no to go into zonegate mode.

Bullshit.

Nick

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

On 14 Jan 20 14:05:28, Michiel Van Der Vlist said the following to Mark Lewis:

I recently encounterad a routing problem caused by a combination of

softwar

used by half of the ZCs and Synchronet. The ZC's software added a

second IN

conflicting with the first one... It confused Synchronet used at

another no

to go into zonegate mode.

Looking nice, yes? Not only not format-flowed but also with truncated lines. And Michiel's name is not "Van Der" it's "van der" What a crappy editor...

This is what Michiel's original looked like:

I recently encounterad a routing problem caused by a combination of software used by half of the ZCs and Synchronet. The ZC's software added a second INTL conflicting with the first one... It confused Synchronet used at another node to go into zonegate mode.

Bullshit.

A crappy comment on top of that -- how unexpected...




..

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://eljaco.se (2:203/2)

On 15 Jan 20 03:36:37, Bj*Rn Felten said the following to Nick Andre:

I recently encounterad a routing problem caused by a combination of softwar used by half of the ZCs and Synchronet. The ZC's software added a second IN conflicting with the first one... It confused Synchronet used at another no to go into zonegate mode.

Bullshit.

A crappy comment on top of that -- how unexpected...

I called "bullshit" in simple plain English, as the statement is "bullshit".

And once again, like a few times before, you have absolute jack shit to come
at me with... so now you want to start whining about quote lines.

And since now this has nothing to do with BinkD, why not fuck off to Fidonews where your particular blend of premium Swedish/Cajun bullshit is on-topic.

Nick

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

On 15 Jan 20 03:36:37, Bj*Rn Felten said the following to Nick Andre:

You really should do something about your beautifier...

Bullshit.

And since now this has nothing to do with BinkD,

Unlike your bullshit comment, you mean?


..

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://eljaco.se (2:203/2)