Um die Beschränkung der maximalen Zeilenlänge aufzuheben und für die
  Lesbarkeit (RfC 5322, Section 2.2.3 Long Header Fields).

  Man sollte sich nur bewußt sein, daß der Wert des Headers derjenige
  nach dem Unfolding ist (maW: Wer CRLF im Header-Wert haben will, muß
  MIME o.ä. nutzen).

  Each header field is logically a single line of characters comprising
  the field name, the colon, and the field body.  For convenience
  however, and to deal with the 998/78 character limitations per line,
  the field body portion of a header field can be split into a multiple
  line representation; this is called "folding".  The general rule is

  that wherever this standard allows for folding white space (not
  simply WSP characters), a CRLF may be inserted before any WSP.  For
  example, the header field:

          Subject: This is a test

  can be represented as:

          Subject: This
           is a test

  Note: Though structured field bodies are defined in such a way that
  folding can take place between many of the lexical tokens (and even
  within some of the lexical tokens), folding SHOULD be limited to
  placing the CRLF at higher-level syntactic breaks.  For instance, if
  a field body is defined as comma-separated values, it is recommended
  that folding occur after the comma separating the structured items in
  preference to other places where the field could be folded, even if
  it is allowed elsewhere.

  The process of moving from this folded multiple-line representation
  of a header field to its single line representation is called
  "unfolding". Unfolding is accomplished by simply removing any CRLF
  that is immediately followed by WSP.  Each header field should be
  treated in its unfolded form for further syntactic and semantic
  evaluation.

  There are two limits that this standard places on the number of
  characters in a line. Each line of characters MUST be no more than
  998 characters, and SHOULD be no more than 78 characters, excluding
  the CRLF.

  The 998 character limit is due to limitations in many implementations
  which send, receive, or store Internet Message Format messages that
  simply cannot handle more than 998 characters on a line. Receiving
  implementations would do well to handle an arbitrarily large number
  of characters in a line for robustness sake. However, there are so
  many implementations which (in compliance with the transport
  requirements of [RFC2821]) do not accept messages containing more
  than 1000 character including the CR and LF per line, it is important
  for implementations not to create such messages.

  The more conservative 78 character recommendation is to accommodate
  the many implementations of user interfaces that display these
  messages which may truncate, or disastrously wrap, the display of
  more than 78 characters per line, in spite of the fact that such
  implementations are non-conformant to the intent of this
  specification (and that of [RFC2821] if they actually cause
  information to be lost). Again, even though this limitation is put on
  messages, it is encumbant upon implementations which display messages

  to handle an arbitrarily large number of characters in a line
  (certainly at least up to the 998 character limit) for the sake of
  robustness.

  user_pref("mail.identity.idN.headers", "Faltungsheader");
  user_pref("mail.identity.idN.header.Faltungsheader", "X-Info: Dieser Header soll\n hiermit gefaltet werden");  

  X-Info: Dieser Header soll
   hiermit gefaltet werden

  References: <100307.140015.at.566.75.dlg@my-fqdn.de>
             <100307.140159.at.567.13.dlg@my-fqdn.de>
             <100307.140346.at.568.54.dlg@my-fqdn.de>
             <100307.140529.at.569.69.dlg@my-fqdn.de>