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

Remember the currently selected option on variable-length menus that might
scroll (using the "bar" var/pointer thing for uifc.list).

support in putmsg/printfile, etc. on per-use basis.
Add per-sub-board P-mode flags (so "Extra Attribute Codes" can be disabled
on a per-sub-board basis).

(e.g. [ and ]).

The global one is executed after all files have been processed.
A per-file command is executed after that file has been copied (if it
was copied successfully).
Command line specifiers are supported in both cases. In the global
command, %f is the TIC file path, and %s is the extraction dir.  In
a per-file command, %f is the destination file, and %s is the source.
This will remain untested until I receive some files to process.

Ctrl-A codes over QWK - excluding Ctrl-A P (pause), L (CLS), and comma (delay)
which were also previously allowed. These other codes can be problematic for
viewers and aren't well-suited to non-scrolling/full-screen message viewing
environments.

the Ctrl-A codes: L (CLS), < (backspace), [ (CR), or ] (LF).

Correctly support CR-terminated FTN-kludge lines (per spec, no LF is required).
Save the revision of this source file as the editor details for raw (writemsg)
and internal (msgeditor) created messages.

@-codes are also supported (i.e. displaying sysop-controlled content).

When message text contains an invalid or possibly dangerous Ctrl-A code,
convert the Ctrl-A to an '@' char.
Only Ctrl-A *attribute* codes will be allowed in message text
(e.g. not ^AP, ^AL, ^A", etc.).

start of a valid control paragraph (kludge line), then convert the Ctrl-A char
to an '@'. This handles the situation where someone quotes control paragraphs
with Ctrl-A chars, for example, we don't want those Ctrl-A chars being
misinterpreted as Ctrl-A codes causing weird colors or pauses or whatever.

Basically nodelist_handler.js, but less specialized.
Usage example in comments; should wikify that.
These are all "file handlers", but I canvassed a total of
three Synchronet sysops and they all shrugged and said
something like:
<DigitalMan> file_handler seems fine

"blink fonts" have been loaded into the terminal.

user, it is better to use bbs.compare_ars() rather than user.compare_ars():
- The "SYSOP" keyword automatically takes the "temp sysop" state into account
- The terminal capabilities keywords (e.g. ANSI, RIP, etc.) work correctly for
  auto-detected terminal capabilities (which are *not* stored in the userbase)