• FMail-lnx32-2.1.0.18-Beta20170905 netmail Pack

    From Paul Quinn@3:640/1384 to Wilfred van Velzen on Wednesday, January 10, 2018 12:25:18
    Hi! Wilfred,

    A funny thing happened yesterday. I finally tested FMail's "ping" function, from my other point...

    09 Jan 18 09:03:21 FMAIL Processing 87479A7C.PKT from 3:640/384 to 3:640/1384
    09 Jan 18 09:03:21 FMAIL Pkt info: FastEcho 1.46, Type 2+, 415,
    2018-01-09 08:51:06, Pwd, Sec
    09 Jan 18 09:03:21 FMAIL Processed PING request message from
    3:640/384.125 to 3:640/1384
    09 Jan 18 09:03:21 FMAIL Deleted: /opt/ftn/fido/inbound/87479A7C.PKT

    That worked beautifully. OTOH, the pack manager's handling of FMAil's 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.

    Since I didn't have a 'node' setting in binkD for the point, it meant the mail packet just got hung up (the default binkD ~binkp.net addressing wouldn't work as it's a point, and therefore not available from the WAN side).

    To my way of thinking it shouldn't have happened. The pack manager's routing is defined as...

    9. 3:640/* via 3:640/384
    10. 1:* 2:* 3:* 4:* 5:* 6:* via 3:640/384

    (The other 8 entries deal with other zones & regions.)

    So, I'm wondering what I might need to add to the routing table in the event of
    further "ping" queries, especially from other 'unknown' nodes? Did the "Pack -C" statement have any bearing?

    Do you have time to help, please?

    Cheers,
    Paul.

    ... Bad command. Bad, bad command! Sit! Stay! Staaay...
    --- GoldED+/LNX 1.1.5-b20110213
    * Origin: Quinn's Rock - Live from Paul's Xubuntu desktop! (3:640/1384)
  • From Wilfred van Velzen@2:280/464.112 to Paul Quinn on Wednesday, January 10, 2018 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":

    That worked beautifully. OTOH, the pack manager's handling of FMAil's 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.

    Since I didn't have a 'node' setting in binkD for the point, it meant the mail packet just got hung up (the default binkD ~binkp.net addressing wouldn't work as it's a point, and therefore not available from the WAN side).

    To my way of thinking it shouldn't have happened. The pack manager's routing is defined as...

    9. 3:640/* via 3:640/384
    10. 1:* 2:* 3:* 4:* 5:* 6:* via 3:640/384

    (The other 8 entries deal with other zones & regions.)

    So, I'm wondering what I might need to add to the routing table in the event of further "ping" queries, especially from other 'unknown' nodes? 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 [ <node>...
    [EXCEPT <node>...]
    [VIA <node>|HOST]
    [/A] [/C] [/H] [/I] [/L] [/O]
    ]

    So if you specify -C you _must_ specify the <node>, 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)
  • From Paul Quinn@3:640/1384 to Wilfred van Velzen on Wednesday, January 10, 2018 20:25:15
    Hi! Wilfred,

    On 10 Jan 18 09:42, you wrote to me:

    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

    Fascinating.

    So pack routed netmail first, and then handle the unsend crash mail
    that is left in my netmail folder.

    Ah, yes. I have another idea in mind, and already on hand, that will employ a similar process. Thank you, kindly.

    Cheers,
    Paul.

    ... No smoke or sparks! ...Hmmm... Must be a software problem then...
    --- GoldED+/LNX 1.1.5-b20110213
    * Origin: Quinn's Rock - Live from Paul's Xubuntu desktop! (3:640/1384)
  • From Wilfred van Velzen@2:280/464 to Paul Quinn on Wednesday, January 10, 2018 13:15:09
    Hi Paul,

    On 2018-01-10 20:25:15, you wrote to me:

    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

    Fascinating.

    Btw: That logging stuff at the end of the lines is because of my "debugging" FMail. Regular users could just dump it to /dev/null or let it just print on the terminal it runs in. The regular fmail.log should contain enough information for them. ;)

    So pack routed netmail first, and then handle the unsend crash mail
    that is left in my netmail folder.

    Ah, yes. I have another idea in mind, and already on hand, that will employ a similar process. Thank you, kindly.

    Let us know how it works out!

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Paul Quinn@3:640/1384 to Wilfred van Velzen on Wednesday, January 10, 2018 22:23:21
    Hi! Wilfred,

    On 10 Jan 18 13:15, you wrote to me:

    Fascinating.

    Btw: That logging stuff at the end of the lines is because of my "debugging" FMail. Regular users could just dump it to /dev/null or
    let it just print on the terminal it runs in. The regular fmail.log
    should contain enough information for them. ;)

    No worries, mate. I would have just dropped the extra and gone with whatever FMail wanted to throw to the logfile in any case.

    So pack routed netmail first, and then handle the unsend crash
    mail that is left in my netmail folder.
    Ah, yes. I have another idea in mind, and already on hand, that
    will employ a similar process. Thank you, kindly.

    Let us know how it works out!

    Absolutely. I give it another go on my netbook tomorrow AM, my time. It's how
    I start my days: breakfast in bed, reading Fido mail. :-D

    Cheers,
    Paul.

    ... I admit I wrote in COBOL once, but I never compiled.
    --- GoldED+/LNX 1.1.5-b20110213
    * Origin: Quinn's Rock - Live from Paul's Xubuntu desktop! (3:640/1384)
  • From Paul Quinn@3:640/384.125 to Wilfred van Velzen on Thursday, January 11, 2018 08:23:29
    Hi! Wilfred,

    On 01/10/2018 10:23 PM, Paul Quinn -> Wilfred van Velzen wrote:

    So pack routed netmail first, and then handle the unsend crash
    mail that is left in my netmail folder.
    Ah, yes. I have another idea in mind, and already on hand, that
    will employ a similar process. Thank you, kindly.

    Let us know how it works out!

    I cheated. My plan B has been an 'understudy' for FMail pack for the longest time; I used CF-Route. Its config for the pertinent routing is simply...

    TOPDOWN
    [ ... ]
    ROUTE-TO 3:640/384 1:* 2:* 3:* 4:*

    As with FMail's pack manager, other statements take care of other zones & regions. The logfile looked like this...

    ------------------------------------------------------
    CFR-UNX 0.95a started at Jan 11,2018 (Thu) 00:07:06

    From: FMail PING bot (3:640/1384.0)
    To: Paul Quinn (3:640/384.125)
    Subj: Pong: Hi! How are ya?
    Date: 11-01-2018 00:07:06 - 0 days ago - Body size: 1013
    Attr: Pvt Loc
    Via: 3:640/384.0 as NORMAL (OUT).
    File: /opt/ftn/fido/outbound/02800180.OUT ------------------------------------------------------

    It was all over & dusted before corn flakes. ;-P

    Cheers,
    Paul.

    --- Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
    * Origin: Paul's Puppy 4.2.1 multiuser vBox - M'boro, Qld, OZ (3:640/384.125)