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

Alex Kiernan alexk at demon.net
Thu Jun 6 05:33:58 UTC 2002


Russ Allbery <rra at stanford.edu> writes:

> 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.
> 

OK, I'll add stuff to readers.conf so we can configure X-Trace (and
friends); I think they should go in as new readers.conf options,
rather than getting mangled into access: (whilst I'm about it I'll add
replacements for all the access: stuff so we can remove access:
altogether if we want).

> 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.
> 

Default off, I guess, for compliance.

> > 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.
> 

Somewhere along the line seems like I forgot how SO_KEEPALIVE actually
worked, sadly I don't think its going to help. I'll likely just go the
whole hog and add an initialtimeout clause to readers.conf which
defaults to the same as the clienttimeout.

-- 
Alex Kiernan, Principal Engineer, Development, Thus PLC


More information about the inn-workers mailing list