Symphony.

lol. good stuff.

SO solutions here.. where we at? I’m not hot on editing the core so wondered if anyone has got a step closer to solving the garbage after 45 characters in email subject?

I will try and do this tomorrow, but you will need to hack the core (i.e replace an existing function by a different one) if you need a quick solution. If I find a good solution, I will as well post in on GitHub so Alistair can review (and maybe implement) it.

Sweet deal! thanks for this, as I said if I knew a bit more coding I would have a go.. but it’s a live site with reliance on the contact form.. so gonna wait it out till the weekend and if there is something here by then, that wold be amazing.. if not .. no worries, I can hold out till it’s right!

Will this solution solve the lack of body to the email?

I seem to only get the subject field?

I can’t speak for the Emailtemplatefilter extension, because I have never used it. All I will try is to solve the encoding/wordwrapping problem in the core. It might be or might not be that this solves the extension problems at the same time…

Ok cool got it!

Ok cool got it!

Hey, it’s enough to get it once!

Well, OK, depending on what you get… :-)

Hah double post! must be my mac mini playing up! Installed windows 7 via bootcamp and it’s doign funny things!! must be the microsoft influence!

4 am in the morning …

Now that’s a really “creepy” conspiracy theory!

OK, it looks like I have solved the header encoding problem. Here’s the result of many hours of work:

• It’s a good thing to use Quoted-Printable-encoded email headers.
• This encoding requires “soft line breaks”.

RFC 2045 (chapter 6.7, “rule (5)”) says:

(5) (Soft Line Breaks) The Quoted-Printable encoding REQUIRES that encoded lines be no more than 76 characters long. If longer lines are to be encoded with the Quoted-Printable encoding, “soft” line breaks must be used. An equal sign as the last character on a encoded line indicates such a non-significant (“soft”) line break in the encoded text.

(http://www.faqs.org/rfcs/rfc2045)

Indeed it is rather easy to break your email subject (in Apple Mail) if you use longer lines!

After sending hundreds of emails using different approaches it turned out that there is a simple solution to header encoding. (Well, shouldn’t there always be a simple solution???)

Here is a finally working dead-simple function as replacement for the encodeHeader function in class.general.php:

/***

Method: encodeHeader
Description: Encodes (parts of) an email header if necessary, according to RFC2047;
Added by: Michael Eichelsdoerfer

***/
public static function encodeHeader($input, $charset='ISO-8859-1')
{
    $m = preg_match_all('/(w*[x80-xFF]+w*)/', $input, $matches);
    if($m)
    {
        mb_internal_encoding($charset);
        $input = mb_encode_mimeheader($input, $charset, 'Q');
    }
    return $input;
}

All the magic here is that mb_encode_mimeheader actually works well (I used to think that it doesn’t) if you set the proper character set using mb_internal_encoding. (The default value is determined by the current NLS setting (mbstring.language), which will probably be different on many servers. Properly setting the encoding solves this problem.)

So if you need a quick solution to the header encoding problem, feel free to replace this function.

Here is how I tested it:

I used tricky subjects like this one (including German umlaut characters):

Here cömes ä special teßt string äääääääääääääääöööööööööööööööööüüüüüüüüüäääääääääääääääöööööööööööööööööüüüüüüüüüäääääääääääääääöööööööööööööööööüüüüüüüüü for Symphony‘s email function Lorem ipsum dolor sit amet, consectetur adipisicing

I sent emails using these subjects and:

• analyzed the emails’ raw text
• checked the output in Apple Mail (v4.1, Snow Leopard)
• checked the output in Outlook Express 6 (Win XP)

If this does not work for you, please keep everybody informed using the Bugtracker. My proposal is there.

So replaceing the encodeheader function in symphony/lib/toolkit/ will solve the issue in email subject headers!

You have $charset=’ISO-8859-1’ is this required or can UTF-8 be in it’s place?

and is this the only bit I need to change to get it to work? you mention mbstring.language setting..

I can confirm.. this works! thank you very much michael-e you r are a gentleman!

Yes, it should work.

ISO-8859-1 is just the default, but it will be overridden by the actual function call.

This was rather hard work, but the result looks so simple… Anyway: I am glad to help Symphony to become even better!

Alistair mentioned that mbstring is a non-default PHP extension. So the function posted above will not work for everybody.

I will try and find a universal solution.

I really tried, but I had to give up. See the bugtracker.

So a 100 percent solution is out of reach, but I added a proposal to the bugtracker which is probably a good solution for most of the cases. It uses mbstring functions if available and falls back to an encoding function without wordwrapping – the latter would the real complicated part because you must take care of single- or double-byte encoded characters. Breaking characters apart would mean breaking your header (which also happens with the base64-encoding function implemented in Symphony 2.0.6). So rather have no wordwrapping than a false one.

This means that the fallback function should produce readable email headers which will not match the RFC guidelines as soon as the length of the endoded header exceeds 76 characters. (Beware that a character of any extended character set will be 6 characters after encoding), but they should display properly anyway (at least in Apple Mail and Outlook Express). Please feel free to test more email clients with this.

/***

Method: encodeHeader
Description: Encodes (parts of) an email header if necessary, according to RFC2047 if mbstring is available;
Added by: Michael Eichelsdoerfer

***/
public static function encodeHeader($input, $charset='ISO-8859-1')
{
    if(preg_match_all('/(s?w*[x80-xFF]+w*s?)/', $input, $matches))
    {
        if(function_exists('mb_internal_encoding'))
        {
            mb_internal_encoding($charset);
            $input = mb_encode_mimeheader($input, $charset, 'Q');
        }
        else
        {
            foreach ($matches[1] as $value)
            {
                $replacement = preg_replace('/([x20x80-xFF])/e', '"=" . strtoupper(dechex(ord("1")))', $value);
                $input = str_replace($value, '=?' . $charset . '?Q?' . $replacement . '?=', $input);
            }
        }
    }
    return $input;
}

Some short test results using German Umlaut characters – “OK” means “subject is readable in Apple Mail and Outlook Express”:

1. Short Subject: “Here comes ä test”

   • OK

2. Long Subject: “Here comes ä special teßt string ääääääääää for Symphony‘s email function Lorem ipsum dolor sit amet, consectetur adipisicing”

   • mbstring: OK
   • fallback function: OK, but no wordwrapping (i.e. no RFC conformance)

3. Very long subject including a multibyte word which in itself is longer than 76 characters (and will be much longer after encoding): “Here comes ä special teßt string äääääöööööüüüüüüüÄÄÄÄÄÄÄÖÖÖÖÖÖÖÖÜÜÜÜÜÜÜÜÜäääääöööööüüüüüüüÄÄÄÄÄÄÄÖÖÖÖÖÖÖÖÜÜÜÜÜÜÜÜÜ for Symphony‘s email function”

   • mbstring: OK
   • fallback function: OK, but no wordwrapping (i.e. no RFC conformance)

4. Very short subject using a single umlaut chracter: “ä”

   • OK

5. Subject without multibyte characters - just to be sure…: “Symphony Password Reset”

   • OK (no encoding takes place)