Audit of INN against draft-ietf-nntpext-base-13.txt complete

Russ Allbery rra at stanford.edu
Wed Jun 5 21:41:58 UTC 2002


Alex Kiernan <alexk at demon.net> writes:
> Russ Allbery <rra at stanford.edu> writes:

>> This is the only bit that's arguably against the RFC, so we should
>> probably document this in the nnrpd man page as an intentional
>> deviation from the standard.  (I understand the reasons for wanting to
>> do it.)

> Do you think this should be configurable? I can't manage to think of a
> scenario in which you'd actually want to disable this behaviour.

Well, some sites actually don't want to add any tracing headers at all
(one theoretically doesn't actually need them; the message ID is
sufficient to grep the logs), so I do think that for both POST and IHAVE
there should be some way of turning them all off.  Right now, it's
impossible to turn off X-Trace on POST, and I think that's a mistake.

Picking good defaults is one thing, but I don't want to lock anyone into a
particular stance on what sort of trace information to expose in the
headers.

> I also got around to conditionalising IHAVE support via access: in
> readers.conf (the `I' option), defaulting to off (plus you have to have
> post access to whatever group you're injecting articles to).

That sounds excellent.

> I'm having a great time - I so rarely get to write code anymore, hacking
> something like that together is great fun!

*grin*  Yeah, that's a big part of why I work on INN.

> Something else which is on the compliance list, the initial timeout I
> thought maybe we could address with SO_KEEPALIVE - basically set it
> until the initial command has come through, then turn it off; I'm not
> sure what the comment in the code means by connection abandoned -
> assuming it means something like the far end didn't send us a reset, but
> has otherwise closed its connection, I think this should address that
> need.

Hm, yeah, that's a thought.  I don't know the exact history behind that
code, and it's sometimes annoying when one is telnetting to the port to
try some things by hand.  At least from the comment, it does sound like
SO_KEEPALIVE would resolve the issue.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.


More information about the inn-workers mailing list