normal messages along with voting data (polls, ballots, etc.) would always be
imported in this order: msgs, polls, ballots/votes, and then poll-closures.
This could result in a confusing order of messages in the local msg base where
there were messages in reply to a poll before the poll appears and other
oddities. Anyway, this is now resolved by placing a msg "header block" for each
vote-data item in the MESSAGES.DAT file. Since there is no body/text blocks,
it should be ignored under normal circumstances, but these header blocks are
only created if VOTING.DAT is enabled anyway.
And now, the VOTING.DAT contains an extra line (empty .ini section) with the
HEADERS.DAT offset associated with the chronology of the item. The format
is still backwards compatible with the earlier builds that included VOTING.DAT
support.

Also, fixed the vote/poll/closure Message-IDs containing a msg number of 0
(while not technically a problem, it wasn't the intention) with the use of the
new function: get_new_msg_number().

Version 1.17 Beta 1: Implemented a workaround for handling message headers that are null (which are more common now with the message voting feature recently introduced in Synchronet).  Now such message headers won't cause weirdness in the message list.  Users won't be able to read such messages.  I'd like to find a way to not show such messages altogether in the message list - Will probably need to use the get_all_msg_headers() method in the MsgBase class to get all message headers except ones for vote messages.

"Subject" wasn't being parsed from VOTING.DAT and is a required header field
for polls, causing error: qwk.cpp line 1149 writing "/sbbs/data/subs/dove-sys"
access=-105, as reported by echickenster.

If a message header has a thread_back value (it's a reply to another msg), but
there is no Reply-ID header field, when converting QWK, look-up the
original message-ID (to use for the relpy/vote Reply-ID value). If the original
message doesn't have a message-ID, use the normal auto-generation scheme.
This isn't normally necessary, but I posted a poll with a message-ID on
DOVE-Net / Sysops and then voted on the poll, creating a vote with no Reply-ID
which causes an SMB "writing" error (access=-105) on the QWKnet node BBSes
(because the required header field is missing).

being imported: resolve_qwkconf() now supports both users (e.g. QWKnet nodes
uploading REP packets) and QWKnet hubs (e.g. importing a QWK packet from
VERT).
Also re-factored resolve_qwkconf() in the process (that was some *old* code).

No functional change.

so use shorter thread names.

How did startup->sem_chk_freq get set (back) to 0 in the first place?
The reason: the startup struct sanitization only occured when the various
server threads were first started. When recycled, the server would call back to
the original caller (e.g. sbbscon) which may (and did) re-read the sbbs.ini
file, which could have SemCheckFrequency set to 0 (or missing) and the
sanitization did not happen again (so a 0 value was used in select() calls,
resuilting in high CPU utilization for several threads).

So now, all startup struct sanitization occurs inside the init/recycle loop
and sem_chk_freq should never revert to 0 again. This was the main bug.

value is missing or set to 0 in the sbbs.ini file, the sanity checking this
value (setting it to 2 seconds) will not occur after a server recycle and the
sbbs.ini is re-parsed. So if for any reason, the sem_chk_freq value becomes
0, these server threads won't hog the CPU because they all YIELD at the
top of thier main loops.

Also, changed all the thread names (e.g. adding "sbbs/" prefix), so they're
more sensible in the Linux 'top' output.

Also, started adding 'vi' modelines to auto-set tabstops when using vi/vim.

key was missing from the sbbs.ini file, it would default to 0 seconds which
could cause continuous high CPU utilization after server recycling.

(optionally).
Sub-board operators can now see all poll-results (always) for locally-posted
polls (same as pollster).

comparison between signed and unsigned integer expressions

(no functional change).

- 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().

- 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().

been read. This way, the configured bsy_timeout value is used. Before, the
value of 0 was used which results in an infinite timeout (max age) for the
mutex, requiring a manual deletion of the file (no automatic recover) if
SBBSecho happened to crash. Now, it'll use the default bsy_timeout value
of 12 hours or the configured value in sbbsecho.ini.

1. If QWKE was enabled for the QWKnet account on the Hub, a user could spoof
   their name with a "From:" QWKE kludge line in the message body. Fixed by
   not processing QWKE "From:" kludge lines at all, ever.
2. If an @VIA kludge line was in the message body, it could over-ride the
   correct value from the HEADERS.DAT (oops). Really, the SENDERNET* lines
   in the HEADERS.DAT were always being overriden by either the @VIA kludge
   line (if present) or just the auto-genereated SENDERNET info (from the
   QWK-ID of the QWKnet account or hub. Normally, in a single hop QWKnet
   message, there will be no @VIA line, so spoofing is still possible in that
   case.

Use the proper method to auto-set the QWK_EXT (QWKE) flag for the user when
TODOOR.EXT is discovered in a REP packet.

record (e.g. the user number is invalid), the user number should be 0 after
returning. This would cause, for example, sbbs_t::login() to accept a login
string with an invalid usernumber (e.g. "12345") and do some strange things.
The same side-effect was missing in the (new) fgetuserdat().

to be able to delete messages that have no hfields, for example, with sub-op
'D' command.
Now support polls with comments (displayed before the poll answers).
Poll results/statistics are only displayed to sub-ops and users who have voted
already. This may be optoinal behavior determined by the pollster in the future.
Sub-ops can now add comments to any post using the 'A' command from the
[O]perator menu - use with caution.

Fixed printf() arguments.

it just calls the (newer) functions readuserdat() and parseuserdat() in a easy
replacement for getuserdat() for places where all users are read in a loop
(the file is only opened one time, dramatically reducing the amount of time).
Added an argument to openuserdat() so it can be used in more situations
(i.e. where the file needs to be opened for modify/create acces).

script. If you have already have a Guest account on your BBS, you might want
to add this restriction to it.

module. This is a reversal of the revision 1.102 commit (Jan-2-2016), but only
for Baja (JS is left with the new behavior). As the commit message said
"We'll see", and what we saw was that the yesnobar.bin and noyesbar.bin
long-standing Baja modules no longer returned "No" when the user hit Ctrl-C.
So at least for now, we have different behavior with regards to the console
abort (ctrl-C) flag between JS and Baja. :-/

up in 'top' output and provide some confusion.

clients:
1. The host_name is not known at the time loginBanned() is called, so that was
    a bogus value (left over from the previous connection) being used in the
    ipfilter_exempt.cfg file check.
2. Sometimes, getnameinfo() would fail, but still return 0, so previous
    host_name value would be erroneously stored as the current client hostname.