Now a sysop can "perm block" a client (IP address) for a limited amount of
time rather than always forever.

Add more displays of the ip.can details when actively blocking a client.

Moved twit/trash functions from userdat.c to trash.c

I wanted a couple of features for filters (e.g. blocked IP addreses):
- expiration date, optionally (only block for a limited time)
- display details of reason for filter in log messages (at time of block)

I've been thinking for some time that these files should be converted to .ini,
but then it occurred to me that I could do a sort of hybrid where the metadata
was key/value pairs tab-delimited from the search-pattern (first text on the
line). This is backward comaptible, relatively easy to view/edit by hand, and
extensible (easy to add/remove metadata fields in the future). So they'll
remain as text/*.can files.

The maximum line length for findstr/trashcan parsed files extended from 255 to
1000 characters.

Moved all trashcan-related functions from scfglib1.c to (new file) trash.c.

For the first time, I actually tested a build on WSL *before* committing to
Git. So, this *should* pass CI the first time. :-O

... especially around incoming connection acceptance, blocked-IPs/hostnames

Many searches are done (e.g. in the mail server, QWK import) for either of 2
strings in single file or list, so let's optimize that to a single iteration
through the file/list. This should reduce some redundant file I/O.

I do find this API a little confusing with the filename or list at the end
of the argument list, but kept it consistent with the existing single string
findstr functions (which are now just wrappers for the new 2-string flavors).

I noticed during this update that findstr() did not share the same behavior
as findstr_in_list() (feature added in commit f08f2137) whereby if all the
patterns were negative searches (beginning with '!'), then *all* the
negative matches would have to be successful (not just the first) for the
function to return true. So now findstr() behaves like findstr_in_list()
in this regard.

I also added some optimizations to findstr_in_string().

Using "Warning" log levels more for things that the sysop might be able to do
something about. If it's just an input data validation (from a random TCP/IP
client), use "Notice" log level instead.

The terminal server log output is still the odd ball.

The time span over which consecutive failed logins are attempted is important

The log format and details might need some adjustment, but this is a start.

Also, don't delay 3 seconds before disconnecting socket when mail server has
reached maximum number of clients - we should immediately release resources
(the socket) and be able to accept another connection ASAP instead.

Deal with new CID 470557 and 470554 in mail server: resource (file*)
leaks in error paths (corner case).

Set minimum severity of TLS messages in web sever to INFO. Debug-level would
hide some common TLS session errors.

The base64-encoded credentials can either be supplied with the AUTH PLAIN
command or in response to a 334 server-challenge. We only supported the
former form and logged a warning ("Missing AUTH PLAIN argument") when we
received the latter. No warning is logged now and the appropriate
server-challege is sent and the response accepted and base64-decoded and
parsed as before.

And fix some use of CRYPT_UNUSED instead of cryptlib session ID.

My mail server was suddenly and inexplicably creating thousands of SMTPS
client threads, each with a unique remote IP address, and each eventually
failing with the rather obscure log message (from cryptlib):
 dbg 'Cannot read item from object' (-41) setting session active

Eventually (after not long, really), the server would run out of resources
and fail in weird and wonderful ways (can't malloc, can't create JS runtime
or context, etc.). The max_clients limit (100, as I have it set) wasn't being
effectively-imposed on SMTPS connections.

The root-cause: the active_clients (counter) wasn't incremented until *after*
the cryptlib/TLS setup for SMTPS connections and SMTPS/TLS connections can
take a long time to fail, resulting in a vulnerability to an effective denial
of service attack.

Raise the minimum severity of all cryptlib/TLS log messages from Debug to
Info.

Create wrappers for smtp_thread() [now smtp_client_thread()] and pop3_thread
[now pop3_client_thread()] that handle basic resource management (thread
counters, active client counters, the client socket).

'T' command from the reading messages (O)perator menu

Abstraction the twit-list usage.

The user name is better to log than the user number. Include user name in
brackets.

Fixes issue #670

So Clang-FreeBSD was warning (in compiles of scfg/scfg*.c by Deuce):
result of comparison of constant 100000 with expression of type 'uint16_t'
(aka 'unsigned short') is always true

Why? Cause a uint16_t's max value is 65535 (less than 100000). Sure we could
have just lowered the UIFC max number of config items to 65535, but that would
have been too easy. And why are these compared-with values of type uint16_t to
begin with? Because most ctrl/*.cnf lists (of configuration items) were
limited to 65535 entries cause ... 16-bit DOS, historically. Now that *.cnf
files aren't used, we could just increase these scfg_t.*_total type sizes from
16 to 32-bits, yeah? The result is this commit.

I went to (signed) int so we could still keep -1 as the special illegal
sub/dir num value (e.g. INVALID_SUB, which is sometimes used to indicate the
email message base). Theoretically, 2 billion configuration items could be
supported in these lists, but SCFG will limit you to 100000 anyway. So there's
a whole lot of s/uint/int in this commit.

I'd be very surprised if this doesn't result in some new GCC/Clang warnings,
but at least the old "comparison of constant 100000" warnings are now gone!

Or even weirder, u_long?

And dereffing a ulong/u_long pointer where you expect to find an IPv4 address?
Yet even weirder still.

Fix that spit: It appears in_addr_t is defined on all platforms (?), so use
that type instead.

No known sightings of these sites actually being the location of a segfault,
but as we learned from the segfaults in rblchk(), the first entry in the
h_addr_list can be NULL in some cases.

I'm not sure why this one only started popping up now, but h_addr_list is a
NULL-terminated list and it makes perfect sense that the first entry could
be the NULL-terminator.

gethostbyname is obsolete/deprecated and we should address that in a separate
commit.

A bunch of possible (but often, not really) use of undefined values.
Some ignored return values (e.g. of chsize/ftruncate, read, write, fgets).

Other than some added diagnostics upon some of these unexpected syscall
failures, there should be no change in behavior from this commit.

The notification of offline users was removed from the mail server 13 years
ago (commit 729eb16b) without a lot of fanfare or explanation. Add an
option for notification of offline users (in addition to online users) for
those sysops that want that behavior.

Use the userdat is_user_online() function in place of the getnodedat() loop,
which also wasn't considering nodes in "logon" status as having a user online.

smtp_netmail_addr() - not currently used anywhere else, but may be someday.
load/mailutil.js's fidoaddr_to_emailaddr() has this same logic (for FTN addrs
at least and is now used by nntpservice.js).

Also, always pass a buffer to smb_faddrtoa() from the mail server since it's
multi-threaded and its unsafe to pass NULL (using a static local buffer).

Pretty much any From field that contains an '@' in the username portion
was subject to comparison to the full email address, but clearly some of
these rejected emails were not forge attempts:

'Chris @ StubHub' vs 'events@mail.stubhub.com'
'Eric S. Raymond (@esr)' vs 'gitlab@mg.gitlab.com'

Fixed by requiring that the sender name is actually a well-formed Internet
email address using smb_netaddr_type(), which was also recently improved to
be more accurate.

Unrelated change: include reverse-path (email address for bounces) in
ILLEGALLY-LONG body and header line log messages (usually SPAM from what
I can tell).

SMTP commands have a shorter limit (510 versus 998) and the body text line limit needed to account for dot-stuffing. 

Log a warning message and send a "500 Line too long" before disconnecting any SMTP client that sends lines > 998 characters in length. Technically, we can handle lines up to 1023 characters, but then we could get out of sync with the client if it sends exactly 1023 chars and then a new-line char (which we would interpret as a blank line, separating the message header and body) - so just punt the client who doesn't obey the rules of the protocol.

When sending an SMB message header via SMTP or POP3, some header fields (lines) could potentially be longer than 1024 and yet sockprintf() was limited to sending 1024 bytes (actually 1022 plus CRLF). This could result in some messages not being sent correctly: header field truncated, not CRLR-terminated, and notably resulting in MIME message contents not being decoded properly in a message viewer/reader. Example (Content-Type is part of the previous header field/line):
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?cm9T1Q9G65VC/lKTTqhODKhy5lHT2y6WWMb/WyvJ+EeGEwYmY7ILhzE3yfNM?=
 =?us-ascii?Q?KeFWN9T/PqHBya1plKf/sHgaw0iRmI7Hq+u9Dp4bG8OqdniKQlK+Aa27oXMd?=
 =?us-ascii?Q?Hly6OEYaSu7jbhGGY89LF0gyRVqquqxkaMfpKvG+h4cQnnu4Tl8YAKeE39a2?=
 =?us-ascii?Q?lHW3372ulmb9jvvZU72J2RtZYkuoIr+Wsqhfyuj39wTZ/+C4qKCsYrmTxrki?=
 =?us-ascii?Q?fBZ4gMPzWkrcWAr7zPcXBg8bphJJB8VJFUjQyksA3EG4dtH8+TZeEcNNBmHf?=
 =?us-ascii?Q?oCGnV9wHr9HszzrSkkZ2GGyh3QZLHAVDNe7wDXSy7HJttZugf9kNqKGeaYQL?=
 =?us-ascii?Q?TpljH1aHPe7MiSP9Dmp/xHQ/DWQOZDx5guNS+iMciMt5p5ad+SkQye0hWRhd?=
 =?us-ascii?Q?usHvpllclzIee6lxJ0VSPAzHGlAOhtOolrHdDB2ODjvkEzU7L2Fj2f5x7p9q?=
 =?us-ascii?Q?9d6sUgSz7vZVx8yyR3KPq3jIX0QUnl0xr2Mix9xcmMNcg0yFLPcznqBdLVa8?=
 =?us-ascii?Q?IC7j0+8oy4BjYxr8Z3elxMC2JKq13gPYgR95cwm6hMDiZbMB4EW/J1uJhD/I?=
 =?us-ascii?Q?RIIqTZ+Ywt8nKOfXj6/a9Aauf0wN71QKKA+in7KY9oksIhkUGvWOrtJwkVDL?=
 =?us-ascii?Q?Q2UFrBBJyQHJgumj5Y+bG8FDk/55IfyV9XYEcsdLL4bCF+HX4QPHZCw4P+li?=
 =?us-ascii?Q?bRvN+UxOO8hgXVkgB1q8mNJ62yQuaj0AContent-Type: multipart/alternative;
	boundary="_000_SN6PR07MB454477F4C32C66D48BA0B02187A09SN6PR07MB4544namp_"

Solved by using asprintf() instead of snprintf() for dynamic string formatting and allocation in one go. Using realloc() to expand the buffer for the appended/required CRLF.

[s]printf format fix-ups

Mostly [s]printf format fixups

Publish all login-failures to this new topic.

This commit also includes a few 64-bit free disk space fixes in the FTP server.

- Most published messages (besides log entries) have a timestamp (in ISO8601 format) prepended and tab-separated
- The order and number of elements in client messages (list and activities) has been updated, now includes user number
- Server client lists are now published to .../SERVER/client/list
- Server client activities (connect, disconnect, update) are now published to .../SERVER/client/action/#
- Server client count is now published to .../SERVER/client (with the maximum client count, if applicable)
- Server states are now just represented by name (e.g. initializing, ready, stopping, stopped) and not number
- BBS errors are logged to sbbs/BBS/action/error/LEVEL (where LEVEL is the log level name, e.g. "critical" or "error')
- All server hack-attempts, SPAM attempts, logins, logouts, uploads, downloads, are published to sbbs/BBS/action/ACTION/*
- Chat pages are published to sbbs/BBS/action/page/node/#
- New users (on the terminal server) are published to sbbs/BBS/action/newuser
- Posted messages and executed external programs (on the terminal server) are published to sbbs/BBS/action/ACTION/CODE topic
- The event thread started/stopped status is published to .../SERVER/event

Yeah, the wiki will get updated soon to reflect/document all these changes

This fixes issue #495.

This is more consistent with how these events are logged in a BBS-common log file in data/*.log.

This change also restores the server abbreviation to the error log entries that used to be there until recently.

Each Synchronet server is now its own MQTT client. This means there's no
longer any MQTT logic in the Synchronet "hosts" (e.g. sbbscon.c, ctrl/*.cpp)
and none needed for SBBS NT services (they'll "just work" with MQTT).

This also means that just about everything (except for nodes, spam and hack)
is now published per-server (in the sbbs/BBS-ID/hostname/server/ topic branch)
and if you want aggregated totals or client lists, you'll have to do that in
your own MQTT client or dashboard.

I also removed the publishing of thread_count and socket_count topics as
they weren't universally supported across all servers and are of questionable
value. They can be added back later if determined to be useful.