9 years ago in commit dbbfabf1

(mail received from authenticated SMTP clients is still allowed)

Previously, the M-restriction also prevent receipt of Internet mail from
authenticated SMTP clients, so separate that restriction into the new 'I'
restriction.

This fixes issue #865

Messages posted to sub-boards via SMTP normally will have the recipient
name/address as the "To" (RECIPIENT) value of the posted message. If the sysop
wishes to replace this string (for all SMTP-posted messages) with a different
string (e.g. "All") this is the setting to allow that.

I do want web-scrapping spammers to collect the 'to' fields for my TLDR and
Coverity-scan posts and post their own spam messages via email (any more).

Also accommodate the new link list API (long -> int).

Many global functions now throw an exception when null or undefined is passed
as a required parameter where null or undefined makes no sense.
e.g. "Argument #1 is an unexpected 'null' or 'undefined' value"
Example exception: is-a/has-a type functions will still return false when
passed null or undefined.

Changed global function return types:
- write() now always returns undefined
- printf() always returns a string, never undefined or garbage string
- prompt() returns null (not undefined) upon no input (as documented)

sbbs works more like jsexec:
- read(0) now returns an empty string instead of undefined
- readln(0) no longer waits for enter

jsexec works more like sbbs:
- add missing write_raw() global function, alias for write()

Include expected number of argment in "Insufficient Arguments" exception
message.

Update JSDOCS for some global methods:
- file_chmod returns boolean, not number
- flags_str requires a minimum of one argument

New tests to validate expected exceptions and return types based on usage.

This allows a server that's being terminated to stop the port-bind delay/retry
loops and terminate more quickly in cases of port binding failures.

Log the error string if it's non-blank, as a warning (e.g. unrecognized
text.ini text.dat string ID).

Reduce the number of logged messages when config load failure happens.

Commonize the load_cfg() error log messages.

uncrustify nl_split_if_one_liner setting

... using uncrustify mod_paren_on_return config

White-space changes only, exception being the rare insertion of NL before
closing brace (couldn't find the option to disable that behavior).

I excluded some header files (e.g. sbbs.h) since uncrustify seemed to be doing
more harm than good there. I might just end up applying different set of rules
to .h files.

e.g. [can|is]_subject_something() is now named subject_[can|is]_something()

No functional change.

Log a debug-level message after loading messages upon POP3 login.

Include a little more detail in 550 responses sent to clients too

Increment SMBLIB version to 3.10

Fix issue #845: Changing system/OS time zone, changes dates/times of posted
messages

Sysops and users shouldn't notice any change unless they change the time zone
of their system/OS (not accounting changes for daylight/standard time) and
the result will be that message dates appear the same after such a change.

For backward compatibily, any stored time_t's in msghdr_t.when_written.time
(i.e. all existing SMB messages) will still be decoded and displayed properly.
We detect a time_t value by the upper 6 bits being non-zero. When the upper
6 bits of a when_written.time value are zero, then we know the 'year' is
stored in the 16-bits before the when_written field (never used bits of the
netattr field, now part of the when_t structure definition) and the Month,
Day, Hour, Minute, and Second of the wallclock at the poster's site are
encoded in the low 26 bits of the time field.

This also eliminates more uses of 32-bit time_t that'll likely start being
a problem 2038 and really fall over and die in 2106. At least messages'
posting dates won't have any issue now. The "when_imported" values could use
a similar treatment someday I suppose - and we could get rid of the
when_imported.zone value as its not really needed we could use those 16-bits
for the when_imported.year.

Didn't change anything with filebases (still using time_t's though the
when_written hdr field isn't used for much with regards to files).

Yes, we could have converted all imported "broken down" message dates to
UTC and continued to store them as a time_t using timegm() instead of mktime()
for conversion to time_t, and I considered that. But we would have needed to
create/use a flag in the message header to indicate such stored date/times
(since they'd have to go through different adjustment for original time zone
before display, basically reversing the logic of all the places we display the
message dates/times using localtime verus gmtime/UTC C RTL functions),
couldn't just initialize the time with a call to time() upon import of local
messages (unless the local timezone happened to be UTC). And in the end, we'd
still have a 32-bit time_t value. So this seemed the better path.

I would have liked to have stored the date fields in a more human readable
encoding (BCD or decimal, ala isoDate and isoTime_t), but I just didn't have
the spare bits in the fixed portion of message headers to be wasteful like
that.

Here's an example from smbutil v of a message header posted after this change:
  when_written     03292595 41E0 Fri Dec 20 18:22:21 2024 PST
  when_imported    6766265D 41E0 Fri Dec 20 18:22:21 2024 PST

Notice the difference in the hex encoding of the date/time between the 2
header fields: when_imported still uses time_t. The when_written.year value
isn't output here.

Part of solution for issue #619 (for the mail server)

By default, the duration is infinite, but some sysops may not want this
file to be ever-grower but rather periodically pruned by the new trashman
utility.

Sysop that don't use spambait.cfg won't benefit from this change.

I suppose if we only had messages with no body text, this value could be 0
(not accounting for any headers) and thus throw a client off.

So consider this as part of the fix for issue #822.

For messages that have no body, we'd report 0. But RFC 1939 says this value
is supposed to be "the exact size of the message in octets" <sigh>. This
would include header fields, so while we can't know the exact RFC822 size,
adding the msg's hdr.length to these values gives size > 0 for messages
with no body text and this enables the Apple iPhone Mail app to download
the message (fixing issue #822).

Part two of this fix is to provide a blank line of message text when there
is none. This changes the message displayed in the iPhone Mail app from:

"This message cannot be displayed because of the way it is formatted.
 Ask the sender to send it again using a different format or email program.

 text/plain"

to (the much nicer):
 "This message has no content".

Allow filtering/blocking email based on the name portion of email header
fields.

(e.g. to, from, subject) ... when transmitting to other hosts (e.g. POP3
clients or other SMTP hosts).

For messages that contain CP437 or UTF-8 chars in these fields and were *not*
imported into the BBS via SMTP or POP3, these header fields would be
transmitted to other hosts with the raw CP437 or UTF-8 chars, thus violating
POP3 and SMTP protocols and likely resulting in garbage displayed in message
readers.

The fix is to encode (using MIME "encoded words", per RFC 2407) where
necessary.

Since moderm mail clients (e.g. Thunderbird) don't see to support CP437
charset in MIME encoded header fields, always translate to UTF-8 first.

We probably should be translating message body text to UTF-8 as well, for
maximum compatibilty with modern mail readers, but this commit doesn't address
body text issues with CP437-encoded content. That'll come later.

We don't log highwater valeus of 1, though those are published to MQTT.

Not dealing with 'services' server yet, cause that's kind of tricky with the
sysop likely wanting to know per-service stats (served counter, highwater
mark, etc.)

Fix observed crash when shutting down services server where the client_t
protocol was pointing to a freed service's protocol description string.

This was the last pointer in client_t and should resolve the last race
conditions (memory ownership issues) with its data members.

This also resolves a small memory leak in getnodeclient() where the last
client "gotten" would have its heap-duplicated protocol string leaked.

This resolves the conflict with MSG_HOLD definition in socket.h on MacOS:
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/socket.h

And hey... [NET]MSG_HOLD isn't actually used anywhere? What's up with that.

The Git commit date/time is more useful information.

Commit 75c5c9e5 was initially to address server termination (sisue #236), but
expanded in scope to include server recycling (e.g. due to semaphore/config
file touch) and that turns out to not be what most sysops want.

If you want an immediate/ungraceful recycle, do a restart (shutdown/stop and
then start) instead.

Immediate/ungraceful server shutdown/termination is still in effect however.

No change to the "server pause" feature either, so combining pause with
recycle would be effective to prevent *new* client connections while waiting
for existing clients to disconnect and allow a recycle to happen.

Both long long and long are reasonable for some mixes of platforms.

Just punt, cast the whole thing to int64_t, and forget about it.

But continue initializing/running for other non-TLS protocol support.

Use cryptDestroySession() instead.

Reported by Max (WESTLINE)...

Introduced in commit 75c5c9e5, since we are now calling the set_state()
callback periodically, and in sbbsctrl, it sets/resets the pause button
checked (depressed) state in response to this callback (should it?), this was
resetting the pause button checked/depressed state peridically (at the
configured sem file check interval, default 2 seconds).

The fix: if the new server state is the same as the previously set server
state, don't call the set_state() callback. I considered this as a potential
optimization when I first wrote that commit, but didn't see any obvious
downside to calling the set_state() callback redundantly. Now that I see a
downside, let's implement this saving/checking of the state to avoid
redundant "set" calls.

We have checks/loops/timeouts waiting for active clients to disconnect and
child thread threads to terminate whenever shutting down or recycling already,
so this should be safe. This pretty simple change fixes issue #236 (can't
terminate server under heavy load).

Also as part of this commit, introduced the ability to "pause" a server
(prevent it from accepting new connections) with the ctrl/pause semaphore
file or via the MQTT server/pause (and resume) topics. This feature is useful
when debugging server issues where you don't necessarily want to fully
shutdown/terminate the server, but don't want any new connections to be
accepted (the listen backlog will fill up with incoming connections though).
Unlike a server shutdown, a server pause can be "undone" via MQTT (by
publishing a message to the "resume" topic).

The "pause" semaphore file is just an "existence" semaphore file - its
date/time stamp doesn't matter. If the file exists, the server will enter
a paused state (and periodically log messages to that fact) until the semfile
is deleted.

This server pause feature is not the same as the pause button function in
sbbsctrl, which just pauses server log output.

The Global Login Requirements (default: blank) are used for any sever that doesn't have it explicitly set.

This resolves issue #666 (the issue of the beast) for Keyop