MSGID: 2:280/464.47 61e163b8   
   REPLY: 3:770/100 adef2735   
   PID: JamNNTPd/Linux 1   
   CHRS: LATIN-1 2   
   TZUTC: 0100   
   TID: CrashMail II/Linux 1.7   
   Paul wrote (2022-01-14):   
      
    PH> + 14 Jan 11:02:34 [23306] addr: 21:1/136@fsxnet   
    PH> + 14 Jan 11:02:34 [23306] addr: 3:770/999@fidonet   
    PH> ? 14 Jan 11:02:34 [23306] inconsistent pwd settings for this node   
    PH> ? 14 Jan 11:02:34 [23306] `letmein': incorrect password   
      
    PH> in the above case I have a node in Zone 21 defined in BinkD and a   
    PH> password etc. all set up.   
      
    PH> The node has then flown a fidonet test aka 3:770/999 that I have a   
    PH> definition for also in BinkD   
      
    PH> node 3:770/999@fidonet noname.com letmein h   
    PH> /hub/filebox/fidonet_z3n770n999   
      
    PH> The passwords between Zone 21 definition in BinkD for this node and the   
    PH> test Fido aka are not the same.   
      
    PH> It seems like I can't offer a node that I have setup for one Zone an   
    PH> option to connect to another Zone unless I use the same passwords across   
    PH> all definitions? Is this correct or am I missing something?   
      
   Yes, that is another problem with binkp's flawed security model.   
      
   I this use case one could try to use the perl-hooks for an workaround.   
   Simplest solution would be to check for the test AKA and then only present the   
   relevant Fido AKA (and drop all your other AKAs). So call from 3:770/999 only   
   returns 3:770/100.   
      
   The problem with this workaround is, that the node cannot receive any other   
   mails (from FSX) if ith's polling its mails, as long as the test AKA is   
   configured. So could make the perl script a bit more complicated and check, if   
   there is anything in your outbound for 3:770/999 and if the outbound is empty,   
   drop the Fido AKA.   
      
   Maybe there are better strategies... (?)   
      
   You could also just not use a password, it's not a secret anyway.   
      
   If the calling node is using binkd, they could use the hide-aka option in   
   binkd.cfg. No idea if Mystic provides anything similar.   
      
   But I wonder, why does a node have to use a test AKA, if they already have a   
   working connection in another network with your hub and knows how the stuff   
   works? Just give them a node number in Fido and configure the same password.   
      
   ---   
    * Origin: Birds aren't real (2:280/464.47)   
   SEEN-BY: 1/123 14/0 15/0 90/1 103/705 105/81 106/201 114/705 709 120/340   
   SEEN-BY: 123/120 131 124/5016 129/305 153/250 757 7715 154/10 203/0   
   SEEN-BY: 218/840 220/70 221/0 226/17 30 227/114 229/110 200 307 424   
   SEEN-BY: 229/426 550 664 700 240/5832 249/206 317 250/5 8 266/512   
   SEEN-BY: 267/800 280/464 5003 5555 282/1038 292/854 8125 298/25 301/1   
   SEEN-BY: 305/3 310/31 317/3 320/219 322/757 341/234 342/200 396/45   
   SEEN-BY: 423/120 460/58 633/280 712/848 770/1 100 340 772/210 220   
   SEEN-BY: 772/230 2452/250   
   PATH: 280/464 770/1 317/3 229/426