MSGID: 2:310/31.3@fidonet ec11c236
REPLY: 2:280/464.47 5ff07c60
PID: OpenXP/5.0.48 (Win32)
CHRS: ASCII 1
TZUTC: 0000
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)
SEEN-BY: 1/123 90/1 105/81 120/340 123/131 124/5016 154/10 203/0 221/0
SEEN-BY: 226/30 227/114 702 229/101 424 426 664 1016 1017 240/5832
SEEN-BY: 249/110 206 317 400 280/464 5003 288/100 292/854 8125 310/31
SEEN-BY: 317/3 322/757 342/200 396/45 423/120 712/848 770/1 2452/250
PATH: 310/31 280/464 229/101 426