Don't add another tear-line (---) if one already exists, when creating
netmail (.msg) stored messages.

flag set.
Allow robot configurations in sbbsecho.in to include attribute values to
add (or-into) the message header, thus allowing for robot-netmail messages
that remain in SMB and are handled by robots (e.g. tickfix.js). Without
the in-transit attribute flag set, the messages will be subsequently
exported out to netmail/*.msg files for potential processing by other
FTN utils.

imported for robots actually have a 'to' index value of 0.

only (e.g. areamgr requests or whatever). In the future, they could be extended
to echomail areas too, if that's desirable.

For now, it's really intended for ticket-FileFix.

Anyway, NetMail can be received for the robot-name@<your-ftn-address> and
the mail message will be stored in the Synchronet "mail" base. The recipient
extension will be absent since there is no valid user account associated with
the robot. Robot names supercede other user names/aliases for received netmail.
If one or more netmail messages were imported for a robot and that robot has
a semaphore path/filename specified (e.g. to trigger a timed event), then that
semaphore will be "touched" before SBBSecho exits.
One weird anomly with this is if attached files are received for robots, those
files will be stored in data/user/0000.in. The altnerative is to just ignore
file attachments sent to robots.

The echofg supprot for robots is still yet to be added. In the mean time, you
can add robots to your sbbsecho.ini like so:
[robot:<name>]
semfile=/path/to/semfile

Incremented version to 3.11.

(from stored messages in .msg files into packets), the origin net/node within
the  *packed message* header would be set to the local system's address
net/node (for the destination zone), always. This is the appropriate action
when packing EchoMail, but not for NetMail.

Now, there are lot of other header fields in the packed message that contain
the source/origin address (e.g. @FMPT, @INTL kludges) and those would reflect
the original origin address still. And these fields take precedence over the
orign net/node fields of the packed message header. So I'm not sure this bug
would actually cause any problems anywhere, but it was a bug all the same.

be unpacked into stored messages (.msg). Debug-level log message indicating
that one or more attributes were removed (and which ones, in hex).
This set of stripped attribute flags could easily be configurable, if that
turns out to be desirable.

Track and log the packet-export exceptions (link packets that were *not*
exported-to) and detail those exceptions (number of seen-bys, paths, origin
address, etc.) which were triggered.
This requires latest xpdev/str_list.*

why his messages aren't being exported to packets.
Don't increment the per-area-export counter when write_to_pkts() returns false.

- don't indent keys
- separate sections with a blank line (to improve readability without idents)

A nice tip from Ragnarok (DOCKSUD)!

calculate the longest tag first, then use that value for the padding.

This makes this file more suitable for import into SCFG->Message Areas
(something I'll work on soon), i.e. as an alternative to importing badareas.lst

to before the actual export, so that if an area has no downlinks, you won't
actually see this errorneous but harmless log message. Also include the
"export-to" address in the message.

Areafix requests to unlink a node from an area would corrupt the list of
linked nodes: the *last* listed node would always be removed. If this was
not the node that submitted the areafix request, then 2 nodes would be
removed from the list of linked-nodes for an echo.
To simplify this, we're just going to not write the removed node back to
the area file, but leave it in the in-memory list. So technically, the node
won't be unlinked until the next run of SBBSecho when the area file is
re-parsed. If that's a problem, we can always add run-time removal from
the in-memory list later. Reported by Alterego (ALTERANT).

*.msg).

(e.g. for Hold status) even if/when it's a point off of us.

Don't ever route netmail when the destination zone/net/node matches a local
AKA (ignoring the point value).

If a packed messages contains no PATH or SEEN-BY lines, we can still detect
and prevent a message loop by comparing the origin address in the packet header
against the downlink's address and if it's a match, skip that downlink.
It is still possible that a packed message header contains a different origin
address than the packet header, and we're actually over-writing the packed
messge header variable with the parsed Origin: line address (if there is one),
so perhaps we'll want to compare the (actual) packed message header origin
address too at some point in the future, if loops continue to be a problem.

write_to_pkts():
If for some weird reason a downlink's address is in the PATH, but not in the
SEEN-BYs, detect as a loop and don't send to (add to an outbound pkt for) the
downlink.

This is an experimental change to see if it addresses the issue reported by
Richard Williamson and Mark Lewis with regards to dupes in the COOKING
echo from point nodes off 1:396/45.

in case something (e.g. Argus mailer) deleted it while we were waiting our
turn to use it. As reported by Alterego (ALTERANT)

aux/net attributes to FidoNet msg header attributes:
- CRASH
- FILEREQUEST (FREQ)
- RECEIPTREQ (RRREQ)

This should fix the FREQ netmail issue reported by Richard Williamson
(RICHARDF). Thanks for the bug report!

in-place or by also copying to a new string in the process.

Don't string "soft-CRs" (0x8d) from UTF-8 encoded FTN messages, ever.

Default strip_soft_cr SBBSecho setting to true/on.

If an incoming message contains no CHRS/CHARSET control line *and* the message
text contains valid UTF-8 character encodings, set the FTN charset value to
UTF-8 so the message will be displayed/handled accordingly.
I did not add checks for header fields (to/from/subject) - we should probably
auto-detect UTF-8 in those as well, but for now, I don't see messages coming
into FidoNet echoes with UTF-8 in the header fields.
Incremented SBBSecho/EchoCfg version to 3.10.

was not a recoverable message header (e.g. the toUserName field was *not*
at offset 0x22):

xx 02 00 01 00 01 00 6A - 02 FE 01 00 00 00 00 30   : .......j.......0
34 20 46 65 62 20 31 31 - 39 20 20 32 30 3A 32 36   : 4 Feb 119  20:26
3A 33 32 04 00 4B 75 72 - 74 20 57 65 69 73 6B 65   : :32..Kurt Weiske

So restore the DateTime field validation: the 20th byte must be null.

messages is a null (0x00) byte. Some broken FidoNet software may include
a full 20 usable characters in their DateTime header field, like so:
"04 Feb 119  20:26:32" - representing February 4th, 2019.  Y2K. <sigh>

The DateTime won't be parsed fully correct, but at least the packet won't be
rejected outright because it is "Grunged". - for Alterego (ALTERANT)

This requires that the AutoAddSubs=true in sbbsecho.ini (the default) and if
you don't want an area file created/updated with new subs, just set new option
AutoAddToAreaFile=false.
Both of these options default to true which is the same as the previous
behavior: if you have a link that configured to hub for a msg group, any subs
not already in the area list/file will be considered new and added dynamically.
So what's new here is that you can set SBBSecho not to create or update an
area file and SBBSecho will run just fine if no area file exists or contains no
area definitions.
Incremented version to 3.09.

Alterego reported, would cause a crash if the netmail message did *not* have
a FLAGS kludge line.

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.