headers
River Tarnell | 2 Jan 2012 03:10

[NNTP] Interesting server behaviour

(Re-sending because my first message didn't appear -- sorry if this 
shows up twice.)

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.

I don't have anything in particular to say about this, but I thought I'd 
note it for the list archives if nothing else.

--

-- 
        -- 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.
Permalink | Reply | 5 comments |
headers
Russ Allbery | 2 Jan 2012 03:56
Picon
Favicon
Gravatar

Re: [NNTP] Interesting server behaviour

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.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Russ Allbery | 2 Jan 2012 03:59
Picon
Favicon
Gravatar

Re: [NNTP] Interesting server behaviour

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/>
Permalink | Reply | 2 comments |
headers
River Tarnell | 2 Jan 2012 06:18

Re: [NNTP] Interesting server behaviour

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.
Permalink | Reply | 1 comment |
headers
Russ Allbery | 2 Jan 2012 06:35
Picon
Favicon
Gravatar

Re: [NNTP] Interesting server behaviour

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/>
Permalink | Reply | 0 comments |
headers
Ade Lovett | 2 Jan 2012 12:09
Favicon

Re: [NNTP] Interesting server behaviour

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
Permalink | Reply | 0 comments |
headers
River Tarnell | 7 Jan 2012 18:14

[NNTP] Advertise maximum article size in CAPABILITIES


(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.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Russ Allbery | 7 Jan 2012 18:21
Picon
Favicon
Gravatar

Re: [NNTP] Advertise maximum article size in CAPABILITIES

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/>
Permalink | Reply | 0 comments |
headers
River Tarnell | 7 Jan 2012 19:56

[NNTP] Command to list wanted groups for transit peers

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?
(Continue reading)

Permalink | Reply | 1 comment |

Gmane