See this document for a complete list of changes .....
https://openxp.uk/doc/changes.txt
Changes and bugfixes (w.r.t. OpenXP 5.0.46):
- Fido network
- Added handling of kludge REPLYTO
There is no "REPLYTO" kludge in Fidonet,
OpenXP 5.0.48 has been released...
Woohoo! I'm on it.
You like? :-))
What's NOT to like? I am still totally impressed how your simple recommendation (is it 2 years ago now?) steered me off my then chiselled-in-stone decision to stick with a Windows-based Apoint
or Winpoint. OpenXP's text based system is truly ideal for
messaging.
There is no "REPLYTO" kludge in Fidonet,
Oh?
= FUTURE4FIDO (2:310/31.3)
==================================================== Msg : 51 of 101
Snt From : Benny Pedersen
2:460/58 02 Dec 20 12:05:12 To : All
Subj : ...
========================================================================
======= @MSGID: 2:460/58 0000054d
@PID: tg_BBS_v0.6.2
@CHRS: CP866 2
@TGUID: 270364579
@REPLYTO 2:460/58 270364579
Hello :)
--- tg BBS v0.6.2
* Origin: Fido by Telegram BBS by Stas Mishchenkov (2:460/58)
========================================================================
=======
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.
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).
That's absolutely correct.
Using the REPLYTO address and ignoring the REPLYADDR could cause^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
issues and is not a correct implementation of FSC-0035.
That's also absolutely correct.
Using the REPLYTO address and ignoring the REPLYADDR could cause
issues and is not a correct implementation of FSC-0035.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
That's also absolutely correct.
What issues?
Techically, REPLYTO is working just fine (by OpenXP).
OpenXP 5.0.48 has been released
OpenXP 5.0.48 has been released
Something that may have gone unnoticed is that *outgoing* mail packets(*.pkt) are now backed up in the \SPOOL directory. Echomail and *routed* netmail packets are backed up in the appropriate sub-directory and will be automatically deleted in due course, whereas *crash* netmail packets will be backed up in the *root* of the \SPOOL directory and will *not* be automatically deleted.
Sysop: | Coz |
---|---|
Location: | Anoka, MN |
Users: | 2 |
Nodes: | 4 (0 / 4) |
Uptime: | 23:44:46 |
Calls: | 93 |
Files: | 4,557 |
Messages: | 215,646 |