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 [ |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca