mailpost: References header is too long

[Julien ÉLIE]

Hi Harald,

> inews failed:
> inews: References header is too long
> inews: article not posted

It happens when a *whole* unfolded header has more than
998 characters.


> A hack around this was easy to implement (see attachment),
> but I would like to know the story behind this. Most EMails
> forwarded to the news got just a single entry in the
> References field. How comes that a few got tons of
> references? Is this a user error?

Interestingly, RFC 5322 (for mail) defines that the lenght limit
of a line is 998 characters and that "An unfolded header field
has no length restriction and therefore may be indeterminately
long."  (Sections 2.1.1 and 2.2.3)


RFC 5536 (for Netnews):

2.2.  Header Fields

   o  Compliant software MUST NOT generate (but MAY accept) header field
      lines of more than 998 octets.  This is the only limit on the
      length of a header field line prescribed by this standard.
      However, specific rules to the contrary may apply in particular
      cases (for example, according to [RFC2047], lines of a header
      field containing encoded words are limited to 76 octets).
      [USEAGE] includes suggested limits for convenience of display by
      user agents.

         NOTE: As stated in [RFC5322], there is NO restriction on the
         number of lines into which a header field may be split, and
         hence there is NO restriction on the total length of a header
         field (in particular it may, by suitable folding, be made to
         exceed the 998-octet restriction pertaining to a single header
         field line).


RFC 5537 (for Netnews):

3.4.4.  Construction of the References Header Field

   If the resulting References header field would, after unfolding,
   exceed 998 characters in length (including its field name but not the
   final CRLF), it MUST be trimmed (and otherwise MAY be trimmed).
   Trimming means removing any number of message identifiers from its
   content, except that the first message identifier and the last two
   MUST NOT be removed.



Maybe the patch should implement that suggestion, and not only pop
the last one?

my @refarray = ( $references =~ /(<.*?>)/g );
if (scalar(@refarray) > 2) {
  my $last_mid = pop(@refarray);
  $references = shift(@refarray) . ' ' . pop(@refarray) . ' ' . $last_mid;
}

I doubt whether we should do anything if the array has less than 3 elements.
I think the header is broken in that case.

Hmm...  RFC 5536 defines:

   references      =  "References:" SP [CFWS] msg-id *(CFWS msg-id)
                      [CFWS] CRLF


It is then more complicated than what you or I are suggesting!

References: <a at b> <c at d> (<e at f> <g at h>)

pop will return <g at h> which we do not want...
Parsing headers is a plague :-/

-- 
Julien ÉLIE

« Lots of people want to ride with you in the limo, but what you want
  is someone who will take the bus with you when the limo breaks down. »
  (Oprah Winfrey)