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...
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...
Or if it is really necessary, create it with _hold_ flavor.
necessary, create it with _hold_ flavor.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
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. ;)
Or if it is really necessary, create it with _hold_ flavor.This is exactly the situation here,
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 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 just seems that a mailer should recognize mail destined to itself
and refuse to make the attempt with an appropraite log notice...
i can imagine what a single node system on POTS would do trying to
call itself...
hold?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
This is indeed a routing problem and should be fixed instead of trying to stop binkd from doing its work.
This is indeed a routing problem and should be fixed instead ofi'm not trying to stop binkd from doing its work... i'm trying to
trying to stop binkd from doing its work.
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...
neverThis 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
noticed.
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
frontdoor never called itself unless there was some specific
settings in place...
settings that would never have been done accidentally...
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...
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.
Sysop: | digital man |
---|---|
Location: | Riverside County, California |
Users: | 1,046 |
Nodes: | 17 (0 / 17) |
Uptime: | 29:55:52 |
Calls: | 501,838 |
Calls today: | 8 |
Files: | 104,425 |
D/L today: |
1,782 files (289M bytes) |
Messages: | 300,027 |
Posted today: | 4 |