On 08 Mar 17  20:55:51, C.G. Learn said the following to Joe Delahaye:   
      
   CL>  JD> Is Binkd loaded? Unless you have DB configured to load binkd as it sta   
   CL>  JD> up, you will have to seperately start binkd.   
   CL>    
   CL> Yes, Binkd is loaded. I can see it call out, but it never sends anything. T   
   CL> hub calls me also, and it never picks anything up. I get my packets for ech   
   CL> mail, but net mail just stays there as a packet, but the actual *.msg in th   
   CL> netmail folder dissapears.   
      
   First of all, lets verify that the BinkD mailbox directory exists for the   
   destination. If the mailbox/staging directory does not exist, no mail can    
   be correctly exchanged. Lets shut down both D'Bridge and BinkD.   
      
   ie. if the destination is 1:229/426 and your QUEUE directory is \DB\QUEUE,    
   then in DOS, CD \ your way to your D'Bridge directory and type:   
      
   DBUTIL QNAME 1:229/426   
      
   MD \DB\QUEUE\D-00106D.0BU   
      
   Note the output of DBUTIL QNAME. That makes up the mailbox name, just add the    
   "D-" infront of it. In this case, 1:229/426 equals D-00106D.0BU.    
      
   While we're at it, lets also make sure nothing is being put on "Hold" status    
   by BinkD. CD \DB\DATA and type:   
      
   DEL /S *.HLD   
   DEL /S *.TRY   
      
   This will delete the control files that tell BinkD to put stuff on hold, and    
   also resets the number of "tries" (attempts) to contact destination systems.   
      
   Restart both D'Bridge and BinkD. Watch very carefully on the next connection    
   attempt, or force one out by doing a POLL to the remote system.   
      
   If mail is still not being exchanged, then verify in the logs that when the   
   system in question connects with yours, that the "domains" are matching.   
   BinkD uses whats known as "5 dimentional" addressing where the domain portion   
   MUST match with the remote system otherwise no mail will be exchanged.  The   
   confusing part is that in 5D addressing, it is not necessarily an actual   
   Internet domain name, but rather moreso a mutually-agreed-upon domain.   
      
   In the BinkD log, if the destination is 1:229/426 and you see something like   
   "1:229/426@fidonet.org busy or N/A" when a connection is established, then   
   uh-oh, the domain is not being correctly matched and no mail will be   
   exchanged in the session.   
      
   In D'Bridge CONFIG-INTERNET, you see that each line in the BINKD SESSIONS   
   screen begins with the Fido address, a space, and the domain name. In the case   
   of Fidonet, this should be set to "fidonet". However, a lot of systems in    
   Fidonet may not necessarily specify "fidonet" as the presented domain in a    
   BinkD session. Very carefully watch your log and if the remote system presents   
   something else, lets say, fidonet.org, then in Config-Internet, you will ARROW   
   DOWN to ADDITIONAL OPTIONS and specify:   
      
   domain fidonet.org alias-for fidonet   
      
   Exit Config-Internet, and restart both D'Bridge and BinkD once again. Force   
   another connection to the remote system, paying attention to the connection   
   log. Note that I strongly recommend NOT specifying "dot" notation in 5D   
   domains in CONFIG-INTERNET. Keep Fidonet as "fidonet". When you start   
   getting into mixing and matching the variations of "fidonet", it becomes a   
   bit difficult to troubleshoot domain-related problems going forward.   
      
   If these two suggestions - The mailbox directory and the BinkD domains - if    
   these two do NOT solve the problem, then let me know.   
      
   Nick   
      
   --- Renegade vY2Ka2   
    * Origin: Joey, do you like movies about gladiators? (1:229/426)