[Postfixbuch-users] (OT) Shop codiert die Betreffzeile nicht

[Matthias Haegele]

Christian Boltz schrieb:
> Hallo Knuth, hallo Andreas, hallo Leute,
> 
> Am Montag, 11. August 2008 schrieb Knuth:
>> Am 10.08.2008 22:28 Uhr, schrieb Andreas Meyer:
>>> X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char E4 hex):
>>> Subject: Status\344nderung Ihrer B[...]
>>>
>>> Wie codiere ich denn mit PHP die Umlaute? In der betreffenden
>>> email.php habe ich schon folgendes probiert, aber ohne Erfolg:
>>>
>>> $subject = mb_encode_mimeheader($subject, 'ISO-8859-1');
> 
> Dir fehlt ein Parameter, damit quoted-printable rauskommt:
>     $subject = mb_encode_mimeheader($subject, 'ISO-8859-1', 'Q');
> 
> Einschränkung: Bei überlangen Headerzeilen erfolgt der Umbruch stur nach 
> Länge und kann evtl. auch mal mitten in einem Wort erfolgen :-(
> (Das steht dummerweise sogar in der Doku und ist daher wohl nicht 
> bugreport-fähig :-/ )
> 
> Die Kommentare auf http://php.net/mb-encode-mimeheader enthalten diverse 
> selbstgeschriebene Funktionen - ob die besser funktionieren, musst Du 
> testen - besonders mit überlangen Betreffzeilen.
> 
> Auch Postfixadmin verwendet eine selbstgeschriebene Funktion 
> (encode_header in functions.inc.php) - wie ich gerade festgestellt 
> habe, ist die aber auch nicht perfekt, wenn es um längere Betreffzeilen 
> geht :-(
> 
> Frage am Rand: Wie lang darf eine Headerzeile lauf RFC eigentlich sein?

Wenn ich die richtige erwischt habe:
http://www.faqs.org/rfcs/rfc2822.html

> 2.1.1. Line Length Limits
> 
>    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.

> Gruß
> 
> Christian Boltz

hth
-- 
Gruesse/Greetings
MH


Dont send mail to: ubecatcher at linuxrocks.dyndns.org
--