MSGID: 2:280/464.47 5ff07c60
REPLY: 2:310/31.3@fidonet ec040151
PID: JamNNTPd/Linux 1
CHRS: LATIN-1 2
TZUTC: 0100
TID: CrashMail II/Linux 1.7
Martin wrote (2021-01-01):

 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> ===========================================================
===================

Sorry, I was confused and thought it had something to do with the MSGID and
reply linking. 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
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).

Using the REPLYTO address and ignoring the REPLYADDR could cause issues and is
not a correct implementation of FSC-0035. If this is not intended to be an
implementation of FSC-0035, maybe the Telegram Gateway and OpenXP should use
another kludge.

---
 * Origin:  (2:280/464.47)
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: 280/464 229/101 426