smb_netaddr_type():
- if passed NULL or a string that begins with whitespace, now returns NET_NONE.
- if passed a string that begins with '@', now returns NET_UNKNOWN.
- if the user.name portion of an otherwise value Internet email address
  contains a space, now returns NET_NONE.

smb_get_net_type_by_addr()
- if passed a string that begins with '@', now returns NET_UNKNOWN.
- if passed a string with space following '@', will now return NET_UNKNOWN.
- if passed a string without a dot following '@', will never return NET_INTERNET.

Unrelated change: Add the missing FILE attribute to smb_msgattrstr()

[s]printf format fix-ups

Likely a part 4 coming next after building with GCC.

On Win32, an off_t is 64-bits while a long is still a measly 32-bits.

Some responding programs will automatically remove the trailing white-space from subject when replying and that would mess up the subject-linkage-by-CRC. So let's just ignore trailing whitespace in the first place.

To fully support files > 4GB in size in file bases, credit values larger than 32-bits must be supported too.

There's a couple of todo comments/items included in this commit, but that's mainly to do with messages (which don't really have costs anyway).

The main thing to deal with now is the fact that users can't have more than 4GB in credits in the first place! That's got to be fixed next.

Used the reserved 16-bits in the file index record to extend the supported index-file-size from 4294967295 (4GB) to 281474976710655 (281TB). I think that's big enough for the foreseeable future. :-)

qp_decode (quoted-printable in-place decode of a string) could write 2 characters *beyond* the allocated buffer by appending "\r\n" to a string that was not quoted-printable in the first place. i.e. the  contents of buf were not actually changed in the decode loop. This could result in a corrupted heap and crash of sbbs or smbutil when reading such a message.

This change may result in a lack of CRLF appended to decoded plain text output, so we'll have to keep an eye out for that and resolve it some other way. One possibility could be to only append the CRLF if the destination pointer is sufficiently behind the source pointer.

This solves the crash that Kirkman reported with a specific message in his "mail" base. The header for the message said it was quoted-printable encoded, but the body text was not actually encoded at all:
OtherHeader      Content-Type: text/plain; charset="iso-8859-1"
OtherHeader      MIME-Version: 1.0
OtherHeader      Content-Transfer-Encoding: quoted-printable

So this started with addressing CID 174264: Big parameter passed by value (PASS_BY_VALUE), but then I fell down the constification rabbit hole. :-)

write()
chsize()

It's anticipated that this will be used for JS-populated file metadata in JSON format in the future (and not just "archive contents" in .ini format).

Also, fix the double-free issue that was occurring when moving files with extended file descriptions (sbbs_t::movefile()). This was actually the primary problem I was fixing here, but noticed the metadata issue: metadata would not have been moved along with the other file info between bases.

And the "name not found" error text was wrong.

Don't allocate and memset a buffer of -1:
#1  0x0000559222bc167f in strListCombine (list=0x559224220720, buf=0x559224226550 "", maxlen=18446744073709551615,
    delimit=0x559222bcce0a "\r\n") at str_list.c:447
447             memset(buf, 0, maxlen);
(gdb) print maxlen
$1 = 18446744073709551615
(gdb) up
#2  0x0000559222ba3841 in smb_addfile_withlist (smb=0x7ffce63a7e90, file=0x7ffce63a5bc0, storage=1, extdesc=0x0,
    list=0x559224220720, path=0x7ffce63a6e80 "/xfer/loons/manhater.mp3") at smbfile.c:365
365                     strListCombine(list, content, size - 1, "\r\n");
(gdb) print list
$2 = (str_list_t) 0x559224220720
(gdb) print list[0]
$3 = 0x0

Found/reported by plt via irc. Thanks!

When moving or renewing files, they're first removed and then added and they were being added with the DELETE attribute set. The filenames are displayed in red when staged for deletion/removal, so that's how I noticed. Oops.

This will allow fast/easy display of archive contents without actually reading the archive files.

Introduces some new functions:
- list_archive_contents()
- smb_adddfile_withlist()

A new SMB convenience variable ("tail", aliased as "content" for a file).
A new file detail level ("file_detail_content", exposed in JS as FileBase.DETAIL.CONTENTS) which adds a "content" array property to file metadata objects for JS FileBase.get().

Files already added to the new filebases won't have this archive content automatically - I'm looking into that now (likely a new or updated JS script to run).

Going to use these to store SAUCE "AUTHOR" and "GROUP" fields for files.

This won't impact Synchronet as it has a separate signal handling
thread, but we still need to behave properly for processes that
don't.  I'm also saying that ENOMEM does not indicate a disconnection,
though it may be better to pretend it was disconnected...

Hopefully not introducing any bugs in the process.

Hopefully not introducing any bugs in the process.

It should be either EACCESS or EAGAIN, but still, could be useful to know.

MSVC detected heap corruption from this function when the attachment was 0-bytes in length. Good catch.

This involved the removal of the content-transfer-decoding feature of the SMTP mail server since we need single-part MIME-attached file contents to be stored in their original encoded form (e.g. base64-encoded) and not in binary, for the message body text (where NULs aren't allowed, CR/LF is appended, etc).

I accidentally made this change to smbtxt.c in the new_file_base branch and then copied over here, so there's some unrelated innocuous changes (comment header, removal of SMBCALL) that hopefully won't cause a merge conflict later.

I don't actually receive single-part MIME attached files, so depending on others (e.g. Nelgin and Dream Master) to test for me.

Advertise the system's QWK-ID (a.k.a. BBS ID) in exported echomail messages. This will allow correlation of avatars that were imported via SYNCDATA carried via QWKnet (e.g. DOVE-Net) with messages imported from those same BBSes via FTN.

The alternative was to have SYNCDATA Avatar messages include all the AKAs of each BBS (in the body text), but that was looking like a rather complicated solution. This approach (the BBSID kludge) seems a much simpler solution.

I still need to implement the JS side of this solution however (for avatar lookups using the FTN BBSID), but this was the first important step.

A couple of stragglers here, the isalnum() call caught by an MSVC exception.

When forwarding a single-part MIME-encoded HTML email, the preamble (original message header info) and any user comments, need to be HTML-encoded.

Add the commonly-used "Fwd: " prefix to the default message subject, when forwarding.

This required that smb_getplaintext() no longer always-NULLify the message's text_subtype (e.g. "html"). For single-part messages, this element was getting freed and NULLed.

Add/use a new SMBLIB convenience function to add a string header field, but only if non-NULL: smb_hfield_string()

even when GETMSGTXT_PLAIN mode flag is used and the message contains a MIME-encoded plain-text portion. Obviously the GETMSGTXT_NO_HFIELDS exception still applies.

The fixed problem was when forwarding a MIME-encoded email, the forwarding information (and user comment, if supplied) could be suppressed/lost.

No longer derive the new message header from the original - too many problems. Simplified the forwarding support smblib (multiple SENDER* and RECIPIENT* header fields no longer expected/supported). Technically, the FORWARDED header field really serves no important purpose now.
A comment can be passed into forwardmail() or (if NULL), will be prompted for. There is an issue where the added comment can be obscured by the receiving mail program if the original message is a multi-part MIME message. Not sure the best solution for that. Still a WIP in that regard.

Use ctime_r() to dump the forwarded date/time.
Correct some other unsafe uses of ctime() here (replace with cime_r).
Fix the accidental reference to the GPL license (it's actually LGPL for smblib).

The convenience pointers to_ext and to_net need to be invalidated (nullified) if we are going to allow forwarding from local email boxes to network mail and keep all the original message header fields in tact.

The "Forwarded" field must now be added *before* any new recipient information (local user extension or network address of the forwarding destination).

This is part of the solution to request #83, #108, and #141.

Don't pass NULL to strcasestr().

In Issue #177, the reported problem message header was "Content-Type: text/plain; charset=utf-8; format=flowed"
The fact that the "charset" value was not quoted and not space delimited means the charset would have been parsed as "utf-8;", which would not provide an exact match (against "utf-8") in smb_msg_is_utf8() and thus the message body would not be considered to be utf-8 encoded.

The solution is to terminate the "charset" parameter value at the semicolon, if it exists, and the value was not quoted.

Also, for good measure, only search for " charset" or ";charset" to avoid false-positive parameter matches,  like "notcharset".

I'm fed-up with MSVC assertions in ctype functions (e.g. isdigit, isprint, isspace, etc.) when called with out-of-range (e.g. negative) values.

This problem only affects MSVC debug builds, but if you run them (like I do), these things are like little time bombs that can drive you crazy (knocking your board out of service).

The new macros names are bit more descriptive as well.

In support of message bases with vote-messages and poll-closures:

smb_msg_type() returns an enum smb_msg_type inferred from the combination
of attribute flags specified (should match msghdr_t.type).

smb_msg_count() calculates the number of message index records of the
specified type(s) (a bit-field) by reading the message base index file. This
value should only used for info/display purposes, so no locking is performed
to return the result as fast as possible.

This allows an accurate number of "posts" (posted *messages*) to be queried
and displayed to a user when appropriate (e.g. instead of
smb.status.total_msgs or just the size of the index file divided by the size
of an index record). In that case, since vote messages and poll closures
aren't displayed as messages to users, exclude those from the count to reduce
confusion. For message bases that don't support voting, this scheme is not
necessary.