MSGID: 2:280/464.47 61e5a1da   
   REPLY: 1:129/215 128351cd   
   PID: JamNNTPd/Linux 1   
   CHRS: UTF-8 2   
   TZUTC: 0100   
   TID: CrashMail II/Linux 1.7   
   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)?   
      
   ---   
    * Origin: Birds aren't real (2:280/464.47)   
   SEEN-BY: 1/123 14/0 15/0 90/1 103/705 105/81 106/201 114/705 709 120/340   
   SEEN-BY: 123/120 131 124/5016 129/305 153/250 757 7715 154/10 203/0   
   SEEN-BY: 218/840 220/70 221/0 226/17 30 227/114 229/110 200 307 317   
   SEEN-BY: 229/424 426 550 664 700 240/5832 249/206 250/5 8 266/512   
   SEEN-BY: 267/800 280/464 5003 5555 282/1038 292/854 8125 298/25 301/1   
   SEEN-BY: 305/3 310/31 317/3 320/219 322/757 341/234 342/200 396/45   
   SEEN-BY: 423/120 460/58 633/280 712/848 770/1 100 340 772/210 220   
   SEEN-BY: 772/230 2452/250   
   PATH: 280/464 770/1 317/3 229/426