https://gitlab.synchro.net/main/sbbs/-/merge_requests/736#note_10617

Thanks for this. Two things before it goes in:

**1. The description's "before" behavior isn't right.**

Netmail addressed to "TRACE" was handled as an AreaMgr request.

On master, the robot block in `import_netmail()` is only entered when the
To name is `AreaFix`, `SBBSecho`, or `PING`. A netmail to `TRACE` never
reaches it, so it goes through ordinary netmail import: user number, sysop alias list, user name lookup, then `DefaultRecipient`. With none of those matching, it is logged as an unknown user. It was never parsed as AreaFix commands.

That sentence describes the intermediate state of this patch: adding
`TRACE` to the outer `if` without the new branch would have dropped it into
the `else { /* AreaMgr */ }` case. Please drop it from the commit message.

**2. This doesn't implement what #278 asks for, so `Fixes #278` would close
it prematurely.**

#278 is about the nodelist PING-flag *TRACE function*: when a netmail
addressed to **PING** passes **through** a node flying the PING flag on
its way to another destination, that in-transit node notifies the sender
and forwards the original message unaltered. That is a routing-time
behavior keyed on PING, not a robot answering mail addressed to `TRACE` at
its final destination.

The `TRACE` robot here overlaps heavily with the existing PING reply, which already returns the full received message text, Via lines included. If the numbered route list is the value you're after, it may fit better as an
addition to the Pong reply than as a new robot name.

If you'd like to keep this MR as-is (a standalone TRACE robot), please
change `Fixes #278` to a plain `#278` reference so the issue stays open for
the in-transit notification. Otherwise, the in-transit part is what would actually close it.

-- *Authored by Claude (Claude Code), on behalf of @rswindell*

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

https://gitlab.synchro.net/main/sbbs/-/merge_requests/736#note_10627

Following up on point 2 above: the FidoNet standard and a current thread
in the FTSC PUBLIC echo both indicate that a robot answering netmail
addressed to `TRACE` is non-standard, so I don't think this should go in as written.

**The spec:** FTS-4010.001 ("The PING and TRACE flags", http://ftsc.org/docs/fts-4010.001), section 3, defines TRACE only as an in-transit behavior keyed on **PING**:

- PING flag: a netmail to user "PING" that reaches its *final destination*
is bounced back to the sender, quoting the Via lines.
- TRACE flag: a netmail to user "PING" that is *merely passing through* a
node flying TRACE causes that node to notify the sender (quoting the Via
lines) and forward the original unaltered toward its destination.
- PING and TRACE responses must never be sent from, or addressed to, "PING".

"TRACE" is not defined as a recipient name anywhere in it.

**FTSC PUBLIC, "PING / TRACE" thread (2026-10-15/16):** several sysops
received netmail addressed to "TRACE" (sender unknown, not necessarily
anyone involved here). Wilfred van Velzen: "There is no such thing as a
TRACE request! 'TRACE' is not a defined destination adres that should
generate an auto-response." Michiel van der Vlist (FTS-4010's author)
deleted his. Andrew Leary, FTSC Administrator: a system receiving one is
free to ignore, delete, or bounce it; no response is required.

**What #278 actually needs** is the in-transit half: when SBBSecho routes a netmail addressed to "PING" that is not for one of its own addresses, it
sends the sender a notification quoting the Via lines and forwards the
original unaltered. SBBSecho has nothing like that today; "PING" is only checked in the final-destination robot in `import_netmail()`.

If you're up for it, reworking this MR toward that would be welcome (and
would legitimately close #278). Otherwise I'd suggest closing this one.

-- *Authored by Claude (Claude Code), on behalf of @rswindell*

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