On Mar 19, 2023 at 9:01:31 PM CDT, "Grant Taylor" <gtaylor@tnetconsulting.net> wrote:

Hi,

One of my peers brought something to my attention that they think is not correct about my configuration. They have provided enough information
to make me think I need to change something.

Before I make changes, I want to better understand what various INN
options are and how they will impact my servers.

First, I have two news servers, one is -- what I call -- my public
transit server (with a small spool) that peers with all my peers and the other is my private archive server (with a much larger spool) and only
peers with my transit server.

I've been using "tnetconsulting.net" as the entry in the Path header
thinking that it is a superset of <host>.tnetconsulting.net or <host>.<subdomain>.tnetconsulting.net. It seems as if this is probably
the incorrect value to be using.

My peer has suggested either "pathalias" or "pathcluster" with a value
of "tnetconsulting.net".

My two news servers perform different roles and I would never consider
them to be any form of cluster with each other. So I think that "pathcluster" is a non-starter.

Will someone please help me understand what my two servers should be
doing and how pathalias might influence how they interact with each
other and the rest of Usenet?

Please and thank you.

N.B. I've not named the peer in question out of courtesy. I have no objection to them naming themselves.

Hehe - the peer in question is me. To shed further light on why Grant is asking, I noticed Grant's issue when I switched to Diablo which does Path matching diagnostics and I noticed this in messages coming from his site:

Path:nnrp.usenet.blueworldhosting.com!!spool1.usenet.blueworldhosting.com!dia blo1.usenet.blueworldhosting.com!usenet.blueworldhosting.com!45.33.28.24.MISM ATCH!tncsrv06.tnetconsulting.net!tncsrv09.home.tnetconsulting.net!.POSTED.alp ha.home.tnetconsulting.net!not-for-mail

I had a similar configuration as Grant and told him I was using "pathalias usenet.blueworldhosting.com" with INN.

I think this is a good discussion as I think based on stuff I've seen here
that INN 2.8.0 will add this Path diagnostic feature similar to Diablo.

Cheers,

Jesse

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

One of my peers brought something to my attention that they think is not correct about my configuration. They have provided enough information
to make me think I need to change something.

Before I make changes, I want to better understand what various INN
options are and how they will impact my servers.

First, I have two news servers, one is -- what I call -- my public
transit server (with a small spool) that peers with all my peers and the
other is my private archive server (with a much larger spool) and only
peers with my transit server.

I've been using "tnetconsulting.net" as the entry in the Path header
thinking that it is a superset of <host>.tnetconsulting.net or <host>.<subdomain>.tnetconsulting.net. It seems as if this is probably
the incorrect value to be using.

My peer has suggested either "pathalias" or "pathcluster" with a value
of "tnetconsulting.net".

My two news servers perform different roles and I would never consider
them to be any form of cluster with each other. So I think that
"pathcluster" is a non-starter.

Will someone please help me understand what my two servers should be
doing and how pathalias might influence how they interact with each
other and the rest of Usenet?

Please and thank you.

N.B. I've not named the peer in question out of courtesy. I have no
objection to them naming themselves.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/19/23 8:08 PM, Jesse Rehmer wrote:

Hehe - the peer in question is me.

;-)

To shed further light on why Grant is asking, I noticed Grant's issue
when I switched to Diablo which does Path matching diagnostics and
I noticed this in messages coming from his site:

Path:nnrp.usenet.blueworldhosting.com!!spool1.usenet.blueworldhosting.com!dia blo1.usenet.blueworldhosting.com!usenet.blueworldhosting.com!45.33.28.24.MISM ATCH!tncsrv06.tnetconsulting.net!tncsrv09.home.tnetconsulting.net!.POSTED.alp ha.home.tnetconsulting.net!not-for-mail

I had a similar configuration as Grant and told him I was using "pathalias usenet.blueworldhosting.com" with INN.

I suspect that I'm going to end up using pathalias as you suggested.

I'm hoping to learn and understand better what should be happening, why
it should be happening, and how I'm (accidentally) going against that now.

I think this is a good discussion as I think based on stuff I've seen here that INN 2.8.0 will add this Path diagnostic feature similar to Diablo.

:-)



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mar 19, 2023 at 9:18:53 PM CDT, "Grant Taylor" <gtaylor@tnetconsulting.net> wrote:

On 3/19/23 8:08 PM, Jesse Rehmer wrote:

Hehe - the peer in question is me.

;-)

To shed further light on why Grant is asking, I noticed Grant's issue
when I switched to Diablo which does Path matching diagnostics and
I noticed this in messages coming from his site:

Path:nnrp.usenet.blueworldhosting.com!!spool1.usenet.blueworldhosting.com!dia
blo1.usenet.blueworldhosting.com!usenet.blueworldhosting.com!45.33.28.24.MISM
ATCH!tncsrv06.tnetconsulting.net!tncsrv09.home.tnetconsulting.net!.POSTED.alp
ha.home.tnetconsulting.net!not-for-mail

I had a similar configuration as Grant and told him I was using "pathalias >> usenet.blueworldhosting.com" with INN.

I suspect that I'm going to end up using pathalias as you suggested.

I'm hoping to learn and understand better what should be happening, why
it should be happening, and how I'm (accidentally) going against that now.

I think this is a good discussion as I think based on stuff I've seen here >> that INN 2.8.0 will add this Path diagnostic feature similar to Diablo.

:-)

To piggy onto this, and something I would like to further understand, is the proper 'technically expected' usage of pathalias vs pathcluster.

I understand the two basically differ whether they append or preprend the element, but I'm not certain which is correct to use in which scenarios.

As I explained to Grant via e-mail, in my experience it didn't seem to matter the ordering of the Path elements so much, but more that the Path I've told my peers to expect appears somewhere in the Path header of articles I offer to them.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/19/23 8:27 PM, Jesse Rehmer wrote:

To piggy onto this, and something I would like to further understand,
is the proper 'technically expected' usage of pathalias vs pathcluster.

+1

I understand the two basically differ whether they append or preprend
the element, but I'm not certain which is correct to use in which
scenarios.

I'm trying to think about how peers might behave depending on the
ordering of ":<host>.<domain>.<tld>:<domain>.<tld>:" vs ":<domain>.<tld>:<host>.<domain>.<tld>:".

My guess below is predicated on the host being "<host>.<domain>.<tld>"
and the pathalias being "<domain>.<tld>":

I can see how having ":<host>.<domain>.<tld>:<domain>.<tld>:"
(pathalias) would cause a peer to not feed to any server (in a
multi-server configuration) if it was configured to exclude
":<domain>.<tld>:".

Hence why in a clustered set of multiple servers, one would likely want
the ":<domain>.<tld>:" to come later (to the left of) than the ":<host>.<domain>.<tld>:".

As I explained to Grant via e-mail, in my experience it didn't seem
to matter the ordering of the Path elements so much, but more that
the Path I've told my peers to expect appears somewhere in the Path
header of articles I offer to them.

:-)



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mar 20, 2023 at 1:26:23 PM CDT, "Julien ÉLIE" <iulius@nom-de-mon-site.com.invalid> wrote:

Hi Jesse,

I noticed Grant's issue when I switched to Diablo which does Path
matching diagnostics and I noticed this in messages coming from his site:

Path:nnrp.usenet.blueworldhosting.com!!spool1.usenet.blueworldhosting.com!dia
blo1.usenet.blueworldhosting.com!usenet.blueworldhosting.com!45.33.28.24.MISM
ATCH!tncsrv06.tnetconsulting.net!tncsrv09.home.tnetconsulting.net!.POSTED.alp
ha.home.tnetconsulting.net!not-for-mail

FWIW, the standardized syntax is "!.MISMATCH.45.33.28.24", in coherence
with "!.POSTED.alpha.home.tnetconsulting.net". The diagnostic is
followed with a value.

I had a similar configuration as Grant and told him I was using "pathalias >> usenet.blueworldhosting.com" with INN.

I think this is a good discussion as I think based on stuff I've seen here >> that INN 2.8.0 will add this Path diagnostic feature similar to Diablo.

According to Diablo's changelog:

Diablo V1.12

Added Path: name checking. If the first element of the Path:
received by an article does not match any 'alias' statements
for the incoming connection, the IP address is prepended
to the path: with .MISMATCH appended.

NOTE <<< you should grep through newly created spool> directories >>>> every so often looking for .MISMATCH in the spool

files to locate incoming feeds with improperly configured
'alias's (in dnewsfeeds). When I turned this feature on,
I found that four of my 80+ feeds were misconfigured.

So the Diablo syntax is backwards?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Jesse,

I noticed Grant's issue when I switched to Diablo which does Path
matching diagnostics and I noticed this in messages coming from his site:

Path:nnrp.usenet.blueworldhosting.com!!spool1.usenet.blueworldhosting.com!dia blo1.usenet.blueworldhosting.com!usenet.blueworldhosting.com!45.33.28.24.MISM ATCH!tncsrv06.tnetconsulting.net!tncsrv09.home.tnetconsulting.net!.POSTED.alp ha.home.tnetconsulting.net!not-for-mail

FWIW, the standardized syntax is "!.MISMATCH.45.33.28.24", in coherence
with "!.POSTED.alpha.home.tnetconsulting.net". The diagnostic is
followed with a value.

I had a similar configuration as Grant and told him I was using "pathalias usenet.blueworldhosting.com" with INN.

I think this is a good discussion as I think based on stuff I've seen here that INN 2.8.0 will add this Path diagnostic feature similar to Diablo.

According to Diablo's changelog:

Diablo V1.12

Added Path: name checking. If the first element of the Path:
received by an article does not match any 'alias' statements
for the incoming connection, the IP address is prepended
to the path: with .MISMATCH appended.

>>> NOTE <<< you should grep through newly created spool
directories every so often looking for .MISMATCH in the spool
files to locate incoming feeds with improperly configured
'alias's (in dnewsfeeds). When I turned this feature on,
I found that four of my 80+ feeds were misconfigured.


I would then suggest to update the alias parameter in dnewsfeeds to
match the one of Grant's server.

--
Julien ÉLIE

« When a newly married couple smiles, everyone knows why. When a ten-
year married couple smiles, everyone wonders why. »

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Jesse,

So the Diablo syntax is backwards?

For the "!45.33.28.24.MISMATCH" path diagnostic?
It was implemented before the final version of the RFC standardizing it.
The expected standardized one is "!.MISMATCH.45.33.28.24".

It may be worthwhile fixing it in a patch... If Miquel wishes to add it
to its waiting-to-be-merged list of patches.
I also reported a few years ago that Diablo's answer to LISTGROUP
command was not the right one, but unfortunately there's no longer any
active development for Diablo.

--
Julien ÉLIE

« Avez-vous remarqué qu'à table les mets que l'on vous sert vous mettent
les mots à la bouche ? » (Raymond Devos)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mar 20, 2023 at 2:20:06 PM CDT, "Julien ÉLIE" <iulius@nom-de-mon-site.com.invalid> wrote:

Hi Jesse,

So the Diablo syntax is backwards?

For the "!45.33.28.24.MISMATCH" path diagnostic?
It was implemented before the final version of the RFC standardizing it.
The expected standardized one is "!.MISMATCH.45.33.28.24".

It may be worthwhile fixing it in a patch... If Miquel wishes to add it
to its waiting-to-be-merged list of patches.
I also reported a few years ago that Diablo's answer to LISTGROUP
command was not the right one, but unfortunately there's no longer any
active development for Diablo.

Given the large number of profitable commercial entities using Diablo, I am quite certain that development has occurred, but is not being shared with the rest of us.

Not a developer, but looking at the source, the only place I see any reference to MISMATCH is here in util/diablo.c:

/*
* check first path element against aliases
* in dnewsfeeds file.
*/
if (PathElmMatches(HLabel, p, bytes, &idx) < 0) {
sprintf(ipfail, "%s.MISMATCH!", PeerIpName);
if (ReportedNoMatch == 0) {
ReportedNoMatch = 1;
logit(LOG_NOTICE, "%-20s Path element fails to match aliases: %*.*s in %s",
HName, idx, idx, p, msgid);
}
} else {
strcpy(ipfail, "");
}

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Jesse,

Given the large number of profitable commercial entities using Diablo, I am quite certain that development has occurred, but is not being shared with the rest of us.

:-(

sprintf(ipfail, "%s.MISMATCH!", PeerIpName);

This line should just be changed to:

sprintf(ipfail, ".MISMATCH.%s!", PeerIpName);

It will then correctly write "usenet.blueworldhosting.com!.MISMATCH.45.33.28.24!tncsrv06.tnetconsulting.net".

--
Julien ÉLIE

« Aue, aue, aues esse aues ? »

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mar 20, 2023 at 3:37:07 PM CDT, "Julien ÉLIE" <iulius@nom-de-mon-site.com.invalid> wrote:

Hi Jesse,

Given the large number of profitable commercial entities using Diablo, I am >> quite certain that development has occurred, but is not being shared with the
rest of us.

:-(

It's annoying and a damn shame. I am absolutely in love with the decentralized architecture of Diablo, and would like to make further use of it via central article numbering, multiple decentralized spools, etc., but the lack of information that is easy to find and lack of community to help point me in the right direction makes it very frustrating.

Once upon a time I stumbled on a great presentation given by someone from a major provider back in the day, maybe it was XSNews, that had slides showing their architecture and some configuration tidbits, but I didn't archive it and can no longer find it. :-(

sprintf(ipfail, "%s.MISMATCH!", PeerIpName);

This line should just be changed to:

sprintf(ipfail, ".MISMATCH.%s!", PeerIpName);

It will then correctly write "usenet.blueworldhosting.com!.MISMATCH.45.33.28.24!tncsrv06.tnetconsulting.n et".

Thanks for confirming. I thought it was that simple, but I'm generally completely lost in C. I've recompiled and have confirmed the proper format of the MISMATCH element.

Now if only there were somewhere USEFUL to submit patches. ;-)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mar 20, 2023 at 4:27:57 PM CDT, "Jesse Rehmer" <jesse.rehmer@blueworldhosting.com> wrote:

On Mar 20, 2023 at 4:18:51 PM CDT, "Grant Taylor" <gtaylor@tnetconsulting.net>
wrote:

On 3/20/23 12:26 PM, Julien ÉLIE wrote:

Hi Jesse and Grant,

Hi,

Path: pathcluster!!pathhost!!pathalias!...

Thank you for clarifying that.

From inn.conf documentation:

pathalias
The main purpose of this parameter is to configure all news servers
within a particular organization to add a common identity string to the
Path header field body.

pathcluster
The main purpose of this parameter is to make several news servers
appear as one server.


This way, you tell your peers that they should expect "pathcluster" as
the last and unique name for your outgoing feeds.

Is "pathcluster" a place holder in your statement or are you suggesting
that I use "pathcluster"/

And "pathalias" is used to add another name in the Path (for instance in >>> the case we recently discussed to add a specific server name so that
articles are not fed to this news server by others).

Since my multiple servers are not pretending to be one server I think I
should use "pathalias". Correct?

So that the leftmost path entry is unique for all your outgoing feeds.

ACK

After reading Julien's explanation, I believe you want to use pathcluster on your feeder machine so that the "tnetconsulting.net" element is the first/left-most element in the path when you pass the article to a peer.

I also fixed my Diablo configuration. The ordering of the '-c' (Common path) and '-p' (Feeder/hostname path) flags matter when you start Diablo, and I had them in the wrong order, and thus technically causing a MISMATCH from my end.
:-)

Now usenet.blueworldhosting.com should always appear as the final Path element when handing articles to peers.

Good discussion all, looking forward to INN 2.8.0 adding the Path diagnostic!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/20/23 12:26 PM, Julien ÉLIE wrote:

Hi Jesse and Grant,

Hi,

Path: pathcluster!!pathhost!!pathalias!...

Thank you for clarifying that.

From inn.conf documentation:

pathalias
The main purpose of this parameter is to configure all news servers
within a particular organization to add a common identity string to the
Path header field body.

pathcluster
The main purpose of this parameter is to make several news servers
appear as one server.

This way, you tell your peers that they should expect "pathcluster" as
the last and unique name for your outgoing feeds.

Is "pathcluster" a place holder in your statement or are you suggesting
that I use "pathcluster"/

And "pathalias" is used to add another name in the Path (for instance in
the case we recently discussed to add a specific server name so that
articles are not fed to this news server by others).

Since my multiple servers are not pretending to be one server I think I
should use "pathalias". Correct?

So that the leftmost path entry is unique for all your outgoing feeds.

ACK



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mar 20, 2023 at 4:18:51 PM CDT, "Grant Taylor" <gtaylor@tnetconsulting.net> wrote:

On 3/20/23 12:26 PM, Julien ÉLIE wrote:

Hi Jesse and Grant,

Hi,

Path: pathcluster!!pathhost!!pathalias!...

Thank you for clarifying that.

From inn.conf documentation:

pathalias
The main purpose of this parameter is to configure all news servers
within a particular organization to add a common identity string to the
Path header field body.

pathcluster
The main purpose of this parameter is to make several news servers
appear as one server.


This way, you tell your peers that they should expect "pathcluster" as
the last and unique name for your outgoing feeds.

Is "pathcluster" a place holder in your statement or are you suggesting
that I use "pathcluster"/

And "pathalias" is used to add another name in the Path (for instance in
the case we recently discussed to add a specific server name so that
articles are not fed to this news server by others).

Since my multiple servers are not pretending to be one server I think I should use "pathalias". Correct?

So that the leftmost path entry is unique for all your outgoing feeds.

ACK

After reading Julien's explanation, I believe you want to use pathcluster on your feeder machine so that the "tnetconsulting.net" element is the first/left-most element in the path when you pass the article to a peer.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Jesse,

I also fixed my Diablo configuration. The ordering of the '-c' (Common path) and '-p' (Feeder/hostname path) flags matter when you start Diablo, and I had them in the wrong order

I am reassured that INN isn't the only news server with trapdoors in its configuration :-)

Good discussion all, looking forward to INN 2.8.0 adding the Path diagnostic!

It will normally be in the 2.7.2 release; we do not necessarily need a
major release for this change. Not before the end of this year though.

Meanwhile, if you have any suggestions, here is what I had in mind.
A new "pathmatch" parameter in incoming.conf expects a wildmat pattern
and has no default value.
If the leftmost path identity of an incoming article from a peer matches
the pattern value of that parameter (in incoming.conf) when set or, when
unset, equals the label of the peer, then a double "!!" will be
prepended to the Path header field to show it has been successfully
verified.
If the leftmost path identity does not match the pattern, when set, "!.MISMATCH." is prepended along with the peer IP, and a notice log is
written to say there's a path mismatch (the log is written only once
*per connection* from the peer, and will be reported in Usenet daily
reports as unknown lines near the beginning of the report).

In all other cases, "!.SEEN." with the peer IP is added, without any
notice log.

There's a special case to deal with: articles coming from a local Unix
domain socket (like connections to innd by rnews or nnrpd). I would
suggest "!.SEEN.localhost" for them (except of course when the path
identity corresponds to nnrpd's "!.POSTED", in which case we do not add
a path diagnostic).
I don't think "!!" or "!.MISMATCH." is suitable for these articles as
the path identity may be different than the real one of the remote peer,
and I do not see any way to ensure that (when processing rnews batches
coming from an external source, UUCP, etc. we no longer know the source).

This proposal permits not generating a "!.MISMATCH." if the admin does
not set an explicit "pathmatch" entry for a peer. It will therefore not surprise him, and won't introduce spurious "!.MISMATCH." in the wild.


I would also suggest a new "pathdiag" parameter, set to true by default,
that can be used at global scope and also per peer, to disable the
feature. Maybe a "pathdomainsocketdiag" parameter would also be useful
to configure the same thing for local Unix domain sockets (they do not
have a peer configuration in incoming.conf).

Any thoughts about that or other suggestions?

--
Julien ÉLIE

« Il n'y a que le premier pas qui coûte. » (Mme du Deffand)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mar 20, 2023 at 5:16:41 PM CDT, "Julien ÉLIE" <iulius@nom-de-mon-site.com.invalid> wrote:

Hi Jesse,

I also fixed my Diablo configuration. The ordering of the '-c' (Common path) >> and '-p' (Feeder/hostname path) flags matter when you start Diablo, and I had
them in the wrong order

I am reassured that INN isn't the only news server with trapdoors in its configuration :-)

Don't adopt Diablo. ;-)

Good discussion all, looking forward to INN 2.8.0 adding the Path diagnostic!

It will normally be in the 2.7.2 release; we do not necessarily need a
major release for this change. Not before the end of this year though.

Gotcha, I thought I had read somewhere that the path diagnostic wasn't going
to be until 2.8.0.

Meanwhile, if you have any suggestions, here is what I had in mind.
A new "pathmatch" parameter in incoming.conf expects a wildmat pattern
and has no default value.
If the leftmost path identity of an incoming article from a peer matches
the pattern value of that parameter (in incoming.conf) when set or, when unset, equals the label of the peer, then a double "!!" will be
prepended to the Path header field to show it has been successfully
verified.
If the leftmost path identity does not match the pattern, when set, "!.MISMATCH." is prepended along with the peer IP, and a notice log is written to say there's a path mismatch (the log is written only once
*per connection* from the peer, and will be reported in Usenet daily
reports as unknown lines near the beginning of the report).

This is more or less equivalent to the behavior of Diablo's "alias" parameter in dnewsfeeds that accepts wildmat patterns, though it doesn't implement the verified !! portion.

In all other cases, "!.SEEN." with the peer IP is added, without any
notice log.

Can you explain further what "other cases" this would be applicable to?

There's a special case to deal with: articles coming from a local Unix
domain socket (like connections to innd by rnews or nnrpd). I would
suggest "!.SEEN.localhost" for them (except of course when the path
identity corresponds to nnrpd's "!.POSTED", in which case we do not add
a path diagnostic).
I don't think "!!" or "!.MISMATCH." is suitable for these articles as
the path identity may be different than the real one of the remote peer,
and I do not see any way to ensure that (when processing rnews batches
coming from an external source, UUCP, etc. we no longer know the source).

I'd have to really think more about this, but can see where this might get a little ugly.

This proposal permits not generating a "!.MISMATCH." if the admin does
not set an explicit "pathmatch" entry for a peer. It will therefore not surprise him, and won't introduce spurious "!.MISMATCH." in the wild.

Nothing that I'm aware of rejects based on MISMATCH at this time, so would it be so bad to have the behavior on by default as is with Diablo? Might
encourage more operators to properly tweak their configurations.

I can see both sides, but have no opinionated weight to throw in either direction besides the statement above.

I would also suggest a new "pathdiag" parameter, set to true by default,
that can be used at global scope and also per peer, to disable the
feature. Maybe a "pathdomainsocketdiag" parameter would also be useful
to configure the same thing for local Unix domain sockets (they do not
have a peer configuration in incoming.conf).

Any thoughts about that or other suggestions?

Sounds reasonable. If pathdiag is enabled by default and you do not add any pathmatch statements to incoming.conf, is the behavior for path diagnostic/matching basically the same as it is now?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/20/23 3:27 PM, Jesse Rehmer wrote:

After reading Julien's explanation, I believe you want to use
pathcluster on your feeder machine so that the "tnetconsulting.net"
element is the first/left-most element in the path when you pass the
article to a peer.

I'm unconvinced.

On 3/20/23 12:26 PM, Julien ÉLIE wrote:

pathalias
The main purpose of this parameter is to configure all news servers
within a particular organization to add a common identity string to
the Path header field body.

This sounds like what I was intending to do by having peers use tnetconsulting.net in their excludes in their newsfeeds file.

pathcluster
The main purpose of this parameter is to make several news servers
appear as one server.

My two servers are decidedly different and in no way or shape trying to
appear as one (logical) server.

The more reading that I do, the more that I think I want a pathalias set
to tnetconsulting.net.

This makes me think that articles from my servers would be something
like the following:

Path: ...:tncsrv09.home.tnetconsulting.net:tncsrv06.tnetconsulting.net:tnetconsulting.net:...

I would then continue asking peers to exclude :tnetconsulting.net: from
their feeds to me.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mar 20, 2023 at 6:15:17 PM CDT, "Grant Taylor" <gtaylor@tnetconsulting.net> wrote:

On 3/20/23 3:27 PM, Jesse Rehmer wrote:

After reading Julien's explanation, I believe you want to use
pathcluster on your feeder machine so that the "tnetconsulting.net"
element is the first/left-most element in the path when you pass the
article to a peer.

I'm unconvinced.

On 3/20/23 12:26 PM, Julien ÉLIE wrote:

pathalias
The main purpose of this parameter is to configure all news servers
within a particular organization to add a common identity string to
the Path header field body.

This sounds like what I was intending to do by having peers use tnetconsulting.net in their excludes in their newsfeeds file.

pathcluster
The main purpose of this parameter is to make several news servers
appear as one server.

My two servers are decidedly different and in no way or shape trying to appear as one (logical) server.

The more reading that I do, the more that I think I want a pathalias set
to tnetconsulting.net.

This makes me think that articles from my servers would be something
like the following:

Path: ...:tncsrv09.home.tnetconsulting.net:tncsrv06.tnetconsulting.net:tnetconsult ing.net:...

I would then continue asking peers to exclude :tnetconsulting.net: from
their feeds to me.

That is the same MISMATCH I see in your articles today. You want your Path to look like this:

Path: tnetconsulting.net!tncsrv09.home.tnetconsulting.net:tncsrv06.tnetconsulting.n et:...

If tncsrv09.home.tnetconsulting.net is our peering server, that's where you want to set pathcluster.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/20/23 12:26 PM, Julien ÉLIE wrote:

Hi Jesse and Grant,

Hi Julien,

Path: pathcluster!!pathhost!!pathalias!...

For my mental sanity I'm going to find & replace some terms:

pathcluster = logical-cluster
pathhost = physical-host
pathalias = organization

Thus the Path: header would (or could) look like this:

Path: ...:logical-cluster:physical-host:organization:...

I can see value in excluding articles for a logical-cluster in a feed to
any machine in that logical-cluster. But don't necessarily exclude
based on physical-host or even organization. -- There could be cases
where different logical-clusters within the organization would want
articles from other clusters in the organization; e.g. if the
logical-clusters are in geographically diverse locations and don't
interconnect with each other; then logical-cluster1 would (potentially)
want articles from logical-cluster2 made up of different physical-hosts
in the same organization.

From inn.conf documentation:

pathalias
The main purpose of this parameter is to configure all news servers
within a particular organization to add a common identity string to the
Path header field body.

pathcluster
The main purpose of this parameter is to make several news servers
appear as one server.

To me there must be a reason for the difference in pathalias and
pathcluster. If not, why would they exist?

I feel like there is some minutia that is /explicitly/ for the
difference between multiple unrelated news servers in an organization
and multiple interrelated news servers in a cluster.

This way, you tell your peers that they should expect "pathcluster" as
the last and unique name for your outgoing feeds.

I obviously still have doubts.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mar 20, 2023 at 6:28:48 PM CDT, "Jesse Rehmer" <jesse.rehmer@blueworldhosting.com> wrote:

On Mar 20, 2023 at 6:15:17 PM CDT, "Grant Taylor" <gtaylor@tnetconsulting.net>
wrote:

On 3/20/23 3:27 PM, Jesse Rehmer wrote:

After reading Julien's explanation, I believe you want to use
pathcluster on your feeder machine so that the "tnetconsulting.net"
element is the first/left-most element in the path when you pass the
article to a peer.

I'm unconvinced.

On 3/20/23 12:26 PM, Julien ÉLIE wrote:

pathalias
The main purpose of this parameter is to configure all news servers
within a particular organization to add a common identity string to
the Path header field body.

This sounds like what I was intending to do by having peers use
tnetconsulting.net in their excludes in their newsfeeds file.

pathcluster
The main purpose of this parameter is to make several news servers
appear as one server.

My two servers are decidedly different and in no way or shape trying to
appear as one (logical) server.

The more reading that I do, the more that I think I want a pathalias set
to tnetconsulting.net.

This makes me think that articles from my servers would be something
like the following:

Path:
...:tncsrv09.home.tnetconsulting.net:tncsrv06.tnetconsulting.net:tnetconsult >> ing.net:...

I would then continue asking peers to exclude :tnetconsulting.net: from
their feeds to me.

That is the same MISMATCH I see in your articles today. You want your Path to look like this:

Path: tnetconsulting.net!tncsrv09.home.tnetconsulting.net:tncsrv06.tnetconsulting.n et:...

If tncsrv09.home.tnetconsulting.net is our peering server, that's where you want to set pathcluster.

I should have looked at your headers before replying, I see its tncsrv06.tnetconsulting.net that is your peering box. So that's where you want pathcluster set to tnetconsulting.

Your current path from my view:

Path: usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!.MISMATCH.45. 33.28.24!tncsrv06.tnetconsulting.net!tncsrv09.home.tnetconsulting.net!.POSTED .alpha.home.tnetconsulting.net!not-for-mail

What you'd have if you set pathcluster to tnetconsulting.net on tncsrv06.tnetconsulting.net is this:

Path: usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!tnetconsultin g.net!tncsrv06.tnetconsulting.net!tncsrv09.home.tnetconsulting.net!.POSTED.al pha.home.tnetconsulting.net!not-for-mail

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Grant Taylor <gtaylor@tnetconsulting.net> writes:

To me there must be a reason for the difference in pathalias and
pathcluster. If not, why would they exist?

pathalias is when there's some other Path entry that you want to add to
the Path of every article passing through your servers for some reason,
maybe because you used to have some other Path entry and you have peers
that are configured to not send you articles that have already passed
through that entity and you can't get them to update to your current Path
entry for some reason.

pathcluster is the name that you are using to identify yourself to peers
and the Path entry they should expect to see from you, in the cases where
that doesn't match the main Path entry for this box. (The most common
case where that happens is when you have multiple servers that you want to present as a "united front" to the outside world and identify as the same virtual server, but you still want distinct Path entries so those servers
can feed each other.)

Both of these are for somewhat unusual edge cases, so it's hard to explain briefly the circumstances under which you might use them. pathcluster is probably the more common case: you have a mess of internal servers with complicated hostnames and Path entries and whatnot, but you want the
outside world to treat that all as an implementation detail and think of
you as simple, single identity in the Path header. The most common case
for pathalias is when you've changed your Path identity for some reason,
you want that to be your new lead entry, but you have peers hanging on to
an old configuration to determine what articles they send you.

I feel like there is some minutia that is /explicitly/ for the
difference between multiple unrelated news servers in an organization
and multiple interrelated news servers in a cluster.

No, neither of these are for the case of unrelated news servers. If you
have unrelated news servers, just use different Path entries for them and
don't set either pathalias or pathcluster. Both of these settings are
only for *related* servers.

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/20/23 5:33 PM, Jesse Rehmer wrote:

I should have looked at your headers before replying, I see its tncsrv06.tnetconsulting.net that is your peering box.

Correct.

So that's where you want pathcluster set to tnetconsulting.

I believe that I want to set /pathalias/ and have you exclude tnetconsulting.net (the organization).

One of the reasons that I'm stuck on /pathalias/ and /organization/ is
that the server at the name will likely change to something other than tncsrv06... at some point in the future.

My current understanding is that /if/ 1) I set a /pathalias/ "tnetconsulting.net" and 2) you exclude "tnetconsulting.net", then the
hostname of the actual back end server that you're peering doesn't
matter. I can change it as part of upgrading / replacing the system.

N.B. this is predicated on the software & configuration wanting the
exclude and the pathalias / path / pathcluster to match. -- I'm not
aware of any need to match the exclude / path to the hostname that
you're connecting to / accepting connections from.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Grant Taylor <gtaylor@tnetconsulting.net> writes:

I believe that I want to set /pathalias/ and have you exclude tnetconsulting.net (the organization).

This will mean that every message from your server will still be marked as
not matching your true Path identity.

One of the reasons that I'm stuck on /pathalias/ and /organization/ is
that the server at the name will likely change to something other than tncsrv06... at some point in the future.

If you expect the name of the server to change, you want to use
pathcluster, *not* pathalias. pathalias puts the common name in the wrong place for Path verification and will then require your peers to update the expected Path entry when the name of the server changes.

My current understanding is that /if/ 1) I set a /pathalias/ "tnetconsulting.net" and 2) you exclude "tnetconsulting.net", then the hostname of the actual back end server that you're peering doesn't
matter.

This is correct for deciding what messages to send you (in that case, both pathalias and pathcluster are equivalent), but *not* for Path
verification.

N.B. this is predicated on the software & configuration wanting the
exclude and the pathalias / path / pathcluster to match. -- I'm not
aware of any need to match the exclude / path to the hostname that
you're connecting to / accepting connections from.

Indeed, they do not need to match, that's just the default behavior. For example, I never configure my news servers that way. I always use
newsfeeds entries like:

example/news.example.org:*:Ap,Tm:innfeed!

(very simplified) so that I have explicit control over what Path entry to exclude from the feed and have shorter peer names in logs, disk files,
etc.

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/20/23 7:25 PM, Russ Allbery wrote:

This is correct for deciding what messages to send you (in that case, both pathalias and pathcluster are equivalent), but*not* for Path
verification.

Okay....

Where can I find out more about how path verification is supposed to
function.

It is becoming evident that I'm thinking about things incorrectly and I
need to read more documentation.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/20/23 6:56 PM, Russ Allbery wrote:

No, neither of these are for the case of unrelated news servers.
If you have unrelated news servers, just use different Path entries
for them and don't set either pathalias or pathcluster. Both of
these settings are only for*related* servers.

Based on this, it seems as if the exclude should reflect the name that
the server uses. If that ever changes, update peers to use the new
name. Or, cause INN (et al.) to continue using the old name.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mar 20, 2023 at 9:35:41 PM CDT, "Jesse Rehmer" <jesse.rehmer@blueworldhosting.com> wrote:

On Mar 20, 2023 at 9:22:47 PM CDT, "Grant Taylor" <gtaylor@tnetconsulting.net>
wrote:

On 3/20/23 7:25 PM, Russ Allbery wrote:

This is correct for deciding what messages to send you (in that case, both >>> pathalias and pathcluster are equivalent), but*not* for Path
verification.

Okay....

Where can I find out more about how path verification is supposed to
function.

It is becoming evident that I'm thinking about things incorrectly and I
need to read more documentation.

The easiest way to think about it is this (for me at least):

You are telling peers that your site's Path is "tnetconsulting.net". When my server receives an article from yours the first element in the Path: header my
server expects to see to validate a match is exactly tnetconsulting.net. If it
contains any other value, such as your FQDNs as the first element, it is considered a mismatch, no matter if this element appears later in the Path.

You want to make sure the last Path element your news server adds when sending
to other peers is what you've told those peers to expect. It's common to use a
generic name for the Path header (like I do with usenet.blueworldhostig.com), but have the actual feeder or other server names by more unique. Those more unique names don't validate for Path matching if they appear before tnetconsulting.net.

Forgot to mention, it may help to look at what headers look like originating from your server from another server's perspective. There are a number of ways to do this, but an easy one is to post an article to alt.test with some valid e-mail address as the sender, and the news.nobody.at reflector will e-mail you confirmation containing headers from your article.

For validation matching you want to see the ordering of elements like the example below where your advertised Path name your peers are looking for is
the left most element before the peer who accepted the article from you.

Path: some-receiving-peer!tnetconsulting.net!tncsrv06.tnetconsulting.net!tncsrv09.h ome.tnetconsulting.net!.POSTED.al
pha.home.tnetconsulting.net!not-for-mail"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mar 20, 2023 at 9:22:47 PM CDT, "Grant Taylor" <gtaylor@tnetconsulting.net> wrote:

On 3/20/23 7:25 PM, Russ Allbery wrote:

This is correct for deciding what messages to send you (in that case, both >> pathalias and pathcluster are equivalent), but*not* for Path
verification.

Okay....

Where can I find out more about how path verification is supposed to function.

It is becoming evident that I'm thinking about things incorrectly and I
need to read more documentation.

The easiest way to think about it is this (for me at least):

You are telling peers that your site's Path is "tnetconsulting.net". When my server receives an article from yours the first element in the Path: header my server expects to see to validate a match is exactly tnetconsulting.net. If it contains any other value, such as your FQDNs as the first element, it is considered a mismatch, no matter if this element appears later in the Path.

You want to make sure the last Path element your news server adds when sending to other peers is what you've told those peers to expect. It's common to use a generic name for the Path header (like I do with usenet.blueworldhostig.com), but have the actual feeder or other server names by more unique. Those more unique names don't validate for Path matching if they appear before tnetconsulting.net.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mar 20, 2023 at 9:43:51 PM CDT, "Jesse Rehmer" <jesse.rehmer@blueworldhosting.com> wrote:

On Mar 20, 2023 at 9:35:41 PM CDT, "Jesse Rehmer" <jesse.rehmer@blueworldhosting.com> wrote:

On Mar 20, 2023 at 9:22:47 PM CDT, "Grant Taylor" <gtaylor@tnetconsulting.net>
wrote:

On 3/20/23 7:25 PM, Russ Allbery wrote:

This is correct for deciding what messages to send you (in that case, both >>>> pathalias and pathcluster are equivalent), but*not* for Path
verification.

Okay....

Where can I find out more about how path verification is supposed to
function.

It is becoming evident that I'm thinking about things incorrectly and I
need to read more documentation.

The easiest way to think about it is this (for me at least):

You are telling peers that your site's Path is "tnetconsulting.net". When my >> server receives an article from yours the first element in the Path: header my
server expects to see to validate a match is exactly tnetconsulting.net. If it
contains any other value, such as your FQDNs as the first element, it is
considered a mismatch, no matter if this element appears later in the Path. >>
You want to make sure the last Path element your news server adds when sending
to other peers is what you've told those peers to expect. It's common to use a
generic name for the Path header (like I do with usenet.blueworldhostig.com),
but have the actual feeder or other server names by more unique. Those more >> unique names don't validate for Path matching if they appear before
tnetconsulting.net.

Forgot to mention, it may help to look at what headers look like originating from your server from another server's perspective. There are a number of ways
to do this, but an easy one is to post an article to alt.test with some valid e-mail address as the sender, and the news.nobody.at reflector will e-mail you
confirmation containing headers from your article.

For validation matching you want to see the ordering of elements like the example below where your advertised Path name your peers are looking for is the left most element before the peer who accepted the article from you.

Path: some-receiving-peer!tnetconsulting.net!tncsrv06.tnetconsulting.net!tncsrv09.h ome.tnetconsulting.net!.POSTED.al
pha.home.tnetconsulting.net!not-for-mail"

It may also help you to explain it this way, on tncsrv09.home.tnetconsulting.net, if you set pathalias to tnetconsulting.net your path to me as your infrastructure is now would look like this (not a
valid match):

Path: tncsrv06.tnetconsulting.net!tncsrv09.home.tnetconsulting.net!tnetconsulting.n et!.POSTED.alpha.home.tnetconsulting.net!not-for-mail

If on the same machine you set pathcluster to the same value it would look
like this (not a valid match):

Path: tncsrv06.tnetconsulting.net!tnetconsulting.net!tncsrv09.home.tnetconsulting.n et!.POSTED.alpha.home.tnetconsulting.net!not-for-mail

If on tncsrv06.tnetconsulting.net you set pathalias to tnetconsulting.net it would look like this (not a valid match):

Path: tncsrv06.tnetconsulting.net!tnetconsulting.net!tncsrv09.home.tnetconsulting.n et!.POSTED.alpha.home.tnetconsulting.net!not-for-mail

If on tncsrv06.tnetconsulting.net you set pathcluster to tnetconsulting.net it would look like this (valid match):

Path: tnetconsulting.net!tncsrv06.tnetconsulting.net!tncsrv09.home.tnetconsulting.n et!.POSTED.alpha.home.tnetconsulting.net!not-for-mail

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/20/23 8:35 PM, Jesse Rehmer wrote:

You are telling peers that your site's Path is
"tnetconsulting.net". When my server receives an article from yours the
first element in the Path: header my server expects to see to validate
a match is exactly tnetconsulting.net. If it contains any other value,
such as your FQDNs as the first element, it is considered a mismatch,
no matter if this element appears later in the Path.

Thank you for explaining Jesse. That's what I was expecting.

As I type this, I'm wondering if this is an issue of what "first"
actually means. Or rather if the inversion of the naturally intuitive placement is causing part of this problem.

To me, the /chronologically/ first path entry is the /right/ /most/ path
entry.

Would it be fair / accurate to re-word your statement as follows:

You are telling peers that your site's Path is
"tnetconsulting.net". When my server receives an article from yours
the *chronologically* *newest* or *left* *most* element in the Path:
header my server expects to see to validate a match is exactly tnetconsulting.net. If it contains any other value, such as your
FQDNs as the *chronologically* *newest* or *left* *most* element, it
is considered a mismatch, no matter if this element appears later in
the Path.

If you can't tell by now, I've been interpreting /first/ as
/chronologically/ /oldest/ or /right/ /most/ Path element (in question).

My understanding of the inn.conf man page seems to corroborate my interpretation of newest / oldest / append / prepend.

--8<--
Note that the Path: header reads right to left, so appended means
inserted at the leftmost side of the Path: header.

8--

--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/20/23 8:43 PM, Jesse Rehmer wrote:

For validation matching you want to see the ordering of elements
like the example below where your advertised Path name your peers
are looking for is the left most element before the peer who accepted
the article from you.

I think this is coming down to a discrepancy between "left most" and
"first".

left most = newest = last
right most = oldest = first

On 3/20/23 8:35 PM, Jesse Rehmer wrote:

When my server receives an article from yours the first element in
the Path: header my server expects to see to validate a match is
exactly tnetconsulting.net.

;-)

Combine this with the following excerpts from the inn.conf man page.

--8<--
pathalias - If set, this value is prepended to the Path: header of
accepted posts (before pathhost) if it doesn't already appear in the
Path: header.

pathcluster - If set, this value is appended to the Path: header of
accepted posts (after pathhost) if it isn't already present as the last
element of the Path: header.

8--

So ... with statements saying "first" that made me think chronologically
oldest / right most thus pathalias. When it now seems that "first"
really should have been chronologically newest / left most thus pathcluster.

Nomenclature can be hard. I learned a LONG time ago that frequently, if
not often, when people are disagreeing about something, there's a fairly
good chance that they are using different meanings / definitions for
things, which alters the logic. :-D



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Grant,

I think this is coming down to a discrepancy between "left most" and
"first".

Combine this with the following excerpts from the inn.conf man page.

--8<--
pathalias - If set, this value is prepended to the Path: header of
accepted posts (before pathhost) if it doesn't already appear in the
Path: header.

pathcluster -  If set, this value is appended to the Path: header of accepted posts (after pathhost) if it isn't already present as the last element of the Path: header.

8--

That's a pretty good point.
I suggest the following improvement in how all that stuff is documented
in inn.conf. (Thanks, Russ, for your great wording I reused.)


*pathhost*
What to put into the Path header field to represent the local site.
This path identity is added to the Path header field body of all
articles that pass through the system, including locally posted
articles, and is also used when processing some control messages and
when naming the server in status reports. There is no default
value; this parameter must be set in inn.conf or INN will not start.
A good value to use is the fully qualified hostname of the system.

The main purpose of the path identity is to avoid being proposed by
your peers articles that already contain your path identity in their
Path header fields.

In case you are running several internal news servers, you may want
to also set *pathcluster* so as to define the primary path identity
to advertise to your peers for their use in correctly identifying
your news servers and adding the right path diagnostic (see
Section 3.2.1 of RFC 5537 for more details about path diagnostics).


*pathalias*
If set, this value is prepended to the Path header field body of
accepted articles (just before *pathhost*, at its right) if it
doesn't already appear in the Path header field. The default value
is unset.

The main purpose of this parameter is when there is some other path
identity that you want to add to the Path header field of every
article passing through your news server(s) for some reason, maybe
because you used to have some other path identity and you have peers
that are configured to not send you articles that have already
passed through that entity, and you can't get them to update to your
current path identity for some reason.


*pathcluster*
If set, this value is appended to the Path header field body of
accepted articles (just after *pathhost*, at its left) if it isn't
already present as the leftmost element of the Path header field
body. The default value is unset.

The main purpose of this parameter is to set the name that you are
using to identify yourself to peers (i.e. the path identity they
should expect to see from you) in the cases where that doesn't match
the main path identity *pathhost* for this news server. (The most
common case where that happens is when you have multiple news
servers that you want to present as a "united front" to the outside
world and identify as the same virtual server, but you still want
distinct path identities so those servers can internally feed each
other.)


--
Julien ÉLIE

« Plus un ordinateur possède de RAM, plus vite il peut générer un
message d'erreur. »

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Jesse,

Meanwhile, if you have any suggestions, here is what I had in mind.
A new "pathmatch" parameter in incoming.conf expects a wildmat pattern
and has no default value.
If the leftmost path identity of an incoming article from a peer matches
the pattern value of that parameter (in incoming.conf) when set or, when
unset, equals the label of the peer, then a double "!!" will be
prepended to the Path header field to show it has been successfully
verified.
If the leftmost path identity does not match the pattern, when set,
"!.MISMATCH." is prepended along with the peer IP, and a notice log is
written to say there's a path mismatch (the log is written only once
*per connection* from the peer, and will be reported in Usenet daily
reports as unknown lines near the beginning of the report).

This is more or less equivalent to the behavior of Diablo's "alias" parameter in dnewsfeeds that accepts wildmat patterns, though it doesn't implement the verified !! portion.

In all other cases, "!.SEEN." with the peer IP is added, without any
notice log.

Can you explain further what "other cases" this would be applicable to?

It would happen when there is neither "!!" nor "!.MISMATCH." as set by
the above suggested rules. INN couldn't check the path identity because
the pathmatch parameter was not set.

It's the third part of the following excerpt from RFC 5537:

A relaying or serving agent SHOULD prepend a <path-diagnostic> to
the Path header field content, where the <path-diagnostic> is
chosen as follows:

* If the expected <path-identity> of the source of the article
matches the leftmost <path-identity> of the Path header
field's content, use "!" (<diag-match>), resulting in two
consecutive "!"s.

* If the expected <path-identity> of the source of the article
does not match, use "!.MISMATCH." followed by the expected
<path-identity> of the source or its IP address.

* If the relaying or serving agent is not willing or able to
check the <path-identity>, use "!.SEEN." followed by the FQDN,
IP address, or expected <path-identity> of the source.

There's a special case to deal with: articles coming from a local Unix
domain socket (like connections to innd by rnews or nnrpd). I would
suggest "!.SEEN.localhost" for them (except of course when the path
identity corresponds to nnrpd's "!.POSTED", in which case we do not add
a path diagnostic).
I don't think "!!" or "!.MISMATCH." is suitable for these articles as
the path identity may be different than the real one of the remote peer,
and I do not see any way to ensure that (when processing rnews batches
coming from an external source, UUCP, etc. we no longer know the source).

I'd have to really think more about this, but can see where this might get a little ugly.

I understand "!.SEEN.localhost" may look ugly for each post from rnews.

When pulling news with pullnews, and transferring them to your server,
you will also probably want to deactivate path diagnostic for the
incoming.conf entry matching the pullnews connection, or set pathmatch
to "*"; otherwise you'll get bunches of "!.MISMATCH."...

This proposal permits not generating a "!.MISMATCH." if the admin does
not set an explicit "pathmatch" entry for a peer. It will therefore not
surprise him, and won't introduce spurious "!.MISMATCH." in the wild.

Nothing that I'm aware of rejects based on MISMATCH at this time, so would it be so bad to have the behavior on by default as is with Diablo? Might encourage more operators to properly tweak their configurations.

Yes, it might encourage a better tweak of configuration of incoming.conf (notably for the news admins who use pullnews, rnews, UUCP...).

Nonetheless, nobody has ever required that the label of the peer entry corresponds to the expected path identity, the hostname pattern neither.
I may have:

peer jesse {
hostname: "news-out.remote-server.net"
}

whereas the path identity is just "remote-server.net".

Why would a "!.MISMATCH." occur?
Why would we force news admins to configure path verification?

That's why I am unsure we should enforce path verification by default,
unless an explicit pathmatch parameter is used:

peer jesse {
hostname: "news-out.remote-server.net"
pathmatch: "remote-server.net"
}

or the peer label is the leftmost path identity (in which case "!!" will
be used):

peer remote-server.net {
hostname: "news-out.remote-server.net"
}

I would also suggest a new "pathdiag" parameter, set to true by default,
that can be used at global scope and also per peer, to disable the
feature. Maybe a "pathdomainsocketdiag" parameter would also be useful
to configure the same thing for local Unix domain sockets (they do not
have a peer configuration in incoming.conf).

Sounds reasonable. If pathdiag is enabled by default and you do not add any pathmatch statements to incoming.conf, is the behavior for path diagnostic/matching basically the same as it is now?

There wouldn't be any change if we do *not* add "!.SEEN." in these
cases. The suggestion here is to add it.

In summary:

When there is a pathmatch parameter, we can either use "!!" or
"!.MISMATCH.". When this parameter is not set, we can either use "!!" (matching the peer label or the hostname pattern) or "!.SEEN.".

If pathdiag is explicitly set with value "true", we add "!!",
"!.MISMATCH." or "!.SEEN." depending on how pathmatch is set.

If pathdiag is explicitly set with value "false", we don't add anything.

If pathdiag is not set, we add "!!" when possible... and nothing
otherwise. Note that it does not strictly comply with the SHOULD of RFC
5537 (a path diagnostic SHOULD always be added).

But in case it surprises news admins on upgrade, maybe INN 2.7.2 should
have pathdiag unset by default; and we set it to true by default only
for INN 2.8.0? (I probably once suggested that, and it is why you have
INN 2.8.0 in mind for path verification!)

--
Julien ÉLIE

« Ce sont vos uniones, pas les miens ! » (Astérix)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/21/23 4:06 PM, Julien ÉLIE wrote:

Hi Grant,

Hi Julien,

That's a pretty good point.

:-)

I suggest the following improvement in how all that stuff is documented
in inn.conf.  (Thanks, Russ, for your great wording I reused.)

This all looks good to me. I think, other than my comment below, any suggestions would be nitpicking / bikesheding.

I do wonder if there might be some value in making a comparison to "pathcluster" possibly being an organization name if the organization
has multiple news servers.

I do believe that if I head read the new verbiage, either before, or
definitely after, Jessee's nudge, I would have chosen to add a
pathcluster, while wondering about it's name.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-03-21, Julien ÉLIE <iulius@nom-de-mon-site.com.invalid> wrote:

*pathalias*
If set, this value is prepended to the Path header field body of
accepted articles (just before *pathhost*, at its right) if it

As it's the use of "before" and "after" that cause so much confusion
when dealing with the Path header - and which means append or prepend -
I'd suggest rewording the parenthesised part to "immediately to the
right of pathhost", or similar. The current wording still allows room
for ambiguity as to which element, "pathhost" or "pathalias", is
rightmost.

*pathcluster*
If set, this value is appended to the Path header field body of
accepted articles (just after *pathhost*, at its left) if it isn't

Likewise here - perhaps "immediately to the left of pathhost". Maybe
"directly" or some other synonym instead of "immediately"...

Cheers,
Tom

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Grant and Tom,

*pathalias*
If set, this value is prepended to the Path header field body of
accepted articles (just before *pathhost*, at its right) if it

*pathcluster* >> If set, this value is appended to the Path header field body of
accepted articles (just after *pathhost*, at its left) if it >

As it's the use of "before" and "after" that cause so much confusion
when dealing with the Path header - and which means append or prepend -
I'd suggest rewording the parenthesised part to "immediately to the
right of pathhost", or similar. The current wording still allows room
for ambiguity as to which element, "pathhost" or "pathalias", is
rightmost.

OK, I see.
I've rewritten the sentences this way:

If set, this value is prepended as a path identity immediately to the
right of *pathhost* in the Path header field body of accepted articles
if it doesn't already appear in the Path header field.

If set, this value is appended as a path identity immediately to the
left of *pathhost* in the Path header field body of accepted articles
if it isn't already present as the leftmost element of the Path header
field body.

It seems clearer, especially the append part to the Path header field,
as one may think it was at the end of the whole field.


Grant's suggestion added:

The most common case where that happens is when you have multiple news
servers that you want to present as a "united front" to the outside
world and identify as the same virtual server, but you still want
distinct path identities so those servers can internally feed each
other. Also, even without internal feeds, I<pathcluster> could be set
to an organization name if the organization has multiple news servers.

--
Julien ÉLIE

« Tous les champignons sont comestibles. Certains, une fois seulement. »

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/22/23 1:24 AM, Julien ÉLIE wrote:

Hi Grant and Tom,

Hi Julien,

Thumbs up all around.

I think it's my turn to buy some people some drinks.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)