INNd refusing messages
edk at collab.net
edk at collab.net
Thu Mar 15 04:19:14 UTC 2001
I'm using INN 2.3.1 on:
# uname -a
Linux host 2.2.16-8 #1 Tue Jul 4 05:41:27 EDT 2000 i686 unknown
The newsgroups are being used to mirror mailing lists; a moderator
address posts the messages to the lists, and if they're approved
(automatically or manually depending on this list) then they're send to
another email address which gates them to nntp. For the latter, I also
use News::Article and News::Gateway libnet ...
Anyway -- during the past 5 weeks, we've come up with three messages
which were posted to the mailing list, but rejected by INN. I would
like to make the newsgroups a true mirror of the mailing lists
(otherwise I think they're worse than useless) -- so I intend to deal
with these one way or another. The error codes, respectively, are as
441 Duplicate "Content-Transfer-Encoding"
441 Line 57 too long
441 Can't parse "Date" header
Is it really invalid for a message to have the same
Content-Transfer-Encoding twice? If it's not explicitly forbidden by
RFCs, it seems to me that INN should be lenient and accept such messages
... I agree that they're not ideal, but in the particular case in which
this occured, the value was the same in both instances of the header.
For the second one -- the line in question is over 1024 bytes (1342),
but I have to ask -- why should that matter? Shouldn't the message be
valid anyway? The item which exceded 1024 Are there concerns with
buffer overflows in nntp clients? If need be, I'm willing to look into
some form of content-munging -- but only if there really is a need. I'm
guessing that if I do content-munging, I should change the encoding;
does anyone have specific suggestions, or an opinion on whether this
makes any sense?
The last one concerns a Date header which is indeed bogus -- it has a
'%z' instead of a timezone:
Date: Tue, 06 Feb 2001 11:07:13 %z
... I can see more reason why it might be necessary to insist on a valid
date header, though I'm not entirely psyched about trying to figure out
a reasonable way to deal with it (from my perspective). I'd like to
default it to some reasonable value (possibly the time right now) -- but
I can see that in other usage scenarios that may not make sense.
But I am curious about the first two ...
More information about the inn-workers