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