home bbs files messages ]

Just a sample of the Echomail archive

Cooperative anarchy at its finest, still active today. Darkrealms is the Zone 1 Hub.

   FMAIL_HELP      Fmail support      2,396 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 1,707 of 2,396   
   Wilfred van Velzen to Paul Quinn   
   Re: FMail-lnx32-2.1.0.18-Beta20170905 ne   
   10 Jan 18 09:42:17   
   
   Hi Paul,   
      
   On 10 Jan 18 12:25, Paul Quinn wrote to Wilfred van Velzen:   
     about: "FMail-lnx32-2.1.0.18-Beta20170905 netmail Pack":   
      
    PQ> That worked beautifully.  OTOH, the pack manager's handling of FMAil's   
    PQ> response caught me by surprise, with...   
      
    >> 09 Jan 18 09:03:21 FMAIL  FMail-lnx32-2.1.0.18-Beta20170905 - Pack -C   
    >> 09 Jan 18 09:03:21 FMAIL  Warning: Node 3:640/384.125 is not defined in   
    >> the node manager   
    >> 09 Jan 18 09:03:21 FMAIL  Message #1 : 3:640/1384 -> 3:640/384.125   
    >> 09 Jan 18 09:03:21 FMAIL  Create   
    >> /opt/ftn/fido/outbound/02800180.pnt/0000007d.flo   
    >> 09 Jan 18 09:03:21 FMAIL  Sending new mail from 3:640/1384 to   
    >> 3:640/384.125   
    >> 09 Jan 18 09:03:21 FMAIL  Netmail: 1,  Personal: 0,  Hudson: 0,  JAMbase:   
    >> 0   
    >> 09 Jan 18 09:03:21 FMAIL  Msgbase net: 0, echo: 0, dup: 0, bad: 0   
    >> 09 Jan 18 09:03:21 FMAIL  Pack Active: 0.0062 sec.   
      
    PQ> Since I didn't have a 'node' setting in binkD for the point, it meant the   
    PQ> mail packet just got hung up (the default binkD ~binkp.net addressing   
    PQ> wouldn't work as it's a point, and therefore not available from the WAN   
    PQ> side).   
      
    PQ> To my way of thinking it shouldn't have happened.  The pack manager's   
    PQ> routing is defined as...   
      
    PQ>   9.   3:640/* via 3:640/384   
    PQ>  10.   1:* 2:* 3:* 4:* 5:* 6:* via 3:640/384   
      
    PQ> (The other 8 entries deal with other zones & regions.)   
      
    PQ> So, I'm wondering what I might need to add to the routing table in the   
    PQ> event of further "ping" queries, especially from other 'unknown' nodes?   
    PQ> Did the "Pack -C" statement have any bearing?   
      
   It might be due to the -C indeed. Although PING replies shouldn't have the   
   Crash flag (I think), so shouldn't be touched by 'Pack -C'. But doing 'Pack   
   -C' the right way is a bit odd:   
      
   The syntax of FMail Pack:   
      
             FMail Pack  [ ...   
                           [EXCEPT ...]   
                           [VIA |HOST]   
                           [/A] [/C] [/H] [/I] [/L] [/O]   
                         ]   
      
   So if you specify -C you _must_ specify the , otherwise the behaviour is   
   undefined.   
      
   What I do in my pack script is something like:   
      
   $BIN/fmail pack 2>&1 | tee -a $LOG   
   ...   
   $BIN/fmail pack '*' '-c' 2>&1 | tee -a $LOG   
      
   So pack routed netmail first, and then handle the unsend crash mail that is   
   left in my netmail folder.   
      
   Wilfred.   
      
   --- FMail-W32 2.0.1.4   
    * Origin:  point@work  (2:280/464.112)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca