MSGID: 2:221/1.58@fidonet e402530d   
   REPLY: 2:310/31.3@fidonet e4005dad   
   PID: OpenXP/5.0.43 (Win32)   
   CHRS: ASCII 1   
   TZUTC: -0400   
   Hello Martin!   
      
   ** On 01.05.20 - 20:17, Martin Foster wrote to August Abolins:   
      
    MF>Hello August!   
      
    MF>*** Monday 13.04.20 at 10:31, August Abolins wrote to Martin Foster:   
           ^^^^^^   
      
   I like that addition!   
      
      
    MF>Further to my previous reply regarding my tests with OpenXP, I've just   
    MF>tried this with my own WinPoint setup and I got exactly the same result as   
    MF>you .....   
      
    MF>---------- 8< ----------   
    MF>01.05.20 20:04:30  Starting Import   
    MF>01.05.20 20:04:30  1 messages from b34f0322.pkt   
    MF>01.05.20 20:04:30  Packet b34f0322.pkt has been moved to backup directory   
    MF>01.05.20 20:04:30  1 messages from b34f27b1.pkt   
    MF>01.05.20 20:04:30  Packet b34f27b1.pkt has been moved to backup directory   
    MF>01.05.20 20:04:30  3 messages from b34f396f.pkt   
    MF>01.05.20 20:04:30  Packet b34f396f.pkt has been moved to backup directory   
    MF>01.05.20 20:04:30  4 messages from b34f4a41.pkt   
    MF>01.05.20 20:04:30  Packet b34f4a41.pkt has been moved to backup directory   
    MF>01.05.20 20:04:30  Area NETMAIL received 2 messages   
    MF>01.05.20 20:04:30  Area BAD received 7 messages   
    MF>01.05.20 20:04:30  Tossed 9 messages from 4 packets   
    MF>---------- 8< ----------   
      
    MF>Having thought about this, I'm not actually surprised by the outcome   
    MF>because I didn't configure a "dummy" FSXNet uplink prior to doing the   
    MF>test. Any thoughts?   
      
      
   I bet that is exactly why it failed for us in WinPoint.  I assumed that     
   WinPoint would automatically create the network particulars just like it     
   does the echo areas when something arrives.   
      
   Creating an uplink entry *first* before tossing makes sense.  I guess we     
   wouldn't want WinPoint to blindly accept every pkt or bundle that it     
   receives.  It's a good thing that the "unknown" .pkts are moved out of the     
   way.   
      
   BUT..  Apoint doesn't seem to care!  ;)  The only thing I see failing in     
   Apoint would be the building of outbound bundles to the proper Boss node.      
   In which case, that should probably be configured before Exporting any new     
   messages created locally.   
      
     ../|ug   
      
   --- OpenXP 5.0.43   
    * Origin: ----------Do Not Fold, Spindle or Mutilate.---------- (2:221/1.58)   
   SEEN-BY: 1/123 90/1 120/340 601 226/30 227/114 229/101 426 664 1014   
   SEEN-BY: 240/5832 249/206 317 400 292/854 317/3 322/757 342/200   
   PATH: 221/1 280/464 229/101 426