References header should be wrapped

[mas90]

Problem:

When RoundCube generates a References header, it is sent as one line, regardless of length. It should wrap if excessively long.

To reproduce:

Use RoundCube to reply to a message in a long thread (i.e. a message which already has a large number of message IDs in the References header).

RoundCube adds a References header to the composed message, containing the contents of the References and Message-ID headers of the message being replied to.

Expected behaviour:

References: <1234@example.com> <5678@example.com>
    <9012@example.com> <3456@example.com> <7890@example.com>
    <and-so-on@example.com>

Actual behaviour:

The above header is sent all on one line without breaks.

Why this is a problem:

My mail server (running amavisd-new) complained as follows:

INVALID HEADER: HEADER LINE LONGER THAN RFC2822 LIMIT OF 998 CHARACTERS

  Header line longer than 998 characters: References: <Pr...
                                                                                                        
(...)
                                                                                                        
HEADER LINE LONGER THAN RFC2822 LIMIT OF 998 CHARACTERS

  The RFC 2822 standard specifies rules for forming internet messages.
  Section '2.1.1. Line Length Limits' prohibits each line of a header
  to be more than 998 characters in length (excluding the CRLF).

[mas90]

Having looked into this a bit further, it seems the semantics of rcube_mail_mime._encodeHeaders() are wrong with regards the References header. Since it appears to contain email addresses, it is split into chunks using comma as a delimiter, but References are space-delimited so everything ends up in one chunk.

In fact it appears that _encodeHeaders() makes several poor assumptions. What happens if I enter an email address in the subject of an email, for example? The subject will then not be escaped correctly.

I'm happy to produce a patch to repair this function, but it would be helpful to first know why PEAR::Mail_Mime's _encodeHeaders() was not considered adequate. Thanks.

[thomasb]

The original Mail_Mime::_encodeHeaders() method encoded the whole string including the recipient address if there are non-ascii chars in the header:

From: =?UTF-8?Q?Thomas=20Br=C3=BCderli=20<thomas@…>?=

Then my SMTP server could not find a valid e-mail address in the from field and added @gna.ch which ended up in a completely messy sender address.

I then compared messages send with other mailers (Thunderbird and Apple Mail) and tried to override this method with the heuristic you can see now.

I don't understand why the references header is written in one line because line wrapping is done in encodeHeaders(). However the problem of strictly using comma as delimiter should be fixed.

[thomasb]

A little addition to my previous comment:
Regarding the References header the only problem is that it is not wrapped after 998 characters, right?

With the current solution, a subject header which contains an e-mail address will be correctly encoded.

I've added a hard-wrap for outgoing headers in [762a699d]. I guess this should fix the problem. Alternatively we could check the $hdr_name when encoding values to avoid further problems.

[dfissue]

Replying to thomasb:

A little addition to my previous comment:
Regarding the References header the only problem is that it is not wrapped after 998 characters, right?

With the current solution, a subject header which contains an e-mail address will be correctly encoded.

I've added a hard-wrap for outgoing headers in [762a699d]. I guess this should fix the problem. Alternatively we could check the $hdr_name when encoding values to avoid further problems.

Sorry to re-open this old bug, but it seems that the fix is incomplete, since you forgot to add a space (or a tab?) after the line break.

Expected behaviour:

References: <1234@example.com> <5678@example.com>
    <and-so-on@example.com>

Actual behaviour:

References: <1234@example.com> <5678@example.com>
<and-so-on@example.com>

Why this is a problem:

Exim thinks the email is broken and tried to fix it by adding one more line break like:

References: <1234@example.com> <5678@example.com>

<and-so-on@example.com>

You may try to change line 183 of "program/include/rcube_mail_mime.php" to:

$input[$hdr_name] = wordwrap($hdr_value, 990, "\n\t", true);  // hard limit header length

[alec]

Works for me in trunk. Probably because we're now using default Mail_Mime wrapping. There's no rcube_mail_mime.php file.