Subj : OpenXP 5.0.48 released
To   : Oli
From : Martin Foster
Date : Sun Jan 03 2021 11:16:00

Hello Oli!

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

 O>>> There is no "REPLYTO" kludge in Fidonet,

 MF>> Oh?

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

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

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

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

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

 O> 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.

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

That's absolutely correct.

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

 O> If this is not intended to be an implementation of FSC-0035, maybe the
 O> 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.

 O> 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)

.