standard time-zone (e.g. -0300 == EST) as this is not accurate when daylight
saving time is in effect (-0400 == EDT or AST?).

Always log the "exiting" line when exiting with a non-zero error level.

exit), just log the error and continue processing. Reported by wkitty42.

- Don't ever try to unpack a 0-byte file.
- Don't log anything or try delete if the file is < 24 hours old.
- Try to delete the file if it's >= 24 hours old (and log a msg, INFO-level).

contain UTF-8 characters.

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

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>

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

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.

FIDOCHARSET
Export CHRS: control line with value determined by sub-board settings (e.g.
ASCII only) and the contents of the message (UTF-8 or CP437).
Import "NOTE:" control line values into the SMB_EDITOR hfield and export
from SMB_EDITOR -> NOTE:.
Increment SBBSecho version to 3.08.

linked nodes: UseOutboxes (default: true)

BinkIT will continue to outboxes even when this option is set to false, but
SBBSecho won't place any mail files in the outboxes when this option is set to
true.

For PSI-Jack who was surprised that SBBSecho put mail files into outboxes.
Since it appears BinkD supports both outboxes and normal outbound directories
for linked nodes and BinkIT does as well, this shouldn't really make any
difference - just a sysop preference.

doesn't actually *use* the password for anything, EchoCfg uses the nodecfg_t
definition from here (which includes the 'ticpwd') and the SBBSecho AreaManager
allows remote changes of the TicPwd by linked-nodes. For PSI-Jack.

When processing area manager netmail messages, SBBSecho can modify
(add/change) keys in the [node:*] section of the sbbsecho.ini file. Although
SBBSecho would read node sections that had a domain (e.g. 5D address) just fine
when processing area manager changes and writing those changes back to the
sbbsecho.ini, only 4D addresses (no "@domain") were used in the section naming.
This could result in duplicate node sections being created in the sbbsecho.ini
file (one with a "@domain", one without) and then "bad things" could happen
(e.g. BinkP authentication failures, packet authentication failures, etc.).

Now, when SBBSecho writes linked-node setting to the sbbsecho.ini, it first
checks for the full 5D address of the node and if that section exists, modify
it, otherwise fall-through to the 3D/4D address of the node for the sectoin
naming.

Log free disk space errors to sbbsecho.log (as well as print to stdout).

(when set to Yes).

The default is off (no stripping). Previously, Soft-CRs were always stripped,
but this behavior is now seen as an anachronism as CP437 char 141 is an
important non-English laguage character and used as such in FidoNet msgs.

When responding to AreaFix requests, it's normal for create_netmail() to be
called with a NULL 'msg' argument value - so don't try to dereference it
(for the "cols" header field value) if it's NULL. Thanks to Mark Lewis for the
bug report.

Don't store a columns value of 0 (the default).
Use SAFEPRINTF in place of sprintf() in parse_control_line().

FidoNet "Kludge line" (control line): "\1COLS: <columns>\r" where <columns>
is a value between 0 and 255 and a value of 0 is special, meaning "unknown"
and not normally specified (this is the default assumption when there is no
"columns"/COLS header field). When a message editor column width is unknown,
is is normally assumed to have been 80 columns for word-wrapping/re-wrapping
purposes when displaying the message text.

This feature has worked well for Synchronet's QWK networking (i.e. there are
far fewer instances of word-wrapping/re-wrapping issues when viewing messages
on DOVE-Net), so I decided to support this message header field over FTN
(SBBSecho) as well. Hopefully other FidoNet software authors will notice and
support this header field in the future as there are still numerous examples
of word-wrap issues when viewing FidoNet messages. At least Synchronet <->
Synchronet systems over FidoNet should be able to re-wrap and display all
message text nicely when both ends support this kludge line.

Incremented SBBSecho version number to 3.07.

If the attached file begins with a '^', ignore/skip that character in the file
path. This should resolve the error reported by Ken  of Section One BBS:
ERROR line 850, attachment file not found: ^C:/SBBS/XTRN/BRE777/...

SBBSecho v2.x included this work-around and it was not included in the v3
re-factoring/re-write. Of course, BRE is doing something wrong and is totally
at fault here, but no one expects BRE to be fixed... ever. :-)

suitable for passing to findstr_in_list().
SBBSecho peformance improvement: don't open/read the twitlist.cfg file for
*each* imported message: just read it once during initialization (using the new
findstr_list() function of course).
Reversed course on the findstr()/trashcan() matching logic: significant leading
white-space was not backwards compatible (and was the cause of recent lost
messages in DOVE-Net) - so I decided to go a different route and support
C-style character escape sequences (e.g. \r, \n, \t, \x##, etc.) in findstr
comparison strings, so the new way to represent a leading space character
in a filter file (e.g. twitlist.cfg, name.can) would be: "\ ". So to match (e.g.
filter/disallow) all strings with a leading space: "\ *". "\x20 *" would also
work (0x20 is ASCII for "space").
Now, again, leading white-space in filter files (e.g. text/*.can, twitlist.cfg)
is ignored. <sigh>

Oct-14-2018:
It turns out, PabloDraw actually inserts a Ctrl-AZ sequence at the end of .msg
(and presumably Synchronet .asc) files it edits - before the SAUCE record.
This resulted in a printed Ctrl-Z character (arrow pointing right) in most
terminals when viewing text/menu files created or edited with PabloDraw. :-(
So, now Ctrl-AZ (uppercase) will revert to the previous definition:
premature end-of-file (EOF)
and a Ctrl-Az (lowercase) will output a Ctrl-Z (substitute) character.
I'm not a big fan of case-sensitive Ctrl-A codes, but frankly, running out of
chars and I already started this pattern with the Ctrl-AF/f sequences.
Hopefully there's no existing software that is/was putting Ctrl-Az (lowercase)
in files, expecting that to trigger a premature EOF. I certainly was not.

requests sent to "SBBSecho" again. SBBSecho used to allow this back in
v3.02 (Nov-2017) and earlier versions, but was removed for loop-safety
since AreaMgr notifications and responses are sent from "SBBSecho", but
we have bot-loop protection built in, so that should be okay.

description/documentation more closely. That is, if there is an INTL kludge
line in the incoming netmail message, there will be no "fuzzy" zone matching.
This means that Fuzzy Zone operation will only apply to netmail messages that
do *not* have an INTL kludge line (which specifies the source and destination
zones already). This solves the problem reported by Mark Lewis with
unexpected Fuzzy Zone behavior (when enabled), it was over-riding the
source zone number even though it was specified (via INTL kludge) in the
original netmail message body.

message-ID (e.g. when exporting from SBBSecho).
This addresses compliance with this [editorialized] clause in FTS-9:
     No system
     should ever add an MSGID and/or REPLY to,  or modify an existing
     MSGID / REPLY contained in,  a message not originating on that [FTN]
     system.

Messages gated from other networks (technically coming from another system,
but originating into an FTN from this system) will still have an FTN Message-ID
generated/added.

Since SBBSecho normally tosses to downlinks directly from packets, this adding
of generated Message-IDs would no normally occur. However, if a downlink
rescanned an area, any messages missing Message-IDs would get them generated
automatically and they would appear to have originating on the local system.
This was never the intention, so this is just a long standing but infrequently
observed (and never reported) bug.

can we get a slight change in the sbbsecho code or maybe in echocfg so that
when a link is set to passive, areafix notices are NOT sent to them even if
"send notices" is specifically set to yes?

The PRIuOFF versus off_t definition mismatch (in ftpsrvr.c too) has not
yet been resolved (on rPi, gcc 6.3.0).

found, it would be added to the list of echoes tracked in echostats.ini.
Ideally, a negative-response message would be sent to requester in this case,
but we're not doing that currently.

was so pervasive. I hope I don't regret changing this. Ctrl-AZ == Ctrl-Z just
"feels right" while Ctrl-AZ == EOF feels stoopid. :-/