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

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.

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"

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

Grant Taylor <gtaylor@tnetconsulting.net> writes:

> 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.

Exactly. pathcluster is a mechanism for doing the latter, when you may be
changing actual servers under the hood but don't want to keep telling
peers to change things or exclude multiple different Path entries because
you may feed them from one server one day and a different server the next
day.

--
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.

Grant Taylor <gtaylor@tnetconsulting.net> writes:
> 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.

https://www.rfc-editor.org/rfc/rfc5537.html#section-3.2.1 although I'm not
sure if that's what you're looking for.

--
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.

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

On Mar 20, 2023 at 10:13:50 PM CDT, "Grant Taylor"
<gtaylor@tnetconsulting.net> wrote:

> 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--

For Path validation it reads left to right, but only validates against the
first element.

On Mar 20, 2023 at 10:16:53 PM CDT, "Jesse Rehmer"
<jesse.rehmer@blueworldhosting.com> wrote:

> On Mar 20, 2023 at 10:13:50 PM CDT, "Grant Taylor"
> <gtaylor@tnetconsulting.net> wrote:
>
>> 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--
>
> For Path validation it reads left to right, but only validates against the
> first element.

More precisely, Path matching from the server perspective is left to right,
and validation only occurs against the first element.

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

On Mar 20, 2023 at 10:21:42 PM CDT, "Grant Taylor"
<gtaylor@tnetconsulting.net> wrote:

> 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

Yeah... so I always read paths left to right, but understand where you are
coming from, but I always ignored that because I'm always considering the Path
from my server to the sending peer and beyond and not the other way around,
which is how most formal documentation refers to adding to/reading the Path
header.

Sorry about that. :-)

When you think about how the server is going to validate it is the left-most
element (which to me is the first, because it is the first one the server
examines). I guess I think too much like a server. (and I've done way to much
NNTP and IPv6 for one day today)

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. »

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

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)

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

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. »

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