Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: Test rig (Richard Kettlewell)
2. Re: Test rig (Richard Kettlewell)
3. Re: Test rig (Julien ?LIE)
4. Re: Test rig (Richard Kettlewell)
----------------------------------------------------------------------
Message: 1
Date: Fri, 10 Jul 2015 16:23:58 +0100
From: Richard Kettlewell <[email protected]>
To: [email protected]
Subject: Re: Test rig
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
On 2015-07-05 21:51, Julien ?LIE wrote:
> Hi Richard,
>
>>> https://github.com/ewxrjk/inntest
>
> That's a pretty useful work, thanks!
>
>
>> Now with HTML output, for example:
>>
>> http://www.greenend.org.uk/rjk/junk/news/innfeed.html
>
> Good to know that the outcome column is all OK.
> Regarding the response codes:
> - I think that's OK for 235 (article accepted) instead of 437 (rejected)
> for IHAVE commands in the examples you give (malformed From: and
> Expires: headers, and empty body) in order to be conservative in what
> has already been injected into Usenet.
>
> - Empty Followup-To: header with POST -> does the resulting article
> <[email protected]> contain that empty header?
> nnrpd normally removes it.
This is:
> - Malformed From: header with POST -> could you please tell what is the
> malformed header you tried? I think nnrpd should enforce a valid
> syntax, so this one is a real bug.
>
> - 435/438/439 instead of 501 to reject articles sent via
> IHAVE/CHECK/TAKETHIS is the right legacy behaviour. Doing otherwise
> would break backwards compatibility so it shouldn't be encouraged right
> now. Maybe in the future...
>
>
> Thanks again for your test rig!
>
------------------------------
Message: 2
Date: Fri, 10 Jul 2015 16:33:20 +0100
From: Richard Kettlewell <[email protected]>
To: [email protected]
Subject: Re: Test rig
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Apologies for previous message, finger trouble.
On 2015-07-05 21:51, Julien ?LIE wrote:
> Hi Richard,
>
>>> https://github.com/ewxrjk/inntest
>
> That's a pretty useful work, thanks!
>
>
>> Now with HTML output, for example:
>>
>> http://www.greenend.org.uk/rjk/junk/news/innfeed.html
>
> Good to know that the outcome column is all OK.
> Regarding the response codes:
> - I think that's OK for 235 (article accepted) instead of 437 (rejected)
> for IHAVE commands in the examples you give (malformed From: and
> Expires: headers, and empty body) in order to be conservative in what
> has already been injected into Usenet.
OK, I'll change the test to accept the current behaviour.
> - Empty Followup-To: header with POST -> does the resulting article
> <[email protected]> contain that empty header?
> nnrpd normally removes it.
This is:
https://github.com/ewxrjk/inntest/blob/64a89a553850deac25ea6e301be4bb8e2ce73753/inntest/errors_post.py#L107
The NNTP messages are:
DEBUG:nntpbits.ClientConnection:00000000 SEND b'POST'
DEBUG:nntpbits.ClientConnection:00000000 RECV b'340 Ok, recommended
message-ID <[email protected]>'
DEBUG:nntpbits.ClientConnection:00000000 SEND b'Message-ID:
<[email protected]>'
DEBUG:nntpbits.ClientConnection:00000000 SEND b'Newsgroups: local.test'
DEBUG:nntpbits.ClientConnection:00000000 SEND b'From:
[email protected]'
DEBUG:nntpbits.ClientConnection:00000000 SEND b'Subject: [nntpbits]
empty followup test (ignore)'
DEBUG:nntpbits.ClientConnection:00000000 SEND b'Followup-To:'
DEBUG:nntpbits.ClientConnection:00000000 SEND b'Date: Fri, 10 Jul 2015
15:24:53 +0000'
DEBUG:nntpbits.ClientConnection:00000000 SEND b''
DEBUG:nntpbits.ClientConnection:00000000 SEND b'hhpR1q5Z2ftvOlk5idV8oKuE'
DEBUG:nntpbits.ClientConnection:00000000 SEND b'.'
DEBUG:nntpbits.ClientConnection:00000000 RECV b'240 Article received
<[email protected]>'
> - Malformed From: header with POST -> could you please tell what is the
> malformed header you tried? I think nnrpd should enforce a valid
> syntax, so this one is a real bug.
This is:
https://github.com/ewxrjk/inntest/blob/64a89a553850deac25ea6e301be4bb8e2ce73753/inntest/errors_post.py#L125
The NNTP messages are:
DEBUG:nntpbits.ClientConnection:00000000 SEND b'POST'
DEBUG:nntpbits.ClientConnection:00000000 RECV b'340 Ok, recommended
message-ID <[email protected]>'
DEBUG:nntpbits.ClientConnection:00000000 SEND b'Message-ID:
<[email protected]>'
DEBUG:nntpbits.ClientConnection:00000000 SEND b'Newsgroups: local.test'
DEBUG:nntpbits.ClientConnection:00000000 SEND b'From: @example.com'
DEBUG:nntpbits.ClientConnection:00000000 SEND b'Subject: [nntpbits]
malformed from test #2 (ignore)'
DEBUG:nntpbits.ClientConnection:00000000 SEND b'Date: Fri, 10 Jul 2015
15:24:53 +0000'
DEBUG:nntpbits.ClientConnection:00000000 SEND b''
DEBUG:nntpbits.ClientConnection:00000000 SEND b'p6oh0XgoXHNjXzc5qBQDrhSu'
DEBUG:nntpbits.ClientConnection:00000000 SEND b'.'
DEBUG:nntpbits.ClientConnection:00000000 RECV b'240 Article received
<[email protected]>'
> - 435/438/439 instead of 501 to reject articles sent via
> IHAVE/CHECK/TAKETHIS is the right legacy behaviour. Doing otherwise
> would break backwards compatibility so it shouldn't be encouraged right
> now. Maybe in the future...
The tests here aren't about rejecting articles - they are about
malformed message IDs.
ttfn/rjk
------------------------------
Message: 3
Date: Fri, 10 Jul 2015 21:46:57 +0200
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: Test rig
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi Richard,
>> - Empty Followup-To: header with POST -> does the resulting article
>> <[email protected]> contain that empty header?
>> nnrpd normally removes it.
>
> This is:
>
> https://github.com/ewxrjk/inntest/blob/64a89a553850deac25ea6e301be4bb8e2ce73753/inntest/errors_post.py#L107
The article that is actually injected into Usenet does not contain the empty
header:
POST
340 Ok, recommended message-ID <[email protected]>
Message-ID: <[email protected]>
Newsgroups: trigofacile.test
From: [email protected]
Subject: Test
Followup-To:
Date: Date: Fri, 10 Jul 2015 15:24:53 +0000
Test.
.
240 Article received <[email protected]>
ARTICLE <[email protected]>
220 0 <[email protected]> article
Path: news.trigofacile.com!.POSTED.localhost.localdomain!not-for-mail
From: [email protected]
Newsgroups: trigofacile.test
Subject: Test
Date: Date: Fri, 10 Jul 2015 15:24:53 +0000
Organization: Groupes francophones par TrigoFACILE
Message-ID: <[email protected]>
Injection-Info: news.trigofacile.com; posting-account="<localhost>";
posting-host="localhost.localdomain:127.0.0.1";
logging-data="4981"; mail-complaints-to="[email protected]"
Xref: news.trigofacile.com trigofacile.test:540
Test.
.
Well, we have now to decide whether nnrpd has to reject the post or remove
empty header fields.
According to RFC 5537:
An injecting agent processes proto-articles as follows:
[...]
2. It MUST reject any proto-article that does not have the proper
mandatory header fields for a proto-article, that has Injection-
Info or Xref header fields, that has a Path header field
containing the "POSTED" <diag-keyword>, or that is not
syntactically valid as defined by [RFC5536].
And RFC 5536:
o Every line of a header field body (including the first and any
that are subsequently folded) MUST contain at least one non-
whitespace character.
NOTE: This means that no header field body defined by or
referenced by this document can be empty.
So to be strictly compliant, the article MUST be rejected by nnrpd.
It is a bug that needs fixing.
>> - Malformed From: header with POST -> could you please tell what is the
>> malformed header you tried? I think nnrpd should enforce a valid
>> syntax, so this one is a real bug.
>
> This is:
>
> https://github.com/ewxrjk/inntest/blob/64a89a553850deac25ea6e301be4bb8e2ce73753/inntest/errors_post.py#L125
>
> DEBUG:nntpbits.ClientConnection:00000000 SEND b'From: @example.com'
If I send "From: a@b", nnrpd complains:
441 From: address not in Internet syntax
so you're right that "From: @example.com" should also be rejected.
Is it the only pattern you found that needs fixing? (empty local part in the
address)
>> - 435/438/439 instead of 501 to reject articles sent via
>> IHAVE/CHECK/TAKETHIS is the right legacy behaviour. Doing otherwise
>> would break backwards compatibility so it shouldn't be encouraged right
>> now. Maybe in the future...
>
> The tests here aren't about rejecting articles - they are about
> malformed message IDs.
Yes, I understand the test case you provide.
What I meant is that the IHAVE/CHECK/TAKETHIS commands were not supposed to
send 501 responses in previous versions of NNTP so backwards compatibility is
broken if we send such answers.
See for instance RFC 2980:
1.1.1 The CHECK command
1.1.2. Responses
238 no such article found, please send it to me
400 not accepting articles
431 try sending it again later
438 already have it, please don't send it to me
480 Transfer permission denied
500 Command not understood
If the client A sends
CHECK really@bad@id
and the server B answers
501 Incorrect syntax
the client A may happily send again the same article, and therefore go on
asking the server B whether it wishes to receive the article.
It then breaks later exchanges.
I remember
(http://lists.eyrie.org/pipermail/ietf-nntp/2009-October/006033.html) having
received <4ac9a2d6$0$21410$afc38c87@> one day, so invalid message-IDs are in
the wild.
Another reason why CHECK/TAKETHIS is not supposed to work this way is as far as
pipelining is concerned. The fact that the message-ID would not systematically
be provided is not good design:
[C] CHECK <[email protected]>
[C] CHECK i am a nasty article
[C] CHECK <[email protected]>
[S] 238 <[email protected]>
[S] 501 Invalid syntax
[S] 431 <[email protected]>
whereas "438 i am a nasty article" is homogeneous with the other responses.
Finally, here are examples from major news servers:
INN 1.7.2 (yes, that was the case in 1.x -- and the same is in versions 2.x):
----------------------------------------------------------------------------
200 feed-A.news.volia.net InterNetNews server INN 1.7.2 (FAST switching patch)
ready
IHAVE test
435 test Bad Message-ID
Diablo:
-------
200 news1.greatnowhere.com NNTP Service Ready (DIABLO 5.0-REL)
IHAVE test
435 test Bad Message-ID
DNEWS:
------
200 mendel.ac-versailles.fr DNEWS Version 5.7e1,, S0, posting OK
IHAVE test
435 article not wanted - Missing opening angle bracket
CHECK test
438 test article not wanted - Missing opening angle bracket
For the above reasons, I am unsure that the legacy response code for invalid
syntax in IHAVE/CHECK/TAKETHIS should be changed. I fear that doing that would
cause endless loops in the exchanges between two servers.
--
Julien ?LIE
? ?tre ?u ne p?s ?tre, telle est l? questi?n? ? (Ker?zen)
------------------------------
Message: 4
Date: Sat, 11 Jul 2015 10:32:01 +0100
From: Richard Kettlewell <[email protected]>
To: [email protected]
Subject: Re: Test rig
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
On 2015-07-10 20:46, Julien ?LIE wrote:
[...]
>>> - Malformed From: header with POST -> could you please tell what is the
>>> malformed header you tried? I think nnrpd should enforce a valid
>>> syntax, so this one is a real bug.
>>
>> This is:
>>
>> https://github.com/ewxrjk/inntest/blob/64a89a553850deac25ea6e301be4bb8e2ce73753/inntest/errors_post.py#L125
>>
>> DEBUG:nntpbits.ClientConnection:00000000 SEND b'From: @example.com'
>
> If I send "From: a@b", nnrpd complains:
> 441 From: address not in Internet syntax
>
> so you're right that "From: @example.com" should also be rejected.
> Is it the only pattern you found that needs fixing? (empty local part in the
> address)
I didn't try to find other possibilities. I'd rather use AFL to attempt
to explore this in more detail, i.e. instead of trying to use my limited
human brain to guess what might or might not be wrongly accepted l-)
>>> - 435/438/439 instead of 501 to reject articles sent via
>>> IHAVE/CHECK/TAKETHIS is the right legacy behaviour. Doing otherwise
>>> would break backwards compatibility so it shouldn't be encouraged right
>>> now. Maybe in the future...
>>
>> The tests here aren't about rejecting articles - they are about
>> malformed message IDs.
>
> Yes, I understand the test case you provide.
> What I meant is that the IHAVE/CHECK/TAKETHIS commands were not supposed to
> send 501 responses in previous versions of NNTP so backwards compatibility is
> broken if we send such answers.
[..]
> For the above reasons, I am unsure that the legacy response code for invalid
> syntax in IHAVE/CHECK/TAKETHIS should be changed. I fear that doing that
> would cause endless loops in the exchanges between two servers.
That's fine, but I'm going to leave it as an 'expected failure' rather
than success, since it does seem to be an RFC violation.
ttfn/rjk
------------------------------
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
End of inn-workers Digest, Vol 74, Issue 2
******************************************
