Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: Build system changes (Julien ?LIE)
2. Re: NNTPS pointers / NNSP (Julien ?LIE)
3. Re: Custom message for authentication (Julien ?LIE)
4. Re: NNTPS pointers / NNSP (Grant Taylor)
5. NNPS / TCP port 433 (Grant Taylor)
----------------------------------------------------------------------
Message: 1
Date: Wed, 27 Oct 2021 23:22:23 +0200
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: Build system changes
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Russ,
>> For the 2.6 release branch, maybe we could just take Richard's work on #206.
>
> Yes, agreed.
>
> Probably also worth thinking about whether we want to release 2.7 first
> with ovsqlite and *then* merge a potentially disruptive build system
> change that's likely to expose a bunch of edge cases and random things the
> current build system does that I didn't think about.
I think we should wait for the new build system for the 2.7.0 release
(if of course you have time to make it work). I had in mind a 2.6.5
last release for the 2.6 branch in the first semester of 2022, and 2.7.0
a few weeks later.
I would also like to add Cancel-Lock support in 2.7.0 (but of course it
can come later).
And we have to focus on changes that only go into major releases, so as
not to delay them more (to 2.8). I noted for 2.7.0:
- Drop obsolete Python and Perl hooks wrappers #163
- Rename require_ssl to require_encryption in readers.conf #156
- Split innreport.conf into 2 files (no open ticket yet)
Rework of history, overview, storage, filtering API naturally also
possible :-)
- Remove or fix installation of signcontrol #28
=> couldn't signcontrol just be moved to the "contrib" directory then?
It will no longer be installed by default and overwritten during a "make
update"
--
Julien ?LIE
??Medice, cura te ipsum.??
------------------------------
Message: 2
Date: Wed, 27 Oct 2021 23:27:04 +0200
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: NNTPS pointers / NNSP
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Grant,
>> I know that is the standard mode of operation.? However I believe
>> there are some ... hacks that can be applied on Linux that get
>> extremely creative with the routing table and use other skulduggery to
>> fake the IP address that INN (et al.) sees.
>
> Success!!! \o/
>
> I'm using a combination of stunnel, iptables connection marking, and
> iproute2 policy based routing to provide NNSP such that INN sees the
> remote system's real IP address.? }:-D
Awesome!
It's worth adding that information in our FAQ if you're OK with that.
I can reference the iptables commands you found out. Any other
configuration to mention?
--
Julien ?LIE
??Ta remise sur pied lui a fait perdre la t?te?!?? (Ast?rix)
------------------------------
Message: 3
Date: Wed, 27 Oct 2021 23:37:13 +0200
From: Julien ?LIE <[email protected]>
To: ejs <[email protected]>, [email protected]
Subject: Re: Custom message for authentication
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi ejs,
> we are running INN with Perl filter for authentication. We do not
> require the authentification for the 'trusted' hosts, e.g. the ones, can
> be tracked to a trusted local ISP.
>
> For now, if a username/password is not set by a client, the server
> resonds with 480 response, and it seems the response is not comming from
> the Perl auth filter.
>
> Is there any way to customize this response, the way 480 response can be
> customized by the return values?
The Perl authentication hook is called only when the client tries to
authenticate (sending an AUTHINFO command) and the Python dynamic hook
when the client tries to enter a group (sending a GROUP command).
Unfortunately, the responses you see for other commands are hard-coded.
For instance "480 IHAVE command disabled by administrator", "480
Posting not allowed", "480 Read access denied"...
Maybe you could add something in "motd.nnrpd" but not many newsreaders
know how to display that message of the day...
--
Julien ?LIE
??Ta remise sur pied lui a fait perdre la t?te?!?? (Ast?rix)
------------------------------
Message: 4
Date: Wed, 27 Oct 2021 20:26:52 -0600
From: Grant Taylor <[email protected]>
To: [email protected]
Subject: Re: NNTPS pointers / NNSP
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 10/27/21 3:27 PM, Julien ?LIE wrote:
> Hi Grant,
Hi Julien,
> Awesome!
:-)
> It's worth adding that information in our FAQ if you're OK with that.
Agreed. Yes, I'm okay with it.
Though I might suggest holding off for a little while longer. I have
managed to use iproute2 policy based routing and stunnel (no iptables
required) to get INN to act as a client to a TLS enabled NNSP (NNTPS)
server.
I'd like to spend some more time working on things, or discuss what I've
done with someone else interested in reproducing what I've done. Use
that effort to make the directions consistent.
E.g. is iptables connection marking required or not? -- iptables or
fancier iproute2 PBR rules achieve the same goal. Also, compare and
contrast stunnel with socat. The latter of the two sets are how I did
the client portion.
> I can reference the iptables commands you found out.? Any other
> configuration to mention?
Ya. More details on the client and unifying of the server (previous
message) and client (yet to be fully described) methods.
But, yes, the spirit is sharing this so that others can utilize it if
they so choose.
--
Grant. . . .
unix || die
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL:
<https://lists.isc.org/pipermail/inn-workers/attachments/20211027/0da5e009/attachment-0001.bin>
------------------------------
Message: 5
Date: Wed, 27 Oct 2021 20:48:29 -0600
From: Grant Taylor <[email protected]>
To: [email protected]
Subject: NNPS / TCP port 433
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hi,
Can anyone say with any authority if the NNPS / TCP port 433 is clear
text like the NNTP / TCP port 119 or implicitly encrypted like the NNTPS
/ TCP port 563?
IANA has the following three ports registered for NNTP:
NNTP - 119 - RFC 3977 - unencrypted & explicit encryption via STARTTLS
NNSP - 433 - RFC 3977 - unspecified
NNTPS - 563 - RFC 4642 - implicit encryption via TLS
RFC 3977 has "STARTTLS" but discusses it on TCP port 119.
RFC 3977 also states: The official TCP port for the NNTP service is
119. However, if a host wishes to offer separate servers for transit
and reading clients, port 433 SHOULD be used for the transit server and
119 for the reading server.
This second statement makes me think that the only difference between
TCP ports 119 and 433 is their intended purpose. This seems reminiscent
of SMTP's MTA port 25 and MSA port 587, both of which are unencrypted /
explicit encryption via STARTTLS.
So ... what should the NNSP / TCP port 433 be? My inclination is that
NNSP / TCP port 433 is identical to NNTP / TCP port 119.
What say you?
--
Grant. . . .
unix || die
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL:
<https://lists.isc.org/pipermail/inn-workers/attachments/20211027/a1d8517a/attachment.bin>
------------------------------
Subject: Digest Footer
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
------------------------------
End of inn-workers Digest, Vol 134, Issue 14
********************************************
