Re: [NNTP] Interesting server behaviour

Russ Allbery <rra <at> stanford.edu>
2012-01-02 02:56:27 GMT

River Tarnell <river <at> RT.UK.EU.ORG> writes:
> (Re-sending because my first message didn't appear -- sorry if this
> shows up twice.)
Hm, not sure what happened there. I didn't see it get caught in the
moderation queue. I'll check the list settings and make sure it wasn't
silently throwing something away.
> I just noticed the following rather unfortunate behaviour from one
> widely-used NNTP server:
> % telnet 69.16.177.254 nntp
> Trying 69.16.177.254...
> Connected to voer-me.highwinds-media.com.
> Escape character is '^]'.
> 200 (cyclone01.ams2) -- Welcome (Cyclone v2.4.1.749-3)
> CAPABILITIES
> 500 Syntax Error or Unknown Command
> Connection closed by foreign host.
> So 6 years after RFC 3799 was published, it's still impossible in
> practice to use CAPABILITIES to discover streaming.
Yeah. This unfortunately was something that we were somewhat expecting,
given how long the standardization process took and the gentle decline of
NNTP technology in general. Not a lot of active work is going on in this
area, so there hasn't been a lot of incentive to refit older software and
move into compliance with the standard.

Re: [NNTP] Interesting server behaviour

Russ Allbery <rra <at> stanford.edu>
2012-01-02 02:59:23 GMT

Russ Allbery <rra <at> stanford.edu> writes:
> River Tarnell <river <at> RT.UK.EU.ORG> writes:
>> (Re-sending because my first message didn't appear -- sorry if this
>> shows up twice.)
> Hm, not sure what happened there. I didn't see it get caught in the
> moderation queue. I'll check the list settings and make sure it wasn't
> silently throwing something away.
The list was set to discard mail from non-members rather than hold it for
moderation. Sorry about that; I'm not sure what I was originally thinking
when I set it that way. That's now fixed.
--
--
Russ Allbery (rra <at> stanford.edu) <http://www.eyrie.org/~eagle/>

Re: [NNTP] Interesting server behaviour

River Tarnell <river <at> RT.UK.EU.ORG>
2012-01-02 05:18:30 GMT

Russ Allbery:
> The list was set to discard mail from non-members rather than hold it for
> moderation. Sorry about that; I'm not sure what I was originally thinking
> when I set it that way. That's now fixed.
I'm pretty sure I subscribed before I posted. My first message had an
S/MIME signature though (MIME type application/x-pkcs7-signature);
perhaps that's why the list rejected it?
I didn't get any sort of rejection message.
Regards,
--
--
-- river. | Free Usenet: http://news.rt.uk.eu.org/
Non-Reciprocal Laws of Expectations: | PGP: 2B9CE6F2
Negative expectations yield negative results.
Positive expectations yield negative results.

Re: [NNTP] Interesting server behaviour

Russ Allbery <rra <at> stanford.edu>
2012-01-02 05:35:46 GMT

River Tarnell <river <at> RT.UK.EU.ORG> writes:
> Russ Allbery:
>> The list was set to discard mail from non-members rather than hold it
>> for moderation. Sorry about that; I'm not sure what I was originally
>> thinking when I set it that way. That's now fixed.
> I'm pretty sure I subscribed before I posted. My first message had an
> S/MIME signature though (MIME type application/x-pkcs7-signature);
> perhaps that's why the list rejected it?
Hm. It *shouldn't* care about that.
> I didn't get any sort of rejection message.
Yeah, non-member mail at least was set to discard. Now it will be held
for moderation, which would result in a notification. (I'm always leery
of that, though, and rejection, because it tends to result in a ton of
bounce-back spam.)
--
--
Russ Allbery (rra <at> stanford.edu) <http://www.eyrie.org/~eagle/>

Re: [NNTP] Interesting server behaviour

Ade Lovett <ade <at> lovett.com>
2012-01-02 11:09:42 GMT

On 01/01/12 18:56, Russ Allbery wrote:
> Yeah. This unfortunately was something that we were somewhat expecting,
> given how long the standardization process took and the gentle decline of
> NNTP technology in general. Not a lot of active work is going on in this
> area, so there hasn't been a lot of incentive to refit older software and
> move into compliance with the standard.
Not to mention that a considerable chunk of the old guard in charge of
large server farms have moved on to pastures new.
Mine's the coat with "Yahoo!" written on the back. At least it will be
in a week or so.
Cheerio.
-aDe

[NNTP] Advertise maximum article size in CAPABILITIES

River Tarnell <river <at> RT.UK.EU.ORG>
2012-01-07 17:14:17 GMT

(Re-sending this because it didn't appear again; I know I'm subscribed
this time, so I think the S/MIME signature must be the problem.)
Hi,
I propose an extension to the NNTP protocol: a server should advertise
the maximum article size it is willing to accept in CAPABILITIES, via a
new "SIZE <nbytes>" capability. A client should not offer any article
(via POST, IHAVE, CHECK or TAKETHIS) which is larger than that size.
Rationale: no need to configure maximum article size to send to every
peer; allows peers to change the maximum article size they want to
accept without having to contact all their peers to change the config;
allows clients posting multi-part messages (i.e., binaries) to split
messages based on the server-suggested size.
Real-world use: I can allow articles up to 1MB from a text-only peer,
while restricting articles from a peer that carries unfiltered binaries
to 32KB.
I haven't implemented this or done any interoperability checking yet;
I'm happy to do that and write an I-D/RFC for it myself if it seems like
a good idea.
Regards,
--
--
-- river. | Free Usenet: http://news.rt.uk.eu.org/
Non-Reciprocal Laws of Expectations: | PGP: 2B9CE6F2
Negative expectations yield negative results.

Re: [NNTP] Advertise maximum article size in CAPABILITIES

Russ Allbery <rra <at> stanford.edu>
2012-01-07 17:21:57 GMT

River Tarnell <river <at> RT.UK.EU.ORG> writes:
> (Re-sending this because it didn't appear again; I know I'm subscribed
> this time, so I think the S/MIME signature must be the problem.)
Gah. Yes. I'm sorry. This is fixed now. I was looking in the wrong
place in the list configuration.
I'e just removed all the restrictions on MIME types. There shouldn't be
any need for that.
> I propose an extension to the NNTP protocol: a server should advertise
> the maximum article size it is willing to accept in CAPABILITIES, via a
> new "SIZE <nbytes>" capability. A client should not offer any article
> (via POST, IHAVE, CHECK or TAKETHIS) which is larger than that size.
I like this idea.
--
--
Russ Allbery (rra <at> stanford.edu) <http://www.eyrie.org/~eagle/>

[NNTP] Command to list wanted groups for transit peers

River Tarnell <river <at> RT.UK.EU.ORG>
2012-01-07 18:56:11 GMT

Hi,
So, most (at least non-binary) peering arrangements include a list of
groups the server wants to accept. Usually this is configured by hand,
but there are automated out-of-band methods to do it automatically (e.g.
GUP, the Group Update Protocol).
I think a better way to do it would be a new command, which would list
the groups the server wants to accept as a wildmat. For instance:
S: 200 Server ready.
C: CAPABILITIES
S: 101 Capabilities list follows.
S: WANTGROUPS
S: ...
S: .
C: WANTGROUPS
S: 2xx List of groups follows.
S: *
S: <at> alt.sex.*
S: <at> *.bina*
S: de.bina*
S: !uk.test
S: .
C: CHECK <...
This would be an "extended" wildmat like INN uses; I don't think <at> is
available in the RFC 3977 wildmats.
Thoughts?