https://gitlab.synchro.net/main/sbbs/-/commit/6033e9d61dad951da5d36309
Modified Files:
docs/v322_new.md exec/load/binkp.js
Log Message:
BinkIT: don't record successful binkp/1.1 callouts as failures

The JSBinkP session loop only breaks out on *receiving* a final M_EOB,
but in binkp/1.1's two-M_EOB handshake the completed state is usually
reached by *sending* the last EOB. After sending it, the peer closes
the connection, and the next loop iteration attempts one more M_EOB on
the now-closed socket; that send fails and (since b795cf6a3d) marked the
whole session as failed -- even though all files had already been sent
and acknowledged. binkit.js then wrote "[callout failure]" to data/binkstats.ini with the sent file(s) listed.

binkp/1.0 peers (Mystic, mbcico) exchange a single M_EOB each and break immediately on receipt, so they were recorded correctly; the bug hit
binkp/1.1 peers (Synchronet/BinkIT, binkd) -- the vast majority of
sessions -- producing huge "failed_callouts" counts despite mail
flowing fine. Reported in DOVE-Net's sync_sysops by Khronos and Gamgee.

Fix: a failed closing M_EOB send is benign once our sent files have all
been acknowledged (pending_ack empty); break the loop without failing
the session in that case. Only fail when files remain unacknowledged.
The on-wire behavior is unchanged. Bumped JSBinkP revision to 6 so the
fix is identifiable via the vers= field in binkstats.ini.

Validated with a two-process TCP loopback harness: binkp/1.1 callout
flips from false to true (file transferred either way); binkp/1.0 and
no-files polls unchanged; a peer that drops mid-transfer still fails.

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

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

https://gitlab.synchro.net/main/sbbs/-/commit/c00526fb8f7f91aa16e28eee
Modified Files:
docs/v322_new.md exec/load/salib.js exec/spamc.js
Log Message:
spamc.js/salib.js: let SpamAssassin see the originating relay IP

Enable the synthetic Received-header injection (set msg.hello_name from
the mailproc hello_name global) so spamd can identify the connecting
client and run sender-IP DNSBLs (Spamhaus, etc.) and SPF -- previously
every message scored with NO_RELAYS/NO_RECEIVED, neutering those checks.

Strip the synthetic Received from the re-written message so the stored
mail doesn't duplicate the Received the mail server adds at delivery
(the duplicate that caused this to be disabled in f886a41 / only-3-strip). Strip it on its own: SA consumes the injected Return-Path, so a combined
match never hit.

Validated live: NO_RELAYS/NO_RECEIVED gone, SPF_PASS + RCVD_IN_* now
firing, stored messages carry exactly one Received header.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
(cherry picked from commit 567c45486b2cb958d70a2fabe2bd9f29e2c8ade0)

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

https://gitlab.synchro.net/main/sbbs/-/commit/63844fa110647fc2660da61b
Modified Files:
docs/v322_new.md exec/load/ircd/core.js unregistered.js
Log Message:
ircd: serialize manual CONNECT, and stop answering ERROR with a numeric

IRCClient_do_connect() declined to start when Outbound_Connect_in_Progress
was set but never set it itself, so for the duration of an operator's
/CONNECT the flag stayed clear and a scheduled Automatic_Server_Connect()
could dial a second server concurrently -- the case 0b4056bbcf (2024-06-19) added the flag to prevent. It also meant every manual /CONNECT logged "Outbound connection while !Outbound_Connect_in_Progress" when the socket callback found the flag already false.

Unregistered_Commands() had no case for ERROR, so a server refusing our handshake -- which reports why with ERROR just before dropping the link --
was answered with 461 "You have not registered", and the reason went no
further than the raw protocol log. Log it and notify routing opers
instead. Outbound links are named by their configured server name, since
an unregistered client's hostname defaults to the socket's peer address,
which is not yet resolvable at that point in the connect callback.

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/45e2c6c9e5b64ac90f4b2728
Modified Files:
docs/v322_new.md exec/load/sbbsdefs.js src/sbbs3/logon.cpp newuser.cpp sbbsdefs.h src/sbbs3/scfg/scfg.c scfg.h scfgindex.h scfgnode.c scfgxtrn.c src/sbbs3/xtrn_sec.cpp
Log Message:
Add a "clear screen before execution" option for external programs

Some external programs clear or overwrite the user's terminal as soon as
they start. Run from a logon event, such a program can wipe text the user
has not yet read. The new XTRN_CLS online program option clears the
screen before the program is executed, using the BBS's own clear-screen
(cls), which first prompts the user to continue if there is unread
output on the screen. GitLab #1243.

The screen is cleared once the program is sure to run (all early-return
checks done) and before the drop file is written and the node status,
start time, inactivity timeout, and MQTT exec event are set, so a long
pause at the prompt affects none of them.

Logon and New User fixed events get the same option (FEVENT_CLS), along
with a pause-after-execution option (FEVENT_PAUSE). A fixed event's
settings are external() mode bits, so these use bits that external()
ignores. The other fixed events run offline and don't offer them.

In SCFG, the online program "Pause After Execution" option becomes
"Terminal Control" (None, Clear, Pause, or "Clear, Pause"), which prompts
for both settings; ESC at the first prompt skips the second. The Logon
and New User fixed event menus offer the same option. toggle_flag() now
returns the list selection so a caller can detect an abort. The fixed
event copy of the option is kept out of the search index, which cannot
tell which fixed events offer it.

scfgindex.h is regenerated, which also picks up the Msg/File Total
Interval option added in 875357a01a (2026-08-17).

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

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