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