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.

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.

- REPLYTOLIST (a mime-decoded version of RFC822REPLYTO)
- RECIPIENTLIST (a mime-decoded version of RC822TO)
- RFC822CC (a mime-encoded version of SMB_CARBONCOPY)
- RFC822ORG (a mime-encoded version of SMB_ORGANIZATION)
- RFC822SUBJECT (a mime-encoded version of SUBJECT)

The RFC822* hfields are only created when necessary: there was a MIME-encoded
hfield value received (e.g. by the mailsrvr) for the corresponding hfield.

The to_list and replyto_list convenience pointers now point to the MIME-decoded
(plain text) version of these header fields, since that's what everyone
normally wants to see and use.

The MIME-encoded flavors (RFC822*) are stored for relaying via SMTP or POP3
and retaining all data (no normalization or decoding).

A new auxattr bit has been defined: MSG_HFIELDS_UTF8 (happens to be the same
as P_UTF8 - snicker). This bit will be set in msg.hdr.auxattr when one or more
hfield values are in UTF-8 format. When this flag is not set, all hfield values
are assumed to be CP437 for backwards compatibility.
Since we are using a single flag, all header fields have to use the same
encoding (either CP437 or UTF-8). When the hfield values are all plain ASCII,
there's no difference between CP437 and UTF-8 and the MSG_HFIELDS_UTF8 flag
is not expected to be set, though setting it shouldn't hurt. The RFC822* hfield
values should also include US-ASCII text (using MIME-encoding for any 8-bit
charsets).

smb_get_hfield() function prototype change: the 3rd argument changed from
an hfield_t* to an hfield_t**, so that the caller can actually change the
hfield type (in memory) if they wish. Nobody seemed to be passing any non-NULL
3rd argument value, so this changed appeared safe to make.

FIDOCHARSET
with its own smbmsg_t convenience pointer: ftn_charset.
this allows greater control over when/how this header field is exported.
Constify smb_msg_is_utf8().
Note that the "Editor" hfield type should hold any FTN "NOTE" control line
values (where msg editor details/version are normally propagated over FidoNet).

to a text/html part of a multi-part MIME encoded message if no text/plain part
exists.
Changed smbmsg_t.charset to smbmsg_t.text_charset.
Added smbmsg_t.text_subtype (e.g. "plain" or "html").
Fixed issue with parsing parsed plain-text when the charset was the last
element of the MIME-part header.

purpose

the (never used) SMB_PRIORITY 32-bit hfield (0 = default/highest priority), to
a new fixed message header field (8-bit) following the X-Priority header field
numbering scheme: 1 = highest, 3 = normal, 5 = lowest and 0 = unspecified.

content-type "charset" parameter value and store in the (new) smbmsg_t.charset.
This is a heap-allocated copy of the text from the message body, so it must be
freed in smb_freemsgmem(). When NULL, the charset can be assumed to be
US-ASCII.

- to_list
- cc_list
- replyto_list

These are all comma-separated lists of names/addresses, RFC-822 style
(so quotes and angle-brackets and all that jazz preserved/included)

indicate that a message's body text contains one or more MIME-encoded/embedded
attachments - so that entities won't have to parse the message headers/body
to determine whether or not a message has MIME-attachments.

back in 1993, but were never needed/used.

header fields. Eliminate smb_getcontenttype() - now unnecessary.

(name/version of text editor used, if known).

"SYD" (Sydney) +10:00, is now "AEST" with a DST (+11:00) counterpart, AEDT.
Added ACST (+9:30) with its DST (+10:30) counterpart, ACDT.
"WEL" (Wellington) +12:00 is now "NZST" with a DST (+13:00) counterpart,
NZDT.

message text (when relevant and available) - this helps when re-wrapping the
message text (e.g. for quoting) and not always guessing "80 columns".

Updated some comments in smbdefs.h too.

messages (and maybe files in the future).

it justs initializes/re-initializes the SMB header and status header
records.
Created smb_t.continue_on_error which (currently) allows an smb_open() to
continue event though some (normally fatal) errors have been detected
(e.g. corrupted SMB header).
This is all in the name of being able to recover message bases after more
forms of corruption.

European (EET) timezones and their DST equivalents (WEST and EEST).

- Change zone name from BER - >CET
- Enable daylight saving (summer) time for CET -> CEST

oldest *existing* message in the thread referenced by the specified msg.

Incremented smblib version 2.60 (to indicate all the recent changes).

smb_voted_already(), e.g. to @-codes in a custom msg header.

comparison between signed and unsigned integer expressions

- Closures (polls can be closed for new voting by the pollster)
- Results can have configurable visibility:
  a. Only to voters (and the pollster) - the default
  b. Everyone
  c. Everyone once the poll has closed
  d. Only the pollster

Changes to smb_getmsgtxt():
Main change: poll questions can now be quoted when replying to a posted poll
(the results cannot be quoted).
Also: there's now automatically a blank line inserted between comment header
fields and poll answers or the msg body text.
Also: upon any malloc failure, the function now returns NULL.
New functions: smb_msg_is_from() and smb_addpollclosure().

There (will be) the possibilty to cast mutliple votes in a single vote-msg
(ballot), when multi-choice polls are introduced later. There were just too
many things call vote/votes and it was getting confusing in my own head. So the
msg type for messages that contain votes is now "ballot".
smb_voted_already() now returns uint16_t (instead of BOOL), returns the votes
of the user (for polls) or just 1 for up/downvotes of msgs.

belong (with the function prototypes).

Using msg attributes to indicate polls and up/down votes since attributes are
stored in the index and enables fast vote tabulating/searching.

The beginnings of an SMB-based voting system - very experimental:
The concept is that a "vote" message can be used to reply to:
1. A normal message, as either an upvote or a downvote, ala social media
2. A poll, polls can either allow a single choice answer or multiple answers
Vote messages won't be visible as normal messages (e.g. when reading messages
online) and SMB processing software (e.g. SBBSecho) should ignore these
messages because they have no body text.
Polls are going to need more work, but the idea is to have the poll question as
a single (newly defined) hfield and the possible answers as dfields.