encode_headers in class_email.php is not RFC compliant

[Comablack]

According to the RFC 822:

3.1.1.  LONG HEADER FIELDS

        Each header field can be viewed as a single, logical  line  of
        ASCII  characters,  comprising  a field-name and a field-body.
        For convenience, the field-body  portion  of  this  conceptual
        entity  can be split into a multiple-line representation; this
        is called "folding".  The general rule is that wherever  there
        may  be  linear-white-space  (NOT  simply  LWSP-chars), a CRLF
        immediately followed by AT LEAST one LWSP-char may instead  be
        inserted.  Thus, the single line

            To:  "Joe & J. Harvey" <ddd @Org>, JJV @ BBN

        can be represented as:

            To:  "Joe & J. Harvey" <ddd @ Org>,
                    JJV@BBN

        and

            To:  "Joe & J. Harvey"
                            <ddd@ Org>, JJV
             @BBN

        and

            To:  "Joe &
             J. Harvey" <ddd @ Org>, JJV @ BBN

and

    3.1.3.  UNSTRUCTURED FIELD BODIES

        For some fields, such as "Subject" and "Comments",  no  struc-
        turing  is assumed, and they are treated simply as <text>s, as
        in the message body.  Rules of folding apply to these  fields,
        so  that  such  field  bodies  which occupy several lines must
        therefore have the second and successive lines indented by  at
        least one LWSP-char.

While IPB doesn't respect this rule and formats multiline long headers like:

Subject: line1
line2

instead of

Subject: line1
  line2

(note the indent on the second line) This causes truncation of such headers as Subject (tested with QMail Toaster installation via SMTP). To correct the problem find:

$value = implode($this->header_eol, $encoded_text_parts);

and replace with:

$value = implode($this->header_eol . '  ', $encoded_text_parts);

[bfarber]

While I've never run into this myself...I'd post this in our bug tracker, as it sounds more like a bug than a feature suggestion.

[Comablack]

You didn't run into this because with latin charset subject will hardly exceed 76 characters. I'm using windows-1251 charset and MIME encoded subject of about 10-20 characters exceeds this value and IPB splits it into multiple lines. Also I didn't have this problem myself with the old mail server (which was probably more tolerant to such mistakes), but with the new MTA installation I got this problem.