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