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 Linux lock() implementation in xpdev/filewrap.c requires that
_FILE_OFFSET_BITS is set to 64 or else OFD (sane) locks are not
used on Linux, defaulting back to the crazy per-process file region
locking of Linux of old. This was done in this commit:
http://cvs.synchro.net/commitlog.ssjs?99999#39639
because:
https://patchwork.kernel.org/patch/9289177/

but on 64-bit Linux, large file support is assumed and you don't
actually need to define _FILE_OFFFSET_BITS, we're peforming this
check for 32-bit Linuxes. Perhaps a check to see if sizeof(off_t)
== 8 would have been better. However, this change enables OFD
Locks for *all* flavors of Linux (not just 64-bit) - so that's
better.

Why do we care? Because using region locks on the same file in
a multi-threaded program doesn't really work right on Linux without
using OFD Locks. I saw this problem with receiving multiple
simultaneous emails in the mailserver and getting smb_locksmbhdr()
errors/failures when trying to save the message data or headers
of the one or more messages every time GitLab would send email
out to those whoe have opted-in to received email notifications
upon gitlab.synchro.net activity.

And separate the saved/imported message text into body and tail (separate SMB msg data fields) automatically to exclude signatures from quoted text.

As requested by Tracker1.

This allows a .sig file to contain "\n-- \n", the "standard" USENET signature delimiter, as requested by Tracker1.

Removed the yield line interval (this is a questionable setting anyway).

Also, made the unlimited max-connections display as "N/A" (instead of
"0") in the Terminal Server config dialog.

Cleans both debug and release build dirs.

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.

When loginFailure() is called with NULL for the password argument, that indicates there was no password available (e.g. an aborted login attempt) - treat each of these as a unique (not duplicate) failed-login attempt. This'll trigger ban/filter thresholds sooner for clients that hammer servers and disconnect mid-login.

At least on Windows, when realloc() is used to allocate a new buffer,
guess what's in that buffer initially? undefined values. So you can't
strcat() onto the end of that! Ouch. This was a fun one to track down.

Also, don't truncate strings to accommodate screen width when the string contains a new-line character.
This is so ScottD (from irc.synchro.net) can use TEXT:556 @-code to print the Ctrl-K menu (text.dat string) via a command shell written in Baja.

Also, auto-set blank node paths in write_main_cfg() (which is called from SCFG) instead of save_cfg() and so now call write_node_cfg() *after* write_main_cfg() in save_cfg(). This should help insure we're saving sane node paths to main.cnf.

Use BIRTH instead of BDATE if you want MM/DD/YYYY (or DD/MM/YYYY) instead of MM/DD/YY or DD/MM/YY formatted birthdate display.

New aliases (for consistency): BIRTHFMT -> BDATEFMT and BIRTH:<fmt> -> BDATE:<fmt>

Can't say I don't blame them, it is a little unnatural. So instead, use either MM/DD/YYYY (the default) or DD/MM/YYYY (European date mode). This required the use of a new @-code: BDATEFMT and the update of a couple of text.dat lines (in next commit).

New bug, reported by Melkor (STARFRON).

The host portion contains ":" after split_port_part(), resulting in a 400
error.
Renaming is_legal_hostname() to is_legal_host(), since requests to webservers are to
"hosts" not "hostnames".

MSVC Error D8016. Just disable "edit and continue" support.

Also added a .gitignore file.

Have msgtoqwk() return a negative number upon error (e.g. blank message, failed to read to body text), which means *no* message header was written to the messages.dat file, so don't increment the record (block) counter used to create the index (NDX) file.

If msgtoqwk() returns 0, that means that a header was written, but no body text (e.g. a vote message) and that is different than an error.

When both Indexes (NDX files) and vote messages are included in a QWK packet (an unexpected, but valid combination), the "Record number" stored in NDX files for subs with votes would be incorrect as it did not increment when a vote message (with no body text) was added to the messages.dat file.

Reported by user that was trying to use MultiMail to read a QWK packet that included both votes and indexes and "IgnoreNDX: No" in their .mmailrc file.

putmsg(), used to display messages and display/menu files, will no longer pass-through the ANSI sequence ESC[c (found in some corrupted ANSI posts to fsxNet->FSX_BOT echo) to the client terminal since this will stimulate a (unwanted) response from the client.

I do wonder if the outchar_esc value check should be == here instead of >=, but I'm not familiar with the string and SOS states. I wonder if any display files sent from the BBS would ever include those sequences.

No functional change with regard to the ANSI output state, just making the code easier to read.

Removed the conversion of `[ and \xFA[ to \x1b[ in putmsg(). This unexplained output translation has been supported since at least v2.xx and I have no recollection of exactly why it was added. If I recall correctly, some BBS software at some point in time sent ANSI-encoded messages into message networks by translating the ESC (\x1b) character in the ANSI sequences to either ` or \xFA in the process. This "feature" seems like it would still work, but it's completely undocumented and I have no idea why it was added (and seriously doubt anyone relies on this behavior), so I'm removing it. If anyone misses this feature, I'll happily add it back, but I'm skeptical that'll happen.

When reading messages, circumvent ANSI-encoded messages by replacing the ESC
character (ASCII 27) with '.'. This could be made an optional behavior if
someone really wants ANSI-encoded messages to be read via smbutil.

Also, allow continuous reading of 1 or more consecutive messages using the
-<digit> option (no prompting).

<nelgin> However, dm should probably maintain it at the source.
<nelgin> DigitalMan, I've uploaded gtkuseredit_glade.c which also widens "Sex" to 5 chars
<nelgin> I've also uploaded my .glade file for comparison
<nelgin> and I've uploaded my convert perl script.
<DigitalMan> the sex/gender field is a single character
<nelgin> Yes, but it doesn't display properly unless I widen it to 5.
<DigitalMan> ah

The password was (recently) limited to 8 chars, so that made sense.
The 24 character limit of the real name does not make sense and I can only
assume it was a typo.

- DATE: (alias: TIME:)
- BDATE:
- PWDATE:
- SINCE:
- LASTON:
- FIRSTON:
- LASTNEW:
- EXPDATE:

Truncating. str is a pointer, so sizeof(str) is only 4 (or 8) bytes.

e.g. MM/DD/YY for drop files that assume that format, or either MM/DD/YY or
DD/MM/YY (depending on sysop preference) for backwards compatibility in
expanded @-codes, Guru chat keyword.

Fixed the birthdate check while logging on to work with new/all birthdate
formats.

... and up to 200 years old (hey, I'm optimistic!)