Replies in echomail areas through Synchronet's NNTP server include "All" in the To: field. I had assumed this was standard behavior for SBBS, similar to the old NNTP-FTN gateways. (However, the REPLY kludge appears to be functioning correctly, allowing messages to be properly threaded.)
After reviewing the source code of nntpservice.js, I discovered a function named getReferenceTo. If I'm not mistaken, this function should return the recipient's name, but it defaults to "All" when a recipient isn't found.
Could it be that this function isn't working as intended?
Re: NNTP and To: field
By: Carlos Navarro to digital man on Tue Nov 04 2025 05:07 pm
Replies in echomail areas through Synchronet's NNTP server include
"All" in the To: field. I had assumed this was standard behavior
for SBBS, similar to the old NNTP-FTN gateways. (However, the
REPLY kludge appears to be functioning correctly, allowing
messages to be properly threaded.)
After reviewing the source code of nntpservice.js, I discovered a
function named getReferenceTo. If I'm not mistaken, this function
should return the recipient's name, but it defaults to "All" when
a recipient isn't found.
Could it be that this function isn't working as intended?
If a recipient isn't found, "All" seems like a sensible default. Are
you saying the failure to find a recipient is a bug? Feel free to
play with it and offer up a patch if you have one.
Replies in echomail areas through Synchronet's NNTP server include
"All" in the To: field. I had assumed this was standard behavior for
SBBS, similar to the old NNTP-FTN gateways. (However, the REPLY
kludge appears to be functioning correctly, allowing messages to be
properly threaded.)
After reviewing the source code of nntpservice.js, I discovered a
function named getReferenceTo. If I'm not mistaken, this function
should return the recipient's name, but it defaults to "All" when a
recipient isn't found.
Could it be that this function isn't working as intended?
If a recipient isn't found, "All" seems like a sensible default. Are you saying the failure to find a recipient is a bug? Feel free to play with
it and offer up a patch if you have one.
Hey Digital!
On Tue, 04 Nov 2025 14:01:02 -0800, you wrote:
Replies in echomail areas through Synchronet's NNTP server include
"All" in the To: field. I had assumed this was standard behavior for
SBBS, similar to the old NNTP-FTN gateways. (However, the REPLY
kludge appears to be functioning correctly, allowing messages to be
properly threaded.)
After reviewing the source code of nntpservice.js, I discovered a
function named getReferenceTo. If I'm not mistaken, this function
should return the recipient's name, but it defaults to "All" when a
recipient isn't found.
Could it be that this function isn't working as intended?
If a recipient isn't found, "All" seems like a sensible default. Are you saying the failure to find a recipient is a bug? Feel free to play with it and offer up a patch if you have one.
I think what he was saying, is that even when there /is/ a recipient (doesn't just about every 'reply' message have a recipient?), it still uses "All" (and I don't disagree that is indeed how NNTP has always worked).
nelgin wrote to All <=-
If a recipient isn't found, "All" seems like a sensible default. Are
you saying the failure to find a recipient is a bug? Feel free to
play with it and offer up a patch if you have one.
I like the Synchronet "You touch it, you own it" model :)
I think what he was saying, is that even when there /is/ a recipient
(doesn't just about every 'reply' message have a recipient?), it
still uses "All" (and I don't disagree that is indeed how NNTP has
always worked).
No, not all USENET replies have a recipient.
X-Comment-to is not a requirement or universally used.
If a recipient isn't found, "All" seems like a sensible default. Are
you saying the failure to find a recipient is a bug? Feel free to
play with it and offer up a patch if you have one.
I like the Synchronet "You touch it, you own it" model :)
I thought NNTP didn't have a to: field?
I think what he was saying, is that even when there /is/ a recipient
(doesn't just about every 'reply' message have a recipient?), it
still uses "All" (and I don't disagree that is indeed how NNTP has
always worked).
No, not all USENET replies have a recipient.Correct, however /this/ (as in what I'm fairly certain we're discussing) isn't USENET. We're using NNTP to access our message bases (which may or
may not actually carry USENET). I think this conversation was much more pointing towards BBS/FTN messages. Most local and FTN messages
(particularly replies) on a BBS usually have a recipient (do they not?), unless it's specifically sent to "All".
X-Comment-to is not a requirement or universally used.
You're right. However, in the hobby we are involved in, it makes the
normal "To" and "From" fields look like everyone elses that aren't using NNTP. I also wasn't stating that Synchronet needed to do that, I was
just mentioning that's how I got around all of my messages posted with a newsreader being addressed to "All".
What (I think?) the question from the OP was, was asking why /all/
messages are addressed to "All" when it seems like there's something
already in the code that is looking for a recipient it could be filling
the "To" field with on a reply?
but with Thunderbird and slrn I am able to stuff an "X-Comment-To" field into the headers so that they both reply to the specific person all
of the time.
05 Nov 2025 17:08, you wrote to Digital Man:Here is a message posted with Thunderbird with the "X-Comment-To" field filled in.
> but with Thunderbird and slrn I am able to stuff an "X-Comment-To" field
> into the headers so that they both reply to the specific person all
> of the time.
Interesting! Could you share how to do that in TB?
Yes, that's what I meant. Thanks, Nick.
This is a reply to a message from Accession in the SYNCHRONET echomail
area, sent via Thunderbird on the NNTP server of a Synchronet-based BBS.
The message will likely be posted to the echo with recipient "To: All" instead of "To: Accession"
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 15 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 29:48:06 |
| Calls: | 178 |
| Files: | 21,502 |
| Messages: | 79,214 |