Hi,
What is the parameter to allow user to customize right part of
the message-id field when posting a message ?
It appears that LaLibreParole <vrai.ou.faux@laposte.net> said:
Hi,
What is the parameter to allow user to customize right part of
the message-id field when posting a message ?
If you post a message that already has a Message-ID, inn won't change
it.
It'll add a Message-ID in the usual case that there isn't one.
And in this case, inn will use something_uniq@machinename.domain
Is it possible to suppress "machinename" ?
LaLibreParole <vrai.ou.faux@laposte.net> writes:
And in this case, inn will use something_uniq@machinename.domain
Is it possible to suppress "machinename" ?
Set domain in the readers.conf access stanza to whatever you want to use
on the right-hand side of message IDs.
And in this case, inn will use something_uniq@machinename.domain
Is it possible to suppress "machinename" ?
Set domain in the readers.conf access stanza to whatever you want to use
on the right-hand side of message IDs.
I didn't succeed: it also adds the name of the server machine.
Do you happen to also have the domain parameter set in inn.conf to the
same value as the one you added to readers.conf?
yes.
(If that's the case, I think it won't be taken into account.
You're right !
the solution: put two different values: one in inn.conf
and a different one in readers.conf.
Bonsoir LaLibreParole,
And in this case, inn will use something_uniq@machinename.domain
Is it possible to suppress "machinename" ?
Set domain in the readers.conf access stanza to whatever you want to use >>> on the right-hand side of message IDs.
I didn't succeed: it also adds the name of the server machine.
Do you happen to also have the domain parameter set in inn.conf to the
same value as the one you added to readers.conf?
(If that's the case, I think it won't be taken into account.
Try to unset the domain parameter in inn.conf, and only
keep the one in readers.conf.)
Bonsoir LaLibreParole,
Do you happen to also have the domain parameter set in inn.conf to the
same value as the one you added to readers.conf?
yes.
(If that's the case, I think it won't be taken into account.
You're right !
the solution: put two different values: one in inn.conf
and a different one in readers.conf.
I don't know why we do that comparison when generating Message-IDs. If >domain is set in both inn.conf and readers.conf to the same value, we
take the FQDN. If domain is not set in inn.conf but is set in
readers.conf, or both are set and different, we take the one in
readers.conf.
I would tend to take the one from readers.conf anyway. As it is forced
in readers.conf, there may be a reason; inn.conf documentation says to
have a look at domain (or virtualhost) in readers.conf to change the >righthand side of autogenerated Message-IDs, but that special rule is
not mentioned. I would just drop it...
I don't know why we do that comparison when generating Message-IDs. If domain is set in both inn.conf and readers.conf to the same value, we
take the FQDN. If domain is not set in inn.conf but is set in
readers.conf, or both are set and different, we take the one in
readers.conf.
I would tend to take the one from readers.conf anyway. As it is forced
in readers.conf, there may be a reason; inn.conf documentation says to
have a look at domain (or virtualhost) in readers.conf to change the righthand side of autogenerated Message-IDs, but that special rule is
not mentioned. I would just drop it...
* Document domain as a first-class configuration parameter for access
groups in readers.conf, saying that it changes the way message IDs are
constructed. (I'm not sure if it does anything else?)
If "virtualhost" is not present it only modify the path in injection info. For example:
With virtualhost: "injection-Info: machinename.readersconfDomain"
Without virtualhost: "injection-Info: machinename.InnConfDomain"
it's a pity that we can't delete the name of the machine at this place
Hi,
Russ Allbery a écrit :
* Document domain as a first-class configuration parameter for access
groups in readers.conf, saying that it changes the way message IDs are
constructed. (I'm not sure if it does anything else?)
Changing it, add the domain value to the Path for messages added by nnrpd
and when getting messages with a client of nnrpd.
* Document domain as a first-class configuration parameter for access
groups in readers.conf, saying that it changes the way message IDs are
constructed. (I'm not sure if it does anything else?)
Changing it, add the domain value to the Path for messages added by nnrpd
and when getting messages with a client of nnrpd.
Hi,
Russ Allbery a écrit :
* Document domain as a first-class configuration parameter for access
groups in readers.conf, saying that it changes the way message IDs are
constructed. (I'm not sure if it does anything else?)
Changing it, add the domain value to the Path for messages added by nnrpd
and when getting messages with a client of nnrpd.
I would tend to take the one from readers.conf anyway. As it is forced
in readers.conf, there may be a reason; inn.conf documentation says to
have a look at domain (or virtualhost) in readers.conf to change the
righthand side of autogenerated Message-IDs, but that special rule is
not mentioned. I would just drop it...
BTW, I had a bit of a hard time following the documentation, because
inn.conf says to set domain in readers.conf but then domain isn't
documented in readers.conf except in the list of inn.conf settings that
can also be set there.
If the inn.conf documentation is correct, the domain setting is ignored if inn_getfqdn() succeeds, which also seems a bit weird. It feels like an expicitly-set configuration option should override whatever we discover
while probing around on the system.
I think the right result may be:
* Use domain unconditionally for forming message IDs if it's set in
readers.conf.
* Use domain if it's set in inn.conf, regardless of what we can discover
from other system calls. (This is backwards-incompatible, so maybe not
on the stable branch.)
I found all of this surprisingly confusing! I'm sure it all made sense to
me at some point fifteen years ago.
There is the "domain" keyword in inn.conf to set the domain name if (and
only if) gethost*name(3) fail. This does not work for me.
I tried the same. I think this should be taken as default if domain isn't defined in readers.conf.
If "virtualhost" is not present it only modify the path in injectionIt's also a behaviour, dating back to the obsolete X-Trace header field,
info. > For example:
With virtualhost: "injection-Info: machinename.readersconfDomain"
Without virtualhost: "injection-Info: machinename.InnConfDomain"
it's a pity that we can't delete the name of the machine at this
place
No: only if "virtualhost" is also set to true in reader.conf.
Digging in the archives, I found out this message:
https://lists.isc.org/mailman/htdig/inn-workers/1999-September/000423.html
"""
Suppose you've got a news farm of twenty-odd
machines hiding behind news.example.com. You probably want just news.example.com in e-mail addresses, but if you use that for message ID generation as well, doesn't that then run a non-trivial risk of duplicate message IDs?
The reason to use the FQDN is so that you can be fairly sure no other
system is generating message IDs in the same namespace....
"""
Besides, it could be worthwhile adding a check that the domain parameter (inn.conf or readers.conf) contains valid characters for a Message-ID...
and fall back to FQDN otherwise (hoping that FQDN also returns a string suitable for a Message-ID!).
I also found out:
https://lists.isc.org/mailman/htdig/inn-workers/2002-August/010116.html
"""
There is the "domain" keyword in inn.conf to set the domain name if (and >>> only if) gethost*name(3) fail. This does not work for me.
I tried the same. I think this should be taken as default if domain isn't
defined in readers.conf.
The reason why we didn't do that a while back is because that's not what domain was meant to be. domain was the *domain* name (to which the host
name should be prepended) and is there as a settable parameter because of sites with old or broken DNS.
domain in readers.conf is something different. :/
I suppose we could decide that there aren't any hosts around any more that are so old that INN can't figure out the right domain name (although I'm
not sure this is true for some weird local configurations) and that domain could be recycled to set the local host name. Although if we're going to
do that, I'd rather just remove the domain parameter and add a new one.
Like, say, hostname. :)
"""
When all of this has been stated, there will also be a change to make in
the FAQ:
https://www.eyrie.org/~eagle/faqs/inn.html#S6.6
Hi,
LaLibreParole a tapoté le 20/09/2022 10:03:
No: only if "virtualhost" is also set to true in reader.conf.
Without virtualhost I haven't succeeded in configuring it...
Now I'm not using it. It may be broken in 2.6.4?
INN's mesage ID generation algorithm is not great and we
could indeed get duplicates if multiple hosts are using the same
right-hand side.
Besides, it could be worthwhile adding a check that the domain parameter
(inn.conf or readers.conf) contains valid characters for a Message-ID...
and fall back to FQDN otherwise (hoping that FQDN also returns a string
suitable for a Message-ID!).
I think if domain has invalid characters we should probably just abort
with a fatal error, assuming it's worth checking for this. That seems
like a basic configuration error we should just make people fix.
I think the tactical fix to honor domain in readers.conf regardless of
what domain in inn.conf is set to is the right fix for stable.
What I'm coming around to for the next major release is that the parameter
in readers.conf should just be called something different, since it is something different, and we should remove the domain setting in
readers.conf (since it doesn't make sense to change the DNS resolution
stuff in readers.conf since that will be a global problem, not just an
nnrpd problem) and have innupgrade change it to some other name. >
The ABNF construct that's used in the standards for Xref is server-name. That's not a bad name for this setting; maybe the new readers.conf setting should be servername?
Which normally you would want to set to the same
thing as pathhost in inn.conf, but they're distinct settings since there
are cases where you may want them to be different.
Hi Russ,
INN's mesage ID generation algorithm is not great and we
could indeed get duplicates if multiple hosts are using the same
right-hand side.
Do you think we should improve the generation of Message-IDs?
They're currently based on the date, PID and a counter incrementing at
each call. A quick improvement could be to also add for instance 6
bytes from RAND_bytes() if OpenSSL support is available (which is most
often the case I believe).
Besides, it could be worthwhile adding a check that the domain parameter >>> (inn.conf or readers.conf) contains valid characters for a Message-ID... >>> and fall back to FQDN otherwise (hoping that FQDN also returns a string
suitable for a Message-ID!).
I think if domain has invalid characters we should probably just abort
with a fatal error, assuming it's worth checking for this. That seems
like a basic configuration error we should just make people fix.
Yes, people should fix such a misconfiguration.
I think the tactical fix to honor domain in readers.conf regardless of
what domain in inn.conf is set to is the right fix for stable.
I also agree; I'll do that.
What I'm coming around to for the next major release is that the parameter >> in readers.conf should just be called something different, since it is
something different, and we should remove the domain setting in
readers.conf (since it doesn't make sense to change the DNS resolution
stuff in readers.conf since that will be a global problem, not just an
nnrpd problem) and have innupgrade change it to some other name. >
The ABNF construct that's used in the standards for Xref is server-name.
That's not a bad name for this setting; maybe the new readers.conf setting >> should be servername?
Yes, servername looks like an appropriate name. It will be a useful >improvement for the next major release.
I propose to also have a servername parameter in inn.conf as inews
generates Message-IDs (and currently uses the value of the domain
parameter in inn.conf).
And the value of servername can be overriden in readers.conf.
Which normally you would want to set to the same
thing as pathhost in inn.conf, but they're distinct settings since there
are cases where you may want them to be different.
The default value of servername in inn.conf (optional parameter) would
then be pathhost (mandatory to set in inn.conf).
A quick improvement could be to also add for instance 6
bytes from RAND_bytes() if OpenSSL support is available (which is most
often the case I believe).
yamo' <user@tld.invalid> composa la prose suivante:
Hi,
Russ Allbery a écrit :
* Document domain as a first-class configuration parameter for access
groups in readers.conf, saying that it changes the way message IDs are >>> constructed. (I'm not sure if it does anything else?)
Changing it, add the domain value to the Path for messages added by nnrpd >>and when getting messages with a client of nnrpd.
No: only if "virtualhost" is also set to true in reader.conf.
If "virtualhost" is not present it only modify the path in injection info. >For example:
With virtualhost: "injection-Info: machinename.readersconfDomain"
Without virtualhost: "injection-Info: machinename.InnConfDomain"
it's a pity that we can't delete the name of the machine at this place
Julien <iulius@nom-de-mon-site.com.invalid> writes:
Digging in the archives, I found out this message:
https://lists.isc.org/mailman/htdig/inn-workers/1999-September/000423.html
"""
Suppose you've got a news farm of twenty-odd
machines hiding behind news.example.com. You probably want just >>news.example.com in e-mail addresses, but if you use that for message ID >>generation as well, doesn't that then run a non-trivial risk of duplicate >>message IDs?
The reason to use the FQDN is so that you can be fairly sure no other >>system is generating message IDs in the same namespace....
"""
Ah, hm. Yes, INN's mesage ID generation algorithm is not great and we
could indeed get duplicates if multiple hosts are using the same
right-hand side.
. . .
Let's assume the issue applies to hosts on different News sites. Either
the News administrator or user decides there's a legitimate privacy
reason that it's not desireable to use the working domain of the News
server or the user's own host. With better random number generators
available these days, is it possible to ensure uniqueness considering
the left part of the Message-ID only if multiple News sites or users
start to use domains in the right half that they don't uniquely control
but are harmless to use, like literally example.com?
As long as you are thinking about this, can you give some consideration
to appending a check digit to the left part?
A certain user I shall not name (but many of you know exactly whom I am talking about) has been forging other users, copying their Injection
headers for preloading into the proto forged article which is injected through the News site that he uses. He typically adds crossposted
newsgroups that the actual author did not crosspost to.
The original Message-ID is preloaded as well, but he gets around
clashing Message-IDs by prepending a character.
A check digit might prevent that. Of course, he'll find all new ways to commit abuse.
"Adam H. Kerman" <ahk@chinet.com> writes:
Let's assume the issue applies to hosts on different News sites. Either
the News administrator or user decides there's a legitimate privacy
reason that it's not desireable to use the working domain of the News >>server or the user's own host. With better random number generators >>available these days, is it possible to ensure uniqueness considering
the left part of the Message-ID only if multiple News sites or users
start to use domains in the right half that they don't uniquely control
but are harmless to use, like literally example.com?
Yes, assuming you have a good random number generator, any random number >generator suitable for a cryptographic key will probably be good enough
for this. The constraints are slightly different, but avoiding collisions >across a fairly large space ends up looking somewhat similar to what you
need to get protection against brute-force attacks. . . .
As long as you are thinking about this, can you give some consideration
to appending a check digit to the left part?
A certain user I shall not name (but many of you know exactly whom I am >>talking about) has been forging other users, copying their Injection >>headers for preloading into the proto forged article which is injected >>through the News site that he uses. He typically adds crossposted >>newsgroups that the actual author did not crosspost to.
The original Message-ID is preloaded as well, but he gets around
clashing Message-IDs by prepending a character.
A check digit might prevent that. Of course, he'll find all new ways to >>commit abuse.
I'm not sure I understand how a check digit helps. The check digit won't >match and... then what? You need some way to filter out the forged
messages, but most people aren't going to be using some new message ID >generation algorithm. Also, since the whole message is forged, that
person can just make up a new message ID at the same domain with a good
check digit.
If the goal is for people to be able to opt in to forgery protection, some >sort of public key signature is a more obvious choice.
Russ Allbery <eagle@eyrie.org> wrote:
If the goal is for people to be able to opt in to forgery protection,
some sort of public key signature is a more obvious choice.
Same issue. No reader checks.
The problem is that the News site was allowing the forged articles to be injected despite the fact of the preloaded Injection headers belongng to another News site, which was quite nonstandard indeed.
Do you think we should improve the generation of Message-IDs? They're currently based on the date, PID and a counter incrementing at each
call. A quick improvement could be to also add for instance 6 bytes
from RAND_bytes() if OpenSSL support is available (which is most often
the case I believe).
Yes, servername looks like an appropriate name. It will be a useful improvement for the next major release. I propose to also have a
servername parameter in inn.conf as inews generates Message-IDs (and currently uses the value of the domain parameter in inn.conf). And the
value of servername can be overriden in readers.conf.
The default value of servername in inn.conf (optional parameter) would
then be pathhost (mandatory to set in inn.conf).
If "virtualhost" is not present it only modify the path in injection info. >> For example:
With virtualhost: "injection-Info: machinename.readersconfDomain"
Without virtualhost: "injection-Info: machinename.InnConfDomain"
it's a pity that we can't delete the name of the machine at this place
This day, i update ubuntu and inn2 to version 2.6.4-2.
The name of the machine has disappeared from injection-info :-)
INN's current algorithm is sort of interesting in that under most circumstances it will guarantee (as opposed to make probabilistically
likely) unique message IDs, but only if the FQDN is unique.
In theory, tossing the counter and the PID and replacing both with eight random bytes is better, since it doesn't rely as heavily on the uniqueness
of the right-hand side. In practice, it feels weird because we're giving
up designed uniqueness for probability! But it's probably still the right thing to do.
Russ Allbery schrieb:
In theory, tossing the counter and the PID and replacing both with
eight random bytes is better, since it doesn't rely as heavily on the
uniqueness of the right-hand side. In practice, it feels weird because
we're giving up designed uniqueness for probability! But it's probably
still the right thing to do.
I'm not sure that's the right way to go. The probability of duplicates
on correctly configured systems would increase, and this is a poor
tradeoff for a decreased probability of duplicates on suboptimally
configured systems.
Hi Russ,
In theory, tossing the counter and the PID and replacing both with
eight random bytes is better, since it doesn't rely as heavily on the
uniqueness of the right-hand side. In practice, it feels weird because
we're giving up designed uniqueness for probability! But it's probably
still the right thing to do.
Besides, on two different servers, OpenSSL will compute different seeds
at startup (or better say the chance that the seeds are identical is negligible).
Radix32() only generates lower-case chars in the left-hand side. I
don't understand the remark that it "doesn't assume that message IDs are case-sensitive": is it because it could also have used upper-case
letters and therefore generating even smaller message IDs?
Indeed, though RFC 5536 only worries about case-insensitive matching on
the right-hand side:
Some software will try to match the <id-right> of a <msg-id> in a
case-insensitive fashion; some will match it in a case-sensitive
fashion. Implementations MUST NOT generate a Message-ID where the
only difference from another Message-ID is the case of characters in
the <id-right> part.
Yes, that's an wise view, and we can consider servername for the identity
of nnrpd and pathhost for the identity of innd.
Maybe your point is that the name of the parameter should be serverhost instead of the previously proposed servername?
In theory, tossing the counter and the PID and replacing both with eight random bytes is better, since it doesn't rely as heavily on the uniqueness
of the right-hand side. In practice, it feels weird because we're giving
up designed uniqueness for probability! But it's probably still the right thing to do.
I think this is the only use of the Radix32() function in INN as well,
which doesn't assume that message IDs are case-sensitive.
I see that we
were worried about case-insensitive matching on message IDs when we wrote 5536. That's unfortunate, since if you assume case-sensitivity, like I
did in my other message, you could make the message ID a lot shorter.
Yes, servername looks like an appropriate name. It will be a useful
improvement for the next major release. I propose to also have a
servername parameter in inn.conf as inews generates Message-IDs (and
currently uses the value of the domain parameter in inn.conf). And the
value of servername can be overriden in readers.conf.
Ah, yes, I forgot about inews.
One interesting wrinkle here: if serverhost and pathhost are set to
different things, it's unclear what should go into Injection-Info. It
looks like we never said. The ABNF grammar says it's a path-identity,
which sort of implies it should be pathhost, but the grammar of course is identical for both elements.
I suspect the right way to think of it is that serverhost is the identity
of nnrpd and pathhost is the identity of innd, so it should be serverhost. (This is probably most interesting in the unusual configuration where you have a farm of nnrpd servers on different hosts all feeding into a central innd.)
The session is generated when a client connects and remains bound to its > socket for its lifetime.To be more precise, session is generated when a client connect (and
INN's mesage ID generation algorithm is not great and weDo you think we should improve the generation of Message-IDs?
could indeed get duplicates if multiple hosts are using the same
right-hand side. >
They're currently based on the date, PID and a counter incrementing at
each call. A quick improvement could be to also add for instance 6
bytes from RAND_bytes() if OpenSSL support is available (which is most
often the case I believe).
Although Spitfire News Server does not support virtual hosts, it uses
this form of Message-Id:
<session.timestamp_arrival_gmt@fqdn>
The "Session" is a complex calculation based on information like "Date"
and "PID" but also on other information from the hardware (Processor AND interface that accepts the client socket), which makes it unique to the "machine/interface" pair.
Are you sure that the information from the hardware will be different in
a virtual private server (VPS)? Couldn't all the virtual machines have
the same processor and interface name?
Even if I am convinced that two articles sent on the same socket (one
after one) cannot have the same timestamp to the nearest hundredth of a second, I have taken into account your remark (elsewhere) on the
timestamp placed after the "session" name.
Spitfire News Server now use this format :
<session.number-of-items-submitted-during-the-same-session@fqdn>
Btw, it's a good thing because it shorten the Message-ID :-)
:-)
It is true that TAKETHIS can be pipelined contrary to POST, so the
chance to POST more than 100 articles in one second is very small,
contrary to a feed where we managed to exchange 140 articles in one
second with TAKETHIS.
A malicious poster may pipeline POST and achieve that rate, but it won't
do any harm; his posts will just be discarded because of duplicate Message-IDs.
That takes the date as a number (20220922222200) and represents it in 6 bytes, which is good enough for the next 10,000 years. With a timestamp,
I'm pretty sure you could cut that down to 64 bits and still be pretty comfortable, which gives you something like:
EmQM4tZ4$uYRo9tEy/80@example.com
Hello Russ,
That takes the date as a number (20220922222200) and represents it in 6
bytes, which is good enough for the next 10,000 years. With a timestamp,
I'm pretty sure you could cut that down to 64 bits and still be pretty
comfortable, which gives you something like:
EmQM4tZ4$uYRo9tEy/80@example.com
Quickly implemented in Spitfire News Server for testing purposes.
Message-ID: <EmQSD29Yka97hBQCPZo=@news.spitfire-nntp.fr>
The result is only slightly larger than my previous format but I give it a chance :)
Oh, since someone is actually using this, I should mention that I realized after my post that this is a kind of silly encoding of the date and you should just use seconds since epoch, which will carry the same information and be a lot more compact.
Also, you can drop the = padding signs from the end of the base64 output.
The amount of padding required can be calculated from the length of the string once you know it's base64-encoded, so it doesn't add any
information.
Oh, since someone is actually using this, I should mention that I realized after my post that this is a kind of silly encoding of the date and you should just use seconds since epoch, which will carry the same information and be a lot more compact.
Hi Russ,
Oh, since someone is actually using this, I should mention that I realized >> after my post that this is a kind of silly encoding of the date and you
should just use seconds since epoch, which will carry the same information >> and be a lot more compact.
At this time, when generating a Message-ID, there is no chance to get a timestamp (at least) in the range of years 1970 to 2021, witch represent about 1640905200 seconds.
Wouldn't it make sense to set the "0 Date" to 2022-01-01 so the Message-ID will be more compact?
At this time, when generating a Message-ID, there is no chance to get a timestamp (at least) in the range of years 1970 to 2021, witch represent about 1640905200 seconds.
Wouldn't it make sense to set the "0 Date" to 2022-01-01 so the
Message-ID will be more compact?
Message-ID: <Y0KVxHLrtq6oCVJ2@news.spitfire-nntp.fr>16 bytes at the left-hand side of the Message-ID, and probably less with
We could also save 1 byte more (in the resulting Base64 string) if
changing the timestamp every minute instead of every second. Dividing
the number of seconds by 2^6=64 (or shifting 6 bits to the right) would
do that, without really adding a noticeable risk of duplicate
Message-IDs I think.
Also, you can drop the = padding signs from the end of the base64 output.
The amount of padding required can be calculated from the length of the
string once you know it's base64-encoded, so it doesn't add any
information.
Done.
Message ID : <Y0KVxHLrtq6oCVJ2@news.spitfire-nntp.fr>
Now, the result is slightly smaler than my previous format 😄
I've had a look at this issue today, and made the discussed changes toI would tend to take the one from readers.conf anyway. As it is forced
in readers.conf, there may be a reason; inn.conf documentation says to
have a look at domain (or virtualhost) in readers.conf to change the
righthand side of autogenerated Message-IDs, but that special rule is
not mentioned. I would just drop it...
BTW, I had a bit of a hard time following the documentation, because
inn.conf says to set domain in readers.conf but then domain isn't
documented in readers.conf except in the list of inn.conf settings that
can also be set there.
* Use domain unconditionally for forming message IDs if it's set in readers.conf.
* Document domain as a first-class configuration parameter for
access groups in readers.conf, saying that it changes the way message
IDs are constructed.
One interesting wrinkle here: if servername and pathhost are set toHaving a deeper look at it for INN 2.8.0 (as it is a
different things, it's unclear what should go into Injection-Info.
It looks like we never said. The ABNF grammar says it's a
path-identity, which sort of implies it should be pathhost, but the
grammar of course is identical for both elements.
Hi Russ,
One interesting wrinkle here: if servername and pathhost are set to >>different things, it's unclear what should go into Injection-Info.
It looks like we never said. The ABNF grammar says it's a
path-identity, which sort of implies it should be pathhost, but the
grammar of course is identical for both elements.
Having a deeper look at it for INN 2.8.0 (as it is a
backwards-incompatible change), I've found the answer in Section 3.2 of
RFC 5537
All news server components (injecting agents, relaying agents, and
serving agents) MUST identify themselves, when processing an article,
by prepending their <path-identity> (defined in Section 3.1.5 of
[RFC5536]) to the Path header field. Injecting agents MUST also use
the same identity in Injection-Info header fields that they add, and
serving and relaying agents SHOULD use the same identity in any Xref
header fields they add.
The server name in Injection-Info MUST be the path identity, and the
server name in Xref SHOULD be the path identity.
Hmm, nnrpd currently leaves the update of the Path header field to innd,
so we'll break a MUST if servername (intended to be the identity of
nnrpd) and pathhost (the identity of innd) are not the same.
I therefore suggest that if servername and pathhost are different, we
add both in Path.
nnrpd will generate "servername!.POSTED.xxx!not-for-mail", and innd will
add "pathhost!!" (with an additional verified diag match "!").
. . .
What is the purpose of the second bang? I do try to read
Path and the purpose would not be obvious to me.
. . .
You know everything about Path now :)
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 428 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 107:42:32 |
| Calls: | 9,053 |
| Calls today: | 10 |
| Files: | 13,395 |
| Messages: | 6,015,806 |