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 (Julien ?LIE)
2. Re: Tweaking inn.conf values for INN 2.6.0 (Julien ?LIE)
----------------------------------------------------------------------
Message: 1
Date: Tue, 14 Jul 2015 21:09:14 +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.
>>
>> we have now to decide whether nnrpd has to reject the post or
>> remove empty header fields.
For the archives of this thread, we finally preferred (after private
discussion) to keep that legacy feature.
A few news clients still rely on this behaviour, and put empty headers
(for instance Followup-To, Summary and Keywords) in the editor. These
headers are then removed by nnrpd, and a few other server software.
A commit has been done to mention that in nnrpd's code.
--- post.c 2015-07-07 16:37:51 UTC (rev 9917)
+++ post.c 2015-07-11 18:54:50 UTC (rev 9918)
@@ -363,6 +363,10 @@
}
if (hp->Value) {
hp->Len = TrimSpaces(hp->Value);
+ /* If the header is empty, we just remove it. We do not reject
+ * the article, contrary to what an injecting agent is supposed
+ * to do per Section 3.5 of RFC 5537. (A revision to RFC 5537
+ * may someday allow again that existing and useful feature.) */
if (hp->Len == 0)
hp->Value = hp->Body = NULL;
}
>>>> - 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.
>>
>> so you're right that "From: @example.com" should also be rejected.
nnrpd currently does a very very basic check of the From: header field.
It only makes sure that the header contains "@" and "." in that order.
We could of course do more checks. Nonetheless, I believe strictly
enforcing the RFC 5322 grammar is too restrictive for nnrpd (and even
problematic for UTF-8 internationalized headers).
Maybe these three other checks could be added:
- at least one non-whitespace character before "@";
- at least one non-whitespace character between "@" and ".";
- at least one non-whitespace character after that ".".
No check that this address is outside a comment.
Do you believe other useful checks should be added?
>>>> 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...
>
> 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.
Do you happen to send CAPABILITIES at the beginning of each NNTP session
of your test rig?
innd could send the expected 501 code to clients that we are sure they
implement version 2 of NNTP (RFC 3977). And we keep backwards compatibility
otherwise, with 43x response codes.
It could be a good move to do, couldn't it?
--
Julien ?LIE
? O fortunatos nimium, sua si bona norint, agricolas. ? (Virgile)
------------------------------
Message: 2
Date: Tue, 14 Jul 2015 21:09:25 +0200
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: Tweaking inn.conf values for INN 2.6.0
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi Florian,
>> * logcycles: increase from 3 to 30 (the current number is
>> ridiculously low; at least a month of archived compressed logs
>> could be kept)
>
> while I'm in favour of increasing buffers etc. and thus make use of
> the vastly expanded storage and RAM commonly available today, I think
> this one has a privacy impact and should not be increased by default
> - three days should be enough to diagnose the most common cases of
> malfunction and abuse, and where more is indeed needed the correct
> knob is easily found.
FYI, I've added a comment in lib/innconf.c to keep track of your
thoughts.This way, we'll remember the reason why this parameter has this
value.Thanks again.
@@ -276,7 +276,11 @@
{ K(innwatchspoolnodes), UNUMBER (200) },
{ K(innwatchspoolspace), UNUMBER (25000) },
- /* The following settings are specific to scanlogs. */
+ /* The following settings are specific to scanlogs.
+ * Keep a low value by default as it has a privacy impact; three days
+ * should be enough to diagnose the most common cases of malfunction
+ * and abuse. Where more is needed, it is easy for the news admin
+ * to increase it. */
{ K(logcycles), UNUMBER (3) },
};
--
Julien ?LIE
? ? O? vous croyez-vous ici ?
? O? je me trouve, je sais. ? (Ast?rix)
------------------------------
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
End of inn-workers Digest, Vol 74, Issue 5
******************************************
