TID: FMail-W32 2.1.3.7-B20170919   
   RFC-X-No-Archive: Yes   
   TZUTC: 0100   
   CHRS: CP850 2   
   MSGID: 2:280/5555 5e1dc193   
   REPLY: 488.fido-binkd@1:3634/12 2282301d   
   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)   
   SEEN-BY: 1/123 90/1 103/705 154/10 203/0 221/0 6 227/114 229/101 200   
   SEEN-BY: 229/426 1014 240/5832 249/307 317 280/464 5003 5555 292/854   
   SEEN-BY: 310/31 342/200 396/45 423/120 712/848 770/1 2452/250 5019/40   
   SEEN-BY: 5020/1042 5053/58   
   PATH: 280/5555 464 229/426