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)

--- Platinum Xpress/Win/WINServer v10.0pr1
* 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)

On 2026 Jun 17 14:33:58, you wrote to Robert Wolfe:

--- Platinum Xpress/Win/WINServer v10.0b40
* Origin: Over the Brink : Grand Island, NY - brinkbbs.org (99:1/6)

--- Platinum Xpress/Win/WINServer v10.0pr1
* 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.

FWIW: it was a simple copy'pasta of the message from the original area to this area... one of two things should have been done... either the OP would have manually invalidated the othernet origin lines OR the message editor should have done it when the message was saved and a proper origin line for the destination FTN was added... apparently the editor doesn't do this so the OP should... it isn't that big a deal, really, and wildcat! has done this for decades... it is not the only one, either...

)\/(ark

"The soul of a small kitten in the body of a mighty dragon. Look on my majesty, ye mighty, and despair! Or bring me catnip. Your choice. Oooh, a shiny thing!"
... Cats are meant to be loved, not to be understood
---
* Origin: (1:3634/12.73)

Hello, Robert!

Wednesday June 17 2026 18:56, from Robert Wolfe -> Nil Alexandrov:

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.

Your quotes were incorrect. That's why my "gold standard" golded screw them up as well.

This is a bug most likely and I will report it to Santronics to get
it corrected. Ah the joys of running beta level software, but at
least its being modernized with binkp support.

There is a new modern trend to vibecode your own FTN SW.
Actually, previous stage was - I don't report a bug and wait for the fix. I just fixed it with my AI help and here is the peer request which nobody will ever accept for a couple of reasons: slopcode, too many PRs because of AI popularity, and/or maintainers have switched to something else in their life.
The current stage - I'll vibecode my own FidoNet editor the way I want. I have a couple of recent examples, but here is offtopic.

Best Regards, Nil
--- GoldED+/LNX 1.1.5-b20260305
* Origin: Gemini can make mistakes, so double-check it (2:5015/46)