Test rig

Julien ÉLIE julien at trigofacile.com
Fri Jul 10 19:46:57 UTC 2015


Hi Richard,

>> - Empty Followup-To: header with POST -> does the resulting article
>> <4Dd2+P3h5tnpEkLjnDr9qhGr at test.terraraq.uk> 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 <mnp2bg$4rl$2 at news.trigofacile.com>
Message-ID: <test-empty-header2 at a.fr>
Newsgroups: trigofacile.test
From: invalid at invalid.invalid
Subject: Test
Followup-To:
Date: Date: Fri, 10 Jul 2015 15:24:53 +0000

Test.
.
240 Article received <test-empty-header2 at a.fr>


ARTICLE <test-empty-header2 at a.fr>
220 0 <test-empty-header2 at a.fr> article
Path: news.trigofacile.com!.POSTED.localhost.localdomain!not-for-mail
From: invalid at invalid.invalid
Newsgroups: trigofacile.test
Subject: Test
Date: Date: Fri, 10 Jul 2015 15:24:53 +0000
Organization: Groupes francophones par TrigoFACILE
Message-ID: <test-empty-header2 at a.fr>
Injection-Info: news.trigofacile.com; posting-account="<localhost>"; posting-host="localhost.localdomain:127.0.0.1";
	logging-data="4981"; mail-complaints-to="abuse at trigofacile.com"
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 at 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 at 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 <i.am.an.article.you.will.want at example.com>
      [C] CHECK i am a nasty article
      [C] CHECK <i.am.an.article.you.defer at example.com>
      [S] 238 <i.am.an.article.you.will.want at example.com>
      [S] 501 Invalid syntax
      [S] 431 <i.am.an.article.you.defer at example.com>

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)


More information about the inn-workers mailing list