Symphony.

Hey all,

Been playing with the excellent Emailtemplatefilter extension, and have been running into issues sending HTML emails. At first I thought something might have been wrong with my Sendmail configuration, but if I remove the extra headers from the General::sendMail command in the extension.driver.php (as below), my emails do come through without issues, although they are treated as plain/text since thats the default ContentType in the sendMail method.

Has anyone experienced this before?

Cheers, Michael

$return = General::sendEmail(
            $email['recipients'],  $email['senders'], $email['sender'], $email['subject'], $email['message'], array(
                'MIME-Version'  => '1.0',
                'Content-Type'  => 'text/html; charset="UTF-8"'
            )
        );

changed to

$return = General::sendEmail(
            $email['recipients'],  $email['senders'], $email['sender'], $email['subject'], $email['message']
        );

Tropica,

I haven’t worked with this extension in the latest versions (of Symphony or maybe even the extension) but at one point I know there was an issue with the sequence of when the content-type header is set. I can’t recall if it was being reset to text/plain, or if it was set to text/plain, and this extension was not able to override it.

Anyway, if you’re comfortable poking around the core files, take a look at the delegate location that this extension uses, and see where content-type is being set. I think I ended up using the php function header() instead of Symphony’s internal method. I know, this is nice and vague but if you need more specific help( I can take a look at my mod), just let me know!

Thanks for the reply ashooner, appreciate it.

I actually located the issue though, looks like my mail server (MediaTemple) was bouncing the emails and marking them as spam. After looking into the internal Symphony sendEmail method, the culprit seems to be the following two lines.

$subject = General::encodeHeader($subject, 'UTF-8');
$from_name = General::encodeHeader($from_name, 'UTF-8');

If I stop the subject and from_name from being encoded by commenting these lines out, the emails come through without an issue. Interestingly if the Content-Type is text/plain this does not seem to effect it and the emails come through with or without the encoding.

Anyway, this is obviously a question for my host, but if anyone runs into this issue like I did, this might hopefully save some time just knowing about it.

Cheers, Michael

Tropica,

Does this mean you get the body of the message coming through without issues too?

I remember issues with header encoding. I once proposed a working solution which then was implemented in the core. But I think this encoding method has since been changed or removed. I am not really sure about it at the moment. I don’t really have the time to look into it, so if anyone sees a clear issue here, it would be useful to have it on the bug tracker.

@Tropica:

If I stop the subject and from_name from being encoded by commenting these lines out, the emails come through without an issue.

This sounds like a spam filter issue. Those filters are rather sensitive regarding encoding issues. So in an ideal (Symphony) world, it should be the other way round! Encoding should make them come through.

I did a quick check, sending me a “forgotten password” email. I had the following spam report:

pts rule name              description
---- ---------------------- --------------------------------------------------
0.0 UNPARSEABLE_RELAY      Informational: message has unparseable relay lines
0.0 RDNS_NONE              Delivered to trusted network by a host with no rDNS
2.0 FROM_EXCESS_BASE64     From: base64 encoded unnecessarily

So it looks like the “from” encoding might be problematic if it is unneccessary.

I guess the problem is a bit different: The new encodeHeader function seems to base64-encode, where it should be quoted-printable.

I think I will post this on the bug tracker.

OK, I looked into it…

We once had a function in the core which did quoted-printable encoding. I replaced the encodeHeader function in class.general.php by the old function and repeated the test. This is what I got:

pts rule name              description
---- ---------------------- --------------------------------------------------
0.0 UNPARSEABLE_RELAY      Informational: message has unparseable relay lines
0.0 RDNS_NONE              Delivered to trusted network by a host with no rDNS

So the bug report is on it’s way.

nice one michael-e

Thanks. I always had problems with things like this, because my family name contains the German letter “ö”…

Now I remember that I proposed the correct encoding function really a long time ago – we had Symphony 1.7! I know that it had been implemented, but I don’t know why or when it has been changed since then.

Anyway, here is the bug report:

http://github.com/symphony/symphony-2/issues/#issue/154

Myself and Henry noticed some issues withe encodeHeader function yesterday, mainly around that it enforces wordwrap at 75 words for the subject and from lines which was screwing up the base64encode resulting in garbage characters.

Perhaps this function should be overhauled to only base64encode if necessary and remove the wordwrap?

Is there a reason for wordwrap on the subject and from lines?

Yes, wordwrapping is a good thing for emails anyway. I have read a lot about sending emails (since I am building a newsletter extension for Symphony, which is supposed to send come-through-emails!), and you may believe that wordwrapping is harmless and useful alike. The problem is in the base64 encoding, which is simply the wrong encoding here.

I’m getting garbage characters after 45 or so.. squares, diamonds and I with circumflex on top.. the subject is also varied with whoever is logged in and tests the email form!

I also managed to break 2 forum discussion threads by entering these characters in the comment field..

http://www.getsymphony.com/community/discussions/31189/

and

http://www.getsymphony.com/community/discussions/31107/

oops!

who do I inform about this?

@brendo: I am afraid that you are right. Wordwrapping may break the subject line even if it is quoted-printable-encoded. I did a test and really managed to get this:

pts rule name              description
---- ---------------------- --------------------------------------------------
2.9 BAD_ENC_HEADER         Message has bad MIME encoding in the header
0.0 UNPARSEABLE_RELAY      Informational: message has unparseable relay lines
0.0 RDNS_NONE              Delivered to trusted network by a host with no rDNS

So this is a point to think about. I will try and do some testing using SwiftMailer (the framework that my extension uses).

@moonoo: Simply post the problem here:

http://getsymphony.com/community/discussions/20493/

Swiftmailer is getting this right!

I managed to receive the following subject line without any problems:

Fünfter Newsletter mit öööööööööääääääääääääßßßßßßßßßßßßßßßßßüüüüüüüüüüüüüüüüüüüüöääääääääääääääääääääääääääääää

But it is wordwrapped in the email:

Subject: =?utf-8?Q?F=C3=BCnfter?= Newsletter mit
 =?utf-8?Q?=C3=B6=C3=B6=C3=B6=C3=B6=C3=B6=C3=B6=C3=B6=C3=B6?=
 =?utf-8?Q?=C3=B6=C3=A4=C3=A4=C3=A4=C3=A4=C3=A4=C3=A4=C3=A4?=
 =?utf-8?Q?=C3=A4=C3=A4=C3=A4=C3=A4=C3=A4=C3=9F=C3=9F=C3=9F?=
 =?utf-8?Q?=C3=9F=C3=9F=C3=9F=C3=9F=C3=9F=C3=9F=C3=9F=C3=9F?=
 =?utf-8?Q?=C3=9F=C3=9F=C3=9F=C3=9F=C3=9F=C3=9F=C3=BC=C3=BC?=
 =?utf-8?Q?=C3=BC=C3=BC=C3=BC=C3=BC=C3=BC=C3=BC=C3=BC=C3=BC?=
 =?utf-8?Q?=C3=BC=C3=BC=C3=BC=C3=BC=C3=BC=C3=BC=C3=BC=C3=BC?=
 =?utf-8?Q?=C3=BC=C3=BC=C3=B6=C3=A4=C3=A4=C3=A4=C3=A4=C3=A4?=
 =?utf-8?Q?=C3=A4=C3=A4=C3=A4=C3=A4=C3=A4=C3=A4=C3=A4=C3=A4?=
 =?utf-8?Q?=C3=A4=C3=A4=C3=A4=C3=A4=C3=A4=C3=A4=C3=A4=C3=A4?=
 =?utf-8?Q?=C3=A4=C3=A4=C3=A4=C3=A4=C3=A4=C3=A4=C3=A4=C3=A4=C3=A4?=

We’ll have to dig deeper.

http://github.com/symphony/symphony-2/issues/#issue/154/comment/63302

Posted issue and I see you link has set a bug report too! I am definately seeing an issue after 45 characters in my subject field!

big issue for me.

We’ll get this repaired. But it’s nearly 02:00 AM now, I really have to go to bed.

If any of you PHP gurus out there would like to try – please use the function I posted on Github and reverse the logic. The str_replace part should be used for each line of the encoded, then wordrapped string. That should do it.

02:00 AM that’s the best hour to get things done!

nice one michael-e

4 am in the morning …

HAHA LOL.. I love this site! best talks ever!!

The Designer who takes 1 year off every 7 years to re-charge!! my dream scenario!

nice one Nils