• FTS-4010 Final Review

    From Andrew Leary@1:320/219 to All on Thu Apr 29 12:29:36 2021
    Hello everybody!

    === Cut === *********************************************************************
    FTSC FIDONET TECHNICAL STANDARDS COMMITTEE *********************************************************************

    Publication: FTS-4010
    Revision: 1
    Title: The PING and TRACE flags
    Author(s): Michiel van der Vlist,
    FTSC members and administrator.
    Issue Date: 2021-04-27 =====================================================================

    Status of this document
    -----------------------

    This document is a FidoNet Technical Standard (FTS).

    This document specifies an optional FidoNet standard for the FidoNet
    community.

    This document is released to the public domain, and may be used,
    copied or modified for any purpose whatever.

    This document supersedes and replaces FSP-1043.
    FSP-1043 is preserved in the FTSC reference library as FRL-1040.


    ---------------------------------------------------------------------
    Contents:
    0. Definitions
    1. Introduction.
    2. The problem.
    3. The solution.
    4. Considerations
    A. References
    B. History ---------------------------------------------------------------------


    0. Definitions
    --------------

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
    NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
    in this document are to be interpreted as described in [FTA-1006].


    1. Introduction
    ---------------

    The PING functionality as introduced by Ward Dossche just over two
    decades ago and advertised by the PING flag is a very useful tool
    in tracing and solving routing problems. This proposal is an update
    of the original specs and introduces the TRACE flag.


    2. The problem
    --------------

    In the original specification as documented by Ward Dossche in the
    April 2001 Z2 nodelist trailer and the specification last documented
    in FTS-5001.006, the PING functionality contains two parts: PING and
    TRACE. According to that specification systems flying the PING flag
    should support both PING and TRACE functionality.

    Recent surveys by the author however have shown that not all systems
    flying the PING flag also support the TRACE functionality. One could
    argue that current practice is that TRACE functionality is optional.

    Considering that the PING function alone is a very useful tool all
    by itself for both routing systems and leaf systems and that TRACE
    is only useful for routing systems, one may conclude that the above
    current practice works well, but that it is not compliant with the
    original and current specs.


    3. The Solution
    ---------------

    Split up the PING and TRACE functionality.


    PING
    ----

    Specified as exactly "PING" with no arguments. Nodes flying this
    flag will adhere to the following functionality:

    If a message destined to user "PING" (case insensitive) arrives
    at its final destination and this final destination flies the
    PING flag, then the receiving node will bounce the message back
    to the original sender clearly quoting all the original via
    lines.

    If a message destined to "PING" arrives at its final destination
    but this final destination does _not_ fly the PING flag then the
    message may be deleted from the system without further action.


    TRACE
    -----

    Specified as exactly "TRACE" with no arguments. Nodes flying this
    flag will adhere to the following functionality:

    If a message destined to user "PING" (case insensitive) arrives
    at a node which flies the TRACE flag but is merely passing
    through to another destination then the in-transit node will
    notify the sender of this occurrence, clearly quoting the via
    lines, and forward the original mail unaltered towards its final
    destination.


    For both PING and TRACE responses, the sender's name must never
    be "PING" and the responses must never be addressed to "PING".


    4. Considerations
    -----------------

    Making the TRACE function optional by separating the flags, is an
    encouragement for developers and script writers to join the project.
    They can choose to only implement the PING functionality and leave
    TRACE functionality for later or omit it completely without
    violating the specs. This will hopefully make more sysops join
    the PING club.

    Splitting up the PING and TRACE functionality by introducing the
    TRACE flag is backward compatible. Systems flying the PING flag
    that do not support TRACE need do nothing, they are compliant
    with the new specs. Systems flying the PING flag that support
    both PING and TRACE functionality may add the TRACE flag to their
    listing. But if they do not, no harm is done, they are still
    compliant with the new specs, it just does not advertise all
    functionality.


    A. References
    -------------


    [FTS-5] "The distribution nodelist".
    Ben Baker, Rick Moore, and David Nugent.
    1996-02-27. Obsoleted by FTS-5000.

    FTS-5000] "The distribution nodelist".
    FTSC Members, Administrator, and Honoured Guests.
    2014-01-23.

    [FTS-5001] "Nodelist flags and userflags".
    FTSC Members, Administrator, and Honoured Guests
    2017-08-13.

    A PING robot survey.
    Michiel van der Vlist.
    Fidonews 38:07, 2021-02-15.

    Ping robot survey, a follow up.
    Michiel van der Vlist.
    Fidonews 38:15, 2021-04-12.


    B. History
    ----------

    Rev.1, 2021-04-27: Initial release.


    === Cut ===

    Please submit any comments or suggestions by 2021-05-06.

    Thank you,

    Andrew

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)
  • From Alexey Vissarionov@2:5020/545 to Andrew Leary on Thu Apr 29 20:39:00 2021
    Good ${greeting_time}, Andrew!

    29 Apr 2021 12:29:36, you wrote to All:

    Publication: FTS-4010
    This document supersedes and replaces FSP-1043.
    FSP-1043 is preserved in the FTSC reference library as FRL-1040.

    The FSP should be out for at least a year to be promoted to the FTS.

    FSP-1043 is dated 2021-04-27. Two days definitely are not enough.


    --
    Alexey V. Vissarionov aka Gremlin from Kremlin
    gremlin.ru!gremlin; +vii-cmiii-ccxxix-lxxix-xlii

    ... that's why I really dislike fools.
    --- /bin/vi
    * Origin: ::1 (2:5020/545)
  • From Andrew Leary@1:320/219 to Alexey Vissarionov on Thu Apr 29 18:50:07 2021
    Hello Alexey!

    29 Apr 21 20:39, you wrote to me:

    The FSP should be out for at least a year to be promoted to the FTS. FSP-1043 is dated 2021-04-27. Two days definitely are not enough.

    Thank you for your input. This particular proposal is very simple, and is already in use in a significant portion of FidoNet. If you have any other comments, please feel free to share them here.

    Andrew

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)
  • From Kees van Eeten@2:280/5003.4 to Andrew Leary on Tue May 4 13:52:32 2021
    Hello Andrew!

    29 Apr 21 12:29, you wrote to All:

    Hello everybody!

    === Cut === *********************************************************************
    FTSC FIDONET TECHNICAL STANDARDS COMMITTEE *********************************************************************

    Publication: FTS-4010
    Revision: 1
    Title: The PING and TRACE flags
    Author(s): Michiel van der Vlist,
    FTSC members and administrator.
    Issue Date: 2021-04-27 =====================================================================

    Although limits on the maximal length of line have been lifted to some extent,
    why do these two flag have a unprecedented length.

    As these two flags are likely to come as a pair, 11 characters are needed
    for their presense. E,g. PG and TR would only use 6.

    Kees

    --- GoldED+/LNX 1.1.5--b20180707
    * Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)
  • From Carlos Navarro@2:341/234.1 to Kees van Eeten on Mon Jun 7 21:44:22 2021
    04 May 2021 13:52, you wrote to Andrew Leary:

    Although limits on the maximal length of line have been lifted to
    some extent, why do these two flag have a unprecedented length.

    As these two flags are likely to come as a pair, 11 characters are
    needed for their presense. E,g. PG and TR would only use 6.

    Maybe PING:T instead of PING,TRACE ...?

    Carlos

    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: costa blanca, Spain (2:341/234.1)
  • From Björn Felten@2:203/2 to Carlos Navarro on Mon Jun 7 22:05:25 2021
    Maybe PING:T instead of PING,TRACE ...?

    Or maybe abandon that stupid PING/TRACE idea entirely? With the Fidoweb working (even with certain ZC guys and their years long grudge against major Fidoweb operators) there seems like there's any need to check the routing with a shitload of netmail.



    ..

    --- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
    * Origin: news://eljaco.se (2:203/2)
  • From Flavio Bessa@4:801/188 to Bj”rn Felten on Mon Jun 7 19:05:48 2021
    On 07/06/21 17:05, Björn Felten -> Carlos Navarro wrote:
     CN>> Maybe PING:T instead of PING,TRACE ...?

      Or maybe abandon that stupid PING/TRACE idea entirely? With the
    Fidoweb
    working (even with certain ZC guys and their years long grudge against major
    Fidoweb operators) there seems like there's any need to check the
    routing with
    a shitload of netmail.


    I don't agree. Regardless of how many links you have, there
    will always be the need for classic netmail delivery.


    --
    _
    ..-----________________--_ ________.--'-`--._____ Flavio Bessa \____==================_) \_'===================` 4:801/188
    _,--___.-|__|-.______|=====/ `---' fcbessa@gmail.com
    `---------._ ~~~~~| Rio de Janeiro
    `-._ - - - ,' Brasil
    \_____,-' Visit Zone4 Website at: https://fido.bbs.docksud.com.ar/wiki/doku.php?id=fidonet:nodos
    --- Thunderbird/MacOS 78.6.0
    * Origin: Andromeda - Saturn's Orbit NNTP Gateway, Brazil (4:801/188)
  • From Andrew Leary@1:320/219 to Carlos Navarro on Mon Jun 7 21:58:10 2021
    Hello Carlos!

    07 Jun 21 21:44, you wrote to Kees van Eeten:

    Although limits on the maximal length of line have been lifted
    to some extent, why do these two flag have a unprecedented
    length.

    As these two flags are likely to come as a pair, 11 characters
    are needed for their presense. E,g. PG and TR would only use 6.

    Maybe PING:T instead of PING,TRACE ...?

    The FTSC documents current practice in FidoNet. The PING and TRACE flags were implemented this way by ZC2, followed shortly by ZC1. Personally, if the length of the flags were a serious issue, they could easily be shortened to PNG and TRC, but this would have to be done by the *Cs, not directly by the FTSC.

    Andrew

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)
  • From Wilfred van Velzen@2:280/464 to Bj”rn Felten on Tue Jun 8 09:11:55 2021
    Hi Bj”rn,

    On 2021-06-07 22:05:25, you wrote to Carlos Navarro:

    Maybe PING:T instead of PING,TRACE ...?

    Or maybe abandon that stupid PING/TRACE idea entirely?

    It's not stupid at all! It's a very useful tool to test netmail routing, without bothering sysops, and depend on them sending replies. (You take the human factor out of it).

    With the Fidoweb working (even with certain ZC guys and their years
    long grudge against major Fidoweb operators) there seems like there's
    any need to check the routing with a shitload of netmail.

    The fidoweb is more about echomail then netmail. But of course netmail will also travel along those "none standard" routes. The more reason to have a tool that can show netmail paths, when it travels these non standard routes...

    Bye, Wilfred.
    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Alexey Vissarionov@2:5020/545 to Wilfred van Velzen on Tue Jun 8 13:11:30 2021
    Good ${greeting_time}, Wilfred!

    08 Jun 2021 09:11:54, you wrote to Bj”rn Felten:

    Maybe PING:T instead of PING,TRACE ...?
    Or maybe abandon that stupid PING/TRACE idea entirely?
    It's not stupid at all! It's a very useful tool to test netmail
    routing, without bothering sysops, and depend on them sending
    replies. (You take the human factor out of it).

    You too: the sysops see these messages anyway, and if there are too many, that becomes very annoying.

    That's exactly the reason why I've removed the PING flag from my nodelist line and shot down the robot. Once anyone would try to send it to me, they'll get a manually crafted fuqoff reply, or, most likely, no reply at all.

    The more reason to have a tool that can show netmail paths, when it travels these non standard routes...

    ... means the more reason to not supporting it.


    --
    Alexey V. Vissarionov aka Gremlin from Kremlin
    gremlin.ru!gremlin; +vii-cmiii-ccxxix-lxxix-xlii

    ... :wq!
    --- /bin/vi
    * Origin: ::1 (2:5020/545)
  • From Wilfred van Velzen@2:280/464 to Alexey Vissarionov on Tue Jun 8 13:05:14 2021
    Hi Alexey,

    On 2021-06-08 13:11:30, you wrote to me:

    Maybe PING:T instead of PING,TRACE ...?
    Or maybe abandon that stupid PING/TRACE idea entirely?
    It's not stupid at all! It's a very useful tool to test netmail
    routing, without bothering sysops, and depend on them sending
    replies. (You take the human factor out of it).

    You too: the sysops see these messages anyway, and if there are too many, that becomes very annoying.

    That's by choice. You could configure your system so it doesn't archive the received and sent PING mails, so you would see none at all.

    So you are annoyed by your own inability to configure your system?

    Bye, Wilfred.
    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Andrew Leary@1:320/219 to Wilfred van Velzen on Tue Jun 8 07:11:10 2021
    Hello Wilfred!

    08 Jun 21 13:05, you wrote to Alexey Vissarionov:

    That's by choice. You could configure your system so it doesn't
    archive the received and sent PING mails, so you would see none at
    all.

    MBSE works this way; the only way I know that a PING or TRACE message was processed is if I check the logs.

    Andrew

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)
  • From Wilfred van Velzen@2:280/464 to Andrew Leary on Tue Jun 8 13:26:12 2021
    Hi Andrew,

    On 2021-06-08 07:11:10, you wrote to me:

    That's by choice. You could configure your system so it doesn't
    archive the received and sent PING mails, so you would see none at
    all.

    MBSE works this way; the only way I know that a PING or TRACE message was processed is if I check the logs.

    In FMail it's configurable:

    Keep PING requests

    Keep a copy of PING request messages after processing. These
    are the received messages addressed to PING on your system.
    The copy is saved in the received netmail area.

    BTW: There is no option to keep TRACE requests, because
    they are in transit mails destined for other systems. They
    are forwarded to their destination without keeping a copy.

    Keep PING responses

    Keep a copy of PING response messages after they are sent.
    The copy is saved in the sent netmail area.

    Keep TRACE responses

    Keep a copy of TRACE response messages after they are sent.
    The copy is saved in the sent netmail area.


    If I set them all to 'No', I get the same behaviour as in your situation.


    Bye, Wilfred.
    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Alexey Vissarionov@2:5020/545 to Wilfred van Velzen on Tue Jun 8 14:46:00 2021
    Good ${greeting_time}, Wilfred!

    08 Jun 2021 13:05:14, you wrote to me:

    Maybe PING:T instead of PING,TRACE ...?
    Or maybe abandon that stupid PING/TRACE idea entirely?
    It's not stupid at all! It's a very useful tool to test netmail
    routing, without bothering sysops, and depend on them sending
    replies. (You take the human factor out of it).
    You too: the sysops see these messages anyway, and if there are
    too many, that becomes very annoying.
    That's by choice. You could configure your system so it doesn't
    archive the received and sent PING mails, so you would see none
    at all. So you are annoyed by your own inability to configure
    your system?

    I prefer to see what is going on. And how to configure _my_ system is _my_ choise.

    And lots of messages sent to _my_ system could be annoying for _me_.


    --
    Alexey V. Vissarionov aka Gremlin from Kremlin
    gremlin.ru!gremlin; +vii-cmiii-ccxxix-lxxix-xlii

    ... GPG: 8832FE9FA791F7968AC96E4E909DAC45EF3B1FA8 @ hkp://keys.gnupg.net
    --- /bin/vi
    * Origin: ::1 (2:5020/545)
  • From Alexey Vissarionov@2:5020/545 to Wilfred van Velzen on Tue Jun 8 15:05:50 2021
    Good ${greeting_time}, Wilfred!

    08 Jun 2021 13:26:12, you wrote to Andrew Leary:

    That's by choice. You could configure your system so it doesn't
    archive the received and sent PING mails, so you would see none
    at all.
    MBSE works this way; the only way I know that a PING or TRACE
    message was processed is if I check the logs.
    In FMail it's configurable

    In HPT you may simply rewrite the robot (that's just a few lines of Perl code) any way you wish.

    Whether you _can_ do that, of course.


    --
    Alexey V. Vissarionov aka Gremlin from Kremlin
    gremlin.ru!gremlin; +vii-cmiii-ccxxix-lxxix-xlii

    ... :wq!
    --- /bin/vi
    * Origin: ::1 (2:5020/545)
  • From Wilfred van Velzen@2:280/464 to Alexey Vissarionov on Tue Jun 8 14:15:14 2021
    Hi Alexey,

    On 2021-06-08 14:46:00, you wrote to me:

    That's by choice. You could configure your system so it doesn't
    archive the received and sent PING mails, so you would see none
    at all. So you are annoyed by your own inability to configure
    your system?

    I prefer to see what is going on.

    Do you read in-transit netmail?

    And how to configure _my_ system is _my_ choise.

    Of course, but then it's your own choice to get annoyed...


    Bye, Wilfred.
    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Alexey Vissarionov@2:5020/545 to Wilfred van Velzen on Tue Jun 8 15:46:46 2021
    Good ${greeting_time}, Wilfred!

    08 Jun 2021 14:15:14, you wrote to me:

    That's by choice. You could configure your system so it doesn't
    archive the received and sent PING mails, so you would see none
    at all. So you are annoyed by your own inability to configure
    your system?
    I prefer to see what is going on.
    Do you read in-transit netmail?

    No (and you can see the ENC flag in my nodelist line). But I read netmail addressed to my node.

    And how to configure _my_ system is _my_ choise.
    Of course, but then it's your own choice to get annoyed...

    I solved this problem in the most effective way: no robot - no problem.


    --
    Alexey V. Vissarionov aka Gremlin from Kremlin
    gremlin.ru!gremlin; +vii-cmiii-ccxxix-lxxix-xlii

    ... that's why I really dislike fools.
    --- /bin/vi
    * Origin: ::1 (2:5020/545)
  • From Wilfred van Velzen@2:280/464 to Alexey Vissarionov on Tue Jun 8 16:27:36 2021
    Hi Alexey,

    On 2021-06-08 15:46:46, you wrote to me:

    And how to configure _my_ system is _my_ choise.
    Of course, but then it's your own choice to get annoyed...

    I solved this problem in the most effective way: no robot - no problem.

    I think it's the wrong solution for a non-existent problem! ;)

    Bye, Wilfred.
    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Sean Dennis@1:18/200 to Wilfred van Velzen on Tue Jun 8 17:58:57 2021
    Wilfred van Velzen wrote to Alexey Vissarionov <=-

    I solved this problem in the most effective way: no robot - no problem.
    I think it's the wrong solution for a non-existent problem! ;)

    It is a problen when you don't know how to set up your system correctly.

    For the record, I support the PING and TRACE flags. I have used the PING capability quite often over the years and find it very useful. MBSE
    supports PING and we're working on supporting TRACE also.

    Later,
    Sean

    ... "Talk is cheap. Show me the code." - Linus Torvalds
    --- MultiMail/Linux
    * Origin: Outpost BBS (1:18/200)
  • From Andrew Leary@1:320/219 to Sean Dennis on Tue Jun 8 23:25:59 2021
    Hello Sean!

    08 Jun 21 17:58, you wrote to Wilfred van Velzen:

    For the record, I support the PING and TRACE flags. I have used the
    PING capability quite often over the years and find it very useful.
    MBSE supports PING and we're working on supporting TRACE also.

    MBSE supports both PING and TRACE functionality.

    Andrew


    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)
  • From Carlos Navarro@2:341/234.1 to Andrew Leary on Wed Jun 9 08:44:46 2021
    07 Jun 2021 21:58, you wrote to me:

    As these two flags are likely to come as a pair, 11 characters
    are needed for their presense. E,g. PG and TR would only use 6.

    Maybe PING:T instead of PING,TRACE ...?

    The FTSC documents current practice in FidoNet. The PING and TRACE
    flags were implemented this way by ZC2, followed shortly by ZC1. Personally, if the length of the flags were a serious issue, they
    could easily be shortened to PNG and TRC, but this would have to be
    done by the *Cs, not directly by the FTSC.

    Yes Andrew, I know. Thank you. Just an informal comment to Kee's comment.

    I just thought that, as TRACE always goes with PING, it could be as a parameter instead of a separate flag.
    However, a node could perfectly have just the TRACE flag (at least Fmail supports this).

    But anyway, it's a bit late :-) and I suppose it's fine like it is.

    Carlos

    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: costa blanca, Spain (2:341/234.1)
  • From Carlos Navarro@2:341/234.1 to Andrew Leary on Wed Jun 9 10:55:38 2021
    29 Apr 2021 12:29, you wrote to All:

    === Cut ===
    Publication: FTS-4010
    Revision: 1
    Title: The PING and TRACE flags
    [...]
    PING
    ----

    Specified as exactly "PING" with no arguments. Nodes flying this
    flag will adhere to the following functionality:

    If a message destined to user "PING" (case insensitive) arrives
    at its final destination and this final destination flies the
    PING flag, then the receiving node will bounce the message back
    ^^^^^^^^^^^^^^^^^^
    to the original sender clearly quoting all the original via
    lines.

    Should the body content of the original message be included, or just the via lines?
    I've seen both cases.

    Carlos

    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: costa blanca, Spain (2:341/234.1)
  • From Wilfred van Velzen@2:280/464 to Carlos Navarro on Wed Jun 9 11:17:58 2021
    Hi Carlos,

    On 2021-06-09 10:55:38, you wrote to Andrew Leary:

    PING
    ----

    Specified as exactly "PING" with no arguments. Nodes flying this
    flag will adhere to the following functionality:

    If a message destined to user "PING" (case insensitive) arrives
    at its final destination and this final destination flies the
    PING flag, then the receiving node will bounce the message back
    ^^^^^^^^^^^^^^^^^^
    to the original sender clearly quoting all the original via
    lines.

    Should the body content of the original message be included, or just the via lines? I've seen both cases.

    The body of the message is nice to have, but not a requirement. VIA lines are essential IMHO, but unfortunately I've seen PING responses without them...

    Bye, Wilfred.
    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Michiel van der Vlist@2:280/5555 to Sean Dennis on Wed Jun 9 17:23:02 2021
    Hello Sean,

    On Tuesday June 08 2021 17:58, you wrote to Wilfred van Velzen:


    For the record, I support the PING and TRACE flags. I have used the
    PING capability quite often over the years and find it very useful.
    MBSE supports PING and we're working on supporting TRACE also.

    I did several tests to provoke a response from your PING, but so far, six hours later, I have received no response. The last attempt was crashed to 1:18/200 at 09:25 UTC.


    Cheers, Michiel
    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.org (2:280/5555)
  • From Sean Dennis@1:18/200 to Andrew Leary on Wed Jun 9 01:34:23 2021
    Andrew Leary wrote to Sean Dennis <=-

    MBSE supports both PING and TRACE functionality.

    I stand corrected. I misunderstood you when we discussed this last week ...

    I think that the return message for a PING request should have the subject
    of "PONG".

    Later,
    Sean

    ... Windows: Just another pane in the glass.
    --- MultiMail/Linux
    * Origin: Outpost BBS (1:18/200)
  • From Wilfred van Velzen@2:280/464 to Michiel van der Vlist on Wed Jun 9 18:24:30 2021
    Hi Michiel,

    On 2021-06-09 17:23:02, you wrote to Sean Dennis:

    For the record, I support the PING and TRACE flags. I have used the
    PING capability quite often over the years and find it very useful.
    MBSE supports PING and we're working on supporting TRACE also.

    MvdV> I did several tests to provoke a response from your PING, but so far, six
    MvdV> hours later, I have received no response. The last attempt was crashed to
    MvdV> 1:18/200 at 09:25 UTC.

    I got a response in about 12 minutes after sending the routed netmail.

    The return path:

    @Via 1:18/200@fidonet @20210609.161554.UTC mbfido 1.0.7.22
    @Via 1:3634/12 @20210609.161750.UTC SBBSecho 3.11-Linux r3.173
    @Via 1:229/426 @20210609.121709.LST D'Bridge 4
    @Via 1:229/426@fidonet @20210609.121709.LST O/T-Track+ 2.85
    @Via 2:280/464 @20210609.162142.681.UTC FMail-lnx64(Toss) 2.1.0.18-B20170815


    Bye, Wilfred.
    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Sean Dennis@1:18/200 to Wilfred van Velzen on Wed Jun 9 19:40:55 2021
    Wilfred van Velzen wrote to Michiel van der Vlist:

    MvdV> I did several tests to provoke a response from your PING, but so far, six
    MvdV> hours later, I have received no response. The last attempt was crashed to
    MvdV> 1:18/200 at 09:25 UTC.

    I have not seen any messages to me from Michiel in this echo nor via
    netmail. That's weird ...

    I got a response in about 12 minutes after sending the routed netmail.

    That's good to know it went that quickly!

    @Via 1:18/200@fidonet @20210609.161554.UTC mbfido 1.0.7.22
    @Via 1:3634/12 @20210609.161750.UTC SBBSecho 3.11-Linux r3.173
    @Via 1:229/426 @20210609.121709.LST D'Bridge 4
    @Via 1:229/426@fidonet @20210609.121709.LST O/T-Track+ 2.85
    @Via 2:280/464 @20210609.162142.681.UTC FMail-lnx64(Toss) 2.1.0.18-B20170815

    That path looks correct as I am connected to both Mark Lewis for regional
    mail and Nick Andre as my regular Fidonet feed.

    This is the first I've heard anything about it because my system doesn't
    notify me about PING and TRACE requests (as it shouldn't since this is an administrative issue).

    Thanks for your report. I greatly appreciate it.

    -- Sean



    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: Outpost BBS (1:18/200)
  • From Wilfred van Velzen@2:280/464 to Sean Dennis on Thu Jun 10 10:31:46 2021
    Hi Sean,

    On 2021-06-09 19:40:55, you wrote to me:

    MvdV> I did several tests to provoke a response from your PING, but
    so far, six
    MvdV> hours later, I have received no response. The last attempt was
    crashed to
    MvdV> 1:18/200 at 09:25 UTC.

    I have not seen any messages to me from Michiel in this echo nor via netmail. That's weird ...

    That's weird indeed. I hope it isn't because someone is filtering, that would be XAB...

    I got a response in about 12 minutes after sending the routed
    netmail.

    That's good to know it went that quickly!

    Some would call it slow. ;-)

    @Via 1:18/200@fidonet @20210609.161554.UTC mbfido 1.0.7.22
    @Via 1:3634/12 @20210609.161750.UTC SBBSecho 3.11-Linux r3.173
    @Via 1:229/426 @20210609.121709.LST D'Bridge 4
    @Via 1:229/426@fidonet @20210609.121709.LST O/T-Track+ 2.85
    @Via 2:280/464 @20210609.162142.681.UTC FMail-lnx64(Toss)
    2.1.0.18-B20170815

    That path looks correct as I am connected to both Mark Lewis for regional mail and Nick Andre as my regular Fidonet feed.

    I you want you could optimize your route for interzonal netmail, by sending some directly through Nick, since you already have a secure link.


    Bye, Wilfred.
    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)