pointer type mismatch in conditional expression
format '%s' expects argument of type 'char *', but argument 5 has type 'void *'

(in addition to the auto-ZMODEM upload detection). Using an evil "goto" for
code reuse.

Discards any previously quoted/typed text, but remains in the editor with the
uploaded text available for append or edit.

any previously quoted/typed text and save as the final message text (no
editing). Useful for upload of pre-written messages or ANSI art or whatever.

(defauls to enabled, for backward compatibility).
Added new autohang args to bbs.send_file() and bbs.receive_file() (default:true)
Added support for "description" argument to bbs.send_file() as well.

auxattr flag since we normally want the attach file to be deleted automatically
when the message is delivered. SBBSecho now won't be deleting the file
attachment unless this flag (or the .msg \1FLAGS "KFS" equivalent flag) is set.

file-attachment deletion in write_flofile() - not the KILLSENT attribute flag.
Export the SMB MSG_KILLSENT auxattr from SMB mail to FTN netmail \1FLAGS KFS.

"UTF-8", set the msg's auxattr MSG_HFIELDS_UTF8 flag because FTS-5003 states:
  "The character set identifier applies to all parts of the message,
   including the header information and the control lines like origin
   and tear line."

MIME-encoded.
If any RFC822* header field is a MIME-encoded UTF-8 string, then set the
(new) auxattr MSG_HFIELDS_UTF8 flag. This will be used (soon, hopefully) to
display UTF-8 encoded header fields to users. There's a gotchas here:
- MIME-encoded header fields with other non-ASCII/8-bit charsets (e.g. CP437,
  ISO-8859) are still stored "as decoded", though the MSG_HFIELDS_UTF8 flag
  may be set *later* (which would be weird), resulting in a mixture of valid
  and invalid UTF-8 header fields. One solution would be to UTF-8-transcode all
  the non-UTF-8 header fields if *any* of them are UTF-8, but we wouldn't
  know which charset to translate *from*. Assuming CP437 isn't going to be
  correct 100% of the time - so punt for now and deal with it at display
  time. e.g. if the MSG_HFIELD_UTF8 auxattr flag is set, but an hfield contains
  invalid UTF-8 data, don't display as UTF-8 (e.g. treat as CP437). We don't
  have translations for other charsets (e.g. ISO-8859) setup yet anyway.

- this is the version used in SyncTERM v1.0.
I happened to try SyncTERM 0.9.5b recently (CTERm 1.151) and it failed
to either load or activate loaded fonts, so: not-supported.

Add listVerify() - confirm the list is sane

to putmg() when displaying messages in the sub on the terminal server.
E.g. to disable word-wrap for *all* messages displayed in a sub, set P_WORDWRAP
in sub_t.n_pmode.

mail -> netmail forwarding for a specific invocation.

This should solve the problem of non-UTF-8 messages posted on non-up-to-date
systems (no UTF-8 support), yet the message has a "charset=utf-8" in a MIME
content-type header.

default TargetPort assignment.
If Port was specified in qs, and if it's our RLoginPort, then set
TargetHostname to GetRLoginInterface().

and in turn that returns 'localhost' if none specified in sbbs.ini.

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

during *display* in the terminal server, so this option would help, say,
the web server).

of UTF-8 message text).
Remember the "bar" position of sub toggle options (now that they scroll).

for some obvious (but missing) mappings.

When writing non-bundle file paths/names to BSO/FLO files, don't use the
delete (^) prefix unless the message has the "Kill Sent" attribute set. This
seems kind of wrong to me. The KFS "Kill File Sent" flag has been defined in
FSC-0053 since 1992, that seems more likely the appropriate flag to determine
if a message attachment should be deleted (or not) after being sent. But
parsing/using the "Flags" control line flags isn't already in SBBSecho, so
I'll just punt for now and do what Mark asked for. <shrug>

use mixed or upper-case for their Transfer File Paths.

transfers. These should *not* be included in message text.

Version 1.23: If a message is in UTF-8 format and the user's terminal doesn't support UTF-8, the message text will be converted to CP437.  Also, if there is a color/attribute code in the message before the message text and there are no other color/attribute codes, the color/attribute codes will be removed so  that the entire message isn't colored

be called as console.print(string, number), the number will be interpretted
as the P_* mode flags value. Otherwise, all arguments are converted to strings
and printed (as before).
If anyone was calling console.print(string, number), they will get different
behavior now. I couldn't find any evidence of anyone using this syntax for
console.print(), so I think this should be okay.
Only a limited set of P_* flags are supported (e.g. P_PETSCII, P_UTF8) - far
fewer than console.putmsg(), but console.putmsg() is much more heavy weight
and supports a lot more "features" likely to interfere with the expected user
output. In general, try to use console.putmsg() only when printing multi-line
text strings or when @-code expansion is needed. Otherwise, console.print()
is usually better.

printing messages in this sub via putmsg, etc.