v1.0.2.26.zip as MyGUI\x20v1.0.2.26.zip (1669424)
This is not a properly escaped filename being sent by BinkD as it does
not follow the BINKP protocol specifications for filename escaping:
This is not a properly escaped filename being sent by BinkD as it doe not follow the BINKP protocol specifications for filename escaping:
http://ftsc.org/docs/fts-1026.001
On 13 Jan 2022 at 10:15a, Stas Mishchenkov pondered and said...
This is not a properly escaped filename being sent by BinkD as
it doe not follow the BINKP protocol specifications for
filename escaping:
http://ftsc.org/docs/fts-1026.001
Hi Stas
I am not a developer so am unsure what it is you are saying by posting this reply?
I am not a developer so am unsure what it is you are saying by posting this reply?
James has quoted a FTS proposal. (hex chars are represent as \nn)
Stats quoted the accepted technical standard. (hex chars are presented
as \xnn, but should also accept/understand any mailer using \nn) - with
a later date IIRC.
binkd has implemented the procotol as per the standard, whereas james has implemented as per the proposal.
Ergo, while he is saying binkd is doing it wrong, it is in fact mystic that is doing it wrong (from a standards point of view).
James has quoted a FTS proposal. (hex chars are represent as \nn)
Stats quoted the accepted technical standard. (hex chars are presented
as \xnn, but should also accept/understand any mailer using \nn) -
with a later date IIRC. binkd has implemented the procotol as per the
standard, whereas james has implemented as per the proposal. Ergo,
while he is saying binkd is doing it wrong, it is in fact mystic that
is doing it wrong (from a standards point of view).
OK thanks for the clarification. I wonder if he monitors this echo? If not I could always pass this info on.
Like it's always the same. It's never Mystic's problem, the others are doing it wrong. (Why should the guru read the fucking manual? Why should he ask for advice? He always knows better ...)
Yes, FTS did change it but they changed it *15 YEARS* after the other method was already in the wild and implemented. That change doesn't magically make legacy software work differently.
method was already in the wild and implemented. That change doesn't magically make legacy software work differently.
sure ;-P
https://github.com/pgul/binkd/blob/45986b77161a366ea3d258a01dad442d3d21d81
binkd has implemented the procotol as per the standard, whereas james has implemented as per the proposal.
I can't figure out what you're trying to show there, but I don't think
you know either.
Thats not the escaping code if that is what you're
going for. This is:
char *strquote (char *s, int flags)
{
... (cut some stuff) ...
sprintf (r + i, "\\x%02x", *(unsigned char *) s);
}
And at least in the version you're showing me, BINKD does not implement the per-connection option for legacy escaping as per the FTS update.
If
it did, then Paul would not have the issue he's having and thus why I
sent him in this direction.
Paul's issue cannot be solved unless BINKD is updated or his downlink changes software versions. There is literally nothing I can do to help him. I don't care if BINKD wants to support escaping in legacy mode as per FTS or not personally.
And for the record. Here's Mystic's code for this. It more closely follows FTS in comparison to the link I just looked at which you sent, so I don't know what you're complaining about:
Function TBinkP.EscapeFileName (Const Str: String) : String;^^^ wrong
{ Replace illegal characters with \## escaped sequences }
Else
{ 0=Original BINKP (Argus, IREX, Amiga) }
{ 1=Updated (Post 2010+ FTS updates ie BINKD uses this) }
binkd has implemented the procotol as per the standard, whereas
james has implemented as per the proposal.
Just for clarification: Mystic does both. Or at least it does as of a couple hours after the issue was first brought to my attention (which was a couple years ago I believe).
binkd has implemented the procotol as per the standard, whereas james has implemented as per the proposal.
Just for clarification: Mystic does both. Or at least it does as of a couple hours after the issue was first brought to my attention
(which was a couple years ago I believe).
And in the latest version it also allows it to be configured on a per-node basis, so if you have one downlink with a legacy mailer that
won't work with anything but /## and one that only supports /x## you can configure each node accordingly.
Did I get that right?
On Sat, 15 Jan 2022 at 08:30 +1100, you wrote to James Coyle:
Did I get that right?
No. Binkd encodes filename correctly according to FTS. Your downlink must update their software to a newer version that understands
proper encoding.
I know how Binkd encodes files.Did I get that right?No. Binkd encodes filename correctly according to FTS. Your
downlink must update their software to a newer version that
understands proper encoding.
My question was directed at James.
My question was directed at James.
Since asked question in BINKD echo (as opposed to netmail), I felt free to answer it. And my aim was to explain why you didn't get it right.
Are you saying that Mystic's binkp will send a file to a node using an escape sequence of \## or \x## depending on how the sysop has configured that node in Mystic configuration?
Are you saying that Mystic's binkp will send a file to a node using
an escape sequence of \## or \x## depending on how the sysop has
configured that node in Mystic configuration?
Yes.
For incoming filenames Mystic handles all variations.
For outbound filenames it uses \## (because any mailer that does \x##
will also accept \##, but mailers that accept \## wont accept \x##). Its the most compatible method. This is how it worked up to A47.
Then in A48 I went further and added in the option in the node configuration so you can choose per-connection just in case there someday is a newer mailer in the future that does \x## but can't do \##...
This A48 addition was as a result of the recommendation that was pointed out to me in FTS-1026.001: http://ftsc.org/docs/fts-1026.001
"In FSP-1011.003 the escape method is specified as two hexadecimal digits preceded with a backslash (e.g. a whitespace is transmitted as "\20"). Some mailers have implemented that method. It is advised to have a
setting for specific nodes to sent escaped characters using the incorrect method."
Mystic implements the recommendation made in the last sentence but BINKD does not as far as I know?
So the solution to Paul's problem is to have
BINKD follow the FTS recommendation, or for the person to upgrade their software version. I can't help him.
This is not what FTS-1026 recommends. It also doesn't work with every legacy mailer. What you don't understand is that FSP-1011 specified the wrong escape method.
This option was meant for mailers that uses the incorrect escape
sequence \## (like Mystic does).
So you expect that binkd implement a feature that is not implemented in a
I would also recommend upgrading from the Mystic mailer to some FTS compliant mailer and to one that supports the faster binkp/1.1 protocol.
This is not what FTS-1026 recommends. It also doesn't work with
every legacy mailer. What you don't understand is that FSP-1011
specified the wrong escape method.
FTS-1026 recommends it to be a per-connection configurable option as I have shown here, which is implemented in Mystic. It is not an option in BINKD and if it were, this would not be a problem for Paul. Those are
the facts.
This option was meant for mailers that uses the incorrect escape
sequence \## (like Mystic does).
Again, you're literally quoting a message that says Mystic can operate in either way, which is the FTS recommendation.
Grow up and stop being so disingenious all of the time.
So you expect that binkd implement a feature that is not
implemented in a
No, as I have said in messages prior: I don't care if BINKD implements it as an option or not. But the only way for Paul's problem to be solved is for BINKD to implement the FTS recommendation on how to handle escaping.
I cannot help him.
Stop trying twist everything to create confusion, and just let it go.
I would also recommend upgrading from the Mystic mailer to some FTS
compliant mailer and to one that supports the faster binkp/1.1
protocol.
As with every single thing you've said in this message, none of this is true.
The difference between BINKP 1.0/NR and BINKP 1.1 has nothing to do with performance. It simply sends an extra round of EOB for handling file requests differently.
You're saying the \## was a typo and not used anywhere, which is absolutely false. The FTS documentation on the subject specifically says mailers DO use that escaping. In fact, older mailers either did no escaping at all or only use \##.
There are no FTS compliance issues with Mystic's echomail, and it
probably transmits more FTN-style mail than any other software.
If there was an actual problem then speak up.
And Paul has worked with
me enough to know if there was a problem I would fix it for him quickly, and he wouldn't have to go through this drama-filled daycare to get help.
It doesn't matter how many more years you go on trying to harass me and spew a bunch of misinformation about me or Mystic, reality will never agree with you.
I am sure everyone here is more than tired of this, so just move on.
FTS-1026 recommends it to be a per-connection configurable option as have shown here, which is implemented in Mystic. It is not an Ol> Ol> JC> Ol> JC> Ol> JC> Ol> JC> Ol> JC> Ol> JC> JC> option BINKD Ol> JC> Ol> JC> and if it Ol> JC> Ol> JC> were, this Ol> JC> Ol> Ol> JC> Ol> JC> JC> would not Ol> JC> Ol> Ol> JC> Ol> JC> JC> be a Ol> JC> Ol> JC> Ol> JC> Ol> JC> Ol> JC> Ol> JC> problem Ol> JC> Ol> JC> Ol> JC> Ol> JC> for Ol> JC> JC> Paul. Ol> JC> Ol> JC> Ol> Ol> JC> Ol> JC> Ol> Ol> JC> Ol> JC> JC> Ol> JC> JC> Those are the Ol> JC> Ol> JC> Ol> JC> Ol> JC> facts.
Do you really believe everyone is too stupid to recognize your discussion strategy?
It always was and still is \x##.
That is not the point. Why would anyone who is using a standard compliant mailer care, that Mystic can be configured to send incorrect escape
codes? (or has to be explicitly configured for sending the correct
escape code)
And its sad that you convinced non-FTN-techincal people like Paul and Deon that you are some sort of subject matter expert (when everyone who actually does this stuff knows you're a subject matter idiot).
Anyway, I dont use it - we know it cannot handle files with spaces in it from a binkd mailer.
is not), but that is moot - if your software doesnt work with it, I dont get why you wouldnt want to make it work with it, even if the binkd development team werent interested in "fixing" it the way you want it "fixed".
Anyway, I dont use it - we know it cannot handle files with spaces in BF> d> BF> d> BF> d> BF> d>
from a binkd mailer.
After all, there's a plethora of alternatives, many of them Open
Source (like the product discussed in this echo), so why insist on using something that you can see never will fix obvious bugs?
spaces in BF> d> BF> d> BF> d> BF> d>Anyway, I dont use it - we know it cannot handle files with
from a binkd mailer.
is not), but that is moot - if your software doesnt work with it, I
dont get why you wouldnt want to make it work with it, even if the
binkd development team werent interested in "fixing" it the way you
want it "fixed".
My software works fine with it, there is nothing I could possibly change.
It handles all formats of escaping and its configurable per node.
I covered this in every response to you, but you don't seem to care.
So instead I'll tell a story because I know he was reading this
thread:
To this day, Mystic might be the only software I've seen working
across the board (net/echo) with same-zone different-domain networks
in 5D.
It came at the cost of Marc and bickering and maybe ruining our own collaboration, but at least the software works. :(
Is there any other mailer than Argus and Irex that doesn't understand \x##?
few mailers that cannot cope with the standard \x##. I believe they all send the M_NUL VER command. Why not auto-detect the broken mailer and switch to the incorrect escape \## automatically?
Is there any other mailer than Argus and Irex that doesn't understand \x##?
* I believe the inclusion of \## in FTS-1026 was more harmful than it
did any good in the long term.
On 2022 Jan 19 13:48:08, you wrote to All:
Is there any other mailer than Argus and Irex that doesn't
understand \x##?
radius and taurus are from the argus family... or is it argus and taurus that are from the radius family? i always get the first two confused...
i'm not even sure which ones of that family are still being updated today...
i just thought i'd mention them since they may have the same
defect in them...
And if the above total mangling of the comments isn't enough to convince you, please stay shy of this inferior product.
..
/me waves from across the network :)
i have sbbsecho and binkd working here with FTN 5D BSO where each different network has its own outbound... even the 18 or so othernets
that share 8 zones, i think, between them... my outbound directory has
happened... it is in the past, though, and i/we have moved on :)
radius and taurus are from the argus family... or is it argus and
taurus that are from the radius family? i always get the first two
confused...
One big happy family ;).
CProductNameFull = 'Taurus (based on Radius (based on Argus))'
i'm not even sure which ones of that family are still being updated
today...
AFAIK development has stopped for all three some time ago.
Anyone still using Argus should upgrade to Radius or Taurus. (I
haven't used any of the programs, so I don't know if it's an easy
upgrade and would work for everyone).
additional noise and an opportunity for misconfiguration. We know the
few mailers that cannot cope with the standard \x##. I believe they all send the M_NUL VER command. Why not auto-detect the broken mailer and switch to the incorrect escape \## automatically?
2) Those that escape with \x## but still allow \## from the mailer
side
BinkD (I think MBSE does too)
Both MBSE and newer Mystic provides the option to support \## or \x## escaping per connection as noted. This seems to be what FTS
recommends as a way to handle this mess. It does seem to be a viable solution but your idea is great too!
Another confusing thing (and is partially responsible for how Mystic
got it wrong originally) is that when you look up BinkP on Wikipedia
it links to the old specifications released by the authors of Argus.
If I remember correctly it was really difficult to even find FTS documentation when I was first implementing FTN into Mystic so these
kind of links proved to be a pain point.
My testbed was Argus, IREX, and BinkD and \## was the only thing that worked with all of them as I recall, and it matches what Wikipedia
says so thats what Mystic used back then...
Unfortunately that is wrong as I later found Radius mailers that only supported \x## and I believe BinkIT falls into this category as well.
I think in hindsight it might have been better for FTS to leave it as
\## since legacy mailers used it and could not be updated, but it is
what it is!
BinkD (the original implementation of BinkP) has always used \x## as far as I know.
BinkD (the original implementation of BinkP) has always used \x##
as far as I know.
BinkD was changed to *accept* '\##' however, back in 2002: https://github.com/pgul/binkd/commit/b4e7b17b7f0621abc1b3017307dd1382e aa039d9
If you ever need clarification on anything related to the FTSC, please don't hesitate to netmail me.
I think in hindsight it might have been better for FTS to leave it
as \## since legacy mailers used it and could not be updated, but
it is what it is!
BinkD (the original implementation of BinkP) has always used \x## as far as I know.
BinkD (the original implementation of BinkP) has always used \x##
as far as I know.
BinkD was changed to *accept* '\##' however, back in 2002:
https://github.com/pgul/binkd/commit/b4e7b17b7f0621abc1b3017307dd1382e
aa039d9
That explains why when James tested against BinkD it had no issues with him using \##.
The most compatible way to do things is to accept both on incoming, while sending using \x##, unless configured otherwise on a per node basis, or when you detect you are connected to a known mailer that uses \## (Argus or IRex.)
I would have to test further to populate the list of mailers that
require setting the WrongEscape option (as it's labeled in the mbcico code.)
If you ever need clarification on anything related to the FTSC, please don't hesitate to netmail me.
And it's only a problem with filenames that contains a whitespace character.It's also a problem for filenames that contain any other "unsafe" characters that "SHOULD" (according to FTS-1026) be escaped.
And it's only a problem with filenames that contains a whitespaceIt's also a problem for filenames that contain any other "unsafe" characters that "SHOULD" (according to FTS-1026) be escaped.
character.
Rob wrote (2022-01-20):
And it's only a problem with filenames that contains a whitespaceIt's also a problem for filenames that contain any other "unsafe" characters that "SHOULD" (according to FTS-1026) be escaped.
character.
You mean like 0x00 to 0x1F (control chars) and backslash (0x53)? How often do you use these in filenames? ;)
And it's only a problem with filenames that contains a whitespace
character.
It's also a problem for filenames that contain any other "unsafe"
characters that "SHOULD" (according to FTS-1026) be escaped.
You mean like 0x00 to 0x1F (control chars) and backslash (0x53)? How
often do you use these in filenames? ;)
Preferably, never, but I'm not in control of what characters are used in filenames received BinkP, the sender is.
Ideally, the BinkP spec would have been even *more* restrictive in the filename characters allowed (escaped or not), because filenames with colons, semicolons, asterisks, question marks and vertical-bars (pipes) are *not* what I would call "safe", yet they're expressly allowed as "safe" in the spec. :-(
| Sysop: | digital man |
|---|---|
| Location: | Riverside County, California |
| Users: | 1,065 |
| Nodes: | 17 (0 / 17) |
| Uptime: | 102:13:54 |
| Calls: | 501,414 |
| Calls today: | 17 |
| Files: | 109,435 |
| U/L today: |
3 files (28,310K bytes) |
| D/L today: |
24,618 files (11,508M bytes) |
| Messages: | 296,991 |
| Posted today: | 6 |