Hi Russ,

> one common
> reason to insert other people's Path identities in your Path header is
> because the Path is used by most servers to deduplicate feeds, so they
> won't send an article to a server whose path identity already appears in
> the Path. Therefore, a long-standing tactic for preventing your post from
> showing up at some server (for whatever reason) is to add its path
> identity to your Path header before posting, or during posting.
[...]
> maybe mixmin.net and aioe.org have a special peering relationship and
> mixmin.net preloads the aioe.org path entry to prevent the messages from
> propagating via normal channels because they'll be sent via some other
> channel that's configured to ignore Path entries. I have done things like
> that before to solve complex peering configuration issues.

I hope such insertions and preloads are done before adding the path
identity of the news server which actually handles the message.
That is to say, if my.news.server.net inserts preload.net in the Path
header field, and has verified the last entry of the received path is
the expected one, it would be this way:

Path: my.news.server.net!preload.net!!previous.path

By the way, is it wise to add a verified diag match here?
(my.news.server.net!!preload.net) I am unsure, as the article did not
pass through preload.net, and such a syntax would imply that
my.server.net verified it came from preload.net.
Yet, I also wonder if "preload.net!!previous.path" is OK as preload.net
didn't verify previous.path (it was actually verified by
my.news.server.net).

So, maybe there shouldn't be any diagnostic added when preloading at the
right side?

Path: my.news.server.net!preload.net!previous.path

The rationale for preload.net added first is that it would otherwise
mean that the next peer would know that the path identity of
my.news.server.net could be preload.net, so that it does not do
something like:

Path:
next.server.com!.MISMATCH.my.news.server.net!preload.net!my.news.server.net!previous.path

Coming back to how INN deals with additional path identities, we have 2
parameters (pathcluster and pathalias) which preload like:

Path: pathcluster!my.news.server!pathalias!previous.path

Would path diagnostic only be activated between pathcluster and
my.news.server, and never around pathalias?

Path: pathcluster!!my.news.server!pathalias!previous.path

It would imply that when pathalias is set, no verification of the path
identity of the feeding peer is done. (Or maybe a special pathaliasdiag
configuration option should be added to incoming.conf to enable it
anyway? - default would be disabled)

pathalias could indeed have 2 different uses: an internal name (and in
that case, path diag would be OK) or the name of another server (and in
that case, I am not sure path diag is OK to be added here)

--
Julien ÉLIE

« La fin du monde est un sujet sérieux, surtout pour ceux qui s'y
préparent. » (Filiu)