ietf-nntp POST and IHAVE responses (was: Commetns on draft-15.pdf)

[Charles Lindsey]

In <yl4rm75bga.fsf at windlord.stanford.edu> Russ Allbery <rra at stanford.edu> writes:


>Charles Lindsey <chl at clw.cs.man.ac.uk> writes:


>> There is also a remark in S9.3.2 (IHAVE) that some servers may not be
>> able to provide such responses in real-time. Should that remark not
>> appear here also, since it seems to apply equally to POST?

>The IHAVE comment is somewhat confusingly worded; it assumes that servers
>work like C News.  It's not a significant problem, but I think it could be
>worded better.  And looking at it more closely, this issue is dealt with
>in a couple of places in 9.3.2 and the latter comment is much clearer.

>I propose simply removing this portion of section 9.3.2:

>    However, the server MAY elect not to post or forward the article if
>    after further examination of the article it deems it inappropriate to
>    do so. Reasons for such subsequent rejection of an article may include
>    such problems as inappropriate newsgroups or distributions, disk space
>    limitations, article lengths, garbled headers, and the like. These are
>    typically restrictions enforced by the server host's news software and
>    not necessarily the NNTP server itself.

Yes, I don't mind if that is removed.

>because the end of the last paragraph says the same thing more succinctly.

Yes, that last paragraph is actually the one I had in mind when I said we
also needed some similar mention in the POST command.

What happens in CNEWS is this. When it receives a POST, it does various
checks for things that posters typically get wrong, and also fills in
absent Message-ID headers, and the like. If it finds anything wrong, it
reports it in a 441 response. If it passes, it queues it up for relaying
later.

When it receives IHAVE, it just queues it up for relaying, as above.

In both cases, the queue is run later on as a batchjob. At that stage some
further (and possibly more obscure) tests are done, which may then result
in the article being dropped on the floor silently.

The paragraph at the end of 9.3.2 was designed to deal with that kind of
silent dropping. My point is that the same thing actually arises, in CNEWS
at least, in the POST command in those cases where the article passed all
the injecting checks, but failed on some of the relaying checks.

Yes, it would be better if the injector did more thorough checks, but I am
just reporting it the way it is.

That is why I suggested that short paragraph at the end of 9.3.2 should be
repeated in POST.


>This sounds like a textbook example of a case where SHOULD is the
>appropriate term, since there are reasons why a server may not want to
>follow the constraint.  I propose adding to the end of the third paragraph
>after:

>    Note that response codes 340 and 440 are used in direct response to
>    the POST command. Others are returned following the sending of the
>    article.

>the following new text:

>    A response of 240 SHOULD indicate that barring unforseen server errors
>    the posted article will be made available on the server and/or
>    transferred to other servers as appropriate.  In other words, articles
>    not wanted by the server SHOULD be rejected with a 411 response and
>    not accepted and silently discarded.

But yes, that is a reasonable alternative to copying the paragraph from
IHAVE.

>Intentionally deceptive spam filters can then be left as a conscious
>decision to not abide by SHOULD, which is explicitly allowed in the
>definition of SHOULD.

Although the causes may be more benign that spam filters, as indicated
above.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: chl at clw.cs.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5