• OpenXP 5.0.48 released

    From Martin Foster@2:310/31.3 to Oli on Fri Jan 1 12:03:00 2021
    Hello Oli!

    *** Tuesday 29.12.20 at 08:53, Oli wrote to Martin Foster:

    See this document for a complete list of changes .....
    https://openxp.uk/doc/changes.txt

    Changes and bugfixes (w.r.t. OpenXP 5.0.46):

    - Fido network
    - Added handling of kludge REPLYTO

    There is no "REPLYTO" kludge in Fidonet,

    Oh?

    = FUTURE4FIDO (2:310/31.3) ====================================================
    Msg : 51 of 101 Snt
    From : Benny Pedersen 2:460/58 02 Dec 20 12:05:12
    To : All
    Subj : ... =============================================================================== @MSGID: 2:460/58 0000054d
    @PID: tg_BBS_v0.6.2
    @CHRS: CP866 2
    @TGUID: 270364579
    @REPLYTO 2:460/58 270364579
    Hello :)

    --- tg BBS v0.6.2
    * Origin: Fido by Telegram BBS by Stas Mishchenkov (2:460/58)
    @PATH: 460/58 280/464 310/31 ===============================================================================

    Regards,
    Martin

    --- OpenXP 5.0.48
    * Origin: OpenXP-Team (2:310/31.3)
  • From Martin Foster@2:310/31.3 to August Abolins on Fri Jan 1 13:16:00 2021
    Hello August!

    *** Wednesday 30.12.20 at 23:58, August Abolins wrote to Martin Foster:

    OpenXP 5.0.48 has been released...

    Woohoo! I'm on it.

    You like? :-))

    What's NOT to like? I am still totally impressed how your simple recommendation (is it 2 years ago now?) steered me off my then chiselled-in-stone decision to stick with a Windows-based Apoint
    or Winpoint. OpenXP's text based system is truly ideal for
    messaging.

    I don't remember exactly what I said but I *do* remember referring to
    it as an adventure. Long may the adventure continue :-)

    Regards,
    Martin

    --- OpenXP 5.0.48
    * Origin: Bitz-Box - Bradford - UK (2:310/31.3)
  • From Martin Foster@2:310/31.3 to Oli on Sun Jan 3 11:16:00 2021
    Hello Oli!

    *** Saturday 02.01.21 at 15:00, Oli wrote to Martin Foster:

    There is no "REPLYTO" kludge in Fidonet,

    Oh?

    = FUTURE4FIDO (2:310/31.3)
    ==================================================== Msg : 51 of 101
    Snt From : Benny Pedersen
    2:460/58 02 Dec 20 12:05:12 To : All
    Subj : ...
    ========================================================================
    ======= @MSGID: 2:460/58 0000054d
    @PID: tg_BBS_v0.6.2
    @CHRS: CP866 2
    @TGUID: 270364579
    @REPLYTO 2:460/58 270364579
    Hello :)

    --- tg BBS v0.6.2
    * Origin: Fido by Telegram BBS by Stas Mishchenkov (2:460/58)
    ========================================================================
    =======

    Sorry, I was confused and thought it had something to do with the
    MSGID and reply linking.

    That's OK, no problem, we all get confused from time to time :)

    I saw REPLYID kludges generated by some software and replyTo is used internally by some message base formats.

    I still don't understand what the REPLYTO kludge is good for in this case.

    It's used for netmail replies to echomail messages originating on the Telegram side of the gateway.

    It is also unspecified as a single kludge and not covered by any
    standard or proposal. There is FSC-0035 (http://ftsc.org/docs/fsc- 0035.001) which defines REPLYADDR *and* REPLYTO in combination (both
    have to be included in the message).

    That's absolutely correct.

    Using the REPLYTO address and ignoring the REPLYADDR could cause
    issues and is not a correct implementation of FSC-0035.
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    That's also absolutely correct.

    If this is not intended to be an implementation of FSC-0035, maybe the Telegram Gateway

    I cannot possibly pass comment on the Telegram Gateway software
    developers' intentions in this respect because I'm not conversant with the way in which his software works.

    and OpenXP should use another kludge.

    However, OpenXP doesn't insert the kludge, it recognises an implementation
    of the kludge and takes action on it when necessary.

    Regards,
    Martin

    --- OpenXP 5.0.48
    * Origin: Bitz-Box - Bradford - UK (2:310/31.3)
  • From August Abolins@2:221/1.58 to Martin Foster on Sun Jan 3 11:24:00 2021
    Hello Martin!

    ** On Sunday 03.01.21 - 11:16, Martin Foster wrote to Oli:

    It is also unspecified as a single kludge and not covered by
    any standard or proposal. There is FSC-0035 (http://
    ftsc.org/docs/fsc-0035.001) which defines REPLYADDR *and*
    REPLYTO in combination (both have to be included in the
    message).

    That's absolutely correct.

    Ah.. but it seems that application of any particular kludge
    (especially if it is just in the documented proposal stage) is
    optional. Therefore, there is nothing technically wrong with
    REPLYTO appearing by itself if it doesn't break anyone's system.

    Infact, MSGID has appeared by itself by many systems (and may
    still do). However.. that one is now documented as an FTS and to
    be used in conjunction with the REPLYID.

    But.. there will always be people insisting to use old software
    that can't be updated to use anything beyond what's in FTS-0001



    Using the REPLYTO address and ignoring the REPLYADDR could cause
    issues and is not a correct implementation of FSC-0035.
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    That's also absolutely correct.

    What issues? Techically, REPLYTO is working just fine (by
    OpenXP). Why is even REPLYADRR required when all equivalent info
    is already present in *other* parts of the header?

    Too bad the FTC-0035 doesn't provide working examples.
    --
    ../|ug

    --- OpenXP 5.0.48
    * Origin: ----------Do Not Fold, Spindle or Mutilate.---------- (2:221/1.58)
  • From Martin Foster@2:310/31.3 to August Abolins on Tue Jan 5 11:24:00 2021
    Hello August!

    *** Sunday 03.01.21 at 11:24, August Abolins wrote to Martin Foster:

    [snip]
    Using the REPLYTO address and ignoring the REPLYADDR could cause
    issues and is not a correct implementation of FSC-0035.
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    That's also absolutely correct.

    What issues?

    I was actually replying to the text which I'd "underlined" :)

    Techically, REPLYTO is working just fine (by OpenXP).

    Yes it is and thanks for confirming that :)

    Regards,
    Martin

    --- OpenXP 5.0.48
    * Origin: Bitz-Box - Bradford - UK (2:310/31.3)
  • From Martin Foster@2:250/1.333 to All on Fri Jan 15 11:10:32 2021
    Greetings All!

    Sunday December 27 2020 11:07, Martin Foster wrote to All:

    OpenXP 5.0.48 has been released

    Something that may have gone unnoticed is that *outgoing* mail packets(*.pkt) are now backed up in the \SPOOL directory. Echomail and *routed* netmail packets are backed up in the appropriate sub-directory and will be automatically deleted in due course, whereas *crash* netmail packets will be backed up in the *root* of the \SPOOL directory and will *not* be automatically deleted.

    Regards,
    Martin

    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: Bitz-Box - Bradford - UK (2:250/1.333)
  • From Martin Foster@2:310/31.3 to All on Wed Jan 20 11:43:00 2021
    Greetings All!

    *** Friday 15.01.21 at 11:10, Martin Foster wrote to All:

    OpenXP 5.0.48 has been released

    Something that may have gone unnoticed is that *outgoing* mail packets(*.pkt) are now backed up in the \SPOOL directory. Echomail and *routed* netmail packets are backed up in the appropriate sub-directory and will be automatically deleted in due course, whereas *crash* netmail packets will be backed up in the *root* of the \SPOOL directory and will *not* be automatically deleted.

    Update .....

    All .REQ files will also be backed up in the root of the \SPOOL directory
    but will *not* be automatically deleted.

    Regards,
    Martin

    --- OpenXP 5.0.48
    * Origin: OpenXP-Team (2:310/31.3)