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

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

Russ Allbery <rra at> writes:

> Alex Kiernan <alexk at> writes:
> > Russ Allbery <rra at> 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