Active connections (sessions) would be interrupted if another SSH
connetion came in and failed (e.g. IP was blocked or failed negotiation).

visibility modes and the user has more SPAM than HAM.

SBBSecho when sendnig netmail (e.g. notifications).

* AreaFix updates:
- No longer accepts AreaFix requests to "SBBSecho", since we send mail from
  that name, accepting mail to the same name can create a bot-loop
- Each linked node has a configurable "name" now, where to send notifications
  (not always "sysop")
- AreaFix support for a node can be toggled without clearing their AreaMgr
  password
- Area listings now include the echo descriptions (when available)
- Fix: the badecho is not included in area lists returned via netmail
- Improved log output around AreaFix requests/operations
- %echostats [echo] command now supported to request most recents stats for
  an area
- Notifications can now be toggled by AreaFix sysops using %NOTIFY On/Off
- Notification mail to the local Area Manager (sysop) now have the correct date
  time/zone in the message header (not copied from the AreaFix request)

* Added support for auto-responding to PING NetMail requests
* When exporting EchoMail, if the date/time written or imported exceeds the
  configured maximum age for EchoMail, don't export it (rescan exempted)
* The -g (generate notification messages) works with a passed address now
* Better grunged packet detection (e.g. NULL-terminated header fields must be
  NULL-terminated)
* Avoid bot-loop by refusing to send netmail from "SBBSecho" to "SBBSecho"
  If you setup an echolist to forward areafix requests to your hub a loop could
  occur :-(

Server via the new 'V' command from the Reading Mail prompt allows you to
toggle between all mail (including SPAM, the default), SPAM only, or HAM only.
Also added a new '/' (search text) command from the reading mail prompts.
Mail imported before the mailsrvr added support (recently) for the MSG_SPAM
attribute flag will not be counted/filtered as SPAM.
SBBSecho will have a commit (next) to support the new loadmail() usage, it
will not compile until then.

The orig address in the packed msg header is (and still is) the proper
local system address (this may be correct behavior, still checking), but
no INTL control line (FSC-0004) was added, so the packed message header
ends up defining the originating system address. So, now we include an
INTL control line in packed netmail messages which reflects the actual
origin address of the message. Thanks to Nigel Reed for helping to identify
and test this problem over the past week or so.

rather than the "from" address. This is necessary for the listserver.js to
properly recognize and process/delete bounce messages (e.g. posted to a sub
by a local user aand exported to the list).

DNSBL).

configurable command-lines.

string (just like we do for other search-types).

command-line option.

(change for *nix).

brackets to make it more clear that it's an implied (not real) value.

on *nix.

When packetizing netmail, the "origin" address in the created packet header
was copied from the netmail (*.msg) message file. This is fine for locally
created netmail, but nof for forwarded netmail (!). This would end up creating
outbound packets with a foreign source/origin address which may or may not
be deliverable.

Sort of related, if there are stray packets in the outbound directory with a
foreign source/origin address - don't packetize them! Just log a msg and ignore
these foreign outbound packets.

This explains at least part of the problem Nelgin reported where a routed
netmail was delivered to him (on Vert) from a hop running SBBSecho v3.01 and
I saw this packet header oddity. Now, why the actual netmail message itself
had the wrong origin address has not been identified.

If your system routes netmail messages (e.g. your hub), you'll want his update!

"Hold" attribute set, don't route to the configured uplink. Just like the last
commit, but now we actually create the proper cut/hut/out filename based on the
status as well.
Turns out, Crash and Hold NetMail was handled correctly in v2.x and was an
un-reported regression (new bug) in v3.0.

"Crash" attribute set, don't route to the configured uplink.
We really should do something similar for the "DIR" FLAGS kludge line, but
that's more work (and isn't easily set on a per-msg basis, like crash is), so
I'll revisit that later.

- Don't search for the section (echo) for each key/value

Added a debug-level log entry about the number of echostats read/parsed.

numbers displayed could be wrong since the poll-messages were not loaded
(or counted).

- If SBBSecho is run in a mode to both import and export (e.g. no command-line
  options), the SMB pointer used when exporting would be crossed-up with the
  last sub-board imported into. This was the cause of the mass dupe flood from
  1:154/30  (mostly announcements from "New Files At War Ensemble BBS").

Added a bit more log output with regards to bad echo area configuration and
re-tossing (this was not related to the bug/fix above).

to cause a "valid" (default) FTN address to be parsed (e.g. 1:1/0).

Most of the changes are in EchoCfg:
- SBBSecho and EchoCfg will now maintain auto-backups of the sbbsecho.ini file
- AutoAddSubs now defaults to true/enabled: this setting is harmless without
  further configuring linked nodes (Uplink for Groups / GroupHub)
- Global Settings are now a separate sub-menu in EchoCfg
- EchoCfg remembers current selection on (more) sub-menus
- Sub-menus have been rearranged and resized
- Numerous Online Help text updates in EchoCfg
- Adding missing/new settings to EchoCfg:
  Log Timestamp Format
  Strict Packet Passwords
  Use FTN Domain/Zone Map
  BSY Mutex File Timeout
  BSO Lock Attempt Delay
  BSO Lock Attempt Limit
  Config File Backups
  Linked Nodes->Uplink for Message Groups
  Echo Statistics File
  Outgoing Semaphore File
  Automatically Add New Subs to Area File
  Maximum Backups to Maintain of Area File
  Relay Filtered Messages
  (everything you can set in sbbsecho.ini should now be editable via EchoCfg)

can be more easily used by more utilities (e.g. echocfg).

Poll with results "closed" (only visible to pollster until the poll is closed)
have bit 31 set in the auxattr message header field. Reportedly (by Nightfox)
this causes Error: can't convert 2147483648 to an integer when attempting
to use this message in JS.
I could'vd sworn I've solved this problem before, but maybe that was with
JS-C v1.5 - anyway, first convert to double using JS_ValueToNumber and then
typecast to uint32.
We probably will need to do something similar with the time values in year
2038 (holding my breath).

actually moved because they were dupes.
Don't attempt to auto-add subs that aren't marked as "FidoNet EchoMail" in SCFG