Updating Path header fields with path diagnostics
Julien ÉLIE
julien at trigofacile.com
Sat Jan 21 18:20:17 UTC 2023
Hi all,
I'm having a look at implementing path diagnostics "!", "!.MISMATCH."
and "!.SEEN." in innd.
(For those who do not know, they are described in Section 3.2 of RFC 5537.)
Ticket #33 contains a patch against INN 2.2 which needs rewriting and
discussing.
It adds a "pathmatch" parameter in incoming.conf, expecting a wildmat
pattern and defaulting to the label of the peer. If the first path
identity of an incoming article from a peer matches the pattern value of
that parameter, then a double "!!" will be prepended to the Path header
field to show it has been successfully verified.
If the first path identity does not match the pattern, "!.MISMATCH." is
prepended along with the peer IP (from inet_ntoa), and a notice log is
written to say there's a path mismatch (the log is written only once per
connection from the peer).
"!!" for articles coming from a Unix domain socket.
"!.SEEN." with the peer IP for all other cases, without any notice log.
I would propose:
- no default value for "pathmatch";
- "!!" if the first path identity matches "pathmatch" when set, or if
unset, equals the label of the peer;
- "!.MISMATCH." with the peer IP if the first path identity does not
match "pathmatch" when set, and a notice log once per connection;
- "!.SEEN.localhost" for articles coming from a Unix domain socket
(except of course when the path identity corresponds to nnrpd's
"!.POSTED" - we do not add a path diagnostic in that case);
- "!.SEEN." with the peer IP for all other cases, without any notice log.
This proposal permits not generating a "!.MISMATCH." if the admin does
not set an explicit "pathmatch" entry for a peer. Otherwise, if the
path identity is not the label, a mismatch will automatically occur.
I'm also unsure we should prepend "!!" to all the articles received from
a Unix domain socket (like posts through rnews). The path identity may
be different than the one of the remote peer. That's why I suggest
"!.SEEN.localhost".
Any thoughts about that, or other suggestions?
Does it sound good to you to unconditionally update the Path header
field this way? (It is a SHOULD in RFC 5537.)
Or should we provide a way to disable it globally, per peer and also for
local sockets in incoming.conf?
--
Julien ÉLIE
« Quand on demande aux gens d'observer le silence, au lieu de l'observer
comme on observe une éclipse de lune, ils l'écoutent ! » (Raymond
Devos)
More information about the inn-workers
mailing list