https://gitlab.synchro.net/main/sbbs/-/commit/8ede971ae8be2c67cbf4879e
Modified Files:
src/sbbs3/mailsrvr.cpp
Log Message:
Complete the BOOL->bool conversion

This likely fixes the recently-introduced heap corruption (sizeof BOOL != sizeof bool).

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/c5daf067bae2f7666c4ccfc2
Modified Files:
src/sbbs3/mailsrvr.cpp
Log Message:
Strip ctrl chars "B" mime-encoded words in incoming message header fields

Per RFC2047: "Only printable and white space character data should be encoded using this scheme."

Apparently TikTok doesn't follow that advice. Here's one example:

68% #614159 (1741720) TikTok Header field contains control characters
...
Subject 6C 69 76 6B 61 70 73 7A 6F 6F 20 70 6F 73 74 65 64 3A 20 4D 75 66 66 69 6E 20 73 61 69 64 20 0A 4E 6F 20 74 68 61 6E 6B 73 F0 9F AB A0

Which expands to:

"livkapszoo posted: Muffin said
No thanks¨"

This could do weird things when the message is viewed (depending on the viewer) and triggers the chksmb error: Control Characters in Header Fields (!): 1

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/47560c50d5d83383947c349a
Modified Files:
src/sbbs3/mailsrvr.cpp
Log Message:
Remove quotes from RCPT TO: <forward-path> before comparing to local names

This resolve an issue observed with Thunderbird sending to local:<name>@bbs: Unknown User: <"local:name"@vert.synchro.net>.

Presumably, Thunderbird is adding the quotes because of the colon. I've not seen this issue before, so perhaps this is new behavior of Thunderbird. In any case, RFC[2]821 specifies that the RCPT TO argument is a Mailbox and that the local-part of a Mailbox may be a quoted-string (instead of a dot-string). So, Synchronet hasn't been compliant in this regard all these years.

No special parsing of \" is implemented since we don't support quotes in names anyway. RFC 821 says the character following a backslash (<x>) may be
"any one of the 128 ASCII characters (no exceptions)" - that implies all control characters too, which sounds really dangerous. That language seems fixed in RFC 2821, but I'm not trying to solve all the crazy escaping possibilities in this simple commit.

The original RCPT TO argument (with quotes, if present) is still stored for subsequent forwarding or whatever.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/8409089bbc3b1e11c0d140f3
Modified Files:
src/sbbs3/mailsrvr.cpp
Log Message:
Cache the dnsbl_exempt.cfg file (mine is 2MB)

... this file was being read multiple times for every incoming SMTP message

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/63ee13b03befd229da39f7d1
Modified Files:
src/sbbs3/mailsrvr.cpp
Log Message:
Insure dnsbl_result is always zero-initialized

Fix recently-introduced bug

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/3b05d005e25a668fdd78aa20
Modified Files:
src/sbbs3/mailsrvr.cpp
Log Message:
Always clear the "from extension" for newly created bounce messages

This bug caused chksmb reported errors in bounced messages (e.g. from listserver):

97% #635909 (30AEF20) Mail Delivery Subsystem From extension mismatch MSGERR: From extension ((null)) does not match index (1)

packing or running fixsmb on the mail base would correct the index, but this
is the real fix.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/29763a38c718800231a135d1
Modified Files:
src/sbbs3/mailsrvr.cpp
Log Message:
Log the message relative number (and total msgs waiting) for POP3 retrievals

giving some indication of progress towards the last message waiting for the user

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/44f1d233a67e7ebf1a15586b
Modified Files:
src/sbbs3/mailsrvr.cpp
Log Message:
Reset a couple of mail-specific filter/listfile objects during cleanup()

Restoring pre commit c8490b7429f behavior with regards to these lists, only noticable in logged/printed stats.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/92ae6263408f0ddd5d05d802
Modified Files:
src/sbbs3/mailsrvr.cpp
Log Message:
mailsrvr: bound sockmimetext line scan with strnlen (CID 639931)

The inner while-loop walks (*np + len) up to RFC822_MAX_LINE_LEN bytes
relying on the embedded NUL test to stop early. When np points at the
"\r\n" literal used as the empty-body fallback (issue #822), Coverity
loses track of the literal's length and reports a 997-byte OVERRUN.
Compute the scan length up-front with strnlen so the bound is explicit; behavior is unchanged but the OVERRUN false-positive is silenced.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/52099548d7f5782b818bdbe7
Modified Files:
src/sbbs3/mailsrvr.cpp
Log Message:
mailsrvr: POP3 reply -ERR (not !UNSUPPORTED) to USER/PASS in TRANSACTION state

Some clients (e.g. Thunderbird) reuse an already-authenticated TCP socket
and re-issue USER/PASS. Per RFC 1939 these are AUTHORIZATION-state-only commands, so respond with a plain -ERR and keep the session alive,
matching Dovecot/Courier behavior and suppressing the misleading
"!UNSUPPORTED COMMAND" log notice.

Refs main/sbbs#1123

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/126ed841933b774477b5c1b1
Modified Files:
src/sbbs3/mailsrvr.cpp
Log Message:
mailsrvr: name the rejected address in the sender-auth 550 replies

The 550 reply for an unauthorized MAIL FROM or From: address named only the address to use instead, never the address that was rejected. The submitter
is left to guess which of the settings in their mail client the server is objecting to, and only the server log records it -- which the submitter
cannot read.

Seen on Vertrauen: "550 Sender address not authorized for this account, try <PHARCYDE@vert.synchro.net>" was read as a statement about the server
hostname the client had connected to, and answered with a question about
which hostname to use, when the setting at fault was the sender address.

Grow from_errmsg to 512 bytes: the header 'FROM' message now formats two addresses of up to 127 characters each, which 256 bytes could truncate.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/c6c715a40a2556421292cdc8
Modified Files:
src/sbbs3/mailsrvr.cpp
Log Message:
Mail Server: don't log POP3 passwords or SMTP AUTH credentials

Fixes #1267

With the receive/response debug options on, the mail server logged the
POP3 PASS line, the SMTP AUTH LOGIN username and password responses, the
AUTH PLAIN response (all base64, trivially decoded), and the AUTH PLAIN
initial response on the command line was logged at LOG_DEBUG regardless of options. The "!Bad AUTH ..." notices logged the raw argument at NOTICE
level. Anyone who could read the log could recover every password used to authenticate to the server.

Redact those lines unless the sysop has set the "Echo Passwords Locally"
system option (SM_ECHO_PW), the way the password-failure messages already
honor it: a received command line is logged through loggable_line(), which replaces a POP3 password or an AUTH initial response with a placeholder,
and a line that is nothing but credentials (an AUTH response) is logged as "<credentials>".

Verified on a scratch mail server with the debug options on: POP3 USER/PASS, AUTH PLAIN (initial response and challenge forms), AUTH LOGIN and a
malformed AUTH LOGIN argument all authenticate or fail as before, and the
log holds no trace of the password in clear or base64; with SM_ECHO_PW set
the lines are logged in full, as before.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/d4f33e47976414b619032701
Modified Files:
src/sbbs3/mailsrvr.cpp
Log Message:
mailsrvr: stop sending the message after a body line fails to send

When a send failed partway through the message body, sockmimetext()
broke out of the body loop but still went on to MIME-encode any
attachments and send the "." end-of-data terminator over the dead
connection. With DKIM signing enabled, that terminator finalized the
verify pass's body hash over the truncated body, so every dropped
connection mid-DATA was also logged as the error "DKIM body hash changed between sign and send - message delivery aborted", though nothing had
changed and the delivery had already failed.

Return as soon as a body line fails to send, as is already done when the
header terminator fails.

Fixes #1279

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/1728d248fb27d5d1cf0737e9
Modified Files:
src/sbbs3/mailsrvr.cpp
Log Message:
mailsrvr: POP3 LIST/UIDL skips unreadable messages instead of stopping

In the POP3 LIST and UIDL (all messages) loop, a failure to read a
message's index entry, lock its header, or read its header ended the
listing early. Every message after the bad one was then missing from
the client's view of the mailbox. Skip just the bad message instead:
the error is still logged, and the other messages keep their POP3
numbers, so RETR and DELE still work on them. A failed socket write
still ends the loop.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/dd868cf96f01d669158e480b
Modified Files:
src/sbbs3/mailsrvr.cpp
Log Message:
Mail server: keep the mailproc script's callback struct alive with its context

Fixes a crash in sbbs.dll (remove_js_socket_event) when an SMTP client
thread ends.

b43e1c8256 (2009-01-14) made js_mailproc() reuse one JS runtime, context
and global object per SMTP client thread, created on the first mailproc
and destroyed only when the thread ends, but left its js_callback_t as a
local of js_mailproc(). The "js" object and the client.socket Socket
object created in that persistent global recorded a pointer to the local,
which was gone as soon as the first js_mailproc() call returned.

Nothing followed that stale pointer after the call until 85e04a4262 (2026-09-30) made every Socket object remember its script's callback
struct at creation and consult it when closed. From then on, destroying
the context at thread end finalized client.socket, do_js_close() walked
the event list of a js_callback_t that was a dead stack frame, and the
mail server crashed with an access violation.

Move the js_callback_t to smtp_client_thread(), beside the runtime,
context and global, and pass it to js_mailproc(). It is still zeroed and
given the logger on each invocation, as before.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net