MSGID: 2:221/1.58@fidonet ec143486
REPLY: 2:310/31.3@fidonet ec11c236
PID: OpenXP/5.0.48 (Win32)
CHRS: ASCII 1
TZUTC: -0500
Hello Martin!

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

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

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



 O>> Using the REPLYTO address and ignoring the REPLYADDR could cause
 O>> issues and is not a correct implementation of FSC-0035.
 MF>               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 MF> 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)
SEEN-BY: 1/123 90/1 105/81 120/340 123/131 124/5016 154/10 203/0 221/1
SEEN-BY: 221/6 360 226/30 227/114 702 229/101 424 426 664 1016 1017
SEEN-BY: 240/5832 249/110 206 317 400 280/464 5003 288/100 292/854
SEEN-BY: 292/8125 310/31 317/3 322/757 342/200 396/45 423/81 120 712/848
SEEN-BY: 770/1 2452/250
PATH: 221/1 280/464 229/101 426