Updating Path header fields with path diagnostics

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)
-- 
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers