Hi Jesse,
> I'm trying to setup the virtualhost option in nnrpd and am not sure I'm doing
> things correctly.
>
> The man page states:
>
>> If you set this parameter to true, you must also set either
>> pathhost or domain in the relevant access group in readers.conf to
>> something different than is set in inn.conf.
>
> So I set virtualhost to true and set pathhost to the desired value, but the
> following error is logged and connections are rejected:
Many thanks for your report! The documentation of virtualhost is indeed
wrong in the readers.conf man page. It should be:
"""
Set this parameter to true in order to make nnrpd behave as if it is
running on a server with a different name than it actually is. The "domain"
parameter then must also be set either in inn.conf or in the same access
group. All articles displayed to clients will have their Xref header field
bodies altered to appear to be from the server named in "domain", and posted
articles will use that server name in the Message-ID and Injection-Info header
field bodies.
Similarly, the Path header field bodies displayed to clients or in posted
articles will use the value of "domain" (if "pathhost" is not set in the
access group, or has the same value as in inn.conf) or "pathhost" (if
"pathhost" is set in the access group to something different than is set
in inn.conf).
At least one of the "domain" or "pathhost" parameters must be set in the
access group to something different than in inn.conf, otherwise nnrpd will
fail to start.
"""
Is it understandable enough, written this way?
> Should nnrpd be happy with just the "pathhost" parameter as the man page
> states, or am I missing something? I fiddled around a bit, but unless I also
> set the domain parameter nnrpd wouldn't accept incoming connections.
Setting "domain" is mandatory (if not already set in inn.conf).
> Does the extra "!" in the Path header have some special meaning, or is this
> due to some other misconfiguration on my part?
It's not a misconfiguration. This is normal, and corresponds to the fact that
nnrpd considers as trusted "
spool1.usenet.blueworldhosting.com" (a known value).
"!!" is a way to say that the path identity is "verified".
Note that INN does not currently implement that verification (to be done...),
and uses that syntax only in virtualhost!
FWIW, an excerpt of RFC 5537 to show you how the Path header field should
be read:
3.2.2. Path Header Field Example
Here is an example of a Path header field created by following the
rules for injecting and relaying agents.
Path: foo.isp.example!.SEEN.isp.example!foo-news
!.MISMATCH.2001:DB8:0:0:8:800:200C:417A!bar.isp.example
!!old.site.example!barbaz!!baz.isp.example
!.POSTED.dialup123.baz.isp.example!not-for-mail
This article was injected by baz.isp.example as indicated by the
<diag-keyword> "POSTED". The injector has recorded that it received
the article from dialup123.baz.isp.example. "not-for-mail" is a
common <tail-entry>.
The article was relayed to the relaying agent known, at least to
old.site.example, as "barbaz". That relaying agent confirmed to its
satisfaction that "baz.isp.example" was an expected <path-identity>
for the source of the article and therefore used <diag-match> ("!")
for its <path-diagnostic>.
barbaz relayed it to old.site.example, which does not support <diag-
keyword> and therefore used the old "!" delimiter. This indicates
that the identity of "barbaz" was not verified and may have been
forged.
old.site.example relayed it to a news server using the <path-
identity> of bar.isp.example and claiming (by using the "!" <path-
diagnostic>) to have verified that it came from old.site.example.
bar.isp.example relayed it to foo-news, which, not being convinced
that it truly came from bar.isp.example, inserted the <diag-keyword>
"MISMATCH" and then stated that it received the article from the IPv6
address [2001:DB8:0:0:8:800:200C:417A]. (This is not to say that
bar.isp.example was not a correct <path-identity> for that source but
simply that the identity did not match the expectations of foo-news.)
foo-news then passed the article to foo.isp.example, which declined
to validate its <path-identity> and instead appended the <diag-
keyword> "SEEN" to indicate it knows the source of the article as
isp.example. This may be either an expected <path-identity> or the
FQDN of the system from which it received the article. Presumably,
foo.isp.example is a serving agent that then delivered the article to
a reading agent.
baz.isp.example, bar.isp.example, and foo-news folded the Path header
field.
--
Julien ÉLIE
« C'est la goutte qui fait déborder l'amphore ! » (Assurancetourix)