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"
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've been playing a bit and here's a patch. Edit nntpservice.js (line 107 in revision 1.2, or line 111 in current 1.3) and change:
var hdr2 = mb.get_msg_header(hdr.reply_id);
to:
var hdr2 = mb.get_msg_header(hdr.reply_id + '');
There may be another way, but this seems to work.
I've been playing a bit and here's a patch. Edit nntpservice.js
(line 107 in revision 1.2, or line 111 in current 1.3) and change:
var hdr2 = mb.get_msg_header(hdr.reply_id);
to:
var hdr2 = mb.get_msg_header(hdr.reply_id + '');
There may be another way, but this seems to work.
That change would just change (force) hdr.reply_id to be a string. It
should already be a string, so that change should do nothing.
That change would just change (force) hdr.reply_id to be a string. It should already be a string, so that change should do nothing.
However, hdr.reply_id is not a string, but an object (a string object).
And
then, mb.get_msg_header() doesn't find anything and returns null.
I guess that something has to be fixed elsewhere (I am not familiar with Synchronet's code), but my quick patch doesn't break anything and it works for now: replies in echomail via NNTP have "To: recipient" instead of "To: All".
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"
You were correct. It came through addressed to "All".
I guess that something has to be fixed elsewhere (I am not familiar with Synchronet's code), but my quick patch doesn't break anything and it works for now: replies in echomail via NNTP have "To: recipient" instead of "To: All".
I'll look into it more.
I just wrote and executed a quick test and the msg header reply_id
property does appear to be a string, as expected:
var msgbase = new MsgBase("test");
if(!msgbase.open())
exit();
var hdr = msgbase.get_msg_header(27);
print(typeof hdr.reply_id);
when run, prints 'string'.
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"
You were correct. It came through addressed to "All".
Another reply, but now with the patch I posted (thanks for testing,
Angel).
12 Nov 2025 23:21, you wrote to me:
I just wrote and executed a quick test and the msg header reply_id property does appear to be a string, as expected:
var msgbase = new MsgBase("test");
if(!msgbase.open())
exit();
var hdr = msgbase.get_msg_header(27);
print(typeof hdr.reply_id);
when run, prints 'string'.
Ok, in that script nothing happens to hdr after loading from the MSGbase. But in nntpservice.js, before being passed to function getReferenceTo, it is processed by function parse_news_header (in newsutil.js). It seems hdr.reply_id is then an array of string (typeof "object"). I think it happens here:
hdr.reply_id = data.match(/<[^\<]*>$/);
| Sysop: | Gate Keeper |
|---|---|
| Location: | Shelby, NC |
| Users: | 804 |
| Nodes: | 20 (0 / 20) |
| Uptime: | 177:52:16 |
| Calls: | 13,390 |
| Calls today: | 1 |
| Files: | 5,294 |
| D/L today: |
50 files (31,135K bytes) |
| Messages: | 606,237 |