Subj : Othernet in the echo (was: file correction)
To   : Robert Wolfe
From : Nil Alexandrov
Date : Wed Jun 17 2026 02:33 pm

Robert,

Tuesday June 09 2026 21:23, from Robert Wolfe -> Andrew Leary:

[...]
 >> -> @TID: PX/Win v10.0b47 PX35-1001M
 >> -> @MSGID: 99:1/1 92df6477
[...]
 >> ->  * Origin: Santronics Online (99:1/1)
[...]
 >> --- Platinum Xpress/Win/WINServer v10.0b40
 >>  * Origin: Over the Brink : Grand Island, NY - brinkbbs.org (99:1/6)
 RW> --- Platinum Xpress/Win/WINServer v10.0pr1
 RW>  * Origin: Santronics Online (99:1/1)

This is not about binkd at all. The binkp talk is beside the point.
What jumped out at me is the message plumbing.

The post shows up as from 99:1/1. That's not a FidoNet address, that's
othernet. Policy 4, 2.1.3 says if outside traffic enters FidoNet through
your system, then the FidoNet node doing the gating has to be clearly
identified as the point of origin.

The PATH says this thing entered through 1:261/20, which is your FidoNet
node. So if mail from zone 99 is being gated into a Fido echo, it ought to
come in as 1:261/20, not 99:1/1. Otherwise replies are aimed at an address
that isn't even in the Fido nodelist.

There's also another zone-99 address in the quoted text, 99:1/6. Same basic
problem: othernet addressing leaking into a Fido echo.

Second problem, and this is separate: no MSGID on the actual message. FTS-9
may call MSGID optional, but it also says MSGID/REPLY must not be stripped
in transit. In practice, no MSGID means broken reply linkage, lousy dupe
tracking, and confused gateways. If your software is dropping MSGIDs, that's
a bug. If it never wrote one, that's not much better.

So this isn't a binkd issue. It's a gating/tosser issue.

And honestly, if this echo has a moderator, this sort of thing should have
been caught already. That's part of keeping an echo from turning into a
junk drawer.

---
 * Origin: old FTN habits die hard (1:16/101)

.