Deuce said to just delete it. <shrug>

The Synchronet FTP server has (since 2001) disallowed PORT/EPRT/LPRT commands with a "reserved" port number (i.e. < 1024) as recommended by RFC2577 and when attempted, would log a "SUSPECTED FTP BOUNCE HACK ATTEMPT" in the data/hack.log file.

However, as Karloch (HISPAMSX) pointed out recently, an FTP Bounce Attack to other TCP ports was still possible (and detected/reported by some security scans as a potential vulnerability).

So, reject all PORT/EPRT/LPRT commands that specify an IP address other than that used for the control TCP connection unless the sysop specifically enables the new "ALLOW_BOUNCE" option flag (in the [ftp] section of sbbs.ini) and the user is an authenticated non-guest/anonymous user. And as before, log the attempt as a suspected hack attempt.

This change also removes the "Directory File Access" checkbox from the Synchronet Control Panel for Windows as that feature is "going away" soon (or at least, it won't be an FTP-specific option/feature if it remains).

The Synchronet FTP server has (since 2001) disallowed PORT/EPRT/LPRT commands with a "reserved" port number (i.e. < 1024) as recommended by RFC2577 and when attempted, would log a "SUSPECTED FTP BOUNCE HACK ATTEMPT" in the data/hack.log file.

However, as Karloch (HISPAMSX) pointed out recently, an FTP Bounce Attack to other TCP ports was still possible (and detected/reported by some security scans as a potential vulnerability).

So, reject all PORT/EPRT/LPRT commands that specify an IP address other than that used for the control TCP connection unless the sysop specifically enables the new "ALLOW_BOUNCE" option flag (in the [ftp] section of sbbs.ini) and the user is an authenticated non-guest/anonymous user. And as before, log the attempt as a suspected hack attempt.

This change also removes the "Directory File Access" checkbox from the Synchronet Control Panel for Windows as that feature is "going away" soon (or at least, it won't be an FTP-specific option/feature if it remains).

Reverted the SAFECOPY() NULL source-pointer magic "(null)" string thing as that caused a different Coverity issue. Explicitly check for NULL at the call-sites instead.

Reverted the SAFECOPY() NULL source-pointer magic "(null)" string thing as that caused a different Coverity issue. Explicitly check for NULL at the call-sites instead.

Hopefully not introducing any bugs in the process.

Hopefully not introducing any bugs in the process.

The new subject line parsing (with quoted-filename support) had a NULL-pointer deref built-in.

Also fixed a few Coverity-reported issues.

Caught by Coverity.

Addresses Coverity's NEGATIVE_RETURNS bug-checker issue.

Identified by Coverity.

As tested and reported in FIDONEWS by Michiel van der Vlist, 2:280/5555, SBBSecho would use the "best match" FidoNet AKA for the originating address when replying to PING netmail messages and not necessarily the original destination address of the ping request. For systems that have multiple addresses (AKAs) that could be considered appropriate originating addresses for the requesting node address (e.g. multiple addresses in the same zone or zone/net), this could cause a confusion for the PING requester.

The create_netmail() function now accepts an optional source (orig) address parameter and the PING response logic passes the netmail's destination address for the reply message's originating (source) address.

I noticed that AreaMgr responses also follow the same logic as PING responses (just use the best-fit AKA, not necessarily the same address as the original request's destination address) - but I did not choose to address that "issue" at this time.

Don't return an error if the node#/node.cnf file can't be opened for all uses of load_cfg() except from the terminal server. This fixes #214 for Tracker1

The previous committed fix/issue raised some additional concerns about this "parity" bit:

Something I didn't notice before from the ZMODEM spec:
"The hex header receiving routine ignores parity."

And looking at lrzsz's zm.c, I see it goes even further and ignores the "parity" bit on the ZPAD and ZDLE bytes proceeding the frame encoding byte as well as in the frame encoding byte itself (so ZHEX, 'B' 0x22 and 0xC2 should be treated as equivalent).

I find it strange that some ZMODEM implementations (e.g. chuck's zshhdr()) would send the terminating LF with the even-parity bit set, but not set the even-parity flag for any of the frame content bytes. And then, expect that the parity flag may be set on incoming hex headers. I suppose it makes sense for 7-E-1 connections, but then the transmitted terminating LF would have had its parity flag set automatically (would not need to be set manually in the code). Add to the mysteries of ZMODEM that will likely never be solved.

Some ZMODEM implementations set the high bit (even parity?) when sending this '\n' terminator.
As reported via IRC:
<Keyop> sexyz: !zmodem_recv_hex_header HEX header not terminated with LF: 138 (8Ah)

Feature requested (?) by u/jumbotronjim on https://www.reddit.com/r/synchronet/:

If the client connection is from a blocked IP address (in ip[-silent].can), but still manages to get through the web server and websocketservice and have their correct IP address reported via Telnet Location, terminate the connection. Seems dubious.

Fix issue reported WitNik (BGGRSCYN) on DOVE-Net:
```
sbbs@raspberrypi:~ $ /sbbs/exec/umonitor -iC
...
sh: 1: /sbbs/exec/syncterm-iC: not found
```

These configuration properties were not previously exposed via JS.

No immediate use/need, but I *almost* did. :-)

"Old style" (e.g. FTN netmail) attachments put the filename(s) in the message subject. Supported quoted-filenames in the message subject (i.e. to support filenames with spaces in them) in addition to the traditional space-delimited filenames. Mixing quoted and space-delimited filenames (for multiple attached files) in a single message subject is supported.

Since on 2.17, pthread_afork() is not in libc, -lpthread must be
after -lcl (library link order issue)

Fixes #211

BIG thanks to Scott Comstock for giving me access to his box to fix
this.

Also change the wording of the -D option to be more descriptive.

The "EchoLists" help menu only worked when you first enter the sub-menu and would get wiped out by subsequent child-menu help text.

Filled out the "Configuring an EchoList" help text.

Fixed issue seen where deleting an EchoList's Required Key didn't set the "dirty config" flag, so saving of changes was not prompted when exiting (if that was the only change made).

Also, it's not technically an option, so remove from the option list.

Fixes the Win32 build.

Done.