The argument to JS_NewContext that we were allowing to be configured was not the contest stack size, but rather:
"The size, in bytes, of each "stack chunk". This is a memory management tuning parameter which most users should not adjust. 8192 is a good default value." - per Mozilla.

So we're just going to use the suggested default, hard-coded.

Revert the previous change to the mailsrvr (don't try to parse the MS Outlook singled-quoted names in to/from header fields).

Instead, use the new matchusername() to perform a liberal name match against the name portion of the destination email address and if it matches, go ahead and use the quoted-name field. Otherwise, use the name portion of the destination address as the TO field for the FTN netmail message.

instead of the potentially-alias'd delivery address. The angle-brackets
(now included) appear to be standards-compliant.

Parse single-quoted "name" portion of email-addr header fields. I don't think this is going to fully solve the issue with FTN netmail gated to SMTP and replied via Outlook, but it's a start. Try that Nelgin.

The "MAIL FROM" command argument must always be enclosed in angle-brackets. Some mail servers (e.g. gmail, aol) would reject messages not delivered in this manner, e.g.:
mx-aol.mail.gm0.yahoodns.net replied with:
"501 Syntax error in parameters or arguments tnmpmscs"
instead of the expected reply:
"250 ..."
gmail-smtp-in.l.google.com replied with:
"555 5.5.2 Syntax error. o6si11103060plk.317 - gsmtp"
instead of the expected reply:
"250 ..."

I'm fed-up with MSVC assertions in ctype functions (e.g. isdigit, isprint, isspace, etc.) when called with out-of-range (e.g. negative) values.

This problem only affects MSVC debug builds, but if you run them (like I do), these things are like little time bombs that can drive you crazy (knocking your board out of service).

The new macros names are bit more descriptive as well.

For non-authenticated SMTP clients, if the "From:" header field contains a "name" which appears to be an email address (i.e. it has an '@' in it), and that address does not match the *actual* address in the "From:" field, reject the mail with an error message about the forged/mismatched address.

This work-around shouldn't be necessary, but at least on my Linux/Samba setup, when GitLab sends out notification emails to subscribers and creates 4+ simultaneous SMTP connections and sends email messages, sometimes (often) it ends up with a lock-timeout on the mail base. The file locking should handle the contention fine, but somehow I end up in scenarios where savemsg() takes 30 seconds to complete (the configured SMB lock-timeout is 30 seconds, likely not a coincidence) - and this causes other clients to timeout trying to lock the base. Just use a sharead-mutex here instead as a work-around. The wait time is indefinite, might want to consider using a timed-wait instead.

Putting IP addresses first.

Log the IP address first in most log messages.
Condense white-space in log messages to a single space.
Log the server IP address of incoming connections.
(more) Intelligent email address enclosure in angle-brackets.
Better duplicate address comparison (just for log message).
Fix wrong order of lprintf arguments in !UNKNOWN USER log message (new bug).

Like the Terminal Server, don't count authenticated connections against the MaxConcurrentConnections limit.

Only authenticated users with passwords (not Guest) count as authenticated connections.

This might not be so great for IPv6 connections (let me know).

Also, use macro for the maximum received SMTP bad command magic number.

Fix-up the sender and recipient info included in log messages in the sendmail thread too.

Bumped rev to 1.735.

Weird that no mail server has ever complained; I guess they're all prettty
"liberal in what they accept".

Also, eliminated an unnecessary strcpy() call.

The mail (SMTP) server is a popular target of bots. Impose a maximum-concurrent-connections limit (optionally). Similar to the terminal server option, except, don't deduct the number of authenticated connections (I can add something like that if desired). The new config option is [mail] MaxConcurrentConnections in the ctrl/sbbs.ini (defaults to 0, no maximum).

Fixed error responses in mail_server accept loop: was always sending POP3 error responses even if the connection was SMTP.

Cleaned-up the service/port checking/logging in the mail_server accept loop: no strcmp() needed, log the protocol name (e.g. "SMTPS") instead of the service name (e.g. "submissions").

Also, if getuserdat() fails, don't count that as a failed login attempt.
Also, track username and password of failed-login attempts of deleted or inactive user accounts.

active_clients is destroyed in cleanup(), so it must be re-initialized inside
the server init/recycle loop.

Fix reported and observed crash in cleanup() (in ftp, mail, websrvr)
when failing to create the temp directory. This was due to cleanup()
being called before the protected integer "active_clients" was
initialized.

Also, md() needs to return the errno value (not a BOOL) since the
caller may be in another DLL with a different errno (which likely
has a value of 0/no error).

... in other non sbbs.dll modules (e.g. *srvr.dll).

So now log error messages elsewhere where appropriate.

DLL-exported and optimized md() a bit.

Eliminate the hack in each server where it will over-write startup host_name
(with the configured Internet email address), if it's blank. This hack was
subject to a race condition where the parent app (e.g. sbbsctrl.exe) would
clear or re-initialize the host_name after the sever threads had initialized.
Instead, just use a function which will return either the startup->host_name
or (fallback to) scfg.inet_addr.

Add another "get cryptlib error string" (at least, that's what I assume GCES
stands for) that allows the log level to be specified, rather than derived
from Cryptlib thinks the log level should be. Do this rather than adding one
(lowering the severity) of every cryptlib log message as I did in the previous
commit to this file.

(e.g. errors become warnings) - I'm tired of seeing this in my
error.log every day:
SEND/TLS ... ERROR 'Received TLS alert message: Handshake failure' (-15) setting session active

The problem: the sysop (me) is not notified of critical errors (e.g. synchro.net zone file problems) in a timely manner.
Part of the solution: notify a configured user (e.g. user #1) via short-message/telegram and email/netmail logged-errors when messages of a configured severity (e.g. "Critical") are logged.
The second part of the solution (coming next) will be allowing timed events to log a message of a configurable severity logged when the event fails (returns a non-zero error level to sbbs).

I'm saving the error-notification-user-number and log-severity as part of the node.cnf file because:
- that's where the validation user number is already set
- I can conceive of a large system were certain node ranges (different instances of sbbs) might want different operators to be notified of logged-errors

This also means I eliminated all the legacy com port/modem stuff from the end of the node.cnf file. None of that is used in sbbs v3.

Also included in this commit are improvements around logging:
- reduce the severity of UDP recvfrom failures in services
- a more detailed log message when the mail server successfully delivers an email (via SMTP) - easier to answer the question: was that email you/they sent delivered successfully?

FTN Reply-IDs are not added here (yet).

SEND using auto-detected DNS server address: 2001:4860:4860::
!SEND INVALID DNS server address: 2001:4860:4860::
Fix off-by-one buffer overflow while at it.

SCFG for Win32 is linked against a load_cfg lib that builds withOUT SCFG defined, so these compiled AR elements were allocated and then many SCFG operations (e.g. copy/paste, create new) would copy the allocated ARs to another configuration and then be subjected to double-free upon exit/clean-up (resulting in exception or crash).
Just get rid of this cruft and some other related RAM-byte-saving hold-overs from the MS-DOS days.

*always* set the KILLSENT attribute flag on email/netmail received for relay via SMTP (regardless of the Internet/Fido netmail setting in SCFG).
The sender should already have a copy (e.g. in their outbox), if they want to keep it.

MSG_SENT is in the netattr field, not the attr field. Double-oops. Thanks Dan_C and Nelgin for bringing to my attention.

Set the KILLSENT network attribute for created Internet email messages when enabled in SCFG->Networks->Internet (new option).
Do the same for FidoNet NetMail messages routed via SMTP.
Only auto-delete sent Internet mail messges when either the KILLSENT
network attribute flag is set or there was no SENDEREXT (from_ext) on the sent message.

the net-attributes header fields.