TID: FMail-lnx64 2.1.0.18-B20170815   
   RFC-X-No-Archive: Yes   
   TZUTC: 0100   
   CHRS: UTF-8 2   
   PID: GED+LNX 1.1.5-b20161221   
   MSGID: 2:280/464 6194bf67   
   REPLY: 2:221/1.58@fidonet f679aae1   
   Hi August,   
      
   On 2021-11-16 18:52:00, you wrote to All:   
      
    AA> An eTransfer typically allows for entering a short message of   
    AA> up to 400 chars.  For a recent eTransfer, I found it important   
    AA> to enter something to reference the billing statement that I am   
    AA> paying for.  My typical message was something like this:   
      
    AA>     This payment is for the "60-90 days" portion of the   
    AA>     statement dated 11/15/21.   
      
    AA> But that triggered an error message:   
      
    AA> "There appears to be an error! All errors must be corrected   
    AA> before continuing."   
      
    AA>     Please enter a valid message. It must not exceed 400   
    AA>     characters and contain only letters, numbers, and the   
    AA>     characters . ! @ / ; : , ' = $ ^ ? * ( ). It must not   
    AA>     contain the words http:, https:, www., javascript,   
    AA>     function, return.   
      
    AA> In this case it seemed that the quote char and the dash was not   
    AA> on the allowed list.  Now, I'm just wondering WHY would a quote   
    AA> or dash char need to be treated differently and excluded from a   
    AA> valid set?   
      
    AA> Likewise, why would even a simple word like function or return   
    AA> be a problem for a message block?   When the system dedicates a   
    AA> 400 char block for a message, why can't the system simply treat   
    AA> that content as a benign group of chars and ignore any   
    AA> "functionality" implied with http: https: or www, etc?   
      
   I suspect it's a standard the banks involved agreed about for this message.   
   It's handled by all kinds of systems at multiple banks, probably all over the   
   world. So it's probably a "better safe then sorry" messure, because there   
   isn't 1 authority that checks and oversees the development of all these   
   systems. That's handled by the IT departments of the individual banks.   
      
    AA> Could there be hacking vectors that haven't been solved in the   
    AA> eTransfer system?   
      
   With so many systems involved you never know if somewhere there is an   
   undiscovered bug lurking in one of them. It's probably wise to assume there   
   are more then one... So it's also wise to prevent them from being triggered by   
   having a strict "front gate".   
      
   Bye, Wilfred.   
      
   --- FMail-lnx64 2.1.0.18-B20170815   
    * Origin: FMail development HQ (2:280/464)   
   SEEN-BY: 1/123 14/0 90/1 103/705 105/81 120/340 123/131 124/5016 129/305   
   SEEN-BY: 153/757 154/10 203/0 221/0 226/30 227/114 702 229/424 426   
   SEEN-BY: 229/428 452 550 664 700 240/5138 5411 5824 5832 5853 249/206   
   SEEN-BY: 249/317 400 280/464 5003 282/1038 292/854 8125 301/1 310/31   
   SEEN-BY: 317/3 320/219 322/757 341/234 342/200 396/45 423/120 633/280   
   SEEN-BY: 712/848 770/1 2432/390 2452/250 2454/119   
   PATH: 280/464 240/5832 229/426