Is order ever significant for netnews headers?
InterLinked <nntp@phreaknet.org> writes:
Is order ever significant for netnews headers?
No, at least not that I'm aware of.
One thing this leaves open is what the best practices would be when
using a reading account to send articles to Usenet.
The only workaround I can think of for this is to have the injector omit
the Injection-Info header when feeding the article and munge the Path
header to omit .POSTED (leaving its site in, to avoid loops), though
that feels somewhat awkward.
On 5/19/2026 9:58 PM, Russ Allbery wrote:
InterLinked <nntp@phreaknet.org> writes:
Is order ever significant for netnews headers?
No, at least not that I'm aware of.
Thanks; another related question on headers - RFC 5537 spells out a few protections against duplicate injection, namely that sites MAY reject articles with .POSTED in the Path, and Injection-Info MUST NOT be present.
One thing this leaves open is what the best practices would be when
using a reading account to send articles to Usenet. I think it's
somewhat more common (or at least, not super uncommon) to have some
smaller servers set up to "suck" articles from a peered server if they aren't themselves peered with other Usenet servers. Likewise, for
posting, a server could likewise receive articles from other sites and
then inject them into Usenet. This way you could run your own Usenet
server and just use a reader account to interact with Usenet, without needing to peer, at least initially.
Am 20.05.26 um 04:29 schrieb InterLinked:
On 5/19/2026 9:58 PM, Russ Allbery wrote:
InterLinked <nntp@phreaknet.org> writes:
Is order ever significant for netnews headers?
No, at least not that I'm aware of.
Thanks; another related question on headers - RFC 5537 spells out a
few protections against duplicate injection, namely that sites MAY
reject articles with .POSTED in the Path, and Injection-Info MUST NOT
be present.
Are there usual situations where a newsreader includes the Path: header?
One thing this leaves open is what the best practices would be when
using a reading account to send articles to Usenet. I think it's
somewhat more common (or at least, not super uncommon) to have some
smaller servers set up to "suck" articles from a peered server if they
aren't themselves peered with other Usenet servers. Likewise, for
posting, a server could likewise receive articles from other sites and
then inject them into Usenet. This way you could run your own Usenet
server and just use a reader account to interact with Usenet, without
needing to peer, at least initially.
UUCP over IP exists for such situations, as this doesn't need a
permanent connection.
InterLinked <nntp@phreaknet.org> writes:
One thing this leaves open is what the best practices would be when
using a reading account to send articles to Usenet.
Yeah, the standard purist answer is "don't do that" because it breaks a
bunch of desirable Usenet properties, but that's sometimes not a practical answer.
I think it's best to think of this as a type of gatewaying (specifically,
a type of incoming gateway). You have to transform the article in order to reinject it, and you therefore are running the risk of creating injection loops and you need to take the precautions required of gateways. There is considerable discussion of the risks of gateways and the measures they
should take here:
https://datatracker.ietf.org/doc/html/rfc5537#section-3.10
The only workaround I can think of for this is to have the injector omit
the Injection-Info header when feeding the article and munge the Path
header to omit .POSTED (leaving its site in, to avoid loops), though
that feels somewhat awkward.
Correct, this is what you have to do. (Well, either omit or rename,
depending on whether that information is of any use on Usenet.)
But RFC 5537 says that Path MUST be removed for duplicate injection
and elsewhere only says the Path header SHOULD NOT contain .POSTED, not
that it MUST NOT exist...
Another more direct conflict: 3.4.1 says Injection-Date MUST be supplied
for multiple injection, but 3.5 #1 says if both Date and Message-ID are already present, Injection-Date MUST NOT be added, so it is seemingly impossible to satisfy both requirements at once here?
On the other hand, I would think a server would not want a client to set
this to something different (e.g. Bell Laboratories), since the
Organization is a reflection of the originating server rather than a
poster, so it feels like it would be reasonable to reject articles that
had one.
InterLinked <nntp@phreaknet.org> writes:
But RFC 5537 says that Path MUST be removed for duplicate injection
I'm not sure what you mean by duplicate injection. The Path header MUST be removed or renamed when reinjecting an article that was already injected elsewhere (as opposed to multiple injection done by offering the same proto-article to a bunch of injecting agents at the same time).
That's because presumably it already has a .POSTED component and it can't be injected again with that present.
and elsewhere only says the Path header SHOULD NOT contain .POSTED, not
that it MUST NOT exist...
I think that SHOULD NOT is a minor bug in the standard, since the
injecting agent MUST reject articles that contain a .POSTED segment (see 3.5). So in practice a .POSTED segment MUST NOT be present in a
proto-article if you want to successfully post it. Maybe we left it as
SHOULD NOT because it would work with a pre-RFC-5537 injecting agent?
Seems like an oversight, though.
Another more direct conflict: 3.4.1 says Injection-Date MUST be supplied
for multiple injection, but 3.5 #1 says if both Date and Message-ID are
already present, Injection-Date MUST NOT be added, so it is seemingly
impossible to satisfy both requirements at once here?
Those are two different pieces of software that have different
requirements. Section 3.5 is about the duties of the news *server* (specifically, the component that accepts POST commands), not the client
like 3.4.1.
On the other hand, I would think a server would not want a client to set
this to something different (e.g. Bell Laboratories), since the
Organization is a reflection of the originating server rather than a
poster, so it feels like it would be reasonable to reject articles that
had one.
Nah. In practice, Organization is a free-form field into which posters can put anything they want (and do). The standard allows either the client or
the server to set it, but in practice, I'd just leave it to the client.
It's not really useful for anything beyond easter eggs (and never really
has been).
On 5/20/2026 11:37 PM, Russ Allbery wrote:
That's because presumably it already has a .POSTED component and it
can't be injected again with that present.
It makes sense, but I would think the .POSTED component could be removed
and the others retain, so that the rest of the path is preserved when reposting it, rather than neutering the existing path history.
Speaking of Path, in looking at examples of headers in Usenet articles, I found this (as just one substring in the path): "!fx18.iad.POSTED!"
I *think* this is ill-formed, as it doesn't seem valid from RFC 5537.
It seems it might be beneficial to recognize ".POSTED" even when not at
the beginning of string, to account for incorrect servers like this one (assuming this is indeed incorrect).
Those are two different pieces of software that have different
requirements. Section 3.5 is about the duties of the news *server*
(specifically, the component that accepts POST commands), not the
client like 3.4.1.
But in certain cases, they could be the same host, as in my example of receiving an article from a peer and sending it to Usenet via a reading connection, i.e. now behaving like a client.
In this situation, if Date and Message-ID are already present in the
article, but not Injection-Date, but then a reading connection is used
to post to Usenet, now it is impossible to comply with both
requirements...
InterLinked <nntp@phreaknet.org> writes:
On 5/20/2026 11:37 PM, Russ Allbery wrote:
That's because presumably it already has a .POSTED component and it
can't be injected again with that present.
It makes sense, but I would think the .POSTED component could be removed
and the others retain, so that the rest of the path is preserved when
reposting it, rather than neutering the existing path history.
I think that would be rather deceptive and would change the meaning of the header. Renaming is surely better?
Speaking of Path, in looking at examples of headers in Usenet articles, I
found this (as just one substring in the path): "!fx18.iad.POSTED!"
I *think* this is ill-formed, as it doesn't seem valid from RFC 5537.
Yup.
There are some things like that which predate the standard, or are just
from confused sites or sites that don't care about the standard. (But in
this case I think it's the former.)
It seems it might be beneficial to recognize ".POSTED" even when not at
the beginning of string, to account for incorrect servers like this one
(assuming this is indeed incorrect).
Recognize and do what with it, though? By the time the article has been injected and is propagating, it's too late, unless you want to reject such articles entirely, which is probably more destructive than is warranted.
Those are two different pieces of software that have different
requirements. Section 3.5 is about the duties of the news *server*
(specifically, the component that accepts POST commands), not the
client like 3.4.1.
But in certain cases, they could be the same host, as in my example of
receiving an article from a peer and sending it to Usenet via a reading
connection, i.e. now behaving like a client.
I'm now really confused about what scenario you're describing; 3.5 is irrelevant to such a client since there is no injecting agent involved in either of those operations. That's just a case of reinjection. In that
case, you MUST NOT add an Injection-Date header if none is present. See
the third paragraph of 3.4.2. This is a case of gatewaying.
In this situation, if Date and Message-ID are already present in the
article, but not Injection-Date, but then a reading connection is used
to post to Usenet, now it is impossible to comply with both
requirements...
I think the third paragraph of 3.4.2 is the relevant bit here, so I think
the problem is just that you thought 3.5 was relevant to this, but it's
not.
That's fair, is there any standard for that like Resent-Path or
Original-Path or not really? I see Original-Sender but no other original headers mentioned.
That also makes me think if, for some bizarre reason, the renamed header already existed, what to do then?
Recognize and do what with it, though? By the time the article has been
injected and is propagating, it's too late, unless you want to reject
such articles entirely, which is probably more destructive than is
warranted.
What I was wondering before is if receiving from a reading client if it
seems warranted to reject such an article or not as "already posted".
Okay, I see, because when it *receives* the article, it's from a peer
and not a reader... that makes sense.
On 5/20/2026 3:01 PM, Marco Moock wrote:
Am 20.05.26 um 04:29 schrieb InterLinked:
On 5/19/2026 9:58 PM, Russ Allbery wrote:
InterLinked <nntp@phreaknet.org> writes:
Is order ever significant for netnews headers?
No, at least not that I'm aware of.
Thanks; another related question on headers - RFC 5537 spells out a
few protections against duplicate injection, namely that sites MAY
reject articles with .POSTED in the Path, and Injection-Info MUST NOT
be present.
Are there usual situations where a newsreader includes the Path: header?
It's allowed by RFC 5537, but I was referring to an article going
through actual transit servers, where the hop to Usenet just happens to
use a reading connection instead of a peering connection. In such a case
you would expect a Path and expect .POSTED.
I would also guess with UUCP there could be quite a path prior to
injection though I'm not as familiar with that.
One thing this leaves open is what the best practices would be when
using a reading account to send articles to Usenet. I think it's
somewhat more common (or at least, not super uncommon) to have some
smaller servers set up to "suck" articles from a peered server if
they aren't themselves peered with other Usenet servers. Likewise,
for posting, a server could likewise receive articles from other
sites and then inject them into Usenet. This way you could run your
own Usenet server and just use a reader account to interact with
Usenet, without needing to peer, at least initially.
UUCP over IP exists for such situations, as this doesn't need a
permanent connection.
I wasn't thinking about not having a permanent connection specifically;
just not having a peering arrangement for any reason. I would assume
that not just any old somebody running an NNTP server can easily peer
with established Usenet servers? Or maybe I'm wrong and it's more open
than I assumed.
For context, I would like to peer eventually, but since I am writing my
own software, would probably want to stick with a reader connection for
a little bit until I'm sure all the kinks have been worked out. That way
I don't irritate anybody if I'm not able to accept articles 24/7 early
on as I fix unforseen issues and fine tune the groups I want to carry.
No reason to use UUCP just for that as I see it.
The scenario described is not hypothetical though as I do plan to have a private news network for private hierarchies, but also carry "curated" Usenet groups of interest to distribute amongst the locally peered servers.
Another question that isn't discussed - the Organization header. I
believe practice is for only injecting servers to add this header, but I don't see anywhere that proto-articles MUST NOT contain this header. On
the other hand, I would think a server would not want a client to set
this to something different (e.g. Bell Laboratories), since the
Organization is a reflection of the originating server rather than a
poster, so it feels like it would be reasonable to reject articles that
had one.
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 70 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 01:50:49 |
| Calls: | 949 |
| Calls today: | 1 |
| Files: | 1,325 |
| Messages: | 281,112 |