James wrote (2022-01-17):

 de>> Are you saying that Mystic's binkp will send a file to a node using
 de>> an escape sequence of \## or \x## depending on how the sysop has
 de>> configured that node in Mystic configuration?

 JC> Yes.

 JC> For incoming filenames Mystic handles all variations.

If that were true, then the problem that Paul saw shouldn't have happened:

- 09 Jan 19:19:39 [24867] VER Mystic/1.12A47 binkp/1.0
- 09 Jan 19:19:39 [24867] BUILD 2020/10/13 12:55:27 Linux/64
[...]
+ 09 Jan 19:19:40 [24867] sending /hub/filebox/fsxnet_z21n1n107/MyGUI v1.0.2.26.zip as MyGUI\x20v1.0.2.26.zip (1669424)
- 09 Jan 19:19:40 [24867] QSIZE 0 files 0 bytes
? 09 Jan 19:19:40 [24867] M_GOT: cannot parse args

 > For outbound filenames it uses \## (because any mailer that does \x##
 JC> will also accept \##, but mailers that accept \## wont accept \x##). Its
 JC> the most compatible method.  This is how it worked up to A47.

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. Binkd used \x## long before FSP-1011 and added \## as a reaction to a mistake in FSP-1011. It is not the most compatible method.

 JC> Then in A48 I went further and added in the option in the node
 JC> configuration so you can choose per-connection just in case there someday
 JC> is a newer mailer in the future that does \x## but can't do \##...

¨

This option was meant for mailers that uses the incorrect escape sequence \## (like Mystic does).

 JC> This A48 addition was as a result of the recommendation that was pointed
 JC> out to me in FTS-1026.001: http://ftsc.org/docs/fts-1026.001

 JC> "In FSP-1011.003 the escape method is specified as two hexadecimal digits
 JC> preceded with a backslash (e.g. a whitespace is transmitted as "\20").
 JC> Some mailers have implemented that method. It is advised to have a
 JC> setting for specific nodes to sent escaped characters using the incorrect
 JC> method."

as it is clearly explained in the quoted FTS.

 JC> Mystic implements the recommendation made in the last sentence but BINKD
 JC> does not as far as I know?

So you expect that binkd implement a feature that is not implemented in a release version of Mystic? (or only recently). And you expect that binkd should implement workarounds for buggy Mystic mailers?

 JC> So the solution to Paul's problem is to have
 JC> BINKD follow the FTS recommendation, or for the person to upgrade their
 JC> software version. I can't help him.

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.

Again: is there any mailer used today that doesn't understand \x## (which is not called Mystic)?

---