The auto-remove param was only needed for fmutex(), which immediately closes
(and thus don't want auto-removal), so create an internal function that's
used by both fmutex() and fmutex_open().

This is needed for *nix where normal (i.e. not Samba-mount) file behavior
requires that we manually unlink() the file, but not until just before closing
it. So we have to keep track of the file name and the 'auto_remove' desire of
the caller. This is not necessary when the file is on a Linux-smbfs, but we
need to work as expected on normal/local *nix file systems too.

This solves atomic lock file removal for *nix, but does not gaurantee lock file
cleanup upon ungraceful process termination (e.g. crash). At least in this
particular case, Windows beats UNIX.

This reverts commit e55183c0.

fmutex_open()'s auto-remove feature doesn't work on normal/local Linux file
systems: unlink() of a file immediately removes its directory entry allowing
subsequent opens of the same file name, defeating the lock.

I had tested fmutex_open() on a Samba mount (from Linux) and it worked as I
wanted (like the Windows version does). Still searching for a good solution:
if a process terminates, gracefully or not, I'd like the file to be removed
at that time and until then, other processes or threads can't create or open
the same lock file (using O_EXCL and file locking to insure this).

Change requested in issue #747 and from Dan_C in #synchronet

Oh, so much copy/paste eliminated!

This appears to be the best we can do when Windows+M (minimize all)
is pressed.  We don't seem to be notified that we should minimize,
only that a different application is being activated.

This also makes Alt-TAB behave a bit more like expected.

Telnet BINARY_TX mode from the client disables CTRL-C input checking in all
versions of SBBS (before now). This change shouldn't be necessary now, but
it worked-around the BINARY_TX issue when I was having it (couldn't abort
mqtt spy).

This condition caused aborting BBS operations via Ctrl-C to fail when
connecting from a traditional Telnet client using binary transmission
mode (e.g. telnet -8) or SyncTERM v1.2rc6.

The check of rio_abortable was probably enough to disable this function
during file transfers (e.g. we've had no issues with SSH file transfers
that might include byte 0x03 received from the client), but I added the
check for SS_FILEXFER system status check too, perhaps unnecessary.

Update Cryptlib to 3.4.8

See merge request !473

Allow only US-ASCII, and send the BADCHARSET response code indicating
that.  Fixes issue with aerc.

On *nix, you need the command shell to do wildcard expansion of filenames

Add the errno value to help root-cause.

We really should be using safe_strerror() everywhere.

If an original references header field was supplied with the message, include
*that* in the header (since it should contain all the IDs of the replied-to
message thread) rather than just the message's reply_id (a single message
ID) when sending via NNTP. This maintains more NNTP post integrity when
sending back out via NNTP.

Not sure why we were storing received "references" in the hdr.references
returned by parse_news_header(), we don't seem to be using it anywere. Maybe
copied from 822header.js or mailproc_util.js? Seems like cruft, so remove it.

Also, don't ever send an "In-Reply-To" heder field via NNTP (it's not valid
/used for NNTP articles, per RFC 5536).

... so this was just redundant noise. Altough "References" is a valid header
field *both* for email and nntp articles, "In-Reply-To" is for email only.
per RFC 5536

We only want one Message-ID (we'll use the last, since that appears to be the
message being replied to based on SLRN behavior). This fixes reply linkage
when posing from newsreaders that put multiple message-IDs in the
references header field. This is required for SBBSecho to do its magic
creation of the FTN REPLY kludge during export.

This is the fix that Accession was looking for, I think.

This reverts commit d4692e0a.

Not the fix we're looking for.

This reverts commit a7f1a24a.

Not the fix we're looking for.

Use the fastest message base access methods documented.
Cache read/write configs and avoid parsing on read if unchanged.
Make common saves dependent on there being changes.

This is likely as good as it gets (assuming it works)

... for Acccession

Clean up as much as possible.

Almost no clients support a / in names.  Maybe I'll define an x-
extension or something when I write my own mail client.

This appears to be the only way to 100% provide mutual exclusivity between
Windows and Linux client sharing a Samba file system.

Also, make fmutex_close() take a pointer to the file descriptor so that we can
better manage the resource (i.e. don't close a descriptor that's already been
closed and possibly valid in another thread).

was printing the filename in uppercase if configured as such

Rather than a single file with config for all subs, use a separate
file for each sub.  This makes clients that do parallel connections
to different mailboxes work much better, and make loading and saving
the config for a mailbox much faster.

The caching stuff is removed to simplify things, and hopefully won't
need to come back... we should just not save config if it doesn't
change.

Only issue I'm still aware of is that 99% of IMAP clients just can't
deal with slashes in mailbox paths.  Like... at all.  The protocol
supports them, but every client seems to have a different way of
breaking with them.

No sense downloading articles we're just going to toss out the next time
we performance msgbase maintenance.

... which simplifies the fmutex_close() function and signature.

By default, the duration is infinite, but some sysops may not want this
file to be ever-grower but rather periodically pruned by the new trashman
utility.

Sysop that don't use spambait.cfg won't benefit from this change.