https://gitlab.synchro.net/main/sbbs/-/issues/1215#note_10051
Root-caused. There are two separate defects here, and they need separate
fixes: one in the mail server that writes the header, one in the mail reader that acts on it.
### 1. The header should not say the sender is on another system
Your intuition about `SenderNetType` is right. When a user submits mail over authenticated SMTP, `mailsrvr` stores the message with `SENDER_NETTYPE` of `NET_INTERNET` and a `SENDERNETADDR` of the sender's own address, even when
the recipient is a local user and both parties are accounts on this BBS. Note that your header already carries `SenderExt 792`, so the server knew perfectly well which local user sent it.
There is a branch that sets the sender net type to "none" for an
authenticated submission, but it has been qualified with "only when posting to a sub-board" since d21065229b (knee-4-prepare, 2009-11-12), which is where it was introduced. E-mail was never covered.
Fixing it takes a little care, because the sender header fields are written once, before the per-recipient loop, and one submission can name both local
and remote recipients. For a recipient on another system the sender net
address is what selects the reverse-path as the envelope sender and what
routes a delivery-failure notice back, so it cannot simply be dropped. The fix sets the sender to the authenticated user's alias up front, then adds the sender net type and address per recipient copy, only for copies whose
recipient is not local. Mail leaving the system is unchanged, and the `From` header your POP3/IMAP client sees is unaffected either way, since that is rendered from the preserved RFC822 `From` field.
### 2. The reply itself fails, and that is a reader bug
This is what actually produced your screenshot, and it is why fixing the
header alone would not help you.
The prompt in your screenshot comes from `exec/msglist.js`, which is what `readmail` is configured to run. Its `mail_reply()` chooses between `bbs.netmail()` and `bbs.email()` on the sender net type alone. Since the type says Internet, it calls `bbs.netmail()`, which refuses the address because it is on one of this system's own domains, and you get "Invalid NetMail address" and "Failed to send".
Sending that mail back out through your own SMTP server used to work by accident, until 4aa2274c97 (provide-5-player, 2026-01-22) stopped netmail to our own addresses. The built-in mail reader was given a fallback at that time, in be05f55db5 (chest-4-dies, 2026-02-11): if the address will not route as netmail but the message carries a sender user number, reply by regular e-mail to that user instead. `msglist.js` never got the equivalent, and `msglist.js` is what is actually running.
So it now falls back the same way. Replies to genuinely remote senders are unaffected, because that fallback needs a sender extension, which a message from another system does not carry.
### Which fix helps you when
The reader fix is the one that answers the mail already sitting in your base, including the message you posted here, because it does not care how the header was written. It is a `.js` file, so it takes effect without a rebuild.
The server fix only changes mail received from that point on. You will need to rebuild for it.
### Verified
Both were checked end to end against a scratch BBS rather than by inspection. With the server fix, an authenticated local user's mail to a local user is stored with the sender alias and no net address, while the same user's mail to a remote address keeps `SenderNetType Internet` and the sender net address, and mail from an unauthenticated remote sender is unchanged. With the stock reader, replying to a message carrying the old header reproduces "Invalid NetMail address" and "Failed to send" exactly as you saw; with the fix, the same reply goes to "Sending E-mail to ... #2" and delivers to the sender's inbox.
Thanks for the detailed header dump, it made this a lot quicker to pin down.
*Authored by Claude (Claude Code), on behalf of @rswindell*
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)