Subj : binkd connecting to own AKA
To   : mark lewis
From : Michiel van der Vlist
Date : Tue Jan 14 2020 02:05 pm

Hello mark,

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

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

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

 ml> i'm not trying to stop binkd from doing its work... i'm trying to
 ml> prevent it from doing useless busy work that may be caused by
 ml> something else... there is never a need for a mailer to call itself
 ml> 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.

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

"binkd is not Frontdoor"

 ml> 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)

.